3.1　数字化转型的4个阶段

在2018年IBM和Forrester Consulting联合发布的报告《数字化转型的深层实质》中，数字化转型的任务由3个主要系统承担：SoE（System of Engagement，行动系统）、SoI（System of Insight，洞察系统）和SoR（System of Record，记录系统）。SoR将系统需要的数据记录下来，SoI负责从数据中发现洞见，而SoE负责根据洞见来引导行动。虽然数字化转型的模型有多种表现方式，但其主要功能和建设内容还是这三个方面。

到目前为止，数字化转型经历了4个不同的发展阶段，分别是信息化阶段、数据仓库/数据集市阶段、数据湖/大数据平台阶段、人工智能/数据中台阶段。这四个阶段的主要建设成果对应着数字化转型各方面的目标，并推动这些目标付诸实现。下面，我们来具体谈谈数字化转型的这四个阶段。

3.1.1　信息化

所谓信息化，在业务层面，就是把面向交易的数据、所有的业务系统用计算机管理起来；在技术层面，采用的技术是关系型数据库、各种范式的管理以及联机事务处理过程（On-Line Transaction Processing，OLTP）。这个阶段的主要任务是把生产行为、交易行为数字化，涉及的IT系统包括但不限于以下系统。

·买卖行为：网页商城、传统柜台业务系统

·进销存：ERP、财会系统

·客户管理：CRM

·供应链管理：SCM

·生产管理：MES

·传感系统：各种传感器

信息化是所有数据系统和数字化运营的根本，需要注意的是，信息化不是一步到位的。随着新业务的出现，新系统的信息化必须与现有系统协调发展，倘若无法完成SoR的需求，就会造成信息丢失、数据割裂。

不过，这个阶段主要依赖的OLTP在作为分析工具时存在明显不足。在OLTP系统中统计一些基本数据很容易，但是进行面向历史的综合分析则会非常困难。例如，要统计每天的销售情况、库存情况非常容易，而如果涉及“过去30天按地区、用户性别、年龄、产品类别的销售分类”或者“哪些产品在过去一年内因为库存不足造成过销售流失”之类的数据，统计起来将会非常困难且效率低下。这是因为在OLTP系统中，历史数据并没有专门的存储和查询优化，查询将会影响到生产数据库，而且无法直接查询某些历史数据（如某个用户过去30天账户余额的变化），也无法自由探索不同维度的组合，维度稍微多一些，数据库就撑不住了。因此使用OLTP数据库无法高效地支持“快速全面的商业洞见”。于是，数据仓库和数据集市应运而生。

3.1.2　数据仓库（数据平台1.0）

数据仓库（Data Warehouse）及其分支数据集市（Data Market）就是为了解决OLTP的不足，完成数字化转型中SoI的需求。它们把OLTP中的数据采集过来，做成面向历史、主题、分析的数据集，进而可以轻松做出上述OLTP难以做出的分析。

图3-1所示为20世纪90年代的数据仓库架构，它与今天常见的数据仓库架构图其实差别并不大。在这个阶段大家第一次意识到数据本身的价值，因此这一阶段的成果可以称为数据平台1.0。

图3-1　20世纪90年代的数据仓库架构

虽然数据仓库解决了OLTP的问题，但是大家发现，当要做某一个业务统计时，通常需要在数据仓库中做一个拥有数百个庞大字段的表去查询，以至于速度太慢，于是就出现了数据集市。

数据集市还是为了解决效率和限制的问题。在技术层面，它与数据仓库类似，但在业务层面，它是针对单个业务域、主题域、面向分析的数据库，它去掉了对事务性（Transactional）的要求，保留了关系型和低一级的范式。因此，它的范式要求没有那么高，有一些信息冗余，但数据查询不需要很复杂的SQL，比较高效且容易实现。

但在数据仓库发展了十多年之后，随着互联网时代的到来，数据仓库还是暴露了很多问题。一个较为明显的问题就是，由于数据仓库的数据只来源于业务系统功能，只能提供一些汇聚的业务信息，所以能做的功能有限，无法提供个性化的信息以及一些非传统业务数据源的信息。例如，每个访问网站的用户按照顺序访问过哪些网页、点过哪些链接、什么时候离开网站，这些个性化的信息数据仓库都无法提供。

另外，一些非传统业务数据源的信息，例如引导用户访问的推荐链接、用户的IP地址、每个请求网站响应的时长，一般存储在服务器日志中，每天所产生的数据量是业务数据量的几千上万倍，而且包含很多价值未知的数据，如果都存储到数据仓库中，其效率之低和限制是无法想象的。在最开始的时候（2006年以前），有很多公司试图用传统技术（如Teradata）来解决这个问题，但都以失败告终。例如，作为原美国四大搜索引擎公司之一的Ask.com，曾经试图在广告商和渠道商的维度上加上地区、内容类别、人群信息等维度，做成深度分析的数据仓库。但即使使用成本高达数百万美元的Oracle集群也需要两天时间才能算完一天的数据，这显然是不值得做的。

