数据中台架构体系理解

Posted 2023-04-09 splendor.s

       目前，大部分企业更倾向于数据集中采集、存储，并应用分层建设。这种方式一方面有利于应用系统的快速部署，另一方面也保证了数据的集中管理与运营，体现数据的资产、资源属性。

数据中台的出现弥补了数据开发和应用开发之间由于开发速度不匹配而出现的响应力不足等缺陷问题。

数据中台是国内学者提出的概念，起始于阿里的“大中台、小前台”概念。阿里的中台是从管理的角度出发，以中台事业部集中数据搜索，技术及产品，数据共享等多个部门的功能。其他组织或企业建设数据中台不一定需要成立中台事业部，但是数据集中治理与提升数据价值转换效率的思路是一致的。

数据中台通用体系架构

       从数据处理与数据治理两个维度出发，可以设计一个解耦的数据中台体系架构。该数据中台体系架构具有一定的柔性，可按照企业应用需求进行组合，或者对单个模块进行扩充，能满足大多数企业数据中台建设的需求。

数据中台的通用体系架构如上图 所示。该中台体系架构以减少功能冗余和提高功能复用为原则，把数据中台解耦为 6 个可以分别独立建设、演进的功能子系统。

数据结构与数据处理子系统是数据中台体系架构的核心，数据治理是提升数据价值的重要手段。该数据中台体系架构的通用性表现在以下几点。

• 该数据中台体系架构综合考虑了数据中台的各种要素，参考这个架构进行建设可以有效提升数据资产价值，提供数据及服务的共享。

• 参考这个数据中台体系架构，企业可以一次规划、分步实施。首先建设处理子系统及数据存储子系统，然后根据业务发展需求，逐步补充数据采集、数据安全及数据治理子系统。

• 该数据中台由 6 个解耦的子系统组成。企业在立项建设时可以灵活组合，每个子系统单独招标建设，也可以把多个子系统合并招标建设。数据中台通用体系架构包含数据存储框架、数据采集框架、数据处理框架、数据治理框架、数据安全框架及数据运营框架等 6 大部分。

1、数据存储框架

数据中台的核心是数据，数据通过采集系统获取，然后数据经过处理框架加工，并接受数据治理框架的管理，同时也要接受数据安全管理框架的管理，最后开放的价值数据将通过数据运营框架对外提供数据服务。 

数据中台的数据架构应该独立规划，并采用合理的技术架构对不同类型的数据进行存储。

数据存储框架中，无论数据采用对象存储、块存储还是数据库存储技术，各种中台数据可按照上图所示分类管理。

源数据主要由采集框架进行管理，数据治理框架按照数据特征把数据简单分为结构化和非结构化数据两大类，而规范化分域数据则是数据治理框架对全量数据的规范化分域整理。宽表数据是数据关联的结果，利用宽表数据可以对人、事、地、物、组等对象进行完整的数据画像，同时宽表数据也可以作为上层模型数据的中间层数据。

元数据和标签数据都是对数据的描述，其中元数据用来对数据的客观属性进行表示，标签数据更倾向于管理者对数据的主观表述及等级划分，比如质量等级标签、安全标签、属性标签等。主数据需要在各系统间频繁更新、交换，且需要独立的存储空间进行维护管理。

2、数据采集框架

数据中台的采集框架应对纳入数据中台的各种源数据进行统一采集管理。数据采集框架中应提供多种数据采集方式，如文件传输协议采集、数据库采集、接口应用程序接入采集、流式采集及网络爬虫采集。

同时采集框架应按照数据采集规范对源数据进行预处理，从而去除明显不需要的数据及多余数据，并对采集过程进行管理。虽然数据中台的体系架构没有统一模板，但各企业数据采集框架基本一致。

3、数据处理框架

