数据中台的由来

数据中台最早是阿里提出的，但真正火起来是2018 年，我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。为什么很多公司开始建设数据中台？尽管数据中台的文章很多，但是一千人眼里有一千个数据中台，到底什么是数据中台？数据中台包含什么?

当企业需要数据化转型、精细化运营，进而产生大规模数据应用需求的时候，就需要建设数据中台。数据中台是高质量、高效赋能数据前台的一系列数据系统和数据服务的组合。数据中台包含数仓体系、数据服务集和BI 平台。

1、是阿里拜访芬兰的一家公司—SupperCell，只有不到10个人，每个员工创造估值3.74亿

2、淘宝遇到的问题：淘宝和天猫是两套完全独立的两套系统，但是却都包含了商品、交易、评价、支付、物流

3、中台之前类似的思想
SOA（方法）：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

电商系统的四个发展阶段

1、单一系统
2、分布式系统
3、平台化（服务业务，支撑作用）
4、中台化（驱动业务，中枢作用）

第一阶段：数据库节点：单一业务系统阶段
第二阶段：数据仓库节点：处理分析报表的需求
第三阶段：数据平台阶段：解决报表和BI的需求
第四阶段：数据中台阶段：系统对接OLTP和OLAP

中台长什么样？

阿里的大中台，小前台

沉淀共享服务，打破系统壁垒，业务快速创新

滴滴的中台

大数据中台解决的问题

到底什么是数据中台？
如何来建设数据中台？
数据中台有哪些应用价值？

建设数据中台的背景

指标口径不一致造成数据不可信；
数据经常无法按时产出，影响工作效率；
敏感数据泄露，引发安全危机。

最终的结果就是数据不好用，无法发挥应有的价值

建设数据中台的复杂度

客观上讲，数据中台的建设是一项系统性工程，从组织架构、支撑技术到流程规范，既要有宏观的顶层设计，又要有强有力的落地执行，所以对整个团队的要求会比较高；
从主观上讲，这些企业本身数据建设经验不足，或者还处于比较初级的阶段，不知道数据建设中有哪些痛点，更不知道用什么样的技术手段和管理机制去解决这些问题。

中台起源

关键词：数据库，数据仓库，数据湖，大数据平台，数据中台

数据存储起源：数据库

1979年：Oracle 1.0 商用数据库发布 1996年：MySQL 1.0 发布，到2000年以后开始火起来。

特点：数据库主要面向事务的增删改场景，一个数据库支撑多个简单单体应用，少量分析需求，借助数据库直接完成。但当数据增长较快，复杂的大量的分析需求，借助数据库做分析开始吃力。

分析计算起源：传统数仓

在 1991 年出版的《Building the Data Warehouse》中，数据仓库之父比尔·恩门（Bill Inmon）首次给出了数据仓库的完整定义，他认为：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。

数据仓库，聚合多个业务系统的数据，同时保存历史数据，进行大数据量的范围查询。

Kimball 和 Inmon 是两种主流的数据仓库方法论，分别由 Ralph Kimball 和 Bill Inmon 提出，在实际数据仓库建设中，业界往往会相互借鉴使用两种开发模式。

Inmon 提出的建模方法自顶向下（顶是指数据的来源，在传统数据仓库中，就是各个业务数据库），基于业务中各个实体以及实体之间的关系，构建数据仓库。缺点是：构建成本高，适用于业务场景固定的业务（实体和关系）

Kimball 建模与恩门正好相反，是一种自底向上的模型设计方法，从数据分析的需求出发，拆分维度和事实。优点是：适用于变化速度比较快的业务。（事实和维度）

传统数据仓库，第一次明确了数据分析的应用场景应该用单独的解决方案去实现，不再依赖于业务的数据库。在模型设计上，提出了数据仓库模型设计的方法论，为后来数据分析的大规模应用奠定了基础。

技术革命：大数据平台

进入互联网，数据量开始暴涨，主要有以下两个变化：

一个是数据规模前所未有。一个成功的互联网产品日活可以过亿，就像你熟知的微信，支付宝，头条，抖音等，每天产生几千亿的用户行为。传统数据仓库难于扩展，根本无法承载如此规模的海量数据。
一个是数据类型变得异构化。互联网时代的数据除了来自业务数据库的结构化数据，还有来自 App、Web 的前端埋点数据，或者业务服务器的后端埋点日志，这些数据一般都是半结构化，甚至无结构的。传统数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须事先定义好，数据必须按照模型设计存储。

