大数据开发工程师-第十八周 直播平台三度关系推荐v2.0-3

---

第十八周 直播平台三度关系推荐v2.0-3

数据中台的前世今生

什么是中台

中台是2019年开始火起来的一个概念，它最早是由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念，灵感来源于一家芬兰的小公司Supercell——一家仅有300名员工，却接连推出爆款游戏，是全球最会赚钱的明星游戏公司。2015年年中,马云带领阿里巴巴集团高管,拜访了位于芬兰赫尔辛基的这家移动游戏公司，这家看似很小的公司，设置了一个强大的技术平台，来支持众多的小团队进行游戏研发。这样一来，他们就可以专心创新，不用担心基础却又至关重要的技术支撑问题。恰恰是这家小公司，开创了中台的“玩法”，并将其运用到了极致。
下面我们举个例子，通过IT行业的发展来进一步理解什么是中台？为什么要出现中台？

传统IT时代

在传统IT时代，无论项目如何复杂，都可以分为 前台 和 后台 两部分，简单明了。
每一个业务线负责维护自己的前台和后台
这里的前台不仅仅包含前端页面，还包含提供的各种服务
后台指的是底层的服务，例如我们提取的一些工具服务
在当时，项目的发展相对稳定，并不需要像互联网时代那么快速的去迭代和试错，所以这种架构没有什么问题。

传统IT时代存在的问题

发展到现在这个时代，传统的前台+后台这种架构是存在一些问题的，每一个产品线之间都会有一些重复的内容，例如这里面的用户模块和支付模块，每一个产品线都需要，如果每一个产品线都是自己开发自己的，这样就会有三套用户模块和支付模块，对于集团公司而言，这就叫重复造轮子。如果后期又增加了新的产品线，还要重新再开发用户模块和支付模块。

所以说为了提高开发效率，我们有必要抽取出一个中间组织，为所有的产品线提供一些公共资源，这个中间组织就是中台。

下面来看一个引入了中台之后的案例。

本来是各个部门都建立了自己的数据采集，数仓，数据模型等内容，重复开发，浪费成本。各个部门的数据也没有打通，数据很难产生很大的价值。
引入了中台之后，构建了统一的数据采集、统一的数据资产中心、统一的数据建模、分析与挖掘、统一的数据服务，最终向各部门统一提供数据支撑。

阿里”大中台小前台架构 ”

接下来这个是阿里的大中台 小前台架构

阿里许多产品线的共通业务经过下沉，形成了中台的各种业务中心，为各大业务线提供支持。
这样前台应用就会更加灵活，想要构建一个新的前台应用也是比较快速容易的。

中台架构主要解决的问题

下面我们来总结一下中台这种架构主要解决的问题。

信息获取成本高，之前是每一个产品线都需要单独维护自己的数据，成本比较高。
服务具有不确定性，通过中台可以以不变应万变
互联互通成本高，不同产品线的数据想要打通成本过高。
低水平重复建设，不同产品线需要重复建设相同的模块。
通过中台，可以很好的解决这些问题。

中台的延伸

中台是一个大而全的概念，基于中台延伸出了多个方向
技术中台
移动中台
业务中台
数据中台
研发中台
组织中台
等等…

在这里我们可以把中台理解为航空母舰，这些中台都是基于这个航空母舰延伸出来的

技术中台提供了技术支撑能力，帮助我们解决了基础设施，分布式数据库等底层技术问题，为前台特种兵提供了精良的武器装备。

移动中台提供了战场一线火力支援能力，帮助我们提供更加个性化的服务，增强用户体验，为战场提供了陆军支援能力，随机应变，所向披靡。
注意：这里的移动中台并不是说这个中台会移动，这里的移动表示的是移动端的意思，就是手机端。

业务中台提供重用服务，例如用户中心，订单中心之类的开箱即用可重用能力，为战场提供了强大的后台炮火支援能力，随叫随到，威力强大。

数据中台提供了数据分析能力，帮助我们从数据中学习改进，调整方向，为战场提供了强大及时的雷达监测能力，帮助我们掌控战场。

研发中台提供了技术实践支撑能力，帮助我们快速搭建项目，管理进度，测试，持续集成，持续交付，是前台特种兵的训练基地及快速送达战场的机动运输部队。

组织中台为我们的项目提供投资管理、风险管理、资源调度等，是战场的指挥部，战争的大脑，指挥前线，调度后方。

阿里中台技术栈全景

接下来我们来看一下阿里的中台技术栈全景

