数据架构演进史-从数据库到数据中台

数据行业的演变 

在数据领域，从业务方向上可以分为 OLTP（联机事务处理）和 OLAP（联机分析处理）两个领域。这个名字很拗口，但是也很有意 思。 OLTP 就是你在本地操作，相对于单机而言，数据记录在本地， 就叫单机事务处理，在本机操作，数据记录在服务器上，这叫联机事 务处理。 OLAP 就是数据存在服务器上，你在本地调用数据进行在线分析， 这叫联机分析处理。

OLTP 的发展路径其实就是数据库的不断演进，从关系型数据库 从单机数据库到高可用版本，到现在的分布式关系型数据库。另外为了满足各种场景下的数据存储和查询，还诞生了 NoSQL、MPP、时 序数据库等一系列的数据库，大数据行业就此拉开序幕。 

OLAP 的发展路径也很有意思。一开始只是在业务数据库中建个 表，统计一下各种固定报表。后来需要分析的内容越来越多，就开始 不断的向前发展，这样也迎来了大数据分析师的黄金发展期。

蛮荒时代 

最早的时候，是没数据仓库什么事情的，OLAP 的内容也少，只 有少量的固定报表，那时候都是开发人员在业务库直接存储的。

现在很多系统仍然是这样的，比如你采购一个 erp、电商平台等， 自带的绝大部分报表都与业务系统在一个数据库中的。其实这个时候 正式对应系统架构中的“单体架构”。

数据仓库时代 

随着信息系统的不断建设，管理者开始不太满足于固定的寥寥几 张报表，他们期望看到更多细节，找到异常，发现问题。这时候，就 必须要有一个信息系统去满足他们的需求，DSS/BI 系统就顺应而生， 几乎同时，数据仓库的概念也一并被提出。 

1990 年前后，现代化的 BI 和数据仓库几乎同时诞生。这也无可 厚非，这俩天生一对啊。BI 就是 OLAP 的业务应用体系，数仓就是 为了支撑 BI 而生的。数据仓库之父比尔·恩门（Bill Inmon）在 1991 年写了一本书《建立数据仓库》。对，就是那个 inmon、kimball 建仓方法论的 inmon。

这时候，业务数据和分析数据开始分道扬镳，走上了不一样的道 路。业务数据处理(OLTP)向准确、及时、一致的方向不断迈进；分析 数据操作(OLAP)向历史静态、聚合、关联、多维的方向发展。

一个典型的问题就是在业务数据库中，你无法回答类似于一个订 单的选购、下单、支付、发货、完成的全流程各用了多少时间的问题。 当然，你可以通过冗余 N 个时间戳来解决，但是你无法将所有状态 变化的数据统统记录下来。因为 OLTP 是反应当前的情况。 而 OLAP 就可以通过全量表、拉链表等方式保存历史状态数据， 从而对每个对象进行历史分析。

数据仓库建设的目的就是为了进行数据分析用的。原则上来说数 据仓库中的数据是不允许修改的。所以你看HIVE 根本就没有update 和 delete 的功能，很多人非常不理解其中的原因，其实这就是因为 HIVE 就是为了数据仓库而生的。

数据仓库解决的核心问题其实就是上面说到的，解决历史情况追 踪，解决数据分析能力、解决业务频繁变化等一系列问题。 

拿 inmon 老爷子的话来总结一下： 数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、 反映历史变化（Time Variant）的数据集合，用于支持管理决策 (Decision Making Support)。

数据湖时代

数据仓库很好用，多维分析简直能满足老板的一切需要。它能让 决策者从公司总体情况，一直下钻到每个业务员的贡献，极大的满足 了决策者的掌控欲，同时也给企业的决策带来了坚实的数据基础。 但是，数据仓库也有其非常致命的弊端：所有数据必须经过定义 之后才能被使用，所有数据都经过了 ETL 处理，所有数据都被聚合。 作为数据工作者的你，肯定能理解其中的含义。一旦数据被动过， 那就会造成信息丢失。

而在算法时代，这是不可接受的。 因此，在数据仓库发展了 20 年之后的 2010 年，Pentaho 的创 始人 James Dixon 提出了一个“数据湖”的概念。简单来说，数据 湖其实可以理解为一个巨大的 ODS 层。

任何使用数据的同学都可以直接到数据湖中自由提取数据： 在多维分析报表中钻取到最细颗粒度之后仍然不能解决问题的， 就到数据湖中查看最原始的数据，查找根因。 在进行算法设计的时候，数仓中处理的数据已经损失了一部分信 息，那就去数据湖中找更详尽、更丰富的底层数据，没准可以找到最佳特征。

数据中台时代 

数据湖貌似非常完美，能解决一切问题，但是肯定哄不住专业的 你。是的，数据湖说的好听，是一个原生态的，任由你汲取的巨型数 据源，说的不好听，就是一个数据垃圾堆。不管你管理的多么好都无 法改变这个事实。 你现在已经找到了一个异常客户，想找到这个客户在公司业务流 中的表现。我们应该会通过 CRM 与其进行沟通和跟进；通过交易平 台与其发生交易；货物是通过 ERP 进行采购的，通过 WMS 记录货 物存储信息的，通过 TMS 记录货物运输过程信息的。最后你是在微 博中收到了他的抱怨信息，在客服中心的 CallCenter 接到投诉电话 的。 这个时候，你想怎么办？各个系统都是独立建设的，所有数据都 在数据湖中，你就是没办法把他们串起来！而且，这还是一条业务线。 公司通常都会有 N 条业务线，每个业务线的系统都统统单独建立一 遍，一个客户与公司发生关系的系统越来越多。 这个时候，数据中台就出现了。

图片来自于阿里云数据中台解决方案手册

所以你可以看到，数据中台解决的是什么问题： 实体的打通和画像-OneID; 数据资产的统一构建与管理-OneModel； 数据服务的统一服务-OneService 这三点，共同组成了数据中台的 OneData 的方法论体系。 OneID 是最底层的数据打通，把各条业务线、各个业务系统的相 同实体（如客户）进行统一识别。用户端的感觉就是你用一个 id，可 以通行阿里系所有 app。企业端的感觉就是无论用户用什么客户端， 通过那个系统与企业发生关系，都能识别成为一个用户；

OneModel 是中间层数据的统一建模，这里其实就是数据仓库。 只不过不是一个业务线的数据仓库，是整个企业，整个集团的，统一 的数据仓库。 OneService 是业务层的统一服务提供，其实还是那一套，主数 据、即席查询、固定报表、多维分析等等。当然会多一些算法层面的 试探，也仅仅是试探而已。 我在之前的工作中，就曾建立数据中台，主要工作内容就是做商 品 id 和用户 id 的打通，进行全局统一建模，提供统一的商品主数据 的编码工作和统一的数据输出。

在数据层面进行多条业务线的服务合并、标准化、统一化，统一 抽象，这就是数据中台。每个架构都是要解决特定的问题的，数据中 台解决的核心问题就是全局统一，全局标准，全局打通。 所以，不要神话中台，更不要神话数据中台。你没有这个问题， 或者说当前最紧急的问题不是中台最擅长解决的，那就不要跟风建中 台。那样会死的很惨的。 

以上，与君共勉！