数据中台这个东西，现在业界并没有一个完整的标准定义，数据中台至少首先是一个分布式的数据仓库，同时包含相对应实施的方法论和方案，介于分布式数据仓库和企业全面数据化中间的任意一个点都可以被定义为数据中台。

可以说，数据中台是实现企业全面数据化的一个解决方案，是一套支撑企业全面数据化的架构，会成为企业开展全面数据化的基础设施。

（1）中台是什么？

企业级能力复用平台！

（2）如何构建中台？

以用户为中心，从战略入手，愿景为指引，用科学有效的方法，步步为营沉淀企业级能力，辅以必要的组织与系统架构调整，方得中台。

（3）中台的价值是啥？

中台为前台而生，专注于为前台赋能，沉淀企业的能力与复用，提升企业的客户响应力。

（4）如何成为数据中台的参与者？

数据中台围绕数据技术开展。除了编程技术、应用开发技术与传统的IT应用技术具有部分的重合，数据中台还有自己的技术体系，比如大数据开发技术、数据仓库建模技术、数据分析体系、数据应用技术体系等。

数据中台建设五步法：

系统都是为应用而生的，数据中台也不例外。要构建一套数据中台服务于企业内部和外部运营，需要有成熟的数据中台建设方法论作为指导。企业建设数据中台遵循的方法论就像菜谱，初学者根据菜谱按部就班就可以轻松完成一道道菜肴，高阶玩家根据菜谱可以查漏补缺，使厨艺精进。数据中台建设方法论可分为高阶规划、系统设计、开发实施、试运行和持续运营 5 个阶段。

1、高阶规划

数据中台规划阶段可细分为业务架构师主导的业务规划和数据架构师主导的数据规划。这两部分内容是相辅相成的，由业务规划进行业务输入，由技术规划对数据现状进行探查，判断业务规划蓝图的可行性，最终形成可行的蓝图规划与应用设计。

1. 业务规划（业务调研、蓝图设计和应用设计）

业务规划分为三个步骤：业务调研、蓝图设计和应用设计。首先通过业务调研对企业进行了解。

（1）业务调研

业务调研主要包括以下两方面。

第一，战略与组织解读。企业战略决定了数据中台的上限，也决定了企业对数据中台的期望与目标。企业战略不仅能折射出企业的数据诉求本质，也能体现出数据中台对企业的价值。因此，通过明确企业战略对企业运营提升的要求，可以抓住企业运营提升的关键环节，对公司管理现状进行诊断，分析数字化能力给企业带来的效率和效益提升，明确企业数字化优化的目标与范围。同时，明确企业的组织架构，熟悉企业的业务模式，了解企业的业务板块，梳理业务部门的业务流程。

第二，调研访谈。调研访谈是通过问卷或针对性访谈的形式，对业务专家进行调研的过程。在调研的过程中可以收集报表、汇报材料、报告、可视化看板、系统建设材料等信息辅助理解业务。调研访谈的目的是通过对业务专家的调研，了解企业与业务，了解业务诉求与痛点，为后续的蓝图设计和应用设计提供业务知识基础和输入。调研前需要对业务背景、行业知识、调研问卷分布做准备，以便达到期望的调研效果。可以将调研问卷提前分发给业务专家，以便业务专家更有针对性地准备问题答复，提高调研效率。调研后需要结合业务场景，对数据进行推导，得出指标需求。推导的过程是现状诉求→需求推导→解决手段→场景推导→指标推导，详见下表。

（2）蓝图设计

通过业务调研了解企业，结合数据现状与业务痛点，将企业不同实体的数据进行提炼、抽象，形成数据域，将数据资产按照一定的体系进行规整，再结合业务诉求对数据分析场景进行提炼，最终形成一张囊括企业数据现状与未来的蓝图，为后续数据中台的建设提供宏观与发展路线的指导。

蓝图设计可从以下几个方面进行分析设计：数智化转型的一些考虑和战略、设计方法论、对客户业务的整体解析、数据中台价值化、分析链路梳理、数据域梳理和划分等。数据中台蓝图一般包括三部分：数据源、数据基础能力及数据洞察与智能应用规划。通过数据中台蓝图可以快速了解企业数据中台的范围与价值。

（3）应用设计

衔接蓝图设计，结合数据调研的成果判断数据可行性后，将数据分析场景、智能应用进行系统落地的可视化设计，形成 PRD 文档和原型进行产品设计与说明，最终促成应用的实现。

2. 技术调研

技术调研是对企业的 IT 整体现状进行摸查，调研内容包含企业主要业务及核心业务系统、整体网络拓扑现状、信息安全相关要求等。

对企业主要业务和核心业务系统的调研包括业务和技术两个方向。业务上梳理企业的主要业务及核心业务流程，技术上则梳理各业务系统及它们之间的数据流转关系。两者相互印证，输出企业的信息系统现状大图，并基于此确定后续的业务系统调研范围。

整体网络拓扑现状的梳理，有助于厘清企业业务数据的存储分布位置、数据传输的带宽限制等信息，为后续数据集成方案设计提供基础信息输入。

通过信息安全相关的调研了解企业内与信息安全相关的组织部门、规章制度等信息和要求，为后续制定数据处理和使用的流程规范提供依据。

3. 系统和数据调研

系统与数据调研的目的是厘清企业数据资源的种类、分布、存储及管理现状。系统与数据调研是按业务系统进行盘点的。系统盘点的范围来源于技术调研的输出。盘点项包括业务流程、业务动作、数据源、数据表、数据字典。该调研工作一般由技术主导。

业务流程及动作的调研，需要从使用者的角度出发，确认业务系统每个原子操作产生了哪些数据，数据存储在哪些数据表中。这部分的调研需要调研人员通过系统文档资料梳理系统流程，并通过实际操作来验证数据流程，最后结合数据字典将系统流程和数据表进行关联。

数据源盘点需关注数据源种类，如结构化、半结构化和非结构化数据，以及链接地址、账号、密码、可抽取数据的时间段等；数据表级别关注是否为核心表、时间戳字段、数据更新标识、表的总数据量、日增数据量等信息。

系统与数据调研完后，需输出相应的产出物，并与业务系统的相关人员就输出物中的产出项进行沟通和确认。在实际实施中，不同企业的信息系统建设情况也不尽相同，输出物中的内容项可能需要以迭代方式进行补充调研。

4.总体规划输出

规划阶段包含业务侧和技术侧的调研，两边的调研工作可以并行开展。在业务侧完成调研及需求规划后，技术侧需要结合业务侧的产出进行相关的数据探查事项，主要目的是确认调研产出是否足够支撑业务规划的数据应用建设。

总体规划在最终定稿后，业务侧需输出指标、标签清单、数据应用规划文档等，而技术侧需输出技术和系统调研的相关输出物，以及系统调研阶段的总结性报告。

2. 系统设计

系统设计包含总体设计、数据设计及平台设计。

1.总体设计（数据架构、平台架构和研发规范）

第一阶段的规划工作完成后，进入总体的架构设计阶段。此阶段需要回答以下问题：如何构建统一、规范、可共享的数据体系，如何避免数据的冗余和重复建设，如何规避数据烟囱和不一致性等。由阿里巴巴提出的 OneData 的核心思想是统一数据主体、统一数据建模、统一数据服务以及一系列的数据管理体系。在设计阶段，可以从这几个方面进行考虑与架构。这一阶段由技术架构师与模型设计师主导，规划设计出整体的数据架构、平台架构和研发规范，如下图所示。

（1）数据架构

数据中台的数据架构设计是基于需求调研阶段的业务需求、数据情况，完成数据中台概要设计工作。数据架构设计主要包含 OneModel 、OneID 和 OneService 。

1. OneData

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

如何实现：

数据划分主题进行管理：表的命名，字段的命名等规范统一，做到见名知义

数据格式和字段命名和定义规范化：具体参考离线数仓项目讲解的表和字段命名规范：数仓分层-业务主题域-业务过程-基础信息-分区规则

指标一致，不存在二义性：提供全局数据字典确保意义一致。

数据模型复用：推荐采用分层的设计方式，通常包括：ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS应用数据层 / DM数据集市层，DIM 公共维度层。

数据完善：数据中台尽可能的覆盖到所有业务过程，用户和系统的一切行为都被记录下来永久保存OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的

差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。

OneModel 可分为以下四部分。

业务板块：根据业务的特点和需求将相对独立的业务划分成不同的业务板块，不同业务板块之间的指标或业务重叠度较低。数据域：数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。划分数据域前，需要基于数据调研与业务调研，熟悉各业务系统设计文档、数据字典等。归纳与总结出跨源的主题域合并，梳理出整个企业的数据域。数据域划分上，需要从三个方面进行考虑。

1）全局性：站在企业高度上，保障良好的扩展性和稳定性。

2）数量适中：根据业务情况，划分的粒度要粗细合适，通常在 5～15 个。

3）可理解：站在业务的角度上，确保划分便于理解，不产生歧义。

