中台实践：数据中台构建五步法

1 数据中台构建五步法

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

图 4-6　数据中台建设五步法

1.1高阶规划

万丈高楼平地起，规划阶段之于数据中台建设，就相当于构建一座水库前的勘察和分析，了解建水库目标、水源、蓄水、水库下游，为设计图纸提供基础支持。同样建设数据中台也需要对企业的数据源、存储数据的方式、数据服务诉求等信息进行摸查，构建未来的蓝图。对现状和将来了解得越清楚，对数据中台的轮廓就了解得越清楚，数据中台的成功就越有保障。数据中台规划阶段可细分为业务架构师主导的业务规划和数据架构师主导的数据规划。这两部分内容是相辅相成的，由业务规划进行业务输入，由技术规划对数据现状进行探查，判断业务规划蓝图的可行性，最终形成可行的蓝图规划与应用设计。

1.业务规划

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

（1）业务调研

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

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

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

表 4-1　数据推导过程

（2）蓝图设计

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

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

（3）应用设计

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

2.技术调研

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

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

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

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

3.系统和数据调研

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

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

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

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

4.总体规划输出

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

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

1.2系统设计

在盘点了企业当前的数据应用需求及数据资产情况，并根据实际情况规划了数据中台的建设路径后，我们就可以进入非常重要的系统设计环节了。系统设计包含总体设计、数据设计及平台设计。

1.总体设计

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

图 4-7　总体设计

（1）数据架构

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

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

（2）平台架构

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

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

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

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

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

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

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

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

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

2.数据设计

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

图 4-8　数据设计

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

结构化数据一般以二维形式存储在关系型数据库中，对于这种数据类型，数据集成有 3 种方式。直连同步：通过规范的 API（如 JDBC）直接连接业务库。但是业务库直连的方式对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能。即使业务数据库存在备库，当数据量较大时，此种抽取方式性能也较差，不太建议使用。

数据文件同步：通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文件，由专门的文件服务器（如 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 所示。在通过场景梳理编排出算法实现逻辑后再开始设计算法模型及实现逻辑。

图 4-9　推荐场景

（3）服务详设

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

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

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

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

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

3.平台设计

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

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

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

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

1.3

开发实施

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

1.环境搭建

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

2.数据集成

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

3.代码研发

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

1.4试运行

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

1.中台试运行

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

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

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

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

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

2.历史数据重跑和测试

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

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

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

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

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

1.5

持续运营

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

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

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

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

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

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

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

2.运营保障

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

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

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

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