最下面是一些基础设施和基础中间件
上层是业务中台和数据中台
其中业务中台里面是以业务进行区分，抽取出来的一些公共组件，例如：会员中心，商品中心，交易中心、订单中心、支付中心、评价中心
后期如果新增的产品线需要用到这些功能的时候可以从业务总台中直接开箱即用，提高效率。
数据中台中包含大数据计算服务(包含离线和实时)、大数据开发套件(这里面包含的是一些小工具)、画像分析、数据可视化、数仓规则、数据服务等，可以实现数据的一站式接入和使用。
移动中台包含了很多移动端的公共组件和功能。
基于这些中台就可以快速为上层这些应用提供各种支持了。

什么是数据中台

前面我们讲了什么是中台，中台其实是一个统称，基于中台也延伸出了很多分支。
每一个分支深究起来都有很多内容，不过目前来说，在这些中台的分支里面，数据中台是最为火热的，因为数据是可以直接为企业决策提供支持，可以直接产生价值的。

下面我们就来具体分析一下什么是数据中台
针对数据中台的定义业内目前有很多种说法，没有官方的定义，不同的人有不同的理解。

通俗来讲数据中台是指利用大数据技术，对海量数据统一进行采集、计算、存储，并且对外提供数据服务。
数据中台的主要作用在于将企业内部所有数据统一处理形成标准化数据，挖掘出对企业最有价值的数据，构建企业数据资产库，对内对外提供一致的，高可用的大数据服务。

正式一点来说，可以这样理解
数据中台是一套可持续 ”让企业的数据用起来 ” 的机制
通过数据中台把数据变为一种服务能力，既能提升决策水平，又能直接支撑企业业务
数据中台不仅仅是技术，也不仅仅是产品，而是一套完整的让数据用起来的机制。
数据中台不是单纯的技术叠加，不是一个技术化的大数据平台，二者有本质区别。
大数据平台更关心技术层面的事情，包括研发效率，平台的大数据处理能力，针对的往往是技术人员
而数据中台的核心是数据服务能力，数据中台不仅面向技术人员，更需要面向多个部门的业务人员。

数据中台的演进过程

数据中台并不是直接就有的，也是根据时代的发展，企业的需求，一步一步演进出来的。
下面我们就来看一下数据中台的演进过程。

1：最开始是 数据库阶段，主要是OLTP（联机事务处理）的需求；
以淘宝为例，最开始淘宝还只是一个简单的网站，淘宝的整个结构就是前端的一些页面，加上后端的数据库，只是个简单的OLTP系统，主要就是交易的事务处理。

这个阶段，互联网黄页才刚刚出现，数据来源大部分还是传统商业的ERP/CRM的结构化数据，数据量并不大，也就是GB的级别。简单的数据库就能满足需求。

随着淘宝用户超过100万，分析需求的比重就越来越大。淘宝需要知道它的交易来自于哪些地区，来自于哪些人，谁在买淘宝的东西等等，于是，就进入了数据处理的第二个阶段：数据仓库阶段。

2：数据仓库阶段，OLAP（联机分析处理）成为主要需求；
OLTP和OLAP对数据存储和计算的需求是不一样的，OLTP处理的是结构化的交易数据，而OLAP对应的是互联网数据，而互联网里面数据量最大的是日志，90%以上的数据都是用户点击之类的非结构化的日志数据，而且数据量已经达到了TB的级别。

针对分析需求，就诞生了数据仓库，数据仓库主要解决大量数据的存储和计算需求，也就是把非结构化的数据转化成结构化数据，存储下来。

这个阶段，数据仓库支持的主要就是BI和报表需求。

随着数据量越来越大，从TB进入了PB级别，原来的技术架构越来越不能支持海量数据处理，这时候就进入了第三个阶段：数据平台阶段。

3：数据平台阶段，主要解决BI和报表需求的技术问题；
这个阶段解决的还是BI和报表需求，但是主要是在解决底层的技术问题，也就是数据库架构设计的问题。

这在数据库技术领域被概括为「Shared Everything、Shared Nothing、或Shared Disk」，说的就是数据库架构设计本身的不同技术思路之争。

Shared Everything一般是针对单个主机，完全透明共享CPU/MEMORY/IO，并行处理能力是最差的，典型的代表SQLServer。

Shared Disk的代表是Oracle RAC，用户访问RAC就像访问一个数据库，但是这背后是一个集群，RAC来保证这个集群的数据一致性。

问题在于Oracle RAC(实时应用集群)是基于IOE架构的（使用IBM的小型机、Oracle数据库、EMC存储设备）。在海量数据处理上，IOE架构有天然的限制，不适合未来的发展。

Shared Nothing的代表就是Hadoop。Hadoop的并行处理和扩展能力更好。

Hadoop的好处是如果要增加数据处理的能力和容量，只需要增加服务器就好，成本不高，在海量数据处理和大规模并行处理上有很大优势。

综上所述，第三阶段就是，建立Shared Nothing的海量数据处理平台来解决数据存储成本增长过快的问题。