除了性能和效率的问题之外，数据仓库有一个重大的局限是其提供的数据能力受到先验经验的限制。数据仓库中的数据经过了高度聚合或处理，从流程上来说比较依赖其在建设时的顶层模型设计。数据在建模和入库的时候需要预先设置Schema和分析主题，而很多数据模型和分析主题的设计比较依赖设计者的经验。如果需要分析的主题或者提供的数据服务在这些预制的数据模型之外，就需要进行比较大的系统改动。这是很多早期的数据仓库建设没有带来令人满意的效果的重要原因之一。

3.1.3　大数据平台（数据平台2.0）

大数据平台（Big Data Platform），包括其中的关键组件数据湖（Data Lake），打破了数据仓库中数据存储和处理的局限，提升了SoR的效率，可以存储和记录更多的数据，也加强了SoI的能力，可以进行很多以前无法完成的查询。此时也出现了很多基于数据驱动的应用，提供SoE的功能。

数据湖在业务层面实现了业务系统的如实快照（贴源层），可以高效存储日志数据、埋点数据、媒体数据、爬虫数据；在技术层面，采用HDFS、Hive、MongoDB、对象存储等技术，解决了个性化信息和非传统业务源信息的分析难题。这个阶段的数据平台开始能够处理业务数据之外的各种数据，因此可以称为数据平台2.0。

在这个阶段，数据仓库和数据集市基于大数据技术得到了进化。在业务层面，它们聚合了更多的数据源，支持更丰富维度的聚合分析；在技术层面，采用了MPP（Vertica、GP）、SQL-on-Hadoop（Presto、Impala、Hive）、高维度分析（Kylin）等技术手段；而在需求方面，这个阶段数据仓库和数据集市的需求与传统的数据仓库和数据集市是类似的，只是运用了更多大数据技术，更多的是做非传统关系数据库。在这个阶段，不再需要Transactional、关系型、范式。

在这个阶段还出现了新型数据库NoSQL。正如其名，NoSQL不是基于SQL的数据库，它包含键-值存储（Key-Value Store）、文档数据库、对象数据库、图数据库等。例如HBase、Cassandra、ClickHouse等键-值存储可以提供海量个性化数据（用户/产品画像、标签体系）的存储和访问（业务的、分析的）。

后来又出现了实时数据、流式数据，从而可以对实时、流式处理的需求进行更快速的响应。比如，根据某个用户在第一分钟内的行为就能够马上对其进行个性化推荐，这就是实时、流处理的威力。Twitter于2013年收购流处理框架Storm，就是因为Twitter的广告有很强烈的实时需求，当用户点击一条推文时，马上就可以为这个用户推送合适的广告。只有这种实时流数据才会用到Storm、MQ、Kafka这样的技术。

之后出现的半结构化数据、对象数据处理技术（如JSON API、文档数据库、对象数据库）可以快速响应业务变更，从而克服了关系型数据难以变化、媒体存储效率低下的问题。例如，对于传统的关系型数据库，增删字段、改变数据库的逻辑是一件非常麻烦的工作，而对于半结构化数据、对象数据，这样的业务变更就会非常容易。

总的来说，虽然在大数据平台阶段基于大数据技术实现的数据仓库和数据集市与传统的数据仓库和数据集市在名称上相同，在业务层面的需求也一致，但前者能够满足更多的数据源和更丰富维度的聚合分析，并能够实现更高维度的数据分析。

可见，基于大数据技术实现的数据仓库和数据集市与传统的数据仓库和数据集市还是存在较大差异。因此在本书中，我们将基于大数据技术实现的数据仓库和数据集市称为大数据数仓、大数据数集，以示区分。

3.1.4　数据中台（数据平台3.0）

通过上面三个阶段的描述我们看到，信息化、数据仓库、大数据平台已经逐步提供了SoR、SoI、SoE的功能，如此一来似乎所有的问题都已经解决。那么，现有的数字化转型体系究竟还有哪些局限，非得要数据中台来做不可？

正如我们在本书开篇抛出的问题，基于计算与存储结构提供标准统一、可链接萃取的数据中台，包含数据采集研发、链接与萃取、数据资产管理、统一数据服务，这不都是大数据平台应该提供的功能、应该做的吗？为什么还有那么多公司要建设数据中台呢？

让我们再回头来看看阿里巴巴对于数据中台需要解决的问题的描述：“各个部门数据重复开发，浪费存储与计算资源”“数据标准不统一，数据使用成本高”“业务数据孤岛问题严重，数据利用效率低”。原来，在很多企业中，这些本应在大数据平台阶段解决的问题并没有得到考虑和解决，因此需要一个新平台来为大数据平台“打补丁”，而这个新平台就是所谓的“数据中台”。因为硅谷的很多企业在大数据平台阶段就已经考虑到并解决了上述问题，所以硅谷并没有出现“数据中台”的概念。

这个阶段的数据平台强调对SoR、SoI、SoE功能实现全局管理和规范化，提升数字化转型的效率和能力，可以称为数据平台3.0。