xinyin025/CategoryResourceRepost
1
0
Fork 0
mirror of https://github.com/cheetahlou/CategoryResourceRepost.git synced 2025-11-16 14:13:46 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

del

Browse Source
This commit is contained in:
louzefeng
2024-07-09 18:38:56 +00:00
parent 8bafaef34d
commit bf99793fd0
6071 changed files with 1017944 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

170
极客时间专栏/geek/数据中台实战课/原理篇/01 | 前因后果：为什么说数据中台是大数据的下一站？.md Normal file
View File

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

144
极客时间专栏/geek/数据中台实战课/原理篇/02 | 关键抉择： 到底什么样的企业应该建数据中台？.md Normal file
View File

@@ -0,0 +1,144 @@
<audio id="audio" title="02 | 关键抉择： 到底什么样的企业应该建数据中台？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c7/51/c77f0811d25528908ace344220dd8151.mp3"></audio>
你好，我是郭忆。
在上一节课中，我和你一起回顾了大数据的发展历史，从历史脉络中，我们看到了数据中台凸显的价值，并得出数据中台是大数据下一站的结论。
既然数据中台受到了前所未有的关注，价值如此之大，是不是所有的企业都适合建设数据中台呢？到底什么样的企业应该建数据中台？带着这样的疑问，我们正式进入今天的课程。
我先跟你分享一下，2018年我们在建数据中台前面临的窘境，通过了解我们建数据中台的背景，你也可以对照着看一下自己所在的企业是否存在这样的问题，从而针对“是否需要构建一个数据中台”这个问题形成自己的看法。
## 建设中台前，我们面临的挑战
对于绝大多数互联网企业来说，2018年绝对是煎熬的一年，因为面临线上流量枯竭，业绩增长乏力，企业成本高筑， 利润飞速下滑的风险。 原先粗放的企业管理模式和经营模式（比如我们在采购商品的时候，凭借经验去做出采购哪个商品的决策）已经没办法继续支撑企业的高速增长，越来越多的企业开始提数字化转型，强调数据是企业增长的新动力，它应该深入企业经营的各个环节。
数据需求的爆发式增长，促进了数据产品的蓬勃发展，在每个业务过程中，都有大量的数据产品辅助运营完成日常工作。例如，在电商的场景中，用户运营、商品运营、市场运营……每个场景下，都有很多的数据产品，每天有大量的运营基于这些产品完成经营决策。
比如在供应链决策协同系统中，我们有一个智能补货的功能，会根据商品的库存、历史销售数据以及商品的舆情，智能计算商品的最佳采购计划，推送给运营审核，然后完成采购下单。
<img src="https://static001.geekbang.org/resource/image/8a/78/8a5a57b32c9176a33ea138d853892d78.jpg" alt="">
**大量数据产品的出现，在不断提高企业运营效率的同时，也暴露出很多尖锐的问题，在我看来，主要有五点。**
1.指标口径不一致。 两个数据产品一个包含税，一个不包含税，它们相同的一个指标名称都是销售额，结果却不一样。运营面对这些指标的时候，不知道指标的业务口径，很难去使用这些数据。
2.数据重复建设，需求响应时间长。随着需求的增长，运营和分析师不断抱怨需求的交付时间拉长，面对快速变化的业务，需求响应时间已经无法满足业务对数据的敏捷研发要求。
3.取数效率低。 面对数十万张表，我们的运营和分析师找数据、准确地理解数据非常困难，想找到一个想要的数据，确认这个数据和自己的需求匹配，他们往往需要花费三天以上的时间，对新人来说，这个时间会更长。
除了查找数据效率低，从系统中取数分析对于非技术出身的分析师和运营来说也是一个难题，这就导致大部分的取数工作还是依赖数据开发来完成。数据开发大部分的时间都被临时取数的需求占据，根本无法专注在数仓模型的构建和集市层数据的建设，最终形成了一个恶性循环，一方面是数据不完善，另一方面是数据开发忙于各种临时取数需求。
4.数据质量差。数据经常因为BUG导致计算结果错误，最终导致错误的商业决策。**分享一个我们踩过的坑，**在大促期间，某类商品搜索转化率增长，于是我们给这个商品分配了更大的流量，可转化率增长的原因是数据计算错误，所以这部分流量也就浪费了，如果分配给其他的商品的话，可以多赚200W的营收。
5.数据成本线性增长。数据成本随着需求的增长而线性增长，2017年的时候，我们一个业务的大数据资源在4000Core，但是2018就已经到达9000Core水平，如果折算成钱的话，已经多了500多万的机器成本。
相信你能在我“惨痛”的经历中，找到自己的影子，这些事儿的确很头疼，好在后来，我们用数据中台解决了这些问题。
## 为什么数据中台可以解决这些问题？
要想回答这个问题，你需要了解上述问题背后的原因。
指标口径不一致，可能原因包括三种：**业务口径不一致、计算逻辑不一致、数据来源不一致。**
如果是业务口径不一致，那就要明确区分两个指标不能使用相同的标识，像上面的例子，含税和不含税的两个指标， 不能同时叫销售额。
业务口径的描述往往是一段话，但是对于很多指标，涉及的计算逻辑非常复杂，仅仅一段话是描述不清楚的，此时，两个相同业务口径的指标，恰巧又分别是由两个数据开发去实现的，这样就有可能造成计算逻辑不一致。比如，有一个指标叫做排关单（排关单：把关单的排除；关单：关闭订单）的当天交易额这个指标，A认为关单的定义是未发货前关闭的订单，B认为关单是当天关闭的订单，大家对业务口径理解不一致，这样实现的计算结果也就会不一致。
最后，还可能是两个指标的数据来源不一样，比如一个来自实时数据，一个是来自离线的数据，即使加工逻辑一样，最终结果也可能不相同。
**综合看来，要实现一致，就务必确保对同一个指标，只有一个业务口径，只加工一次，数据来源必须相同。**
而数据需求响应慢在于烟囱式的开发模式，导致了大量重复逻辑代码的研发，比如同一份原始数据，两个任务都对原始数据进行清洗。如果只有一个任务清洗，产出一张明细表，另外一个任务直接引用这张表，就可以节省一个研发的清洗逻辑的开发。
**所以，要解决数据需求响应慢，就必须解决数据复用的问题，要确保相同数据只加工一次，实现数据的共享。**
取数效率低，一方面原因是找不到数据，另一方面原因可能是取不到数据。要解决找不到数据的问题，就必须要构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据。而非技术人员并不适合用写SQL的方式来取数据，所以要解决取不到数据的问题，就要为他们提供可视化的查询平台，通过勾选一些参数，才更容易使用。
数据质量差的背后其实是数据问题很难被发现。我们经常是等到使用数据的人反馈投诉，才知道数据有问题。而数据的加工链路一般非常长，在我们的业务中，一个指标上游的所有链路加起来有100多个节点，这是很正常的事情。等到运营投诉再知道数据有问题就太迟了，因为要逐个去排查到底哪个任务有问题，然后再重跑这个任务以及所有下游链路上的每个任务，这样往往需要花费半天到一天的时间，最终导致故障恢复的效率很低，时间很长。
**所以，要解决数据质量差，就要及时发现然后快速恢复数据问题。**
最后一个是大数据的成本问题，它其实与需求响应慢背后的数据重复建设有关，因为重复开发任务的话，这些任务上线肯定会花费双倍的资源。如果我们可以节省一个任务的资源消耗，满足两个数据需求，就可以控制不必要的资源消耗。所以，成本问题背后也是数据重复建设的问题。
正当我们为这些问题苦恼的时候，数据中台的理念给了我们全新的启迪，那么数据中台到底是怎么一回事儿呢？**在我看来，数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用。**
数据中台消除了冗余数据，构建了企业级数据资产，提高了数据的共享能力，这与我们需要的能力不谋而合，所以很快，我们开启了数据中台的建设。
## 数据中台是如何解决这些问题的？
指标是数据加工的结果，要确保数据需求高质量的交付，首先是要管好指标。
原先指标的管理非常分散，没有全局统一的管理，在数据中台中，必须要有一个团队统一负责指标口径的管控。
其次，要实现指标体系化的管理，提高指标管理的效率。在指标系统中，我们会明确每个指标的业务口径，数据来源和计算逻辑，同时会按照类似数仓主题域的方式进行管理。
最后，要确保所有的数据产品、报表都引用指标系统的口径定义。当运营把鼠标Hover到某个指标上时，就可以浮现出该指标的口径定义。
通过对全局指标的梳理，我们实现了100%的数据产品的指标口径统一，消除了数据产品中，指标口径二义性的问题，同时还提供了方便分析师、运营查询的指标管理系统。
**那么数据中台是怎么实现所有数据只加工一次的呢？**简单来说，就是对于数仓数据，我们要求相同粒度的度量或者指标只加工一次，构建全局一致的公共维表。要实现上述目标，需要两个工具产品：
- 一个是数仓设计中心，在模型设计阶段，强制相同聚合粒度的模型，度量不能重复。
- 另外一个是数据地图，方便数据开发能够快速地理解一张表的准确含义。
这样就解决了数据重复加工导致研发效率瓶颈的问题，现在我们把需求的平均交付时间从一周减少到2～3天，大幅提高了数据产能，得到了分析师和运营的认可。
**数据中台通过服务化的方式，提高了数据应用接入和管理的效率。**原先数仓提供给应用的访问方式是直接提供表，应用开发自己把数据导出到一个查询引擎上，然后去访问查询引擎。在数据中台中，数仓的数据是通过API接口的方式提供给数据应用，数据应用不用关心底层不同的查询引擎访问方式的差异。
**对于非技术人员，数据中台提供了可视化的取数平台，**你只需要选取指标、通过获取指标系统中每个指标的可分析维度，然后勾选，添加筛选过滤条件，点击查询，就可以获取数据。
同时，数据中台构建了企业数据地图，你可以很方便地检索有哪些数据，它们在哪些表中，又关联了哪些指标和维度。通过自助取数平台和数据地图，公司的非技术人员开始自助完成取数，相比通过提需求给技术人员的方式，取数效率提高了300%。
<img src="https://static001.geekbang.org/resource/image/36/03/36cb4c806b39fd38691133df5cbf2d03.jpg" alt="" title="EasyFetch 网易自助取数界面">
**数据中台由于数据只能加工一次，强调数据的复用性，这就对数据的质量提出了更高的要求。**而我们实现了全链路的数据质量稽核监控，对一个指标的产出上游链路中涉及的每个表，都实现了数据一致性、完整性、正确性和及时性的监控，确保在第一时间发现、恢复、通知数据问题。
原先，当技术人员问我们“今天数据有没有问题？” 的时候，我们很难回答，现在我们可以很自信地回答，数据对不对，哪些数据不对，什么时候能恢复了。我个人认为这个能力对我们最终达成99.8% 数据SLA至关重要。
**最后一个是成本问题。**我们在构建数据中台的时候，研发了一个数据成本治理系统，从应用维度、表维度、任务的维度、文件的维度进行全面的治理。 从应用的维度，如果一个报表30天内没有访问，这个报表的产出价值就是低的，然后结合这个报表产出的所有上游表以及上游表的产出任务，我们可以计算加工这张表的成本，有了价值和成本，我们就能计算ROI，根据ROI就可以实现将低价值的报表下线的功能。通过综合治理，最终我们在一个业务中节省了超过20%的成本，约900W。
通过数据中台，最终我们成功解决了面临的问题，大幅提高了数据研发的效率、质量，降低了数据的成本。那么现在让我们回到课程开始时的问题，到底什么样的企业适合建数据中台？ 是不是所有企业都要构建一个数据中台？
## 什么样的企业适合建数据中台？
不可否认，数据中台的构建需要非常大的投入：一方面数据中台的建设离不开系统支撑，研发系统需要投入大量的人力，而这些系统是否能够匹配中台建设的需求，还需要持续打磨。另外一方面，面对大量的数据需求，要花费额外的人力去做数据模型的重构，也需要下定决心。
所以数据中台的建设，需要结合企业的现状，根据需要进行选择。我认为企业在选择数据中台的时候，应该考虑这样几个因素。
<li>
企业是否有大量的数据应用场景： 数据中台本身并不能直接产生业务价值，数据中台的本质是支撑快速地孵化数据应用。所以当你的企业有较多数据应用的场景时（一般有3个以上就可以考虑），就像我在课程开始时提到电商中有各种各样的数据应用场景，此时你要考虑构建一个数据中台。
</li>
<li>
经过了快速的信息化建设，企业存在较多的业务数据的孤岛，需要整合各个业务系统的数据，进行关联的分析，此时，你需要构建一个数据中台。比如在我们做电商的初期，仓储、供应链、市场运营都是独立的数据仓库，当时数据分析的时候，往往跨了很多数据系统，为了消除这些数据孤岛，就必须要构建一个数据中台。
</li>
<li>
当你的团队正在面临效率、质量和成本的苦恼时，面对大量的开发，却不知道如何提高效能，数据经常出问题而束手无策，老板还要求你控制数据的成本，这个时候，数据中台可以帮助你。
</li>
<li>
当你所在的企业面临经营困难，需要通过数据实现精益运营，提高企业的运营效率的时候，你需要构建一个数据中台，同时结合可视化的BI 数据产品，实现数据从应用到中台的完整构建，在我的接触中，这种类型往往出现在传统企业中。
</li>
<li>
企业规模也是必须要考虑的一个因素，数据中台因为投入大，收益偏长线，所以更适合业务相对稳定的大公司，并不适合初创型的小公司。
</li>
如果你的公司有这样几个特征，不要怀疑，把数据中台提上日程吧。
## 课堂总结
本节课，我结合自己的经历，带你了解了企业数据在日常使用过程中面临的一些难题，通过分析，我们发现，数据中台恰好可以对症下药，解决这些问题。在这个过程中，我想强调这样几个重点：
- 效率、质量和成本是决定数据能否支撑好业务的关键，构建数据中台的目标就是要实现高效率、高质量、低成本。
- 数据只加工一次是建设数据中台的核心，本质上是要实现公共计算逻辑的下沉和复用。
- 如果你的企业拥有3个以上的数据应用场景，数据产品还在不断研发和更新，你必须要认真考虑建设数据中台。
在最后，我想再次强调一下，建设数据中台不能盲目跟风，因为它不一定适合你，我在生活中见到了很多不符合上述特征，却想要建设数据中台的公司，比如一些初创型的小公司，初期投入了大量人力成本建设数据中台，因为业务变化快，缺少深入数据应用场景，结果却是虎头蛇尾，价值无法落地。所以，你最正确的做法是仔细想想我提出的上述5点要素。
因为这节课信息比较密集，我用一个脑图帮你梳理一下知识体系，便于你理解：
<img src="https://static001.geekbang.org/resource/image/1a/9c/1a03abc87fb3bd691a03d2a56c974e9c.jpg" alt="">
## 思考时间
我同样给留给你一道思考题，一个企业是不是只能建设一个数据中台？
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。