数据处理是每个数据应用的基本环节之一，经典的数据抽取、转换和加载（ETL）处理流程在数据采集预处理、数据整合、数据建模等多个地方均要使用。单独建设数据处理框架有利于数据处理工具组件的集中开发与管理，也有利于数据中台数据处理任务的协调与调度。

数据处理框架专门负责数据处理相关的任务，包括批处理、流处理、人工智能分析、数据清洗、数据交换及查询，此外数据处理的相关工具组件可在处理框架中配置。任务调度模块在数据处理框架中处于居中指挥的作用，并对运行的数据处理任务进行监控及异常处理等操作。

4、数据治理框架

广义的数据治理不仅包含提升数据价值的内容，如数据管理、数据目录、数据质量等，也包含数据安全管理及数据共享服务。

数据安全管理与数据价值提升是一个矛盾体，如果由一个厂商或开发团队进行数据安全管理及数据价值提升相关软件的开发，则开发者的操作难免有所偏向，而且矛盾不容易公开，少了冲突也就少了优质的解决方案。

另外，数据共享与数据治理的其他内容也存在相同的问题。因此，本文建议数据中台的数据治理框架中不包含数据安全与共享的相关内容。

数据治理框架包含数据目录、数据管理、模型管理和数据质量 4 个模块：

• 数据地图、数据资产目录、知识图谱及数据血缘的主要作用是展示数据的属性及相互关系，因此都纳入数据目录模块。

• 数据模型能提高数据中台对外部应用需求的反应能力，固化的中间模型数据需要专门管理。模型管理包括模型目录、模型血缘及模型地图等。

• 数据管理又可以细分为元数据管理、主数据管理、标签数据管理及源数据管理。

• 数据质量管理模块按照制定的数据标准及数据稽核规则对数据中台中的数据进行质量管理。

5、数据安全框架

数据已经成为数据资产，数据安全框架是数据中台必不可少的组成部分。数据安全叠加在数据中台其他功能框架之上，数据采集、处理、交换、共享等每个环节均必须实施安全控制策略。安全框架可以分为日志管理、用户认证、权限管理及加解密等几个功能模块。

此外，安全全门户也可以对外提供安全能力封装，展示数据中台的安全态势及安全视图。

6、数据运营框架

数据中台的核心功能是综合众多数据应用的数据处理及数据治理功能，集中建设、集中管理、减少冗余、增加复用。数据中台的最终目的还是为其他应用或开发者提供数据服务，而对外数据服务功能将直接面向不确定的外部对象。

因此单独建设数据运营，一方面有利于针对外部用户提供针对性功能；另一方面，数据运营模块作为用户与数据中台核心数据服务之间的中间层，可以有效隔离外部用户直接控制、接触核心数据及应用，可保护数据中台的安全性及内部功能的稳定性。

综合以上因素，数据运营应配置运营门户、能力开放、数据开放及运营监控等功能：

• 运营门户：对数据中台管理者提供管理门户，对开发者提供开发者门户。对内部应用提供内部应用门户，对外部应用提供外部应用门户。运营门户针对不同的用户提供不同的通道并开放不同的数据中台能力。

• 能力开放：把数据中台的数据处理能力、数据分析能力等经过适当的封装后对用户提供服务，可以是微服务，也可以是 API 接口，或者直接提供二次开发能力。

• 数据开放：通过数据目录，数据/模型展示（可视化、数据视图等）为其他数据应用系统提供数据服务。

• 运营监控：对数据中台的总体运营情况进行监控管理，包括硬件环境、软件环境，并且确定监控指标，按需求提供运营日报，处理告警信息。

数据中台典型架构 

       数据中台的目标是让数据持续用起来，通过数据中台提供的工具、方法和运行机制，把数据变为一种服务能力，让数据更方便地被业务所使用。下图所示为数据中台总体架构图，数据中台是在底层存储计算平台与上层的数据应用之间的一整套体系。

 数据中台总体架构图

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

1. 数据汇聚

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

