如何快速构建自己的数据中台知识体系

问题导读
1.数据中台为什么很难成功？
2.为什么数据中台是大数据的下一站？
3.什么样的企业应该建数据中台？


一、开篇词
1.1 数据中台为什么很难成功呢？
客观原因：数据中台的建设是一项 系统性工程，从 组织架构、支撑技术到流程规范，既要有宏观的顶层设计，又要有强有力的落地执行，团队要求较高
主观原因：企业本身数据建设经验不足，不清楚数据建设中的痛点，更不知道用什么样的技术手段和管理机制去解决问题

1.2 方法论先行
通过原理方法论的学习，希望大家能弄明白下面三个问题：

• 什么是数据中台？
• 数据中台解决了什么问题？
• 如何来规划数据中台的建设？
  

不管是数据中台还是业务中台，归根结底都是业务驱动第一性原理。

中台是 技术+方法论+工具 的沉淀，在做任何的系统前我们都需要深刻反思业务的来源、现状，未来我们业务的核心价值观是什么？

这当中有管理也有技术，驱动业务数据化，数据资产化，资产服务化，服务业务化的循环。

而数据中台无疑是要让数据这种资产价值最大化，成为企业的重要基础设施，重要的生产资料。

1.3 实践出真知
这部分主要侧重数据中台支撑技术的整体架构，逐一讲述每个模块的具体实现。

了解企业在数据建设中到底存在哪些痛点，以及如何解决这些痛点。





数据中台一定是基于大数据体系的，内在是数仓，底座是大数据计算平台。

数据中台建设的目的就是为了让数据持续的用起来，赋能业务，提高响应能力和洞察能力，而上述的每一个点都是不可或缺的。


二、为什么数据中台是大数据的下一站？
2.1 启蒙时代：数据仓库的出现
商业智能（Business Intelligence）诞生在上个世纪90年代，数据分析需要聚合多个业务系统的数据，传统数据库已经不能满足数据分析场景。

Bill Inmon 1991年 给出数仓定义：

数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。

Bill Inmon 提出的建模方法：

• 自顶向下（这里的顶指数据来源）
• 基于业务中各个实体以及实体之间的关系构建数据仓库
  

Kimball 则提出了与 Bill Inmon 正好相反的建模方法，一种自底向上的模型设计方法。


两种方法各有优劣：

Bill Inmon

• 从数据源开始构建，构建成本高，适用于比较固定的业务，如金融领域
• 冗余数据少是它的优势
  

Kimball

• 从分析场景出发，适用于变化速度较快的业务，比如互联网业务
• 现在业务变化较快，更适合用kimball维度建模
  

2.2 技术变革：从Hadoop到数据湖

互联网时代的变革

• 数据规模前所未有的庞大
• 数据类型的异构化
  

数据规模和数据类型的限制，导致传统数据仓库无法支撑互联网时代的商业智能。

互联网巨头谷歌率先开始相关的探索，三驾马车奠定了现代大数据的技术基础。

• 《The Google File System》
• 《MapReduce：Simplified Data Processing on Large Clusters》
• 《Bigtable：A Distributed Storage System for Structed Data》
  

Hadoop相比于传统数仓的优势

• 完全分布式，易于扩展，价格低廉能满足海量数据的处理需求
• 弱化数据格式
  

Data Lake

数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。

随着Hadoop技术日趋成熟，2010年 数据湖的概念在 Hadoop World 大会上被提出，同样也拉开了Hadoop商业化的大幕。


2.3 数据工厂时代：大数据平台兴起
进入数据工厂的时代，我们首先要面对的就是数据开发复杂的流程：从数据集成、数据开发再到数据测试、数据发布、任务运维。

如此繁杂的工作流程，如果没有搞高效的平台支撑，自然效率低下。大数据平台概念的提出，就是为了提高数据研发的效率，降低研发门槛。

大数据平台是面向数据研发场景的，覆盖数据研发的完整链路的数据工作台

2.4 数据价值时代：数据中台崛起
在大规模数据的应用场景下，也逐渐暴露除了一些问题：

• 烟囱式的开发导致企业的数据互相割裂，业务对数据的信任度下降
• 大量重复的计算、开发，导致研发效率的浪费，大数据应用成本越来越高
  