在划分数据域时，既要涵盖当前所有业务的需求，也要考虑有新业务时，能够将其包含到已有的数据域中，或者能够很容易地拓展新的数据域。

总线矩阵：在进行了充分的业务调研和需求调研后，就要构建总线矩阵了。总线矩阵由业务处理过程和维度组成一个二维表格。在行为不同的业务处理过程（事实）与维度的交叉点上打上标记，表示该业务处理过程与该维度相关。这就是构建一致性维度与一致性事实的过程。维度表和事实表的模型设计以构建出来的总线矩阵为依据。

数据分层：数据模型以维度建模理论为基础，建设数据中台的公共数据层。一般将数据模型划分为操作数据层（Operational Data Store，ODS）、通用数据模型层（Common Data Model，CDM）和应用数据层（Application Data Service，ADS）。

OneID 功能包含以下四部分。

OneID 配置：主要根据具体的业务需求，完成数据源表、ID 映射表、歧义规则表的设置工作。

OneID 数据处理：主要通过数据源表和 ID 映射表等配置表单完成原始数据的数据拉取和清洗等操作，生成基础数据。

OneID 规则计算：主要利用图计算框架完成关键连接点的搜索和歧义数据的图连通工作，并根据配置的规则对图数据进行切割，从而唯一确定一个实体的身份信息，生成 OneID。

OneID 数据存储和展示：主要完成 OneID 图数据存储和展示，以及最后生成的 OneID 清单数据存储等。

OneService 统一数据服务

OneService 包括以下功能模块：服务单元设计、API 设计、API 审核和 API 运营。服务单元设计是指将单个或多个物理表配置成一个视图。基于配置好的服务单元，通过简单可视化界面或 SQL 脚本，设计 API 的请求参数和返回参数，以及对应的 API 信息。API 设计好后，将其发布至服务市场供使用者调用。API 在被使用前，需要经过申请审批。被使用的 API 需要运维及监控，包括平均响应时长、调用次数、错误率、掉线百分比等指标的监控，还可以配置 API 的告警及限流措施等。

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

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

提供无状态的，高性能和稳定可靠的数据服务

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

（2）平台架构

结合前期调研的业务需求和数据现状，从宏观层面规划出数据中台的各个模块、各个功能部件所用到的技术总体架构图。总体架构由数据采集、数据存储、数据流、网络、部署、安全等组成。

采集架构：数据采集打通各种数据来源，为数据中台提供待分析和处理的数据，主要分为实时和离线数据采集方案，具体可参见 4.2.2 节。

存储架构：整个存储架构包含原始数据源存储技术、数据源接入技术、数据中台数据存储与计算技术、数据服务及数据应用技术。从数据采集、数据加工到最后的数据展现，设计出整个流程中不同数据来源到数据中台的存储。

数据流：从业务数据进入数据采集通道，到进入数据中台在各个加工任务中流转，再到数据对外服务的这个过程，需要进行哪些存储、哪些技术处理等，这些步骤需要在设计时就以数据流向用流程图的形式画出。

网络架构：数据中台涉及与多方的源系统进行数据交互，而网络设计对于后续数据同步、接口调用等有较大影响，因此需要综合考虑各业务系统与搭建数据中台环境的网络情况。如果涉及上云，业务系统有可能在本地，而数据中台的环境在云上，要考虑是否需要设计专线。同时根据每天要同步的数据量，设计出带宽的容量。

部署架构：这部分设计主要涉及数据中台的研发平台与应用软件。需包含整体的部署方案，如 Hadoop 生态圈中所采用各个组件的部署节点，每个角色的功能部署几个节点，在机器资源上如何分布，还包括数据库的主备方案、后端应用的部署等。

安全架构：主要包含研发平台的用户角色权限控制方案、开发与生产环境隔离方案、数据安全方案。考虑在数据抽取、数据加工处理和数据服务的整个数据加工链条中对企业的敏感信息进行加密处理。

（3）数据模型设计规范与标准

良好的数据模型可方便、有效地组织数据中台中存储的企业数据资产，所以数据模型的设计工作有必要遵循一定的规范和约束。团队在明确定义模型设计的相关实施规范及要求后，需要向参加数据中台建设的相关人员明确规范和要求，确保团队内统一标准，以保障和提升数据开发与运维管理的效率，并方便后续的知识移交和数据管理工作。规范应清晰地阐述模型定义与代码开发的相关约束。模型规范要明确数据架构中的分层、分层的命名，定义不同接入频率、不同系统表命名方式。代码研发规范层面应定义好各种不同用途、不同脚本类型的命名规范等。

2. 数据设计 （数据集成、模型设计和服务详设）

数据设计包括数据集成、模型设计和服务详设，如下图所示。

（1）数据集成

数据集成需要解决不同源系统数据异构性问题。源业务系统的数据类型多种多样，有来源于关系型数据库的结构化数据，也有来源于非关系型数据库的非结构化数据及半结构化数据。

结构化数据一般以二维形式存储在关系型数据库中，对于这种数据类型，数据集成有 3 种方式。

直连同步：通过规范的 API（如 JDBC）直接连接业务库。但是业务库直连的方式对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能。即使业务数据库存在备库，当数据量较大时，此种抽取方式性能也较差，不太建议使用。

首先我们需要确认平台接入哪些数据，确认数据接入的方式是实时接入还是离线抽取。离线抽取的话是全量抽取还是增量抽取。抽取频次数每天抽取还是每小时抽取。

离线数据可以使用Sqoop抽取关系型数据库到HDFS。

实时接入可以使用kafka实时写入数据到HDFS集群上。

数据文件同步：通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文件，由专门的文件服务器（如 FTP 服务器）作为中间文件交换，加载到数据中台。但由于要保证数据文件的完整性，通常除数据文件外，还需要上传校验文件，供下游系统校验数据同步的准确性。

数据库日志解析同步：这种方式实现了实时与准实时同步，延迟可以控制在毫秒级别，并且对业务系统的性能影响比较小，目前广泛应用于从业务系统到数据中台系统的增量数据同步应用之中。

除了数据读取的方式，还可按数据量来分解数据集成策略。

小数据量同步：数据记录小于 10 万条的源表建议每日全量更新，写入全量分区表。全量分区表可按天创建。可根据业务需要设置数据的生命周期，并定时清理。

大数据量同步：数据记录大于 10 万条的源表通过时间戳抽取增量数据到增量分区表。增量分区表可设置长周期，根据需要设置冷、温、热数据区。

非结构化数据一般没有固定的结构，各种文档、图片、视频、音频等都属于非结构化数据。对于这类数据，数据集成策略通常是直接整体存储，而且一般存储为二进制的数据格式。

除了结构化数据和非结构化数据，还有半结构化数据。半结构化数据的应用越来越广泛。半结构化数据带有用来分隔语义元素和数据记录的标记，具有自描述特性，常见的数据格式有 JSON 和 XML。对于半结构化数据，数据集成策略同样可以是直接整体存储。但随着数据技术的发展，NoSQL 数据库已经可以很好地支持半结构化数据的存储。NoSQL 在逻辑表现形式上相当灵活，主要有 4 种模型。

键值模型：键值模型在表现形式上比较单一，但却有很强的扩展性。

列式模型：由于每列可以动态扩展，列式模型相比键值模型能够支持的数据更为复杂。

文档模型：文档模型对于复杂数据的支持和在扩展性上都有很大优势。

图模型：使用场景通常基于图数据结构，如社交网络、推荐等。

在半结构化数据集成方面，建议使用 NoSQL 数据库。

（2）模型设计

数据模型可以分为主题域模型、标签模型和算法模型。其中主题域模型是基础，是对数据标准化、规范化的过程。标签模型基于主题域模型将对象的各种标识打通归一，将跨业务板块、跨数据域的对象组织起来。算法模型基于主题域模型，将各对象的历史行为、属性等数据作为输入，利用算法能力分析和预测对象的行为。下面来详细介绍这三种数据模型的设计。

首先来看主题域模型设计。主题域模型也就是大家常说的数仓模型。数仓模型的设计方法论已经非常成熟，最权威的数仓模型设计是 Kimball 的维度建模。阿里巴巴在维度建模的基础上进行了升华，沉淀了 OneModel 方法论，将数据从业务板块到业务域、业务流程、指标和维度，一层层梳理，构建出企业的指标体系并形成数仓模型。OneModel 方法论强调从业务过程出发，站在数据应用与分析的角度，梳理出业务过程中涉及的维度及度量，并对业务过程中的度量进行规范化定义，统一指标口径，消除指标二义性，形成统一的指标体系；同时，构建一致性维度及事实矩阵，并据此进行维度及事实模型设计。

主题域模型可分为以下三层。

