155 lines
16 KiB
Markdown
155 lines
16 KiB
Markdown
# 01 | 前因后果：为什么说数据中台是大数据的下一站？
|
||
|
||
你好，我是郭忆。
|
||
|
||
“数据中台”无疑是今年大数据圈最火的词，如果你关注数据相关的行业会议，但凡有数据中台相关的主题，人员都会爆满。去年5月，我作为演讲嘉宾参加了由ITPUB主办的中国数据库大会，一个100人的“数据中台”场次，最后涌进来200多人，前排地下、走廊、过道到处都挤满了人，还有很多人因为挤不进来在外面看直播，数据中台的火爆程度可见一斑。
|
||
|
||
除了支撑集团的大数据建设，我的团队还提供To B的企业服务，因此我也有机会接触到一些正在做数字化转型的传统企业。从2018年末开始，原先市场上各种关于大数据平台的招标突然不见了，取而代之的是数据中台项目，建设数据中台俨然成为传统企业数字化转型的首选，甚至不少大数据领域的专家都认为，数据中台是大数据的下一站。
|
||
|
||
那么为什么数据中台被认为是大数据的下一站呢？它与你之前遇到的数据仓库、数据湖、大数据平台又有什么区别？
|
||
|
||
今天这节课，我想带着这个问题，**与你深入大数据的发展历史，先从数据仓库的出现讲起，途径数据湖，再到大数据平台，**因为这样，你才能理解大数据发展的每个阶段遇到的问题，从而深入理解数据中台在大数据发展中的历史定位。
|
||
|
||
## 启蒙时代：数据仓库的出现
|
||
|
||
商业智能（Business Intelligence）诞生在上个世纪90年代，它是将企业已有的数据转化为知识，帮助企业做出经营分析决策。比如在零售行业的门店管理中，如何使得单个门店的利润最大化，我们就需要分析每个商品的销售数据和库存信息，为每个商品制定合理的销售采购计划，有的商品存在滞销，应该降价促销，有的商品比较畅销，需要根据对未来销售数据的预测，进行提前采购，这些都离不开大量的数据分析。
|
||
|
||
而数据分析需要聚合多个业务系统的数据，比如需要集成交易系统的数据，需要集成仓储系统的数据等等，同时需要保存历史数据，进行大数据量的范围查询。传统数据库面向单一业务系统，主要实现的是面向事务的增删改查，已经不能满足数据分析的场景，**这促使数据仓库概念的出现。**
|
||
|
||
在1991年出版的《Building the Data Warehouse》中，数据仓库之父比尔·恩门（Bill Inmon）首次给出了数据仓库的完整定义，他认为：
|
||
|
||
> 数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。
|
||
|
||
为了帮你理解数据仓库的四要素，我举个电商的例子。
|
||
|
||
在电商场景中，有一个数据库专门存放订单的数据，另外一个数据库存放会员相关的数据。构建数据仓库，首先要把不同业务系统的数据同步到一个统一的数据仓库中，然后按照主题域方式组织数据。
|
||
|
||
|
||
|
||
主题域是业务过程的一个高层次的抽象，像商品、交易、用户、流量都能作为一个主题域，**你可以把它理解为数据仓库的一个目录。**数据仓库中的数据一般是按照时间进行分区存放，一般会保留5年以上，每个时间分区内的数据都是追加写的方式，对于某条记录是不可更新的。
|
||
|
||
除了这个概念之外，我还要提一下他和金博尔（Kimball） 共同开创的数仓建模的设计方法，这个方法对于后来基于数据湖的现代数据仓库的设计有重要的意义，所以你有必要了解。
|
||
|
||
恩门提出的建模方法自顶向下（这里的顶是指数据的来源，在传统数据仓库中，就是各个业务数据库），基于业务中各个实体以及实体之间的关系，构建数据仓库。
|
||
|
||
比如，在一个最简单的买家购买商品的场景中，按照恩门建模的思维模式，首先你要理清这个业务过程中涉及哪些实体。买家、商品是一个实体，买家购买商品是一个关系。所以，模型设计应该有买家表，商品表，和买家商品交易表三个模型。
|
||
|
||
|
||
|
||
|
||
|
||
金博尔建模与恩门正好相反，是一种自底向上的模型设计方法，从数据分析的需求出发，拆分维度和事实。那么用户、商品就是维度，库存、用户账户余额是事实。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
这两种方法各有优劣，恩门建模因为是从数据源开始构建，构建成本比较高，适用于应用场景比较固定的业务，比如金融领域，冗余数据少是它的优势。金博尔建模由于是从分析场景出发，适用于变化速度比较快的业务，比如互联网业务。**由于现在的业务变化都比较快，所以我更推荐金博尔的建模设计方法。**
|
||
|
||
传统数据仓库，第一次明确了数据分析的应用场景应该用单独的解决方案去实现，不再依赖于业务的数据库。在模型设计上，提出了数据仓库模型设计的方法论，为后来数据分析的大规模应用奠定了基础。但是进入互联网时代后，传统数据仓库逐渐没落，一场由互联网巨头发起的技术革命催生了大数据时代的到来。
|
||
|
||
## 技术革命：从Hadoop 到数据湖
|
||
|
||
进入互联网时代，有两个最重要的变化。
|
||
|
||
* 一个是数据规模前所未有，一个成功的互联网产品日活可以过亿，就像你熟知的头条、抖音、快手、网易云音乐，每天产生几千亿的用户行为。传统数据仓库难于扩展，根本无法承载如此规模的海量数据。
|
||
|
||
* 另一个是数据类型变得异构化，互联网时代的数据除了来自业务数据库的结构化数据，还有来自App、Web的前端埋点数据，或者业务服务器的后端埋点日志，这些数据一般都是半结构化，甚至无结构的。传统数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须事先定义好，数据必须按照模型设计存储。
|
||
|
||
|
||
所以，数据规模和数据类型的限制，导致传统数据仓库无法支撑互联网时代的商业智能。
|
||
|
||
而以谷歌和亚马逊为代表的互联网巨头率先开始了相关探索。从2003年开始，互联网巨头谷歌先后发表了3篇论文：《The Google File System》《MapReduce：Simplified Data Processing on Large Clusters》《Bigtable：A Distributed Storage System for Structed Data》，这三篇论文奠定了现代大数据的技术基础。它们提出了一种新的，面向数据分析的海量异构数据的统一计算、存储的方法。关于这三篇论文，在这里我们不做深入的解读，如果对实现技术感兴趣的话，也可以查看我在文末提供的链接。
|
||
|
||
但2005年Hadoop出现的时候，大数据技术才开始普及。你可以把Hadoop 认为是前面三篇论文的一个开源实现，我认为Hadoop 相比传统数据仓库主要有两个优势：
|
||
|
||
1. 完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的处理要求；
|
||
|
||
2. 弱化数据格式，数据被集成到Hadoop之后，可以不保留任何数据格式，数据模型与数据存储分离，数据在被使用的时候，可以按照不同的模型读取，满足异构数据灵活分析的需求。
|
||
|
||
|
||
随着Hadoop 技术日趋成熟，2010年，Pentaho 创始人兼CTO James Dixon在纽约Hadoop World 大会上提出了数据湖的概念，他提到：
|
||
|
||
> 数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。
|
||
|
||
数据湖概念的提出，我认为是Hadoop从开源技术走向商业化成熟的标志。企业可以基于Hadoop 构建数据湖，将数据作为一种企业核心资产。
|
||
|
||
数据湖拉开了Hadoop 商用化的大幕，但是一个商用的Hadoop 包含20多种计算引擎， 数据研发涉及流程非常多，技术门槛限制了Hadoop的商用化进程。那么如何让数据的加工像工厂一样，直接在设备流水线上完成呢？
|
||
|
||
## 数据工厂时代：大数据平台兴起
|
||
|
||
对于一个数据开发，在完成一项需求时，常见的一个流程是首先要把数据导入到大数据平台中，然后按照需求进行数据开发。开发完成以后要进行数据验证比对，确认是否符合预期。接下来是把数据发布上线，提交调度。最后是日常的任务运维，确保任务每日能够正常产出数据。
|
||
|
||
|
||
|
||
如此繁杂的一个工作流程，如果没有一个高效的平台作为支撑，就跟写代码没有一个好用的IDE， 用文本编辑器写代码一样，别人完成十个需求，你可能连一个需求都完成不了，效率异常低下，根本无法大规模的应用。
|
||
|
||
提出大数据平台的概念，就是为了提高数据研发的效率，降低数据研发的门槛，让数据能够在一个设备流水线上快速地完成加工。
|
||
|
||
> 大数据平台是面向数据研发场景的，覆盖数据研发的完整链路的数据工作台
|
||
|
||
|
||
|
||
大数据平台按照使用场景，分为数据集成、数据开发、数据测试……任务运维，大数据平台的使用对象是数据开发。大数据平台的底层是以Hadoop为代表的基础设施，分为计算、资源调度和存储。
|
||
|
||
Hive、Spark、Flink、Impala 提供了大数据计算引擎：
|
||
|
||
* Hive、Spark 主要解决离线数据清洗、加工的场景，目前，Spark用得越来越多，性能要比Hive 高不少；
|
||
* Flink 主要是解决实时计算的场景；
|
||
* Impala 主要是解决交互式查询的场景。
|
||
|
||
这些计算引擎统一运行在一个称为Yarn的资源调度管理框架内，由Yarn来分配计算资源。目前最新的研究方向中也有基于Kubernetes实现资源调度的，例如在最新的Spark版本（2.4.4）中，Spark已经能够运行在Kubernetes管理的集群上，这样的好处是可以实现在线和离线的资源混合部署，节省机器成本。
|
||
|
||
数据存储在HDFS、Kudu和HBase 系统内。HDFS 不可更新，主要存全量数据，HBase提供了一个可更新的KV，主要存一些维度表，Kudu 提供了实时更新的能力，一般用在实时数仓的构建场景中。
|
||
|
||
大数据平台像一条设备流水线，经过大数据平台的加工，原始数据变成了指标，出现在各个报表或者数据产品中。随着数据需求的快速增长，报表、指标、数据模型越来越多，找不到数据，数据不好用，数据需求响应速度慢等问题日益尖锐，成为阻塞数据产生价值的绊脚石。
|
||
|
||
## 数据价值时代：数据中台崛起
|
||
|
||
时间到了2016年前后，互联网高速发展，背后对数据的需求越来越多，数据的应用场景也越来越多，有大量的数据产品进入到了我们运营的日常工作，成为运营工作中不可或缺的一部分。在电商业务中，有供应链系统，供应链系统会根据各个商品的毛利、库存、销售数据以及商品的舆情，产生商品的补货决策，然后推送给采购系统。
|
||
|
||
大规模数据的应用，也逐渐暴露出现一些问题。
|
||
|
||
业务发展前期，为了快速实现业务的需求，烟囱式的开发导致企业不同业务线，甚至相同业务线的不同应用之间，数据都是割裂的。两个数据应用的相同指标，展示的结果不一致，导致运营对数据的信任度下降。如果你是运营，当你想看一下商品的销售额，发现两个报表上，都叫销售额的指标出现了两个值，你的感受如何? 你第一反应肯定是数据算错了，你不敢继续使用这个数据了。
|
||
|
||
数据割裂的另外一个问题，就是大量的重复计算、开发，导致的研发效率的浪费，计算、存储资源的浪费，大数据的应用成本越来越高。
|
||
|
||
* 如果你是运营，当你想要一个数据的时候，开发告诉你至少需要一周，你肯定想是不是太慢了，能不能再快一点儿？
|
||
|
||
* 如果你是数据开发，当面对大量的需求的时候，你肯定是在抱怨，需求太多，人太少，活干不完。
|
||
|
||
* 如果你是一个企业的老板，当你看到每个月的账单成指数级增长的时候，你肯定觉得这也太贵了，能不能再省一点，要不吃不消了。
|
||
|
||
|
||
这些问题的根源在于，数据无法共享。2016年，阿里巴巴率先提出了“数据中台”的口号。**数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。**之前，数据是要啥没啥，中间数据难于共享，无法积累。现在建设数据中台之后，要啥有啥，数据应用的研发速度不再受限于数据开发的速度，一夜之间，我们就可以根据场景，孵化出很多数据应用，这些应用让数据产生价值。
|
||
|
||
## 课堂总结
|
||
|
||
现在，回到我们本节课的题目：为什么说数据中台是大数据的下一站？ 在我看来，有这样几个原因：
|
||
|
||
1. 数据中台构建于数据湖之上，具备数据湖异构数据统一计算、存储的能力，同时让数据湖中杂乱的数据通过规范化的方式管理起来。
|
||
|
||
2. 数据中台需要依赖大数据平台，大数据平台完成了数据研发的全流程覆盖，数据中台增加了数据治理和数据服务化的内容。
|
||
|
||
3. 数据中台借鉴了传统数据仓库面向主题域的数据组织模式，基于维度建模的理论，构建统一的数据公共层。
|
||
|
||
|
||
总的来说，数据中台吸收了传统数据仓库、数据湖、大数据平台的优势，同时又解决了数据共享的难题，通过数据应用，实现数据价值的落地。
|
||
|
||
在文章的最后，为了帮你把数据中台诞生的大事件串联起来，我做了一张时间图，在这个时间线里，你可以很清晰地看到数据中台诞生的前期、中期，和后期的大事件，这样可以帮你更清晰的掌握数据中台背景。
|
||
|
||
|
||
|
||
## 思考时间
|
||
|
||
在这节课快要结束时，我给你留一个发散性的思考题：如果说数据中台是大数据的下一站，那数据中台的下一站是什么？这个话题很有趣，欢迎你大开“脑洞”，在留言区与我分享。
|
||
|
||
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。
|
||
|
||
**论文链接：**
|
||
|
||
* [《The Google File System》](https://dl.acm.org/doi/abs/10.1145/945445.945450)
|
||
* [《MapReduce：Simplified Data Processing on Large Clusters》](https://dl.acm.org/doi/abs/10.1145/1327452.1327492)
|
||
* [《Bigtable：A Distributed Storage System for Structed Data》](https://dl.acm.org/doi/abs/10.1145/1365815.1365816)
|
||
|