所以：传统数仓应对这种场景吃力，开始涌现一些针对大规模海量数据进行分析处理的技术。

2003年起，谷歌发表了 3 篇论文：《The Google File System》《MapReduce：Simplified Data Processing on Large Clusters》《Bigtable：A Distributed Storage System for Structed Data》

这三篇论文，提出了一种新的，面向海量数据分析的海量异构数据的统一计算和存储的方法，奠定了现代大数据，大规模并行计算的技术基础。Yahoo对此做了开源实现，就是现在的Hadoop。两个优势：

完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的处理要求；
弱化数据格式，数据被集成到 Hadoop 之后，可以不保留任何数据格式，数据模型与数据存储分离，数据在被使用的时候，可以按照不同的模型读取，满足异构数据灵活分析的需求。

随着 Hadoop 技术日趋成熟，2010 年，Pentaho 创始人兼 CTO James Dixon 在纽约 Hadoop World 大会上提出了数据湖的概念，他提到：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。数据湖是按存储原始数据格式的数据存储，旨在任何数据可以以最原始的形态储存，可是结构化或者非结构化数据，以确保数据在使用时可以不丢失任何细节，一般以Hadoop系统存储为比较典型的解决方案，所有的实时数据和批量数据，都汇总到数据湖当中，然后从湖中取相关数据用于机器学习或者数据分析。

易观在2018年，提出数据河的概念，避免“数据湖”成为“数据沼泽”，流动的“数据河”是关键。因为大部分使用数据湖的企业在数据真的需要使用的时候，往往因为数据湖中的数据质量太差而无法最终使用。数据只有流动起来，才可以不成为数据沼泽，湖泊只是暂存数据河流的基地。数据流动就意味着所有的数据产生，最终要有它的耕种者和使用者。要让数据有效流动起来，就要建立有效的“数据河”（Data River）。数据河（Data River）就是在由源头产生清晰干净的有效数据（去ETL化，数据源头业务就像生态水源一样，不让污水流下去），通过各个河流网，流向各个数据消费端的架构。

数据工厂时代：大数据平台

大数据平台是面向数据研发场景的，覆盖数据研发的完整链路的数据工作台。就是为了提高数据研发的效率，降低数据研发的门槛，让数据能够在一个设备流水线上快速地完成加工。

大数据平台按照使用场景，分为数据集成、数据开发、数据测试……任务运维，大数据平台的使用对象是数据开发。大数据平台的底层是以 Hadoop 为代表的基础设施，分为计算、资源调度和存储等。

数据存储：HDFS，HBase，Kudu等
数据计算：MapReduce, Spark, Flink
交互式查询：Impala, Presto
在线实时分析：ClickHouse，Kylin，Doris，Druid，Kudu等
资源调度：YARN，Mesos，Kubernetes
任务调度：Oozie，Azakaban，AirFlow等
....
数据收集，数据迁移，服务协调，安装部署，数据治理等

大数据平台像一条设备流水线，经过大数据平台的加工，原始数据变成了指标，出现在各个报表或者数据产品中。

数据价值时代：数据中台

在应用大数据平台架构的时候，你可能遇到这么个问题：因为烟囱式的开发，不同数据应用可能存在相同应用指标，但是运营可能发现这些数据指标的结果不一致，因为不知道该用谁信任谁而导致运营对数据的信任下降。

数据割裂的另外一个问题，就是大量的重复计算、开发，导致的研发效率的浪费，计算、存储资源的浪费，大数据的应用成本越来越高。

如果你是运营，当你想要一个数据的时候，开发告诉你至少需要一周，你肯定想是不是太慢了，能不能再快一点儿？
如果你是数据开发，当面对大量的需求的时候，你肯定是在抱怨，需求太多，人太少，活干不完。
如果你是一个企业的老板，当你看到每个月的账单成指数级增长的时候，你肯定觉得这也太贵了，能不能再省一点，要不吃不消了。

这些问题的根源在于，数据无法共享。

2016 年，阿里巴巴率先提出了“大中台，小前台”战略，推出了数据中台。数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。之前，数据是要啥没啥，中间数据难于共享，无法积累。现在建设数据中台之后，要啥有啥，数据应用的研发速度不再受限于数据开发的速度，然后我们就可以根据需求场景，快速孵化出很多数据应用，这些应用让数据产生价值。