操作数据层（Operational Data Store，ODS）：主要将业务系统、日志等结构化和半结构化数据引入数据中台，保留业务系统原始数据。ODS 分为缓冲区和数据服务区。缓冲区设计主要保持与数据源的一致性，保证 ODS 能原样引入所接入的源数据，不进行任何类型转换和数据加工处理。数据服务区包括全量明细数据，该数据是对缓冲区数据进行类型转换或增量合并处理后得到的，数据服务区为通用数据模型层和应用数据层提供数据服务。引入缓冲区是考虑到数据引入后可能会有一些特殊的处理需求，比如埋点数据采集后一般为 JSON 格式数据，这类需要在解析后再引入；或者有一部分实时采集的数据需要与当前存量数据进行合并处理，以获取当前最新状态的数据。缓冲区能起到很好的追溯作用，方便后续追查与核对问题，为后续的数据分层建模提供良好的数据基础。

通用数据模型层（Common Data Model，CDM）：包含整个数据中台的大部分数据，是数据中台的基础，因此保证该层数据的健壮性是重中之重。CDM 主要完成公共数据加工与整合，建立一致性的维度，构建可复用、面向分析和统计的明细事实表及汇总事实表。

应用数据层（Application Data Service，ADS）：提供直接面向业务或应用的数据，主要对个性化指标数据进行加工处理；同时为方便满足数据应用、数据消费的诉求，进行面向应用逻辑的数据组装，比如大宽表集市、横表转纵表、趋势指标串等。

其次介绍标签模型设计。实体标签模型是数据中台建设中的另一类重要模型，这类模型对于企业数据治理、业务输出都具有举足轻重的作用。企业的重要数据资产，如客户、商品、门店、供应商、员工等实体的标签模型都是数据中台加工的重点。比如，先获取商品的生产、采购、定价、销售、退货等历史行为数据，然后按照业务场景需要来制定商品所涉及的商品标签，形成商品标签模型。

最后来讲解算法模型设计。数据中台整合全域的数据，需要通过 AI 算法将宝贵的数据形成有价值的数据资产。算法模型是数据中台中最难设计的模型，但又是最能将企业的数据资产发挥出几何倍数价值的模型。例如，凭借商品个性化推荐模型，淘宝的“千人千面”场景帮助用户极大提升了体验感，缩短了用户的交易链条，提升了用户的转化率。算法模型与上两种模型的不同之处在于，在建模的过程中需要充分聚焦算法所服务的场景。比如对于商品推荐算法模型，建模时需要充分理解涉及商品推荐的相关场景。商品个性化推荐一般有首页推荐商品列表、猜你喜欢专栏、购物车推荐专栏等场景。我们要充分梳理这些场景的需求点，然后制定实现推荐模型的场景，如图 4-9 所示。在通过场景梳理编排出算法实现逻辑后再开始设计算法模型及实现逻辑。

（3）服务详设

数据服务按数据内容可分为主题分析类数据服务、标签类数据服务和算法类数据服务。

主题分析类数据服务可通过整合数据分析场景，分专题设计通用的数据汇总宽表，通过数据宽表拼写不同的 SQL，支撑相应的数据报表，避免数据的冗余建设。

标签类数据服务的设计却有所不同，切忌按照标签使用场景逐个进行数据服务设计。因为运营可能会随时增加标签，迫使在设计标签服务时考虑通用性和扩展性。一般建议以底层的标签宽表为出发点，设计标签通用的增加、修改和查询功能。

与业务联动紧密的算法类数据服务则需要注意可能直接面对低延迟、高并发的调用场景，比如推荐场景，包括搜索推荐、猜你喜欢、加购推荐等，一定要做好服务接口的性能压测，以满足业务实时交易级的性能要求。

除了考虑服务的通用性和性能，还需要考虑服务开放的数据安全性。

3. 平台设计（资源规划、技术选型、部署方案）

平台设计指的是大数据运行平台在资源规划、技术选型、部署方案等方面的设计，是根据总体架构中的平台架构展开的。平台能力具有通用性、扩展性和前瞻性是数据中台成功建设的基础。平台设计阶段将以客户现有数据体量及可预测的业务增长情况作为考量因素，对平台建设所需的资源进行预估和规划，产出平台及数据应用部署所需的资源清单、部署方案及相关人员在平台上的账号和权限的设计等。

1、资源规划：

需要对支撑大数据平台所需的资源进行估算。一般可考虑未来 3 年企业的数据量，可借鉴的存储空间资源估算公式如下：

磁盘空间预估=当前企业数据存量（TB）×3 +数据日　增量（TB）×3（副本数）×365×3

数据中台架构应该具备的能力

1、基础设施/基础平台、存储引擎、计算引擎、辅助服务

2、数据集成

3、数据开发

4、工作流调度

5、数据治理：数据质量、元数据管理、数据安全

6、数据可视化

7、DevOps

6、其他数据服务

2、技术选型：

大数据技术选型的原则是考虑当前及未来一段时间可能使用的场景，根据场景来推导技术的选择。一般会从数据的采集、存储、计算、管理、运维等多方面考虑需要选择的技术或成熟产品来搭建大数据平台。比如，文件采集使用 Flume 到 HDFS，数据库采集使用 DataX 到 HDFS，计算与加工基于 Hive 存储、离线使用 Spark SQL 处理、实时采用 Flink 等。

数据存储：HDFS，HBase，Kudu等

数据计算：MapReduce, Spark, Flink

交互式查询：Impala, Presto

在线实时分析：ClickHouse，Kylin，Doris，Druid，Kudu等

资源调度：YARN，Mesos，Kubernetes

任务调度：Oozie，Azakaban，AirFlow等

....

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

数据量小的使用 MySQL：Hive数仓，Spark计算引擎的计算结果导出到 MySQL

数据量大的使用 HBase + ElasticSearch：解决海量数据中的低延迟高效查询

需要多维分析的可能需要 ClickHouse，Kylin，Greenplum：提供现在分析能力

实时性要求高的需要用到 Redis：提供高性能单点查询能力

3、 部署方案、ETL平台

1、ETL平台、统一计算，统一运管 运行管理能力：数据任务管理、监控和资源管理的功能组件库

集中扩展、管理大数据计算与存储资源，使其成为共享的数据计算资源。

在开发数据模型时，我们必须有一个统一的平台，能够像流水线一样，把数据一步步加工成数据模型。这其中涉及到数据萃取、数据聚合、作业调度等。

3. 开发实施

开发实施阶段可分为环境搭建、数据集成、代码研发三个层面。

1. 环境搭建

平台层面的环境搭建，包括大数据集群、数据研发平台、智能数据应用产品等相关工具的部署。平台的搭建按设计阶段输出的资源规划和平台部署方案实施即可。在平台环境、工具组件部署后，需要对平台环境进行测试，同时在产品工具层面，需要对企业进行相关产品的使用培训，并通过企业的验收。

2. 数据集成

数据集成方案从宏观上设计和规范了数据源级别的数据集成流程和同步策略。在当前阶段，需要对各数据源制定表级别的集成策略，形成数据同步清单，包括上云数据存量、日增量、分区字段、数据更新频率、存储周期、上云时间等相关信息，供具体实施时使用。数据集成工作实施后，还需要逐一对数据源表进行数据监控及验证，以确保集成的数据无问题。

3. 代码研发

代码研发阶段包括数据研发与验证、应用研发与测试、性能测试三部分。数据研发与验证主要包括数据模型的业务代码开发、数据监控代码开发、数据准确性验证。从模型数据开发、数据监控开发到数据验证，再到模型上线，需要一整套开发流程来保障数据的产出。应用研发与测试主要包括数据应用层面的开发和测试工作，如数据服务、数据应用前端开发。性能测试包括数据产出时间、数据接口服务性能、数据应用访问性能等方面的测试。

4. 试运行

数据中台上线之后，分析专题的指标口径、数据应用效果等多方面的数据准确性都需要通过真实的运行数据去验证。在这个时间段还不太适合全面对外发布，也不宜对外开放数据能力。通常我们需要进行一段时间的试运行。

1.中台试运行

为保障生产环境数据的准确性，需要先在测试环境基于企业全量的数据进行一段时间的试运行，这主要包含以下几步。

1）数据迁移：增量模型涉及的存量数据需进行一次全量的数据迁移，以保证数据的完整性，全量模型则直接按频度进行抽取即可。迁移前，需制定详细的迁移方案及步骤；迁移时，需记录各个环节的关键数据，如迁移耗时、资源消耗情况等；迁移后，需总结并输出迁移报告。

2）数据跑批：完整运行数据中台的全流程任务，包括数据抽取、加工、服务提供及应用展现，分析各层级模型任务的运行耗时以及对应时间段的资源情况，并不断优化、调整运行任务的启动和依赖关系，以达到最佳的配置。

3）数据验证：筛选核心关键指标、标签，进行数据准确性的验证，例如存量指标可与系统现有指标进行对比，增量指标则与模型设计内容逐层对比。

4）应用验证：对于对外服务接口类应用，联系应用方进行接口及数据的验证，并完成应用全流程的拉通，优化调用的频次及时间点；对于报表及专题分析类应用，验证报表数据与数据中台侧数据的一致性，以及测试前端页面、展现数据的性能。