4：数据中台阶段，通过系统来对接OLTP（事务处理）和OLAP（报表分析）的需求，强调数据业务化的能力。
这个阶段的特征是数据量呈现指数级增长，从PB迈向了EB级别，未来会到什么量级，谁也说不清楚。

主要是因为，2015年之后，IOT（物联网）发展起来，带动了视频、图像、声音数据的增长，未来90%的数据可能都来自于视频、图像、声音这些非结构化数据，这些数据需要视觉计算技术、图像解析引擎+视频解析引擎+音频解析引擎来转换成结构化数据。5G技术的发展，可能会进一步放大视频、图像、声音数据的重要性。

线下要想和线上一样，通过数据来改善业务，就要和线上一样能做到行为可监测，数据可收集，这是前提。线下最大量的就是视频、图像、声音数据，而这些数据靠人来手工收集，肯定是不靠谱的，依靠IOT（物联网）技术和算法的进步，最终会通过智能端来自动化获取数据。

要使用这些数据，光有视觉算法和智能端也不行，要有云来存储和处理这些数据，以及打通其它领域的数据。

目前的数据中台，最底层的数据平台还是偏技术的，是中台技术方案的其中一个组件，主要解决数据存储和计算的问题；在往上面就是一层数据服务层，数据服务层通过服务化API能够把数据和前台的业务层对接；数据中台里面都是系统去做对接，通过智能算法，能把前台的分析需求和交易需求去做对接，最终赋能业务。

数据中台 VS 数据仓库

数据仓库主要支持管理决策和业务分析
数据中台是将数据服务化之后提供给业务系统，目的是将数据能力渗透到各个业务环节，不限于决策分析类场景
数据中台建设包含数据体系建设，也就是数据中台包含数据仓库的完整内容
所以说数据仓库阶段的成果是可以转化到数据中台阶段的，并不会全部推倒重做。

数据中台需要具备的四大能力

根据我们前面对数据中台的分析，总结起来，数据中台需要具备以下能力：
1：数据汇聚整合
随着业务的发展，企业内部往往有多个信息部门和数据中心，大量系统、功能和应用重复建设，存在巨大的数据资源、计算资源和人力资源的浪费，同时组织壁垒也会导致数据孤岛的出现，使得内外部数据难以全局规划，数据中台需要对数据进行整合和完善。

2：数据提纯加工
数据就像石油，需要经过提纯加工才能使用，这个过程就是数据资产化。
数据中台必须联通全域数据，通过统一的数据标准和质量体系，建设提纯加工后的标准数据资产体系，以满足企业业务对数据的需求。

3：数据服务可视化
为了尽快让数据用起来，数据中台必须提供快捷，快速的数据服务能力，让相关人员能够迅速开发数据应用，支持数据资产场景化能力的快速输出，以响应客户的动态需求。

4：数据价值变现
数据中台通过打通企业数据，提供以前单个部门无法提供的数据服务能力，以实现数据的更大价值变现。

数据中台架构

数据中台总体架构图

前面我们通过理论层面对数据中台有了一定的了解，下面我们通过架构层面来详细看一下数据中台的设计

数据中台是位于底层存储计算平台与上层的数据应用之间的一整套体系。
数据中台屏蔽掉底层存储平台的计算技术复杂性，降低对技术人才的需求，让数据的使用成本更低。
通过数据中台的数据汇聚、数据开发模块建立企业数据资产。
通过数据体系对数据进行分层存储
通过资产管理、数据服务，把数据资产变为数据服务能力，服务于企业业务。
数据安全管理、数据运营体系，保障数据中台可以长期健康、持续运转。

数据汇聚
数据汇聚是数据中台数据接入的入口，数据中台本身不产生数据，所有的数据来自于业务系统，数据库、日志、文件等，这些数据分散在不同的网络环境和存储平台中，难以利用，很难产生业务价值，所以需要统一汇聚。

数据开发
数据开发是一整套数据加工以及处理的工具，因为通过数据汇聚模块汇聚到中台的数据没有经过处理，基本是按照数据的原始状态堆砌在一起的，这样业务是很难直接使用的。所以需要通过数据开发模块实现对数据的加工处理，形成有价值的数据，提供给业务部门使用。

数据体系
通过数据汇聚、数据开发，中台就具备了构建数仓平台的基本能力，这一块其实就是将采集过来的各种数据按照数仓的标准进行建设。

数据资产管理
通过数仓建立起来的数据资产比较偏向于技术，业务人员比较难理解，资产管理是以业务人员更好理解的方式，把数据资产展现给企业的业务人员。

数据服务体系
数据服务体系就是把数据变为一种服务能力，通过数据服务让数据参与到业务，激活整个数据中台，数据服务体系是数据中台存在的价值所在。