总的来说，数据中台吸收了传统数据仓库、数据湖、大数据平台的优势，同时又解决了数据共享的难题，通过数据应用，实现数据价值的落地。

数据中台适合企业

大数据平台型企业的问题

大量数据产品的出现，在不断提高企业运营效率的同时，也暴露出很多尖锐的问题，在我看来，主要有五点。

指标口径不一致：主要原因：业务口径不一致、计算逻辑不一致、数据来源不一致。要实现一致，就务必确保对同一个指标，只有一个业务口径，只加工一次，数据来源必须相同。
数据重复建设，需求响应时间长：解决数据复用的问题，要确保相同数据只加工一次，实现数据的共享。
取数效率低：构建一个全局的企业数据资产目录，实现数据地图的功能，快速找到数据
数据质量差：存储数据链路，及时发现数据质量问题，并恢复数据。
数据成本线性增长：大企业烟囱式开发，导致一个企业拥有很多小数仓，不同数仓可能开发相同任务，导致资源浪费，而且也做不到淘汰低价值数据任务。所以解决方案的核心：解决数据重复建设，打通数据孤岛。

因此：数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用。

那么数据中台如何解决呢？

由一个团队，负责所有指标的管控，明确每个指标的业务口径，数据来源和计算逻辑，消除指标二义性
数据服务化，提高了数据应用接入和管理的效率
对于非技术人员，数据中台提供了可视化的取数平台。你只需要选取指标、通过获取指标系统中每个指标的可分析维度，然后勾选，添加筛选过滤条件，点击查询，就可以获取数据。
构建了企业数据地图，你可以很方便地检索有哪些数据，它们在哪些表中，又关联了哪些指标和维度
数据只能加工一次，强调数据的复用性
成本控制，研发了一个数据成本治理系统，从应用维度、表维度、任务的维度、文件的维度进行全面的治理

什么样的企业适合建数据中台？

数据中台的构建需要非常大的投入：一方面数据中台的建设离不开系统支撑，研发系统需要投入大量的人力，而这些系统是否能够匹配中台建设的需求，还需要持续打磨。另外一方面，面对大量的数据需求，要花费额外的人力去做数据模型的重构，也需要下定决心。

所以数据中台的建设，需要结合企业的现状，根据需要进行选择。我认为企业在选择数据中台的时候，应该考虑这样几个因素。

企业是否有大量的数据应用场景：数据中台本身并不能直接产生业务价值，数据中台的本质是支撑快速地孵化数据应用。所以当你的企业有较多数据应用的场景时（一般有 3 个以上就可以考虑），就像我在课程开始时提到电商中有各种各样的数据应用场景，此时你要考虑构建一个数据中台。
经过了快速的信息化建设，企业存在较多的业务数据的孤岛，需要整合各个业务系统的数据，进行关联的分析，此时，你需要构建一个数据中台。比如在我们做电商的初期，仓储、供应链、市场运营都是独立的数据仓库，当时数据分析的时候，往往跨了很多数据系统，为了消除这些数据孤岛，就必须要构建一个数据中台。
当你的团队正在面临效率、质量和成本的苦恼时，面对大量的开发，却不知道如何提高效能，数据经常出问题而束手无策，老板还要求你控制数据的成本，这个时候，数据中台可以帮助你。
当你所在的企业面临经营困难，需要通过数据实现精益运营，提高企业的运营效率的时候，你需要构建一个数据中台，同时结合可视化的 BI 数据产品，实现数据从应用到中台的完整构建，在我的接触中，这种类型往往出现在传统企业中。
企业规模也是必须要考虑的一个因素，数据中台因为投入大，收益偏长线，所以更适合业务相对稳定的大公司，并不适合初创型的小公司。

建设数据中台不能盲目跟风，因为它不一定适合你。

如何建设数据中台

方法论

在 2016 年，阿里巴巴就提出了数据中台建设的核心方法论：OneData 和 OneService

OneData

OneData 就是所有数据只加工一次。

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

如何实现：

数据划分主题进行管理：表的命名，字段的命名等规范统一，做到见名知义
数据格式和字段命名和定义规范化
指标一致，不存在二义性：提供全局数据字典确保意义一致。
数据模型复用
数据完善

OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。

OneService

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

现阶段企业数据应用现状：

