数据中台从规划到落地的5个阶段

系统都是为应用而生的，数据中台也不例外。要构建一套数据中台服务于企业内部和外部运营，需要有成熟的建设方法论作为指导。数据中台建设方法论可分为高阶规划、系统设计、开发实施、试运行和持续运营 5 个阶段。

01 、高阶规划

1. 业务规划
业务规划分为三个步骤：业务调研、蓝图设计和应用设计。
（1）业务调研业务调研主要包括以下两方面。 第一，战略与组织解读。企业战略决定了数据中台的上限，也决定了企业对数据中台的期望与目标。因此，通过明确企业战略对企业运营提升的要求，可以明确企业数字化优化的目标与范围。。 第二，调研访谈。调研访谈是通过问卷或针对性访谈的形式，对业务专家进行调研。在调研的过程中可以通过收集报表、报告、系统建设材料等信息辅助理解业务。
（2）蓝图设计通过业务调研了解企业，结合数据现状与业务痛点，将企业不同实体的数据进行提炼、抽象，形成数据域，将数据资产按照一定的体系进行规整，再结合业务诉求对数据分析场景进行提炼，最终形成一张囊括企业数据现状与未来的蓝图。
（3）应用设计 衔接蓝图设计，结合数据调研的成果判断数据可行性后，将数据分析场景、智能应用进行系统落地的可视化设计，形成 PRD 文档和原型进行产品设计与说明。
2. 技术调研
技术调研是对企业的 IT 整体现状进行摸查，调研内容包含企业主要业务及核心业务系统、信息安全相关要求等。 对企业主要业务和核心业务系统的调研包括业务和技术两个方向。业务上梳理企业的主要业务及核心业务流程，技术上则梳理各业务系统及它们之间的数据流转关系。通过信息安全相关的调研了解企业内与信息安全相关的组织部门、规章制度等信息和要求，为后续制定数据处理和使用的流程规范提供依据。
3. 系统和数据调研
系统与数据调研的目的是厘清企业数据资源的种类、分布、存储及管理现状。系统与数据调研是按业务系统进行盘点的。 业务流程及动作的调研，需要从使用者的角度出发，确认业务系统每个原子操作产生了哪些数据，数据存储在哪些数据表中。数据源盘点需关注数据源种类，如结构化、半结构化和非结构化数据，以及链接地址、账号、密码、可抽取数据的时间段等；数据表级别关注是否为核心表、时间戳字段、数据更新标识、表的总数据量、日增数据量等信息。 系统与数据调研完后，需输出相应的产出物，并与业务系统的相关人员就输出物中的产出项进行沟通和确认。
4.总体规划输出
规划阶段包含业务侧和技术侧的调研，可以并行开展。在业务侧完成调研及需求规划后，技术侧需要结合业务侧的产出进行相关的数据探查事项，主要目的是确认调研产出是否足够支撑业务规划的数据应用建设。总体规划在最终定稿后，业务侧需输出指标、标签清单、数据应用规划文档等，而技术侧需输出技术和系统调研的相关输出物，以及系统调研阶段的总结性报告。
02 、系统设计
系统设计包含总体设计、数据设计及平台设计。1.总体设计（数据架构、平台架构和研发规范）第一阶段的规划工作完成后，进入总体的架构设计阶段。由阿里巴巴提出的 OneData 的核心思想是统一数据主体、统一数据建模、统一数据服务以及一系列的数据管理体系。在设计阶段，可以参考这几个方面进行考虑与架构。如下图所示。
（1）数据架构数据中台的数据架构设计是基于需求调研阶段的业务需求、数据情况，完成数据中台概要设计工作。数据架构设计主要包含 OneModel 、OneID 和 OneService 。
1. OneData
数据中台就是要在整个企业中形成一个公共数据层，实现数据的复用，所以强调数据只加工一次，不会因为不同的应用场景造成数据重复加工。
如何实现：数据划分主题进行管理：表的命名，字段的命名等规范统一，做到见名知义数据格式和字段命名和定义规范化：具体参考离线数仓项目讲解的表和字段命名规范：数仓分层-业务主题域-业务过程-基础信息-分区规则指标一致：提供全局数据字典确保意义一致。
数据模型复用：推荐采用分层的设计方式，通常包括：ODS，DWD，DWS，ADS / DM，DIM。数据完善：数据中台尽可能的覆盖到所有业务过程，用户和系统的一切行为都被记录下来永久保存OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。OneModel 可分为以下四部分。
业务板块：根据业务的特点和需求将相对独立的业务划分成不同的业务板块，不同业务板块之间的指标或业务重叠度较低。数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。数据域划分上，需要从三个方面进行考虑。
1）全局性：站在企业高度上，保障良好的扩展性和稳定性。
2）数量适中：根据业务情况，划分的粒度要粗细合适，通常在 5～15 个。
3）可理解：站在业务的角度上，确保划分便于理解，不产生歧义。在划分数据域时，既要涵盖当前所有业务的需求，也要考虑有新业务的弹性扩展。
总线矩阵：在进行了充分的业务调研和需求调研后，就要构建总线矩阵了。总线矩阵由业务处理过程和维度组成一个二维表格。在行为不同的业务处理过程与维度的交叉点上打上标记，表示该业务处理过程与该维度相关。
数据分层：数据模型以维度建模理论为基础，建设数据中台的公共数据层。一般将数据模型划分为操作数据层（ODS）、通用数据模型层（CDM）和应用数据层（ADS）。OneID 功能包含以下四部分。
OneID 配置：主要根据具体的业务需求，完成数据源表、ID 映射表、歧义规则表的设置工作。
OneID 数据处理：主要通过数据源表和 ID 映射表等配置表单完成原始数据的数据拉取和清洗等操作，生成基础数据。
OneID 规则计算：主要利用图计算框架完成关键连接点的搜索和歧义数据的图连通工作，并根据配置的规则对图数据进行切割，从而唯一确定一个实体的身份信息，生成 OneID。
OneID 数据存储和展示：主要完成 OneID 图数据存储和展示，以及最后生成的 OneID 清单数据存储等。
OneService 统一数据服务OneService 包括以下功能模块：服务单元设计、API 设计、API 审核和 API 运营。服务单元设计是指将单个或多个物理表配置成一个视图。基于配置好的服务单元，通过简单可视化界面或 SQL 脚本，设计 API 的请求参数和返回参数。API 设计好后，将其发布至服务市场供使用者调用。API 在被使用前，需要经过申请审批。被使用的 API 需要运维及监控，包括平均响应时长、调用次数、错误率等指标的监控，还可以配置 API 的告警及限流措施等。
（2）平台架构结合前期调研的业务需求和数据现状，从宏观层面规划出数据中台的各个模块、各个功能部件所用到的技术总体架构图。
采集架构：数据采集打通各种数据来源，为数据中台提供待分析和处理的数据，主要分为实时和离线数据采集。
存储架构：整个存储架构包含原始数据源存储技术、数据源接入技术、数据中台数据存储与计算技术、数据服务及数据应用技术。
数据流：从业务数据进入数据采集通道，到进入数据中台在各个加工任务中流转，再到数据对外服务的这个过程，需要进行哪些存储、哪些技术处理等，这些步骤需要在设计时就以数据流向用流程图的形式画出。
网络架构：数据中台涉及与多方的源系统进行数据交互，而网络设计对于后续数据同步、接口调用等有较大影响。
部署架构：这部分设计主要涉及数据中台的研发平台与应用软件。需包含整体的部署方案。
安全架构：主要包含研发平台的用户角色权限控制方案、开发与生产环境隔离方案、数据安全方案。
（3）数据模型设计规范与标准良好的数据模型可方便、有效地组织数据中台中存储的企业数据资产，所以数据模型的设计工作有必要遵循一定的规范和约束。
2. 数据设计 （数据集成、模型设计和服务详设）数据设计包括数据集成、模型设计和服务详设，如下图所示。
（1）数据集成数据集成需要解决不同源系统数据异构性问题。结构化数据一般以二维形式存储在关系型数据库中，对于这种数据类型，数据集成有 3 种方式。
直连同步：通过规范的 API（如 JDBC）直接连接业务库。但是业务库直连的方式对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能，此种抽取方式性能较差，不太建议使用。数据文件同步：通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文件，由专门的文件服务器加载到数据中台。但由于要保证数据文件的完整性，通常除数据文件外，还需要上传校验文件，供下游系统做数据校验。
数据库日志解析同步：这种方式实现了实时与准实时同步，延迟可以控制在毫秒级别，并且对业务系统的性能影响比较小，目前应用较为广泛。除了数据读取的方式，还可按数据量来分解数据集成策略。
小数据量同步：数据记录小于 10 万条的源表建议每日全量更新，写入全量分区表。全量分区表可按天创建。可根据业务需要设置数据的生命周期，并定时清理。
大数据量同步：数据记录大于 10 万条的源表通过时间戳抽取增量数据到增量分区表。增量分区表可设置长周期，根据需要设置冷、温、热数据区。非结构化数据一般没有固定的结构，各种文档、图片、视频、音频等都属于非结构化数据。对于这类数据，数据集成策略通常是直接整体存储，而且一般存储为二进制的数据格式。除了结构化数据和非结构化数据，还有半结构化数据，常见的数据格式有 JSON 和 XML。对于半结构化数据，数据集成策略同样可以是直接整体存储。但随着数据技术的发展，NoSQL 数据库已经可以很好地支持半结构化数据的存储。NoSQL 主要有 4 种模型。
键值模型：键值模型在表现形式上比较单一，但却有很强的扩展性。
列式模型：由于每列可以动态扩展，列式模型相比键值模型能够支持的数据更为复杂。
文档模型：文档模型对于复杂数据的支持和在扩展性上都有很大优势。
图模型：使用场景通常基于图数据结构，如社交网络、推荐等。
（2）模型设计数据模型可以分为主题域模型、标签模型和算法模型。主题域模型是基础，是对数据标准化、规范化的过程。标签模型基于主题域模型将对象的各种标识打通归一，将跨业务板块、跨数据域的对象组织起来。算法模型基于主题域模型，将各对象的历史行为、属性等数据作为输入，利用算法能力分析和预测对象的行为。主题域模型设计。主题域模型也就是大家常说的数仓模型，最权威的数仓模型设计是 Kimball 的维度建模。阿里巴巴基于维度建模，沉淀了 OneModel 方法论。主题域模型可分为以下三层。
操作数据层（Operational Data Store，ODS）：主要将业务系统、日志等结构化和半结构化数据引入数据中台，保留业务系统原始数据。ODS 分为缓冲区和数据服务区。缓冲区保证 ODS 能原样引入所接入的源数据，不进行任何类型转换。数据服务区是对缓冲区数据进行类型转换或增量合并处理后得到的，为通用数据模型层和应用数据层提供数据服务。引入缓冲区是考虑到数据引入后可能会有一些特殊的处理需求，比如JSON 格式数据，需要在解析后再引入。
通用数据模型层（Common Data Model，CDM）：包含整个数据中台的大部分数据，是数据中台的基础，因此保证该层数据的健壮性是重中之重。主要完成公共数据加工与整合，建立一致性的维度，构建可复用、面向分析和统计的明细事实表及汇总事实表。
应用数据层（Application Data Service，ADS）：提供直接面向业务或应用的数据，主要对个性化指标数据进行加工处理；同时为方便满足数据应用、数据消费的诉求，进行面向应用逻辑的数据组装，比如大宽表集市、横表转纵表、趋势指标串等。
标签模型设计。企业的重要数据资产，如客户、商品、门店、供应商、员工等实体的标签模型都是数据中台加工的重点。比如，先获取商品的生产、采购、定价、销售、退货等历史行为数据，然后按照业务场景需要来制定商品所涉及的商品标签，形成商品标签模型。
算法模型设计。数据中台整合全域的数据，需要通过 AI 算法将宝贵的数据形成有价值的数据资产。算法模型是最能将企业的数据资产发挥出几何倍数价值的模型。例如，凭借商品个性化推荐模型，淘宝的“千人千面”场景帮助用户极大提升了体验感。
（3）服务详设数据服务按数据内容可分为主题分析类数据服务、标签类数据服务和算法类数据服务。主题分析类数据服务可通过整合数据分析场景，分专题设计通用的数据汇总宽表，通过数据宽表拼写不同的 SQL，支撑相应的数据报表，避免数据的冗余建设。标签类数据服务的设计却有所不同，切忌按照标签使用场景逐个进行数据服务设计。
因为运营可能会随时增加标签，迫使在设计标签服务时考虑通用性和扩展性。一般建议以底层的标签宽表为出发点，设计标签通用的增加、修改和查询功能。与业务联动紧密的算法类数据服务则需要注意可能直接面对低延迟、高并发的调用场景，比如推荐场景，包括搜索推荐、猜你喜欢、加购推荐等，一定要做好服务接口的性能压测，以满足业务实时交易级的性能要求。除了考虑服务的通用性和性能，还需要考虑服务开放的数据安全性。
3. 平台设计（资源规划、技术选型、部署方案）平台设计指的是大数据运行平台在资源规划、技术选型、部署方案等方面的设计。台设计阶段将以客户现有数据体量及可预测的业务增长情况作为考量因素，对平台建设所需的资源进行预估和规划，产出平台及数据应用部署所需的资源清单、部署方案及相关人员在平台上的账号和权限的设计等。
1、资源规划需要对支撑大数据平台所需的资源进行估算。一般可考虑未来 3 年企业的数据量。数据中台架构应该具备的能力：
1、基础设施/基础平台、存储引擎、计算引擎、辅助服务
2、数据集成
3、数据开发
4、工作流调度
5、数据治理：数据质量、元数据管理、数据安全
6、数据可视化
7、DevOps
6、其他数据服务
2、技术选型：大数据技术选型的原则是考虑当前及未来一段时间可能使用的场景，根据场景来推导技术的选择。03 开发实施开发实施阶段可分为环境搭建、数据集成、代码研发三个层面。
1. 环境搭建
平台层面的环境搭建，包括大数据集群、数据研发平台、智能数据应用产品等相关工具的部署。平台的搭建按设计阶段输出的资源规划和平台部署方案实施即可。部署后，需要对平台环境进行测试，同时在产品工具层面，需要对企业进行相关产品的使用培训。
2. 数据集成
数据集成方案从宏观上设计和规范了数据源级别的数据集成流程和同步策略。在当前阶段，需要对各数据源制定表级别的集成策略，形成数据同步清单，包括上云数据存量、日增量、数据更新频率等相关信息，供具体实施时使用。实施后，还需要逐一对数据源表进行数据监控及验证。
3. 代码研发
代码研发阶段包括数据研发与验证、应用研发与测试、性能测试三部分。数据研发与验证主要包括数据模型的业务代码开发、数据监控代码开发、数据准确性验证。研发与测试主要包括数据应用层面的开发和测试工作，如数据服务、数据应用前端开发。性能测试包括数据产出时间、数据接口服务性能等方面的测试。
04 试运行
数据中台上线之后，分析专题的指标口径、数据应用效果等多方面的数据准确性都需要通过真实的运行数据去验证。通常需要进行一段时间的试运行。
1.中台试运行
为保障生产环境数据的准确性，需要先在测试环境基于企业全量的数据进行一段时间的试运行，主要包含以下步骤。
1）数据迁移：增量模型涉及的存量数据需进行一次全量的数据迁移，以保证数据的完整性，全量模型则直接按频度进行抽取即可。
2）数据跑批：完整运行数据中台的全流程任务，包括数据抽取、加工、服务提供及应用展现，分析各层级模型任务的运行耗时以及对应时间段的资源情况，并不断优化和调整。
3）数据验证：筛选核心关键指标、标签，进行数据准确性的验证，例如存量指标可与系统现有指标进行对比，增量指标则与模型设计内容逐层对比。
4）应用验证：对于对外服务接口类应用，联系应用方进行接口及数据的验证，并完成应用全流程的拉通，优化调用的频次及时间点。
2.历史数据重跑和测试
在试运行过程中，数据中台的指标或标签可能会因为业务侧的口径变更而进行历史数据的重刷动作。在这种情况下，要保证数据准确且可逆，需注意以下事项。影响评估：评估业务变动涉及的模型。数据备份：数据处理前，先备份当前状态下的数据。口径调整：确认业务口径调整涉及的技术口径调整内容，并体现在模型设计文档的版本控制中。数据验证：调整后，严格按照设计内容进行数据的验证和测试，并与业务侧达成一致，在测试环境中进行确认。
05 持续运营
在数据中台正式上线后，随着企业业务的不断拓展，会接入更越来越多的数据源。同时，某些数据应用会因为企业业务方向的调整而废弃，就需要及时清理。作为数据中台的建设者，不仅需要定期与数据使用者主动沟通，了解数据使用情况，还要通过系统查看指标、标签等资产的调用情况，以此判断是否需要优化。
1.正式上线
试运行稳定执行一段时间后，可按模块和迭代申请生产环境的正式上线。正式上线时，分以下两步进行。
1）割接方案。如果数据中台存在替换现有其他系统的情况，就需要制定割接方案，以保障数据中台能够覆盖旧系统的数据能力。
2）上线预演。在正式上线前，需进行割接或上线的演练操作，尽可能多地暴露数据、环境、资源等各方面的问题。系统上线后，制定相关的检查规则及告警机制，以保障数据中台的正常运行。大致分为如下两类。数据规则：数据一致性，主键唯一性，数据完整性。资源规则：服务器资源，如 CPU、I/O 等，以及存储告警规则。
2.运营保障
系统上线以后，跟进系统的运行情况，综合分析以提炼新的需求点。运营策略可从产品、应用、数据三方面进行。产品侧：收集直接使用方的产品体验状况，根据反馈内容进行优化，提高产品的易用性，增强使用方对产品的黏性。应用侧：分析应用对象的重点关注模块，并阶段性地形成分析报告。中台建设者可根据报告内容，对接应用相关人员，持续挖掘新的需求内容。数据侧：通过数据链路跟踪的结果，总结阶段性重点关注的数据内容。结合自上而下和自下而上两种途径，分析整个系统数据层面的缺口，并制定汇聚及扩建计划，提高中台数据支撑的力度。