一文读懂数据架构的进化史

近期看到很多企业在设计自己的数据平台，以及选型一些数据分析工具，正好拜读了数据仓库之父的《数据架构：大数据、数据仓库以及Data Vault》一书，有些许感触，就来聊一下个人思考吧。

首先从企业信息化发展阶段时，数据平台结构的程度来看。个人依照企业信息化，将数据平台阶段划分为：只有业务数据库——>中间库——>完善数据仓库(DW)——>数据集市(Data Mart)，顺序与阶段并不绝对正确，可能有组合，可能所在阶段不完全一致。以下先看各个数据平台阶段特点，再看对应阶段数据分析 工具 选型的考虑吧。

1.业务数据库

一个企业IT信息化建设最初的阶段，业务库中数据量不大，要分析展示下数据情况啦，不慌，问题不大，这时候OLTP结构下也可以写写 SQL 快速展现，随便玩玩office工具也没问题。

但是随着时间的推移，各种问题开始出现：

• (1)查询和写入频率越来越高，高频write和和长时间read冲突越来越严重。而数据分析要耗费大量计算资源，不能动不动挂业务系统吧。
• (2)数据量越来越大，历史业务数据啦，新业务数据激增啦，第一要务就是要解决业务应用效率问题了，谁管数据分析里的问题呢。
• (3)业务越来越多，表结构越来越复杂。业务系统数量的越来越多，导致数据孤岛开始形成。

这种情况下，企业面临数据展示与数据平台建设的阶段了要怎么处理。这种情况下要做数据分析就麻烦了，要人为去各个系统取数，人力是一个方面。各个系统口径命名啥都有差异，人为的处理出错率高就是另一方面。

2.中间库

由于上述问题，就要引入中间库来处理。左图结构解决了高频write和read冲突问题，以及单数据库服务器性能问题，顺手也搞定了数据备份。这种情况下呢简单查询还是可以的，但是在转换聚合等需要多表关联、以及大数据量等业务复杂度高的情况下，其处理性能就不容乐观了。

此时就开始考虑可以利用空闲时间的服务器性能来做预先处理呢。右图这种T+n的预处理离线计算的架构就出现了，引入独立的任务调度和计算引擎：计算压力可以交给数据库处理，也可交给ETL处理，展现性能初步解决。

但是这种情况下，数据库表结构实在太过复杂，每做一个分析，就要理一次业务逻辑、写一段sql，还没法进行历史追溯，以及数据整理成果的复用，so sad。

那有没有理一次之后，后续能够省点事的方式呢?这时候数仓的概念就可以使用上了。

3.完善数据仓库(DW)

把业务库数据整理成星型结构，保证了事实的积累和维度的追溯。自由选择需要的维度和相关事实进行筛选计算，麻麻再也不用担心每次写sql都要去看“蜘蛛网”了。还有索引、结果表、分区分表等等黑科技来保证每次查旬需扫描的数据量最小，解决数据库性能问题。

当然这种架构方式的缺点也很明显，不是企业内一致的数据(多系统，多主题数据不一致)，就会产生信息孤岛。当然，如果客户企业就是很小，就一个系统，不用整合，一个数据集市足以的情况下采用这种方式也可以。常见情况是会在各个独立的DW间建立一些对照表，可实现数据交换。如果多个DW间没有物理隔绝，也可以形成EDW。

4.完善数仓+数据集市(Data Mart)

为了实现各个业务系统取数分析，或者做更多操作，就实现中心数据仓库EDW从各个源系统收集数据，再将数据提供给各个数据集市和挖掘仓库使用。这也被称为企业信息工厂架构(CIF)，一般情况下，大型企业会花费许多精力实现这类架构。

业务复杂度的提高与数据量级的增大以及对这些数据的应用，促成了各个大数据平台的繁荣，这个放到另一篇文章陈述。

无论是以什么架构存在，数据展示的需求都必不可少。分析工具选择必不可少，要在以上阶段以一款工具涵盖，那必然需要一款既可以做敏捷数据集市建模，又可以做数据展示分析的工具来处理。这种工具可对业务数据进行简单、快速整合，实现敏捷建模节省时间，并且可以大幅度提升数据的展示速度，可对接前端的数据分析展示层，实现自由数据展示与OLAP分析，典型如各类BI分析工具。

数据分析也很考验分析工具数据读取、运算的性能，但拥有大数据量计算引擎的BI分析工具并不多。像FineBI与其高性能数据引擎在以上几个阶段均可在不同程度解决很多场景。

(1)业务数据库阶段，此阶段已经陈述过，重点问题就是计算性能影响大，以及数据孤岛问题。建立数仓的过程相对敏捷数据集市而言，时间还是久的。这个时候就看看建立个常规意义的数仓和数据展示需求谁更紧急啦，或者可能有的也没建数据平台的意识也说不准。此时快速的数据展示需求，就可以通过将数据放到FineBI的数据引擎中支撑实现。

(2)中间库与完善数仓阶段，此阶段其实主要就是计算性能问题了，用户的数据量级也一定挺大了。正好借助于FineBI的分布式引擎，完成数据加速计算工作。此引擎属hadoop生态，核心计算引擎利用的spark，借助了alluxio作为内存加速计算，处理了大数据计算问题，也很好阐释了“大数据”。这个在接下来的文章中也会说到，这里先埋个伏笔，暂不赘述。

此阶段呢，肯定有一些响应时间要求较高的展示需求，多次作业同步可能带来延迟影响。而FineBI的引擎扩展了kettle的插件，实现数据可以直接load到引擎中，倒是将麻烦的作业处理工作解决了。

(3)完善数仓+数据集市阶段，这种阶段数据平台建设已经很完善了，各业务部门数据量级，业务复杂度都很高。

底层技术上虽然数据集市是建立在集成的中心数据仓库EDW上，但是这些数据集市之间还是不能进行数据交换的，大家建立的方法和ETL程序都会不同，各个数据集市之间的数据不见得的是一致，且平台架构超级复杂，扩展以及再为各业务部门设计计算层结果表之类都相对麻烦。此时可考虑部分需整合数据放到敏捷数据集市处理，可直接对接的再直接对接处理。FineBI的引擎恰好都满足这样的场景需求，前端OLAP分析恰好也有，简单处理整合展示一站式解决。