数据量小的使用 MySQL：Hive数仓，Spark计算引擎的计算结果导出到MySQL
数据量大的使用HBase + ElasticSearch：解决海量数据中的低延迟高效查询
需要多维分析的可能需要 ClickHouse，Kylin，Greenplum：提供现在分析能力
实时性要求高的需要用到 Redis

因此，从不同的系统取数据，应用开发需要定制不同的访问接口。而且如果数据发生异常，还不能查出影响到下游应用的那些应用或者报表。所以当你想下线一张表的时候，就无法实施，造成了上线容易，下线难的囧状。

而 API 接口一方面对应用开发屏蔽了底层数据存储，使用统一标准的 API 接口查询数据，提高了数据接入的速度。另一方面，对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。

如何实现：

屏蔽底层数据来源的不同：不同的数据来源，统一的数据出口
实现包括权限，日志，监控等管控能力的数据网关：权限控制，统计分析，流量控制，成本控制等
给用户屏蔽底层的物理数据模型，提供数据逻辑模型：动态拼接多张相同粒度的数据结构，简化接入复杂度
提供无状态的，高性能和稳定可靠的数据服务

OneService 体系的目标是提高数据的共享能力，让数据可以被用得好，用得爽。

技术

以网易数据中台为例：

这个图完整地描述了数据中台支撑技术体系

1、大数据计算、存储基础设施

数据中台的底层是以 Hadoop 为代表的大数据计算、存储基础设施，提供了大数据运行所必须的计算、存储资源。
2、工具产品

在 Hadoop 之上，浅绿色的部分是原有大数据平台范畴内的工具产品，覆盖了从数据集成、数据开发、数据测试到任务运维的整套工具链产品。同时还包括基础的监控运维系统、权限访问控制系统和项目用户的管理系统。由于涉及多人协作，所以还有一个流程协作与通知中心。
3、数据治理模块

灰色的部分，是数据中台的核心组成部分：数据治理模块。它对应的方法论就是 OneData 体系。以元数据中心为基础，在统一了企业所有数据源的元数据基础上，提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的 5 个产品，分别对应的就是数据发现、模型、质量、成本和指标的治理。
4、数据服务

深绿色的部分是数据服务，它是数据中台的门户，对外提供了统一的数据服务，对应的方法论就是 OneService。数据服务向下提供了应用和表的访问关系，使数据血缘可以延申到数据应用，向上支撑了各种数据应用和服务，所有的系统通过统一的 API 接口获取数据。
5、数据产品和应用

在数据服务之上，是面向不同场景的数据产品和应用，包括面向非技术人员的自助取数系统；面向数据开发、分析师的自助分析系统；面向敏捷数据分析场景的 BI 产品；活动直播场景下的大屏系统；以及用户画像相关的标签工厂。

组织

数据中台提供的是一个跨业务部门共享的公共数据能力，所以，承担数据中台建设职责的部门一定是一个独立于业务线的部门。

独立部门的最大风险是与业务脱节，所以我们对数据中台的组织定位是：懂业务，能够深入业务，扎根业务。数据中台要管理所有的指标，而每个业务线之间的指标既有差异，也有交叉，要理解指标的口径定义，就必须要了解业务的过程。同时，当我们要制定一些新的指标时，必须要了解各个业务线新的业务目标，指标的本质还是为业务目标服务的。

综合来讲：

数据产品部门：负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进，指标口径的定义和维护（有的部门是由分析师管理）。
数据平台部门：负责研发支撑数据中台构建的产品，例如指标系统、元数据中心、数据地图等。
数据开发团队：负责维护数据中台的公共数据层，满足数据产品制定的数据需求。
应用开发团队：负责开发数据应用产品，比如报表系统、电商中的供应链系统、高层看板、经营分析。

数据中台的组织架构改革涉及原有各个部门的利益，所以这个是数据中台构建最难又不得不做的地方，必须要取得高层领导的支持和重视。所以需要：

一把手牵头，全员共识；
总体规划，分步实施；
找准切入点，解决具体业务问题

中台实现：元数据中心

元数据

数据中台的构建，需要确保全局指标的业务口径一致，要把原先口径不一致的、重复的指标进行梳理，整合成一个统一的指标字典。而这项工作的前提，是要搞清楚这些指标的业务口径、数据来源和计算逻辑。而这些数据呢都是元数据。

元数据中心应该包括哪些元数据呢？什么样的数据是元数据？