数据汇聚是数据中台必须提供的核心工具，把各种异构网络、异构数据源的数据能够方便地采集到数据中台进行集中存储，为后续的加工建模做准备。数据汇聚方式一般有数据库同步、埋点、网络爬虫、消息队列等；从汇聚的时效性来分，有离线批量汇聚和实时采集。

2. 数据开发

通过数据汇聚模块汇聚到中台的数据，没有经过什么处理，基本是按照数据的原始状态堆砌在一起的，这样业务还是很难使用。数据开发是一整套数据加工以及加工过程管控的工具，有经验的数据开发、算法建模人员利用数据加工模块提供的功能，可以快速把数据加工成对业务有价值的形式，提供给业务使用。

数据开发模块主要是面向开发、分析人员，提供离线、实时、算法开发工具以及任务的管理、代码发布、运维、监控、告警等一些列集成工具，方便使用，提升效率。

3. 数据资产体系

有了数据汇聚、数据开发模块，中台已经具备传统数仓平台的基本能力，可以做数据的汇聚以及各种数据开发，就可以建立企业的数据资产体系。之前说数据资产体系是中台的血肉，开发、管理、使用的都是数据。大数据时代，数据量大，增长快，业务对数据的依赖也会越来越高，必须考虑数据的一致性和可复用性，垂直烟囱式的数据和数据服务的建设方式注定不能长久存在。

不同的企业因业务不同导致数据不同，数据建设的内容也是不同的，但是建设方法可以相似，数据要统一建设，笔者建议数据按照贴源数据、统一数仓、标签数据、应用数据的标准统一建设。

4. 数据资产管理

通过数据资产体系建立起来的数据资产还是一套偏技术的数据体系，业务人员比较难理解。资产管理是以企业全员更好理解的方式，把企业的数据资产展现给企业全员（当然要考虑权限和安全管控），数据资产管理包括对数据资产目录、元数据、数据质量、数据血缘、数据生命周期等进行管理和展示，以一种更直观的方式展现企业的数据资产，提升企业的数据意识。

5. 数据服务体系

前面利用数据汇聚、数据开发建设企业数据资产，利用数据管理展现企业的数据资产，但是并没有发挥数据的价值。数据服务体系就是把数据变为一种服务能力，通过数据服务让数据参与到业务，激活整个数据中台，数据服务体系是数据中台存在的价值所在。

企业的数据服务是千变万化的，中台产品可以带有一些标准服务，但是很难满足企业的服务诉求，大部分服务还是需要通过中台的能力快速定制。数据中台的服务模块并没有自带很多服务，而是提供快速的服务生成能力以及服务的管控、鉴权、计量等功能。

6. 运营体系和安全体系

通过前面的数据汇聚、数据开发、数据资产、资产管理、数据服务，已经完成了整个数据中台的搭建和建设，也已经在业务中发挥一定的价值。

运营体系和安全体系是数据中台得以健康、持续运转的基础，如果没有它们，数据中台很可能像个一般项目一样，一期搭建起平台、建设部分数据、尝试一两个应用场景之后而止步，无法正常地持续运营，不能持续发挥数据应用价值。这也就完全达不到建设数据中台的目标。

 

企业数据中台架构图   

一、技术中台架构图 

中台概念出现之前，在信息化模式上，前端为支撑业务的应用端，后端为各个应用系统，为前端用户，如：客户、供应商、伙伴、社会，提供服务，但随着市场、用户需求、业务的多变性，底层僵硬的应用无法及时提供支撑。

企业需要一个强大的中间层为高频多变的业务提供支撑，为不同的受众用户提供多端访问渠道，基于此类需求“中台”概念出现，接着开始对企业客户、中间件厂商、数据平台厂商、甚至传统应用软件厂商都有较大的概念冲击。

此时，微服务技术和架构、容器化的生态、Devops概念和工具处于大发展的阶段，最后基于“大中台、小前台”的信息化建设模式开始流行。