2.历史数据重跑和测试

在试运行过程中，数据中台的指标或标签可能会因为业务侧的口径变更而进行历史数据的重刷动作。在这种情况下，要保证数据准确且可逆，有如下几点注意事项。

影响评估：评估业务变动涉及的模型，并形成清单列表。

数据备份：数据处理前，先备份当前状态下的数据。

口径调整：确认业务口径调整涉及的技术口径调整内容，并体现在模型设计文档的版本控制中。

数据验证：调整后，严格按照设计内容进行数据的验证和测试，并与业务侧达成一致，在测试环境中进行确认。

5. 持续运营

数据中台不是一锤子买卖，是需要持续经营的。在数据中台正式上线后，随着企业业务的不断拓展，会接入更越来越多的数据源，数据的分析也将越来越精细，数据应用场景会更加丰富多样。同时，某些数据应用会因为企业业务方向的调整而废弃，这些已经过时的应用就需要及时清理。作为数据中台的建设者，不仅需要定期与数据使用者主动沟通，了解数据使用情况，了解这些数据到底带来了什么价值，还要通过系统查看指标、标签、专题、应用 API 这些资产的被调用情况，以此来判断是否需要优化等。

1.正式上线

试运行稳定执行一段时间后，可按模块和迭代申请生产环境的正式上线动作，以交付阶段性的工作成果。在正式上线时，分以下两步进行。

1）割接方案。如果数据中台存在替换现有其他系统的情况，就需要制定详细的割接方案，以保障数据中台能够覆盖旧系统的数据能力。2）上线预演。在正式上线前，需进行割接或上线的演练操作，尽可能多地暴露数据、环境、资源等各方面的问题，并逐步进行优化和调整。

系统上线后，制定相关的检查规则及告警机制，以保障数据中台的正常运行。检查规则可大致分为如下两类。

数据规则：数据一致性，主键唯一性，数据完整性。

资源规则：服务器资源，如 CPU、I/O 等；存储告警规则。

检查规则执行完成后，根据检查结果制定告警策略，如异常告警阻断、异常告警不阻断。同时，通过短信、邮件等方式将检查的结果进行告知，并制定告警升级机制。

2.运营保障

系统上线以后，跟进系统的运行、使用情况，综合分析以提炼新的需求点，创造更大的价值点，持续运营。数据中台的运营策略可从产品、应用、数据三方面进行。

产品侧：收集直接使用方的产品体验状况，根据反馈内容进行优化，提高产品的易用性，增强使用方对产品的黏性。

应用侧：分析应用对象的重点关注模块，并阶段性地形成分析报告。中台建设者可根据报告内容，对接应用相关人员，持续挖掘新的需求内容，持续耕耘以创造更大的价值。

数据侧：通过数据链路跟踪的结果，总结阶段性重点关注的数据内容。结合自上而下和自下而上两种途径，分析整个系统数据层面的缺口，并制定汇聚、扩建的计划，提高中台数据支撑的力度。

以上内容摘自《中台实践：数字化转型方法论与解决方案》一书，经出版方授权发布

数据中台建设五步法：

第一步：数据资源的盘点与规划：启动过程组

数据化的基础是信息化或者信息化所产生的数据。这些数据本就有数据化的含义，同时这些数据又会进入数据化框架体系，继续通过计算产出更多的数据和更大的价值。所以，对企业数据资源的盘点是数据化建设的前提和基础。一份完整、准确的数据资源是后续数据化建设的有力保障。

数据资源的盘点与规划需要达到以下目的：

（1）梳理现状：对现有数据资源盘点和统计。

（2）整体规划：对企业可以拥有或者应该拥有的数据资源进行规划。

（3）回顾复盘：构建盘点体系并使用必要工具，保证盘点的成果能够始终与真实情况相符。

第二步：数据应用规划与设计：规划过程组

企业要基于现有的技术条件和方案，进行相对完整的数据应用规划。这个步骤可以回答如下问题。

企业中有哪些数据需求：我们要从业务线、业务层级到最细粒度的岗位，梳理数据需求。

企业应该构建哪些数据应用：我们要围绕数据需求进行数据应用的整体规划和设计。

应该按照什么顺序实现这些数据应用：我们要对数据应用建立评估模型，评估的维度包括数据应用是否可以实现、数据应用的业务价值、数据应用的实现成本这三个主要方面。通过评定结果，我们可以确定数据应用的实现路径。

第三步：数据资产建设：规划过程组、执行过程组

数据资产的建设要依托数据中台的核心产品完成。数据资产是企业数据化建设的关键基础。所有的数据化建设最后都以数据资产为基础，并且围绕这个基础展开。数据资产将是企业在全面数据化建设前期中投入最多、见效最慢的基础层模块。关于数据中台的种种探讨和争议以及妥协的很大一部分原因是这个基础建设庞大、复杂和投入高。

数据资产建设的内容包括以下几个方面：

技术建设

（1）产品选型。产品选型包括如何选择数据中台产品、数据中台产品应该具备的功能以及技术参数指标。

（2）技术架构设计。技术架构设计包括数据中台产品如何部署、如何替换传统的数据仓库或者与之并行、数据中台如何抽取当前的应用数据。

标准和数据仓库模型构建

（1）建模及开发规范。建模及开发规范包括数据仓库模型设计规范的制定，数据开发规范的制定，如何避免当前较为常见的数据开发混乱、难以运维的情况。

（2）数据建模。数据建模包括进行数据仓库模型构建，并提交评审。

数据抽取、数据开发、任务监控与运维

（1）数据抽取。数据抽取包括从数据资源层抽取数据进入ODS层。

（2）数据开发。数据开发包括进行数据任务开发，进行数据清洗、数据计算。

（3）任务监控与运维。任务监控与运维包括监控所有数据任务，对异常和错误任务进行必要的人工干预和处理。

数据质量校验

数据质量校验包括对当前发现的数据质量问题进行校验和处理，推动数据治理工作开展和持续优化。

数据应用支撑

数据应用支撑包括为当前的数据应用开发提供支撑开发平台。

第四步：数据应用的详细设计与实现：执行过程组、监控过程组、不断优化、持续改进

不管是使用瀑布模型还是敏捷模型，数据应用的设计大体上都可以遵循传统信息化应用设计的过程和理念。数据应用中的数据开发一般在数据库或者数据仓库中完成。数据应用的内容展示可以采用BI分析工具展现，例如可视化大屏或者定制化开发应用。数据应用还可以通过API接口服务提供数据成果，让其他外部应用按需调用。数据应用的开发与传统信息化应用的开发有以下不同之处。

数据应用关注数据源的内容和质量：数据质量

我们在数据应用实施前应该充分了解企业当前的数据源情况，包括数据种类、每种数据的具体属性、数据内容的质量等问题。大部分落地失败的数据应用，都是由数据源的各种问题引起的，比如数据缺失或者数据质量问题。

复杂的数据开发需要不断调优和迭代

随着机器学习、深度学习等算法的引入，数据模型的构建手段越来越丰富。但是在通常情况下，最终业务价值的产生是一个复杂的过程，不仅需要数据的支撑，还需要管理的配合。

数据应用的结果数据的验证工作量占比高

论证数据结果的正确与否或者评估数据应用的效果，是一项费时、费力的工作。即使相对简单的指标计算，最后也经常会占用全部过程中1/3以上的时间进行正确性验证。甚至很多算法类项目，需要提前构建成果评估模型，并首先获得甲方企业的认可，然后才能开始进行数据开发。

数据应用的运维难度大

因为数据中的各种异常情况往往是不可知或者意想不到的，所以数据运维需要有强大的人工保障，以保持任务的运转。

数据应用的成果需要运营

数据应用的开发完成只是数据发挥价值的第一步，如何让业务部门理解模型、用好数据才是后续的关键。尤其是在刚刚引入新的数据，且尚未显现业务价值的时候，企业更需要对数据进行深入运营。

第五步：数据化组织规划

企业数据化应该是在未来一个时期内具有企业战略高度的事情，数据化需要一个具有同等战略高度的组织负责推进。无论是从传统的IT部门转型还是由战略部门或者类似部门介入都是很好的选择。组织是保障数据中台顺利落地的一个核心，也是推动企业数据化进程的人员抓手。

四、总结

“数据中台是实现企业全面数据化的一个解决方案，是一套支撑企业全面数据化的架构，会成为企业开展全面数据化的基础设施。”如果用技术语言总结就是：“前台聚合，中台解耦，数据融合，业务创新”。

随着大数据和人工智能的进一步普及，几乎所有的传统企业都在拥抱并推动自身数字化转型。作为一本数据中台实践，内容基本上覆盖了企业数字化实战的方方面面，对方法论、实施路径、平台、数据应用等方面都有阐述，有着一定的借鉴价值。

（以上内容摘录自网络，如有侵权请联系删除）