数据运营体系
是数据中台得以健康、持续运转的基础

数据安全管理
是为了保证数据中台中的数据安全。

这是一个典型的数据中台总体架构设计。

数据中台 四字箴言

如果大家之前没有工作过的话，可能对数据中台还是不好理解，所以在这我将数据中台的功能总结为四个字：采、存、通、用

下面我们来详细分析一下这四字箴言

采
采：表示采集的意思，就是采集企业中的所有数据。
随着互联网、移动互联网、物联网等技术的兴起，企业的业务形态开始多元化，数据的产生形式也是多样化的，对应的就需要有多种采集形式

埋点采集、硬件采集、爬虫采集、数据库采集、日志采集

埋点采集：一般是采集用户行为信息，例如用户在平台上的浏览、点击、停留等行为
硬件采集：指的是物联网数据采集，例如通过无人机传感器来采集空气质量指标
爬虫采集：指的是采集互联网上的公开数据，例如：电商平台竞品价格采集
数据库采集：一般是采集企业内的业务数据，例如：用户交易数据、用户个人信息数据等
日志采集：一般是采集软件运行时产生的日志

这些是常见的采集形式

从数据组织形式可以分为：结构化数据、半结构化数据、非结构化数据
结构化数据：数据规则、完整、能够通过二维逻辑来表现的数据，严格遵守数据格式与长度规范，常见的有数据库中的数据、excel中的数据
半结构化数据：数据规则、完整，同样严格遵守数据格式与长度规范，但无法通过二维关系来表现，常见的有JSON、XML等格式的数据
非结构化数据：数据结构不规则或不完整，不方便用二维逻辑表来表现，需要经过复杂的逻辑处理才能提取其中的信息内容，常见的有word文档、图片、视频、音频等数据

从数据的时效性上来划分，可以分为：离线数据、实时数据
离线数据：主要用于大批量数据的周期性迁移，对时效性要求不高，一般采用分布式批量数据同步的形式，通过连接读取数据，读取数据过程中可以有全量、增量的方式，经过统一处理后写入到目标存储。
实时数据：主要面向低延时的数据应用场景，一般通过实时监控的方式实现，例如通过读取数据库的binlog日志来实现数据库的实时数据采集。

前面我们针对数据的采集形式、数据的组织形式、数据的时效性进行了分析，那这些数据在采集的时候具体应该使用什么类型的工具呢？

常见的采集工具有：Flume、FileBeat、Logstash、Sqoop、Canal、DataX等
其中Flume、FileBeat、Logstash适合采集日志数据，这三个组件的特性在前面项目课程中已经详细分析过了，在这不再赘述。
sqoop是在结构化数据和HDFS之间进行批量数据迁移的工具，适合批量采集数据库中的数据，它的主要优势是，在特定场景下，数据交换过程会有很大的性能提升。主要缺点是处理过程定制程度较高，需要在脚本中调整配置参数实现，在用户的一些自定义逻辑和数据同步链路监控方面比较薄弱。
DataX是阿里开源的一套数据采集工具，提供数据采集全链路的流量监控，将作业本身的状态，数据流量，数据速度，执行速度等信息进行展示，提供脏数据探测功能，支持传输过程中对传输报错进行策略化处理。由于它是基于进程内读写直连的方式，高并发数据采集场景下对机器内存要求比较高。不过DataX不支持非结构化数据的采集。

这些单个工具都无法很好的满足企业复杂的数据采集场景，所以我们需要对已有的采集工具进行二次开发，以可视化配置的方式提供给用户，屏蔽底层工具的复杂性，要支持常见的数据源采集：关系型数据库、NoSQL数据库、MQ、文件系统等，并且支持增量同步、全量同步等方式。

存
将数据采集过来之后，就需要考虑数据存储了。
在这里我们可以将数据分为两种：静态数据和动态数据
其中静态数据：是以 HDFS 、S3等分布式文件系统作为存储引擎，适用于高吞吐量的离线大数据分析场景。这类存储的局限性是数据无法进行随机的读写。
动态数据：是以 HBase、Cassandra等NoSQL数据库作为存储引擎，适用于大数据随机读写的场景。这类存储的局限性是批量读取吞吐量远不如HDFS，不适合用于批量数据分析的场景。

通
表示是对数据进行加工计算，构建企业级数据仓库，打通企业中的全域数据。
针对数据的加工计算，可以分为两大块，离线计算和实时计算
离线计算中的代表框架为：MapReduce、Hive、和Spark
实时计算中的代表框架为：Storm、SparkStreaming和Flink，针对实时计算，现在主要是以Flink为主了。
针对这些计算框架，如果每一个计算任务都需要开发代码的话，对使用人员就不友好了，特别是针对一些业务人员，他们不会写代码，只会写SQL，所以这时候我们就需要开发一套基于SQL的一站式开发平台，底层引擎使用Spark和Flink，支持离线数据计算和实时数据计算。
让用户彻底规避掉繁重的底层代码开发工作。