二、银行数据架构体系

数据架构层面通过数据分类、分层部署等手段，从非功能性视角将数据合理布局。通过整体架构管控和设计，支持业务操作类和管理分析类应用（系统），满足业务发展及IT转型对数据的需求，架构的扩展性和适应性能够提升数据分析应用的及时性、灵活性和准确性。

那实际情况下各个银行的数据架构体系会有所不同，根据各行的业务发展、客户数据量、交易数据量、功能需求等会有不同的演变路径以及发展方向。

一般国有银行、股份制银行等全国性的银行业务较复杂，数据量也较多，数据架构也因此进化较快。常见的数据架构分区如下图所示：

三、零售行业中台架构

这是一张混合了技术和业务的中台逻辑架构示意图，前台应用部分我们将零售和消费品行业需要对接消费者的若干应用系统一一列举了出来，但是在中台架构下它们已经和传统的“应用系统”有了很大的差别，变得非常“轻量”。

 

 四、业务中台架构

前台跟着界面走，天生就稳定不了，总是有五花八门的数据请求，这是必然的事情。

后台应该主要负责数据存储，把不同形式和规模的数据以合适的方式整理好，大数据倒腾起来动静太大，要求有一定的稳定性。

如果前台的请求都要求后台直接做，那后台管的事就太多了。

五、后台架构

后台是被许多前台共享的，如果直接向前台提供灵活数据服务，还可能导致各个前台之间的耦合程度变高，维护成本立即陡增。

同样的，把这些数据处理放在前台也不合适，一方面不太安全，另一方面，前台团队也是忙着让界面如何更好看使用更流畅，没太多工夫琢磨数据的事情。这样一个后台架构就能够相对平衡这一矛盾。

六、实时数据中台

下面是实现实时数据中台的一种逻辑架构，方便理解，其实最关键的是实时模型那一层  

 七、企业级中台发展过程

我用下面这张图来概括中台发展的三个阶段，最终我们发现，对于那些已经有 ERP 系统的企业来讲，中台的建设本质就是利用微服务架构构建开放业务平台来替换闭源单体架构的 ERP 系统的过程。

八、阿里中台架构

中台是一种架构理念和方法。任何一种架构的方法，其本质不外乎，利用分、合、打散、重组等技术手段，对系统进行有序化重构，以达到减少系统“熵”的过程，使系统得以不断进化。

 

九、阿里核心架构图

通过阿里云平台将技术中台进行部署，对集团内共享业务单元提供支撑，并最终对前台各业务线提供服务化能力输出。

十、全渠道零售中台 

如果仅仅是把所有的东西打包在一个“大后台”并不能真正解决IT的痛点，因为毕竟它是一个IT系统。IT系统要考虑的东西除了业务功能，更重要和更有价值的地方在于：

十一、全渠道集成架构

2007~2012年是“集成模式”概念被抛出率最高的年代，它有一个名字叫“SOA”，SOA就是那个时代的“全渠道中台”

 

 

十二、网易严选数据中台体系

数据中台的核心职责是高效地赋能数据前台为业务提供价值。要想理解数据中台先要理解数据前台，上文说到的搜索、推荐、BI 报表、数据大屏等都属于数据前台。

 

行业数据中台解决方案

▲地产行业解决方案 

 ▲证券行业解决方案

▲零售行业解决方案 

▲制造行业解决方案

▲传媒行业解决方案 

▲检务行业解决方案 

总结 

建设数据中台，实现企业或机构数据资产的高效管理和数据价值最大化，为机构带来了数据平台化的运营机制，有望解决应用开发与数据开发速度不匹配的问题。利用数据中台，可以将机构的核心技术或团队凝聚在一起，建设机构内强大的数据开发、运营等团队，提升机构的团队的硬实力和软实力。