157
极客时间专栏/geek/数据中台实战课/原理篇/03 | 数据中台建设三板斧：方法论、组织和技术.md Normal file
View File

@@ -0,0 +1,157 @@
<audio id="audio" title="03 | 数据中台建设三板斧：方法论、组织和技术" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/af/73/af73d87af42e50c1632f23545cc6bf73.mp3"></audio>
你好，我是郭忆。
在上一讲中，我带你了解了什么样的企业适合建数据中台，可能有的同学会说：你可真的戳中我了，我们现在就面临这个问题，可是知道要转型，要建设数据中台，却不知道要咋做，怎么办呢？
现在有很多讲“如何建设数据中台”的文章，大家的观点各不相同：
- 有的观点说，数据中台是一种数据建设的方法论，按照数据中台设计方法和规范实施就可以建成数据中台了；
- 也有观点认为，数据中台的背后是数据部门组织架构的变更，把原先分散的组织架构形成一个统一的中台部门，就建成了数据中台；
- 除此之外，你可能还听到过一些大数据公司说，他们可以卖支撑数据中台建设的产品技术。
那数据中台到底如何建设呢？咱们先不着急回答这个问题，而是看一个例子。
你肯定见过盖房子，盖房子之前，是不是先得有设计图纸，知道如何去盖这个房子？然后还必须要有一个好用的工具（比如水泥搅拌机、钢筋切割机）帮你盖好这个房子。当然了，盖房子离不开一个靠谱的施工队伍，这里面涉及很多角色（泥瓦工、木工、水电工等等），这些人必须高效协作，最终才能盖出一个好的房子。
如果我们把建数据中台比作是盖房子，那么设计图纸就是数据中台建设的方法论；工具是数据中台的支撑技术；施工队伍就是数据中台的组织架构。这三者缺一不可。
这一讲我就以全局的视角，让你从宏观上了解如何建设一个企业级的数据中台。
## 数据中台建设方法论
早在2016年，阿里巴巴就提出了数据中台建设的核心方法论：OneData和OneService。经过这么多年，很多公司都进行了实践，但你很难找出一个准确的定义去描述这些方法论，而我结合自己在网易数据中台建设的经验，对方法论进行了系统化的定义，你可以借鉴参考一下。
### OneData
用一句话定义OneData的话，就是所有数据只加工一次。 这个概念具体是啥意思呢？我们来看一个例子。
<img src="https://static001.geekbang.org/resource/image/11/0d/111bdb91bcc9f36ea3da013a3bca610d.jpg" alt="">
电商业务建设数据中台之前，每个部门内部都会有一些小的数仓去完成本部门的数据分析需求。
有一天，供应链团队接到一个数据需求，那就是计算“商品库存”指标，供应链的运营需要根据每个商品的库存制订商品采购计划，部门的数据开发从业务系统同步数据，进行数据清洗、聚合、深度加工，最终，产出这个指标花了1周的时间。
而恰逢全年最重要的大促节日，市场部门也需要根据每个商品的库存，制订商品的促销计划。该数据开发接到这个紧急的需求（与供应链团队类似）从需求开发到上线，也足足花费了1周的时间。同部门的运营会抱怨说，为什么数据需求开发这么慢，根本无法满足大促期间高频的市场运营决策。而对公司而言，等待1周意味着遭受巨大损失，该促销的商品没有促销，不该促销的却低价卖了。
如果你是这个公司的老板， 肯定会问，既然供应链团队已经计算出来了商品库存的数据，为什么市场部门不直接用，还要从头再计算一遍呢？这个看似很傻的行为，却处处出现在我们日常的数据建设中。
而数据中台就是要在整个电商业务形成一个公共数据层，消灭这些跨部门的小数仓，实现数据的复用，所以强调数据只加工一次，不会因为不同的应用场景，不同的部门数据重复加工。
那具体来说，如何去做才能实现数据只加工一次呢？有这样五点：
<img src="https://static001.geekbang.org/resource/image/39/08/39c72956708fe40c781ce0e03dfb7508.jpg" alt="">
试想一下，现在你构建了数据中台，但存在几万张表，同时又有几十个数据开发维护这些表，如何来确保这些表的管理效率？ **我建议你选择划主题域。**
我们可以将这几万张表划到不同的主题域中，比如在电商业务中，商品、交易、流量、用户、售后、配送、供应链都可以作为主题域。好的主题域划分，是相对稳定，尽可能地覆盖绝大多数的表。
**除此之外，还要对表的命名进行规范化统一，** 表的名称中最好能够携带表的主题域、业务过程、分层以及分区信息。比如，对于仓储域下的一张入库明细表，规则命名可以这样：
<img src="https://static001.geekbang.org/resource/image/25/d0/251a20233507361d8795277a4ef8edd0.jpg" alt="">
接着你还必须构建全局的指标字典，确保所有表中相同指标的口径必须一致（这部分内容我会在06讲细说）。
<img src="https://static001.geekbang.org/resource/image/2c/77/2ca64f179ce1c756d520fb38881afd77.jpg" alt="">
另外，为了实现模型的复用，数据中台适合采用分层的设计方式，常见的分层包括：ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS/DM 应用数据层/数据集市层。**最后，数据中台的数据必须尽可能的覆盖所有的业务过程，**数据中台中每一层的数据也要尽可能完善，让数据使用者尽可能的使用汇总后的数据。
OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。
### OneService
OneService，数据即服务，强调数据中台中的数据应该是通过API接口的方式被访问。
这里我想提个问题：为什么数据一定要通过API 接口的方式被访问，不通过API 接口，直接提供数据表给用户又存在哪些问题呢？
如果你是数据应用开发，当你要开发一个数据产品时，首先要把数据导出到不同的查询引擎上：
- 数据量小的使用MySQL；
- 大的可能用到HBase；
- 需要多维分析的可能需要Greenplum；
- 实时性要求高的需要用到Redis；
总的来说，不同的查询引擎，应用开发需要定制不同的访问接口。
如果你是一个数据开发，当某个任务无法按时产出，发生异常时，想要了解这个表可能会影响到下游的哪些应用或者报表，但是却发现单纯依赖表与表的血缘无法触及应用，根本无法知道最后的这些表被哪些应用访问。与此同时，当你想下线一张表时，因为不知道谁访问了这张表，无法实施，最终造成了“上线容易，下线难”的窘境。
而API 接口一方面对应用开发屏蔽了底层数据存储，使用统一标准的API接口查询数据，提高了数据接入的速度。另一方面，对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。
那如何来实现数据服务化呢？
<img src="https://static001.geekbang.org/resource/image/83/72/83c1364dc7c836a31122a45ebea09672.jpg" alt="">
**屏蔽异构数据源：**数据服务必须要能够支撑类型丰富的查询引擎，满足不同场景下数据的查询需求，常见的有MySQL、HBase、Greenplum、Redis、Elasticsearch等。
**数据网关：**要实现包括权限、监控、流控、日志在内的一系列管控能力，哪个应用的哪个页面访问了哪个模型，要做到实时跟踪，如果有一些模型长时间没有被访问，应该予以下线。使用数据的每个应用都应该通过accesskey和secretkey实现身份认证和接口权限的管理。另外，访问日志可以方便在访问出现问题时，加快排查速度。
**逻辑模型：**从用户的视角出发，屏蔽底层的模型设计的实现，面向用户提供逻辑模型。什么是逻辑模型呢？熟悉数据库的同学应该知道，数据库中有一个视图的概念，视图本身并没有真实的数据，一个视图可以关联一张或者多张表，每次在查询的时候，动态地将不同表的查询结果聚合成视图的查询结果。逻辑模型可以类比视图，它可以帮助应用开发者屏蔽底层的数据物理实现，实现相同粒度的数据构造一个逻辑模型，简化了数据接入的复杂度。
**性能和稳定性：**由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展。
OneService 体系的目标是提高数据的共享能力，让数据可以被用得好，用得爽。
## 数据中台支撑技术
讲完方法论，我们接着要来讲数据中台的支撑技术，因为一个好用的工具，可以让你的数据中台建设事半功倍。
<img src="https://static001.geekbang.org/resource/image/8d/02/8da01dbcf1f318fcf90d3c26e3f1b602.jpg" alt="">
这个图完整地描述了数据中台支撑技术体系，它的底层是以Hadoop为代表的大数据计算、存储基础设施，提供了大数据运行所必须的计算、存储资源。
以HDFS为代表的分布式文件系统，以Yarn/Kubernates为代表的资源调度系统，以Hive、Spark、Fink为代表的分布式计算引擎，都属于基础设施范畴。如果把数据中台比作是一个数据工厂，那可以把它们比作是这个工厂的水、电。
在Hadoop之上，浅绿色的部分是原有大数据平台范畴内的工具产品，覆盖了从数据集成、数据开发、数据测试到任务运维的整套工具链产品。同时还包括基础的监控运维系统、权限访问控制系统和项目用户的管理系统。由于涉及多人协作，所以还有一个流程协作与通知中心。
灰色的部分，是数据中台的核心组成部分：数据治理模块。它对应的方法论就是OneData 体系。以元数据中心为基础，在统一了企业所有数据源的元数据基础上，提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的5个产品，分别对应的就是数据发现、模型、质量、成本和指标的治理。
深绿色的部分是数据服务，它是数据中台的门户，对外提供了统一的数据服务，对应的方法论就是OneService。数据服务向下提供了应用和表的访问关系，使数据血缘可以延申到数据应用，向上支撑了各种数据应用和服务，所有的系统通过统一的API接口获取数据。
在数据服务之上，是面向不同场景的数据产品和应用，包括面向非技术人员的自助取数系统；面向数据开发、分析师的自助分析系统；面向敏捷数据分析场景的BI产品；活动直播场景下的大屏系统；以及用户画像相关的标签工厂。
这套产品技术支撑体系，覆盖了数据中台建设的整个过程，配合规范化实施，你就可以搭建出一个数据中台，关于具体的细节我会在实现篇中逐一分析讲解，这里你只需要知道这个框架就可以了。
## 组织架构
我在开篇提到，在网易电商数据中台建设之前，各个部门都会存在一些小的数仓，**那么你有没有想过，为什么会存在这些分散的小数仓？** 归根结底是因为建设这些数仓的人分散在各个业务部门。所以，如果你要建设数据中台，单纯有方法论和支撑技术还不够，还必须要有一个独立于业务部门的中台团队。
数据中台提供的是一个跨业务部门共享的公共数据能力，所以，承担数据中台建设职责的部门一定是一个独立于业务线的部门。这个部门的负责人应该直接向公司的CTO汇报工作，当然这个也要取决于数据中台建设的层次，例如在网易内，有云音乐、严选等多个产品线，数据中台的建设层次是在产品级别的，也就是说，云音乐有一个数据中台，严选有一个数据中台，所以严选的数据中台应该向严选的CTO汇报。
而独立部门的最大风险是与业务脱节，所以我们对数据中台的组织定位是：**懂业务，能够深入业务，扎根业务。**数据中台要管理所有的指标，而每个业务线之间的指标既有差异，也有交叉，要理解指标的口径定义，就必须要了解业务的过程。同时，当我们要制定一些新的指标时，必须要了解各个业务线新的业务目标，指标的本质还是为业务目标服务的。
综合来讲，什么样的组织架构是适合数据中台建设的呢？
<img src="https://static001.geekbang.org/resource/image/4a/6f/4ac92d2291f1f478572372295caf5e6f.jpg" alt="">
- 数据产品部门：负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进，指标口径的定义和维护（有的部门是由分析师管理）。
- 数据平台部门：负责研发支撑数据中台构建的产品，例如指标系统、元数据中心、数据地图等。
- 数据开发团队：负责维护数据中台的公共数据层，满足数据产品制定的数据需求。
- 应用开发团队：负责开发数据应用产品，比如报表系统、电商中的供应链系统、高层看板、经营分析。
而且，中台组织的绩效目标一定是要与业务落地价值绑定的，比如在电商中，我们提供了供应链决策系统，有智能补货的功能，会根据商品的库存，各个地区的历史销售情况，生产加工周期，自动生成补货决策，由人工审核以后，直接推送给采购系统。那我们评估价值时，我们会拿由系统自动生成的采购计划占整体采购计划的比例来衡量数据的应用价值。
最后，数据中台的组织架构改革涉及原有各个部门的利益，所以这个是数据中台构建最难又不得不做的地方，必须要取得高层领导的支持和重视。
## 课堂小结
这节课，我以自己建设数据中台的经历，带领你了解了数据中台建设的三板斧：方法论、支撑技术和组织架构。在课程的最后，我想再强调几个点。
<li>
适合数据中台的组织架构是建设数据中台的第一步，数据中台组织一定是独立的部门，同时要避免与业务脱节，深入业务，要与业务目标绑定。
</li>
<li>
数据中台支撑技术大规模落地，需要有成熟的系统工具作为支撑，同时要注意这些系统工具之间的联动和打通。
</li>
<li>
数据中台的方法论可以借鉴，但是不能完全照搬，每个公司的数据应用水平和当前遇到的问题都不相同，可以针对这些问题，分阶段制定数据中台的建设计划，选择性的应用一些技术，例如当前最主要的问题是数据质量问题，那就应该优先落地数据质量中心，提升质量。
</li>
最后，让我们回到开篇的那个问题，如何建设数据中台？在我看来，方法论、支撑技术和组织架构，对于建设数据中台，三者缺一不可。而且我想再强调一下，数据中台的建设绝对不是为了建中台而建中台，数据中台的建设一定要结合落地场景，可以先从从一些小的场景开始，但是规划一定是要有顶层设计的。关于具体的操作细节，我会在第二部分，用8讲的篇幅来讲给你听。
<img src="https://static001.geekbang.org/resource/image/af/52/afedf9dca0f4366ff3fad9ef2f44b952.jpg" alt="">
## 思考时间
在课程最后，我希望你能够思考一下，哪些数据中台建设的方法论和支撑技术是适合你当前的公司的，如果你们要做数据中台，你所在的组织架构要做哪些变动。
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。

