数据中台实战

01 | 前因后果：为什么说数据中台是大数据的下一站？

数据仓库的出现

• 四要素：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。（像商品、交易、用户、流量都能作为一个主题域，你可以把它理解为数据仓库的一个目录。数据仓库中的数据一般是按照时间进行分区存放，一般会保留 5 年以上，每个时间分区内的数据都是追加写的方式，对于某条记录是不可更新的。）

• 恩门建模 从数据的来源出发 实体。买家、商品是一个实体，买家购买商品是一个关系。所以，模型设计应该有买家表，商品表，和买家商品交易表三个模型（宽表）

• 更推荐 金博尔建模 从数据分析的需求出发，拆分维度和事实。那么用户、商品就是维度，库存、用户账户余额是事实。

• 在模型设计上，提出了数据仓库模型设计的方法论

• 互联网时代，有两个变化：数据规模前所未有；数据类型变得异构化（App、Web 的前端埋点数据，或者业务服务器的后端埋点日志，这些数据一般都是半结构化，甚至无结构的）

Hadoop 相比传统数据仓库 有两个优势：

• 完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的处理要求；
• 弱化数据格式，数据被集成到 Hadoop 之后，可以不保留任何数据格式，数据模型与数据存储分离，数据在被使用的时候，可以按照不同的模型读取，满足异构数据灵活分析的需求
• 随着 Hadoop 技术日趋成熟， 提出了数据湖的概念
• 数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统
• 基于 Hadoop 构建数据湖，将数据作为一种企业核心资产
• 但是一个商用的 Hadoop 包含 20 多种计算引擎， 数据研发涉及流程非常多，技术门槛限制了 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 提供了实时更新的能力，一般用在实时数仓的构建场景中。
大数据平台像一条设备流水线，经过大数据平台的加工，原始数据变成了指标，出现在各个报表或者数据产品中。

• 随着数据需求的快速增长，报表、指标、数据模型越来越多，找不到数据，数据不好用，数据需求响应速度慢等问题日益尖锐，成为阻塞数据产生价值的绊脚石。

数据价值时代：数据中台崛起

• 价值：解决运营的需求，商品缺货
• 大数据问题：数据割裂导致程序反复开发，烟囱开发。从而导致数据无法共享
• 数据中台构建于数据湖之上，具备数据湖异构数据统一计算、存储的能力，同时让数据湖中杂乱的数据通过规范化的方式管理起来
• 数据中台需要依赖大数据平台，大数据平台完成了数据研发的全流程覆盖，数据中台增加了数据治理和数据服务化的内容。
• 数据中台借鉴了传统数据仓库面向主题域的数据组织模式，基于维度建模的理论，构建统一的数据公共层
• 总的来说，数据中台吸收了传统数据仓库、数据湖、大数据平台的优势，同时又解决了数据共享的难题，通过数据应用，实现数据价值的落地。
• 

02 | 关键抉择： 到底什么样的企业应该建数据中台？

• 经营决策：智能补货的功能，会根据商品的库存、历史销售数据以及商品的舆情

问题：
1 - 指标口径不一致：两个数据产品一个包含税，一个不包含税，

• 指标口径不一致，可能原因包括三种：业务口径不一致、计算逻辑不一致、数据来源不一致（自实时数据，离线）。
• 要实现一致，就务必确保对同一个指标，只有一个业务口径，只加工一次，数据来源必须相同
• 如何实现
• 管好指标，要一个团队统一负责；明确每个指标的业务口径，数据来源和计算逻辑，同时会按照类似数仓主题域的方式进行管理；确保所有的数据产品、报表都引用指标系统的口径定义。当运营把鼠标 Hover 到某个指标上时，就可以浮现出该指标的口径定义

2 - 数据重复建设

• 烟囱式的开发模式： 两个任务都对原始数据进行清洗。如果只有一个任务清洗，产出一张明细表，另外一个任务直接引用这张表，就可以节省一个研发的清洗逻辑的开发
• 所以，要解决数据需求响应慢，就必须解决数据复用的问题，要确保相同数据只加工一次，实现数据的共享。
• 如何实现
• 构建全局一致的公共维表：一个是数仓设计中心，在模型设计阶段，强制相同聚合粒度的模型，度量不能重复。另外一个是数据地图，方便数据开发能够快速地理解一张表的准确含义。

3 - 取数效率低

• 找不到数据，可能是取不到数据
• 如何实现
• 构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据
• 技术人员：API 接口的方式提供给数据应用
• 非技术人员：数据中台提供了可视化的取数平台，你只需要选取指标、通过获取指标系统中每个指标的可分析维度，然后勾选，添加筛选过滤条件，点击查询，就可以获取数据
• 同时，数据中台构建了企业数据地图，你可以很方便地检索有哪些数据，它们在哪些表中，又关联了哪些指标和维度。通过自助取数平台和数据地图，公司的非技术人员开始自助完成取数