虽然一个良好的架构对一个信息系统的后期扩容及运维有重要作用，但总体架构设计只是数据中台建设的第一步，每一个功能模块还有很大的细化空间，如不同类型数据的存储技术选型、数据安全合规审计技术、数据模型设计等。在具体项目中，数据共享与安全保护的平衡点、新技术的引用等，都需要进一步细化研究。

爱奇艺数据中台建设方案

• 数据中台的产生：数据工作的痛点、数据中台的产生、中台的实质

• 爱奇艺数据中台的定义：理解数据中台、数据中台的发展历程、输出和定位

• 爱奇艺数据中台的建设：中台建设、Pingback体系、数仓体系、数仓平台、离线数仓架构、大数据平台、数据平台架构

• 数据中台的应用场景：统一化、个性化、定制化

一、数据中台的产生

1、数据工作的痛点

1. 使用门槛高：数据工作是一个专业性特别强的一个工作，对于人员的要求比较高。

2. 口径不一致：在使用数据过程当中，口径不一致是特别常见的一种问题，这种问题可能会导致一种数据使用和分析的差异，而且会降低业务的数据分析效率。

3. 数据可靠性低：在生产过程中，降低业务的数据分析效率，最终会对业务决策造成严重的影响，不仅数据链路过程很长，其中还会引入很多数据质量问题。

4. 跨业务难度大：因为缺少一个统一的数据建设的规划、标准和规范，所以难以指导各个业务或者整个生产链路的各个环节，以拥有一个标准化的生产和处理过程，就导致了多个业务的数据难以融合，难以发挥更大的数据价值。

5. 接入成本高：如果有新的业务接入或者新的场景需要使用数据，很多工作都需要人工处理。去申请各种资源、权限、找数据并且串联整个数据的采集、生产、计算、同步和展示等各个环节，这是一个耗时长、效率低，最终还是很容易出错的过程。

6. 投递质量低：说到数据的话肯定离不开投递，投递是用来记录用户行为的一连串的数据信息。如果投递过程缺少标准化或者流程管控的话，都会导致投递质量比较差。

7. 获取数据难：数据的生产到最终使用，中间可能要经历一个比较长的时间周期或者一个比较宽的团队跨度，用户可能无法很快地找到想要的数据，或者数据团队生产出来的数据并没有真正触达到业务，来达到它的数据价值。

8. 数据资产模糊：这个点可能和获取数据难有一点点关联，数据资产模糊的话更多的是在说需要对公司的数据资产做一个整体的管理，如果没有这个整体的管理，就会导致对数据资产的级别和拥有什么数据资产都很模糊。最终就是导致数据的优势难以发挥出来，而且虽然耗费了很多计算资源、人力资源、存储资源，但没有带来相应的价值，最终导致资源效率极低。

2、数据中台的实质

数据中台更像一种企业架构，是一套结合互联网技术和行业特性，在企业发展的不确定性中，寻找确定性，并且持续沉淀和抽象企业核心能力，最终支持企业快速、高效、低成本进行业务创新和增强的企业架构。

二、爱奇艺数据中台的定义

1、理解数据中台

数据后台：

大家平时更多用到了大数据集群，也就是说Hadoop、Spark、Flink以及其他OLAP工具。但是这些只是数据后台的一个概念，并没有做成一个标准化、通用化、门槛相对来说比较低的中台化的概念。 

数据中台：

数据中台其实是一个数据即服务的产品概念，它包括了数据服务、数据平台、数据中台产生的数据以及在所有的数据工作中产生的标准和规范，这一些组成了我们所谓的数据中台。

数据前台：

数据前台就是我们实际的产品落地的具体例子，主要包括了几个大的方向：

• 分析体系，比如说用户分析、内容分析、业务报表等；

• 数据应用，比如说即席查询、可视化查询工具；

• 数据产品，类似于画像和推荐业务，可能都是一些数据最终形成的产品，直接面向用户服务。