用
企业全域数据采集、存储，打通之后，就涉及到如何去用了。
这里的”用” 包含很多层面。
首先是包括数据资产管理，也可以称之为数据治理，其中包含数据元标准管理，数据标签管理，数据模型管理、元数据管理、数据质量管理等，保证数据中台里面数据的合理化和规范化，充分发挥数据的价值。
对于数据的拥有者和管理者来说，通过对数据的合理管理和有效应用，能盘活并充分释放数据的巨大价值，但如果不能对数据进行有效管理，数据就用不起来，或者即使用起来也用不好，在这种情况下，堆积如山的无序数据给企业带来的是高昂的成本。

在使用数据的时候还需要做好数据安全管理，随着大数据技术和应用的快速发展，数据所承载的多维度业务价值已被越来越多的挖掘和应用变现，随之而来的是数据安全和隐私已经成为世界性的关注点，上升到国家战略层面，最近闹得沸沸扬扬的特朗普要禁用国外版的抖音(TikTok)事件，特朗普的理由就是TikTok平台的数据对他们产生了威胁。
所以说数据安全很有必要，整体的数据安全管理体系通过分层建设、分级防护，创造面向数据的安全管理体系系统框架，形成完整的数据安全管理体系。
数据中台的建设，应该始终把数据安全管理放在最重要的位置上，通过设计完备的数据安全管理体系，多方面，多层次保障数据安全。

最终我们需要把安全、有价值的数据快速方便的提供给上层应用，此时需要通过数据服务对外开放，也就是API接口的形式。
举个例子，水是生命之源，是人们赖以生存和发展的重要物质资源，在日常生活中，可以通过不同的方式使用水，这也给我们的生活带来了巨大便利。
在数据世界中，数据资产就好比日常生活中生命所需的水资源，无处不在且不可或缺。但是如果没有相应的水加工厂，运输管道，人们只能到水库打水喝，这明显会极大影响人们正常的生活和工作。因此，将数据封装成数据服务，以接口形式提供给上层应用，才能极大释放、提升数据资产的价值。

最后总结一下，数据中台其实可以这样理解，采集企业全域数据，存储起来，通过加工计算打通数据之间的关系，最后以API接口的形式对外提供数据服务。这就是数据中台要做的事情。

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

前面我们分析了什么是数据中台，数据中台的好处，以及数据中台的架构，是不是所有的企业都需要构建数据中台呢？
不是的，下面就来看一下到底什么样的企业适合建设数据中台

看这个案例：
某企业下面有多个科研实体，每个科研实体下面有多个研究中心
类似于一个集团公司，下面有多个子公司，每个子公司里面还有多个产品线。
这种类型的企业业务复杂，有丰富的数据维度和多个业务场景，比较适合建设数据中台。
初创型企业没有必要搭建数据中台，首先要解决的是生存问题，甚至于连数据仓库都没必要搭建，需要等企业走上正轨进入快速发展期的时候才需要构建数据仓库、数据中台。

数据应用成熟度的四个阶段

当然了，评价一个企业是否适合建设数据中台，也是有一些量化指标的，可以根据企业中的数据应用成熟度来进行判断，我们可以把企业中数据应用成熟度分为四个阶段

统计分析
决策支持
数据驱动
运营优化

针对不同的阶段，从企业战略定位、企业数据形态、数据应用场景、数据应用工具、企业组织架构等多个方面，不同特征维度进行参考判定，也就构成了数据应用成熟度评估模型。
依据这四个阶段的划分标准，企业可以进行数据应用成熟度的自我评测。
数据应用成熟度越高，则代表数据对业务的支撑能力越强，数据应用成熟度越低，则意味着业务对数据的依赖程度越低。

来看一下具体的评估模型。

第一阶段：统计分析阶段
统计分析阶段主要有以下特征
1：在企业战略方面，该阶段的企业战略定位纯粹以业务为驱动，主要以满足企业业务需求，实现业务流程的流程化、自动化为导向。
2：在企业数据形态方面，该阶段的企业可能有少量的业务数据积累，但没有以数据为导向积累数据，数据主要以业务系统依托的关系型数据库进行存储，数据无组织，各业务数据分散存储和管理，数据维度单一，无数据质量管控。
3：在数据应用场景方面，该阶段的数据应用场景只针对业务系统中的关键数据和指标，进行简单的、单一维度的统计分析和管理，辅助业务总结，每次基于业务目标的数据统计都需要定制化开发，如周报、月报等。
4：在数据应用工具方面，该阶段业务报表主要以系统内嵌报表以及Excel报表为主，模式相对单一。
5：在企业组织架构发面，该阶段企业无专门的数据相关部门，主要以IT部门的数据库运维管理和业务部门的数据分析师为主，需要数据报表时，一般用系统中定制的统计报表或者由特定业务部门提供Excel报表。

