Ｇ－ＬＡＧ五月份作业－数据架构演化－罗小川
近期公司正在进行数据平台招标工作，过程中有些平台建设思路以及数据分析工具选型的问题等思考，期间有些许感触，想结合日常的工作实际情况，来聊一下个人思考，请大家指正。
首先从企业信息化发展阶段时，数据平台结构的程度来看。个人依照企业信息化，将数据平台阶段划分为：只有业务数据库——>中间库——>完善数据仓库（DW）——>数据集市（Data Mart），顺序与阶段并不绝对正确，可能有组合，可能所在阶段不完全一致。
以下先看各个数据平台阶段特点：
1.业务数据库
一个企业IT信息化建设最初的阶段，业务库中数据量不大，要分析展示下业务数据情况，这时候在传统数据库的OLTP结构下也可以写写SQL快速展现业务所需数据。
但是随着时间的推移，各种问题开始出现：
（1）查询和写入频率越来越高，高频write和和长时间read冲突越来越严重。而数据分析要耗费大量计算资源，如果SQL效率执行效率不高，严重的情况下会对业务系统产生严重的影响，拖慢日常的业务接单效率直至数据库宕机。
（2）数据量越来越大，比如历史业务数据啦，新业务数据激增啦，此时第一要务就是要解决业务应用效率问题了，此时数据库上的数据查询、数据分析效率低的问题就会被边缘化。
（3）业务越来越多，表结构越来越复杂。业务系统数量的越来越多，导致企业数据孤岛开始形成。
这种情况下，企业面临数据展示与数据平台建设的阶段了要怎么处理。这种情况下要做数据分析就麻烦了，要人为去各个系统取数，人力是一个方面。各个系统口径命名啥都有差异，人为的处理出错率高就是另一方面。
2.中间库
由于上述问题，就要引入中间库来处理。下面左图结构解决了高频write和read冲突问题，以及单数据库服务器性能问题，顺手也搞定了数据备份。实际上这点在我公司的实现就是增加了数据的镜像库层，将部分分析类统计查询需求放到了这上面，这种情况下呢简单查询还是可以的，但是在转换聚合等需要多表关联、以及大数据量等业务复杂度高的情况下，其处理性能就不容乐观了。
此时就开始考虑可以利用空闲时间的服务器性能来做预先处理呢。右图这种T+n的预处理离线计算的架构就出现了，引入独立的任务调度和计算引擎：计算压力可以交给数据库处理，也可交给ETL处理，展现性能初步解决。我们公司目前也是部门系统采用了此方案，例如官网、呼叫中心的客户、保单类数据的汇总推送就是通过公司自己搭建的ODS层进行了数据的简单汇总后，按照T＋Ｎ的不同策略，把数据分发到各个下游数据库中，提供给最终系统用户使用。
但是这种情况下，数据库表结构实在太过复杂，每做一个分析，就要理一次业务逻辑、写一段sql，还没法进行历史追溯，以及数据整理成果的复用。
那有没有理一次之后，后续能够省点事的方式呢？这时候数仓的概念就可以使用上了。
3.完善数据仓库（DW）
这个阶段就是我们目前数据平台建设正在开展的工作阶段，实际上就是需要我们把业务库数据整理成星型结构，保证了事实的积累和维度的追溯。自由选择需要的维度和相关事实进行筛选计算，再也不用担心每次写sql都要去看“蜘蛛网”了。还有索引、结果表、分区分表等等黑科技来保证每次查旬需扫描的数据量最小，解决数据库性能问题。
当然这种架构方式的缺点也很明显，不是企业内一致的数据（多系统，多主题数据不一致），就会产生信息孤岛。当然，如果客户企业就是很小，就一个系统，不用整合，一个数据集市足以的情况下采用这种方式也可以。常见情况是会在各个独立的DW间建立一些对照表，可实现数据交换。如果多个DW间没有物理隔绝，也可以形成EDW。
4.完善数仓+数据集市（Data Mart）
这个阶段是我们数据平台后面的快速迭代发展阶段，我们会为了实现各个业务系统取数分析，或者做更多操作，就实现中心数据仓库EDW从各个源系统收集数据，再将数据提供给各个数据集市和挖掘仓库使用。这也被称为企业信息工厂架构（CIF），一般情况下，大型企业会花费许多精力实现这类架构。
业务复杂度的提高与数据量级的增大以及对这些数据的应用，促成了各个大数据平台的繁荣。
总的来说，个人感觉我们公司的数据结构的演化过程也是正在经历着从二阶段走到三阶段，并通过一到两年的时间努力完成整个公司数据中台体系的搭建完成。相信通过领导的正确领导和同事的协同努力下，并将实现此目标。