所以数据中台抽象出来，就是指“平台+服务+数据+标准化”的概念，它是将数据的生产、收集、处理、存储和服务进行封装，并且面向不同层级的用户提供不同的服务形式。在数据标准化过程中，数据中台可以防止数据重复建设，避免口径问题，提高数据的使用效率。

2、数据中台的发展历程

3、数据中台的输出

数据中台输出形式分为以下几个：

4、数据中台的定位

说到数据中台定位，因为数据中台和前台、后台都需要有一个明确的划分，数据中台定位提供了这种抽象通用的能力来支持前台团队在此基础之上进行定制化，最终在复用通用能力的同时，能够满足业务快速发展的个性化的需求，达到一个全局最优化的状态。

三、爱奇艺数据中台建设

1、建设

主要从五个角度去输出中台能力，分别是服务、数据、平台、投递、标准/规范。在爱奇艺数据中台的实施过程中，划分出了三个大方向：

• 生产，也就是我们所说的投递体系；

• 数据，也就是统一数仓的体系，是数据的核心；

• 大数据平台能力：包括开发、治理、服务。

日志投递：

这部分输出了投递规范，进一步针对投递规范，需要对公司的相关员工进行培训，让大家深刻地理解投递是为了做什么，并且怎样才能达到我们对于用户的行为足够深入的分析要求。

大数据平台：

有一线开发、对应的运维管理、实时开发对应的运维管理，以及数据治理、数据图谱、数据服务和即席查询。即席查询是我们数据服务里的一个子项，但是因为应用面比较广，就单独拎出来了。

统一数仓：

统一数仓的能力也就是为下游提供离线和实时的两种数仓能力。为了方便大家实现跨离线和实时混合使用的场景，需要进行标准化的工作，也就是离线输出的字段、定义、口径、格式和实时数据要尽可能一致，即实时数据向离线数据看齐。

数仓在提供数据本身的能力之外，还要维护整个公司级别的指标体系和统一维度，让所有的数据系统平台和都会对接到统一的维度指标体系。而且，为了帮助数仓建设过程中的数据建模和统计指标的管理，建设了一个对应的数据平台，也是按照数据规范的标准建设，以此来支持使用方使用平台依照规范去建设数仓的流程化工作。

2、Pingback体系

Pingback的体系就是投递体系，那么具体为什么要做这个事情呢？

投递工作面临的问题主要有以下几个点：

3、数仓体系

数仓体系几个要解决的痛点：

4、数仓平台

数仓平台主要是为了做业务建模、数据建模、物理建模、维度管理、指标管理和数仓管理。

数仓平台的特性：

• 数据表创建的约束性：比如我们需要对表有的命名规范要求，如果没有一个工具去管理，可能会因为大家对规范的理解不一致，最终导致落地过程中依然存在各种各样的差异性；

• 数据信息的可描述性：指在创建表的过程中，为了快速地满足业务，很少去添加一些相关的描述信息，导致数据缺少描述性。所以需要通过平台，要求用户在数据创建的过程中把信息描述的足够精细，方便后续的数据使用过程；

• 数据建模体系的完整性：指我们需要一个三步的建模过程，即业务建模后，有对应的数据建模；数据建模之后，针对这个数据建模，有不同的物理建模的形式。整体是一个流程化的工作，避免用户为了快速地满足业务需求跳过某些过程，最终导致建模的扩展性较差；

• 数据关系的维度与指标管理的系统性：通过提供一套统一的维度和指标管理体系来作为一个中心，对外输出统一的指标和维度，让大家在使用的过程中，可以使用这些标准化后的并且集中管理的元数据；

• 数据关系的可追溯性：是指通过数仓建设、建模的过程，促使我们后续数据表和字段的相互关系是有记录可查询的，也就是我们所说的数据血缘关系。

5、离线数仓架构

下面是数仓的简化架构，主要是体现了离线数仓部分。其中带颜色的一部分是统一数仓，其他的浅颜色的就是一些数据应用，包括数据集市和主题数仓。

 