如果对数据的应用仅停留在单系统、单维度的统计分析上，只用于对历史业务开展情况进行简单分析，数据并没有发挥出应有的价值，数据只是辅助企业了解业务运转的情况。我们希望能通过数据为业务决策提供支撑，因此就出现了第二阶段

第二阶段：决策支持阶段
决策支持阶段主要有以下特征
1：在企业战略方面，该阶段，企业开始具备通过数据支撑经营决策的思路，并在考虑通过数据可视化的方式实现数据与业务的融合，以解决业务问题和支撑管理决策。
2：在企业数据形态方面，企业开始注重业务过程中的数据积累，开始对各业务环节的数据进行汇聚、管理、数据维度逐渐丰富。以面向业务主体的指标体系为形式进行数据组织，开始注重数据质量的管控，实施数据质量控制。
3：在数据应用场景方面，该阶段的数据应用场景开始基于数据仓库进行各业务主题的数据收集、管理、分析，为企业管理人员提供决策支持。
4：在数据应用工具方面，开始针对数据收集和管理 建立数据仓库，数据开发工具和专业可视化工具，进行系统化数据收集、管理和分析。
5：在企业组织架构发面，开始出现数据分析师的岗位，可能会设立专门的数据挖掘或商业智能部门来支撑企业进行数据化决策。

无论是在统计分析阶段还是决策支撑阶段，业务的运转和数据之间依然是相互隔离的。企业对数据的应用都还停留在对部分维度的业务数据进行分析得到结果后，再由人工对业务进行不同程度的干预，最终实现业务优化。而我们希望能够让数据直接驱动业务变得更精准，更有效。最典型的应用场景就是类似于头条、抖音里面的个性化推荐功能，通过数据直接驱动业务的优化。所以就出现了第三阶段

第三阶段：数据驱动阶段

数据驱动阶段主要有以下特征
1：在企业战略方面，企业开始将数据作为重要资产和生产资料，通过大数据技术对企业相关数据进行汇聚、打通和分析挖掘，为业务应用提供数据服务，通过数据驱动业务发展。
2：在企业数据形态方面，业务数据积累具备一定规模，对结构化数据、非结构化数据进行处理与应用，根据需求进行数据清洗加工和标准化处理。
3：在数据应用场景方面，该阶段的数据应用场景主要以满足业务需求为主，主要是用数据提升现有业务能力，进行智能化升级。
4：在数据应用工具方面，在该阶段，企业开始通过大数据生态体系中的批计算、流计算等大数据处理技术进行数据汇聚和开发，并最终为现有的业务场景赋能，以驱动业务升级。
5：在企业组织架构发面，在该阶段，企业开始正式设立独立的大数据部门。

数据驱动阶段，数据其实已经与业务紧密结合，数据在业务运转过程中直接产生价值，但是，由于数据应用都是独立建设的，没有从全局考虑，企业在数据应用的过程中，经常会遇到标准口径不一致，内容重复建设，各业务数据无法融合产生更大的价值，企业数据价值无法被业务快速应用等问题，因此，出现了第四阶段

第四阶段：运营优化阶段
运营优化阶段主要有以下特征
1：在企业战略方面，该阶段，企业开始建设数据中台，数据中台定位是为企业未来5~10年发展提供数据能力支撑，在DT时代对企业进行智能化升级。
2：在企业数据形态方面，在该阶段，企业数据伴随数据驱动的业务快速发展，数据量快速增长，通过建立企业体系化，标准化的数据采集、存储、实现企业数据的全面资产化。
3：在数据应用场景方面，在该阶段，数据应用通过统一的数据资产体系，提供统一、标准化的数据服务能力，为企业各类快速变化的业务应用提供数据服务支撑。
4：在数据应用工具方面，建立一套体系化的数据汇聚、加工、管理、服务及应用体系，逐渐实现大数据能力工具化，工具平台化，平台智能化。
5：在企业组织架构方面，在该阶段，企业组织架构中开始在管理层设置数据管理委员会来负责数据机制的建设和管理，将数据变为企业的一种独特资产。同时也会成立专门的资产运营部门，保障数据资产应用的合理性和效率，将更多的数据服务消费者引入到数据平台之中。