元数据划为三类：数据字典、数据血缘和数据特征。

数据字典描述的是数据的结构信息：表结构信息

数据血缘是指一个表是直接通过哪些表加工而来。数据血缘一般会帮我们做影响分析和故障溯源。比如说有一天，你的老板看到某个指标的数据违反常识，让你去排查这个指标计算是否正确，你首先需要找到这个指标所在的表，然后顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。

数据特征主要是指数据的属性信息：存储空间大小，数仓分层，访问热度，主题分类，关联指标等

元数据技术

根据我的经历和了解，业界比较流行的元数据产品技术主要有：

开源的有 Netflix 的 Metacat、Apache 的 Atlas；
商业化的产品有 Cloudera Navigator。

关于开源的这两款产品，Metacat 擅长管理数据字典，Atlas 擅长管理数据血缘。

Metacat 介绍：https://github.com/Netflix/metacat

从上面 Metacat 的架构图中，你可以看到，Metacat 的设计非常巧妙，它并没有单独再保存一份元数据，而是采取直连数据源拉的方式，一方面它不存在保存两份元数据一致性的问题，另一方面，这种架构设计很轻量化，每个数据源只要实现一个连接实现类即可。

Apache Atlas 介绍：http://atlas.apache.org/

血缘采集，一般可以通过三种方式：

通过静态解析 SQL，获得输入表和输出表；
通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表；
通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。

第一种方式，面临准确性的问题，因为任务没有执行，这个 SQL 对不对都是一个问题。第三种方式，血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。所以第二种方式，我认为是比较理想的实现方式，而 Atlas 就是这种实现。

对于 Hive 计算引擎，Atlas 通过 Hook 方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给 Kafka，由一个 Ingest 模块负责将血缘写入 JanusGraph 图数据库中。然后通过 API 的方式，基于图查询引擎，获取血缘关系。对于 Spark，Atlas 提供了 Listener 的实现方式。

网易元数据中心实现

下图按照功能模块分为数据血缘、数据字典和数据特征。

元数据中心统一对外提供了 API 访问接口，数据传输、数据地图、数据服务等其他的子系统都可以通过 API 接口获取元数据。另外 Ranger 可以基于元数据中心提供的 API 接口，获取标签对应的表，然后根据标签更新表对应的权限，实现基于标签的权限控制。

关键点

元数据中心是数据中台的基石，它提供了我们做数据治理的必须的数据支撑，数据的指标、模型、质量、成本、安全等的治理，这些都离不开元数据中心的支撑。

元数据中心设计上必须注意扩展性，能够支持多个数据源，所以宜采用集成型的设计方式。
数据血缘需要支持字段级别的血缘，否则会影响溯源的范围和准确性。
数据地图提供了一站式的数据发现服务，解决了检索数据，理解数据的“找数据的需求”。

中台实现：指标管理

指标是一种特定类型的元数据，公司的运营会围绕它进行工作，可以说，它是业务和数据的交汇点。指标数据能不能用，会影响他们的日常工作。而且元数据在指标管理、模型设计、数据质量和成本治理四个领域也都发挥着作用，而这些领域构成了数据中台 OneData 数据体系。

为什么需要指标管理

举两个例子：

第一个：新用户

市场部门认定新用户是首次下单并完成支付的用户；
会员中心认定新用户是当日新注册用户。

第二个：7日UV

过去7日UV的平均值
过去7日所有Vistor的去重数量

定义不一致，口径不一致，计算逻辑就不一致。所以构建数据中台，需要提供全局一致的指标口径，输出完备统一的指标字典。

常见指标问题

一般进行烟囱式开发的企业都多多少少存在以下的指标问题：

相同指标名称，口径不一致：比如"新用户销售额，7日UV"
相同口径，指标名称不一样：比如"优惠券抵扣金额"和"优惠券消费金额"
不同限定词，描述相同事实过程的俩个指标，相同事实部分口径不一致
指标口径描述不清晰：比如"关单金额"
指标命名难于理解：比如"转化率" 和 "ROI"
指标数据来源和计算逻辑不清晰

如何定义指标

面向主题：为了提高指标管理的效率，你需要按照业务线、主题域和业务过程三级目录方式管理指标
拆分原子指标和派生指标：统计周期、统计粒度、业务限定、原子指标，组成派生指标，所以原子指标可以定义为不能够按照上述规则进一步拆分的指标。比如：30 天内某商品的非会员购买用户数
命名规范：规范统一化，通俗易懂化。
关联的应用和可分析的维度
分等级管理

