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

近期看到很多企业在设计自己的数据平台，以及选型一些数据分析工具，正好拜读了数据仓库之父的《数据架构：大数据、数据仓库以及DataVault》一书，有些许感触，就来聊一下个人思考吧。首先从企业信息化发展阶段时，数据平台结构的程度来看。

但随着时间的推移，各种问题开始出现：（1）查询和写入的频率越来越高，高频写入和长时间阅读冲突越来越严重。数据分析需要大量的计算资源，而您无法移动业务系统。（2）数据量越来越大，历史业务数据即将来临，新的业务数据正在激增。首要任务是解决业务应用效率问题。谁在乎数据分析中存在的问题？（3）越来越多的企业，表结构越来越复杂。越来越多的业务系统导致了数据孤岛的形成。

但是这种情况下，数据库表结构实在太过复杂，每做一个分析，就要理一次业务逻辑、写一段sql，还没法进行历史追溯，以及数据整理成果的复用，sosad。那有没有理一次之后，后续能够省点事的方式呢？这时候数仓的概念就可以使用上了。把业务库数据整理成星型结构，保证了事实的积累和维度的追溯。自由选择需要的维度和相关事实进行筛选计算，麻麻再也不用担心每次写sql都要去看“蜘蛛网”了。

为了实现对每个业务系统的分析或进行更多操作，中央数据仓库EDW从各种源系统收集数据，然后将数据提供给各种数据集市和采矿仓库。这也称为企业信息工厂体系结构（CIF），通常，大型企业花费大量精力来实现此类体系结构。

业务复杂性的增加以及数据量的增加和这些数据的应用促进了各种大数据平台的繁荣，这在另一篇文章中有所介绍。无论架构如何，对数据表示的需求都是必不可少的。分析工具的选择是必不可少的。要被上述阶段的工具所覆盖，必须拥有一个既可以进行敏捷数据集市建模又可以进行数据显示分析的工具。

（3）改善舞台和数据集市阶段。这一阶段的数据平台建设已经完善。每个业务部门的数据级别都很高，业务复杂性非常高。在底层技术中，尽管数据集市建立在集成的中央数据仓库EDW上，但这些数据集市之间仍然没有数据交换。建立的方法和ETL程序将不同，数据集市之间的数据将不同。不一定一致的是平台架构是超级复杂的，并且为每个业务单元扩展和设计计算层结果表相对麻烦。