这就是数据应用成熟度的四个阶段，目前中大型企业大部分处于从决策支持阶段转向数据驱动阶段，一些一线大型互联网企业正在处于从数据驱动阶段转向运营优化阶段。
目前数据中台正处于快速发展阶段，成熟的大型公司都在开始着手构建数据中台。

案例分析

下面有几个小案例，我们来分析一下

企业A：类似于”万能钥匙 ”之类的工具类APP，随着DAU的增加，需要给用户提供个性化推荐内容
目前比较合适的是启动一个内容推荐类的算法项目，在可预见的将来，看不到更多的数据场景，所以不适合建设数据中台。

企业B：类似于”百果园 ”之类的连锁店，门店数量比较多，需要用大数据来精细化运营用户和商品
因为具备了一定的门店规模和数据规模，可以实现一些个性化营销推送，商品猜你喜欢等功能，比较适合建设数据中台。

企业C：类似于”华为 ”这样的多业态集团公司，旗下有多个业务板块，各个业务板块都有自己的数仓和报表

这种属于多业态集团公司，是最适合建设数据中台的。

数据中台企业级解决方案

前面我们对数据中台的理论进行分析，下面我们来看一下，数据中台在一些大型企业中的落地方案

阿里数据中台

在国内，”中台”的概念是阿里带头喊出来的，所以我们先来看一下阿里的数据中台方案

最底层是计算和存储平台
往上面是垂直数据中心，负责全域数据采集与引入，以需求为驱动，以数据多样性的全域思想为指导，采集与引入全业务、多终端、多形态的数据；
再往上面是公共数据中心，按照基础层、公共中间层、应用层的数据分层架构模式，通过数据指标结构化、规范化的方式实现指标口径统一
再往上面是萃取数据中心，形成以业务核心对象为中心的连接和标签体系，深度萃取数据价值
再往上面是统一主题式服务，通过构建服务元数据中心和数据服务查询引擎，面向业务统一数据出口与数据查询逻辑，屏蔽多数据源与多物理表；
左侧是数据资产管理：通过资产分析、应用、优化、运营等方面实现降低数据管理成本、追踪数据价值。

最上层的是不同的产品线应用，通过下面的数据中台提供一站式数据服务支撑。

阿里数据中台有三大核心：

OneData（统一数据）：定义数据标准与建模标准，对离线数据、实时数据建立数据资产体系
OneEntity（统一实体）：主数据的管理，实现全域产品体系主数据融合
OneService（统一服务）：统一对外提供API与SDK服务
这就是阿里数据中台的三大核心。其实就是将全域数据统一标准，然后打通，最终统一对外提供数据服务。

菜鸟数据中台

整体技术架构，分三层，底层是基础设施，基础平台，中间是中台，上面是前台。
有些同学可能会有困惑“数据中台和大数据平台”的区别是什么？
图中的基础平台就是我们常说的大数据平台，包含了数据的采集、计算、加工等。
数据中台是构建在整个大数据平台之上的，它是围绕数据运营、分析、应用等场景去做的一套解决方案。

数据中台分成两块，一个是数据层，一个是服务层。数据层就是我们前面说的“数仓“，这里边包含菜鸟的所有数据，沉淀的数据资产。
再往上是服务层，这里划分成了几个套件，每个套件都是围绕数据使用的一个场景做的解决方案 。

右侧的东西是数据管理套件，从数据的加工生产到使用，它从全链路的视角把数据给管理起来。

最上层是前台业务。

滴滴数据中台

最底层是数据架构：数据架构体系包含了当前大数据领域主流的技术

再往上面是数据研发，数据中间件，实现数据的采集，计算和数据质量监控。

再往上面是数据资产体系，构建了数据字典和数据图谱，然后通过数据赋能，提供各种自助查询和可视化分析。

最上层是数据服务层，将数据服务化提供给各个产品使用。

苏宁数据中台

最底层是大数据计算存储引擎
上层是数据开发套件，负责加工计算数据，
然后是数据仓库主题域，构建多维度的数据主题，
接下来是数据治理套件，管理数据模型，保证数据质量。

再往上层是数据应用引擎，这里面包含了可视化引擎，数据服务引擎，数据分析引擎和画像引擎，通过这几个引擎对外提供数据服务。

最上层是数据应用层，主要是使用数据的。

华为云数据中台

华为云数据中台在这里可以划分为三块

第一块是数据建设：其实就是把全域数据采集过来，对数据加工计算，基于各种维度构建数据主题。
第二块是平台建设：这里面抽取出来了一些公共的功能组件，并且提供了数据服务。

第三块是中台消费场景，这里面会有多种场景依靠数据中台提供数据支撑。

浙江移动数据中台

浙江移动打造的数据中台，是为了实现跨域数据整合并沉淀公共的数据能力，同时提供丰富的数据模型，标准化的数据服务，个性化的开发平台与工具，满足一线数据开放和智慧运营的要求。
这个数据中台架构中主要包含了三块内容
数据模型、数据服务和数据开发。