数据中台这个东西，现在业界并没有一个完整的标准定义，数据中台至少首先是一个分布式的数据仓库，同时包含相对应实施的方法论和方案，介于分布式数据仓库和企业全面数据化中间的任意一个点都可以被定义为数据中台。

可以说，数据中台是实现企业全面数据化的一个解决方案，是一套支撑企业全面数据化的架构，会成为企业开展全面数据化的基础设施。

（1）中台是什么？

企业级能力复用平台！

（2）如何构建中台？

以用户为中心，从战略入手，愿景为指引，用科学有效的方法，步步为营沉淀企业级能力，辅以必要的组织与系统架构调整，方得中台。

（3）中台的价值是啥？

中台为前台而生，专注于为前台赋能，沉淀企业的能力与复用，提升企业的客户响应力。

（4）如何成为数据中台的参与者？

数据中台围绕数据技术开展。除了编程技术、应用开发技术与传统的IT应用技术具有部分的重合，数据中台还有自己的技术体系，比如大数据开发技术、数据仓库建模技术、数据分析体系、数据应用技术体系等。

数据中台建设五步法：

系统都是为应用而生的，数据中台也不例外。要构建一套数据中台服务于企业内部和外部运营，需要有成熟的数据中台建设方法论作为指导。企业建设数据中台遵循的方法论就像菜谱，初学者根据菜谱按部就班就可以轻松完成一道道菜肴，高阶玩家根据菜谱可以查漏补缺，使厨艺精进。数据中台建设方法论可分为高阶规划、系统设计、开发实施、试运行和持续运营 5 个阶段。

1、高阶规划

数据中台规划阶段可细分为业务架构师主导的业务规划和数据架构师主导的数据规划。这两部分内容是相辅相成的，由业务规划进行业务输入，由技术规划对数据现状进行探查，判断业务规划蓝图的可行性，最终形成可行的蓝图规划与应用设计。

1. 业务规划（业务调研、蓝图设计和应用设计）

业务规划分为三个步骤：业务调研、蓝图设计和应用设计。首先通过业务调研对企业进行了解。

（1）业务调研

业务调研主要包括以下两方面。

第一，战略与组织解读。企业战略决定了数据中台的上限，也决定了企业对数据中台的期望与目标。企业战略不仅能折射出企业的数据诉求本质，也能体现出数据中台对企业的价值。因此，通过明确企业战略对企业运营提升的要求，可以抓住企业运营提升的关键环节，对公司管理现状进行诊断，分析数字化能力给企业带来的效率和效益提升，明确企业数字化优化的目标与范围。同时，明确企业的组织架构，熟悉企业的业务模式，了解企业的业务板块，梳理业务部门的业务流程。

第二，调研访谈。调研访谈是通过问卷或针对性访谈的形式，对业务专家进行调研的过程。在调研的过程中可以收集报表、汇报材料、报告、可视化看板、系统建设材料等信息辅助理解业务。调研访谈的目的是通过对业务专家的调研，了解企业与业务，了解业务诉求与痛点，为后续的蓝图设计和应用设计提供业务知识基础和输入。调研前需要对业务背景、行业知识、调研问卷分布做准备，以便达到期望的调研效果。可以将调研问卷提前分发给业务专家，以便业务专家更有针对性地准备问题答复，提高调研效率。调研后需要结合业务场景，对数据进行推导，得出指标需求。推导的过程是现状诉求→需求推导→解决手段→场景推导→指标推导，详见下表。

（2）蓝图设计

通过业务调研了解企业，结合数据现状与业务痛点，将企业不同实体的数据进行提炼、抽象，形成数据域，将数据资产按照一定的体系进行规整，再结合业务诉求对数据分析场景进行提炼，最终形成一张囊括企业数据现状与未来的蓝图，为后续数据中台的建设提供宏观与发展路线的指导。

蓝图设计可从以下几个方面进行分析设计：数智化转型的一些考虑和战略、设计方法论、对客户业务的整体解析、数据中台价值化、分析链路梳理、数据域梳理和划分等。数据中台蓝图一般包括三部分：数据源、数据基础能力及数据洞察与智能应用规划。通过数据中台蓝图可以快速了解企业数据中台的范围与价值。

（3）应用设计

衔接蓝图设计，结合数据调研的成果判断数据可行性后，将数据分析场景、智能应用进行系统落地的可视化设计，形成 PRD 文档和原型进行产品设计与说明，最终促成应用的实现。

2. 技术调研

技术调研是对企业的 IT 整体现状进行摸查，调研内容包含企业主要业务及核心业务系统、整体网络拓扑现状、信息安全相关要求等。

对企业主要业务和核心业务系统的调研包括业务和技术两个方向。业务上梳理企业的主要业务及核心业务流程，技术上则梳理各业务系统及它们之间的数据流转关系。两者相互印证，输出企业的信息系统现状大图，并基于此确定后续的业务系统调研范围。

整体网络拓扑现状的梳理，有助于厘清企业业务数据的存储分布位置、数据传输的带宽限制等信息，为后续数据集成方案设计提供基础信息输入。

通过信息安全相关的调研了解企业内与信息安全相关的组织部门、规章制度等信息和要求，为后续制定数据处理和使用的流程规范提供依据。

3. 系统和数据调研

系统与数据调研的目的是厘清企业数据资源的种类、分布、存储及管理现状。系统与数据调研是按业务系统进行盘点的。系统盘点的范围来源于技术调研的输出。盘点项包括业务流程、业务动作、数据源、数据表、数据字典。该调研工作一般由技术主导。

业务流程及动作的调研，需要从使用者的角度出发，确认业务系统每个原子操作产生了哪些数据，数据存储在哪些数据表中。这部分的调研需要调研人员通过系统文档资料梳理系统流程，并通过实际操作来验证数据流程，最后结合数据字典将系统流程和数据表进行关联。

数据源盘点需关注数据源种类，如结构化、半结构化和非结构化数据，以及链接地址、账号、密码、可抽取数据的时间段等；数据表级别关注是否为核心表、时间戳字段、数据更新标识、表的总数据量、日增数据量等信息。

系统与数据调研完后，需输出相应的产出物，并与业务系统的相关人员就输出物中的产出项进行沟通和确认。在实际实施中，不同企业的信息系统建设情况也不尽相同，输出物中的内容项可能需要以迭代方式进行补充调研。

4.总体规划输出

规划阶段包含业务侧和技术侧的调研，两边的调研工作可以并行开展。在业务侧完成调研及需求规划后，技术侧需要结合业务侧的产出进行相关的数据探查事项，主要目的是确认调研产出是否足够支撑业务规划的数据应用建设。

总体规划在最终定稿后，业务侧需输出指标、标签清单、数据应用规划文档等，而技术侧需输出技术和系统调研的相关输出物，以及系统调研阶段的总结性报告。

2. 系统设计

系统设计包含总体设计、数据设计及平台设计。

1.总体设计（数据架构、平台架构和研发规范）

第一阶段的规划工作完成后，进入总体的架构设计阶段。此阶段需要回答以下问题：如何构建统一、规范、可共享的数据体系，如何避免数据的冗余和重复建设，如何规避数据烟囱和不一致性等。由阿里巴巴提出的 OneData 的核心思想是统一数据主体、统一数据建模、统一数据服务以及一系列的数据管理体系。在设计阶段，可以从这几个方面进行考虑与架构。这一阶段由技术架构师与模型设计师主导，规划设计出整体的数据架构、平台架构和研发规范，如下图所示。

（1）数据架构

数据中台的数据架构设计是基于需求调研阶段的业务需求、数据情况，完成数据中台概要设计工作。数据架构设计主要包含 OneModel 、OneID 和 OneService 。

1. OneData

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

如何实现：

数据划分主题进行管理：表的命名，字段的命名等规范统一，做到见名知义

数据格式和字段命名和定义规范化：具体参考离线数仓项目讲解的表和字段命名规范：数仓分层-业务主题域-业务过程-基础信息-分区规则

指标一致，不存在二义性：提供全局数据字典确保意义一致。

数据模型复用：推荐采用分层的设计方式，通常包括：ODS 原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS应用数据层 / DM数据集市层，DIM 公共维度层。

数据完善：数据中台尽可能的覆盖到所有业务过程，用户和系统的一切行为都被记录下来永久保存OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的

差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。

OneModel 可分为以下四部分。

业务板块：根据业务的特点和需求将相对独立的业务划分成不同的业务板块，不同业务板块之间的指标或业务重叠度较低。数据域：数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。划分数据域前，需要基于数据调研与业务调研，熟悉各业务系统设计文档、数据字典等。归纳与总结出跨源的主题域合并，梳理出整个企业的数据域。数据域划分上，需要从三个方面进行考虑。

1）全局性：站在企业高度上，保障良好的扩展性和稳定性。

2）数量适中：根据业务情况，划分的粒度要粗细合适，通常在 5～15 个。

3）可理解：站在业务的角度上，确保划分便于理解，不产生歧义。