6、大数据平台

爱奇艺大数据平台经历了五个阶段：

开发：在第一阶段完成了整个数据开发的平台化、可视化能力，降低了开发门槛，并提升开发标准化。

运维：在开发之后，需要提升任务的管理和运维能力。通过建设运维管理模块的建设，保证用户更方便地对任务进行管理，并且对任务产出的稳定性和数据产出的时效性实现了有效的监控。

质量：在提供了数据开发和管理相关能力之后，需要进一步对数据产出进行质量校验，避免生产出的数据在未关注数据质量的情况下直接被使用，造成数据问题的快速扩散。

使用：数据使用也是一个数据发现的过程。比如生产了很多数据，如何让用户看到这些数据，并将其更好地应用在业务需求当中。针对这个痛点，完成数据图谱模块的发布，把各种的数据元信息进行收集、加工、管理，最终把完整的数据信息以一种更友好的形式提供出来，帮助大家快速地发现数据，进一步去了解数据元信息、快速准确地使用数据。

治理：是数据生态的最后一个环节，也是打造健康生态闭环的重要部分。有的公司可能是把治理放到比较靠前的环节，但是在一些场景下，比如说业务快速发展的过程中，治理往往是跟不上业务需求的。所以爱奇艺采取的方式是，等业务发展到一定程度，再去补充数据治理的能力，对存量去治理，对增量去管控。治理工作的内容主要包括对数据和任务进行日常审计，然后通过数据血缘和使用情况，对数据的冗余度进行有效评估，并进行相应的优化，以减少资源和人力的浪费。

7、数据平台架构

 

• 最底层是数据层，比如投递服务器的日志，包括业务的数据或者其他数据来源，通过采集层和传输层达到我们的计算层。

• 计算层，更多的是大数据集群服务，也包括一些任务调度能力。

• 平台层包括离线和流式任务的开发管理、机器学习平台、数仓平台，然后下面是对于整个的数据的ETL的一个平台化的处理，还有外部数据的一个同步能力的模块，称为数据集成。在拥有这些开发能力或管理能力的同时，还需要对投递管理、数据安全、数据质量、数据图谱做一些有效的建设，并且在整个数据体系中去做数据治理工作。

• 服务层是以即席查询、实时分析，数据服务、元数据服务多种形式对下游提供服务能力。

四、应用场景

数据中台的应用场景，面向不同阶段来提供不同的接入方式：

• 第一个阶段是统一化的形式。有一套通用的模板，它的优点和缺点都很明显，优点是接入起来很简单，缺点就是不够个性化和定制化，只能支持这种通用的数据能力。所以它比较适合于业务初期，能够进行快速接入，并且自动化地完成这种数据的处理和服务；

• 第二个阶段是个性化的能力。把整个流程确定下来，业务在使用过程中可以针对某些环节做定制化的开发，拓展现存数据模块的能力来满足一些个性化需求，所以它更适用于业务的成长期的阶段；

• 第三个阶段是定制化的能力。定制化更多面向一些特别成熟的业务，也就是对于数据这一块的需求有多方面的、深层次的使用场景，并且通用的和个性化的架构已经不足以满足数据需求的情况下，可以采用定制化的能力。定制化能力也就是我们提供数据模块化的能力，然后业务再根据自己的需求去对应选取这些模块化能力，并进行组装和扩展，来满足自己定制化的需求。

作者：马金韬

原文：dbaplus

end

Flink 从入门到精通 系列文章
基于 Apache Flink 的实时监控告警系统关于数据中台的深度思考与总结（干干货）日志收集Agent，阴暗潮湿的地底世界

公众号(zhisheng)里回复 面经、ClickHouse、ES、Flink、 Spring、Java、Kafka、监控 等关键字可以查看更多关键字对应的文章。

点个赞+在看，少个 bug ????