4 - 数据质量差/数据计算错误：案例（某类商品搜索转化率增长，于是分配了更大的流量，可转化率增长的原因是数据计算错误。）

• 数据的加工链路长，一个指标上游的所有链路加起来有 100 多个节点，要逐个去定位任务
• 要解决数据质量差，就要及时发现然后快速恢复数据问题。
• 如何实现：
• 因为数据只加工一次，强调数据复用，对质量有更高要求，实现了全链路的数据质量稽核监控，对一个指标的产出上游链路中涉及的每个表，都实现了数据一致性、完整性、正确性和及时性的监控，确保在第一时间发现、恢复、通知数据问题。

5- 数据成本线性增长 和第二条 数据重复建设 有因果关系

• 如何实现
• 数据成本治理系统：从应用维度、表维度、任务的维度、文件的维度进行全面的治理

企业考虑建数据中台的因素

• 企业是否有大量的数据应用场景：数据中台的本质是支撑快速地孵化数据应用。要有较多数据应用的场景
• 较多的业务数据的孤岛：仓储、供应链、市场运营都是独立的数据仓库，跨数据系统，消除数据孤岛
• 面对大量的开发
• 数据中台因为投入大，收益偏长线,不适合初创型的小公司
• 通过数据实现精益运营，提高企业的运营效率
  

问题

• 数据中台不见得一下子要搞得很大，可以先从1-2个数据应用场景入手，从需求出发，然后随着接入的数据应用越来越多，中台越来越完善
• 网易，云音乐、严选、传媒、有道因为业务相差很大，所以数据分析绝大多数的场景都在业务线内部，每个业务线构建一个数据中台；用户画像的部分，可能存在业务线之间的数据局部打通，做法是基于“小黑屋”的联邦学习模式
• 数据成本：1 cu = 1 cpu 4 g memory 1T 物理存储
• 数据中台投入：一部分是人，一部分是系统以及物理机器
• 获得的效果：部分企业大部分都已经构建了自己的Hadoop集群，已经有了一些数据应用场景，拿数据复用作为衡量指标，每复用一次，就认为节省了多少研发效能，多少资源
• 数据中台强调数据、接口的复用，实现数据的共享，从而提高效率、质量，节省成本，可以更好的支撑数据应用
• 数据加工：指的是数据的ETL，在大数据生态下，一般基于Hive、Spark或者Flink计算引擎实现的数据格式化、清洗、过滤、关联、聚合等。

03 | 数据中台建设三板斧：方法论、组织和技术

• 如何建设数据中台：建设数据中台好比盖房子，那么设计图纸就是数据中台建设的方法论；工具是数据中台的支撑技术；施工队伍就是数据中台的组织架构。这三者缺一不可。

OneData

数据中台就是要在整个电商业务形成一个公共数据层，消灭这些跨部门的小数仓，实现数据的复用，所以强调数据只加工一次，不会因为不同的应用场景，不同的部门数据重复加工。

• 如何实现

• 主题域：比如在电商业务中，商品、交易、流量、用户、售后、配送、供应链都可以作为主题域
• 表的命名进行规范化统一：表的名称中最好能够携带表的主题域、业务过程、分层以及分区信息
• 构建全局的指标字典：确保所有表中相同指标的口径必须一致
• 为了实现模型的复用，数据中台适合采用分层的设计：ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS/DM 应用数据层 / 数据集市层
  
• 数据是资产，不是成本。资产和成本的差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。

OneService 数据即服务，强调数据中台中的数据应该是通过 API 接口的方式被访问

• 数据应用开发：
  数据量小的使用 MySQL；
  大的可能用到 HBase；
  需要多维分析的可能需要 Greenplum；
  实时性要求高的需要用到 Redis；

• 当你想下线一张表时，因为不知道谁访问了这张表 上线容易，下线难

• 好处：API 接口一方面对应用开发屏蔽了底层数据存储，另一方面，对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。

• 如何实现
  

• 屏蔽异构数据源：数据服务必须要能够支撑类型丰富的查询引擎，满足不同场景下数据的查询需求，常见的有 MySQL、HBase、Greenplum、Redis、Elasticsearch 等。

• 数据网关：要实现包括权限、监控、流控、日志在内的一系列管控能力，哪个应用的哪个页面访问了哪个模型，要做到实时跟踪

• 辑模型： 数据库中有一个视图的概念， 每次在查询的时候，动态地将不同表的查询结果聚合成视图的查询结果

• 性能和稳定性：由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展。

数据中台支撑技术

以 HDFS 为代表的分布式文件系统，以 Yarn/Kubernates 为代表的资源调度系统，以 Hive、Spark、Fink 为代表的分布式计算引擎，都属于基础设施范畴。如果把数据中台比作是一个数据工厂，那可以把它们比作是这个工厂的水、电