在划分数据域时，既要涵盖当前所有业务的需求，也要考虑有新业务时，能够将其包含到已有的数据域中，或者能够很容易地拓展新的数据域。

总线矩阵：在进行了充分的业务调研和需求调研后，就要构建总线矩阵了。总线矩阵由业务处理过程和维度组成一个二维表格。在行为不同的业务处理过程（事实）与维度的交叉点上打上标记，表示该业务处理过程与该维度相关。这就是构建一致性维度与一致性事实的过程。维度表和事实表的模型设计以构建出来的总线矩阵为依据。

数据分层：数据模型以维度建模理论为基础，建设数据中台的公共数据层。一般将数据模型划分为操作数据层（Operational Data Store，ODS）、通用数据模型层（Common Data Model，CDM）和应用数据层（Application Data Service，ADS）。

OneID 功能包含以下四部分。

OneID 配置：主要根据具体的业务需求，完成数据源表、ID 映射表、歧义规则表的设置工作。

OneID 数据处理：主要通过数据源表和 ID 映射表等配置表单完成原始数据的数据拉取和清洗等操作，生成基础数据。

OneID 规则计算：主要利用图计算框架完成关键连接点的搜索和歧义数据的图连通工作，并根据配置的规则对图数据进行切割，从而唯一确定一个实体的身份信息，生成 OneID。

OneID 数据存储和展示：主要完成 OneID 图数据存储和展示，以及最后生成的 OneID 清单数据存储等。

OneService 统一数据服务

OneService 包括以下功能模块：服务单元设计、API 设计、API 审核和 API 运营。服务单元设计是指将单个或多个物理表配置成一个视图。基于配置好的服务单元，通过简单可视化界面或 SQL 脚本，设计 API 的请求参数和返回参数，以及对应的 API 信息。API 设计好后，将其发布至服务市场供使用者调用。API 在被使用前，需要经过申请审批。被使用的 API 需要运维及监控，包括平均响应时长、调用次数、错误率、掉线百分比等指标的监控，还可以配置 API 的告警及限流措施等。

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

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

提供无状态的，高性能和稳定可靠的数据服务

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

（2）平台架构

结合前期调研的业务需求和数据现状，从宏观层面规划出数据中台的各个模块、各个功能部件所用到的技术总体架构图。总体架构由数据采集、数据存储、数据流、网络、部署、安全等组成。

采集架构：数据采集打通各种数据来源，为数据中台提供待分析和处理的数据，主要分为实时和离线数据采集方案，具体可参见 4.2.2 节。

存储架构：整个存储架构包含原始数据源存储技术、数据源接入技术、数据中台数据存储与计算技术、数据服务及数据应用技术。从数据采集、数据加工到最后的数据展现，设计出整个流程中不同数据来源到数据中台的存储。

数据流：从业务数据进入数据采集通道，到进入数据中台在各个加工任务中流转，再到数据对外服务的这个过程，需要进行哪些存储、哪些技术处理等，这些步骤需要在设计时就以数据流向用流程图的形式画出。

网络架构：数据中台涉及与多方的源系统进行数据交互，而网络设计对于后续数据同步、接口调用等有较大影响，因此需要综合考虑各业务系统与搭建数据中台环境的网络情况。如果涉及上云，业务系统有可能在本地，而数据中台的环境在云上，要考虑是否需要设计专线。同时根据每天要同步的数据量，设计出带宽的容量。

部署架构：这部分设计主要涉及数据中台的研发平台与应用软件。需包含整体的部署方案，如 Hadoop 生态圈中所采用各个组件的部署节点，每个角色的功能部署几个节点，在机器资源上如何分布，还包括数据库的主备方案、后端应用的部署等。

安全架构：主要包含研发平台的用户角色权限控制方案、开发与生产环境隔离方案、数据安全方案。考虑在数据抽取、数据加工处理和数据服务的整个数据加工链条中对企业的敏感信息进行加密处理。

（3）数据模型设计规范与标准

良好的数据模型可方便、有效地组织数据中台中存储的企业数据资产，所以数据模型的设计工作有必要遵循一定的规范和约束。团队在明确定义模型设计的相关实施规范及要求后，需要向参加数据中台建设的相关人员明确规范和要求，确保团队内统一标准，以保障和提升数据开发与运维管理的效率，并方便后续的知识移交和数据管理工作。规范应清晰地阐述模型定义与代码开发的相关约束。模型规范要明确数据架构中的分层、分层的命名，定义不同接入频率、不同系统表命名方式。代码研发规范层面应定义好各种不同用途、不同脚本类型的命名规范等。

2. 数据设计 （数据集成、模型设计和服务详设）

数据设计包括数据集成、模型设计和服务详设，如下图所示。

（1）数据集成

数据集成需要解决不同源系统数据异构性问题。源业务系统的数据类型多种多样，有来源于关系型数据库的结构化数据，也有来源于非关系型数据库的非结构化数据及半结构化数据。

结构化数据一般以二维形式存储在关系型数据库中，对于这种数据类型，数据集成有 3 种方式。

直连同步：通过规范的 API（如 JDBC）直接连接业务库。但是业务库直连的方式对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能。即使业务数据库存在备库，当数据量较大时，此种抽取方式性能也较差，不太建议使用。

首先我们需要确认平台接入哪些数据，确认数据接入的方式是实时接入还是离线抽取。离线抽取的话是全量抽取还是增量抽取。抽取频次数每天抽取还是每小时抽取。

离线数据可以使用Sqoop抽取关系型数据库到HDFS。

实时接入可以使用kafka实时写入数据到HDFS集群上。

数据文件同步：通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文件，由专门的文件服务器（如 FTP 服务器）作为中间文件交换，加载到数据中台。但由于要保证数据文件的完整性，通常除数据文件外，还需要上传校验文件，供下游系统校验数据同步的准确性。

数据库日志解析同步：这种方式实现了实时与准实时同步，延迟可以控制在毫秒级别，并且对业务系统的性能影响比较小，目前广泛应用于从业务系统到数据中台系统的增量数据同步应用之中。

除了数据读取的方式，还可按数据量来分解数据集成策略。

小数据量同步：数据记录小于 10 万条的源表建议每日全量更新，写入全量分区表。全量分区表可按天创建。可根据业务需要设置数据的生命周期，并定时清理。

大数据量同步：数据记录大于 10 万条的源表通过时间戳抽取增量数据到增量分区表。增量分区表可设置长周期，根据需要设置冷、温、热数据区。

非结构化数据一般没有固定的结构，各种文档、图片、视频、音频等都属于非结构化数据。对于这类数据，数据集成策略通常是直接整体存储，而且一般存储为二进制的数据格式。

除了结构化数据和非结构化数据，还有半结构化数据。半结构化数据的应用越来越广泛。半结构化数据带有用来分隔语义元素和数据记录的标记，具有自描述特性，常见的数据格式有 JSON 和 XML。对于半结构化数据，数据集成策略同样可以是直接整体存储。但随着数据技术的发展，NoSQL 数据库已经可以很好地支持半结构化数据的存储。NoSQL 在逻辑表现形式上相当灵活，主要有 4 种模型。

键值模型：键值模型在表现形式上比较单一，但却有很强的扩展性。

列式模型：由于每列可以动态扩展，列式模型相比键值模型能够支持的数据更为复杂。

文档模型：文档模型对于复杂数据的支持和在扩展性上都有很大优势。

图模型：使用场景通常基于图数据结构，如社交网络、推荐等。

在半结构化数据集成方面，建议使用 NoSQL 数据库。

（2）模型设计

数据模型可以分为主题域模型、标签模型和算法模型。其中主题域模型是基础，是对数据标准化、规范化的过程。标签模型基于主题域模型将对象的各种标识打通归一，将跨业务板块、跨数据域的对象组织起来。算法模型基于主题域模型，将各对象的历史行为、属性等数据作为输入，利用算法能力分析和预测对象的行为。下面来详细介绍这三种数据模型的设计。

首先来看主题域模型设计。主题域模型也就是大家常说的数仓模型。数仓模型的设计方法论已经非常成熟，最权威的数仓模型设计是 Kimball 的维度建模。阿里巴巴在维度建模的基础上进行了升华，沉淀了 OneModel 方法论，将数据从业务板块到业务域、业务流程、指标和维度，一层层梳理，构建出企业的指标体系并形成数仓模型。OneModel 方法论强调从业务过程出发，站在数据应用与分析的角度，梳理出业务过程中涉及的维度及度量，并对业务过程中的度量进行规范化定义，统一指标口径，消除指标二义性，形成统一的指标体系；同时，构建一致性维度及事实矩阵，并据此进行维度及事实模型设计。

主题域模型可分为以下三层。