如何构建指标系统

提供一个易于维护的规范标准化指标管理系统，具备查询，增删等功能。
数据中台团队必须要有一个专门负责指标管理的人或者小组（一般不超过 3 个人），最好是数据产品经理来负责，如果你的公司没有这个职位，也可以让分析师承担。
提供一个完备的指标创建流程：提交指标需求，需求评审，模型设计和数据开发，验证，上线，应用接入

指标管理总结

数据中台直接产出的核心指标必须实施强管理，由数据中台团队的专人或者小组负责，最好是数据产品经理的角色。
指标的管理必须结合系统 + 规范的治理方法，明确每个角色的职责，通过系统化的方法实现。
不同的两个指标描述的相同业务过程中的相同事实部分口径不一致，是指标梳理过程中最常见的问题，需要通过拆分原子指标和派生指标的方式解决。

中台实现：模型设计

大多数公司的分析师会结合业务做一些数据分析（需要用到大量的数据），通过报表的方式服务于业务部门的运营。但是在数据中台构建之前，分析师经常发现自己没有可以复用的数据，不得不使用原始数据进行清洗、加工、计算指标。

烟囱式数据开发：数据模型无法复用，每次遇到新的需求，都从原始数据重新计算

如何构建可复用模型

大数据中台的数据模型：

构建可复用模型的标准：数据模型可复用，完善且规范

统计明细层完善度：统计DWD层表被跨层引用次数即可，次数越多，证明完善度越好
DWS/ADS/DM 层完善度：能满足多少查询需求。

中台实现：数据质量

现有的大数据平台，或者数仓项目，很难做到任务追踪和数据追踪。举一个例子。

运营每天上班的第一件事，都是打开响应的数据运营系统，如果某天突然发现这个数据反常，需要数据开发部门核对，或者经过他们自己核对，发现数据的确算错已经投诉了。

这样的例子中，可以得出几个结论：

数据部门晚于业务方发现数据异常，被投诉后才发现问题。
出现问题后，数据部门无法快速定位到数据异常的根源，排查用了较长的时间。
故障出现在数据加工链路的上游顶端，出现问题没有第一时间报警处理，导致问题修复时，所有下游链路上的任务都要运行，修复时间成本非常高。

这些问题最终导致了数据长时间不可用。这就是数据质量的问题

数据质量问题的根源

对于一个做数据开发的人来讲，遇见数据质量的问题（也就是算错了数据的问题）是经常性的。而，通常进行排查和数据恢复，都需要较长的时间，和较大的代价。在多次问题的复盘中，总结出以下规律：

业务系统变更，包括表结构变更，源系统环境变更，源数据格式异常
数据开发bug + 数据开发任务变更：忘了修改数据源，写死数据分区，数据格式异常
物理资源不足：YARN上多租户争抢资源导致数据延迟产出
基础设施不稳定：NameNode高可用失效导致数据读写功能异常

如何提高数据质量

想提升数据质量，最重要的就是“早发现，早恢复”：

早发现，是要能够先于数据使用方发现数据的问题，尽可能在出现问题的源头发现问题，这样就为“早恢复”争取到了大量的时间。
早恢复，就是要缩短故障恢复的时间，降低故障对数据产出的影响。

具体实施：

添加稽核校验任务：确保数据的完整性、一致性和准确性
建立全链路监控：可以基于血缘关系建立全链路数据质量监控。
通过智能预警，确保任务按时产出：延迟产出，异常任务等立即报警
通过应用的重要性区分数据等级，加快恢复速度

如何衡量数据质量

对于数据治理做到什么程度，很难衡量，最好的办法就是量化。

某个时间点以前核心任务的产出完成比，超过规定时间，没有完成产出则稽核校验失效
基于稽核规则，计算表级别的质量分数。对于低于质量分数的表，分发到响应责任人进行改进。
需要立即介入的报警次数。超过规定次数的需要立即介入
数据产品 SLA。数据应用中的所有指标在规定时间内产出。如果没有，则计算不可用时间，不可用时间越短，证明SLA越好

中台实现：成本控制

企业数据中台追求的是：高效，质量和成本。简单来说就是：快，准，省。所以能不能合理控制成本，也是决定数据中台项目成功与否的关键。

