数据仓库那些事儿之架构篇

Posted 2021-04-24 十年IT老兵

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了数据仓库那些事儿之架构篇相关的知识，希望对你有一定的参考价值。

数据仓库那些事儿之架构篇

从建设数据仓库的企业规模来看，目前主要集中在特大型及大型企业，原因主要有三：其一，建设数据仓库需要巨大的资金支持，小企业很难在财力上持续投入；其二，数据仓库本身是基于大量内外部基础数据建立而成，中小企业一般不具有这样的数据规模，当然目前互联网行业有很多企业规模不大，但数据量极大，不过他们一般不会花巨资投如在传统数仓上，而是更喜欢用大数据（互联网行业大数据的概念与传统行业数据仓库的概念还不太一样）、云计算这种方式来处理内外部数据；其三，数据仓库存在产出不确定性，即投入产出比并不明确，大量数据并没有为企业创造大量价值，企业投入热情不高。

我参与过浦发银行数仓维护、平安保险数仓开发、平安银行数仓建设，都是大型或超大型银行及保险企业，几家企业数仓除软硬件差异、所选数据库不同外，架构上几乎没有明显差异，下面以银行为例，说说一般银行的通用数据仓库架构。

从下往上看。

业务系统层
数据仓库数据来源主要有以下几个：业务系统、日志文件、外部数据等，其中业务系统是最主要的数据来源，但凡搭建数据仓库的企业，其对接导入的业务系统数量都很多，以中大规模的股份制商业银行为例，作为数据源的业务系统会高达几十个甚至上百个。
总行数据管理层
总行数据管理层包括总行级数据仓库和面向各部门、各分行、各业务主题的数据集市，总行数据仓库数据最为全面，集成了全行所需要的各种数据及外部机构所需要的各类数据。总行数据仓库因为数据量非常大，所以对数据的入库管理非常严格，这里的严格主要包括三个方面：一个是无效数据或低效数据严格控制不让其入库，第二个是数仓内数据生命周期受到严格控制，保留时效一般不会超过2-3年，再一个就是数据的加工会总分层明确，这可以极大的提供公共数据利用率以及结算效率。
总行数据仓库应用层
所谓的数据仓库应用层，指的是基于数据仓库所构建的“报表系统”及“下游业务系统”。
报表系统是数据仓库的标准产出系统，也是数据仓库覆盖范围最广、使用频度最高的应用系统，报表系统的用户遍及全行，上至总行总裁室领导，下至各事业部、各中心、各分行、各支行直至最基层业务人员。报表系统一般采购外部第三方成熟的报表工具软件，比如Cognos、BIEE、BO等工具，当然ETL层工作也是必不可少的。
下游业务系统主要是基于数据仓库开发的、时效性要求较低的数据分析型系统，比如各类绩效考核系统、各类数据查询系统、外部机构数据查询系统（人行、监管机构、司法机关、民政机关等）。
总行数据文件服务器
传统行业数据仓库一般都采用数据库存储方式，比如teradata，oracle，mysql集群等，文件服务不是数仓数据主要的存放方式，但文件服务器也有它不可或缺的作用。在数据入库环节，有部分数据源是通过文件方式传递到数仓文件服务器，再通过ETL导入数仓中，由于银行的多层级机构和业务系统接口权限控制的关系，分行级数仓（也有些人认为分行级数仓应该叫数据集市）不能直接对接总行级业务系统，分行数仓数据来源主要依靠总行数仓的数据下发，总行数据下发主要途径就是“文件下发”。总行数据通过ETL工具，把对应分行的数据拆分出来打包成“数据源文件”，通过FTP方式下发推送到分行数据文件服务器，分行获取到数据文件后，再经过ETL过程将文件拉入分行数据仓库中。
分行数据文件服务器
分行数据文件服务器的左右与总行数据文件服务器作用功能及其相似，参照上文第4点，分行数据文件服务器主要用来接收总行下发的数据文件，供给分行数仓入库使用。
分行数据仓库
分行数仓与总行数仓也及其相似，不同的是分行数仓只有自己分行权限内的数据，比如上海分行不会拥有北京分行的数据，虽数据量远远小于总行数仓，但是对于各个业务系统的数据掌握还是非常全面的，以我在分行为例，上海分行已经入库的系统数据多达30个，目前生产库的数据量已达30Tb。
分行数据仓库应用层
分行数据仓主要作用于总行也及其相似，应用大头儿仍是报表，同时基于分行数仓建立的业务系统也有一些，以我所在的上海分行为例，目前基于分行数仓建立的系统主要有对外查询系统（本级司法、公安、民政），监管报送系统，头寸系统等，信审绩效系统等。