2.2 经典数据中台解决方案
为了满足业务经营分析、精细化运营、辅助决策和驱动业务等方面的需求，企业通过搭建平台来实现对应功能，从而满足经营管理者、业务用户、数据工程师、数据科学家和客户的使用需求。由此，数据中台应运而生。数据中台并不是一个具体的产品，而是一个解决方案，包括技术平台、数据建模、数据治理3个部分。经典数据中台解决方案如图2.2所示。
图2.2 经典数据中台解决方案
2.2.1 技术平台
技术平台涵盖数据开发和使用过程，通过提供统一的集成开发环境来降低数据工程师、数据科学家及数据分析师开发和使用数据的门槛。技术平台的主要功能如图2.3所示。
图2.3 技术平台的主要功能
● 业务数据源：主要包括结构化、半结构化和非结构化三大类。结构化数据源主要存储在MySQL、Oracle和HBase等数据库中；半结构化数据主要是各种日志数据，包括客户端日志、服务器端日志和联网设备日志等；非结构化数据主要是各种文本数据、声音数据和图像数据。
● 离线数据处理：主要包括批量数据集成、离线计算引擎和交互式分析引擎。批量数据集成主要通过接入数据库、Excel/CSV/JSON文件和数据传输协议等，利用ETL 工具[1]进行数据抽取、转换和加载；离线计算引擎主要支持在大规模数据集上进行复杂的数据转换、聚合和分析，并且通过任务调度将计算的结果进行持久化保存；交互式分析引擎支持使用SQL代码直接读取、查询数据。
● 实时数据处理：主要包括实时数据采集、流计算引擎和交互式分析引擎。实时数据采集通过数据库订阅、消息队列、日志文件监控、WebSocket等方式，对采集到的实时数据进行数据清洗、格式转换和字段提取等操作；流计算引擎对实时数据流进行处理，确保高吞吐量和低延迟，支持基于事件时间的处理、状态管理和容错恢复，能完成数据流的转换、聚合、过滤、窗口操作等实时计算任务；交互式分析引擎支持使用SQL代码对存储的实时数据进行实时分析和应用。
● 数据挖掘：主要包括大数据研发平台、机器学习平台、分析和商务智能平台。大数据研发平台提供一站式的数据开发功能，包括数据处理与计算、数据存储与管理、资源管理与调度，以及运维与监控等；机器学习平台能够高效地开发、训练和部署机器学习模型，主要功能包括数据准备与管理、模型开发与训练、可视化、协作与共享，以及模型部署与服务化；分析商务智能平台能够简化和加快数据分析和决策的过程，主要功能包括数据整合与准备、数据可视化与报表生成、自助式分析与查询，以及数据探索与发现等。
● 数据应用：主要包括应用程序接口（Application Program Interface，API）、软件开发工具包（Software Development Kit，SDK）、实时数据服务和场景分析应用。API支持通过编程方式获取、处理和管理数据；SDK提供了封装、抽象和便捷的方式来集成和使用数据服务；实时数据服务是指通过API、SDK等提供实时数据访问、分析、处理等服务；场景分析应用是指对特定场景的数据进行分析和挖掘，并且以交互式界面的方式封装成业务人员可直接使用的应用。
[1]ETL即抽取（Extract）、转换（Transform）、加载（Load）。ETL工具是一种用于数据集成和处理的软件。——编者注
2.2.2 数据建模
数据建模通常包含数据标准、概念模型和物理模型3个方向的工作。
● 数据标准：保障在内部和外部使用和交换数据时的一致性和准确性的规范性约束。数据标准有助于提升数据质量、厘清数据构成、打通数据孤岛、加快数据流通和释放数据价值，对业务数据的使用有着至关重要的作用。
● 概念模型：对业务实体的描述，通常由业务人员和数据架构师创建，用于标识用户在现实世界中看到的数据。概念模型用于规划数据治理主题，梳理业务对象之间的关系，以及指导系统建设。注意，本书将逻辑模型的细化过程也纳入概念模型的范畴。
● 物理模型：对真实数据库的描述，包括属性定义、数据类型和索引等。物理模型通常由开发人员和数据库管理员（Database Administrator，DBA）创建，解决了数据存储和系统性能等技术问题。
1．数据标准
常见的数据标准定义过程如图2.4所示。接下来，按照从上到下、从左到右的顺序，对图2.4中的核心环节进行阐述。
图2.4 常见的数据标准定义过程
● 业务板块：逻辑空间的重要组成部分，也是基于业务特征划分的命名空间，可依据独立的运营体系进行划分。
● 数据域：将业务过程或维度进行抽象的集合，也是对业务对象高度概括的概念归类，其目的是便于数据的管理和应用。
● 维度实体：用来反映业务的一类属性，通常包括基础维度、维度属性和派生维度。维度实体具有业务主键这种唯一性标识，确保与之相连的各个事实表之间存在引用完整性的根本保障。
● 业务过程：企业业务的活动事件，用以描述实体与实体间的关系，通常可以概括为不可拆分的行为事件。
● 业务限定：在构建派生指标的过程中，对原子指标进行特定的描述性修饰，通常通过一个逻辑表达式来限定指标的统计范围。业务限定也需要进行一定的通用性抽象，从而尽可能地复用，改善数据标准的一致性问题，大幅提升研发工作的效率。
● 基础维度：用来反映业务的一类属性，这类属性的集合构成一个维度，如产品维度的产品大类、产品小类和所属生产线等。
● 维度属性：用以查询约束条件、分组和标签生成的基本来源，是数据易用性的关键，如产品名称、产品规格等。
● 度量：用来衡量业务指标的具体数值，通常为数字型，随着业务过程记录并存储，例如销售下单过程中的订单金额。
● 原子指标：在某业务事件行为中所使用的度量，是业务定义中不可再拆分的指标，具有明确的业务含义。原子指标通常通过业务过程（动作）和度量计算得来，或者通过基础维度和计数方法获得，例如销售下单过程中的原子指标就是订单金额。
● 时间周期：数据统计的时间范围或者时间点，例如最近7天、最近30天、自然周和截至当日等。
● 修饰词：对除了统计维度以外指标的业务场景进行限定和抽象（维度值），例如在日志域的访问终端类型下，修饰词有PC端、无线端等。
● 派生维度：通过维度属性添加统计区间计算得来，用于业务细分场景的分析，例如产品的价格区间通过计算产品价格得出。
● 派生指标：用户在业务需求中需要统计的指标。一个派生指标通常由一个或多个原子指标在不同的指标套件、不同的计算公式下组合而成，也可以理解为是对原子指标业务范围的限定。
2．概念模型
常见的概念模型的设计过程如图2.5所示。接下来，对图2.5中的三大模块（实体梳理、事件梳理和模型设计）进行详细阐述。
图2.5 常见的概念模型的设计过程
● 实体梳理：一般从企业的核心产品和服务价值流入手，从管理职能、岗位职责、业务领域和行业模型等方面来梳理数据域和实体。首先，根据企业的管理职能和岗位职责，整理出数据域目录；其次，对数据域内的实体进行剥离，通常分为客观实体和虚拟实体，客观实体为现实世界存在的对象，如人、设备、产品、生产线等，虚拟实体为数字化对象，如组织、流程等；最后，对于一个数据域存在多个实体的情况，不论是客观实体还是虚拟实体，都以实体为最小单位进行拆分。
● 事件梳理：一般通过业务流程详细调研，梳理数据流与事件（业务过程）的关联关系，再根据业务调研结果和行业模型抽取出全部事件。首先，将组合型的事件拆分成不可分割的行为事件。其次，按照业务分类规则，将拥有相似特征的事件分为一类，且每个事件只能唯一归属于一类。最后，进行事件、实体和关系梳理，明确每个数据域下有哪些事件以及事件与实体的关系，输出事件—实体总线矩阵，通过定义一个二维矩阵，对数据域下的事件与实体信息进行记录。
● 模型设计：一般通过数据探查做进一步的分析和模型细化，通过概念模型和行业参考设计更详细的数据实体和数据属性的描述，从而更好地指导系统的逻辑实现。首先，需要为每个数据实体定义特征和属性；其次，通过实体之间的关系，可以表达数据实体之间的依赖和联系，建立模型之间的一对一、一对多或多对多的关系；最后，根据事件的输入和输出来补充虚拟实体或者客观实体的属性，从而满足业务运行过程中数据记录和分析的要求。
3．物理模型
常见的物理模型的设计结构如图2.6所示。接下来，对图2.6中的各层进行详细阐述。
图2.6 常见的物理模型的设计结构
● ODS层：操作数据层（Operational Data Store，ODS），主要用于原始数据在数据平台的落地，提供基础原始数据，可减少对业务系统的影响。此类数据在数据结构、数据之间的逻辑关系上，都需要与原始数据保持一致。首先，考虑源数据的数据量，对于小数据量的表可以使用全量表的设计，对于大数据量的表可以使用增量表的设计；其次，考虑表的更新频率，需要根据业务应用的需求，采取实时更新、准实时更新、T+1更新的策略；最后，对于某些原系统设计不合理，需要考虑历史数据更新的情况，采取全量、增量、历史3个存储区来处理。
● DWD层：明细数据层（Data Warehouse Detail，DWD）包含了一系列由ODS层数据经过清洗、过滤和连接等操作后得到的规范化明细数据。首先，通过梳理原子指标和实体的对应关系矩阵，将相同粒度的原子指标整合到同一实体下面；其次，将ODS层中不同粒度的原子指标拆分成各自的实体；最后，筛选基于该表原子指标衍生出来的派生指标，判断派生指标的计算逻辑，若是由该表的原子指标组合而成且数据粒度仍能保持一致，则将筛选出来的符合该原则的派生指标放在DWD表中，作为新的列字段。
● DWS层：数据轻度汇总层（Data Warehouse Summary，DWS）按粒度、维度对明细数据进行统计汇总，为上层数据分析和算法应用生成公共指标。首先，将DWD表维度相同的指标，按照最明细的粒度，汇总到一张DWS表中；其次，对于高频使用的汇总维度，基于该DWS表进行聚合，产生新的粒度，从而形成新的DWS表；最后，若不同粒度的DWS层的指标被经常性地组合调用，则会把不同粒度的DWS表提前JOIN（连接），进行关联计算，形成冗余的DWS表。
● ADS层：应用数据层（Application Data Store，ADS）通常以业务场景或职能来划分主题域，此层数据一般需要从DWS层导出到OLAP数据库中，方便最终业务用户直接查询和使用。首先，ADS层通常按照业务应用的需求进行设计，需要按业务需求进行指标梳理；然后，从DWS层寻找是否有满足的指标，若有则直接查询获取，如果没有则需要加工DWS层指标以满足ADS层的需求；最后，对于个性化的、低频使用的指标，需要考虑穿过DWS层，直接从DWD层、ODS层获取设计。
2.2.3 数据治理
数据治理素有“三分技术、七分管理”的说法，前文讲到的技术平台、数据建模属于技术，想要进行高效和精准的数据治理，还需要流程、制度和组织的支撑。
国际上的数据治理架构有很多，但都大同小异。本节以数据治理研究所（DGI）的数据治理架构为例，详细阐述数据的建设与治理。DGI的数据治理架构如图2.7所示。
图2.7 DGI的数据治理架构
● 使命价值：对应图中的①部分。数据治理的使命与价值是对企业愿景和战略的分解，DGI给出的建议包括实现更好的决策、减少操作摩擦、建立标准可重复的流程、通过协调降低成本并提高效率、确保流程的透明度等。
● 治理目标：对应图中的②部分。治理目标指具体的受益对象（一般会设定为产品、服务、流程、能力和资产等）方面的KPI。
● 流程规范：对应图中的③④⑤⑥⑦部分。流程规范是数据治理的核心，主要包括数据产品、过程控制、流程职责与义务、决策方式、政策与规则等部分。此规范主要是确定数据治理的标准，落实标准的流程、保障流程执行的制度和规则。
● 平台工具：对应图中的⑧部分。一般指数据开发和使用的工具链，本书2.2.1节主要就是讲这部分的能力，可以通过平台来提高数据的开发和使用效率。
● 工作计划：对应图中的⑨部分。工作计划是关于如何协调和组织各数据治理相关角色、人员以及数据治理的不同生命周期，而制订的统一的项目工作计划。
● 人员和组织结构：对应图中的⑩部分。人员和组织结构给出了数据治理的建议，数据治理办公室（DGO）负责推动数据治理工作的落地。其中，“Big G”负责决策（批准数据治理体系），并将决策转化为行动；“little g”专注于执行，通过治理活动的管理与控制，增加数据资产的价值。