我们需要明白数据中台的核心：避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。

共享、连接和服务，这是中台思想的根。


那为什么说数据中台是大数据的下一站呢？

我想可以从下面四点来考虑：

数据中台构建于数据湖之上，具备数据湖异构数据统一计算、存储的能力，同时让数据湖中杂乱的数据通过规范化的方式管理起来；
数据中台需要依赖大数据平台，大数据平台完成了数据研发的全流程覆盖，数据中台增加了数据治理和数据服务化的内容；
数据中台借鉴了传统数据仓库面向主题域的数据组织模式，基于维度建模的理论，构建统一的数据公共层；
数据中台吸收了传统数据仓库、数据湖、大数据平台的优势，同时又解决了数据共享的难题，通过数据应用，实现数据价值的落地；


学习思考：数据中台的下一站是什么？

• 实时数据中台，实现流批一体
• 云上数据中台，全面拥抱K8S，实现在线、离线混合部署，进一步提高资源利用率
• 智能元数据管理+增强分析，降低数据分析的门槛，进一步释放数据智能
• 自动化代码构建，进一步释放数据研发的效能
• 数据产品的时代，面向各行业的数据产品全面涌现，并和数据中台实现联动
  

三、什么样的企业应该建数据中台？
企业数据日常在使用时，往往会面临以下的问题：

• 指标口径不一致
• 需求响应慢
• 取数效率低
• 数据质量差
• 数据成本增长过快
  

而这些问题的背后，主要由以下几点原因构成：

缺少全局统一的指标管理；
烟囱式的开发导致数据重复建设；
找不到数据，非技术的同学取数困难；
数据加工的链路过长，出现问题很难及时发现；
数据重复建设，无用的数据加工消耗了大量的资源。

数据中台该如何解决这些问题呢？

确保全局指标业务口径、数据来源、计算逻辑一致
相同聚合粒度的度量、指标只加工一次，避免重复建设
构建企业数据资产目录，提供非技术人员取数工具
全链路稽查监控，早发现、早处理、早恢复
计算每个应用、报表、指标的ROL，避免低价值的数据加工

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

拥有多个数据应用场景
存在业务数据孤岛
面临效率、质量和成本的问题
需要借助数据提高企业经营效率
业务相对稳定的有一定规模的公司


四、数据中台建设的三板斧
如果我们把建数据中台比作是盖房子，那么设计图纸就是数据中台建设的方法论；工具是数据中台的支撑技术；施工队伍就是数据中台的组织架构。这三者缺一不可。

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

OneData

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

具体来说主要由以下五点：

分主题域管理
命名规范定义
指标一致
数据模型复用
数据完善
这里离不开OneData的具体的实施流程，前面在 ： 什么是OneData？阿里数据中台实施方法论解读 有详细的解读，这里就不再赘述。

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

OneService

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

屏蔽异构数据源：数据服务必须要能够支撑类型丰富的查询引擎，满足不同场景下数据的查询需求。
数据网关：实现包括权限、监控、流控、日志在内的一系列管控能力，哪个应用的哪个页面访问了哪个模型，要做到实时跟踪，如果有一些模型长时间没有被访问，应该予以下线。
逻辑模型：从用户的视角出发，屏蔽底层的模型设计的实现，面向用户提供逻辑模型。
性能和稳定性：由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展。

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


4.2 支撑技术




这个图完整地描述了数据中台支撑技术体系，它的底层是以 Hadoop 为代表的大数据计算、存储基础设施，提供了大数据运行所必须的计算、存储资源。

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

灰色的部分，是数据中台的核心组成部分：数据治理模块。它对应的方法论就是 OneData 体系。

深绿色的部分是数据服务，它是数据中台的门户，对外提供了统一的数据服务，对应的方法论就是 OneService。


4.3 组织架构
什么样的组织架构是适合数据中台建设的呢？简单总结几点如下：

独立于业务线的中台组织部门
中台团队必须深入业务，懂业务
中台团队的组织架构
数据产品
数据开发
数据平台
数据应用
中台团队的组织绩效必须与业务绑定

最新经典文章，欢迎关注公众号

原文链接：https://blog.csdn.net/BeiisBei/article/details/118005051