如果老板问你：

今年大数据中台预算 5000W，都用来支撑什么业务了？
你们都做了哪些优化成本的举措呢？效果怎样？

正常来说，数据中台的成本，是按照人力，物力，按照机器数量和电费来算的，又不是按照数据应用来算的，来自老板的这种灵魂拷问，还真是不好回答。但是一个公司的资源都是有限的，不可能无限增加，所以这些资源肯定都需要确保应用在公司的核心战略上产生价值。所以数据中台刚好又是一个高消耗支撑部门，所以如果想展现自己的价值，至少要做到两方面：

支撑好业务，获得业务部门的认可
精简架构，控制成本，为公司省钱

成本陷阱

根据经验，可以总结优化的地方还是挺多，如果都做到位，可以节省一半资源。相信很多小伙伴已经基本中招。

数据上线容易，下线难，什么没有下线机制。
低价值的数据应用消耗了大量的机器资源。
烟囱式的开发模式导致数据加工重复。
数据倾斜导致资源分配利用不均衡
未设置数据生命周期，导致过期数据长期占用磁盘资源。
调度周期设置不合理，未形成闲忙搭配得当。
任务指定资源参数配置不当
数据为压缩存储

甚至还可以再列举一些。

精细化成本管理

全局资产盘点

1、精细化成本管理的第一步，就是要对数据中台中，所有的数据进行一次全面盘点，基于元数据中心提供的数据血缘，建立全链路的数据资产视图。

2、数据成本计算：一张表的成本 = 每个加工任务的计算资源成本 * m + 上有依赖表的存储资源成本 * n

3、数据价值计算：给使用人数，使用频率，数据应用数，老板等因素加权计算

发现问题

1、持续产生成本，但是已经没有使用的末端数据（“没有使用”一般指 30 天内没有访问）：没有使用，却消耗了资源

2、数据应用价值很低，成本却很高，这些数据应用上游链路上的所有相关数据：低价值产出

3、高峰期高消耗的数据：高成本的数据

治理优化

1、对于第一类问题，应该对表进行下线

2、对于第二类问题，我们需要按照应用粒度评估应用是否还有存在的必要，如果没有，则删除。

3、第三类问题，主要是针对高消耗的数据，又具体分为产出数据的任务高消耗和数据存储高消耗，分配到非高峰期运行即可。

治理效果评估

1、最简单粗暴的标准：省了多少钱

2、下线了多少任务和数据；这些任务每日消耗了多少资源；数据占用了多少存储空间。

3、将上述节省资源换算成钱，这就是你为公司省的钱。

中台实现：数据服务化

数据服务解决的问题

数据接入效率低

为了保障数据的查询速度，需要引入中间存储

数据量小：MySQL
低延时：Redis
数据两大：HBase
多维分析，数据量大：GreenPlum

不同中间存储提供的 API 接口不一致，导致使用复杂度提高。维护困难。

解决方案：提供统一的 API 接口，为开发者和应用者屏蔽不同的中间存储和底层数据源

数据服务解决的问题

中间存储中的数据无法复用
API接口根据应用高度定制化，也无法复用
数据服务暴露的不是数据，而是接口
数据服务具备限流功能，使得不同应用共享数据成为可能

不确定数据应用在哪里

数据和应用的链路关系是断的
数据出现问题，不知道影响了哪个应用，无法优先恢复
下线数据，不知道下游还有没有应用访问
L数据服务维护了数据应用和数据中台表的链路关系，建立全链路血缘

数据部门的字段更变导致数据应用变更

汇总层模型根据需求不断优化是最频繁出现的事情
对应用开发来说，底层表变更简直就是噩梦
数据服务解耦了数据应用和数据，修改
数据服务的映射关系即可实现字段变更

数据服务解决方案

为所有的数据应用提供统一的 API 接口服务

表现在：

接口规范化定义
数据网关
链路关系的维护
数据交付
提供多样中间存储
逻辑模型
API 接口
API 测试

数据服务实现了数据中台模型和数据应用的全链路打通，解决了任务异常影响分析和数据下线不知道影响哪些应用的难题；

基于相同主键的物理模型，可以构建逻辑模型，逻辑模型解决了数据复用的难题，提高了接口模型的发布效率；

来源：oschina

链接：https://my.oschina.net/u/4316695/blog/4535040

标签

Hadoop

Apache Atlas

metacat

mysql