192
极客时间专栏/geek/数据中台实战课/原理篇/特别放送｜史凯：建设数据中台到底有什么用？.md Normal file
View File

@@ -0,0 +1,192 @@
<audio id="audio" title="特别放送｜史凯：建设数据中台到底有什么用？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/93/e2/932d09d5e1ca8adb12750fad8e0135e2.mp3"></audio>
你好，我是史凯，是ThoughtWorks数据智能业务的负责人，你可以叫我凯哥。
我从1999年就开始做程序，在IT行业已经工作20个年头了。最开始，我是在IBM做Websphere 研发，后来历经埃森哲、EMC，一直从事的是企业数字化转型咨询，做过很多系统，比如企业的ERP、ESB系统、SOA架构以及很多领域的业务系统等等。
最近这五年，我专注在数据和人工智能领域，从数据仓库、商业智能、主数据管理到大数据平台的建设，经过很多项目的沉淀和总结，最后我和团队一起总结了精益数据创新的体系。可以说，这么多年我一直战斗在企业信息化的一线。
2019年，我被数据领域权威咨询机构DataIQ评为2019 数据赋能者100人之一，也是腾讯云最有价值专家TVP一员。
很荣幸给郭老师的数据中台课程写加餐文章，我想从我的角度和你聊聊企业为什么要建设数据中台，数据中台对于企业的价值到底是什么。今天的内容我不会在落地细节上进行拓展，主要是从概念和框架的角度，给你提供一个更全面的视角。因为我坚信，做好任何一件事情的前提就是弄清楚为什么。
## 数据中台火了，我们的诉求是什么？
我们先来看看百度搜索指数吧。
<img src="https://static001.geekbang.org/resource/image/03/40/03bbe42c47ea9400400a6b211568e240.jpg" alt="">
这张图告诉我们，数据中台的百度搜索指数最终超越了数字化转型和数据仓库。
嗯，数据中台确实是火了，很多企业已经在落地了，没启动的企业也在考虑中了。很明显，落地数据中台是能够满足企业的一些诉求的，具体是啥呢？
去年我发布了一个数据中台的行业调研，收到了400多份有效的问卷，大家对于数据中台的期望都写了一段话，对这些文字进行分析统计，我得出了这样的词云图。
<img src="https://static001.geekbang.org/resource/image/50/94/50a44de2ee663f982baf5d980dcee394.jpg" alt="">
然后，我对此进行了进一步的分析，发现了大家对于数据中台最多的期待是如下三点：
- 距离业务更近；
- 为企业提供直接的业务价值；
- 提供数据服务而不仅是报表。
为了让你更好地理解企业为什么要建设数据中台，数据中台的概念为什么会受市场和企业的追捧，下面我展开来说一下这几点。
过去企业的数据系统距离用户和业务比较远，这里的远主要包括三点。
第一，数据系统只是技术支撑而不能直接产生业务价值。做一个业务系统，比如，电商平台，可以直接带来收入。但是，传统的数据应用，比如数据仓库，是不能带来直接的价值的。
第二，当业务人员需要在报表里修改一些内容的时候，得到的响应慢，因为业务人员无法自己直接使用数据来产生洞察，需要去找数据团队。
第三，过去在数据方面的投资，大量花费在数据采集、处理和建模部分，而真正利用到业务领域的也不多。
换个角度来看，就是业务开发团队对数据的利用有很大的需求，主要体现在，希望数据中台能够解决企业数据开发的效率问题，协作问题和能力问题。
数据中台给了应用开发人员这样的希望，那就是他们不需要关注具体的取数逻辑，只需要关注客户需求，可以像搭乐高一样方便的组合各种数据中台的数据服务到自己的应用当中去，数据准确并且一致。
**所以，如果用一句话来说数据中台的价值，那就是改变原来企业利用数据的形式。**
过去，数据的利用形式主要是商业智能，说直接一点就是做报表，做报表的目的就是让管理者知道现在的业务在发生什么，为什么会发生这些事情，接下来可能会发生什么，这一切都是提供给我们的管理者去看的，帮助管理者去做出一个业务决策。
随着业务复杂度的提升，一个决策背后的因素是非常多的，一个现象需要多个维度的解读才能够体现业务全貌。于是，管理者需要的报表就越来越多，很多企业会有多个不同业务线的数据仓库，每个数据仓库里都有千张以上的报表，最后就陷入了报表的迷宫。
当我们回头来看这个过程，我们发现，**报表并不是我们所需要的，而数据本身也不是我们所需要的，我们所需要的是一个业务决策，一个业务行为。**
比如，当用户打开电商产品目录的时候，将他最有可能购买的产品展示在第一页，而原来的OLTP、OLAP分离的数据处理流程是做不到的，那么，在业务交易的过程中，也没有办法从历史数据和全域数据的分析结果中获得行动的指引。
总而言之，市场对于数据中台的期待，是提供直接驱动业务流程的数据服务，而不仅是需要经过人去转化和解读的数据可视化报表，原来商业智能时代已经过去，市场和用户期待的是数据智能的时代。
## 建设数据中台的根本目的是什么？
诉求在这里了，建设数据中台似乎能够提供解决方案。但是建设中台不是一蹴而就的事情，也不是一件容易的事，需要在技术上、组织架构上都做对应的调整才可以，落地过程也会面临种种挑战。那企业为啥还要兴师动众地来落地数据中台呢？
结合这些年我自己的经验，我认为这个问题的答案就是：**数据中台的愿景是打造数据驱动的智能企业。**
<img src="https://static001.geekbang.org/resource/image/1a/3c/1aeccc8597c2bd05d49e97343d193c3c.jpg" alt="">
这个观点，我在一篇文章[《数据中台的使命、愿景、本质和六大核心能力》](https://mp.weixin.qq.com/s/O_taKcAoogelov1TBqy0-g)里剖析过。
今天呢，我想深入和你聊聊企业建设了数据中台，成为了数据驱动的智能企业，这对企业到底有什么收益呢？
我认为企业能够获得两个方面的收益：**优化现有业务和实现新业务的转型。**
<img src="https://static001.geekbang.org/resource/image/bd/b3/bdb57bfb3dcdcc0ad59f3a23c1fa7ab3.jpg" alt="">
### 优化现有业务
优化业务这一点很好理解，就是通过数据分析和人工智能技术的应用，优化原有的业务流程。我从以下5个方面和你深入进来看。
**第一，增加现有业务的收入。**
这是企业建设数据中台的一个直接诉求。比如，通过分析产品的价格、销量、用户数据来优化产品定价、优化产品组合、进行精准营销，从而能够促进产品的销售，增加现有产品的收入。
给你举一个典型的案例，是我们给一个能源类企业做的数据中台。建成后能够根据历史销量、市场份额、市场容量等数据进行建模，从而帮助企业的销售部门去优化销售任务的分配，最后提升销售额。
这样的一个看上去很小的项目，能给企业带来啥价值呢？这么说吧，过去，企业每年年初给全国的几十个销售定业绩并持续去跟踪，是一个很痛苦的事情，原因主要在于目标不好锚定，每个销售管理着一堆经销商，经销商的销量、退货都不拉通，所以无法客观地量化和追踪销售的业绩。
怎么办呢？过去这一切靠的都是销售总监的经验去拍数，更多靠的是谈判能力，是一个不确定性很高的工作。有了数据中台后，把行业数据、市场竞争数据、往年销售数据以及经销商的数据都拉通来看，一下子能够给到销售总监全貌，还可以做模拟，让销售业绩分配这个工作变成一个可量化、可预测的确定性工作。
**第二，促进生产效率。**
通过数据中台的建设，能够促进生产效率的提升。关于这一点，直接给你说个场景吧。
比如，某个大型电信服务商，通过对勘测、规划、设计工作的建模，实现数据自动化处理，减少人工干预和问题的出现，从而大幅提升工程师的设计效率和准确性，将工程设计的周期缩短一半以上。
分析下原因。电信服务商的投标是一个很复杂的工作，从客户发出需求到根据需求去勘测、做出规划、具体实施设计再到把实施设计转化成物料设计、工程设计、财务设计，最后再形成投标方案，这个过程过去至少需要一个月，需要众多不同业务部门和专业技能的协作，其中大部分工作都花在了不同数据的合并、拉通、对齐和映射上。
那么当这个企业建设了数据中台后，所有的数据能够自动处理，大家在同一个数据服务里获取、修改、加工同样的一套数据，并且每次做方案的过程都沉淀成新的服务，后面的项目可以复用，这样大大缩短了工期，有些标准化比较高的项目类型，可以从原来的一个月缩短到三天。
**第三，降低运营成本，提升运营的利润。**
这个是目前利用场景最多的，主要就是通过数据分析来优化业务流程、缩短运营周期，从而提升运营的利润。
比如，我之前做的一个项目，是给一家大型的钢铁厂进行配方的规划优化，通过对配方数据、市场价格、销量数据的综合分析建模，给到成本最优、产值最高的生产组合，从而能够降低运营成本，提升利润。
你可能对钢铁这个行业不太了解，钢铁行业里配矿决策是一个很复杂但是很重要的环节，不同的配矿方案，其成本和工艺都不一样，对利润的影响很大。
如何根据技术和商业的众多因素去选择最优的配方呢？过去都是根据经验来维护和计算配矿规则，效率低、周期长。有了数据中台后，将原材料的性能、化学工艺、产品质量等技术因素和价格、成分、运营成本及销售收入等商业因素的数据统一进行建模，统一计算后最终做出综合规划，这样做大大提升了利润、降低了运营成本。
如下图所示，这是一个典型的钢粉配方的和制造成本的表格，这里面每一项的变化都会带来成本的变化，而影响利润的除了制造成本外，还有销售价格，运营成本等，这样一来如何设计出最优化的配矿决策就是非常重要的因素。通过数据建模，机器学习的智能配矿模型能够全方位的规划最优的方案，从而达到特定的商业目标，比如缩短生产周期，或者是提升利润，优化库存等。
<img src="https://static001.geekbang.org/resource/image/f3/69/f3d2d6a195ddece211fecd315d55bf69.jpg" alt="">
**第四，提升用户体验。**
提升用户体验的核心是企业要理解自己的用户，知道用户对自己产品、服务的认知，然后对应优化自己的产品和服务，这就需要建设用户数据平台，构建统一的用户视图，建立起用户画像。
这里我举个富国银行的例子，他们在数据转型中，利用数据中台分析用户的行为数据，来重构在线银行的网站，提升用户体验。富国银行在2016年的时候面临很大的业绩挑战，为了更好地了解用户，他们建立了企业级的数据中台，把全行的用户信息都打通，做成用户画像，打上各种标签，并根据这些用户画像和标签，重新设计了电子银行网站，让网站的服务和风格以用户为中心。
这是一个为期几年的数据转型之旅，富国银行也因为这个项目成功地成为了行业里的“零售之王”，更多细节可以看看这篇文章[《富国银行的数据转型之旅》](https://mp.weixin.qq.com/s/dg30hCV9mZ95NyNVVs3TmQ)。
**第五，提升资产利用率。**
这一点主要是指分析、优化高价值资产，提升资产的利用率。
我举一个我们做过的物流领域路径优化的案例。我们曾经给国内最大的物流企业之一做过路径优化的项目，帮助他们提升人员和车辆的使用率。过去，每天早上每个区域都有一个经验丰富的员工，统一规划前一天收到的派件和收件订单，把这些订单分配给对应的小组。
这个过程的目的就是最大化地利用车辆和快递员这两个核心资产。但是这个规划是很复杂的，因为不仅要考虑成本，还要考虑到每个件积压的时间不一样、紧急程度不一样、不同的地点路况对于车辆的要求也不一样等等，这些数据的采集、拉通、建模是很重要的基础工作而这一切都依赖与数据的打通。
建设数据中台，拉通了数据后，派单收单的路径更优化了，更好的分配给快递员，提升了车辆的使用率提升了20%左右。你看，这样的场景就很典型，体现了数据中台所能支撑的智能规划业务的价值。
### 业务创新和转型
接下来，我们继续来看建设数据中台的第二个收益，实现业务创新和转型。这里我总结了四个主要的价值，这些价值乍一听好像都比较抽象，我会用具体的例子来分析。
**第一，数字化产品创新。**
这里有一个很生动的例子，我们有一个合作了十多年的海外房地产交易网站客户，主要是定期和他们做黑客马拉松。
有一次我们黑客马拉松的一个小组，通过数据分析发现了一个小模式，就是有一群用户，在一段时间内高频访问网站，但是不产生任何看房、卖房的行为。这是为什么呢？最后通过数据分析，发现这样的用户都有一个共同的特点，那就是她们大部分都是女性，而且基本上访问链接停留时间最长的，很多都是图片，而且是室内的图片。
基于这些数据，我们推测，这群人是来看装修的，于是，基于这个推测，这个小组孵化了一个新产品，专门提供装修服务，这个产品最后还成功了，成为了公司除房地产中介服务之外的新业务线。
这也是典型的通过数据洞察发现业务新价值，从而实现数字化产品创新的场景。
**第二，数字化资产销售。**
这一点说的就是将已经积累的数据，通过组合、包装、分析、脱敏，形成对于一部分用户有价值的数据资产，比如行业报告或者优质的内容，直接销售产生收入。
这个典型的场景就是搜索引擎，搜索引擎将用户的信息进行统计分析、脱敏处理后，变成一系列的知识和分析报告，然后以会员的方式，提供给有需要的用户。
我们都用过百度指数吧，这里面，用户可以定义和购买自己感兴趣的关键词，一年是198元，然后百度就会把所有搜索过这个关键词的记录统计出来，变成这个关键词的搜索指数。比如，数据中台的关键词就是我去年购买的，我就能实时追踪这个关键词在中文市场被搜索的热度。这就是数据化资产销售的价值模式。
<img src="https://static001.geekbang.org/resource/image/2a/00/2abd54451c8f627499b7f6a880e12600.jpg" alt="">
**第三，业务平台化收益。**
有一句话在去年很流行，“未来的企业，要么自己做平台，要么被别人平台化”。平台经济成为了这几年数字化领域炙手可热的概念。总的来说，平台化就是你搭建一个平台，让需求方和供给方上来交易，最后你来收取服务费。
那么如何建立平台呢？拉通一个领域数据，形成数字化平台，再通过平台来运营一个特定的业务和客户群体，从而通过平台来产生收益。
典型的场景就是交易撮合平台，比如非常玄幻的比特币交易平台。你可能会说，这个和数据中台有什么关系？这个过程其实也是一个领域数据中台的建设过程，因为作为平台方，其实主要做的就是数据的生意，对接信息、对接交易双方。那么数据中台在企业内部，就相当于一个数据采集、加工、交易的平台，业务方既可能是数据服务的消费者，又可能是生产者，最终的产品是数据服务。
**第四，数字化生态业务。**
这一点是从更高的一个维度来看的，就是在平台化基础之上，通过打穿产业供应链，帮助企业建设自己的数字化生态，从而在生态中产生新的业务价值和收入。
一个典型的例子就是Google的应用商店。当有足够多的伙伴在这个平台上进行交易的时候，它就可以在这些海量的交易和行为数据中去发现特别多的规律，然后产生更多的产品创新，利用数据来牵引着这个生态朝自己设计的方向发展。
在这个生态里，有非常多的角色参与其中，开发者、自由开发者、广告商、应用购买者等，而Google掌握着所有方的数据，用户的浏览、下载、付费、交易，一切的数据都能够被分析、被利用，帮助Google Play的运营方去发现新的业务价值，创造收入。
## 总结
讲了这么多，我们来做个总结。今天我和你分享了建设数据中台到底有什么用，从我的经验出发，我总结了一个数据中台收益框架，这个框架包括两大维度、九个细分项。掌握这些内容有啥用呢？最核心的就是给我们建设数据中台这件事找到目标，你可以把这9项作为一个指导，先明确价值和方向，再找到应用场景，以此作为牵引来建设自己的数据中台。
最后，再分享一点我这些年做企业信息化的感受。
我想大部分企业是要经历一个转型的，朝着数智化方向演进。企业的转型，从最早的信息化走向数字化，下一个目标是数智化。
<img src="https://static001.geekbang.org/resource/image/7f/e2/7f55c0cfa6d21f3a9147059a142bdce2.jpg" alt="">
信息化解决的是企业内部的管理问题，让企业能够以一个有组织、有流程的方式高效地运转起来。
数字化解决的是企业与外部的连接问题，让企业能够直接触达客户，并且建立线上的业务。<br>
数智化解决的是让企业成为智能企业，业务更智慧的问题，这个过程的核心生产要素就是数据。
可以说，数智化转型能够给企业带来颠覆性的变革，但是如何去发现数据的价值，如何构建数据智能的能力，如何规模化赋能业务呢？
这时候企业需要一个抓手，利用这个抓手来对齐业务和技术，不断前进。数据中台就像是这个抓手，谁能够围绕以上的业务优化和转型两个方面的价值来建设数据中台，谁就能够在数智化转型中获得领先优势。
讲到这里，我都有点激动了，数据中台的这股浪潮，给我们提供了一个机会，但是这个机会也对我们提出了很多、很高的能力要求。我想把这个问题作为课后思考题留给你，请你想想，成为数智化企业，都需要哪些能力呢？我做了众多个国内外领先企业的转型研究，发现了一些规律和有意思的事情。
期待你的思考，也期待后面有机会和你继续探讨。