mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-11-16 14:13:46 +08:00
del
This commit is contained in:
louzefeng
170
极客时间专栏/geek/数据中台实战课/原理篇/01 | 前因后果：为什么说数据中台是大数据的下一站？.md
Normal file
170
极客时间专栏/geek/数据中台实战课/原理篇/01 | 前因后果：为什么说数据中台是大数据的下一站？.md
Normal 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
144
极客时间专栏/geek/数据中台实战课/原理篇/02 | 关键抉择： 到底什么样的企业应该建数据中台？.md
Normal 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
157
极客时间专栏/geek/数据中台实战课/原理篇/03 | 数据中台建设三板斧：方法论、组织和技术.md
Normal 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
192
极客时间专栏/geek/数据中台实战课/原理篇/特别放送｜史凯：建设数据中台到底有什么用？.md
Normal 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>
|
||||
数智化解决的是让企业成为智能企业，业务更智慧的问题，这个过程的核心生产要素就是数据。
|
||||
|
||||
可以说，数智化转型能够给企业带来颠覆性的变革，但是如何去发现数据的价值，如何构建数据智能的能力，如何规模化赋能业务呢？
|
||||
|
||||
这时候企业需要一个抓手，利用这个抓手来对齐业务和技术，不断前进。数据中台就像是这个抓手，谁能够围绕以上的业务优化和转型两个方面的价值来建设数据中台，谁就能够在数智化转型中获得领先优势。
|
||||
|
||||
讲到这里，我都有点激动了，数据中台的这股浪潮，给我们提供了一个机会，但是这个机会也对我们提出了很多、很高的能力要求。我想把这个问题作为课后思考题留给你，请你想想，成为数智化企业，都需要哪些能力呢？我做了众多个国内外领先企业的转型研究，发现了一些规律和有意思的事情。
|
||||
|
||||
期待你的思考，也期待后面有机会和你继续探讨。
|
||||
169
极客时间专栏/geek/数据中台实战课/实现篇/04 | 元数据中心的关键目标和技术实现方案.md
Normal file
169
极客时间专栏/geek/数据中台实战课/实现篇/04 | 元数据中心的关键目标和技术实现方案.md
Normal file
@@ -0,0 +1,169 @@
|
||||
<audio id="audio" title="04 | 元数据中心的关键目标和技术实现方案" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4e/0a/4e9535d135d900fd575ebd768e30550a.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
在上一节课程中，我从宏观的角度，系统性地带你了解了数据中台建设的方法论、支撑技术和组织架构，从这节课开始，我们正式进入实现篇，我会从微观的角度出发，带你具体分析数据中台的支撑技术，以电商场景为例，分别讲解元数据中心、指标管理、模型设计、数据质量等技术如何在企业落地。
|
||||
|
||||
这节课，咱们来聊聊元数据。
|
||||
|
||||
为什么要先讲元数据呢？我来举个例子。在原理篇中，我提到数据中台的构建，需要确保全局指标的业务口径一致，要把原先口径不一致的、重复的指标进行梳理，整合成一个统一的指标字典。而这项工作的前提，是要搞清楚这些指标的业务口径、数据来源和计算逻辑。而这些数据呢都是元数据。
|
||||
|
||||
你可以认为，如果没有这些元数据，就没法去梳理指标，更谈不上构建一个统一的指标体系。当你看到一个数700W，如果你不知道这个数对应的指标是每日日活，就没办法理解这个数据的业务含义，也就无法去整合这些数据。**所以你必须要掌握元数据的管理，才能构建一个数据中台。**
|
||||
|
||||
那么问题来了：元数据中心应该包括哪些元数据呢？ 什么样的数据是元数据？
|
||||
|
||||
## 元数据包括哪些？
|
||||
|
||||
结合我的实践经验，我把元数据划为三类：数据字典、数据血缘和数据特征。我们还是通过一个例子来理解这三类元数据。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/47/db/4792edac4ec5eefdbf5f2e71f404b0db.jpg" alt="">
|
||||
|
||||
在这个图中，dwd_trd_order_df 是一张订单交易明细数据，任务flow_dws_trd_sku_1d 读取这张表，按照sku粒度，计算每日sku的交易金额和订单数量，输出轻度汇总表dws_trd_sku_1d。
|
||||
|
||||
数据字典描述的是数据的结构信息，我们以dws_trd_sku_1d为例，数据字典包括：
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/70/b6/706050b3ef2c71001ecd94158efe55b6.jpg" alt="">
|
||||
|
||||
数据血缘是指一个表是直接通过哪些表加工而来，在上面的例子中，dws_trd_sku_1d是通过dwd_trd_order_df的数据计算而来，所以，dwd_trd_order_df是dws_trd_sku_1d的上游表。
|
||||
|
||||
数据血缘一般会帮我们做影响分析和故障溯源。比如说有一天，你的老板看到某个指标的数据违反常识，让你去排查这个指标计算是否正确，你首先需要找到这个指标所在的表，然后顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。
|
||||
|
||||
而数据特征主要是指数据的属性信息，我们以dws_trd_sku_1d为例：
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/d5/1b/d5303f16e5a969f039080e413d26201b.jpg" alt="">
|
||||
|
||||
通过这个例子，你了解了元数据了吗？ 不过元数据的种类非常多，为了管理这些元数据，你必须要构建一个元数据中心。那么接下来，我们就来看看如何搭建一个元数据中心，打通企业的元数据。
|
||||
|
||||
## 业界元数据中心产品
|
||||
|
||||
我做系统设计这么些年，一直有一个习惯，是先看看业界的产品都是怎么设计的，避免关门造车。业界的比较有影响力的产品：
|
||||
|
||||
- 开源的有Netflix的Metacat、Apache Atlas；
|
||||
- 商业化的产品有Cloudera Navigator。
|
||||
|
||||
我今天重点想带你了解Metacat和Atlas这两款产品，一个擅长于管理数据字典，一个擅长于管理数据血缘，通过了解这两款产品，你更能深入的理解元数据中心应该如何设计。
|
||||
|
||||
### Metacat 多数据源集成型架构设计
|
||||
|
||||
关于[Metacat](https://github.com/Netflix/metacat)，你可以在GitHub上找到相关介绍，所以关于这个项目的背景和功能特性，我就不再多讲，我只想强调一个点，就是它多数据源的可扩展架构设计，因为这个点对于数据字典的管理，真的太重要！
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ca/3f/ca1fd21c2109b921c680008469dd663f.jpg" alt="">
|
||||
|
||||
在一般的公司中，数据源类型非常多是很常见的现象，包括Hive、MySQL、Oracle、Greenplum等等。支持不同数据源，建立一个可扩展的、统一的元数据层是非常重要的，否则你的元数据是缺失的。
|
||||
|
||||
从上面Metacat的架构图中，你可以看到，Metacat的设计非常巧妙，它并没有单独再保存一份元数据，而是采取直连数据源拉的方式，一方面它不存在保存两份元数据一致性的问题，另一方面，这种架构设计很轻量化，每个数据源只要实现一个连接实现类即可，扩展成本很低，我把这种设计叫做集成型设计。我认为这种设计方式对于希望构建元数据中心的企业，是非常有借鉴意义的。
|
||||
|
||||
### Apache Atlas 实时数据血缘采集
|
||||
|
||||
同样，关于[Apache Atlas](http://atlas.apache.org/)的背景和功能，我也不多说，只是想强调Atlas 实时数据血缘采集的架构设计，因为它为解决血缘采集的准确性和时效性难题提供了很多的解决思路。
|
||||
|
||||
血缘采集，一般可以通过三种方式：
|
||||
|
||||
- 通过静态解析SQL，获得输入表和输出表；
|
||||
- 通过实时抓取正在执行的SQL，解析执行计划，获取输入表和输出表；
|
||||
- 通过任务日志解析的方式，获取执行后的SQL 输入表和输出表。
|
||||
|
||||
第一种方式，面临准确性的问题，因为任务没有执行，这个SQL对不对都是一个问题。第三种方式，血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。所以第二种方式，我认为是比较理想的实现方式，而Atlas 就是这种实现。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b9/8c/b96e93b2ea7548fbd8bcb15eab93988c.jpg" alt="">
|
||||
|
||||
对于Hive 计算引擎，Atlas 通过Hook方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给Kafka，由一个Ingest 模块负责将血缘写入JanusGraph图数据库中。然后通过API的方式，基于图查询引擎，获取血缘关系。对于Spark，Atlas 提供了Listener的实现方式，此外Sqoop、Flink 也有对应的实现方式。
|
||||
|
||||
这两款产品在设计网易元数据中心时，给了很多灵感，下面我就带你了解一下网易元数据中心的设计，以便你掌握一个元数据中心在设计时应该考虑哪些点。
|
||||
|
||||
## 网易元数据中心设计
|
||||
|
||||
在设计网易元数据中心之初，我设定了元数据中心必须实现的5个关键目标：
|
||||
|
||||
**其一，多业务线、多租户支持。**
|
||||
|
||||
在网易，电商、音乐都是不同的业务线，同一个业务线内，也分为算法、数仓、风控等多个租户，所以元数据中心必须支持多业务线、多租户。
|
||||
|
||||
**其二，多数据源的支持。**
|
||||
|
||||
元数据中心必须要能够支持不同类型的数据源（比如MySQL、Hive、Kudu等），同时还要支持相同数据源的多个集群。为了规范化管理，还需要考虑将半结构化的KV也纳入元数据中心的管理（比如Kafka、Redis、HBase等）。这些系统本身并没有表结构元数据，所以需要能够在元数据中心里定义Kafka每个Topic的每条记录JSON中的格式，每个字段代表什么含义。
|
||||
|
||||
**其三，数据血缘。**
|
||||
|
||||
元数据中心需要支持数据血缘的实时采集和高性能的查询。同时，还必须支持字段级别的血缘。
|
||||
|
||||
什么是字段级别的血缘，我们来举个例子。
|
||||
|
||||
>
|
||||
<p>insert overwrite table t2 select classid, count(userid) from t1 group<br>
|
||||
by classid;</p>
|
||||
|
||||
|
||||
t2表是由t1表的数据计算来的，所以t2和t1是表血缘上下游关系，t2的classid字段是由t1的classid字段产生的，count字段是由userid经过按照classid字段聚合计算得到的，所以t2表的classid与t1的classid存在字段血缘，t2表的count分别与t1表的classid和userid存在血缘关系。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/10/31/10215ac91d081d84a53ee72deb1fad31.jpg" alt="">
|
||||
|
||||
字段血缘在做溯源的时候非常有用，因为大数据加工链路的下游是集市层，为了方便使用者使用，一般都是一些很宽的表（列很多的表，避免Join带来的性能损耗），这个表的上游可能是有几十个表产生的，如果不通过字段血缘限定溯源范围，就会导致搜索范围变得很大，无法快速地精准定位到有问题的表。
|
||||
|
||||
另外，数据血缘还必须要支持生命周期管理，已经下线的任务应该立即清理血缘，血缘要保留一段时间，如果没有继续被调度，过期的血缘关系应该予以清理。
|
||||
|
||||
**其四，与大数据平台集成。**
|
||||
|
||||
元数据中心需要与Ranger集成，实现基于tag 的权限管理方式。在元数据中心中可以为表定义一组标签，Ranger可以基于这个标签，对拥有某一个标签的一组表按照相同的权限授权。这种方式大幅提高了权限管理的效率。比如，对于会员、交易、毛利、成本，可以设定表的敏感等级，然后根据敏感等级，设定不同的人有权限查看。
|
||||
|
||||
另外，元数据中心作为基础元数据服务，包括自助取数分析系统，数据传输系统，数据服务，都应该基于元数据中心提供的统一接口获取元数据。
|
||||
|
||||
**其五，数据标签。**
|
||||
|
||||
元数据中心必须要支持对表和表中的字段打标签，通过丰富的不同类型的标签，可以完善数据中台数据的特征，比如指标可以作为一种类型的标签打在表上，主题域、分层信息都可以作为不同类型的标签关联到表。
|
||||
|
||||
基于这5个因素的考虑，我们设计了网易元数据中心。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/d5/f4/d590abca0d8f54d19fa413696dfd97f4.jpg" alt="" title="网易元数据中心系统架构设计图">
|
||||
|
||||
这个图按照功能模块分为数据血缘、数据字典和数据特征。
|
||||
|
||||
数据血缘由采集端、消息中间件、消费端以及血缘清理模块组成，基于Hive Hook，Spark Listener，Flink Hook ，可以获取任务执行时输入表和输出表，推送给统一的消息中间件（Kafka），然后消费端负责将血缘关系沉淀到图数据库中。
|
||||
|
||||
图数据库选择Neo4j，主要考虑是性能快、部署轻量化、依赖模块少，当然，开源的Neo4j没有高可用方案，并且不支持水平扩展，但是因为单个业务活跃的表规模基本也就在几万的规模，所以单机也够用，高可用可以通过双写的方式实现。
|
||||
|
||||
血缘还有一个清理的模块，主要负责定时清理过期的血缘，一般我们把血缘的生命周期设置为7天。
|
||||
|
||||
数据字典部分，我们参考了Metacat实现，我们由一个统一的Connector Mananger负责管理到各个数据源的连接。对于Hive、MySQL，元数据中心并不会保存系统元数据，而是直接连数据源实时获取。对于Kafka、HBase、Redis等KV，我们在元数据中心里内置了一个元数据管理模块，可以在这个模块中定义Value的schema信息。
|
||||
|
||||
数据特征主要是标签的管理以及数据的访问热度信息。元数据中心内置了不同类型的标签，同时允许用户自定义扩展标签类型。指标、分层信息、主题域信息都是以标签的形式存储在元数据中心的系统库里，同时元数据中心允许用户基于标签类型和标签搜索表和字段。
|
||||
|
||||
元数据中心统一对外提供了API访问接口，数据传输、数据地图、数据服务等其他的子系统都可以通过API接口获取元数据。另外Ranger 可以基于元数据中心提供的API接口，获取标签对应的表，然后根据标签更新表对应的权限，实现基于标签的权限控制。
|
||||
|
||||
元数据中心构建好以后，你肯定会问，这个元数据中心没有界面吗？它长什么样子？用户咋使用这个元数据中心？ 别急，我们接着往下看。
|
||||
|
||||
## 数据地图：元数据中心的界面
|
||||
|
||||
数据地图是基于元数据中心构建的一站式企业数据资产目录，可以看作是元数据中心的界面。数据开发、分析师、数据运营、算法工程师可以在数据地图上完成数据的检索，解决了“不知道有哪些数据？”“到哪里找数据？”“如何准确的理解数据”的难题。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/7b/8c/7b0bb4f2555d4610a05b91c86416888c.png" alt="">
|
||||
|
||||
数据地图提供了多维度的检索功能，使用者可以按照表名、列名、注释、主题域、分层、指标进行检索，结果按照匹配相关度进行排序。考虑到数据中台中有一些表是数仓维护的表，有一些表数仓已经不再维护，在结果排序的时候，增加了数仓维护的表优先展示的规则。同时数据地图还提供了按照主题域、业务过程导览，可以帮助使用者快速了解当前有哪些表可以使用。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a3/35/a315fc502a4f94ac3b77947d38de7535.jpg" alt="">
|
||||
|
||||
当使用者定位到某一个表打开时，会进入详情页，详情页中会展示表的基础信息，字段信息、分区信息、产出信息以及数据血缘。数据血缘可以帮助使用者了解这个表的来源和去向，这个表可能影响的下游应用和报表，这个表的数据来源。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/17/ba/17516d5fb201cffc9d69f32e98993bba.png" alt="">
|
||||
|
||||
数据地图同时还提供了数据预览的功能，考虑到安全性因素，只允许预览10条数据，用于判断数据是否符合使用者的预期。数据地图提供的收藏功能， 方便使用者快速找到自己经常使用的表。当数据开发、分析师、数据运营找到自己需要的表时，在数据地图上可以直接发起申请对该表的权限申请。
|
||||
|
||||
数据地图对于提高数据发现的效率，实现非技术人员自助取数有重要作用。经过我的实践，数据地图是数据中台中使用频率最高的一个工具产品，在网易，每天都有500以上人在使用数据地图查找数据。
|
||||
|
||||
## 课程总结
|
||||
|
||||
本节课，我以元数据作为起点，带你了解了元数据应该包括数据字典、数据血缘和数据特征，然后通过分析两个业界比较有影响力的元数据中心产品，结合我在网易数据中台实践，给出了元数据中心设计的5个关键特性和技术实现架构，最后介绍了基于元数据中心之上的数据地图产品。我想在最后强调几个关键点：
|
||||
|
||||
- 元数据中心设计上必须注意扩展性，能够支持多个数据源，所以宜采用集成型的设计方式。
|
||||
- 数据血缘需要支持字段级别的血缘，否则会影响溯源的范围和准确性。
|
||||
- 数据地图提供了一站式的数据发现服务，解决了检索数据，理解数据的“找数据的需求”。
|
||||
|
||||
最后，你要知道，元数据中心是数据中台的基石，它提供了我们做数据治理的必须的数据支撑，在后续的章节中，我们将逐一介绍指标、模型、质量、成本、安全等的治理，这些都离不开元数据中心的支撑。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/06/63/069ede4c461619307896563cbf681063.jpg" alt="">
|
||||
|
||||
## 课程思考
|
||||
|
||||
在课程中，我介绍了血缘采集的三种方式，并且推荐了通过实时采集的方式，但是其实静态解析血缘也有它的优势应用场景，你能想到有哪些么？欢迎在留言区与我讨论。
|
||||
|
||||
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。
|
||||
223
极客时间专栏/geek/数据中台实战课/实现篇/05 | 如何统一管理纷繁杂乱的数据指标？.md
Normal file
223
极客时间专栏/geek/数据中台实战课/实现篇/05 | 如何统一管理纷繁杂乱的数据指标？.md
Normal file
@@ -0,0 +1,223 @@
|
||||
<audio id="audio" title="05 | 如何统一管理纷繁杂乱的数据指标？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/cc/db/ccc940e955a0d4e48aebb15f87a95edb.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
上一节课，我讲到了各种类型的元数据，这些元数据有什么用？跟我们的数据中台又有什么关系呢？ 其实，元数据在指标管理、模型设计、数据质量和成本治理四个领域都发挥着作用，而这些领域构成了数据中台OneData 数据体系。从今天开始，我将带你逐一了解元数据在上述领域的应用，首先是指标管理。
|
||||
|
||||
指标是一种特定类型的元数据，公司的运营会围绕它进行工作，可以说，它是业务和数据的交汇点。指标数据能不能用，会影响他们的日常工作。来看一件我身边发生的事儿。
|
||||
|
||||
在电商业务中，新用户销售额是考核市场活动拉新效果的重要指标。马漂亮（化名）是市场部门的数据分析师，某一天，她要给CEO提供一份数据报告，报告中有一项指标是“新用户销售额”。孙美丽（化名）是会员中心的运营，她每天都会给CEO提供每日的新用户销售额数据。
|
||||
|
||||
结果有一天，CEO看了这两份报告后发现，同一日的新用户销售额数值相差很大，他判断数据出了问题，责令两个部门的负责人进行排查。**排查后发现，市场部门对新用户口径的定义和会员中心不一样：**
|
||||
|
||||
- 市场部门认定新用户是首次下单并完成支付的用户；
|
||||
- 会员中心认定新用户是当日新注册用户。
|
||||
|
||||
也就是说，市场部门认定的新用户中，可能有之前注册但是没有下过单的客户；而会员中心只包括当日注册并完成下单支付的用户。其实，在日常工作中还有很多类似的问题。
|
||||
|
||||
造成上述问题的根源是因为指标口径不一致，而你要构建全局一致的指标口径，输出企业的指标字典。
|
||||
|
||||
## 指标混乱现状
|
||||
|
||||
从2018年年末开始，网易电商数据中台团队对电商业务的核心指标进行了全面的盘点和梳理，为的就是解决指标口径不一致的问题。原先800个指标，最终梳理完成427个指标，在梳理过程中，我总结了7个常见的指标问题，希望你能对照着看一下，自己是否也存在类似的情况。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a4/36/a45797ab82110cff7ac4e0f9b43baa36.jpg" alt="">
|
||||
|
||||
你可以编个口诀记忆一下，比如：
|
||||
|
||||
同名不同径，同径不同名。<br>
|
||||
口径不清晰，口径有错误。<br>
|
||||
命名难理解，计算不易懂。<br>
|
||||
来源不清晰，同部不同径。
|
||||
|
||||
**第一，相同指标名称，口径定义不同。**
|
||||
|
||||
我开篇说的就是这个问题，不同的部门对相同的“新用户销售额”，因为口径定义的差别，导致指标数值的不一致。而这种情况是指标管理中最容易出现的情况。口径不一致，数据也就没办法横向对比，失去了数据辅助商业决策的意义。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/8f/54/8f34d04b88b0ee071b49ab1f534e8f54.jpg" alt="">
|
||||
|
||||
**第二，相同口径，指标名称不一样。**
|
||||
|
||||
这种情况与上面相反，比如发放优惠券是电商常见的促销手段，现在你有两个数据产品：
|
||||
|
||||
- 一个是经营大脑，主要展示的是企业日常经营活动健康度的核心指标，它有一个指标叫“优惠券抵扣金额”；
|
||||
- 一个是市场360，主要是展示市场活动效果衡量的指标，它也有一个指标叫“优惠券消耗金额”。
|
||||
|
||||
其实，两者的口径定义并没有区别，但是指标名称不同，这会让使用指标的人疑惑，是不是同一个指标，计算逻辑是否一致？数据是否可以横向对比？
|
||||
|
||||
**第三，不同限定词，描述相同事实过程的两个指标，相同事实部分口径不一致。**
|
||||
|
||||
这个问题该如何理解呢？ 来看一个例子。
|
||||
|
||||
黑卡会员购买用户和非会员购买用户数，它们描述的都是用户下单购买商品的相同业务过程，记录的都是购买商品的事实，只是一个限定词是黑卡会员，一个限定词是非会员。
|
||||
|
||||
按照一致性原则，虽然是两个指标，但是对于购买用户数这个相同的事实部分，业务口径、计算逻辑应该是一致的，但是现实情况却可能不是这样：
|
||||
|
||||
- “黑卡会员购买用户数”的口径定义是计算周期内去重的（重复购买的用户只算一个），下单并且支付成功的用户数量；
|
||||
- “ 非会员的购买用户数”的口径定义是计算周期内去重的，下单并且支付成功，排除关单（“关单”是指在用户在下单购买成功后，取消订单）的用户数量。
|
||||
|
||||
你能看到，对于购买用户数，这两个指标的口径是不一致的，一个包含关单，一个不包含关单。
|
||||
|
||||
**第四，指标口径描述不清晰。**
|
||||
|
||||
在梳理过程中，我们还发现，有些报表上的指标口径描述的比较笼统。比如“关单金额”，口径描述“关闭订单的金额”。不同人的理解可能不一样，有的人会认为是支付成功后关闭订单；也有可能是支付完成前，取消订单。描述不清晰，就会让人们对数据的理解产生歧义。
|
||||
|
||||
**第五，指标口径描述错误。**
|
||||
|
||||
在流量分析数据产品中，有“7日uv”这个指标，口径的定义是7日内日均uv。根据口径描述的计算逻辑，应该是最近7日，每日uv相加除以7取平均值。显然，这个定义在业务场景中是有问题的，正确的7日uv的口径定义应该是7日内有登录过，去重的用户数。
|
||||
|
||||
**第六，指标命名难于理解。**
|
||||
|
||||
我们在梳理促销业务过程的指标时，有一个数据产品的指标名称是“ROI”，口径定义优惠券销售额/优惠券成本。ROI其实是投资回报率的简称，在电商业务场景中，除了优惠劵，商品降价促销都可以计算ROI，所以比较好的命名应该是（商品|类目|通用）优惠劵ROI。所以，指标命名不规范的话，从指标名称中很难看出指标描述的业务过程。
|
||||
|
||||
**最后，指标数据来源和计算逻辑不清晰。**
|
||||
|
||||
如果指标数据来源不清楚，一旦这个指标数据异常，就很难去做溯源。另外，有些指标的计算逻辑比较复杂，仅仅凭借业务口径一段描述，使用指标的人还是无法理解这个指标的计算逻辑，这个时候就需要有一些伪码或者SQL描述。
|
||||
|
||||
## 如何规范化定义指标
|
||||
|
||||
那么如果你面临这些问题，该如何规范化定义指标呢？我提供给你一些经验，希望你能从中学习到如何高效、规范化的管理指标。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/6f/1f/6ffb4a672a9c89cb573527e83152ce1f.jpg" alt="">
|
||||
|
||||
**首先，面向主题域管理。**
|
||||
|
||||
为了提高指标管理的效率，你需要按照业务线、主题域和业务过程三级目录方式管理指标（业务线是顶级目录）。
|
||||
|
||||
在网易，电商、游戏、音乐、传媒、教育都是不同的业务线。在业务线之下，是主题域，指标中的主题域与数仓中的概念是一致的，划分标准最好是跟数仓保持一致（数仓主题域的划分，我会在06讲详细讲述）。在主题域下面还有细分的业务过程，比如对于交易域，细分的业务过程有加入购物车、下单、支付。
|
||||
|
||||
**其次，拆分原子指标和派生指标。**
|
||||
|
||||
为了解决前面提到的，“黑卡购买用户数”和“非会员购买用户数”，这两个指标对购买用户数口径定义不一致的问题，我们需要引入原子指标和派生指标的管理方式。**那么什么是原子指标，什么是派生指标呢？**
|
||||
|
||||
统计周期、统计粒度、业务限定、原子指标，组成派生指标，所以原子指标可以定义为不能够按照上述规则进一步拆分的指标。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b4/01/b411dd7d53b272af1ec4b3c839c8cb01.jpg" alt="">
|
||||
|
||||
在例子中，你可以这样理解：
|
||||
|
||||
- 购买用户数是原子指标，原子指标的口径定义是“计算周期内去重的，下单并且支付成功的用户数量，包括关单”；
|
||||
- 黑卡会员和非会员都可以认定为业务限定词；
|
||||
- 统计粒度是商品粒度的；
|
||||
- 统计周期是30天。
|
||||
|
||||
这样30天内，商品维度的黑卡会员购买用户数和30天内商品维度的非会员购买用户数就作为两个派生指标存在，但是他们继承自同一个原子指标。
|
||||
|
||||
**除此之外，还需要指标命名规范。**
|
||||
|
||||
指标命名规范要遵循两个基本的原则：
|
||||
|
||||
- 易懂，就是看到指标的名称，就可以基本判断这个指标归属于哪个业务过程；
|
||||
- 统一，就是要确保派生指标和它继承的原子指标命名是一致的。
|
||||
|
||||
除此之外，指标应该有指标名称和指标标识（或者叫英文名）。
|
||||
|
||||
**对于原子指标，**指标名称适合用“动作+度量”的命名方式（比如注册用户数、购买用户数），标识的命名用英文简写或者汉语拼音缩写比较好。
|
||||
|
||||
**对于派生指标，**指标名称应该严格遵循“时间周期+统计粒度+修饰词+原子指标”的命名方式，标识命名要用“修饰词_原子指标_时间周期”的方式。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/3b/c0/3b7d48e206002cb4817b8ae3af1da6c0.jpg" alt="">
|
||||
|
||||
**第四，关联的应用和可分析维度。**
|
||||
|
||||
对于使用指标的人（运营、分析师）了解了这个指标的口径定义之后，下一步就是要看指标的数值。所以，在全局的指标字典中，还应该有指标被哪些应用使用，这样方便去对应的数据产品或者报表上查看指标的数值。除此之外，还应该有指标的可分析维度，方便分析师从不同的维度分析指标的变化趋势。
|
||||
|
||||
**最后一个是分等级管理。**
|
||||
|
||||
那这么多指标，数据中台管的过来么？是的，确实管不过来，因为不仅仅是数据中台会产出一些公共核心指标，业务部门也会创建一些专属业务部门内的指标。那面对这么多指标，如何管理呢？以我的经验，你可以按照以下原则区分等级，来管理指标。
|
||||
|
||||
- 一级指标：数据中台直接产出，核心指标（提供给公司高层看的）、原子指标以及跨部门的派生指标。
|
||||
- 二级指标：基于中台提供的原子指标，业务部门创建的派生指标。
|
||||
|
||||
不同等级的指标意味着管理方式不同：
|
||||
|
||||
- 一级指标，要确保指标按时、保证质量产出，指标创建由中台负责；
|
||||
- 二级指标，允许业务方自己创建，中台不承诺指标的产出时间和质量。
|
||||
|
||||
现在你了解如何管理指标了吗？ 我建议你在学完这部分知识以后，结合自己所在的业务，找一些指标，试着按照上面的方法实践一下，这样掌握得会加更深刻。
|
||||
|
||||
## 指标系统
|
||||
|
||||
在了解如何管理指标之后，我们还需要一款好用的工具，帮助我们落实管理方法。我观察到，很多公司喜欢用Excel管理指标，觉得Excel 上手容易，编辑比较方便。在我看来，Excel并不是一个适合指标管理的工具，有这样几个原因：
|
||||
|
||||
- 难于共享；
|
||||
- 缺少权限控制；
|
||||
- 无法动态更新；
|
||||
- 指标无法跟数仓的模型动态关联。
|
||||
|
||||
所以，我们需要一个面向指标的管理系统。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b3/64/b39e3317ec1c4b52828ce480ab1cfd64.jpg" alt="">
|
||||
|
||||
指标系统是基于元数据中心构建的一个指标管理工具，它从元数据中心自动同步数仓的主题域和业务过程，按照规范化定义创建指标。
|
||||
|
||||
新创建的指标同时会以特定类型的标签，下沉到元数据中心对应的表和字段上，这样在数据地图上就可以搜索到表关联的指标。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/5f/3c/5f0e0df7a3ddaedc674d22b0a796fe3c.jpg" alt="">
|
||||
|
||||
指标系统还提供了按照指标名称、标识、业务口径的检索功能。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f9/b8/f90eab6cf97b35bb750515321c5ab3b8.jpg" alt="">
|
||||
|
||||
既然指标系统能够实现指标的规范化定义，帮你解决“如何系统化、规范化定义指标”的问题，那接下来我们的重点就是如何基于指标系统构建全局的指标字典，因为这是指标治理的最终结果。
|
||||
|
||||
## 基于指标系统构建全局的指标字典
|
||||
|
||||
指标治理的最终结果，就是要形成一个全局业务口径一致的指标字典。让使用指标的人，可以通过指标字典，快速了解指标的业务含义和计算过程，不会对指标口径产生歧义。
|
||||
|
||||
数据中台团队必须要有一个专门负责指标管理的人或者小组（一般不超过3个人），最好是数据产品经理来负责，**如果你的公司没有这个职位，也可以让分析师承担（前提是分析师必须属于中台团队）。**
|
||||
|
||||
构建全局的指标字典分为两个场景：
|
||||
|
||||
- 一个是面对一个新的指标需求，如何基于指标系统完成指标开发流程；
|
||||
- 另外一个是面对已经存在的，混乱的指标现状，如何进行全局梳理。
|
||||
|
||||
先来看第一个场景。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/34/c0/3435009bc51ed4488eb233ee0ed634c0.jpg" alt="">
|
||||
|
||||
这个图详细地描述了新建指标的流程，流程中参与的各个角色。我在这里想强调几点：
|
||||
|
||||
<li>
|
||||
指标需求评审，需要需求方、数据开发、应用开发都参加。评审首先要确认这是不是一个新的指标，并明确它是原子指标还是派生指标。评审的目的就是要大家达成一致。
|
||||
</li>
|
||||
<li>
|
||||
评审的结果一种是不需要开发，是一个已经存在的指标，直接可以通过设计逻辑模型（具体我会在数据服务章节讲），发布接口，获取数据。第二种就是需要开发。前者交付时间短，后者需要排期，交付时间长。
|
||||
</li>
|
||||
<li>
|
||||
上面我提到指标有一级和二级之分，这个流程适用于一级指标，对于二级指标，可以不需要评审，当然开发也是由业务方开发和发布上线。
|
||||
</li>
|
||||
|
||||
接下来，我们来看第二个场景。
|
||||
|
||||
除了新建指标的流程，对于很多公司，已经有一定的大数据业务，但是还不能算是一个中台，那这部分公司该如何进行一次全局的指标梳理呢？我认为应该有以下几个步骤：
|
||||
|
||||
1. 成立以数据产品或者分析师为核心的1～3人的工作小组，专门负责指标的全局梳理；
|
||||
1. 制定指标梳理计划，明确指标梳理目标，覆盖多少个业务线，与业务方共同制定时间计划；
|
||||
1. 对于每一个业务线，需要对还在使用的数据报表、数据产品进行盘点，这里顺便可以把没用的报表和数据产品应该下线；
|
||||
1. 对于每一个报表和数据产品中涉及的指标，按照以下格式进行收集；
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/5c/42/5cfabaa4ca599ae827f41a98850ae142.jpg" alt="">
|
||||
|
||||
1. 对于收集的指标，明确业务口径，对于口径相同的，应该去除重复，关联的应用应该合并，此时以我的经验，可以过滤掉相当一部分；
|
||||
1. 根据指标业务口径，明确指标所属的主题域、业务过程；
|
||||
1. 区分指标类型，对于派生指标，要明确指标的统计粒度、修饰词、时间周期以及关联的原子指标；
|
||||
1. 按照指标系统对指标的规范化定义，把整理好的指标录入指标系统。
|
||||
|
||||
通过全局的梳理和新建指标流程的管控，你就可以构建一个全局一致的指标字典了。
|
||||
|
||||
## 课堂总结
|
||||
|
||||
本节课，我带你了解了如何构建全局一致的指标字典，通过系统+规范的方法，帮你解决了数据中台指标一致性管理的难题，我想再强调几个点：
|
||||
|
||||
- 数据中台直接产出的核心指标必须实施强管理，由数据中台团队的专人或者小组负责，最好是数据产品经理的角色。
|
||||
- 指标的管理必须结合系统+规范的治理方法，明确每个角色的职责，通过系统化的方法实现。
|
||||
- 不同的两个指标描述的相同业务过程中的相同事实部分口径不一致，是指标梳理过程中最常见的问题，需要通过拆分原子指标和派生指标的方式解决。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a6/d7/a6b5d401cb6fe286dd26302096488ad7.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
在课程的最后，还是留给你一个思考题。在一个企业的指标字典中，你觉得应该原子指标多，还是派生指标多？原因是什么呢？欢迎在留言区留言。
|
||||
|
||||
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。
|
||||
200
极客时间专栏/geek/数据中台实战课/实现篇/06 | 数据模型无法复用，归根结底还是设计问题.md
Normal file
200
极客时间专栏/geek/数据中台实战课/实现篇/06 | 数据模型无法复用，归根结底还是设计问题.md
Normal file
@@ -0,0 +1,200 @@
|
||||
<audio id="audio" title="06 | 数据模型无法复用，归根结底还是设计问题" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d7/a1/d764a95e81227dfa4d693338aaaaf0a1.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
上一节课，我带你了解了数据中台如何管理指标，如果我们把指标比喻成一棵树上的果实，那模型就是这棵大树的躯干，想让果实结得好，必须让树干变得粗壮。
|
||||
|
||||
先来看一幕真实的场景。
|
||||
|
||||
大多数公司的分析师会结合业务做一些数据分析（需要用到大量的数据），通过报表的方式服务于业务部门的运营。但是在数据中台构建之前，分析师经常发现自己没有可以复用的数据，不得不使用原始数据进行清洗、加工、计算指标。
|
||||
|
||||
由于他们大多是非技术专业出身，写的SQL 质量比较差，我甚至见过5层以上的嵌套。这种SQL 对资源消耗非常大，会造成队列阻塞，影响其他数仓任务，会引起数据开发的不满。数据开发会要求收回分析师的原始数据读取权限，分析师又会抱怨数仓数据不完善，要啥没啥，一个需求经常要等一周甚至半个月。分析师与数据开发的矛盾从此开始。
|
||||
|
||||
这个矛盾的根源在于数据模型无法复用，数据开发是烟囱式的，每次遇到新的需求，都从原始数据重新计算，自然耗时。而要解决这个矛盾，就要搞清楚我们的数据模型应该设计成什么样子。
|
||||
|
||||
## 什么才是一个好的数据模型设计？
|
||||
|
||||
来看一组数据，这两个表格是基于元数据中心提供的血缘信息，分别对大数据平台上运行的任务和分析查询（Ad-hoc）进行的统计。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/19/2b/19c8925b0107dc7ad298d9bb62971d2b.jpg" alt="" title="表1 离线调度任务/表统计">
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/37/d3/371cfb2754297d211d9cd5b2af48fdd3.jpg" alt="" title="表2 一周内Ad-hoc 查询统计">
|
||||
|
||||
下图是数仓分层架构图，方便你回忆数据模型分层的设计架构：
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/91/d5/9199d1545ecf90454882f01868f68ed5.jpg" alt="">
|
||||
|
||||
我们首先来看表1。表1中有2547张未识别分层的表，占总表6049的40%，它们基本没办法复用。 重点是在已识别分层的读表任务中，ODS：DWD：DWS：ADS的读取任务分别是1072：545：187：433，直接读取ODS 层任务占这四层任务总和的47.9%，这说明有大量任务都是基于原始数据加工，中间模型复用性很差。
|
||||
|
||||
我们再来看看表2，在已识别的分层的查询中，ODS：DWD：DWS：ADS的命中的查询分别是892：1008：152：305，有37.8%的查询直接命中ODS层原始数据，说明DWD、DWS、ADS层数据建设缺失严重。尤其是ADS和DWS，查询越底层的表，就会导致查询扫描的数据量会越大，查询时间会越长，查询的资源消耗也越大，使用数据的人满意度会低。
|
||||
|
||||
最后，我们进一步对ODS层被读取的704张表进行分解，发现有382张表的下游产出是DWS，ADS，尤其是ADS达到了323张表，占ODS层表的比例45.8%，说明有大量ODS层表被进行物理深加工。
|
||||
|
||||
**通过上面的分析，我们似乎已经找到了一个理想的数仓模型设计应该具备的因素，那就是“数据模型可复用，完善且规范”。**
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/d6/b3/d6b10b27dfa4e4cff5a2ca496bd1fbb3.jpg" alt="">
|
||||
|
||||
### 如何衡量完善度
|
||||
|
||||
**DWD 层完善度：**衡量DWD层是否完善，最好看ODS层有多少表被DWS/ADS/DM层引用。因为DWD以上的层引用的越多，就说明越多的任务是基于原始数据进行深度聚合计算的，明细数据没有积累，无法被复用，数据清洗、格式化、集成存在重复开发。因此，我提出用跨层引用率指标衡量DWD的完善度。
|
||||
|
||||
>
|
||||
跨层引用率：ODS层直接被DWS/ADS/DM层引用的表，占所有ODS层表（仅统计活跃表）比例。
|
||||
|
||||
|
||||
跨层引用率越低越好，在数据中台模型设计规范中，我们要求不允许出现跨层引用，ODS层数据只能被DWD 引用。
|
||||
|
||||
**DWS/ADS/DM 层完善度：**考核汇总数据的完善度，我认为主要看汇总数据能直接满足多少查询需求（也就是用汇总层数据的查询比例衡量）。如果汇总数据无法满足需求，使用数据的人就必须使用明细数据，甚至是原始数据。
|
||||
|
||||
>
|
||||
汇总数据查询比例：DWS/ADS/DM层的查询占所有查询的比例。
|
||||
|
||||
|
||||
你要明确的是，这个跟跨层引用率不同，汇总查询比例不可能做到100%，但值越高，说明上层的数据建设越完善，对于使用数据的人来说，查询速度和成本会减少，用起来会更爽。
|
||||
|
||||
### 如何衡量复用度
|
||||
|
||||
数据中台模型设计的核心是追求模型的复用和共享，通过元数据中心的数据血缘图，我们可以看到，一个比较差的模型设计，自下而上是一条线。而一个理想的模型设计，它应该是交织的发散型结构。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/e4/97/e4038beaead8be1db13aa1c7299c2a97.jpg" alt="">
|
||||
|
||||
我提出用模型引用系数作为指标，衡量数据中台模型设计的复用度。引用系数越高，说明数仓的复用性越好。
|
||||
|
||||
>
|
||||
模型引用系数：一个模型被读取，直接产出下游模型的平均数量。
|
||||
|
||||
|
||||
比如一张DWD层表被5张DWS 层表引用，这张DWD层表的引用系数就是5，如果把所有DWD层表（有下游表的）引用系数取平均值，则为DWD层表平均模型引用系数，一般低于2比较差，3以上相对比较好（经验值）。
|
||||
|
||||
### 如何衡量规范度
|
||||
|
||||
表1中，超过40%的表都没有分层信息，在模型设计层面，这显然是不规范的。除了看这个表有没有分层，还要看它有没有归属到主题域（例如交易域）如果没有归属主题域，就很难找到这张表，也无法复用。
|
||||
|
||||
其次，你要看表的命名。拿stock这个命名为例，当你看到这个表时，知道它是哪个主题域、业务过程？是全量数据的表，还是每天的增量数据？总的来说，通过这个表名获取的信息太有限了。一个规范的表命名应该包括主题域、分层、表是全量快照，还是增量等信息。
|
||||
|
||||
除此之外，如果在表A中用户ID的命名是UserID，在表B中用户ID 命名是ID，就会对使用者造成困扰，这到底是不是一个东西。所以我们要求相同的字段在不同的模型中，它的命名必须是一致的。
|
||||
|
||||
**讲了这么多，你要如何吸收经验呢？在这里，我给你几点建议。**
|
||||
|
||||
- 你可以拿着这些指标去评估一下，自己的数仓现状如何。
|
||||
- 然后制订一些针对性的改进计划，比如把这些不规范命名的表消灭掉，把主题域覆盖的表比例提高到90%以上。
|
||||
- 在尝试完一段时间的模型重构和优化后，再拿着这些指标去测一测是不是真的变好了。我见过很多数据开发在向上级汇报工作时，喜欢用重构了多少模型说明工作成果，很多老大会想，这些重构到底对数据建设有多少帮助？有没有一些量化的指标可以衡量？**我想有上面的知识，你可以应对这个问题了。**
|
||||
|
||||
现在你知道什么是好的数仓设计了，可目前已经存在了大量烟囱式开发，具体怎么做才能让它变成一个数据中台呢？
|
||||
|
||||
## 如何从烟囱式的小数仓到共享的数据中台
|
||||
|
||||
建设数据中台本质就是构建企业的公共数据层，把原先分散的、烟囱式的、杂乱的小数仓，合并成一个可共享、可复用的数据中台（我在[03讲](https://time.geekbang.org/column/article/220290)提到过，建议你回顾一下）。结合我在网易的实践经验，我给你几点建议。
|
||||
|
||||
**第一，接管ODS层，控制源头。**
|
||||
|
||||
ODS是业务数据进入数据中台的第一站，是所有数据加工的源头，控制住源头，才能从根本上防止一个重复的数据体系的出现。
|
||||
|
||||
数据中台团队必须明确职责，全面接管ODS 层数据，从业务系统的源数据库权限入手，确保数据从业务系统产生后进入数据仓库时，只能在数据中台保持一份。这个可以跟业务系统数据库管理者达成一致，只有中台团队的账号才能同步数据。
|
||||
|
||||
ODS层表的数据必须和数据源的表结构、表记录数一致，高度无损，对于ODS 层表的命名采用ODS_业务系统数据库名_业务系统数据库表名方式，比如ods_warehous_stock，warehous是业务系统数据库名，stock是该库下面的表名。
|
||||
|
||||
**第二，划分主题域，构建总线矩阵。**
|
||||
|
||||
主题域是业务过程的抽象集合。可能这么讲，稍微有点儿抽象，但其实业务过程就是企业经营过程中一个个不可拆分的行为事件，比如仓储管理里面有入库、出库、发货、签收，都是业务过程，抽象出来的主题域就是仓储域。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/17/cc/1724055dd6eb3911cee9084d9a674ecc.jpg" alt="" title="表3 电商业务的主题域划分">
|
||||
|
||||
主题域划分要尽量涵盖所有业务需求，保持相对稳定性，还具备一定的扩展性（新加入一个主题域，不影响已经划分的主题域的表）。
|
||||
|
||||
主题域划分好以后，就要开始构建总线矩阵，明确每个主题域下的业务过程有哪些分析维度，举个例子：
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/34/ec/348e85b3a97e90345df4bce09cbf5aec.jpg" alt="" title="表4 交易域的总线矩阵">
|
||||
|
||||
**第三，构建一致性维度。**
|
||||
|
||||
售后团队的投诉工单数量有针对地区的分析维度，而配送团队的配送延迟也有针对地区的分析维度，你想分析因为配送延迟导致的投诉增加，但是两个地区的分析维度包含内容不一致，最终会导致一些地区没办法分析。所以我们构建全局一致性的维表，确保维表只存一份。
|
||||
|
||||
**维度统一的最大的难题在于维度属性（如果维度是商品，那么商品类别、商品品牌、商品尺寸等商品的属性，我们称为维度属性）的整合。**是不是所有维度属性都要整合到一个大的维表中，也不见得，我给你几个建议。
|
||||
|
||||
<li>
|
||||
公共维度属性与特有维度属性拆成两个维表。在自营平台中，通常也会有一些第三方的商家入驻，但是数量很少。大部分商品其实都没有店铺的属性，这种情况，就不建议将店铺和商品的其他维度属性，比如商品类别、品牌设计成一个维表。
|
||||
</li>
|
||||
<li>
|
||||
产出时间相差较大的维度属性拆分单独的维表，比如有些维度属性产出时间在凌晨2点，有些维度属性产出时间在凌晨6点，那2点和6点的就可以拆成两个维表，确保核心维表尽早产出。
|
||||
</li>
|
||||
<li>
|
||||
出于维表稳定性产出的考虑，你可以将更新频繁的和变化缓慢的进行拆分，访问频繁的和访问较少的维表进行拆分。
|
||||
</li>
|
||||
|
||||
对于维表的规范化命名，建议你用“DIM_主题域_描述_分表规则”方式。**分表你可以这样理解：**一个表存储几千亿行记录实在是太大了，所以需要把一个表切割成很多小的分区，每天或者每周，随着任务被调度，会生成一个分区。我提供给你一个常见的分区规则（这个规则你在用的时候，查阅就可以了）。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ff/b9/ff40520c4716d28ca0d220a997f819b9.jpg" alt="">
|
||||
|
||||
**第四，事实表整合。**
|
||||
|
||||
我觉得事实表整合遵循的最基本的一个原则是，统计粒度必须保持一致，不同统计粒度的数据不能出现在同一个事实表中。来看一个例子：
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/78/97/789d5b5f83405eba77e8cdbb6b1ce997.jpg" alt="">
|
||||
|
||||
在数据中台构建前，供应链部门、仓储部门和市场部门都有一些重复的事实表，我们需要将这些重复的内容进行去除，按照交易域和仓储域，主题域的方式进行整合。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/cb/55/cb15353c0724c59ab0b24b64057cb055.jpg" alt="">
|
||||
|
||||
对于仓储部门和供应链部门都有的库存明细表，因为仓储部门的统计粒度是商品加仓库，而供应链部门的只有商品，所以原则上两个表是不能合并，而是应该独立存在。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/fe/5b/fe81e5b9a4f290563b850d73022a865b.jpg" alt="">
|
||||
|
||||
对于市场部门和供应链部门的两张下单明细表，因为统计粒度都是订单级别，都归属于交易域下的下单业务过程，所以可以合并为一张事实表。
|
||||
|
||||
除此之外，还应该考虑将不全的数据补齐。对于ODS 层直接被引用产出DWS/ADS/DM层的任务，通过血缘，找到任务清单，逐个进行拆解。没有ODS对应的DWD的，应该生成DWD表，对于已经存在的，应该迁移任务，使用DWD层表。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c3/c5/c3f514d99386ad2731f4d50d8b3ed8c5.jpg" alt="">
|
||||
|
||||
DWD/DWS/ADS/DM的命名规则适合采用“[层次][主题][子主题][内容描述][分表规则]”的命名方式。
|
||||
|
||||
**第五，模型开发。**
|
||||
|
||||
模型设计完成后，就进入模型开发阶段，我想提几个你需要注意的点：
|
||||
|
||||
1. 所有任务都必须严格配置任务依赖，如果没有配置任务依赖，会导致前一个任务没有正常产出数据的情况下，后一个任务被调度起来，基于错误的数据空跑，浪费资源，同时增加了排查故障的复杂度；
|
||||
1. 任务中创建的临时表，在任务结束前应该删除，如果不删除，会发现有大量的临时表存在，占用空间；
|
||||
1. 任务名称最好跟表名一致，方便查找和关联；
|
||||
<li>生命周期的管理，对于ODS和DWD，一般尽可能保留所有历史数据，对于<br>
|
||||
DWS/ADS/DM 需要设置生命周期，7～30天不等；</li>
|
||||
1. DWD 层表宜采用压缩的方式存储，可用lzo压缩。
|
||||
|
||||
**第六，应用迁移。**
|
||||
|
||||
最后一步就是应用的迁移，这个过程的核心是要注意数据的比对，确保数据的完全一致，然后进行应用迁移，删除老的数据表。
|
||||
|
||||
总的来说，建设数据中台不是一口气就能吃成一个胖子，它的建设往往是滚雪球的方式，随着一个个应用的迁移，中台的数据也越来越丰满，发挥的价值也越来越大。
|
||||
|
||||
## 数仓建模工具EasyDesign
|
||||
|
||||
当然了，这些步骤的实现，离不开一个好用的工具作为支撑，为了规范化数据模型的设计，我们研发了EasyDesign的模型设计产品，让这些流程实现系统化管理。而我希望你了解如何去设计这个工具，或者在选用工具的时候应该考虑有哪些功能。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/74/b5/74c84414f5e004cbc1351c6e77d1e0b5.jpg" alt="">
|
||||
|
||||
EasyDesign 构建于元数据中心之上，通过API调用元数据中心的数据血缘接口，结合数仓模型设计的指标，给出了模型设计度量。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/64/04/6493f76676d8d40beb8a84c2554d0a04.jpg" alt="">
|
||||
|
||||
EasyDesign按照主题域、业务过程、分层的方式管理所有的模型。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/50/bc/50849628d758e95666ee5d3cce9ed7bc.jpg" alt="">
|
||||
|
||||
它还提供了维度、度量和字段基础字典的管理，同时具备模型设计审批流程的控制。
|
||||
|
||||
## 课堂总结
|
||||
|
||||
本节课，我结合自己的经验，带你了解了数据中台的模型设计。从确立设计目标，到通过一系列步骤，将一个个分散的、杂乱的、烟囱式的小数仓逐步规整到一个可复用、可共享的数据中台，最后通过产品化的方式实现系统化的管理。在最后，我想再强调几个点：
|
||||
|
||||
- 完善度、复用度和规范度构成了衡量数据中台模型设计的度量体系，可以帮助你评估数仓设计的好坏。
|
||||
- 维度设计是维度建模的灵魂，也是数据中台模型设计的基础，维度设计的核心是构建一致性维度。
|
||||
- 事实表的统计粒度必须保持一致，不同统计粒度的数据不能出现在同一个事实表中。
|
||||
|
||||
你要知道，数据中台的构建往往需要花费半年甚至一年以上的时间，但是数据中台建成后，对研发效率的提升效果非常明显，在网易电商业务中，中台构建后相比构建前，数据需求的平均交付时间从一周缩短到3天内，需求响应速度的提升，为企业运营效果提升提供了数据支撑。我相信通过数据中台的构建，你所在企业的数据研发效率也会得到大幅度的提升。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/05/4b/056037d1806f48243643a3689a89e14b.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
在数据中台实际实施落地的过程中，数据团队不但要建设公共数据层，形成数据中台，还要承担着巨大的新需求的压力。而且，往往需求的优先级都高于建设公共数据层的优先级，导致中台建设的进度难以保障。 对这个问题，你有什么解决方法呢？
|
||||
|
||||
最好，感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的朋友。
|
||||
188
极客时间专栏/geek/数据中台实战课/实现篇/07 | 同事老打脸说数据有问题，该怎么彻底解决？.md
Normal file
188
极客时间专栏/geek/数据中台实战课/实现篇/07 | 同事老打脸说数据有问题，该怎么彻底解决？.md
Normal file
@@ -0,0 +1,188 @@
|
||||
<audio id="audio" title="07 | 同事老打脸说数据有问题，该怎么彻底解决？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d5/ff/d5e4d5efdb448eefd3f46f61ca7cd7ff.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
上一节课，我带你从模型设计层面，逐步将分散、杂乱、烟囱式的小数仓整合成了可复用、可共享的数据中台，数据研发效能提升了一倍。那是不是交付数据足够快，使用数据的人就满意了？ 当然不是，来看发生在我身边的一件事儿。
|
||||
|
||||
供应链部门运营陈英俊（化名）每天上班第一件事情，就是打开供应链辅助决策系统（数据产品），根据系统上给出的商品库存数据、区域下单数据，制订商品的采购计划，然后发送给供货商。可是今天当他准备工作时，突然发现系统中部分商品库存数据显示为0，他第一时间将问题反馈给了数据部门。与此同时，与他一样无法工作的还有供应链部门的其他50多名运营。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/bc/7d/bcd45f4e938efe5e215e505f3e4f0b7d.jpg" alt="" title="图1 ADS层商品库存表加工链路图">
|
||||
|
||||
接到投诉后，负责库存域的数据开发郝建（化名）立即开始定位，首先就“商品库存”指标的产出表ads_wms_sku_stock_1d进行排查，确认它产出任务没有问题，是这个任务的上游输入表数据有问题，引发下游表数据异常。
|
||||
|
||||
从数据血缘图中你可以看到，ads_wms_sku_stock_1d上游有20多张表，郝建逐层校验是哪个表的数据出现问题，结果锁定在了dwd_wms_inbound_stock_df。这张表的产出任务在前一天有一次线上变更，任务代码存在漏洞，对部分商品入库数据格式解析异常，但是没有将异常抛出，导致产出数据表dwd_wms_inbound_stock_df 数据异常，进而影响了所有下游表。
|
||||
|
||||
排查问题用了近3个小时。
|
||||
|
||||
既然问题定位清楚，就要开始修复的流程。修改好代码后，郝建重新跑了dwd_wms_inbound_stock_df的产出任务，确认数据没有问题，然后需要重跑该任务下游链路上的5个任务（图中红色表的产出任务）。
|
||||
|
||||
运行完任务用了5个小时。
|
||||
|
||||
经过数据验证，确认没有问题，此时已经过去了将近9个小时。对于像陈英俊这样的运营来说，一天都无法工作。如果你是陈英俊， 对数据会满意吗？**所以，光快还不够，还要保证质量。**
|
||||
|
||||
当然，这个例子暴露出这样几个问题：
|
||||
|
||||
- 数据部门晚于业务方发现数据异常，被投诉后才发现问题。
|
||||
- 出现问题后，数据部门无法快速定位到数据异常的根源，排查用了较长的时间。
|
||||
- 故障出现在数据加工链路的上游顶端，出现问题没有第一时间报警处理，导致问题修复时，所有下游链路上的任务都要运行，修复时间成本非常高。
|
||||
|
||||
**这些问题最终导致了数据长时间不可用。**那如何解决这些问题，确保数据高质量的交付呢？ 首先，你要了解产生这些问题的根源，毕竟认识问题才能解决问题。
|
||||
|
||||
## 数据质量问题的根源
|
||||
|
||||
在网易电商业务数据中台构建之初，我对数据团队一年内，记录在案的321次数据质量事件做了逐一分析，对这些事件的原因进行了归纳，主要有下面几类。这里多说一句，如果你想改进数据质量，不妨也对过去踩过的坑做一次复盘，归一下类，看看问题都出在哪里，然后制定针对性的改进计划。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/91/68/9191c7dd526022341edaf98c5be2be68.jpg" alt="">
|
||||
|
||||
#### 业务源系统变更
|
||||
|
||||
数据中台的数据来源于业务系统，而源系统变更一般会引发3类异常情况，
|
||||
|
||||
**首先是源系统数据库表结构变更。**例如业务系统新版本发布上线，对数据库进行了表结构变更，增加了一个字段，同时对部分字段的类型、枚举值进行了调整。这种表结构变更没有通知到数据团队，导致数据同步任务或者数据清洗任务异常，进而影响了下游数据产出。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/5d/2c/5d679674ecb108d152251d1777c8722c.jpg" alt="" title="图2 日志服务器扩容误操作引发数据异常">
|
||||
|
||||
**第二个是源系统环境变更。**我经常在大促期间见到这种情况，其中的典型是前端用户行为埋点日志量暴增，系统管理员紧急对服务器进行扩容，上线了5台新的服务器，但是没有配置这5台服务器的日志同步任务，结果导致数据侧少了这5台服务器的数据，最终影响了数据计算结果的准确性。
|
||||
|
||||
**最后一个是源系统日志数据格式异常。**这种情况通常出现在前后端埋点日志中。业务系统发布上线引入埋点BUG，导致IP格式出现了不符合约定的格式（比如，我们一般约定的IP格式是166.111.4.129，结果出现了166.111.4.null），最终也会导致计算结果错误。
|
||||
|
||||
#### 数据开发任务变更
|
||||
|
||||
这种情况在数据质量事件中占到了60%以上，而它大多数是由于数据开发的纰漏引发的，来看几个你比较熟悉的例子：
|
||||
|
||||
- 任务发布上线，代码中引用的测试库没有修改为线上库，结果污染了线上数据；
|
||||
- 任务发布上线，代码中使用了固定分区，没有切换为“${azkaban.flow.1.days.ago}”，导致数据异常；
|
||||
- 前面例子中，数据格式处理错误，代码忽略了异常，导致数据错误；
|
||||
- 任务配置异常，它通常表现在任务没有配置依赖，前一个任务没有运行完，后一个任务就开始运行，输入数据不完整，导致下游数据产出错误。
|
||||
|
||||
#### 物理资源不足
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c4/89/c45309ce7dcc381aab2c5f4ca770f589.jpg" alt="" title="图3 Hadoop多队列任务提交">
|
||||
|
||||
在多租户下，Hadoop生态的大数据任务（MR，Hive，Spark）一般运行在yarn管理的多个队列上（调度器为CapacityScheduluer），每个队列都是分配了一定大小的计算资源（CPU、内存）。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c1/41/c1e5cdb298ff76bc0b68dce656190541.jpg" alt="" title="图4 物理资源不足导致任务延迟">
|
||||
|
||||
我展示了两种常见的物理资源不足，导致任务延迟产出的情况。
|
||||
|
||||
#### 基础设施不稳定
|
||||
|
||||
从数量上来看，这类异常不算多，但影响却是全局性的。我们曾经在大促期间，碰到了一个[Hadoop 2.7 NameNode的BUG，](https://issues.apache.org/jira/browse/HDFS-10453)造成HDFS整个服务都停止读写，最终通过临时补丁的方式才修复。
|
||||
|
||||
总的来说，出现问题并不可怕，可怕的是，我们没有及时发现问题，尽快恢复服务，举一反三地通过流程和技术手段，降低问题出现的概率。所以接下来我们就来看一看，如何提高数据质量？
|
||||
|
||||
## 如何提高数据质量？
|
||||
|
||||
我认为，要想提升数据质量，最重要的就是“早发现，早恢复”：
|
||||
|
||||
- 早发现，是要能够先于数据使用方发现数据的问题，尽可能在出现问题的源头发现问题，这样就为“早恢复”争取到了大量的时间。
|
||||
- 早恢复，就是要缩短故障恢复的时间，降低故障对数据产出的影响。
|
||||
|
||||
那具体如何做到这两个早呢？我总结了一套数据质量建设的方法，包括这样几个内容。
|
||||
|
||||
#### 添加稽核校验任务
|
||||
|
||||
在数据加工任务中，对产出表按照业务规则，设计一些校验逻辑，确保数据的完整性、一致性和准确性，这是提升数据质量最行之有效的方法。
|
||||
|
||||
通常建议你在数据产出任务运行结束后，启动稽核校验任务对数据结果进行扫描计算，判断是否符合规则预期。如果不符合，就根据提前设定的强弱规则，触发不同的处理流程。
|
||||
|
||||
如果是强规则，就立即终止任务加工链路，后续的任务不会执行，并且立即发出电话报警，甚至我们要求，关键任务还要开启循环电话报警，直到故障被认领；如果是弱规则，任务会继续执行。但是存在风险，这些风险会通过邮件或者短信的方式，通知到数据开发，由人来进一步判断风险严重程度。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/06/ea/06243ebbbfa6b46fc61803c84cb8edea.jpg" alt="" title="图5 稽核校验执行流程图">
|
||||
|
||||
那具体要加哪些稽核规则呢？
|
||||
|
||||
<li>
|
||||
**完整性规则。**主要目的是确保数据记录是完整的，不丢失。常见的稽核规则有表数据量的绝对值监控和波动率的监控（比如表波动超过20%，就认为是异常）。还有主键唯一性的监控，它是判断数据是否有重复记录的监控规则，比较基础。除了表级别的监控，还有字段级别的监控（比如字段为0、为NULL的记录）。
|
||||
</li>
|
||||
<li>
|
||||
**一致性规则。**主要解决相关数据在不同模型中一致性的问题。商品购买率是通过商品购买用户数除以商品访问uv计算而来的，如果在不同的模型中，商品购买用户数是1W、商品访问uv10W，商品购买率20%，那这三个指标就存在不一致。
|
||||
</li>
|
||||
<li>
|
||||
**准确性规则。**主要解决数据记录正确性的问题。常见的稽核规则有，一个商品只能归属在一个类目，数据格式是不是正确的IP格式，订单的下单日期是还没有发生的日期等等。
|
||||
</li>
|
||||
|
||||
它们是强规则还是弱规则，取决于业务对上述异常的容忍度（比如涉及到交易、支付跟钱相关的，一般都会设置为强规则，对于一些偏行为分析的，一般都是弱规则）。
|
||||
|
||||
#### 建立全链路监控
|
||||
|
||||
在06讲中，我强调数据中台的模型设计是分层的，确保中间结果可以被多个模型复用。
|
||||
|
||||
不过这会导致数据加工的链路变长，加工链路的依赖关系会非常复杂，最终当下游表上的某个指标出现问题，排查定位问题的时间都会比较长。**所以，我们有必要基于数据血缘关系，建立全链路数据质量监控。**
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/4e/02/4e2f5518a2273a0295352eae7f2a4c02.jpg" alt="" title="图6 全链路数据质量监控">
|
||||
|
||||
从这个图中你可以看到，业务系统的源数据库表是起点，经过数据中台的数据加工链路，产出指标“黑卡会员购买用户数”，数据应用是链路的终点。
|
||||
|
||||
对链路中每个表增加稽核校验规则之后，当其中任何一个节点产出的数据出现异常时，你能够第一时间发现，并立即修复，做到早发现、早修复。另外，即使是使用方反馈经营分析上的黑卡会员购买用户数，相较于昨天数据大幅下降超过30%，你也可以快速判定整个指标加工链路上节点是否运行正常，产出任务是否有更新，提高了问题排查速度。
|
||||
|
||||
#### 通过智能预警，确保任务按时产出
|
||||
|
||||
在数据质量问题中，我提到会存在物理资源不足，导致任务产出延迟的情况。在网易，所有数据中台产出的指标要求6点前产出。为了实现这个目标，我们需要对指标加工链路中的每个任务的产出时间进行监控，基于任务的运行时间和数据血缘，对下游指标产出时间进行实时预测，一旦发现指标无法按时产出，则立即报警，数据开发可以终止一些低优先级的任务，确保核心任务按时产出。
|
||||
|
||||
#### 通过应用的重要性区分数据等级，加快恢复速度
|
||||
|
||||
稽核校验会消耗大量的资源，所以只有核心任务才需要。核心任务的定义是核心应用（使用范围广、使用者管理级别高）数据链路上的所有任务。
|
||||
|
||||
#### 规范化管理制度
|
||||
|
||||
讲到这儿，你可能会问：数据质量取决于稽核规则的完善性，如果数据开发没有添加，或者添加的规则不全，是不是就达不到早发现、早恢复？
|
||||
|
||||
这个问题戳中了要害，就是规则的完备性如何来保障。在我看来，这不仅仅是一个技术问题，也涉及管理。在网易，我们会制定一些通用的指导规则（比如，所有数据中台维护的表都需要添加主键唯一性的监控规则），但这些通用规则往往与业务关系不大。如果涉及业务层面，就要由数据架构师牵头，按照主题域、业务过程，对每个表的规则进行评审，决定这些规则够不够。
|
||||
|
||||
那我想建议你，如果要做稽核校验，可以通过组建数据架构师团队，由这个团队负责核心表的规则审核，确保规则的完备性。
|
||||
|
||||
那么当你按照这几个方法建立了数据质量体系之后，要如何验证体系是否有效呢?
|
||||
|
||||
## 如何衡量数据质量？
|
||||
|
||||
做数据治理，我一直奉行“效果可量化”的原则，否则这个治理做到什么程度，很难衡量。那么如何评价数据质量是否有改进呢？除了故障次数，你还可以有这样几个指标。
|
||||
|
||||
<li>
|
||||
4点半前数据中台核心任务产出完成率。这个指标是一个综合性指标，如果任务异常，任务延迟，强稽核规则失败，都会导致任务无法在规定时间前产出。
|
||||
</li>
|
||||
<li>
|
||||
基于稽核规则，计算表级别的质量分数。根据表上稽核规则的通过情况，为每个表建立质量分数，对于分数低的表，表负责人要承担改进责任。
|
||||
</li>
|
||||
<li>
|
||||
需要立即介入的报警次数，通常以开启循环报警的电话报警次数为准。对于核心任务，任务异常会触发循环电话报警，接到报警的数据开发需要立即介入。
|
||||
</li>
|
||||
<li>
|
||||
数据产品SLA。每个数据产品上所有指标有没有在9点产出，如果没有，开始计算不可用时间，整体可以按照不同数据产品的重要性进行折算，99.8%是数据产品一个相对比较好的SLA。
|
||||
</li>
|
||||
|
||||
不过，技术和规范最终需要依靠产品来帮助落地，在网易内部，有一个数据质量中心的 产品，通过介绍这个产品，我希望能给你一个参考，如何去设计一个数据质量中心，或者在选型的时候，数据质量中心必须具备的功能。
|
||||
|
||||
## 数据质量中心
|
||||
|
||||
数据质量中心（以下简称DQC）的核心功能是稽核校验和基于数据血缘的全链路数据质量监控。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f3/b1/f39b371750e39eabde620ced05d0f0b1.jpg" alt="">
|
||||
|
||||
DQC的首页是质量大屏，提供了稽核规则的数量、表的覆盖量以及这些规则的执行通过情况。通过这些数据，你就能跟你的老板讲清楚，目前数据质量水平建设如何？目标是多少？距离目标还有多少差距。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/70/ef/702ec67c9cb0f5b572a64af4289c31ef.jpg" alt="">
|
||||
|
||||
在DQC 中创建稽核规则非常简单，DQC 内置了大量的基础规则，例如IP 字段格式校验，主键唯一性校验，表行数波动率校验，同时还提供了自定义SQL的方式，允许业务层面的规则创建，例如我们前面提到的一致性规则中，两个指标相除等于第三个指标，就可以通过自定义SQL解决。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/dd/c6/dd914160281cd1872eedb0717fb6c6c6.jpg" alt="">
|
||||
|
||||
DQC 还提供了全链路监控的功能，覆盖了从数据导入、数据加工、模型产出、指标、到数据应用的完整链路。绿色节点代表数据正常，蓝色节点代表数据正在产出中，红色节点代表数据异常，灰色节点代表产出任务还未被调度到。通过这个监控，大幅提高了问题发现和定位的速度。
|
||||
|
||||
所以你可以发现，一个好用的DQC， 必须要具备的功能就是质量度量、稽核规则管理以及全链路监控。
|
||||
|
||||
## 课堂总结
|
||||
|
||||
本节课，我从数据质量问题的根源入手，带你分析了背后的原因，和五种提高数据质量的方法，在课程结束前，我再强调几个重点：
|
||||
|
||||
- 数据质量治理必须要做到全链路，从业务系统的数据源到指标所在的应用，这样可以提前发现问题，将故障消灭在摇篮中；
|
||||
- 根据应用的优先级和全链路血缘关系，圈定核心任务，要确保核心任务的稽核规则全覆盖，优先保障核心任务的按时产出，在资源紧缺时，有必要停止非核心任务；
|
||||
- 稽核规则的完备性，可以通过数据架构师团队对每个域下的核心表进行评审的方式保障，同时问题回溯和复盘，也可以不断地完善。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/33/6c/33c40b8caedcd08edf50efeddbe6f26c.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
我提到数据完整性可以通过数据记录的波动率来监控，如果超过20%的波动，应该被视为异常。但是你有没有想过，这种也存在误判的情况，尤其是在双十一大促期间，大概率数据稽核规则都是异常的，此时你又该怎么办？
|
||||
|
||||
最后，感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的人。
|
||||
259
极客时间专栏/geek/数据中台实战课/实现篇/08 | 交付速度和质量问题解决了，老板说还得“省”.md
Normal file
259
极客时间专栏/geek/数据中台实战课/实现篇/08 | 交付速度和质量问题解决了，老板说还得“省”.md
Normal file
@@ -0,0 +1,259 @@
|
||||
<audio id="audio" title="08 | 交付速度和质量问题解决了，老板说还得“省”" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c4/fe/c4abadeab2f5be3c9c114513b74223fe.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
在上一节课中，我们讨论了如何保障数据中台的数据质量，让数据做到“准”。我认为，除了“快”和“准”，数据中台还离不开一个“省”字。尤其是随着数据规模越来越大，成本越来越高，如果不能合理控制成本，还没等你挖掘出数据的应用价值，企业利润就已经被消耗完了。
|
||||
|
||||
所以，能否做到精细化的成本管理，关乎数据中台项目的成败。还是分享一个我见过的事儿。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ab/cf/abd782015625ed0497a401b1b2eab7cf.png" alt="" title="某电商业务数据建设资源增长趋势（CU= 1vcpu + 4G memory）">
|
||||
|
||||
这张图展示了某电商平台的大数据资源消耗增长趋势，尤其值得你关注的是，到了2019年，全年的资源规模已经达到了25000CU，全年机器预算达到了3500W。对一个在创业的企业来说，这显然是一笔不小的开支。
|
||||
|
||||
终于有一天，数据团队的负责人李好看（化名）就被CEO叫到了办公室，CEO问了几个问题：
|
||||
|
||||
- 这3500W花在什么业务上？
|
||||
- 你们做了哪些成本优化的举措，效果如何？
|
||||
|
||||
一系列的灵魂拷问，直接把李好看问懵了，他心想：团队的成本是按机器又不是数据应用核算的。在数据中台中，数据应用之间的底层数据是复用的，那具体每个数据产品或者报表花了多少钱，自己没有这样的数据啊，怎么可能知道。
|
||||
|
||||
可对CEO来说，这些问题很重要，因为资源总是有限的，他必须确保资源都用在战略目标的关键节点上。比如，对于电商团队，今年的核心KPI是提升单个注册会员在平台的消费额，那从老板角度来讲，他必须确保资源都投入与KPI相关业务中，例如基于数据对注册会员进行精准化营销，来提升会员在平台的消费额。
|
||||
|
||||
讲到这儿，你可以想一想，自己所在的团队是否发生过类似的事情？ 我相信，数据部门是企业的成本中心，如果要展现自己的价值，一方面是支撑好业务，获得业务的认可；另外一方面就是精简成本，为公司省钱。
|
||||
|
||||
所以，今天我们就把重点放在省钱上，聊一聊数据中台的精细化成本管理。
|
||||
|
||||
## 有哪些成本的陷阱？
|
||||
|
||||
在一开始建设数据中台时，你往往会关注新业务的接入，数据的整合，数据价值的挖掘上，忽略成本管控的问题，从而落入陷阱中，造成成本爆炸式的增长。所以，你有必要深入了解一下有哪些陷阱，从而尽量在日常开发中避免。
|
||||
|
||||
在这里，我总结了8种陷阱，其中：
|
||||
|
||||
- 1~3是广泛存在，但是容易被忽略的，需要你格外注意；
|
||||
- 4~8涉及数据开发中一些技能，你在开发过程中注意一下就可以了。
|
||||
|
||||
除此之外，在学习这部分知识的过程中，我建议你“知其然，更要知其所以然”，这样才能发现问题的本质，从而深入掌握解决问题的方法。
|
||||
|
||||
**第一，数据上线容易下线难。**
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/e5/5d/e5db0e377d41724e387a0d2fc0e8bb5d.png" alt="">
|
||||
|
||||
先来看一组统计数据，这是某数据中台项目，表相关的使用统计。从中你可以发现，有一半的表在30天内都没有访问，而这些表占用了26%的存储空间。如果我们把这些表的产出任务单独拎出来，在高峰期需要消耗5000Core CPU的计算资源，换算成服务器需要125台（按照一台服务器可分配CPU 40Core计算），折合成本一年接近500W。
|
||||
|
||||
是不是觉得自己竟然有这么多没用的数据？我经常把数据比作手机中的图片，我们总是不断地拍照，生成图片，却懒得清理，最终手机里面的存储经常不够用。
|
||||
|
||||
对于无法及时清理数据，数据开发其实也有苦衷。他们并不知道一个表还有哪些任务在引用，还有哪些人在查询，自然不敢停止这个表的数据加工，那造成的后果就是数据上线容易，下线难。
|
||||
|
||||
**第二，低价值的数据应用消耗了大量的资源。**
|
||||
|
||||
我们的数据看上去每天都在被访问，但究竟产出了多少价值，投入和产出是否匹配呢？作为一个数据部门，我们要问一问自己。
|
||||
|
||||
我们曾经有一个宽表（拥有很多列的表，经常出现在数据中台下游的汇总层数据中），算上上游加工链路的任务，每天加工这张宽表要消耗6000块钱，一年要200W，可追查后我们发现，这张宽表实际每天只有一个人在使用，还是一个运营的实习生。显然，投入和产出极不匹配。
|
||||
|
||||
这其实间接说明，数据部门比较关注新的数据产品带给业务的价值，却忽略了已经存在的产品或者报表是否还存在价值，最终导致低价值的应用仍然在大量消耗资源。
|
||||
|
||||
**第三，烟囱式的开发模式。**
|
||||
|
||||
烟囱式的开发不仅会带来研发效率低的问题，同时因为数据重复加工，还会存在资源浪费的问题。我们来算一笔账，一张500T的表，加工这张表，计算任务需要高峰期消耗300Core，折合7台服务器（按照一台服务器可分配CPU 40Core计算），再加上存储盘的成本(按照0.7 元/TB*天计算)，一年需要消耗40W。
|
||||
|
||||
而这张表每复用一次，就可以节省40W的成本。所以通过模型复用，还可以实现省钱的目的。
|
||||
|
||||
**第四，数据倾斜。**
|
||||
|
||||
数据倾斜会让任务性能变差，也会浪费大量的资源，那什么是数据倾斜呢？
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/83/c8/83bb148a5b12651be930df928d170fc8.jpg" alt="" title="单Stage阶段Spark任务数据分片运行图">
|
||||
|
||||
你肯定听说过木桶效应吧？一个木桶装多少水，主要取决于最短的那块板。对于一个分布式并行计算框架来说，这个效应同样存在。对于Spark计算引擎来说，它可以将海量的数据切分成不同的分片（Partition），分配到不同机器运行的任务中，进行并行计算，从而实现计算能力水平扩展。
|
||||
|
||||
但是整个任务的运行时长，其实取决于运行最长的那个任务。因为每个分片的数据量可能不同，每个任务需要的资源也不相同。由于不同的任务不能分配不同的资源，所以，总任务消耗资源=max{单个任务消耗的资源} * 任务数量。这样一来，数据量小的任务会消耗更多的资源，就会造成资源的浪费。
|
||||
|
||||
我们还是举个电商场景的例子。
|
||||
|
||||
假设你需要按照商户粒度统计每个商户的交易金额，此时，我们需要对订单流水表按照商户进行group by计算。在平台上，每个商户的订单交易量实际差距很大，有的订单交易量很多，有的却比较少。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f2/a9/f267e8c7f4d1b03ff464e349cbd98ba9.jpg" alt="">
|
||||
|
||||
我们利用Spark SQL完成计算过程。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/11/0c/1152306e695043efba993f303e31720c.jpg" alt="" title="数据倾斜示意图">
|
||||
|
||||
在上图中，任务A 读取了左边某个分片的数据，按照供应商进行聚合，然后输出给下一个Stage的B、C、D任务。
|
||||
|
||||
你可以看到，聚合后，B、C和D任务输入的数据量有很大的不同，B处理的数据量比C和D多，消耗的内存自然更多，假设单个Executor需要分配16G，而B、C、D不能设置不同的内存大小，所以C和D也都设置了16G。可实际上，按照C和D的数据量，只需要4G就够了。这就造成了C和D 任务资源分配的浪费。
|
||||
|
||||
**第五，数据未设置生命周期。**
|
||||
|
||||
在[06讲](https://time.geekbang.org/column/article/224516)中，我强调，一般原始数据和明细数据，会保留完整的历史数据。而在汇总层、集市层或者应用层，考虑到存储成本，数据建议按照生命周期来管理，通常保留几天的快照或者分区。如果存在大表没有设置生命周期，就会浪费存储资源。
|
||||
|
||||
**第六，调度周期不合理。**
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/91/52/913db7534374e4da5b2bf1a4c2f84052.png" alt="">
|
||||
|
||||
通过这张图你可以看到，大数据任务的资源消耗有很明显的高峰和低谷效应，一般晚上12点到第二天的9点是高峰期，9点到晚上12点，是低谷期。
|
||||
|
||||
虽然任务有明显的高峰低谷效应，但是服务器资源不是弹性的，所以就会出现服务器在低谷期比较空闲，在高峰期比较繁忙的情况，整个集群的资源配置取决于高峰期的任务消耗。所以，把一些不必要在高峰期内运行任务迁移到低谷期运行，也可以节省资源的消耗。
|
||||
|
||||
**第七，任务参数配置。**
|
||||
|
||||
任务参数配置的不合理，往往也会浪费资源。比如在Spark中，Executor 内存设置的过大；CPU设置的过多；还有Spark 没有开启动态资源分配策略，一些已经运行完Task的Executor 不能释放，持续占用资源，尤其是遇到数据倾斜的情况，资源浪费会更加明显。
|
||||
|
||||
**第八，数据未压缩。**
|
||||
|
||||
Hadoop 的HDFS 为了实现高可用，默认数据存储3副本，所以大数据的物理存储量消耗是比较大的。尤其是对于一些原始数据层和明细数据层的大表，动辄500多T，折合物理存储需要1.5P（三副本，所以实际物理存储500**3），大约需要16台物理服务器（一台服务器可分配存储按照12**8T计算），如果不启用压缩，存储资源成本会很高。
|
||||
|
||||
另外，在Hive或者Spark 计算过程中，中间结果也需要压缩，可以降低网络传输量，提高Shuffer (在Hive或者Spark 计算过程中，数据在不同节点之间的传输过程)性能。
|
||||
|
||||
你看，我为你列举了8个典型的成本陷阱，那你可能会问了，老师，我已经中招了，该怎么办呢？ 别急，接下来我们就看一看，如何进行精细化的成本管理。
|
||||
|
||||
## 如何实现精细化成本管理？
|
||||
|
||||
我认为，成本治理应该遵循全局盘点、发现问题、治理优化和效果评估四个步骤。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b7/bb/b72d173eee93d56100bcc7f53da0a1bb.jpg" alt="">
|
||||
|
||||
### 全局资产盘点
|
||||
|
||||
精细化成本管理的第一步，就是要对数据中台中，所有的数据进行一次全面盘点，基于元数据中心提供的数据血缘，建立全链路的数据资产视图。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/fc/64/fc9f418642523cc955ba91575f240064.jpg" alt="">
|
||||
|
||||
从这个图中你可以看到，全链路数据资产视图的下游末端关联到了数据应用（报表：财务分析），而上游的起点是刚进入数据中台的原始数据。数据之间通过任务进行连接。
|
||||
|
||||
接下来，我们要计算全链路数据资产视图中，末端数据的成本和价值（末端数据就是加工链路最下游的表，例如图中TableA，Table G）。
|
||||
|
||||
为什么一定要从末端开始呢？ 因为中间数据，在计算价值的时候，还要考虑下游表被使用的情况，比较难计算清楚，所以我们选择从末端数据开始。这与我们下线表的顺序也是一致的，如果数据的价值很低，成本很高，我们也是从末端数据开始下线的。
|
||||
|
||||
**那么数据成本该如何计算呢？**
|
||||
|
||||
我们要对上图中财务分析报表核算成本，这个报表上游链路中涉及到a，b，c，3个任务，A，B，C，D，E，F， 6张表，那么：
|
||||
|
||||
>
|
||||
这张报表的成本=3个任务加工消耗的计算资源成本+6张表消耗的存储资源的成本。
|
||||
|
||||
|
||||
另外，需要注意的是，如果一个表被多个下游应用复用，那这个表的存储资源成本以及产出任务消耗的成本，需要分摊给多个应用。
|
||||
|
||||
**那价值又该如何计算呢？**
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/e4/63/e4a0117a42386ad9c8bec7a418d89563.jpg" alt="">
|
||||
|
||||
我们来分析一下这张图。
|
||||
|
||||
如果末端数据是一张应用层的表，它对接的是一个数据报表，那衡量这个数据的价值，主要是看报表的使用范围和使用频率。在计算使用范围时，通常用周活来评估，同时还要考虑不同管理级别的人权重，对于老板，他一个人的权重可以相当于1000个普通员工。
|
||||
|
||||
之所以这样设计，是考虑到管理级别越高，做出的商业决策影响就越大，自然这个价值也就越大。使用频率一般使用单个用户每周查看报表的次数来衡量，次数越高，说明报表价值越大。
|
||||
|
||||
如果末端数据对接的不是一个数据报表，而是面向特定场景的数据应用（比如我之前提到过的供应链分析决策系统，它面向的人群主要是供应链部门）。衡量这类产品的价值，主要考虑目标人群的覆盖率和直接业务价值产出。什么是直接业务价值产出呢？，在供应链决策系统中，就是通过系统自动生成的采购订单占所有采购订单的比例。
|
||||
|
||||
除此之外，末端数据，可能还是一张集市层的表，它主要用于提供给分析师做探索式查询。这类表的价值主要看它被哪些分析师使用，使用频率如何。同样，在使用范围评估时，要对分析师按照级别进行加权。
|
||||
|
||||
### 发现问题
|
||||
|
||||
全局盘点，为我们发现问题提供了数据支撑，而你需要重点关注下面三类问题：
|
||||
|
||||
- 持续产生成本，但是已经没有使用的末端数据（“没有使用”一般指30天内没有访问）；
|
||||
- 数据应用价值很低，成本却很高，这些数据应用上游链路上的所有相关数据；
|
||||
- 高峰期高消耗的数据。
|
||||
|
||||
那么为什么你要关注这三类数据呢？
|
||||
|
||||
- 其实第一类就是没有使用，但一直在消耗成本的表，对应的就是我提到的陷阱1。
|
||||
- 第二类其实就是低价值产出，高成本的数据应用，对应的是陷阱2。
|
||||
- 第三类高成本的数据，对应的就是陷阱4～8。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/86/36/86978c0d60e6cc050b1b9fc512221b36.png" alt="">
|
||||
|
||||
陷阱3实际是在第6节模型设计中解决的。
|
||||
|
||||
### 治理优化
|
||||
|
||||
针对这三类问题，我们需要制订相应的策略。
|
||||
|
||||
对于第一类问题，应该对表进行下线。 数据下线要谨慎，你可以参考这张数据下线的执行过程图：
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/9a/3b/9a782afd76ce95cab7e224afb97e123b.jpg" alt="">
|
||||
|
||||
末端数据删除后，原先末端数据的上游数据会成为新的末端数据，同样还要按发现问题到治理优化进行重复，直到所有的末端数据都不满足下线策略为止。
|
||||
|
||||
对第二类问题，我们需要按照应用粒度评估应用是否还有存在的必要。对于报表，可以按照30天内没有访问的应用自动下线的策略，先对报表进行销毁，然后对报表上游的表进行下线，如果该表还被其他的应用引用，就不能下线。**下线步骤可以参考前面的下线步骤。**
|
||||
|
||||
第三类问题，主要是针对高消耗的数据，又具体分为产出数据的任务高消耗和数据存储高消耗。对于产出任务高消耗，首先要考虑是不是数据倾斜。具体怎么判断呢？其实你可以通过MR或者Spark日志中，Shuffer的数据量进行判断。如果有某一个Task 数据量非常大，其他的很少，就可以判定出现了数据倾斜。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/bb/4a/bb6bff0893077c370c812911684ed24a.png" alt="" title="图 Spark task shuffer records">
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ce/62/ce3feb95851ef24d662127dae42cf062.png" alt="" title="图 MR reduce task records">
|
||||
|
||||
如果出现数据倾斜，该如何处理呢？
|
||||
|
||||
数据倾斜的处理方法有很多，不同的场景有一些适用的解决方案：比如在一些大表和小表关联时，Key 分布不均造成的数据倾斜，可以使用mapjoin的方式解决；另外还有一些比较通用的处理方式，例如把热点的Key 进行单独的处理，然后对剩下的Key进行处理，然后对结果进行并集。
|
||||
|
||||
因为它不是本文的重点，所以这里就不再详细展开，之前有一篇美团的文章，对数据倾斜有比较深入的分析，推荐给你做课下学习的[资料。](https://tech.meituan.com/2016/05/12/spark-tuning-pro.html)
|
||||
|
||||
除了数据倾斜，我们还应该检查任务的配置参数。例如对于Spark 执行引擎，Executor 个数是否开的过大，executor-cores和executor-memory是否开的过多，利用率比较低。一般来说，executors-memorty 设置为4G-8G为宜，executor-cores设置为2-4个为宜（这是我们实践过利用率最高的配置选项）。
|
||||
|
||||
另外，你还要考虑任务是否真的有必要在高峰期执行，可以根据集群的负载情况，尽量将任务迁移到非高峰期执行，我将这个步骤称为“削峰填谷”。
|
||||
|
||||
上面几点是产出任务高消耗的情况，那么对于存储消耗比较大的任务，你首先要考虑是否要压缩，尤其是对于原始数据层和明细数据层，建议压缩，压缩的方式有这样几种：
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/9c/fd/9c17d6c8975d68ca3679a201fd05dcfd.jpg" alt="">
|
||||
|
||||
整体来看，对于小文件的压缩，不考虑split，gzip比较合适；对于大文件，推荐使用lzo，支持split，在保证压缩效率的前提下，有着相对稳定的压缩比。
|
||||
|
||||
除此之外，还需要考虑生命周期是否设置：
|
||||
|
||||
- 对于ODS原始数据层和DWD 明细数据层，比较适合用永久保留的策略；
|
||||
- 对于一些商品、用户维表，可以考虑3年或者5年的保留策略。
|
||||
|
||||
整体上，底层表都是长期保留的。所以你的关注重点应该是汇总层以上的表（包括汇总层），一般可以根据数据的重要性，制订7天，1个月的保留策略。
|
||||
|
||||
### 治理效果评估
|
||||
|
||||
现在，通过我介绍的这几个方法，你已经能够节省大量的资源消耗，那如何量化我们的治理成果呢？
|
||||
|
||||
五个字：省了多少钱。不过，如果直接拿服务器的数量来衡量，其实并不能真实地反应治理效果，因为还要考虑业务增长的原因。业务不是停止不动的，所以你可以围绕任务和数据的成本考虑这样几点：
|
||||
|
||||
- 下线了多少任务和数据；
|
||||
- 这些任务每日消耗了多少资源；
|
||||
- 数据占用了多少存储空间。
|
||||
|
||||
拿这些资源来计算成本，这样就能够算出来省了多少钱。我还是拿本节课开始的例子来看，任务A 运行时长 3个小时，在运行过程中，共消耗5384503 cpu*s，37007892 GB *s, 假设我们1个CU （1 cpu， 4g memeory）一年是1300元成本，折合每天为3.5元（计算公式为1300/365）。
|
||||
|
||||
**这里需要特别强调，**不论是优化或者下线任务，我们只统计高峰时间段内，因为优化低峰时间，并不能实际节省资源。
|
||||
|
||||
高峰时间段为8个小时，那折合每秒的费用为0.00012153, 那该任务的费用为max{5384503*0.00012153, 37007892/4 * 0.00012153} = max{654, 1124} = 1124 。那下线这个任务后，就节省1124元，再加上表 A占用的存储空间大小乘以每GB的成本，就可以得出数据表A下线节省的费用。
|
||||
|
||||
## 成本治理中心
|
||||
|
||||
成本治理不是一劳永逸的工作，需要持之以恒，不断发现问题，然后治理优化，建立长久运行机制的前提是必须降低成本治理的门槛，接下来，看一下网易的一个成本治理的平台，EasyCost。<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/94/8d/94acdfab6f168b955d16109748abed8d.png" alt="">
|
||||
|
||||
系统提供了数据诊断的功能，可以按照访问时间、访问频率、关联的应用，设置下线策略，支持一键灰度下线，大幅提高了管理的效率。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/04/f4/047cef40dba74b20b9d97f31d92216f4.png" alt="">
|
||||
|
||||
通过介绍EasyCost，我想告诉你的是，今天的内容，其实可以通过系统化的方式沉淀到产品中，然后通过产品提高管理的效率，从而实现治理机制的长久落地。
|
||||
|
||||
## 课堂总结
|
||||
|
||||
总的来说，通过数据中台，一方面你可以获得大数据作为资产中心带来的红利，另一方面，你也有可能陷入成本的深渊，为野蛮增长的大数据费用买单。
|
||||
|
||||
今天这节课，我从常见的8个成本陷阱入手，带你分析了可能造成成本浪费的原因，然后介绍了精细化成本管理的方法，在最后，我想再强调几个你可能忽略的点：
|
||||
|
||||
<li>
|
||||
无用数据的下线应该从全链路数据资产视图的末端入手，然后抽丝剥茧，一层一层，向数据加工链路的上游推进。
|
||||
</li>
|
||||
<li>
|
||||
应用层表的价值应该以数据应用的价值来衡量，对于低价值产出的应用，应该以应用为粒度进行下线。
|
||||
</li>
|
||||
<li>
|
||||
对高消耗任务的优化只要关注集群高峰期的任务，项目的整体资源消耗只取决于高峰期的任务消耗，当然，如果你使用的是公有云的资源，可以高峰和低谷实施差异化的成本结算，那低谷期的也是要关注的。
|
||||
</li>
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c2/b7/c233339ec939674b3e1517d69d7b9bb7.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
在数据中台的集市层，会存在一些大的宽表，这些宽表可能存在几百个字段，上游可能有数十个表，如果要计算这个表的成本会非常高。在这个表中，字段的访问频率是不相同，有的字段频率很高，有的字段频率很低，如果要对这张宽表做优化，你觉得如何来做呢?
|
||||
|
||||
最后感谢你的阅读，如果这节课让你有所收获，也欢迎你分享给更多的朋友。
|
||||
101
极客时间专栏/geek/数据中台实战课/实现篇/09 | 数据服务到底解决了什么问题？.md
Normal file
101
极客时间专栏/geek/数据中台实战课/实现篇/09 | 数据服务到底解决了什么问题？.md
Normal file
@@ -0,0 +1,101 @@
|
||||
<audio id="audio" title="09 | 数据服务到底解决了什么问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/35/75/35407539cb859f11e2f29ef703f6ae75.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
从04讲元数据中心开始，到08讲成本治理，我已经把元数据以及在它基础上的五大应用场景：数据发现（数据地图）、指标管理、模型设计、数据质量、成本优化，全部讲完了。这部分内容对应的就是数据中台OneData 方法论。相信学完这部分内容之后，你已经了解了OneData方法论在企业内部落地的方法了。
|
||||
|
||||
而这节课我要和你聊的，是数据中台另外一个核心方法论，OneService的实现：数据服务。
|
||||
|
||||
服务化在业务系统中提的比较多，它是业务系统化繁为简，实现业务拆分的必经之路（特别是这几年微服务的概念深入人心）。那对于数据中台，服务化意味着什么呢？数据服务到底解决了什么问题？ 我相信很多人会有这样的疑问。
|
||||
|
||||
>
|
||||
服务化：不同系统之间通过服务方式交互，服务通常以API接口形式存在。
|
||||
|
||||
|
||||
当然，关于数据服务的“料”很多，信息比较密集，所以我会用两讲的时间帮你搞清楚这部分内容，今天咱们先来从问题入手，看一看数据服务解决了什么问题，打消你“为什么要有数据服务”这样的疑问。
|
||||
|
||||
在我看来，要想搞清楚数据服务解决了什么问题，就要先知道，没有数据服务，我们在日常数据建设中存在哪些痛点。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f5/cd/f592d25e7e5a469299e752e51c7b69cd.jpg" alt="">
|
||||
|
||||
## 数据接入方式多样，接入效率低
|
||||
|
||||
数据中台加工好的数据，通常会以Hive表的形式存储在HDFS上。如果想直接通过数据报表或者数据产品前端展现，为了保证查询的速度，会把数据导出到一个中间存储上：
|
||||
|
||||
<li>
|
||||
数据量少的可以用MySQL , Oracle等DB，因为部署维护方便、数据量小、查询性能强。比如数据量小于500W条记录，建议使用DB作为中间存储；
|
||||
</li>
|
||||
<li>
|
||||
涉及大数据量、多维度查询的可以用GreenPlum，它在海量数据的OLAP（在线分析处理）场景中有优异的性能表现。比如数据量超过500W记录，要进行多个条件的过滤查询；
|
||||
</li>
|
||||
<li>
|
||||
涉及大数据量的单Key查询，可以用HBase。在大数据量下，HBase拥有不错的读写性能。比如超过500W记录，根据Key查询Value的场景。如果需要用到二级索引，由于HBase原生不支持二级索引，所以可以引入ES，基于ES构建二级索引和RowKey（HBase中的Key）映射关系，查询时先根据二级索引在ES中找到RowKey，然后再根据RowKey获取HBase中的Value值。
|
||||
</li>
|
||||
|
||||
因为不同的中间存储，涉及的访问API 也不一样，所以对数据应用开发来说，每个数据应用都要根据不同的中间存储，开发对应的代码，如果涉及多个中间存储，还需要开发多套代码，数据接入效率很低。
|
||||
|
||||
而数据服务为数据开发屏蔽了不同的中间存储，应用开发使用统一的API接口访问数据，大幅度提高了数据应用的研发效率。
|
||||
|
||||
当然了，数据接入效率低，除了跟对接不同的中间存储有关，还因为数据和接口不能复用。这又是怎么回事呢？
|
||||
|
||||
## 数据和接口没有办法复用
|
||||
|
||||
我们还是举个例子。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/3c/47/3c4cca0dd33c6c3db697dcd13d0a2147.jpg" alt="" title="数据和接口无法复用示意图">
|
||||
|
||||
在上图中，当我们开发“数据应用-经营分析”时，数据开发会基于a表加工c表，然后数据应用开发会把a和b的数据导出到“数据应用-经营分析的数据库db1”中，然后开发经营分析的服务端代码，通过接口1对web提供服务。
|
||||
|
||||
当我们又接到任务开发“数据应用-毛利分析”时，我们同样需要用到b表的数据，虽然b的数据已经存在于db1中，但db1是“数据应用-经营分析”的数据库，无法共享给“数据应用-毛利分析”（因为不同应用之间共享数据库，会存在相互影响）。
|
||||
|
||||
同时，经营分析的服务端接口也无法直接给毛利分析用，因为接口归属在经营分析应用中，已经根据应用需求高度定制化。
|
||||
|
||||
所以我们看到这样的现象：即使数据重复，不同数据应用之间，在中间存储和服务端接口上，也是无法复用的。这种烟囱式的开发模式，导致了数据应用的研发效率非常低。
|
||||
|
||||
而数据服务，使数据中台暴露的不再是数据，而是接口，接口不再归属于某个数据应用，而是在统一的数据服务上。这就使接口可以在不同的数据应用之间共享，同时因为数据服务具备限流的功能，使接口背后的数据共享成为可能，解决了不同应用共享数据相互影响的问题。
|
||||
|
||||
那么当数据应用上线之后，我们就进入了运维阶段，如果这个阶段没有数据服务的话，会出现什么问题呢？
|
||||
|
||||
## 不知道数据被哪些应用访问
|
||||
|
||||
来看一个我身边的案例。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/2f/72/2f2938084744301182c46595dbec1172.jpg" alt="" title="故障恢复示意图">
|
||||
|
||||
张好看（化名）是一名数据开发，某一天的凌晨，她突然接到了一堆电话报警：有大量的任务出现异常（对应上图中红色表的产出任务）。经过紧张的定位后，她确认问题来源于业务系统的源数据库，也就是说，因为一次数据库的表结构变更，导致数据中台中，原始数据清洗出现异常，从而影响了下游的多个任务。
|
||||
|
||||
这时，摆在她面前的，是一堆需要恢复重跑的任务。可是队列资源有限，到底先恢复哪一个呢？ 哪个任务最终会影响到老板第二天要看的报表呢？
|
||||
|
||||
虽然数据血缘建立了表与表之间的链路关系，但是在表的末端，我们却不知道这个表被哪些应用访问，所以应用到表的链路关系是断的。当某个任务异常时，我们无法快速判断出这个任务影响了哪些数据应用，从而也无法根据影响范围决定恢复的优先级，最终可能导致重要的报表没有恢复，不重要的报表却被优先恢复了。
|
||||
|
||||
同样，在成本治理中，我也提到，因为没有应用和数据的链路关系，我们不敢贸然下线数据。
|
||||
|
||||
而数据服务打通了数据和应用的访问链路，建立了从数据应用到数据中台数据的全链路数据血缘关系，这就等于我们在迷宫中拿到了一个地图，当任何一个任务出现问题，我们都可以顺着地图，找到这个故障影响了哪些应用，从而针对重要应用加速恢复速度。同样，我们也可以放心的下线数据中台中任意一张表。
|
||||
|
||||
除了不知道数据被哪些下游应用使用，在运维阶段，我们还经常面临着数据表频繁重构，而这也许是数据应用开发最可怕的噩梦了。
|
||||
|
||||
## 数据部门字段变更导致应用变更
|
||||
|
||||
数据中台底层模型的字段变更是比较频繁的一个事情，因为本身汇总层的模型也在随着需求不断优化。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f8/de/f802e6bc9d5d24ce3fdb6077f9a063de.jpg" alt="">
|
||||
|
||||
“数据应用-经营分析”使用了数据中台的ads_mamager_1d这张表的c字段，如果我们对这张表进行了重构，访问字段需要替换成e字段，此时需要数据应用修改代码。这种因为数据中台的数据变更导致应用需要重新上线的事情，是非常不合理的，不但会增加应用开发额外的工作量，也会拖累数据变更的进度。
|
||||
|
||||
有了数据服务，就会把数据应用和中台数据进行解耦，当中台数据表结构变更时，我们只需要修改一下数据服务上接口参数和数据字段的映射关系就可以了。不需要再修改代码，重新上线数据应用。
|
||||
|
||||
## 课堂总结
|
||||
|
||||
你看，我列举了在数据接入和运维过程中，遇到的4个典型的问题，也为你简要分析了数据服务为什么能够帮我们解决这些问题。而这些问题会让数据应用使用中台数据效率低下，同时也带来了中台数据维护的烦恼。
|
||||
|
||||
今天这部分内容，是下一讲的基础，下一讲我会和你聊一聊数据服务具备哪些功能，如果你正准备设计一个数据服务，或者正在做数据服务的产品选型，那你一定要留意这部分内容。最后，我会提供给你一个网易数据服务的实现方案，告诉你在数据服务实现上的几个关键设计。
|
||||
|
||||
在最后，我通过一个脑图，总结一下今天的内容。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/bc/90/bc053d290f89c901d0916d94dbc1ec90.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
其实，在我刚接触数据服务的时候，我听到最多的一种说法，数据服务解决了数据的安全性的问题，你觉得有道理吗？ 欢迎你在留言区与我互动。
|
||||
|
||||
最后，感谢你的阅读，如果这一节课让你有所收获，也欢迎你将它分享给更多的朋友，我们下一讲见。
|
||||
167
极客时间专栏/geek/数据中台实战课/实现篇/10 | 数据服务难道就是对外提供个API吗？.md
Normal file
167
极客时间专栏/geek/数据中台实战课/实现篇/10 | 数据服务难道就是对外提供个API吗？.md
Normal file
@@ -0,0 +1,167 @@
|
||||
<audio id="audio" title="10 | 数据服务难道就是对外提供个API吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/87/84/87298f4dcedd208d22b857b7dbfb1e84.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
在上一讲中，我为你介绍了为什么必须要有数据服务，你可以看到，数据服务在数据建设中发挥着重要的作用。那有的人可能会好奇了，数据服务到底长什么样子呢？ 是不是只对外提供一个API？ 真的有这么简单吗？接下来，我们就带着这些问题，学习今天的内容。
|
||||
|
||||
而我希望你能在学完这部分内容之后，真正掌握数据服务的产品功能设计和系统架构设计。因为这会对你设计一个数据服务，或者选择一个商业化产品，有很大的帮助。
|
||||
|
||||
## 数据服务应该具备的八大功能
|
||||
|
||||
我认为，数据服务应该具备八个功能，只有具备这些功能，才能解决我们在上一讲提到的问题。比如，数据接入方式多样，接入效率低；数据和接口没办法共享；不知道数据被哪些应用访问……
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/d3/29/d3e6a9bf2d88b050250351ac276c8029.jpg" alt="">
|
||||
|
||||
那么为了让你更好地理解数据服务的功能，我来讲个小故事。
|
||||
|
||||
你肯定去过菜鸟驿站取快递吧？假设有一个很大的菜鸟驿站，里面有很多组货架，每个货架前都有一些工作人员帮助我们取快递，同时也有很多队伍排队。
|
||||
|
||||
取快递，要先约定好接口（比如统一使用收货码来取货）。然后，为了保证不同队伍都能取到快递，我们要对每个队伍做一些限流（比如一个队伍一次只能取一个人）。在你取走快递时，驿站会记录是谁取走了哪个快递，方便后续追查。
|
||||
|
||||
这段时间，菜鸟驿站服务开始升级，不仅可以取快递，还提供快递送货上门的服务。除此之外，不同种类的快递对应的货架也变得不同，比如生鲜食品，货架是冷藏冰箱，文件、信封，货架就是文件柜。
|
||||
|
||||
对于取快递的人来说，如果他买了生鲜，又买了信封，那他要排好几个队伍，肯定不方便。所以，一般来讲，取快递的人最好只在一个队伍排队，而驿站工作人员帮他一次把多个货架的快递都取过来。
|
||||
|
||||
可驿站的货架实在是太多了，为了方便每个取快递的小伙伴都能快速找到每个货架以及队伍，驿站提供了一个导览。与此同时，为了不让工作人员出错，驿站的工作人员必须经过严格的测试，才能上岗。
|
||||
|
||||
讲完这个故事之后，我们接着回到数据服务的这八大功能上来。在取快递的这个例子中，你可以把数据服务看成是一个菜鸟驿站，工作人员看成是API解耦库，货架可以看作是中间存储，快递则可以认为是数据。
|
||||
|
||||
那么对应到八个功能，就是：
|
||||
|
||||
- 接口规范化定义，可以看成是取快递约定的收货码，基于统一的收货码取走快递；
|
||||
- 数据网关，可以看成是我们对每个货架前的队伍进行限流，确保每个队伍都能取走快递；
|
||||
- 链路关系的维护，可以看作是驿站会记录谁取走了什么快递；
|
||||
- 数据交付，可以看作驿站同时提供取快递和送货上门服务；
|
||||
- 提供多样中间存储，可以看成有不同类型的货架；
|
||||
- 逻辑模型，可以看成是一个工作人员，可以取多个货架的快递；
|
||||
- API接口，可以看作是驿站的不同货架的不同队伍导览；
|
||||
- API测试，可以看作是驿站工作人员上岗前的测试。
|
||||
|
||||
通过这个故事，你是不是已经对数据服务的八个功能有一个形象的感知了？接下来，我们来看看数据服务这八个功能具体包含什么内容。
|
||||
|
||||
**第一个是接口规范化定义。**
|
||||
|
||||
接口规范化定义就是取快递时我们约定的取件码。数据服务，对各个数据应用屏蔽了不同的中间存储，提供的是统一的API。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c6/e5/c65a500e6c72670c36aa96b0fb3e52e5.png" alt="" title="网易数据服务EasyDS界面示意图
|
||||
">
|
||||
|
||||
在上图中，我们可以在数据服务上，定义每个API接口的输入和输出参数。
|
||||
|
||||
**第二，数据网关。**
|
||||
|
||||
作为网关服务，数据服务必须要具备认证、权限、限流、监控四大功能，这是数据和接口复用的前提。这就跟我们在菜鸟驿站前取快递，要对每个队伍的人进行认证、限流一个道理。我详细介绍一下。
|
||||
|
||||
首先是认证，为了解决接口安全的问题，数据服务首先会为每个注册的应用分配一对accesskey和secretkey，应用每次调用API 接口，都必须携带acesskey和secretkey。
|
||||
|
||||
除此之外，对于每个已发布的API，API 负责人可以对应用进行授权，只有有权限的应用才可以调用该接口。同时，API接口的负责人可以对应用进行限流（例如限制每秒QPS 不超过200），如果超过设定的阈值，就会触发熔断，限制接口的访问频率。
|
||||
|
||||
需要你注意的是，对于接口复用来说，限流功能非常必要，否则会造成不同应用之间的相互影响。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/71/c4/71b7881dc2eba1ab3f91d6682d2ad1c4.png" alt="" title="应用对接口授权示意图">
|
||||
|
||||
当然，数据服务还要提供接口相关的监控，比如接口的90%的请求响应时间、接口调用次数、失败次数等相关的监控，另外，对于长时间没有调用的API ，应该予以下线。这样做的好处是防止没用的接口额外占用资源。
|
||||
|
||||
**第三，全链路打通。**
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/59/46/59e8853a53e9456da459064b45212d46.jpg" alt="">
|
||||
|
||||
数据服务还必须负责维护数据模型到数据应用的链路关系。
|
||||
|
||||
在上图中，经营分析是一个数据应用，甄美丽是数据应用的开发，当她想要访问数据服务中的某个接口获取表A和B的数据时，她需要向接口的发布者马帅帅申请授予权限。然后经营分析就可以通过接口获取到数据。
|
||||
|
||||
同时，数据服务会把经营分析和表A和B的访问关系，推送给数据中台的元数据中心。接着元数据中心表A、B以及A和B的上游所有的表（图中D和E）上，就会有经营分析数据应用的标签。
|
||||
|
||||
当表D的产出任务异常时，马帅帅可以通过元数据中心，快速判断出该任务影响了经营分析数据产品的数据产出。同时，当马帅帅想要下线表D时，也可以通过这张表是否有标签，快速判断这个表下游是否还有应用访问。当马帅帅取消API 接口授权时，元数据中心同时会清理表的相关标签。
|
||||
|
||||
**需要特别提到的是，**一个数据应用往往涉及很多页面，如果我们在影响分析时，只分析到应用，可能粒度还是太粗了，需要到更细级别的页面的粒度，比如一个任务异常，我不光要知道是哪个数据产品，还必须得知道是哪个数据产品的哪个页面。此时，我们在接口授权时，可以标注页面名称。
|
||||
|
||||
**第四，推和拉的数据交付方式。**
|
||||
|
||||
相信你听到的数据服务，都是以API接口的形式对外提供服务，但是业务实际场景中，光API 还不够的。我把API 方式称为拉的方式，而实际业务中同样还需要推的场景。
|
||||
|
||||
比如在实时直播场景中，商家需要第一时间获得关于活动的销售数据，此时就需要数据服务具备推的能力，我把它称为数据的送货上门服务。数据服务将数据实时写入到一个Kafka中，然后应用通过订阅Kafka的Topic，可以获得实时数据的推送。
|
||||
|
||||
**第五，利用中间存储，加速数据查询。**
|
||||
|
||||
数据中台中数据以Hive表的形式存在，基于Hive或者是Spark计算引擎，并不能满足数据产品低延迟，高并发的访问要求，
|
||||
|
||||
所以，一般做法是将数据从Hive表导出到一个中间存储，由中间存储提供实时查询的能力。数据服务需要根据应用场景支持多种中间存储，我列举了一些常用的中间存储以及这些存储适用的场景，希望你能根据实际场景选择适合的中间存储。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/58/31/589e542b326d8666bb192e6079034831.jpg" alt="">
|
||||
|
||||
**第六，逻辑模型，实现数据的复用。**
|
||||
|
||||
在前面取快递的场景中，每一个货架一拨工作人员，其实对取快递的人并不友好，所以最好的就是一个人帮我们把所有的快递都取了。这就有点儿类似数据服务中逻辑模型的概念了。我们可以在数据服务中定义逻辑模型，然后基于逻辑模型发布API，逻辑模型的背后实际是多个物理表，从用户的视角，一个接口就可以访问多张不同的物理表了。
|
||||
|
||||
逻辑模型可以类比为数据库中视图的概念，相比于物理模型，逻辑模型只定义了表和字段的映射关系，数据是在查询时动态计算的。逻辑模型可以看作是相同主键的物理模型组成的大宽表。逻辑模型的存在，解决了数据复用的问题，相同的物理模型之上，应用可以根据自己的需求，构建出不同的逻辑模型，每个应用看到不同的列。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/9d/bd/9d04db950b6545ae7fb67e33c127a9bd.jpg" alt="">
|
||||
|
||||
在上面这个例子中，有三个物理模型，但是主键都是商品ID，针对商品运营系统和店铺参谋，我们可以构建两个不同的逻辑模型，分别从不同的视角看数据，逻辑模型并不实际存在，而是在查询的时候，根据逻辑模型映射的物理模型字段，动态的地将请求拆分给多个物理模型，然后对多个查询结果进行聚合，得到逻辑模型查询的结果。
|
||||
|
||||
**第七，构建API 集市，实现接口复用。**
|
||||
|
||||
为了实现接口的复用，我们需要构建API的集市，应用开发者可以直接在API 集市发现已有的数据接口，直接申请该接口的API 权限，即可访问该数据，不需要重复开发。
|
||||
|
||||
需要特别指出的是，数据服务通过元数据中心，可以获得接口访问的表关联了哪些指标。使用者可以基于指标的组合，筛选接口，这样就可以根据想要的数据，查找可以提供这些数据的接口，形成了一个闭环。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/bd/b0/bd41b45fd4f18af51c478ac680a378b0.jpg" alt="">
|
||||
|
||||
讲了这么多数据服务应该具备的功能，你可能会问，那数据服务应该如何实现呢？ 我们下面就来讲数据服务的架构设计。
|
||||
|
||||
## 数据服务系统架构设计
|
||||
|
||||
网易在实现数据服务时，主要采用了云原生、逻辑模型和数据自动导出三个关键设计，关于这部分内容，我希望你能通过学习，在实际工作中可以借鉴我们的方式完成数据服务的设计，或者在选择商业化产品时，给你一个架构选型方面的参考。
|
||||
|
||||
**云原生**
|
||||
|
||||
云原生的核心优势在于每个服务至少有两个副本，实现了服务的高可用，同时根据访问量大小，服务的副本数量可以动态调整，基于服务发现，可以实现对客户端透明的弹性伸缩。服务之间基于容器实现了资源隔离，避免了服务之间的相互影响。这些特性非常适用于提供高并发、低延迟，在线数据查询的数据服务。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/18/69/1844f8bf8facbba99c46a8b507203369.jpg" alt="">
|
||||
|
||||
上图是网易数据服务的部署架构，在这个图中，每个已经发布上线的API接口都对应了一个Kubernates的Service，每个Service 有多个副本的Pod组成，每个API 接口访问后端存储引擎的代码运行在Pod对应的容器中，随着API接口调用量的变化，Pod 可以动态的创建和销毁。
|
||||
|
||||
Envoy 是服务网关，可以将Http请求负载均衡到Service的多个Pod上。Ingress Controller 可以查看 Kubernates中每个Service的Pod 变化，动态地将Pod IP写回到Envoy，从而实现动态的服务发现。前端的APP，Web或者是业务系统的Server端，通过一个4层的负载均衡LB接入到Envoy。
|
||||
|
||||
基于云原生的设计，解决了数据服务不同接口之间资源隔离的问题，同时可以基于请求量实现动态的水平扩展。同时借助Envoy实现了限流、熔断的功能。你也可以借鉴我们的方案，实现原原生的数据服务设计。
|
||||
|
||||
**逻辑模型**
|
||||
|
||||
相较于物理模型，逻辑模型并没有保存实际的数据，而只是包括了逻辑模型和物理模型的映射关系，数据在每次查询时动态生成。逻辑模型的设计，解决了不同接口，对于同一份数据，需要只看到自己需要的数据的需求。
|
||||
|
||||
下图是网易数据服务逻辑模型的系统设计图。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c3/6d/c3a2793aa44c4da16b60f80bb2ac626d.jpg" alt="">
|
||||
|
||||
接口发布者在数据服务中选择主键相同的多张物理表构建一个逻辑模型，然后基于逻辑模型发布接口。API 服务接到查询请求后，根据逻辑模型和物理模型字段的映射关系，将逻辑执行计划拆解为面向物理模型的物理执行计划，并下发多个物理模型上去执行，最后对执行的结果进行聚合，返回给客户端。
|
||||
|
||||
一个逻辑模型关联的物理模型可以分布在不同的查询引擎上，但是这种情况下，考虑性能因素，只支持基于主键的筛选。
|
||||
|
||||
**数据自动导出**
|
||||
|
||||
数据服务选择的是数据中台的一张表，然后将数据导出到中间存储中，对外提供API 。那数据什么时候导出到中间存储中呢？ 要等数据产出完成。
|
||||
|
||||
所以在用户选择了一张数据中台的表，定义好表的中间存储后，数据服务会自动生成一个数据导出任务，同时建立到这个数据中台表的产出任务的依赖关系，等到每次调度产出任务结束，就会触发数据导出服务，将数据导出到中间存储中，此时API 接口就可以查询到最新的数据。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/2a/b5/2a3a546bc5d8d3b51270755282c580b5.jpg" alt="">
|
||||
|
||||
## 课堂总结
|
||||
|
||||
你看，数据服务化不是一个API接口这么简单吧，它的背后是数据标准化交付的整套流程。通过这节课，我为你介绍了数据服务的八大关键功能设计和三大系统架构设计。
|
||||
|
||||
在最后，我还想强调几个点：
|
||||
|
||||
- 数据服务实现了数据中台模型和数据应用的全链路打通，解决了任务异常影响分析和数据下线不知道影响哪些应用的难题；
|
||||
- 基于相同主键的物理模型，可以构建逻辑模型，逻辑模型解决了数据复用的难题，提高了接口模型的发布效率；
|
||||
- 数据服务宜采用云原生的设计模式，可以解决服务高可用、弹性伸缩和资源隔离的问题。
|
||||
|
||||
数据服务化对于加速数据交付流程，以及数据交付后的运维管理效率有重要作用，也是数据中台关键的组成部分。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a8/6c/a83b384e3fd4932f2bf4fcc4babcd86c.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
数据服务要想解决数据被哪些应用访问的问题，就必须确保所有数据应用都必须通过数据服务获取数据中台的数据，那问题来了，如何确保数据服务是数据中台的唯一出口？欢迎在留言区与我互动。
|
||||
|
||||
最后感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的朋友。
|
||||
222
极客时间专栏/geek/数据中台实战课/实现篇/11 | 怎么一劳永逸地解决数据安全问题？.md
Normal file
222
极客时间专栏/geek/数据中台实战课/实现篇/11 | 怎么一劳永逸地解决数据安全问题？.md
Normal file
@@ -0,0 +1,222 @@
|
||||
<audio id="audio" title="11 | 怎么一劳永逸地解决数据安全问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e6/04/e61b9b876a6e6bae6c520dbbc4366804.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
在前面的课程中，我们了解了数据中台在数据建设效率、质量和成本方面的内容。而除了快、准和省以外，数据中台还必须是安全的。因为如果不安全，你很可能出现和“微盟删库跑路”同样的事情。所以，为了让你能重视数据中台的数据安全，我简单说一下这件事儿的情况。
|
||||
|
||||
2020年2月23日19点，国内最大的精准营销服务商微盟出现了大面积的系统故障，旗下300万商户的线上业务全部停止，商铺后台的所有数据被清零。始作俑者是一位运维人员，他在生产环境数据库进行了删库操作，而刚刚上市不久的微盟就因此遭受了巨大的损失，从2月23日宕机以来，市值已经蒸发了30亿港元。这件事儿堪称史上最贵的安全事件。
|
||||
|
||||
那么从微盟的教训中，我们能得到什么警醒呢？在数据中台中怎么防止出现类似的事件呢？ 我想这或许是你需要认真思考的内容。安全问题可大可小，不出事情，你可能根本不会重视，但是一旦出现事故，就是灾难性的。在网易，我们对数据中台的安全管理是非常严格的。
|
||||
|
||||
在刚开始构建网易数据中台的时候，我们就重点考虑了数据中台的安全保障，我把它归结为五大法宝。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b2/f3/b2fc3e4ff33a32feef34f224e0f434f3.jpg" alt="">
|
||||
|
||||
接下来，我就带你深入分析一下，希望学完这部分内容之后，你可以回答这样三个问题：
|
||||
|
||||
- 如何解决数据误删除问题；
|
||||
- 如何解决敏感数据泄露问题；
|
||||
- 如何解决开发和生产物理隔离问题。
|
||||
|
||||
它们是你在数据中台建设中一定会面临的，学完之后，你一定可以找到解决这些问题的方法。
|
||||
|
||||
**机制一：数据备份与恢复**
|
||||
|
||||
对于绝大多数的企业，数据中台的数据都存储在HDFS中，即使是实时的数据（存储于Kafka），也会归档一份到HDFS，因为要保存历史数据进行回算或者补数据。**所以我们要解决的核心问题是HDFS 的数据备份。**
|
||||
|
||||
网易HDFS 数据的备份，是基于HDFS 快照 + DistCp + EC实现的。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/5a/db/5ae3dde9024db601ce1cc872de35d0db.jpg" alt="" title="网易数据备份的架构图">
|
||||
|
||||
我们分为线上集群和冷备集群两个集群，数据加工任务访问的是线上集群，存储采用的是HDFS默认的3副本。而冷备集群，主要考虑到存储成本的因素，采用的是EC 存储。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/1f/88/1f210c06cd54528ad03d19799b69d088.jpg" alt="" title="EC 存储原理示意图">
|
||||
|
||||
**为了让你了解EC存储的基本原理，我多说几句。**其实，Hadoop 在3.x就正式引入了EC 存储，它是一种基于纠删码实现的数据容错机制，通过将数据进行分块，然后基于一定的算法计算一些冗余的校验块，当其中一部分数据块丢失的时候，可以通过这些冗余的校验块和剩余的数据块，恢复出丢失的数据块。
|
||||
|
||||
这么说可能不太形象，我做个比喻。比如有三个数据块，分别存储的是1、2和3。我们非常担心其中一个数据块坏了，丢失内容。所以增加了一个块，这个块存储的内容是前面三个数据块之和。那么如果其中任意一个数据块坏了，我们可以根据现有的数据块计算出丢失的数据块内容。 比如1丢失了，我们可以根据6-3-2计算出1，当然这个只是最简单的EC 算法，只能容忍一个数据块丢失，实际的EC算法要再复杂一些 。
|
||||
|
||||
关于EC 具体的算法细节，不是本节课的重点，不过我在文末提供了一个链接，你可以课下研究一下。在这里我只想告诉你的是，EC 存储，在不降低可靠性的前提下（与HDFS 3副本可靠性相同），通过牺牲了一定的计算性能（因为计算校验块需要消耗额外的计算资源），将数据存储成本降低了一半，非常适合低频访问的冷数据的存储，而备份数据就是这种类型的数据。
|
||||
|
||||
**那线上集群的数据又是如何同步到冷备集群的呢？**
|
||||
|
||||
在回答这个问题前，你有必要先了解一下快照的基本原理，因为这样你才能理解后续的数据同步流程。
|
||||
|
||||
Hadoop 在2.x版本就已经支持了对某个文件或者目录创建快照，你可以在几秒内完成一个快照操作。在做快照前，你首先要对某个目录或者文件启用快照，此时对应目录下面会生成一个.snapshot的文件夹。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/93/58/936a5ab8ff49edefc8fff146b6cb9958.jpg" alt="">
|
||||
|
||||
在上图中， 我们对/helloword目录启用快照，然后创建一个s1的备份。此时，在.snapshot下存在s1文件。然后我们删除/helloword/animal/lion 文件时，HDFS 会在animal 目录创建differ文件，并把diifer文件关联到s1备份，最后把lion文件移动到differ目录下。
|
||||
|
||||
通过这个案例，我们不难发现，HDFS 快照实际只记录了产生快照时刻之后的，所有的文件和目录的变化，非常适合每天只有少数文件被更新的数据中台，代价和成本也很低。
|
||||
|
||||
有了快照之后，我们就需要把快照拷贝到冷备集群中，这里选择的是Hadoop 自带的DistCp。为什么考虑DistCp 呢？因为它支持增量数据的同步。它有一个differ参数，可以对比两个快照，仅拷贝增量的数据。同时，DistCp是基于MapReduce 框架实现的数据同步工具，可以充分利用Hadoop分布式计算的能力，保证数据的拷贝性能。
|
||||
|
||||
我提供给你一张详细的图，透过这张图，你可以看到具体的数据从线上集群拷贝到冷备集群的流程。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/94/92/94dbe40ed0d79d205cb52fab5d2ece92.jpg" alt="">
|
||||
|
||||
首先，对于第一次开始数据备份的文件，我们会先创建一个快照，然后利用DistCp 拷贝全量的备份数据到冷备集群。然后后续的每一天，我们都会定时生成一个快照，并和前一天的快照基于distcp --differ 参数进行对比，将有更新的部分再同步到冷备集群。同步完成以后，会删除前一天的快照，这样就完成了每日数据的增量同步。
|
||||
|
||||
这里需要特别注意的是，拷贝数据会对线上I/O 产生比较大的压力，所以尽量在任务运行的低峰期进行同步（比如白天12点到晚上24点之间的时间），同时DistCp的bandwidth参数可以限制同步的速率，你可以根据I/O 负载和数据同步速率，动态调整。比如说，I/O 利用率100%，应该限制数据拷贝带宽，为10MB/s。
|
||||
|
||||
讲到这儿，你已经了解了数据中台中，文件目录的备份了，但是光这些还不够，我们还需要备份数据的产出任务，表相关的信息：
|
||||
|
||||
- 任务的备份，要保存任务代码、任务的依赖关系、任务的调度配置以及任务的告警、稽核监控等信息；
|
||||
- 表的备份主要是备份表的创建语句。
|
||||
|
||||
在网易，我们提供了产品化的解决方案，数据开发可以在我们提供的数据管理平台上，选择一张表，创建备份，然后系统就会自动地完成任务、文件和表的备份。平台也提供了一键恢复的功能，系统会自动地帮数据开发创建任务和表，拷贝数据从冷备集群到线上集群。
|
||||
|
||||
那么你可能会有疑问：什么样的数据应该备份呢？ **在我看来，数据的备份策略应该和数据资产等级打通，对于核心数据资产，数据中台应该强制进行备份。**
|
||||
|
||||
那假如说，数据没有备份，但我们误删除了，还有没有其他的补救方法呢？ 你可以试一下接下来地的这个机制。
|
||||
|
||||
**机制二：垃圾回收箱设计**
|
||||
|
||||
HDFS 本身提供了垃圾回收站的功能，对于意外删除的文件，可以在指定时间内进行恢复，通过在Core-site.xml中添加如下配置就可以开启了，默认是关闭状态。
|
||||
|
||||
```
|
||||
<property>
|
||||
<name>fs.trash.interval</name>
|
||||
<value>1440</value>
|
||||
</property>
|
||||
|
||||
```
|
||||
|
||||
当HDFS 一旦开启垃圾回收功能后，用户通过命令行执行rm 文件操作的时候，HDFS 会将文件移到/user/[用户名]/.trash/current/ 目录下。这个目录下的文件会在fs.trash.interval 配置的时间过期后被系统自动删除。当你需要恢复文件的时候，只需要把/user/[用户名]/.trash/current/被删除文件移到要恢复的目录即可。
|
||||
|
||||
**听到这儿，你是不是感觉问题已经解决了呢？但是我想强调的是HDFS垃圾回收机制在实际应用过程中，存在重大的缺陷。**因为它只能支持通过命令行执行rm操作，对于在代码中通过HDFS API调用Delete接口时，会直接删除文件，垃圾回收机制并不生效。尤其是我们在Hive中执行drop table删除一个Hive内表，此时删除的数据文件并不会进入trash目录，会存在巨大的安全隐患。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/d9/fe/d91b36b36c8b150a28a5080cc5c318fe.jpg" alt="" title="改造后 HDFS 回收站原理示意图">
|
||||
|
||||
那你要怎么解决呢？我建议你可以对HDFS的Client 进行修改，对Delete API通过配置项控制，改成跟rm相同的语义。也就是说，把文件移到trash目录。对于Hive 上的HDFS Client 进行了替换，这样可以确保用户通过drop table 删除表和数据时，数据文件能够正常进入HDFS trash目录。
|
||||
|
||||
**通过这种方式，你可以解决数据误删除的问题。**但HDFS 回收站不宜保留时间过长，因为回收站中的数据还是三副本配置，会占用过多的存储空间。所以我给出的一个配合解决方案是，回收站保留24小时内的数据。这样解决的是数据还没来得及被同步到冷备集群，误删除的情况。对于一天以上的数据恢复，建议采取基于冷备集群的数据备份来恢复。
|
||||
|
||||
好了，讲完如何解决数据的误删除之后，接下来我们来解决第二个问题，就是如何避免敏感数据的泄露，而这离不开精细化的权限管理。
|
||||
|
||||
**机制三：精细化的权限管理**
|
||||
|
||||
数据权限是数据中台实现数据复用的前提和必要条件。如果刚开始系统没有开启权限，后期接入权限，任务的改造成本会非常高的，几乎涉及到所有的任务。**所以权限这个问题，在数据中台构建之初，必须提前规划好。**
|
||||
|
||||
网易数据中台支撑技术体系是基于OpenLDAP + Kerberos + Ranger 实现的一体化用户、认证、权限管理体系。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b2/55/b206938aec70551a9d2784c453aae755.jpg" alt="" title="网易数据中台用户、认证、权限系统架构
|
||||
">
|
||||
|
||||
试想一下，如果有几千台机器，却没有一个统一的用户管理服务，当我们想添加一个用户时，需要到几千台服务器上去创建初始化用户，这个管理和运维的效率有多低。而OpenLDAP就帮我们解决了这个问题。
|
||||
|
||||
OpenLDAP是一个轻量化的目录服务，数据以树型结构进行存储，能够提供高性能的查询服务，非常适合用户管理的场景。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/23/2d/23cd128afadafa2e31f8249ad3f93c2d.jpg" alt="" title="OpenLDAP 树型目录架构示意图
|
||||
">
|
||||
|
||||
在OpenLDAP中，我们可以创建用户（User）和组(Group)，对于每个用户，会有唯一的uid，对于每个组，通过Memberuid，我们可以添加一个用户到一个组中。
|
||||
|
||||
在网易大数据平台上注册一个用户，平台会自动生成一个OpenLDAP的用户，当该用户加入某个项目时，会将该项目对应的Group下增加一个Memberuid。假设在上图中，甄漂亮加入了da_music项目，那么在da_music 的Group下，会增加Memberuid:1002。同理，当甄美丽加入某个角色时，在对应角色的Group下，也会有甄美丽对应的Memberuid。
|
||||
|
||||
那Hadoop 又是怎么跟OpenLDAP集成的呢？
|
||||
|
||||
Hadoop 可以使用LdapGroupsMappings 同步LDAP创建的用户和用户组，这样当我们在LDAP中添加用户和组时，会自动同步到Hadoop集群内的所有机器上。
|
||||
|
||||
**通过这个方式，你就可以解决用户管理的问题了，而接下来要解决的就是认证的问题。**在非安全网络中，除了客户端要证明自己是谁，对于服务端而言，同样也需要证明我是我。为了实现双向的认证，我们在生产环境启用了安全等级最高的，基于共享密钥实现的Kerberos认证。
|
||||
|
||||
说起Kerberos认证的原理，我想举一个有趣的例子。
|
||||
|
||||
你肯定去过游乐场吧！ 为了进游乐场，首先你需要提供你的身份证，实名购买一张与你身份绑定的门票。在进入游乐场之后呢，每个游乐设施前，都有一个票据授权机器，你需要刷一下你的门票，授权机器会生成一个该游乐设施的票据，你拿着这个票据就可以玩这个游乐设施了。
|
||||
|
||||
当然，当你想玩另外一个游乐设施的时候，同样需要刷一下你们的门票，生成对应游乐设施的票据。而且你的门票是有有效期的，在有效期内，你可以尽情地玩游乐设施，一旦超过有效期，你需要重新购买你的门票。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/0d/0d/0ddf10ccb97b12cd25e8e1fe88dfd90d.jpg" alt="" title="Kerberos 认证原理示意图
|
||||
">
|
||||
|
||||
Kerberos认证与上面这个故事类似，在上面的故事中，TGT（Ticket-granting ticket）可以看作是门票，Client首先使用自己的密钥文件Keytab和用户标识Principal去认证服务器（AS）购买TGT，认证服务器确认是合法的用户，Client会获得TGT，而这个TGT使用了TGS（Ticket-granting service）的Keytab加密，所以Client是没办法伪造的。
|
||||
|
||||
在访问每个Server前，Client需要去票据授权服务（TGS）刷一下TGT，获取每个服务的票据（ST），ST使用了Client要访问的Server的Keytab加密，里面包含了TGS 认证的用户信息，Client是无法伪造ST的。
|
||||
|
||||
最后基于每个服务的票据，以及客户端自己生成的加密客户认证信息（Autenticator）访问每个服务。每个Server都有归属于自己的Keytab，Server只有使用Server自己的Keytab才能解密票据（ST），这就避免了Client传给了错误的Server。
|
||||
|
||||
与此同时，解密后票据中包含TGS认证的客户信息，通过与Authenticator 中Client生成的客户信息进行对比，如果是一致的，就认为Client是认证通过的。
|
||||
|
||||
一般在Hadoop中，我们会使用Kinit 工具完成TGT的获取，TGT 一般保存24小时内。**我介绍Kerberos原理，其实是想让你知道，Kerberos对于Hadoop集群来说，是一个非常安全的认证实现机制，我推荐你使用Kerberos 实现Hadoop集群的安全认证。**
|
||||
|
||||
你可能会问，Kerberos 使用的是Principal标识用户的，它又是怎么和OpenLDAP中的用户打通的呢？ 其实我们访问HDFS，使用的是Principal，Hadoop可以通过配置hadoop.security.auth_to_local，将Principal映射为系统中的OpenLDAP的用户。用户注册时，平台会为每一个新注册的用户生成Principal以及相对应的Keytab文件。
|
||||
|
||||
认证完成之后呢，就要解决哪些客户可以访问哪些数据的问题了。我推荐你使用Ranger来解决权限管理的问题。
|
||||
|
||||
**为什么要选择Ranger呢？**因为Ranger 提供了细粒度的权限控制（Hive列级别），基于策略的访问控制机制，支持丰富的组件以及与Kerberos的良好集成。权限管理的本质，可以抽象成一个模型：“用户-资源-权限”。
|
||||
|
||||
数据就是资源，权限的本质是解决哪些人对哪些资源有权限。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/d1/93/d1407e801aa4e89f54bbc8e2e2384093.jpg" alt="">
|
||||
|
||||
在Ranger中，保存了很多策略，每一个资源都对应了一条策略，对于每个策略中，包含了很多组许可，每个一个许可标识哪个用户或者组拥有CRUD权限。
|
||||
|
||||
讲完了用户、认证和权限实现机制，那你可能会问，**权限的申请流程是什么样子的呢? **
|
||||
|
||||
在数据中台中，每一张表都有对应的负责人，当我们在数据地图中找到我们想要的数据的时候，可以直接申请表的访问权限，然后就会发起一个权限申请的工单。表的负责人可以选择授权或者拒绝申请。申请通过后，就可以基于我们自己的Keytab访问该表了。
|
||||
|
||||
**另外，需要特别强调的是，**由于数据中台中会有一些涉及商业机密的核心数据，所以数据权限要根据数据资产等级，制订不同的授权策略，会涉及到不同的权限审批流程，对于一级机密文件，可能需要数据中台负责人来审批，对于一般的表，只需要表的负责人审批就可以了。
|
||||
|
||||
## 机制四：操作审计机制
|
||||
|
||||
进行到第三步，权限控制的时候，其实已经大幅降低了数据泄露的风险了，但是一旦真的出现了数据泄露，我们必须能够追查到到底谁泄露了数据，所以，数据中台必须具备审计的功能。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/e6/e4/e60423e0a54035a06dc0885a67fc99e4.jpg" alt="">
|
||||
|
||||
由于用户每次访问数据，都要对权限进行验证，所以在校验权限的同时，可以获取用户访问表的记录，Ranger支持审计的功能，用户的访问记录会由部署在各个服务（HDFS，HBase等等）上的插件推送到Audit Server上，然后存储在Solr中，Ranger提供了API接口查询表的访问记录。但是必须指出的是，Ranger开启Audit 后，会对服务内的插件性能产生影响。
|
||||
|
||||
除了敏感数据泄露的风险，我还看到一些企业想要对开发和生产环境进行物理隔离。为什么企业会有这个诉求呢？
|
||||
|
||||
首先，很多传统公司的数据开发都是外包人员，从企业的角度，不希望数据开发直接使用生产环境的数据进行测试，从安全角度，他们希望生产和测试从物理集群上完全隔离，数据脱敏以后，给开发环境进行数据测试。
|
||||
|
||||
其次，涉及一些基础设施层面的组件升级（比如HDFS、Yarn、Hive、Spark等），贸然直接在生产环境升级，往往会造成兼容性的事故，所以从安全性的角度，企业需要有灰度环境，而用开发环境承担灰度环境的职能，是一个不错的选择。
|
||||
|
||||
最后，虽然可以为生产和开发环境设置不同的库和队列，从而实现隔离，避免开发任务影响线上任务和数据，但会导致任务上线需要改动代码，所以最理想的，还是实现开发和生产环境两套集群，同一套代码，在开发环境对应的就是开发集群，提交上线后，就发布到生产集群。
|
||||
|
||||
这些就是企业希望开发和生产集群物理隔离的原因，那我们接下来看一看该如何满足。
|
||||
|
||||
## 机制五：开发和生产集群物理隔离
|
||||
|
||||
在面对这个需求时，我们遇到了两类完全不同的企业群体。
|
||||
|
||||
一部分来自传统企业，尤其是金融行业，他们对安全性的要求远大于对效率的诉求，严格禁止数据开发使用线上数据进行测试，他们希望有两套完全不同的环境，包括操作平台，任务在开发环境进行开发，配置任务依赖，设置稽核规则和报警，然后由运维人员进行审核后，一键发布到生产环境。当数据开发需要对数据进行测试时，可以同步生产环境的局部数据（部分分区），数据会进行脱敏。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/01/b2/01844c9d1a63f2874bf2a6ffdb8e3eb2.jpg" alt="">
|
||||
|
||||
上图是该模式下的部署架构。
|
||||
|
||||
通过这张图我们可以看到，开发和测试环境本身是两套完全独立的平台，因为每次数据测试，都需要同步生产环境的数据，所以这种模式下，数据开发的效率会有比较大的影响，但是优势在于对数据安全实现了最高级别的保护。
|
||||
|
||||
与这部分客户不同的是，很多企业需要同时兼顾安全和效率，他们没有办法接受同步生产环境数据，而是需要在开发环境能够直接使用线上的数据进行测试。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/99/c8/99e170d0a50a6a8718987556c04697c8.jpg" alt="">
|
||||
|
||||
上图展示了该模式下的部署架构。
|
||||
|
||||
我们可以看到，大数据平台和任务调度系统（Azkaban）都是一套，然后Hive，Yarn和HDFS都是两套，两套集群通过Metastore 共享元数据。
|
||||
|
||||
这样做的一个好处在于，一个集群的Hive可以直接访问另外一个集群的数据。在同一个Metastore中，开发环境的数据在_dev库中，生产环境的数据在_online库中，用户在代码中不需要指定库，在任务执行时，根据运行环境，自动匹配库。例如在开发环境执行，Hive默认会使用_dev库下的表，而在生产环境执行，Hive默认会使用_online库下的表，从而实现了不需要改代码可以实现一键发布。
|
||||
|
||||
上面两种部署模式，你可以根据你所在的企业实际情况进行选择，对安全性要求高，推荐第一种方案，对于效率要求高，同时兼顾一定的安全性，就推荐第二种方案。
|
||||
|
||||
## 课堂总结
|
||||
|
||||
以上就是这节课的全部内容了，总的来说，我为你介绍了解决数据中台安全问题的五大制胜法宝，相信通过这些保障机制，你可以解决数据中台遇到的安全问题了。最后，我再强调几个重点：
|
||||
|
||||
- 数据备份要同时兼顾备份的性能和成本，推荐采用EC存储作为备份集群的存储策略；
|
||||
- 数据权限要实现精细化管理，基于OpenLDAP+Kerberos+Ranger可以实现一体化用户、认证、权限管理；
|
||||
- 开发和生产环境物理隔离，我提到了两种部署模式，需要综合权衡效率和安全进行选择。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ba/26/babcbf9505bfcc8156469e888ddd8826.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
在课程的最后，我还是留一个思考题，来与你进行互动。
|
||||
|
||||
引入权限管理，势必会对数据研发效率产生影响，同时已有的任务必须重构，进行认证改造。你是如何思考安全和效率之间的优先关系的？ 欢迎在留言区与我互动。
|
||||
|
||||
最后，感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的朋友。
|
||||
|
||||
**HDFS EC 存储介绍：**<br>
|
||||
[https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html](https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html)
|
||||
189
极客时间专栏/geek/数据中台实战课/实现篇/12 | 数据的台子搭完了，但你还得想好戏该怎么唱.md
Normal file
189
极客时间专栏/geek/数据中台实战课/实现篇/12 | 数据的台子搭完了，但你还得想好戏该怎么唱.md
Normal file
@@ -0,0 +1,189 @@
|
||||
<audio id="audio" title="12 | 数据的台子搭完了，但你还得想好戏该怎么唱" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c8/a5/c8b576816d5b963a14418dc3dc058aa5.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
从第4节元数据管理开始，到第10节数据安全，我已经详细讲了如何建成快、准、省和安全的数据中台。现在，数据中台的台子已经全部搭完了，接下来，好戏就可以上演了，也就是说，我们要在数据中台的基础上，构建企业数据应用体系，用好数据中台的数据。
|
||||
|
||||
对企业来说，用好数据非常关键，从我多年的数据建设经验来看，我把数据在企业的应用划分成三个阶段。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/75/70/75206cde06d83ab7bacd4dfc99038f70.jpg" alt="">
|
||||
|
||||
<li>
|
||||
**初级阶段。一般企业的数据应用都是从数据报表开始的，**分析师会为业务部门的负责人、运营制作一些BI报表，把数据通过可视化的方式呈现出来，这是数据应用的初始阶段。
|
||||
</li>
|
||||
<li>
|
||||
**发展阶段。**只是可视化的展现数据已经不能满足业务的需求，业务需要根据数据持续监控业务过程，发现问题、诊断分析，并给出决策建议，最后需要一键执行，形成完成的业务过程闭环，**这个时候就要借助数据产品来实现，**网易也是在2018年才开始大规模构建数据产品体系。
|
||||
</li>
|
||||
<li>
|
||||
**高级阶段。**无论是数据报表、还是数据产品，它们呈现的都是固化的分析思路，只能解决知道的业务问题，但是日常工作还有很多未知的业务问题，比如销售额指标突然下降了，需要基于数据进行探索分析。这个时候，如果都依赖分析师，肯定不现实，**那么就要实现自助取数，**让每个人都能基于数据去做分析和决策，实现普惠大数据。我认为这是数据应用的最高级阶段，网易在2019年开始开放越来越多的中台数据，让更多的非技术人员去使用数据。
|
||||
</li>
|
||||
|
||||
那么今天这节课，我们就从这三个阶段，谈一谈如何用好数据中台的数据。
|
||||
|
||||
## 数据中台该如何赋能BI 工具
|
||||
|
||||
很多人对数据的了解，都是从BI工具做的报表开始的。关于BI 工具的产品本身，不是我想说的重点，我主要想和你讨论的是数据中台时代，如何让数据中台帮助BI工具更强大。
|
||||
|
||||
我会从四个方面带你了解这部分内容。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a3/6d/a3aad90b94b15e4ea4848fa8c156436d.jpg" alt="">
|
||||
|
||||
**第一，统一报表指标业务口径。**
|
||||
|
||||
数据报表上会存在指标口径不一致的问题，相同指标名称，两个报表里的数据却相差很大，这会让数据使用者对数据失去信任。
|
||||
|
||||
而数据中台的所有的指标都是由指标系统统一管理的，如果能在数据报表上直接看到指标系统中，指标的口径定义，就可以让看报表的人准确理解数据的含义，也可以避免不同报表之间指标口径不一致的问题。
|
||||
|
||||
同时，如果我们在指标系统上修改了指标的口径定义，也可以同步到所有的呈现该指标的数据报表中。
|
||||
|
||||
**第二，掌握任务影响了哪些数据报表。**
|
||||
|
||||
当某个任务异常，影响了下游多个任务时，我们往往要根据任务的影响范围，决定任务恢复的优先级。如果任务影响了老板每天看的一张报表，而你却不知道，没有优先修复它，那你就等着被批吧。
|
||||
|
||||
那我们要怎么知道一个 任务影响了哪些数据报表呢？
|
||||
|
||||
在网易，数据报表在保存时，BI工具可以把报表和数据的链路关系，推送给数据中台的元数据中心。当数据中台的任何一个任务出现异常，我们通过数据血缘，就可以快速找到这个任务影响了哪些数据报表，尤其是在故障恢复的时候，根据报表的优先级，我们可以优先恢复高优先级的报表。
|
||||
|
||||
**第三，治理低价值的数据报表。**
|
||||
|
||||
根据数据中台的全链路数据血缘，我们可以计算每一个报表上游所有的数据加工成本，然后得到这个报表的成本。然后根据报表的访问量和访问人群，我们可以计算报表的ROI（投入产出比），下线低价值的数据报表。
|
||||
|
||||
**第四，全维度钻取。**
|
||||
|
||||
在制作报表时，分析师只能依靠经验去判断一个指标有哪些可分析维度。如果BI工具能根据元数据中心提供的所有指标可分析维度，自动根据指标在各个维度下的取值，找出指标波动的原因，那这就是全维度钻取了，它是目前业界最为热门的研究领域，增强分析的一个方向。
|
||||
|
||||
比如，有一个单车租赁公司，发现8月份的营业额下降了，系统通过根据各个维度的数据对比和分析发现，8月份营业额下降，是因为那个月雨天的天数增多导致的。如果分析师不知道用天气的维度去分析营业额，很可能就不知道原因。但是全维度钻取，可以基于数据中台营业额的所有可分析维度，包括天气，自动计算出雨天的销售额相比晴天的销售额低，同时进行交叉分析，发现8月份的雨天数量比其他月份多，最后找到问题的原因。
|
||||
|
||||
你看，数据中台是不是很大程度上增强了BI工具的产品能力？ 在BI 工具的基础上制作数据报表，这才是数据应用的初级阶段，接下来，咱们继续看一下，基于数据中台，我们能做出什么数据产品，提升业务的运营效率。
|
||||
|
||||
## 打造零售行业精益数据运营体系
|
||||
|
||||
零售行业是目前我见过的所有行业中，对数据使用程度最深的行业，所以我会以零售行业为例，带你了解如何借助数据实现精益运营。
|
||||
|
||||
假如你是“贾天真连锁奶茶店”的老板，你的目标是把更多的奶茶卖给更多的人，赚更多的钱。那你要时刻谨记零售行业一个很经典的理论，那就是：人、货、场，在正确的地点，把正确的商品，卖给正确的人。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/95/52/954d9fd8531063b3068c7a5f5b477052.jpg" alt="">
|
||||
|
||||
### 让更多的人，买更多的奶茶
|
||||
|
||||
为了让更多的人，买更多的奶茶，你必须要解决客户拉新和促活的问题。那如何拉新呢？
|
||||
|
||||
获得新用户的方式，一般就是做广告，但是做广告也有很多渠道：
|
||||
|
||||
- 微信公众号；
|
||||
- 抖音；
|
||||
- 快手短视频；
|
||||
- 小区电梯；
|
||||
- ……
|
||||
|
||||
可这么多的广告渠道，到底哪个渠道的广告效果最好，性价比最高呢？数据说了算！
|
||||
|
||||
我们一般用新消用户数、单个新消用户的平均消费金额（新消ARPU）、新消单客成本来衡量各个渠道的广告投放效果。你可以参考这几点，选择最优的广告投放渠道。例如，微信公众号相比快手短视频，每日新消用户数更多、单个新消的平均消费金额更多、新消客成本更低，那你就应该果断选择微信公众号。
|
||||
|
||||
当然，广告中选择的奶茶种类也会在很大程度上影响广告拉新效果。比如高档小区投放广告时，应该选择价格高、健康的饮品；普通小区的话，更加亲民的奶茶才能吸引更多的客户。那如何来选择奶茶的种类呢？还是数据说了算！
|
||||
|
||||
除了根据数据选择奶茶种类之外，广告的投放也要讲究策略，就拿微信公众号这个渠道来说，年纪大的客户群体，注重健康饮品；年轻的客户群体注重价格亲民、口感、样式。所以，必须要基于人群画像（年龄、地区、学历等），决定推送哪些人哪些商品。至于人群画像，需要基于日常的顾客交易数据计算而来。
|
||||
|
||||
不过，光拉新用户，但是如果留不住用户也不行。那么如何让老用户，增加消费奶茶的频率呢？
|
||||
|
||||
我相信你肯定也见过一些套路，比如经常收到一些短信、App站内消息、小程序、微信公众号推送的打折信息，然后没忍住，就“剁手”了。那你有没有想过，这些商家是怎么抓住你的，怎么就知道你喜欢这一款？
|
||||
|
||||
我曾经做过2年的推荐算法，这个算法有一个很经典的论述：大数据可以做到让机器比你自己更了解自己。所以，如果你曾经购买过奶茶，那系统就可以交易行为数据计算出你喜欢的奶茶口味、品类，你平时喜欢在哪家店购买，然后定向把这些店对应的奶茶优惠信息推送给你，这样你大概率会中招！
|
||||
|
||||
你可以看到，店家总是有各种各样的套路促进你消费。
|
||||
|
||||
店家在数据的基础上，一方面可以让新客源源不断，另一方面可以增加老客复购的频率，这时整个奶茶生意的销售额就实现了最大化。
|
||||
|
||||
### 保障奶茶不要断货
|
||||
|
||||
作为老板的你，要让更多的奶茶，卖给更多的人，那前提必须要保障奶茶的充足供应，这就涉及到供应链管理的问题。
|
||||
|
||||
因为奶茶本质上属于生鲜品，如果门店囤货太多，鲜果就会烂掉。但如果缺货，又会影响门店的销售，所以如何在保证不缺货的前提下，尽量减少门店的囤货，这是你必须要解决的问题。
|
||||
|
||||
而供应链涉及到销售、补货、到货和库存四个环节。如果有一款数据产品，可以根据奶茶的实际销售情况和销售计划、结合门店库存的安全水位、采购时间周期，自动计算需要补货的原材料，然后推送给采购系统进行补货，那你是不是会觉得很省心？
|
||||
|
||||
### 实现门店的利润最大化
|
||||
|
||||
当然了，奶茶卖得多不多，还和门店有很大的关系。如果你的店员，可以根据数据，及时发现滞销的奶茶，然后在客户结账的时候，主动推荐这些奶茶，那你就可以获得更高的门店收益。我们一般使用“坪效（每天每平米门店的营业额）”来衡量单个门店的经营状况。
|
||||
|
||||
通过这几点，其实你可以看到，零售行业有很多赚钱的窍门。接下来，我带你了解一下如何基于数据产品，轻松地使用这些窍门。
|
||||
|
||||
### 构建数据产品，实现数据驱动下的精益运营
|
||||
|
||||
数据产品与BI报表最大的不同，在于它们不仅可以实现数据的可视化展示，更为重要的是，可以基于数据，对业务过程进行持续的监控，及时发现问题，进行诊断，并形成决策建议，付诸执行。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/aa/25/aa908bdf3f944ade86c2921548363d25.jpg" alt="">
|
||||
|
||||
数据产品，首先要实现对业务目标的量化。对于卖奶茶来说，你要关注的重点是研发出更多的网红款的奶茶，确保圈住更多的“奶茶粉儿”，同时降低库存周转的压力，因为有越多的滞销奶茶，就会导致积压更多的货物，产生更多的成本。
|
||||
|
||||
为了实现这个目标，你可以用动销率来评估目标的达成。
|
||||
|
||||
>
|
||||
动销率：销售商品的品类数量占库存的商品品类数量的比例。
|
||||
|
||||
|
||||
为了提高动销率，数据产品必须对每个奶茶品类进行销售的跟踪，及时发现零动销的奶茶。
|
||||
|
||||
所以，你可能会经常收到“xxx款奶茶零动销”“xxx款奶茶慢动销”的预警信息，然后接下来你就要对这款奶茶出现零动销进行分析了：数据产品会通过不同季节横向对比这款奶茶的销售情况，也会通过顾客消费问卷去分析这款奶茶的口感，最终找到这款奶茶滞销的原因。
|
||||
|
||||
接下来，你就要根据原因产生决策建议了。比如如果是因为奶茶口感的因素，应该及时下架这款奶茶，否则会影响口碑。数据产品可以推送给运营进行审核，然后运营确认后，一键下线商品，此后各个奶茶店的菜单中，不会再出现该款奶茶。
|
||||
|
||||
当然了，我只是拿零售行业举了个例子，因为很多问题都是共通的，用奶茶店，我总结了一些方法论，你可以结合自己所在的行业去应用：
|
||||
|
||||
- 找到业务问题、量化业务目标，比如，我们找到提高奶茶周转的关键，在于及时发现滞销奶茶品类，那么我们用动销率来衡量业务目标；
|
||||
- 然后要对业务目标持续监控，及时发现问题，比如，我们监控各个品类奶茶的销售情况，及时发现零动销奶茶；
|
||||
- 紧接着，要对问题进行诊断，比如，我们要发现奶茶滞销是因为口感太差；
|
||||
- 当然，还要根据原因形成决策，比如下线这款奶茶；
|
||||
- 最后付诸执行，比如通过一键，在所有门店菜单中去掉了该品类奶茶。
|
||||
|
||||
你看，数据产品实现了从监控问题、发现问题、解决问题的完整闭环。可数据产品毕竟还是按照固化的分析思路进行分析和产生决策建议，在日常运营中，还会有很多数据产品或者数据报表无法解释的问题，这个时候就必须要依赖探索式的数据分析来解决，而探索分析的门槛主要在于获取数据，接下来，咱们就来聊聊自助取数的问题。
|
||||
|
||||
## 让技术人员不再是数据的搬运工，释放取数效能
|
||||
|
||||
对于传统行业来说，BI部门一般有两项职责，一个是做报表，一个是取数。而取数的工作量远远多于报表的工作量。
|
||||
|
||||
一年中做的报表可能就几百张，但是取数，一年可能要取几千次，或者上万次。而大部分传统企业的取数会依赖技术人员，因为他们离数据更近，取数还涉及写代码，所以，如果你是非技术人员，根本不可能基于数据去做探索式的分析。
|
||||
|
||||
所以，大量的取数工作就落在了懂技术的数据开发的头上。
|
||||
|
||||
靠别人取数，会存在大量的沟通和协作的成本，同时因为公共集市层数据不完善，导致无法基于现有的数据，直接完成取数，需要数据开发加工新的数据，所以耗时会非常的长，一般需要一周时间。高昂的取数成本，压制了取数的需求，也导致探索式的数据分析，根本不可能大规模的使用。
|
||||
|
||||
对于数据开发来说，他们更希望自己的工作重心放在建设公共集市层的数据上，因为公共集市层越完善，取数的成本就越低，不需要额外的开发。但是他们忙于临时的取数需求，根本就没有时间和精力去做这些工作。最后就形成了不良循环，越是集市层数据不完善，取数的工作量就会越大（要开发新的模型），越多的时间去临时取数，集市层越没人建设。
|
||||
|
||||
这个问题该如何破解呢？ 我们研发了一个自助取数平台，叫EasyFetch（意为简单取数）。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/c0/f2/c0161537e2ae0d5022ceeac7d0fa09f2.png" alt="">
|
||||
|
||||
这个平台主要有这样几个优点：
|
||||
|
||||
- 用图形化的方式，替代了写SQL的方式；
|
||||
- 提供了对业务人员比较友好的业务过程、指标、维度的概念，替换了表、字段；
|
||||
- 每个指标的业务口径都能够直接显示；
|
||||
- 用户通过选取一些指标和维度，添加一些筛选值，就可以完成取数过程；
|
||||
- 界面非常简洁，使用门槛非常低。
|
||||
|
||||
在实现层面，我们在数据中台里，加工了多个面向不同业务过程的集市层的表，取数平台会自动根据用户选择的度量和维度，去对应的表中关联多张表进行查询，SQL会自动根据查询进行优化，避免非技术人员调试SQL以及写的SQL 质量非常差的问题。
|
||||
|
||||
通过自助取数平台，原先我们数据开发50%的时间都在临时取数，而现在只有10%的时间，在自助取数平台无法满足（需要加工集市层模型）的情况下，帮助用户取数。
|
||||
|
||||
同时，这部分的工作也会对集市层模型的不断优化产生促进作用。对于取数效率来说，原先10个数据开发，一周做100个取数需求，已经是濒临极限。而现在，我们一周有1000多次有效取数的需求在自助取数平台完成，取数效率提升了10倍以上。
|
||||
|
||||
还有一个有趣的现象，我也想分享给你，就是我们发现，在周末，也有很多人在使用取数平台，经过调研，我们发现很多人在基于数据写周报，这是之前完全无法想象的事情。
|
||||
|
||||
最后，我建议你在设计取数平台时，一定要注重简洁、对用户的引导、降低用户的使用门槛。因为我们面临的是非技术人员，我们要拿出做C端产品的姿态去做取数产品。
|
||||
|
||||
## 课堂小结
|
||||
|
||||
这就是今天我要讲的全部内容了，你可以看到，数据中台之上，可以有这么多的数据应用场景，数据可以帮助我们实现这么多原先不可能做到的事情。在课程的最后，我想再强调几个重点：
|
||||
|
||||
- 数据中台对BI 赋能体现在指标口径的一致、任务影响分析、数据报表的成本以及基于数据中台的元数据之上的全维度钻取；
|
||||
- 数据产品实现了从目标量化，持续跟踪，异常诊断，决策建议，最后到执行的完整数据驱动业务目标达成的闭环；
|
||||
- 通过实现面向非技术人员友好的自助取数平台，让数据开发专注于集市模型的构建，可以释放取数的效能，大幅度促进数据的应用范围和深度。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/cd/98/cd21535b991f4266b393ed4562911998.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
今天我主要介绍的都是零售行业数据应用的场景，在其他的行业，比如农业、物流、金融、教育、制造业等等，来谈谈你所在的行业有哪些数据应用的场景，如何来实现业务目标的数据驱动？欢迎在留言区与我互动。
|
||||
|
||||
最后，感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的朋友。
|
||||
150
极客时间专栏/geek/数据中台实战课/实现篇/13 | 数据研发就只是写代码吗？.md
Normal file
150
极客时间专栏/geek/数据中台实战课/实现篇/13 | 数据研发就只是写代码吗？.md
Normal file
@@ -0,0 +1,150 @@
|
||||
<audio id="audio" title="13 | 数据研发就只是写代码吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e6/3d/e69137f0509594b61f6794776140323d.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
到现在，我已经讲了10几个数据中台的工具产品，除此之外，我还提到了数据产品、数据架构师、数据开发、应用开发、分析师……多个角色。既然数据中台要用到这么多工具，又涉及这么多角色，如果没有配套的协同流程和规范，那也没办法达到数据中台高效、高质量、低成本的建设目标。来看几件有意思的事儿。
|
||||
|
||||
郝有才（数据开发）修改了数据中台一个数据加工任务，变更了产出的数据表字段，因为没有通知到下游数据的负责人，结果影响了10多个任务，大量数据应用出现异常。这属于比较典型的“协作事故”，咱们再接着看一个跨团队之间协作的问题。
|
||||
|
||||
张漂亮（业务系统的服务端开发）今天业务上线，她提交了数据库变更工单，修改了商品交易明细表的商品类型枚举值。但这个升级并没有通知数据部门，结果导致基于商品类型计算的多个指标数值出现错误，严重影响了第二天多个数据产品的数据产出。
|
||||
|
||||
这些教训告诉我们，建设数据中台是一项系统性的工程，**你不但要有技术的思维，更要有管理者的视角。**所以接下来，我会带你了解数据中台中三个最常见的协作流程：数据研发、数据分析、资产管理。**我们一起看一下，不同角色使用场景化的工具产品是如何进行高效协作的？**
|
||||
|
||||
因为流程协作涉及的料也很多，我会用两讲的时间来讲这部分内容。今天，我们就先从数据研发的场景讲起，如果你是一名普通的数据开发，你肯定很熟悉下面的这些场景。
|
||||
|
||||
当然，在学习的过程中，我建议你关注这样几个重点，因为它们对于你理解一个协作流程如何运转非常关键：
|
||||
|
||||
- 一个流程中涉及到了哪些环节？
|
||||
- 这些环节涉及到哪些角色参与？
|
||||
- 承载这个场景的工具产品是什么？
|
||||
- 这些环节之间是如何衔接的？
|
||||
|
||||
话不多说，开始今天的内容。
|
||||
|
||||
也许在很多人的印象中，数据研发就是写代码，其实对大规模、标准化的数据建设来说，这远远不够。在网易，标准的数据研发流程包括四个阶段：需求阶段、开发阶段、交付阶段和运维阶段。每个阶段中又涉及多个环节，如果你缺失了这些环节，就很容易出问题，数据也会因此没办法高效、高质量的交付。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/13/fc/135074b35571f137b6299fcf058d12fc.jpg" alt="">
|
||||
|
||||
## 需求阶段
|
||||
|
||||
需求是数据开发的起点。如果想让后面的流程高效运作，那需求的定义一定要清晰，这样协作者（数据开发、应用开发、数据产品/分析师）对需求的理解才能一致。
|
||||
|
||||
在数据中台中，数据需求通常是以指标的形式出现的，比如李天真提了个需求（计算每日黑卡会员的消费额），而承载这个场景的产品就是我们[05讲](https://time.geekbang.org/column/article/223715)的指标系统。
|
||||
|
||||
那什么时候会提需求？又什么时候会频繁用到指标系统呢？
|
||||
|
||||
一般来说，分析师在制作新的报表，数据产品经理在策划新的数据产品时，会提一些新的指标需求，然后就会在指标系统登记指标（包括指标的业务口径、可分析维度、关联的应用、时间周期信息）。这个时候，指标的状态就是待评审状态。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/1d/60/1db47733f4f29b293afa34485ce00b60.jpg" alt="" title="指标系统需求登记示意图">
|
||||
|
||||
然后，管理指标的数据产品（没有这个角色的，分析师也行）会叫上相关的数据开发、应用开发、提出这个需求的分析师或者数据产品，对指标进行评审：
|
||||
|
||||
- 指标是新指标还是存在的指标；
|
||||
- 如果是新指标，那么是原子指标还是派生指标；
|
||||
- 确认指标业务口径、计算逻辑和数据来源。
|
||||
|
||||
那评审后的结果又是什么呢？
|
||||
|
||||
- 如果是新指标，就在指标系统上录入相关信息，指标状态是待开发状态；
|
||||
- 如果是存在的指标，应用开发可以直接找到这个指标所在的表，然后看这个表是否已经有现成的接口可以被直接使用，如果有，就直接申请授权，如果没有，可以基于这张表发布一个新的接口。
|
||||
|
||||
## 研发阶段
|
||||
|
||||
现在，新指标的状态是待开发状态，接下来就要进入开发阶段。在这个阶段，你要秉持“先设计，后开发”的理念。为啥这么说呢？
|
||||
|
||||
因为很多开发都习惯边开发、边设计，想到哪里，代码写到哪里，这其实并不是一个好习惯。这会造成缺少整体的设计，开发过程中经常出现表结构频繁修改、代码返工、整体研发效率不高。
|
||||
|
||||
所以说，我们要先做好模型的设计，而承载这个场景的工具产品就是[06讲](https://time.geekbang.org/column/article/224516)的模型设计中心。**这里我再强调一下，**数据开发在设计的过程中，可能要用到一些已经存在的数据，这时就要利用数据地图发现已经存在的表，然后理解这些表中数据的准确含义。
|
||||
|
||||
除此之外，在模型设计过程中，要对模型中每个字段关联前面设计好的指标，以及可分析的维度。比如，我们对下图的account字段，标记为指标“用户消费金额”，user标记为“买家维度”。这个标记会把模型和指标建立关联关系，然后把前面设计的指标落实到了表中。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b6/f4/b6acb7c9ce4f37118d8dce82bcbd83f4.jpg" alt="" title="模型设计中心，新建模型示意图">
|
||||
|
||||
到这一步，模型设计还不算完，数据开发还要提交模型上线工单。工单会根据模型所属的主题域，流转到对应域的负责人，并通知对应域负责人进行审批。审批通过后，模型会自动发布到生产环境。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/2d/78/2dde6ba76dca0bcdb066293c0a279978.jpg" alt="" title="模型发布上线工单示意图">
|
||||
|
||||
这里你要注意一下，数据域的负责人一般是数据架构师，他需要检查数据是不是重复建设，要保证自己管理的域下模型设计的相关复用性、完善度、规范性的相关指标。
|
||||
|
||||
当然了，除了新建模型之外，已有模型也会存在变更的情况（比如增加一个字段或变更字段枚举值）。这个时候，要根据数据血缘，通知所有依赖这个表的下游任务的负责人，在负责人确认以后，才能进行模型变更。
|
||||
|
||||
比如，甄可爱是一名数据开发，她接到需求完成模型设计之后，就要开始模型的开发了。首先她要把数据从业务系统导入数据中台中，那她第一步就要申请对应数据库的权限，然后在数据传输中心建立数据传输任务，把数据同步过来。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/db/aa/dbb914bcbde0af3a383488d9ff8b48aa.jpg" alt="">
|
||||
|
||||
接下来，要清洗和加工数据，那她要在数据开发中心开发数据的ETL任务，根据之前模型设计，编写对应任务的代码。
|
||||
|
||||
任务代码完成以后，甄可爱要在数据测试中心，验证数据：
|
||||
|
||||
- 一个是进行数据探查，确定新加工的数据是否符合预期；
|
||||
- 另外一类是对原有模型的重构，新增字段或者更新部分字段。此时不仅要验证新加工数据的正确性，还要确保原有未修改数据与修改前是否有改变，我们管它叫数据的比对。
|
||||
|
||||
数据测试中心还提供了静态SQL 代码检查的功能，主要是发现一些使用固定分区、使用测试环境的库、使用笛卡尔积等代码问题，我们把这个过程叫SQL Scan。 在我们的开发规范中，只有通过SQL Scan的代码才被允许发布上线。
|
||||
|
||||
在数据测试完成后，甄可爱还要在数据质量中心里配置稽核校验规则。目的是对任务产出的数据进行校验，在数据出现问题时第一时间发现问题，快速地恢复故障。
|
||||
|
||||
在开发规范中，主键唯一性监控、表行数绝对值以及波动率监控等属于基础监控，是必须要添加的，另外还需要根据业务过程，添加一些业务规则，比如一个商品只能归属一个类目等。
|
||||
|
||||
配置完稽核规则，甄可爱要任务发布上线了。任务发布上线，要设置调度周期，配置任务依赖，设置报警规则以及报警对象，选择提交的队列。
|
||||
|
||||
任务发布与模型发布一样，也需要进行审核。首先甄可爱需要发起任务发布上线的工单，然后工单会根据产出表所在域流转到对应域负责人贾英俊审批，审批的主要内容：
|
||||
|
||||
- 确认任务参数设置是否合理，比如Spark Executor 分配内存和CPU资源；
|
||||
- 检查任务依赖、报警设置是否正确，核心任务必须要开启循环报警，同时要开启报警上报；
|
||||
- 重点审核稽核规则是否完备，是否有缺失需要补充。
|
||||
|
||||
在审批通过以后，任务就会发布上线，每天就会有数据源源不断的产生了。
|
||||
|
||||
到这里，甄可爱就完成了所有模型研发的流程了。你看，虽然是一个模型研发的环节，可涉及这么多的工具产品，还包括了多个审批流程，但是这些工具和流程，都是标准化研发不可或缺的。例如如果不测试，就会导致大量的BUG上线，如果没有稽核监控规则配置，就会导致出了BUG还不知道，等着被投诉。
|
||||
|
||||
而数据研发完，接下来就是数据的交付了，如何让数据快速接入到数据应用中呢？
|
||||
|
||||
## 交付阶段
|
||||
|
||||
在数据中台之前，其实并不存在单独的交付阶段，因为数据开发加工好数据应用需要的表，他的工作就已经结束了，剩下的就是应用开发的事儿了。应用开发需要把数据导出到应用所属的数据库，然后开发API接口，供客户端调用。
|
||||
|
||||
数据中台，提出了数据服务化的思想，数据中台暴露的不再直接是数据，而是服务。数据开发不仅需要加工数据，还需要把数据发布成API接口或者其他服务形式，提供给业务系统或者数据产品调用，从而形成了单独的数据交付阶段。
|
||||
|
||||
数据服务承载了数据交付的整个流程。数据开发，可以直接选择一张数据中台的Hive表，然后在数据服务上创建一个数据抽取任务，把数据抽取到中间存储中（中间存储可以是DB，KV，MPP等）。这个过程，数据服务会自动根据中台数据的产出时间，在调度系统中创建数据导出任务，建立到产出任务的依赖。
|
||||
|
||||
接下来，数据开发可以基于中间存储发布API接口，定义输入和输出参数，测试API后发布上线。这个时候，数据开发的工作才算完成。
|
||||
|
||||
最后，应用开发在数据服务上创建应用，然后申请对该接口的授权，等数据开发审批通过后，就可以直接调用该接口获取数据了。
|
||||
|
||||
数据交付完呢，还不算完，接下来数据开发的工作，还需要保证任务的正常运行，这就进入了第四个阶段，运维阶段。
|
||||
|
||||
## 运维阶段
|
||||
|
||||
承载运维阶段的工具产品主要是任务运维中心。
|
||||
|
||||
在这个阶段的第一责任人是任务负责人（一般是这个任务对应的数据开发）。这里有这样几个过程：
|
||||
|
||||
- 数据开发接到报警后，要第一时间认领报警；
|
||||
- 任务运维中心提供了报警认领的功能，数据开发点击认领，代表数据开发开始处理这个报警；
|
||||
- 如果报警迟迟没有人认领，任务运维中心会每隔5分钟会发起一次电话报警，直到报警认领；
|
||||
- 如果报警一直没有认领，系统会在3次报警，15分钟后进行报警的上报，发送给模型所在域的负责人。
|
||||
|
||||
这样的机制设计，确保了报警能够在第一时间被响应，我们在实施这项机制后，报警的平均响应时间从2个小时缩短到15分钟内。
|
||||
|
||||
那么当数据开发认领报警之后，需要开始排查，首先要确认上游依赖任务稽核规则是否有异常（也就是输入数据是否存在异常）。如果没有异常，数据开发要通过任务运行日志，排查当前任务的问题原因，并进行紧急修复，接下来再重跑该任务，任务重跑完，还要通过数据地图，找到所有依赖该表的下游任务负责人，发送“下游任务需要进行重跑”的通知。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b6/98/b6c56a1812116b9961a443ca6e11ab98.jpg" alt="" title="数据地图通知下游任务负责人示意图">
|
||||
|
||||
故障恢复完，还要进行复盘，其中重要的事情就是补充稽核规则，确保不再出现犯过的错误。通过这样不断沉淀和记录，数据中台的数据质量就会越来越高，数据质量问题也会减少。
|
||||
|
||||
## 课堂总结
|
||||
|
||||
你看，数据研发不仅仅只是写代码这么简单吧？在这四个阶段中，你经常容易忽略的是需求阶段和交付阶段，如果需求定义不一致，就很容易导致后面的研发返工，如果没有标准的数据交付流程，就会数据接入慢，同时交付后维护的复杂度会增加。我再强调两个重点：
|
||||
|
||||
- 数据研发的需求是从指标的规范化定义开始，数据产品、数据开发和应用开发要建立一致的指标业务口径、计算逻辑和数据来源，从而才能确保需求被高质量的交付；
|
||||
- 数据服务承载了数据标准化交付的功能，通过发布成服务API的方式，把数据中台的数据接入到数据产品中。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/b5/a9/b5dded288ffee1c3b09fdd6b566efda9.jpg" alt="">
|
||||
|
||||
数据研发好之后，数据就要被使用了，下一节课，我们再以数据使用者的角度以及数据资产管理的视角，带你了解后面两个流程：数据分析流程，带你看一下数据是如何被使用的；然后是资产管理流程，看一下如何有效的实现精细化的资产管理。
|
||||
|
||||
## 思考时间
|
||||
|
||||
在你日常的数据建设中，遇到过哪些因为流程协作导致的问题呢？ 欢迎你在留言区与我互动。
|
||||
|
||||
最后，感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的朋友。
|
||||
123
极客时间专栏/geek/数据中台实战课/实现篇/14 | 数据被加工后，你还要学会使用和管理数据.md
Normal file
123
极客时间专栏/geek/数据中台实战课/实现篇/14 | 数据被加工后，你还要学会使用和管理数据.md
Normal file
@@ -0,0 +1,123 @@
|
||||
<audio id="audio" title="14 | 数据被加工后，你还要学会使用和管理数据" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4c/db/4c6efca891b6b89e5f5b476217508cdb.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
上一讲，我讲了数据研发的四个阶段，你可以发现，标准化的研发流程对交付高效、高质量的数据来说非常关键。那么数据被加工好以后，怎么使用数据和管理数据就是重点了。
|
||||
|
||||
所以今天，我会从数据使用者的角度出发，聊一聊怎么构建高效的数据分析流程。同时，也会以资产管理者的视角，带你了解怎么实现数据资产的精细化管理。
|
||||
|
||||
我希望你通过学习今天的内容，判断一下日常工作中自己在数据使用和管理方面是不是还存在流程环节上的缺失，并不断完善，让数据使用、管理得更好。
|
||||
|
||||
## 落地高效的数据分析流程
|
||||
|
||||
根据我的经验，我把数据分析过程划分五个步骤。接下来，我通过分析师甄可爱的例子，为你呈现了一个典型的数据分析流程。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/2c/1f/2c77d0e41fefdac7a5c23ca7d6ba781f.jpg" alt="">
|
||||
|
||||
**第一步：发现业务问题。**
|
||||
|
||||
数据分析的典型场景呢，起点都是业务出现了某个问题，我们需要基于数据找出业务问题背后的原因。
|
||||
|
||||
分析师甄可爱所在的公司，电商平台Q2季度某个品类的商品销售额下降了30%，老板要求给出问题的原因，并进行整改。这个任务落到了她的身上。 要解释这个问题，她必须要从现有的数据入手，看看到底是哪里出现问题。
|
||||
|
||||
**第二步：理解数据。**
|
||||
|
||||
她首先要了解这样几点：
|
||||
|
||||
- 要分析的业务过程；
|
||||
- 这些业务过程中涉及到了哪些关键指标；
|
||||
- 这些指标的业务口径是什么；
|
||||
- 有哪些可以分析的维度。
|
||||
|
||||
这些事儿比较琐碎，甄可爱为了提高效率，利用指标系统，将要分析的业务过程快速锁定到交易域下的业务过程，然后找到交易域下有哪些指标。通过指标系统，她了解了“渠道销售额”这个指标的口径定义、计算逻辑和数据来源。
|
||||
|
||||
接下来，她要去查看指标对应的数据，借助指标系统，甄可爱可以直接跳转到指标关联到数据报表上，接下来她需要申请报表的权限，查看数据。报表负责人审批通过后，甄可爱就可以看到数据了。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/60/a7/607131bf2b7573e9ec61c3c0b3b9f2a7.jpg" alt="" title="数据地图导览示意图">
|
||||
|
||||
这个时候她发现，淘宝渠道销售额数据出现下降，拖累了整体品类销售额的数据。可是当她想进一步探查渠道下降的原因时，却发现并没有渠道级别的商品库存和销售指标。现在，靠现有的指标和数据已经没办法进一步解读业务问题的原因了，甄可爱需要进行探索式分析。
|
||||
|
||||
**第三步：探索式分析。**
|
||||
|
||||
那她首先要找到当下有哪些数据可以用，借助数据地图，她可以快速了解当前主题域下有哪些表，这些表分别代表什么含义。
|
||||
|
||||
这个时候，会存在两种情况：
|
||||
|
||||
- 如果现有的数据可以满足分析的需求，她可以直接在数据地图表详情页上发起数据权限的申请流程；
|
||||
- 如果现有的数据没办法满足需求，甄可爱就要对数据开发提出数据研发的需求，会稍显麻烦。
|
||||
|
||||
幸运的是，甄可爱发现，商品粒度的库存和销售表中有渠道的字段，按照渠道进行聚合、过滤，就可以满足分析的需求了。所以，她在数据地图的相关表详情页里申请了这些表的权限。
|
||||
|
||||
接下来，权限申请流程会流转到表对应的负责人上：
|
||||
|
||||
- 对于核心表（比如交易数据），除了表负责人审批，还需要中台负责人审批；
|
||||
- 核心表中的一些核心KPI数据（比如平台全年销售额），还需要CTO甚至CEO级别的审批。
|
||||
|
||||
等了一段时间，权限审批终于通过，甄可爱收到了来自权限中心的通知，于是她马不停蹄地在自助分析上，基于SQL 对相关表进行了探查分析。甄可爱对比分析后发现，淘宝渠道销售数据下降的主要原因是：该品类下的部分畅销商品经常库存为0，出现缺货情况，导致整体品类销售额下降。
|
||||
|
||||
**第四步：可视化展现。**
|
||||
|
||||
现在，找到了问题原因，为了给老板讲清楚分析过程，甄可爱还要通过报表的方式，把分析过程呈现出来。所以，她又在BI工具网易有数上进行了报表的制作，把报表授权给相关的管理层。
|
||||
|
||||
看到了原因后，管理层制订了供应链优化措施，加大了淘宝渠道的库存供货，整体品类销售额数据出现回升，终于解决了问题。
|
||||
|
||||
**第五步：分析过程产品化。**
|
||||
|
||||
解决了现有问题，并不是数据分析的终点。我们还要建立长久的问题发现和解决机制。
|
||||
|
||||
为了持续地监控该问题，并对其进行智能预警，甄可爱需要将分析过程固化到数据产品中。她策划并研发了供应链决策协同系统，能够自动检测商品的库存和销售，智能生成补货建议，然后推送给采购系统。
|
||||
|
||||
到此，整个数据分析的全过程就完成了。最后，我想再强调一个点，在这五个步骤中，你往往最容易忽略是最后一个步骤。当然，这也并不只是分析师的疏忽，本身数据产品的建设还需要有一定的研发资源的投入。
|
||||
|
||||
为了解决大规模数据产品研发资源投入的问题，在网易，我们基于网易有数（BI工具）实现了数据门户的功能，它实现了一个低代码构建数据产品的开发环境，允许分析师通过拖拉拽的方式构建企业数据门户，从而为高效的大规模数据产品构建提供了基础。基于数据门户，企业可以构建商品运营系统、供应链协同决策系统、流量看板系统、会员运营管理系统等不同的数据产品，满足不同场景下数据分析的需要。
|
||||
|
||||
数据如何被使用讲完，接下来，我还想来谈谈数据的精细化管理流程，因为这个流程或者环节的缺失，会导致很多成本、安全、以及稳定性的问题。
|
||||
|
||||
## 构建精细化的资产管理流程
|
||||
|
||||
在数据中台中，数据资产的精细化管理主要包括成本治理和资产管理两个部分。在网易，我们分别研发了两个工具产品来完成上述管理流程的落地，分别是成本治理中心（简称EasyCost）和数据管理中心（简称EasyManager）。
|
||||
|
||||
下面我们通过资产管理员李无邪的视角，来看看上述两个工具产品日常是如何运转的。
|
||||
|
||||
李无邪首先要登录到EasyCost中，然后制订数据自动下线的规则，比如，他认定30天内没有访问的数据需要下线。然后系统会根据规则，每天自动将符合规则的表和目录推送给表的负责人，等待表的负责人审核确认。
|
||||
|
||||
表的负责人张美丽接到了EasyCost 推送的邮件，此时一般有两种情况：
|
||||
|
||||
<li>
|
||||
第一种，是该数据虽然没有被使用但是属于核心资产，以后用的上，需要保留，此时可以申请加入白名单中，由资产管理员李无邪审批后，不再被推送。
|
||||
</li>
|
||||
<li>
|
||||
第二种情况，是该数据确实没有被使用了，那张美丽就点击一键下线，然后系统会进行数据的灰度下线，首先会先停止调度任务，数据不再产出，7天后，数据会被自动清理。在下线前，可以选择是否保存备份。
|
||||
</li>
|
||||
|
||||
为主题域的负责人和数据团队的管理者，同样也会收到EasyCost推送的面向主题域和数据中台整体的表的使用情况，从管理者的角度，也可以对下形成治理的压力，把成本治理纳入到数据开发的绩效考核中。
|
||||
|
||||
接下来，我们讲讲资产管理部分。资产管理的核心是数据资产等级的制订，李无邪需要为数据中台的数据制订资产等级规则。
|
||||
|
||||
李无邪要依据两方面的因素，制订资产等级的标记规则：
|
||||
|
||||
- 一方面是数据本身涉及企业的核心机密，比如KPI、产品日活、毛利等；
|
||||
- 另外一方面因素是根据数据应用的优先级，然后基于全链路的数据血缘制订数据的等级。
|
||||
|
||||
数据等级可以与数据权限的审批流程、模型和任务发布上线的审批流程打通，根据不同的资产等级，需要不同级别的角色来完成审批。另外，数据资产等级还与数据备份策略相关，对于核心数据，我们要求必须实施备份。
|
||||
|
||||
此外，数据中台的小文件也需要关注，因为如果小文件过多，会导致HDFS 元数据过大，对HDFS的元数据服务NameNode产生性能问题。所以EasyManager同样需要对小文件的数量和分布进行监控，然后推送给各个主题域和表的负责人，同时系统提供了小文件合并的工具，可以帮助数据开发快速的完成小文件的治理。
|
||||
|
||||
## 课堂小结
|
||||
|
||||
今天这节课，我带你重点了解了如何构建高效的数据分析流程，和如何实现精细化的资产管理流程。
|
||||
|
||||
通过这两讲内容的学习，我相信你就不会觉得，面对这么多的工具产品，不知道该怎么用！涉及这么多人，又不知道什么人该干什么事儿了。同样，你也可以把前面提到的工具和角色串联起来，形成一个可落地运行的机制，应用到你日常的数据建设工作中。
|
||||
|
||||
在最后，我想再强调几个重点：
|
||||
|
||||
- 数据分析的完整流程应该从了解业务数据，到探查式分析，再到通过数据报表进行可视化呈现，最后通过数据产品固化场景，实现持续监控、自动生成决策建议，一键执行的目标；
|
||||
- 资产管理流程中，资产管理员的主要职责在于制订规则，包括数据或者报表下线的规则，数据资产等级的规则，目的是凸显数据的资产属性，聚焦核心数据。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/cb/b2/cb9eb41313f04fe00a15a6adf10f86b2.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
数据研发、数据分析以及资产管理是数据中台中三个基本流程，除了这些，你还知道有哪些别的流程需要涉及到多个角色的协作？ 如果需要通过一个工具产品，流程协作中心来完成上述协作流程，你觉得该如何设计这个产品呢？
|
||||
|
||||
欢迎在留言区与我互动。最后，感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的朋友。
|
||||
166
极客时间专栏/geek/数据中台实战课/实现篇/15 | 数据中台在网易电商业务的最佳实践.md
Normal file
166
极客时间专栏/geek/数据中台实战课/实现篇/15 | 数据中台在网易电商业务的最佳实践.md
Normal file
@@ -0,0 +1,166 @@
|
||||
<audio id="audio" title="15 | 数据中台在网易电商业务的最佳实践" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/af/3f/af38e89e69f0d37dfa4f6a4039872e3f.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
从OneData 到 OneService、从方法论到支撑技术、从宏观架构到微观实现，我已经带你系统地了解了建设数据中台的所有核心知识点。你可以看到，虽然人人都在讨论数据中台，但是真的实战起来，还是不简单吧？
|
||||
|
||||
而且建数据中台是一项系统性的工程，涉及人员组织架构的变动，需要研发大量的系统支撑工具，更要和业务部门达成密切的合作，形成双赢，反之会有失败的风险。还是分享一件我见过的事儿。
|
||||
|
||||
甄英俊是某零售企业IT部门的老大，最近他也想在企业中建数据中台。设想一番后，他亲自操刀，组建了新的数据中台部门，还亲自规划了十个业务场景（包括会员看板、商品运营、供应链管理、售后管理、毛利分析、类目管理、门店管理、仓储管理、渠道分析、辅助选品）。
|
||||
|
||||
但数据中台团队没有和业务部门达成一致的KPI，在具体工作推进过程中，中台团队与业务部门脱节，业务部门也没有资源支撑中台的推进（例如指标的梳理）。
|
||||
|
||||
最后，虽然基于原先规划的十个场景，数据中台确实做出了一些报表，但很少有人查看。于是，尴尬的一幕发生了：在年终总结汇报中，甄英俊自信地向CEO汇报了数据建设的成果（输出了多个报表，覆盖了多少业务场景）。可当CEO问业务老大是否感觉到数据的作用？业务老大摇了摇头，他们并没有认可数据中台的成果。
|
||||
|
||||
这是一个很典型的失败项目，而问题的根源就在于数据中台团队虽然独立于业务，但是并不能脱离业务。 甄英俊最大的失误就是没有深入调研业务问题，也没有和业务达成一致的KPI，更没有根据业务的反馈，不断完善数据应用。
|
||||
|
||||
所以，如果你要建中台，要做到这样几点：
|
||||
|
||||
- 问问自己为什么要建中台，与业务达成一致的目标；
|
||||
- 把数据中台作为一个公司级别的顶级项目来推进，而不是一个数据部门自己的KPI；
|
||||
- 数据中台必须要有清晰的、可量化的价值来衡量（从主观上也要得到业务部门的认可）。
|
||||
|
||||
而今天这节课，我会从项目立项、到项目推进，最后到项目总结，带你看一下网易电商数据中台的构建过程。这样一来，你会明白如何在企业一步一步落地数据中台，这对想要建设数据中台的你来说，非常有借鉴意义。
|
||||
|
||||
## 立项数据中台项目
|
||||
|
||||
我认为，立项是建数据中台最关键的一步，因为它的核心就是挖掘业务的痛点，跟业务达成一致的建设目标。**如果能达成一个一致的、可量化的目标，数据中台的项目就成功了一半。**
|
||||
|
||||
所以在网易电商数据中台构建之前，我们（数据部门）对业务方（包括市场、商品、供应链、仓配、售后、会员等）进行了密集的调研，尤其是跟各个部门的老大了解了这样两个方面：
|
||||
|
||||
- 当前数据使用过程中存在哪些痛点；
|
||||
- 当前业务部门最关注的业绩目标。
|
||||
|
||||
这里我多说几句，对一些传统企业来说，业务部门的数据思维能力比较薄弱，数据使用水平还比较初级，根本讲不出什么痛点。如果遇到这种情况，你要多关注一下业绩目标（比如，如何让数据帮助企业达成KPI）。 如果谈论这种话题，业务部门的老大一定很感兴趣。
|
||||
|
||||
经过调研，我总结了这样几个痛点。
|
||||
|
||||
**第一，指标业务口径不一致。**
|
||||
|
||||
在建数据中台前，网易电商已经有20多款数据产品，它们涉及800多个指标，存在大量业务口径不一致的情况，导致了数据不可信、无法用。你看，虽然数据产品不少，但是真正发挥价值的却寥寥无几。其实这还没算数据报表，如果把报表算进来，就更夸张了。
|
||||
|
||||
**第二，需求响应速度慢。**
|
||||
|
||||
在电商平台中，业务部门运营活动的规模和频率大大提高，原先可能一个月才一次促销活动，现在是一天一次，甚至还有小时级别的。淘宝上一双NewBalance的鞋子，前一个小时还是599，下一个小时就成了429，而这背后其实是大量的商品运营策略在发挥作用。
|
||||
|
||||
活动一开始，运营人员就需要分析大量的数据，从而不断优化运营策略。此时，数据部门会收到大量的数据研发需求。而我们统计后发现，数据部门一个需求的平均交付时间是一周（数据来源于项目管理工具JIRA），根本没办法满足业务部门的需求，可以这么说，数据研发的速度已经无法支撑业务高频的运营活动。
|
||||
|
||||
**第三，取数效率低。**
|
||||
|
||||
我们问了很多的分析师、运营，他们集中认为取数效率太低，原因有两个。
|
||||
|
||||
一个是他们不知道有哪些数据，也不知道到哪里去找数据。当时整个电商团队存在三个小数仓（供应链、市场和仓配客）加起来有近4W张表，对他们来说，找到并准确理解数据，其实是非常困难的事情。
|
||||
|
||||
另一个是，基于SQL取数，对于非技术人员来说，门槛比较高。分析师经常遇到一个SQL异常就不知所措，更不要说不懂SQL的运营。
|
||||
|
||||
正是因为这两个原因，取数要靠数据开发帮助完成，效率很低。有多低呢？平均取数需求从提出到交付，需要一周（数据来源于项目管理工具JIRA）。而这也抑制了数据的大规模使用，与此同时，临时取数的需求，占据了数据开发的大量时间（来自JIRA的数据统计，数据开发50%的时间都被临时性的取数需求占据）。
|
||||
|
||||
**第四，数据经常违反常识。**
|
||||
|
||||
糟糕的数据质量也是各个业务部门对数据最为不满的地方，经过POPO群统计（网易内部办公协作通讯工具），平均每周，我们就有10个数据质量问题被业务方投诉。
|
||||
|
||||
更为可怕的是，这些问题中，90%都是由业务方先于数据提供方发现的问题，然后50%都是因为数据研发的BUG导致。在当时，我们经常出现数据经常无法按时产出，数据修复需要花费一天的时间！
|
||||
|
||||
**第五，数据成本指数级增长。**
|
||||
|
||||
2018年，电商业务的大数据资源从一年4000CU(1 CU = 1 Core + 4 memory) 增长到12000CU，并且还在持续高速增长。当时正好是2018年底，公司对业务毛利这块儿管控得非常严格，精简成本作为了各个业务推进的优先级，大数据这块也不例外。
|
||||
|
||||
为了优化大数据的成本，我们排查后发现，至少有20%的数据在当时都属于废弃数据，这些数据每天仍在产生，却没有人访问，浪费着资源。
|
||||
|
||||
除了现有数据是否用得好以外，我们也对各个部门的业务目标进行了调研，目的就是让数据帮助解决更多的业务问题。
|
||||
|
||||
<li>
|
||||
**商品部门：**主要目标是优化商品结构、降低滞销商品比例、提高商品库存周转，从而达到控制毛利水平的目标。所以他们最紧急的就是监控平台上滞销的商品。
|
||||
</li>
|
||||
<li>
|
||||
**供应链部门：**主要目标是尽可能保证商品的供货充足，尽量避免缺货商品出现。所以及时发现缺货商品，制订更精准的采购计划是最紧急的事儿。
|
||||
</li>
|
||||
<li>
|
||||
**仓配客部门：**最重要的业务目标是保障商品及时送达，优化物流成本。所以，基于各个仓库的数据和物流公司的报价，制订最合理的配送计划，是他们最重要的事儿。
|
||||
</li>
|
||||
|
||||
有了这两方面的调研之后，我们下一步的目标制订就会顺利很多，最后，我们从效率、质量和成本三个方面，和业务部门制订了共同的KPI。同时又因为当时整个电商业务的核心方向是控制毛利水平，提高商品周转，所以在业务目标上，我们选择了与之最相关的商品和供应链部门进行合作，共背业绩KPI。
|
||||
|
||||
这里我提供给你一份数据中台KPI考核表格，希望你能参考一下，数据中台部门考核KPI应该包括哪些内容。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/e2/45/e2cd612d3eee288530efc8bdf16d5d45.jpg" alt="" title="数据中台 业绩KPI 目标（参考）">
|
||||
|
||||
你看，这个表里包含中台建设和业务支撑两部分，前者对应的是业务痛点，后者对应的是业务目标。更为关键的是，我们都是从业务出发制订的这两部分内容，我认为这是业务愿意和中台团队达成共建KPI的基础。
|
||||
|
||||
后来，在CTO的推动下，供应链、仓配以及市场部门把指标梳理、自助取数、数据模型迁移中台纳入了KPI考核。当然，对数据中台的支撑工作，这部分在业务部门的KPI中比例不会很高，一般最多20%，但是却很重要，因为只有这样，业务部门才有压力去做这个事情。
|
||||
|
||||
以上就是立项阶段了，在这个阶段里，我们从挖掘业务痛点，到输出共建目标，接下来，我们就来看一看这个目标是怎么落地的。
|
||||
|
||||
## 推进数据中台项目落地
|
||||
|
||||
我会从四个方面带你了解数据中台的落地过程，这部分内容，会帮你把前面12讲串起来，并形成企业落地执行方案。
|
||||
|
||||
**第一步，调整团队组织架构，明确各个团队的职责。**
|
||||
|
||||
在数据中台构建之前，电商业务主要存在3个独立的数仓：市场、供应链和仓配客。这些业务部门中有数据开发、数据产品还有分析师。
|
||||
|
||||
而我们首先要做的，就是成立数据中台团队，这个团队是在原有市场数仓（除了服务市场，还服务于管理层）的基础上建起来的。
|
||||
|
||||
而对供应链和仓配客，我们并没有立即把他们的数据开发团队并入中台团队，而是调整了团队职责，把他们的数据开发的职责调整成，基于数据中台数据，加工私有的集市层和应用层。
|
||||
|
||||
这样处理的话，各方比较容易接受，不然业务部门会觉得中台团队在抢他们的人，对于员工个人，也可能因为团队定位、福利等原因不愿意转部门。
|
||||
|
||||
建立数据中台团队之后（主要由3名数据产品和15个数据开发构成），接下来就是明确团队的职责。数据中台主要负责DW层公共数据，以及跨部门共享的集市层和应用层的数据建设。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/62/1c/62199242b5b44685c912ae22fca96f1c.jpg" alt="" title="数据中台团队与业务部门分工示意图">
|
||||
|
||||
**第二步，数据整合。**
|
||||
|
||||
中台团队成立后，首先面对的是混乱的指标业务口径，所以团队要先梳理指标，建立全局的指标管理规范（对应咱们的05讲）。这项工作由1名数据产品牵头，2名数据产品辅助，对电商分布在各个业务线的20多个数据产品，800多个指标进行了梳理，去除了冗余指标，对齐口径不一致的指标。
|
||||
|
||||
最后，我们把指标梳理成400个，其中，原子指标127个，这个过程花了1个月的时间，不过大部分时间都是在理解业务，和业务的分析师、数据产品对口径。
|
||||
|
||||
接下来，中台团队还要对模型进行重构、整合和迁移（对应咱们的06讲），而这部分工作可以分为设计阶段和实施阶段。
|
||||
|
||||
设计阶段，由一名数据架构师牵头，根据梳理好的指标，构建主题域，然后在原有模型的基础上进行重新设计，构建一致性维度。**这里需要强调的是，**中台团队必须要完全接管ODS层数据，这可以强迫业务部门必须要基于中台数据进行再加工。当然，中台团队会肩负着巨大的压力，但是只有熬过最痛苦的时期，这种中台的机制才能建立起来，**一旦原始数据没有管住，那中台就会功亏一篑。**
|
||||
|
||||
实施阶段需要投入大量的人力，但是中台团队还承担着公共数据需求的研发，所以为了保证模型重构和迁移的进度，我们从15个数据开发中拆出了5个人，专门进行模型的重构和迁移。最终，我们完成了200多张表的基础数据的迁移重构，而这个过程花费了近5个月的时间。
|
||||
|
||||
**第三步，研发工具产品。**
|
||||
|
||||
在数据中台构建过程中，我们积累了很多规范和经验，但数据中台如果要形成落地、长久的运行机制，就必须把这些规范和经验沉淀到产品中，通过产品化的方式实现。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a0/d7/a0604418589bb759adf3dd89000ef9d7.jpg" alt="" title="网易数据中台支撑技术工具产品架构图">
|
||||
|
||||
所以在原有数据研发、数据产品团队的基础上，我们开始构思数据平台（工具产品）研发团队。因为考虑到网易集团存在公共技术研发部门（杭州研究院），可以实现工具产品在集团内不同业务线之间复用，所以选择了与公技合作的方式，由公技承担数据中台支撑技术产品的研发。
|
||||
|
||||
我们研发了20多个数据中台支撑技术产品，总结了四个产品设计的经验，对你设计这些产品有很大的借鉴价值。
|
||||
|
||||
- 正交化产品设计。每个产品聚焦一个应用场景，构建产品矩阵，简化了系统使用的复杂度。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/31/1d/314391dc67b377bdyy1c83036fbb7e1d.jpg" alt="" title="EasyData 数据中台支撑技术工具列表">
|
||||
|
||||
- 全链路打通，形成产品闭环。比如任务运维中心与有数报告打通，可以看到一个任务影响了哪些下游报表。
|
||||
- 组件式产品架构，允许业务根据场景搭配产品使用，形成面向不同场景的解决方案能力，例如数据质量解决方案、成本优化解决方案。
|
||||
- 轻型易用、降低用户门槛，尤其注重非技术人员的交互体验。
|
||||
|
||||
我们研发这些工具产品，投入了20多个系统研发人力，因为公技可以把这些工具产品复用给其他的业务，所以对于单个业务来说，成本还是可以接受的。
|
||||
|
||||
**第四，数据产品构建。**
|
||||
|
||||
最后，就是业务支撑。我们通过构建数据产品，帮助业务达成业绩目标。我们的重点是商品和供应链。分别研发了商品运营系统和供应链辅助决策系统，大幅度提升了业务决策的效率。数据产品团队，我们有10个人的团队规模，主要负责数据产品研发。
|
||||
|
||||
## 总结数据中台项目成果
|
||||
|
||||
耗时一年半（实际执行一年的时间），我们完成了电商数据中台的搭建，并产出了一些阶段性的成果，对于成果这部分，你可以重点参考一下，因为你也可以通过这种方式，说服你的老板启动数据中台的建设。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/fc/99/fcceb84f1c5bd69d8efb7c4b33b68299.jpg" alt="" title="网易电商数据中台成果汇报">
|
||||
|
||||
数据产品深入到业务运营，商品运营实现了滞销商品下降60%，大幅提高了库存周转，降低了业务的成本。供应链辅助决策系统，每周有70%的订单由系统自动生成，推动给采购系统。用了一年时间，我们基本达成了在2018年底我们设定的中台建设目标。
|
||||
|
||||
## 课堂小结
|
||||
|
||||
这节课，我用网易电商建设数据中台的案例，从项目立项、推进、成果总结，让你看到了数据中台在企业落地的完整过程。**最后，我想用一句话来总结今天的内容，那就是：数据中台从业务中来，到业务中去！同时我还想送给要建设数据中台的人一句话，“建设数据中台，不仅需要技术的思维，更需要管理者的视角”。**
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/cf/07/cf934a2f72617bdeed632ca0e77ffd07.jpg" alt="">
|
||||
|
||||
## 思考时间
|
||||
|
||||
学完最后一节课，你可以看到，所有关于数据中台的建设规范，我们最终都沉淀到了工具产品中，形成了产品化的解决方案，你知道这是为什么吗？
|
||||
|
||||
最后，感谢你的阅读，如果这节课让你有所收获，也欢迎你将它分享给更多的朋友。
|
||||
69
极客时间专栏/geek/数据中台实战课/开篇词/开篇词 | 数据中台，是陷阱？还是金钥匙？.md
Normal file
69
极客时间专栏/geek/数据中台实战课/开篇词/开篇词 | 数据中台，是陷阱？还是金钥匙？.md
Normal file
@@ -0,0 +1,69 @@
|
||||
<audio id="audio" title="开篇词 | 数据中台，是陷阱？还是金钥匙？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/47/f8/47be0d64fa1a19e7a5806524ff64f5f8.mp3"></audio>
|
||||
|
||||
你好， 我是郭忆，网易大数据平台的负责人，你叫我老郭就可以了。最近我响应国家号召，添了二宝，成了“超级奶爸”，再加上咱们课程上线，生活比较忙碌。不过忙归忙，一想到能和你在这里相遇，心里多多少少有些紧张和激动。
|
||||
|
||||
为了加深彼此的了解，我先简单介绍一下自己。我在网易主要负责大数据平台团队，对内服务于网易各个业务线（包括网易云音乐、严选、有道、新闻，以及已经离开网易大家庭的考拉），主要是为业务提供大数据建设需要的产品和技术；对外呢，主要帮传统企业实现数字化转型，提高运营效率，我们的客户涉及零售、教育、农业、金融、物流等多个行业。
|
||||
|
||||
前段时间，我带着团队，在网易完成了多个业务线的数据中台项目落地，有了一些量化的成果，也获得了业务方的高度认可。除此之外，我还总结了一套数据中台建设的方法论，以及经过实践验证的数据中台支撑技术体系，再加上自己在数据领域积累了十多年的经验，所以我觉得自己可以在这个时间点跟你聊一聊，**到底什么是数据中台？如何来建设数据中台？数据中台有哪些应用价值？**
|
||||
|
||||
说到数据中台，你肯定不陌生，从2018年末开始，它突然在大数据圈儿走红。大家聊天如果不提中台，好像就落伍了。也正是因为数据中台，大数据受到了前所未有的关注。作为一个数据人，我非常高兴，也感到责任重大，因为大家对数据中台寄予了很大的期望，把它当作企业数字化转型的金钥匙，投入了上百万，甚至是千万，希望解决企业经营效率的问题。
|
||||
|
||||
但是我们也看到一些企业未能达到预期的结果，比如说，指标口径不一致造成数据不可信；数据经常无法按时产出，影响工作效率；敏感数据泄露，引发安全危机。最终的结果就是数据不好用，无法发挥应有的价值。所以有人泼冷水说：数据中台就是一个充满诱惑的陷阱，看上去很美好，但是根本不可能落地成功。**那数据中台到底是陷阱？还是金钥匙呢？ 为什么这些项目很难成功呢？ **
|
||||
|
||||
在我看来，这里面既有客观原因，又有主观原因：
|
||||
|
||||
<li>
|
||||
客观上讲，数据中台的建设是一项系统性工程，从组织架构、支撑技术到流程规范，既要有宏观的顶层设计，又要有强有力的落地执行，所以对整个团队的要求会比较高；
|
||||
</li>
|
||||
<li>
|
||||
从主观上讲，这些企业本身数据建设经验不足，或者还处于比较初级的阶段，不知道数据建设中有哪些痛点，更不知道用什么样的技术手段和管理机制去解决这些问题。
|
||||
</li>
|
||||
|
||||
两方面的原因最终造成数据中台项目往往虎头蛇尾，开始的时候规划得很大，实际却草草收场。而我希望通过这门课程，帮你少走一些弯路。
|
||||
|
||||
如果你是一名数据开发，每天累死累活地做需求、排查问题，还天天被人怼，嫌质量差、嫌速度慢；如果你是一个企业的数据负责人，正在为如何建设数据中台而犯愁，不知道如何向你的老板描述数据中台的价值；如果你是一个企业的老板，觉得目前企业的经营太过粗暴，决策完全凭经验，拍脑袋决定，需要实现数字化转型，提高企业经营效率。
|
||||
|
||||
那么我相信这门课会对你有一定的启发和帮助，这也是我写这个专栏的初衷。
|
||||
|
||||
当然了，在你打开这个专栏之前，也许看到过很多“洗脑”的文章，比如《数据中台，企业数字化转型的利器》《迷信中台是一种病，得治》。值得肯定的是，这些文章很好地宣传了数据中台的理念，让数据中台一跃成为网红。
|
||||
|
||||
可如果你认真分析这些文章，就会发现它们太过抽象，很难有可以执行落地的方案，也缺少实践的案例，对应用价值的描述缺少量化的成果，更像是一些项目感悟。比如，赋能业务是这些文章反复提到的点，但具体如何赋能？赋能得怎么样？业务得到了哪些改变？这些却很少提及。
|
||||
|
||||
总的来说，这些文章与实际数据中台建设的距离比较远，可供学习和参考的内容非常有限。我相信，对你来讲，最想知道的是大量的实践案例，从概念到实现，如何来搭建一个数据中台，让数据好用。 我举个例子，很多文章会提及避免烟囱式的开发模式，可具体怎么做呢？如果你已经是烟囱式的开发模式，实际存在了很多分散的小数仓，那怎么样才能让它变成一个数据中台呢？我想这才是你最关心的问题。
|
||||
|
||||
**这也是我写这个专栏最大的不同，那就是结合网易数据中台的实践经验，给你大量一线的案例。**结合这些案例，你能由浅及深地了解数据中台如何在企业落地，而不仅仅浮于概念的表面。此外，在每篇文章结束前，我还为你准备一个思维脑图，帮你梳理每篇文章的知识点，让你形成知识体系，帮你融会贯通。
|
||||
|
||||
**如果用一句话概括我的讲解方式，那就是从原理到实现，最后到实践。**你从中既可以看到数据中台支撑技术的全貌，又不会错过每一个实现细节。配合大量的实践案例，你可以深入掌握数据中台的落地过程。
|
||||
|
||||
为此，我把内容划分了原理篇、实现篇。
|
||||
|
||||
在原理篇中，我会告诉你数据中台的来龙去脉，数据仓库、数据湖、大数据平台以及数据中台的区别，以及它们有什么样的内在联系，然后会跟你讨论什么样的企业适合建数据中台。最后，我会从全局的视角出发，讲解数据中台如何在企业落地。
|
||||
|
||||
通过原理篇的介绍，我希望可以回答你三个问题：什么是数据中台，数据中台解决了什么问题，如何来规划数据中台的建设。
|
||||
|
||||
实现篇是我讲解的重点，我会基于数据中台支撑技术的整体架构，逐一讲解每个模块的具体实现。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/97/d9/9744956fd9527f9b50e90f214d67f8d9.jpg" alt="">
|
||||
|
||||
在这部分内容讲解中，我会遵循从问题入手，然后给出解决方案，接着评估解决的效果，最后问题解决不是一次性的工作，为了使得问题得到长久化的解决，需要借助产品化的实现方式，所以最后我会讲如何将管理方法沉淀成产品。
|
||||
|
||||
接着我会讲解数据服务化相关内容，比如告诉你为什么要实现数据服务化，如何设计一个数据服务。数据安全也是数据中台的核心内容，尤其是随着最近删库跑路的热点事件，安全问题也被企业越来越重视，那么我们将讨论如何实现精细化的权限管理，如何做好企业数据的备份。
|
||||
|
||||
最后，我会讲一下基于数据中台之上的通用数据应用（包括自助取数、可视化分析等）。在这个过程中，我会以电商场景为例，通过大量的案例，帮助你理解这些问题以及问题的解决过程。
|
||||
|
||||
通过实现篇的学习，你可以了解企业在数据建设中到底存在哪些痛点，如何解决这些痛点，这些经验和案例可以立即应用到你目前的工作中，帮助你解决当前遇到的问题（例如指标口径不一致、数据无法按时产出……）。
|
||||
|
||||
除此之外，我会以网易电商的数据中台为例，从项目立项、推进到成果汇报，详细地描述数据中台在网易电商的落地过程。同时我还会对数据中台未来的方向进行展望，包括实时数据中台、跨云数据中台、自动化代码生成能力、智能元数据管理和增强分析等热门技术方向的探讨。
|
||||
|
||||
总的来说，通过这个专栏，你将获得这样几点：
|
||||
|
||||
- 一线互联网公司数据中台的实践经验
|
||||
- 大量实践案例讲解如何躲过数据中台建设的那些坑
|
||||
- 可落地执行的数据中台建设方法
|
||||
- 经过实践的数据中台支撑技术体系
|
||||
|
||||
最后，我想跟你说点儿掏心窝子的话，数据中台到底是陷阱还是金钥匙？我想这主要取决于你有多懂数据中台，把它用好了，绝对是企业打开数字化转型的金钥匙，用不好，那就是一个充满诱惑的陷阱。
|
||||
|
||||
因为我也曾和你一样，刚开始面对数据中台的时候，一点儿经验都没有，后来我一边探索，一边总结，不断反思和复盘，最终总结出自己的一套数据中台建设经验，我希望将这些经验分享给你，让你少走一点儿弯路，相信你只要肯下功夫学习，一定能够让数据中台成功在企业落地。
|
||||
|
||||
随时欢迎你在留言区与我互动，我们一起切磋！
|
||||
76
极客时间专栏/geek/数据中台实战课/结束语/结束语 | 数据中台从哪里来，要到哪里去？.md
Normal file
76
极客时间专栏/geek/数据中台实战课/结束语/结束语 | 数据中台从哪里来，要到哪里去？.md
Normal file
@@ -0,0 +1,76 @@
|
||||
<audio id="audio" title="结束语 | 数据中台从哪里来，要到哪里去？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0a/39/0a4cd45fcee8ff6eedcf0ce7ab473739.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
一晃一个多月过去了，咱们也要说再见了，虽然课程更新得比较顺利，但这个课从敲定、到打磨、再到上线，中间还是蛮坎坷的。虽然网易数据中台的建设有了一些规模和一些阶段性的成果，但成果需要巩固和扩大，在这个过程中，还要解决出现的一些新的问题。而我自己也在带团队，所以忙得脚打后脑勺。
|
||||
|
||||
后来，开始准备咱们的课之后，我都是晚上9点多到家，看一眼孩子就开始写稿，写到凌晨是常有的事儿。中间有一段时间，孩子总闹脾气说我不陪她，那个时候，我心里很酸，真的想放弃算了，但是现在回想起来，很庆幸自己坚持下来了。
|
||||
|
||||
因为这门课对我来说，意义真的很大，一方面让我在晚上安静的时候，认真总结和思考了自己在数据中台建设中的工作，沉淀这些工作背后的方法论和知识体系，让我对数据中台的理解上升到一个新的台阶，另一方面，我把这些沉淀的知识分享给了你们，还收获了很多的认可和鼓励，也得到了新的启发，这对我后续的工作有很大的帮助。
|
||||
|
||||
除此之外，在课程的留言区，我也收获了很多的感动。记得有一位同学（@Geek_albert）在留言区说，自己在睡觉前刷视频，无意间刷到了我在开课时，直播的视频，一口气看完，睡意全无。因为我说的这些痛点全都命中了他目前的工作，他也非常认可我关于这些问题的分析，并迅速加入到学习的队伍中来，获得了很多的收获和成长。我记得自己看到这个留言的时候，真的真的很开心，也很感动，还发了朋友圈。
|
||||
|
||||
类似的留言还有很多，我非常开心能帮你解决当前遇到的问题。这也让我看到，数据中台要解决的问题，其实是一个普遍存在的问题，也让我更加坚信，**数据中台并不是一阵风，而是企业数据建设发展到一定阶段，必然的选择！**
|
||||
|
||||
在这里，我要向所有坚持学习的同学说一声感谢，在你们身上，我看到了数据中台在企业落地过程中遇到的各种各样的问题，尤其是传统行业的企业。这让我有了一些新的想法，特别要感谢@aof @吴科 ，我看到每次内容一更新，他们总是第一时间在留言区和我交流目前遇到的问题和思考。
|
||||
|
||||
就要说再见了，之前我一直在想，在课程结束的时候跟你们说点儿啥，后来我发现，有很多同学都在提业务和数据中台的关系，所以今天，我就想跟你聊聊，“数据中台从哪里来，到哪里去”，希望能对业务和数据中台的关系有一个深入的探讨。
|
||||
|
||||
## 数据中台从哪里来？
|
||||
|
||||
还记得在03讲数据中台建设的三板斧中，关于组织关系，我曾经说过，数据中台的团队必须独立于业务部门，同时又不能脱离业务。
|
||||
|
||||
独立于业务，是因为数据中台要实现多个业务之间数据的共享，如果在业务部门内部，单个业务部门没有动力去做这个事情。
|
||||
|
||||
那为什么不能脱离业务呢？ 这就与今天的话题密切相关了。
|
||||
|
||||
因为数据中台必须要解决业务的问题，我记得之前在和严选数据部门负责人交流时，他有一句话让我印象深刻，他说：“数据中台各项指标建设得再好，都比不上业务部门老大在管委会上，说一句数据有用，什么数据帮他们解决了什么问题。”我觉得，这其实反应了一个根本问题，**那就是业务部门的口碑，是数据部门的生命线，**如果没办法获得业务的认可，数据做得再多，也是无用功。
|
||||
|
||||
那么要解决业务的问题，得先搞清楚业务存在哪些问题。我把这些问题归结为两类：
|
||||
|
||||
- 第一类是数据用的好不好的问题；
|
||||
- 第二类是怎么让数据帮助业务解决更多的问题。
|
||||
|
||||
据我所知，很多企业已经拥有了大数据研发的基础，也有了不少数据应用的场景，但是数据到底用的好不好，这是他们面临的最大的问题。
|
||||
|
||||
从业务的视角看，需求响应速度慢、取数效率低、指标口径不一致、数据经常无法按时产出，违反常识，甚至是高昂的大数据成本，种种原因让很多想用数据，但是对成本比较敏感的业务望而却步。这些问题最终导致数据在业务部门用的并不好。
|
||||
|
||||
我清楚记得，在数据中台构建前，一个业务部门的负责人向我反馈说：“别看现在有3000多张报表，其实能用的不超过10张，因为指标口径都不一致，根本无法用，不知道相信谁。“这个时候，数据中台要解决的核心问题就是效率、质量和成本的问题。只有解决好这些问题，才能让数据用的好，业务部门用的爽，真正实现让更多的人使用数据的目的。
|
||||
|
||||
第二类问题，是如何让数据帮业务解决更多的问题。对一些企业来说，尤其是传统企业，如果连数据应用场景都还没有，你去跟他谈效率、质量和成本，他们根本就不会关心，因为他们还没有到达这个阶段。
|
||||
|
||||
所以，对他们来说，数据到底能解决什么业务问题才是最重要的，因为他们还没尝到数据的甜头。比如，某项业务指标出现下降，你能基于数据，帮他找到下降的原因，并解决，那业务就会很认可数据的价值。
|
||||
|
||||
我建议你基于1~2数据应用场景作为切入，比如对于零售行业，我就先选择滞销、缺货商品监控作为起始场景，构建数据中台。然后随着应用场景的增多，数据中台的数据越来越丰富和完善。这种滚雪球的建设方式对于企业来说风险最小，前期不需要大量的投入，在建设过程中可以看到阶段性成果，是比较容易落地的一条数据中台建设途径。
|
||||
|
||||
## 数据中台到哪里去？
|
||||
|
||||
当然，数据中台的价值最终是要回到业务价值上来的。对数据部门的负责人来说，最尴尬的地方，就是数据中台并不能直接产生业务价值，他们需要前台（也就是数据应用）来接触业务，所以数据中台的价值，最终还是要通过数据应用来体现。
|
||||
|
||||
对应于前面两类业务问题，我认为数据中台的价值，最终也是体现在数据用的好不好和数据解决了什么业务问题上。
|
||||
|
||||
数据用的好不好，主要看这样几点：
|
||||
|
||||
- 数据需求的交付时间到底有没有缩短；
|
||||
- 还存不存在指标业务口径不一致的问题；
|
||||
- 数据质量是否有显著的提升；数据成本是否增长变慢了。
|
||||
|
||||
而最终应用到业务身上的，**就是数据使用的成本到底有没有降低，只有真正降低了，才能让更多的人用。**
|
||||
|
||||
第二个就是数据解决了什么业务问题，这个主要还是要通过一些业务场景来体现，比如：
|
||||
|
||||
- 帮助零售行业解决了库存周转慢的问题；
|
||||
- 帮助物流行业提前发现了快递延迟的风险；
|
||||
- ……
|
||||
|
||||
而这些都需要结合具体的案例说明。只要有这些活生生的案例，再加上业务部门老大的认可，那我相信，你的工作成果一定可以被老板认可。
|
||||
|
||||
别看我絮絮叨叨讲了这么多，其实我主要是想让你明白一个基本的道理：**数据中台和业务的关系，就是鱼和水的关系，谁也离不开谁，**不能把它们完全分开来看。业务想要获得更大的增长，就必须依赖数据中台，数据中台想要存活下去，就必须依赖业务的口碑和认可。**这也是我这十多年来，数据建设过程中最重要的一条经验了。**
|
||||
|
||||
好了，咱们的课程到此就告一段落了。但课程的结束，并不意味着我们交流结束，我会时刻关注留言，与你继续互动，咱们就把留言区当作沟通的桥梁吧，记得多提问，说实话，其实我已经养成了每天睡觉前，看留言的习惯了！
|
||||
|
||||
在文章的结尾，我为你准备了一份调查问卷，题目不多，希望你能抽出两三分钟填写一下。我非常希望听听你对这个课程的意见和建议，期待你的反馈！
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/c7/4f/c7249d4707c23d6b2781b8f6c666044f.jpg" alt="">](https://jinshuju.net/f/FIK81A)
|
||||
|
||||
最后的最后，我想用一句话回答一下我们今天的问题，那就是“数据中台一定要从业务问题中来，到业务价值中去！” 这也是我建设数据中台的初衷。我希望你能够时刻保持这个初衷，这样才不会在建设数据中台中迷失了方向。
|
||||
14
极客时间专栏/geek/数据中台实战课/结束语/结课测试 | 建设数据中台的这些知识，你都掌握了吗？.md
Normal file
14
极客时间专栏/geek/数据中台实战课/结束语/结课测试 | 建设数据中台的这些知识，你都掌握了吗？.md
Normal file
@@ -0,0 +1,14 @@
|
||||
<audio id="audio" title="结课测试 | 建设数据中台的这些知识，你都掌握了吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/90/47/9021aadca5c24185594077b6cce03c47.mp3"></audio>
|
||||
|
||||
你好，我是郭忆。
|
||||
|
||||
现在呢，咱们的课程结束了，恭喜你顺利学完《数据中台实战课》中所有的内容，不知道你掌握的怎么样呢？
|
||||
|
||||
我为你准备了一套结课测试题。它是对你课程学习效果的一个检验，你也可以把它作为一个对于课程的系统性回顾。
|
||||
|
||||
我们的测试题目一共包括 14道单项选择题和 6道多项选择题，每题 5 分，满分 100 分。
|
||||
|
||||
当你完成测试以后，也可以看到我为你附上的参考答案和题目解析，希望能够帮助到你。
|
||||
|
||||
好了，请开始你的测试吧。加油！<br>
|
||||
[<img src="https://static001.geekbang.org/resource/image/00/06/00244430e720d587a1f30c84a77a1306.png" alt="">](http://time.geekbang.org/quiz/intro?act_id=130&exam_id=280)
|
||||
Reference in New Issue
Block a user