操作数据层（Operational Data Store，ODS）：主要将业务系统、日志等结构化和半结构化数据引入数据中台，保留业务系统原始数据。ODS 分为缓冲区和数据服务区。缓冲区设计主要保持与数据源的一致性，保证 ODS 能原样引入所接入的源数据，不进行任何类型转换和数据加工处理。数据服务区包括全量明细数据，该数据是对缓冲区数据进行类型转换或增量合并处理后得到的，数据服务区为通用数据模型层和应用数据层提供数据服务。引入缓冲区是考虑到数据引入后可能会有一些特殊的处理需求，比如埋点数据采集后一般为 JSON 格式数据，这类需要在解析后再引入；或者有一部分实时采集的数据需要与当前存量数据进行合并处理，以获取当前最新状态的数据。缓冲区能起到很好的追溯作用，方便后续追查与核对问题，为后续的数据分层建模提供良好的数据基础。

通用数据模型层（Common Data Model，CDM）：包含整个数据中台的大部分数据，是数据中台的基础，因此保证该层数据的健壮性是重中之重。CDM 主要完成公共数据加工与整合，建立一致性的维度，构建可复用、面向分析和统计的明细事实表及汇总事实表。

应用数据层（Application Data Service，ADS）：提供直接面向业务或应用的数据，主要对个性化指标数据进行加工处理；同时为方便满足数据应用、数据消费的诉求，进行面向应用逻辑的数据组装，比如大宽表集市、横表转纵表、趋势指标串等。

其次介绍标签模型设计。实体标签模型是数据中台建设中的另一类重要模型，这类模型对于企业数据治理、业务输出都具有举足轻重的作用。企业的重要数据资产，如客户、商品、门店、供应商、员工等实体的标签模型都是数据中台加工的重点。比如，先获取商品的生产、采购、定价、销售、退货等历史行为数据，然后按照业务场景需要来制定商品所涉及的商品标签，形成商品标签模型。

最后来讲解算法模型设计。数据中台整合全域的数据，需要通过 AI 算法将宝贵的数据形成有价值的数据资产。算法模型是数据中台中最难设计的模型，但又是最能将企业的数据资产发挥出几何倍数价值的模型。例如，凭借商品个性化推荐模型，淘宝的“千人千面”场景帮助用户极大提升了体验感，缩短了用户的交易链条，提升了用户的转化率。算法模型与上两种模型的不同之处在于，在建模的过程中需要充分聚焦算法所服务的场景。比如对于商品推荐算法模型，建模时需要充分理解涉及商品推荐的相关场景。商品个性化推荐一般有首页推荐商品列表、猜你喜欢专栏、购物车推荐专栏等场景。我们要充分梳理这些场景的需求点，然后制定实现推荐模型的场景，如图 4-9 所示。在通过场景梳理编排出算法实现逻辑后再开始设计算法模型及实现逻辑。

（3）服务详设

数据服务按数据内容可分为主题分析类数据服务、标签类数据服务和算法类数据服务。

主题分析类数据服务可通过整合数据分析场景，分专题设计通用的数据汇总宽表，通过数据宽表拼写不同的 SQL，支撑相应的数据报表，避免数据的冗余建设。

标签类数据服务的设计却有所不同，切忌按照标签使用场景逐个进行数据服务设计。因为运营可能会随时增加标签，迫使在设计标签服务时考虑通用性和扩展性。一般建议以底层的标签宽表为出发点，设计标签通用的增加、修改和查询功能。

与业务联动紧密的算法类数据服务则需要注意可能直接面对低延迟、高并发的调用场景，比如推荐场景，包括搜索推荐、猜你喜欢、加购推荐等，一定要做好服务接口的性能压测，以满足业务实时交易级的性能要求。

除了考虑服务的通用性和性能，还需要考虑服务开放的数据安全性。

3. 平台设计（资源规划、技术选型、部署方案）

平台设计指的是大数据运行平台在资源规划、技术选型、部署方案等方面的设计，是根据总体架构中的平台架构展开的。平台能力具有通用性、扩展性和前瞻性是数据中台成功建设的基础。平台设计阶段将以客户现有数据体量及可预测的业务增长情况作为考量因素，对平台建设所需的资源进行预估和规划，产出平台及数据应用部署所需的资源清单、部署方案及相关人员在平台上的账号和权限的设计等。

1、资源规划：

需要对支撑大数据平台所需的资源进行估算。一般可考虑未来 3 年企业的数据量，可借鉴的存储空间资源估算公式如下：

磁盘空间预估=当前企业数据存量（TB）×3 +数据日　增量（TB）×3（副本数）×365×3

数据中台架构应该具备的能力

1、基础设施/基础平台、存储引擎、计算引擎、辅助服务

2、数据集成

3、数据开发

4、工作流调度

5、数据治理：数据质量、元数据管理、数据安全

6、数据可视化

7、DevOps

6、其他数据服务

2、技术选型：

大数据技术选型的原则是考虑当前及未来一段时间可能使用的场景，根据场景来推导技术的选择。一般会从数据的采集、存储、计算、管理、运维等多方面考虑需要选择的技术或成熟产品来搭建大数据平台。比如，文件采集使用 Flume 到 HDFS，数据库采集使用 DataX 到 HDFS，计算与加工基于 Hive 存储、离线使用 Spark SQL 处理、实时采用 Flink 等。

数据存储：HDFS，HBase，Kudu等

数据计算：MapReduce, Spark, Flink

交互式查询：Impala, Presto

在线实时分析：ClickHouse，Kylin，Doris，Druid，Kudu等

资源调度：YARN，Mesos，Kubernetes

任务调度：Oozie，Azakaban，AirFlow等

....

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

数据量小的使用 MySQL：Hive数仓，Spark计算引擎的计算结果导出到 MySQL

数据量大的使用 HBase + ElasticSearch：解决海量数据中的低延迟高效查询

需要多维分析的可能需要 ClickHouse，Kylin，Greenplum：提供现在分析能力

实时性要求高的需要用到 Redis：提供高性能单点查询能力

3、 部署方案、ETL平台

1、ETL平台、统一计算，统一运管 运行管理能力：数据任务管理、监控和资源管理的功能组件库

集中扩展、管理大数据计算与存储资源，使其成为共享的数据计算资源。

在开发数据模型时，我们必须有一个统一的平台，能够像流水线一样，把数据一步步加工成数据模型。这其中涉及到数据萃取、数据聚合、作业调度等。

3. 开发实施

开发实施阶段可分为环境搭建、数据集成、代码研发三个层面。

1. 环境搭建

平台层面的环境搭建，包括大数据集群、数据研发平台、智能数据应用产品等相关工具的部署。平台的搭建按设计阶段输出的资源规划和平台部署方案实施即可。在平台环境、工具组件部署后，需要对平台环境进行测试，同时在产品工具层面，需要对企业进行相关产品的使用培训，并通过企业的验收。

2. 数据集成

数据集成方案从宏观上设计和规范了数据源级别的数据集成流程和同步策略。在当前阶段，需要对各数据源制定表级别的集成策略，形成数据同步清单，包括上云数据存量、日增量、分区字段、数据更新频率、存储周期、上云时间等相关信息，供具体实施时使用。数据集成工作实施后，还需要逐一对数据源表进行数据监控及验证，以确保集成的数据无问题。

3. 代码研发

代码研发阶段包括数据研发与验证、应用研发与测试、性能测试三部分。数据研发与验证主要包括数据模型的业务代码开发、数据监控代码开发、数据准确性验证。从模型数据开发、数据监控开发到数据验证，再到模型上线，需要一整套开发流程来保障数据的产出。应用研发与测试主要包括数据应用层面的开发和测试工作，如数据服务、数据应用前端开发。性能测试包括数据产出时间、数据接口服务性能、数据应用访问性能等方面的测试。

4. 试运行

数据中台上线之后，分析专题的指标口径、数据应用效果等多方面的数据准确性都需要通过真实的运行数据去验证。在这个时间段还不太适合全面对外发布，也不宜对外开放数据能力。通常我们需要进行一段时间的试运行。

1.中台试运行

为保障生产环境数据的准确性，需要先在测试环境基于企业全量的数据进行一段时间的试运行，这主要包含以下几步。

1）数据迁移：增量模型涉及的存量数据需进行一次全量的数据迁移，以保证数据的完整性，全量模型则直接按频度进行抽取即可。迁移前，需制定详细的迁移方案及步骤；迁移时，需记录各个环节的关键数据，如迁移耗时、资源消耗情况等；迁移后，需总结并输出迁移报告。

2）数据跑批：完整运行数据中台的全流程任务，包括数据抽取、加工、服务提供及应用展现，分析各层级模型任务的运行耗时以及对应时间段的资源情况，并不断优化、调整运行任务的启动和依赖关系，以达到最佳的配置。

3）数据验证：筛选核心关键指标、标签，进行数据准确性的验证，例如存量指标可与系统现有指标进行对比，增量指标则与模型设计内容逐层对比。

4）应用验证：对于对外服务接口类应用，联系应用方进行接口及数据的验证，并完成应用全流程的拉通，优化调用的频次及时间点；对于报表及专题分析类应用，验证报表数据与数据中台侧数据的一致性，以及测试前端页面、展现数据的性能。

