10张架构图详解数据中台，附全套数据中台ppt
数据中台到底是什么，几年过去了，一直众说纷。
笔者认为数据中台不应该是一个单纯的系统或者是一个软件工具，而应该是一套架构、一套数据流转模式。
数据中台需要采集数据作为原材料进行数据加工、数据建模、然后分门别类地储存，再根据实际的业 务场景，打造各类数据服务（含数据应用平台）从而实现对业务的赋能加速。
但以上流程的实现，需要有对应的系统与产品作为支撑，那么基础的数据中台到底应该由哪些系统或者产品组成？
这里我们可以先来看一下几个企业的数据中台架构，文末也分享了10份数据中台实践案例合集，从多家公司的完整实践经验看下来，应该能一窥究竟。
数据中台总体架构图
数据中台是在底层存储计算平台与上层的数据应用之间的一整套体系。数据中台屏蔽掉底层存储平台的计算技术复杂性，降低对技术人才的需求，让数据的使用成本更低。通过数据中台的数据汇聚、数据开发模块建立企业数据资产。
通过资产管理与治理、数据服务把数据资产变为数据服务能力，服务于企业业务。数据安全体系、数据运营体系保障数据中台可以长期健康、持续运转。
阿里巴巴数据中台
全域数据采集与引入：以需求为驱动，以数据多样性的全域思想为指导，采集与引入全业务、多终端、多形态的数据。
标准规范数据架构与研发：统一基础层、公共中间层、百花齐放应用层的数据分层架构模式，通过数据指标结构化规范化的方式实现指标口径统一。
连接与深度萃取数据价值：形成以业务核心对象为中心的连接和标签体系，深度萃取数据价值。
统一数据资产管理：构建元数据中心，通过资产分析、应用、优化、运营四方面对看清数据资产、降低数据管理成本、追踪数据价值。
统一主题式服务：通过构建服务元数据中心和数据服务查询引擎，面向业务统一数据出口与数据查询逻辑，屏蔽多数据源与多物理表。
网易严选中台架构图
数据中台的下层是数据平台，数据平台主要解决跟业务无关的问题，主要是大数据的存储和计算问题。
数据中台的上层就是数据前台，主要包括 BI 报表、数据产品和业务系统。数据中台首先赋能分析师通过 BI 报表的形式来驱动业务精细化运营。如下图所示，基于数仓里已经半加工好的数据，再通过BI 平台快速的根据业务需求进行数据可视化和数据分析
网易云音乐数据中台架构
最底层是基础设施层，这包括资源环境和平台工具两部分
第二层是数据层，数据层即网易云音乐的 OneData，包括元数据中心、标准化数仓、数据地图、统一指标体系、数据安全中心和保障这套体系的数据质量管理中心。
第三层是服务层，服务层即网易云音乐的 OneService。它提供不同层级和粒度的数据 API，包括从最底层的任务执行调度能力，到最面向应用的人群圈定的各类服务能力。
最上层是产品层，针对一个个核心业务问题（增长、营收、版权）搭建了对应数据产品，实现从业务流程、信息采集、数据洞察到 ROI 评估再到业务流程的完整闭环
转转数据中台
数据模型、数据服务与数据开发，通过数据建模实现跨域数据整合和知识沉淀，通过数据服务实现对于数据的封装和开放，快速、灵活满足上层应用的要求，通过数据开发工具满足个性化数据和应用的需要
某企业数据中台架构图
下面这个数据中台，根据数据资产梳理结果，并以大数据平台的“数据采集+海量存储+计算引擎”为基础搭建公司数据湖，再基于数据湖并结合“数据资产管理服务”和“智能数据研发服务”两大支撑服务群实现中台数据的资产化管理和智能化开发，达到快速应对各类数据需求的目标，也实现一整套基于宽表结构、分主题的基础数据，然后实现对外提供数据服务的统一接口，并最终形成汇聚公司数据及其服务的中台，为实现数据赋能的数据应用和产品提供全方位的基础数据以及各类服务支持。
农行数据中台架构
农行“薄前台、厚中台、强后台”IT 架构体系中对前中后三个层次描述得更为明确，将大数据平台和 PAAS、IAAS 基础设施划入了后台。
根据以上企业的数据中台实践，我们不难看出，所有的数据中台建设，都是围绕着企业数据的采集接入、加工存储、统一管理与数据服务4项能力来开展的。
但无论如何，我非常建议大家多看看不同企业的中台架构图和建设方案，内化自己对中台的理解，而不是盲目跟风、照搬其他公司的中台架构和建设蓝图，比如你真要照着阿里的方式做，基本就把自己的资源耗光了，也很难换来价值产出，也不要仓促地去购买商用的数据中台套件，没有什么较佳路径是可依赖的，每个企业所处的数据和业务阶段都不同，始终要根据你这个企业所处的阶段、一线对于数据的真实需求做出合理的判断和选择。
最后，分享一些我手中珍藏的中台相关的建设方案和报告，推荐大家去看看。
获取方式：
相关内容
数仓系列第10篇：数据治理
目录
01数据治理、数据管理与数据管控
在日常工作中，数据“治理”、“管理”和“管控”常常被“混搭”。这种混搭，在不同的文件、报告、沟通层面，可能造成对数据工作的歧义，具体到谁来做、做什么、怎么做，特别需要概念层面澄清。
1.数据治理
是什么：事实上，治理面对的更多是战略层面、组织层面、制度层面的事务，是“make sure it’s be doing”，确立“什么样的决策需要在什么层级制定”。所以，数据治理是一个相对高阶的概念。
谁来做：对应的是一个“数据治理委员会”级别的机构，由这个委员会来建立数据治理的整体组织架构，定义责任主体，落实工作机制。
2.数据管理
是什么：“管理”是对“治理”的贯彻，是通过一系列实际落地的办法去实现“治理”目标的具体过程，是操作和实施层面的概念。
谁来做：数据管理对应的是一个以“数据管理部”级别的职能部门+各个相关职能部门的矩阵化组织。通过内建组织机构和工作机制，有牵头、有配合、有主责、有落实，在各自的职能领域去完成数据管理的具体任务，包括企业级层面的数据标准化、数据资产管理，业务领域层面的数据规范化、数据质量改进等等。
3.数据管控
是什么： “管控”是对“管理”要求在业务过程、产品设计、开发实现层面的具体实施。管控离不开“制度”+“规范”+“工具”+“考核反馈”，每一个管控机制，都应该有一个PDCA的管理循环。
谁来做：数据管控的落地，制度设计和规范定义层面，需要数据管理部门牵头推进，同时，也需要技术部门的工具和系统能力支撑，才能“管得了，管得住，管到位”。
如上图，清洁源头数据就是一个数据治理目标，数据标准管理办法、数据质量管理办法就是帮助实现治理目标所制定的管理制度，在开发过程中的标准管控、在运行阶段的质量管控就是在实际工作当中实现标准、质量管理的具体措施和手段。
02系统架构、应用架构和数据架构
随着企业信息化程度的不断提升，以及有关方面对企业数字化转型的不断深入，“架构”成为热词。这个时候，无论是业务部门还是技术部门，往往会提到好几个架构术语，包括系统架构、应用架构。同时，随着数据治理工作推进，数据架构也映入眼帘，但是他们之间的关系仍然需要不断澄清。
1.系统架构
系统架构是一个相对技术化的专有定义，特指信息系统的物理设施+软件模块+功能组件的关系定义，狭义或低阶的系统架构范围可以是一个或一套业务或技术功能的系统，即所谓的功能级或部门级系统架构；广义或高阶的系统架构可以涵盖到企业级、全领域，形成企业级系统架构。相对而言，系统架构偏IT系统的实施层面，内容多包括软件、硬件、网络、协议等方面。
2.应用架构
应用架构的定义会更加突出“应用导向”，虽然系统架构也会陈述一些IT作业和功能的相互调用关系，但是这些内容是IT实施层面对业务需求层面的具体化，因此反而不容易被业务人员在自己的语言体系内掌握，这时候，需要一种业务化的架构解释，这个就是应用架构。今年以来，随着付晓岩等业界大咖的不断宣（who）传（you）,业务架构一词也浮出水面，业务架构转型，企业级业务（应用）架构规划设计，分领域组件和分层体系的规划建设也不断在理论层面被丰富，在实践层面被完善。
3.数据架构
数据架构是一个古老而又年轻的概念。说古老，在于从IT系统诞生开始，就伴随着软件编码+数据结构，数据是软件的基本功，表结构设计是很多软件设计的第一步。说年轻，在于数字化转型以来，数据的体量规模、质量要求已经从TB发展到PB再到EB，一些领域已经到了ZB，量变带来质变，简单的表结构管理已经无法满足需要，数据架构管理应运而生。
目前，数据架构管理的理论体系初步构建，在DAMA、信通院、金融科技标准化委员会的不断推动下，数据架构的标准化表述已经趋于统一，基本覆盖如下四个方面：数据标准管理、数据模型管理、数据资产管理、数据分布管理。
03数据标准、数据模型、数据资产、数据分布
1.数据标准管理
就是将系统级、项目级的数据规范提升到企业级层次和全领域范围，着力解决基本的业务定义和基础的数据整合，统一企业级范围内的数据指标、数据标签、图数据关系的基本定义和口径管理。
2.数据模型管理
目前一般是业务交易过程的模型管理和数据运营应用过程的模型管理，传统的解释是OLTP类数据模型+OLAP类数据模型，国外的典型的代表是IBM-FSDM（金融数据模型）+TERADATA-FSLDM（金融数据逻辑模型），国内的典型代表有建设银行的C模型+阿里的数据中台逻辑模型。
前一种模型的共同特点在于，和业务过程、产品设计相对应的，主要是应用于前台交易、业务运营类的系统的数据结构设计；后一种模型的特点则在于从数据整合、用户画像、指标体系、图计算和AI计算等方面出发，从数据的海量采集、存储、计算、流转，从数据资源的生命周期管理方面出发而进行的数据结构设计。
数据模型管理，往最“实”了说，离不开“表结构”；但是，什么地方用三范式或者退化三范式，什么地方用维度表，什么地方用雪花表，什么地方用图关系表，这个是数据模型的要点。
3.数据资产
和数据资产对应的概念是数据资源。所有存量IT系统中的数据，都是资源，正如石油埋在地下，是资源。但是资源要发挥价值，需要开采、需要提炼、需要产品化，才能成为可用资产。没有经过产品化的资源，还不能成为资产；而如果产品化成本过高，无法有效利用的资源，则可能成为垃圾。
就数据而言，编目清晰、接口规范、口径准确、责任明确的数据，可以列入数据资产。企业的数据资产可以包括数据标签、数据指标、图数据关系、固定报表、数据服务API以及规范化后的元数据等。这些资产，有利于后续的数据加工和应用，而只有通过有效的数据加工应用，数据资源才能产品化为数据资产。
4.数据分布
在系统架构管理中，强调的是“高内聚+低耦合”，软件功能上的集约化；在应用架构管理中，强调的是“功能聚集性+职能责任制”，尽量统一、集约、纯粹。在数据架构中，同样对于数据的存储分布、流转路径有自身的架构原则，尤其是在于数据中台层面，归纳而言就是数据分布上“只存一份、只算一次”。
只存一份，是针对过去数据分析应用环境的系统竖井，各自为政的多重数据COPY，各自取数的加工路径，要求在企业级数据架构规划中，大规模海量数据要去除冗余，加强存储管理，并尽量推动“存+算”分离的技术架构来保障架构规划的落地。只算一次，就是数据加工过程和口径管理，数出同源。
04数据仓库、数据湖与数据中台
1.数据仓库
数据仓库是一个存在已久并且已经面临更替的概念。传统上，因为数据分析、报表加工的需要，将源业务系统的数据采集汇集到数据仓库，通过数据清洗、加工、整合，然后形成方便后续使用的数据应用。
数据仓库架构还没有完全过时，但是已经面临巨大的冲击和挑战。首当其冲就是成本，传统数据仓库的领头羊是TERADATA等厂商，数据存储容量PB级，很难继续在物理上扩展，成本费效比下降很快；其次就是应用领域，数据仓库不能满足非结构化数据的存储和应用需要，埋点数据分析所依托的海量数据无法存储在传统的数据仓库中；第三就是时效性，传统数据仓库层层加工的数据层次，掌握技能的人员太少，处理转换路径太长，时效性也不能满足要求。
2.数据湖
数据湖和数据仓库的区别，一种理解是数据仓库是结构化数据存储，数据湖是按原样存储数据，无需事先对数据进行结构化处理。相比于数据进入数据仓库需要进行入仓前的模型化处理，数据湖增加数据会更快捷、方便。
而更为重要的区别在于，数据仓库是“弱数据治理”时代的产物，大部分企业没有建立企业级的数据治理架构和组织，数据仓库疲于在技术层面去做数据的整合。数据湖的背景则是“强数据治理”，“问渠那得清如许，为有源头活水来”，如果“入湖”的数据不清洁，那么数据湖就是“数据沼泽”；但是如何做到入湖的数据是清水，就需要对企业级源系统的数据治理，加强底层清理、提高入湖标准。如果做不到这一点，那么数据湖采集的数据越多，数据垃圾越多。
3.数据中台
数据中台是以数据应用为导向，以数据治理为保障，以数据湖底座为支撑，以数据服务和数据分析为具体价值输出的一个整体性的数据体系。
数据中台的建设，应该有整体规划。尤其是，数据中台是企业数据能力积累和建设的综合表现，需要企业大数据基础设施、大数据技术栈能力建设和大数据团队建设的不断优化。
数据中台的实施，在项目层面，可以采取“以用带建”的方式，在基础能力整体规划建设的基础上，通过业务应用项目的推进来倒推数据中台具体数据输出内容。
05数据中台是什么，不是什么，为什么
1.简单微服务和传统数据仓库不是数据中台
简单微服务只是解决API的调用封装，扒开微服务看，竖井还是竖井，时间越长管理难度越高，经年累月后就成为一堆乱麻，谁也不敢动。传统数据仓库更多是T+N级别的数据批量整合，缺实时性、缺大数据，对当前营销、风控、智能领域的数据需求无法响应。以上两者，包括两者的组合，都不是数据中台。
2.数据中台的基本背景就是企业级数据治理
数据中台的建设，先导是数据治理。只有数据在企业级范畴内完成基础梳理、标准体系建设，最大限度地形成源系统数据清洁和质量保障机制，形成数据溯源和血缘管理，数据中台建设才具备一个长期推进和迭代演进的基础。
在所有的数据中台规划中，数据资产管理平台或者数据治理平台是核心组件，承担对企业级的数据治理工作的平台落实和流程贯彻，数据资产盘点清理和目录化服务的基本功能，是企业级数据标准体系的具体呈现。
3.数据中台的技术底座是大数据平台和数据湖
数据中台的技术底座不再是类似TERADATA等一家单一厂商的单一产品，而是大数据技术栈组成的大数据平台，包括MPP、HIVE、HBASE、ES、CUBE、FLINK、图和AI等多种技术组件，共同构成的数据平台支撑体系。数据中台的性能，包括存储、计算、流转、大规模数据服务响应、实时性数据服务响应等参数指标，取决于技术平台的打造和能力建设。
数据中台的数据底座是数据湖，是大数据基础支撑下，海量数据的采集和存储，包括结构化、非结构化数据，包括企业内部数据和外部数据，包括批量采集数据和实时采集数据。数据湖的“闸口”是数据质量保障机制，一方面是在源系统的质量规则检验机制，一方面是在“入湖”口的数据质量监控和报告机制。数据湖的“清洁度监控”，还有赖于数据加工流转的血缘管理，这需要元数据管理工具的支持。
4.数据中台的四大特征是统一治理、统一计算、统一服务、统一分析
数据中台是数据能力的集中和集约，在数据治理的背景下，在大数据技术的支撑下，面向海量、智能、实时的数据应用需求，数据中台的四大基本能力建设就是治理能力、计算能力、服务能力和分析应用能力。
统一治理就是要将散落在企业各处的内、外部数据进行梳理及整合，使其成为企业级可用资源，为统一计算提供干净的底层数据。
统一计算就是要做到对主要数据应用，客户画像、经营管理指标、图和人工智能应用的统一数据构建，具体而言就是在进行基础数据高度整合，在ONE DATA基础上对数据标签、数据指标、图关系变量等的统一计算，解决“数出多源”问题，去除“同义不同名、同名不同义”问题。
统一服务就是要将数据计算的结果，面向高性能、大规模的业务应用，面向开放银行、规则引擎、营销和欺诈模型等机器级调用的需要，将数据进行产品化、服务化封装，以数据API等方式提供系统级调用服务，方便业务中台、前台系统的数据取用。
统一分析就是要将数据计算的结果，包括整合数据的明细内容，以分租户、分环境的方式，通过数据资产目录的开放共享，提供数据环境+分析工具+数据资产的配套机制，方便数据分析团队+数据科学家进行数据分析应用，挖掘数据价值，为各种业务规则、模型的构建进行数据赋能。
06结语
通过本次概念层面的梳理，我们将数据工作的体系框架、架构规范、平台管理等方面进行了一些总结。目前，数据中台建设的落地工作也在推进，4P平台的建设工作正在有序实施，也希望上面的概念梳理能够给大家对相关工作的理解提供一些帮助。欢迎关注公众号，一起进步！