数据模型：负责实现数据与数据模型打通。
数据服务：负责封装标准数据服务，对外提供数据查询服务
数据开发：针对各种个性化数据应用开发需求提供技术支持

某大数据服务商数据中台

底层是基础设施和计算层
往上面是数据开发治理模块，里面涉及离线数据开发、实时数据开发和算法开发。
再往上层是数据服务层，这里面会对数据进行体系化，最终对外提供服务。
最上层是业务应用层，这里会通过数据服务提供数据支撑。

某企业数据大脑

这个是某企业的数据大脑总体设计，里面包含了数据中台。
数据大脑主要是为了解决大数据系统建设中数据存储、连通、使用的共性问题，形成业务数据中台，包括数据资源的统一规划，数据整体建模和资产管理，数据标签化计算，形成不同行业的数据体系。
将行业知识库和领域数据相结合，开发各类计算组件，构建统一数据加工平台，对数据进行加工整理支撑行业应用，形成相关领域行业的数据大脑。

这里面的数据中台主要包含以下内容：

到这为止，我们分析了多个企业的数据中台，虽然这些企业的数据中台架构没有完全一样的，但是总结下来我们会发现，他们里面都会有一些共同的核心内容。
数据采集存储、数据加工计算，整合打通各个维度数据，最后对外提供数据服务。
其实精简之后就是我在前面给大家总结的数据中台四字箴言，采存通用。

希望通过我们前面的学习能够然大家对数据中台有一个整体的认识。

数据中台之数据加工总线

目前大数据领域实时计算的现状

随着大数据行业的整体发展，企业对实时计算的需求越来越多，特别是在构建实时数仓的时候，需要接入很多实时数据源，并且数仓还是分层的，针对每一层的数据都需要进行实时计算，此时就需要开发很多实时计算程序，实时计算程序的复用性很低，针对每一种类型的数据都需要开发对应的实时计算程序，开发成本高，并且对程序员也不友好，需要专门的大数据开发工程师，所以我们希望在实时计算领域能够提供类似HiveSQL的功能，直接写SQL就能实现实时计算任务，不需要每次都写一堆的代码，提高工作效率，尽可能让会只会SQL的普通开发人员也能轻松的开发实时计算任务。

为了解决这个痛点，于是，我们研发了数据加工总线平台，也可以称之为数据实时流转平台。

什么是数据加工总线

为了使实时数据的处理能够更加高效、简单，所以我们研发了一站式实时数据开发平台。只需要在页面选择数据源、目的地以及对应的SQL计算逻辑，就可以轻松实现海量实时数据计算任务的开发。

这个平台主要的功能就是支持SQL实现实时数据计算任务的开发。

我们期望达到的目标，通过这套平台，可以实现用SQL解决80%以上的实时数据计算需求。

数据加工总线原型图总览

由于数据加工总线涉及前端和后端，在企业中前端代码有专门的同事负责开发，我们大数据部门只需要负责后台功能开发即可，所以在课程中不涉及前端页面代码，在这里通过原型图来演示一下数据加工总线具体的使用流程，加深大家的理解。
注意：原型图只能在这里给大家演示一下，不能发出去，希望大家理解。

数据加工总线架构图V1.0

接下来看一下数据加工总线的后台架构图

数据源和目的地都是Kafka，因为目前在大数据领域，实时数据一般都是用的Kafka。
中间就是我们需要开发的核心计算引擎，基于SparkSQL封装的实时SQL计算引擎。
为什么在这要选择使用SparkSQL？
因为SparkSQL在我们公司已经广泛应用了很长时间了，并且Spark框架本身也迭代了很多版本了，比较稳定，整个生态圈也比较完善。所以前期在技术选型的时候优先考虑的是底层计算引擎的稳定性。
还有就是秒级别的延时是可以满足业务需求的，所以当时SparkSQL+SparkStreaming是最好的方案。
Flink当时版本还不是很稳定，FlinkSQL也是刚出现没多久，所以没有直接使用Flink。
当时我们也考虑了，等第一个版本稳定了以后，后期再把FlinkSQL也增加进来，提供两套底层计算引擎，可以根据需求进行动态切换。

针对这里面的数据字段和数据模型的概念做一下解释
由于我们需要在SparkSQL中基于kafka的数据进行建表，kafka中的数据我们使用的是json格式的，json格式的数据只有字段名称，缺少字段类型信息，官方一点来说其实就是缺少元数据信息，所以需要针对kafka中的数据定义元数据，这样才能在SparkSQL中建表。

注意：元数据的定义是在数据治理子系统中维护的。

---