2.历史数据重跑和测试

在试运行过程中，数据中台的指标或标签可能会因为业务侧的口径变更而进行历史数据的重刷动作。在这种情况下，要保证数据准确且可逆，有如下几点注意事项。

影响评估：评估业务变动涉及的模型，并形成清单列表。

数据备份：数据处理前，先备份当前状态下的数据。

口径调整：确认业务口径调整涉及的技术口径调整内容，并体现在模型设计文档的版本控制中。

数据验证：调整后，严格按照设计内容进行数据的验证和测试，并与业务侧达成一致，在测试环境中进行确认。

5. 持续运营

数据中台不是一锤子买卖，是需要持续经营的。在数据中台正式上线后，随着企业业务的不断拓展，会接入更越来越多的数据源，数据的分析也将越来越精细，数据应用场景会更加丰富多样。同时，某些数据应用会因为企业业务方向的调整而废弃，这些已经过时的应用就需要及时清理。作为数据中台的建设者，不仅需要定期与数据使用者主动沟通，了解数据使用情况，了解这些数据到底带来了什么价值，还要通过系统查看指标、标签、专题、应用 API 这些资产的被调用情况，以此来判断是否需要优化等。

1.正式上线

试运行稳定执行一段时间后，可按模块和迭代申请生产环境的正式上线动作，以交付阶段性的工作成果。在正式上线时，分以下两步进行。

1）割接方案。如果数据中台存在替换现有其他系统的情况，就需要制定详细的割接方案，以保障数据中台能够覆盖旧系统的数据能力。2）上线预演。在正式上线前，需进行割接或上线的演练操作，尽可能多地暴露数据、环境、资源等各方面的问题，并逐步进行优化和调整。

系统上线后，制定相关的检查规则及告警机制，以保障数据中台的正常运行。检查规则可大致分为如下两类。

数据规则：数据一致性，主键唯一性，数据完整性。

资源规则：服务器资源，如 CPU、I/O 等；存储告警规则。

检查规则执行完成后，根据检查结果制定告警策略，如异常告警阻断、异常告警不阻断。同时，通过短信、邮件等方式将检查的结果进行告知，并制定告警升级机制。

2.运营保障

系统上线以后，跟进系统的运行、使用情况，综合分析以提炼新的需求点，创造更大的价值点，持续运营。数据中台的运营策略可从产品、应用、数据三方面进行。

产品侧：收集直接使用方的产品体验状况，根据反馈内容进行优化，提高产品的易用性，增强使用方对产品的黏性。

应用侧：分析应用对象的重点关注模块，并阶段性地形成分析报告。中台建设者可根据报告内容，对接应用相关人员，持续挖掘新的需求内容，持续耕耘以创造更大的价值。

数据侧：通过数据链路跟踪的结果，总结阶段性重点关注的数据内容。结合自上而下和自下而上两种途径，分析整个系统数据层面的缺口，并制定汇聚、扩建的计划，提高中台数据支撑的力度。

以上内容摘自《中台实践：数字化转型方法论与解决方案》一书，经出版方授权发布

数据中台建设五步法：

第一步：数据资源的盘点与规划：启动过程组

数据化的基础是信息化或者信息化所产生的数据。这些数据本就有数据化的含义，同时这些数据又会进入数据化框架体系，继续通过计算产出更多的数据和更大的价值。所以，对企业数据资源的盘点是数据化建设的前提和基础。一份完整、准确的数据资源是后续数据化建设的有力保障。

数据资源的盘点与规划需要达到以下目的：

（1）梳理现状：对现有数据资源盘点和统计。

（2）整体规划：对企业可以拥有或者应该拥有的数据资源进行规划。

（3）回顾复盘：构建盘点体系并使用必要工具，保证盘点的成果能够始终与真实情况相符。

第二步：数据应用规划与设计：规划过程组

企业要基于现有的技术条件和方案，进行相对完整的数据应用规划。这个步骤可以回答如下问题。

企业中有哪些数据需求：我们要从业务线、业务层级到最细粒度的岗位，梳理数据需求。

企业应该构建哪些数据应用：我们要围绕数据需求进行数据应用的整体规划和设计。

应该按照什么顺序实现这些数据应用：我们要对数据应用建立评估模型，评估的维度包括数据应用是否可以实现、数据应用的业务价值、数据应用的实现成本这三个主要方面。通过评定结果，我们可以确定数据应用的实现路径。

第三步：数据资产建设：规划过程组、执行过程组

数据资产的建设要依托数据中台的核心产品完成。数据资产是企业数据化建设的关键基础。所有的数据化建设最后都以数据资产为基础，并且围绕这个基础展开。数据资产将是企业在全面数据化建设前期中投入最多、见效最慢的基础层模块。关于数据中台的种种探讨和争议以及妥协的很大一部分原因是这个基础建设庞大、复杂和投入高。

数据资产建设的内容包括以下几个方面：

技术建设

（1）产品选型。产品选型包括如何选择数据中台产品、数据中台产品应该具备的功能以及技术参数指标。

（2）技术架构设计。技术架构设计包括数据中台产品如何部署、如何替换传统的数据仓库或者与之并行、数据中台如何抽取当前的应用数据。

标准和数据仓库模型构建

（1）建模及开发规范。建模及开发规范包括数据仓库模型设计规范的制定，数据开发规范的制定，如何避免当前较为常见的数据开发混乱、难以运维的情况。

（2）数据建模。数据建模包括进行数据仓库模型构建，并提交评审。

数据抽取、数据开发、任务监控与运维

（1）数据抽取。数据抽取包括从数据资源层抽取数据进入ODS层。

（2）数据开发。数据开发包括进行数据任务开发，进行数据清洗、数据计算。

（3）任务监控与运维。任务监控与运维包括监控所有数据任务，对异常和错误任务进行必要的人工干预和处理。

数据质量校验

数据质量校验包括对当前发现的数据质量问题进行校验和处理，推动数据治理工作开展和持续优化。

数据应用支撑

数据应用支撑包括为当前的数据应用开发提供支撑开发平台。

第四步：数据应用的详细设计与实现：执行过程组、监控过程组、不断优化、持续改进

不管是使用瀑布模型还是敏捷模型，数据应用的设计大体上都可以遵循传统信息化应用设计的过程和理念。数据应用中的数据开发一般在数据库或者数据仓库中完成。数据应用的内容展示可以采用BI分析工具展现，例如可视化大屏或者定制化开发应用。数据应用还可以通过API接口服务提供数据成果，让其他外部应用按需调用。数据应用的开发与传统信息化应用的开发有以下不同之处。

数据应用关注数据源的内容和质量：数据质量

我们在数据应用实施前应该充分了解企业当前的数据源情况，包括数据种类、每种数据的具体属性、数据内容的质量等问题。大部分落地失败的数据应用，都是由数据源的各种问题引起的，比如数据缺失或者数据质量问题。

复杂的数据开发需要不断调优和迭代

随着机器学习、深度学习等算法的引入，数据模型的构建手段越来越丰富。但是在通常情况下，最终业务价值的产生是一个复杂的过程，不仅需要数据的支撑，还需要管理的配合。

数据应用的结果数据的验证工作量占比高

论证数据结果的正确与否或者评估数据应用的效果，是一项费时、费力的工作。即使相对简单的指标计算，最后也经常会占用全部过程中1/3以上的时间进行正确性验证。甚至很多算法类项目，需要提前构建成果评估模型，并首先获得甲方企业的认可，然后才能开始进行数据开发。

数据应用的运维难度大

因为数据中的各种异常情况往往是不可知或者意想不到的，所以数据运维需要有强大的人工保障，以保持任务的运转。

数据应用的成果需要运营

数据应用的开发完成只是数据发挥价值的第一步，如何让业务部门理解模型、用好数据才是后续的关键。尤其是在刚刚引入新的数据，且尚未显现业务价值的时候，企业更需要对数据进行深入运营。

第五步：数据化组织规划

企业数据化应该是在未来一个时期内具有企业战略高度的事情，数据化需要一个具有同等战略高度的组织负责推进。无论是从传统的IT部门转型还是由战略部门或者类似部门介入都是很好的选择。组织是保障数据中台顺利落地的一个核心，也是推动企业数据化进程的人员抓手。

四、总结

“数据中台是实现企业全面数据化的一个解决方案，是一套支撑企业全面数据化的架构，会成为企业开展全面数据化的基础设施。”如果用技术语言总结就是：“前台聚合，中台解耦，数据融合，业务创新”。

随着大数据和人工智能的进一步普及，几乎所有的传统企业都在拥抱并推动自身数字化转型。作为一本数据中台实践，内容基本上覆盖了企业数字化实战的方方面面，对方法论、实施路径、平台、数据应用等方面都有阐述，有着一定的借鉴价值。

（以上内容摘录自网络，如有侵权请联系删除）