最近几年，数据中台概念的热度一直不减。2018 年起，马蜂窝也开始了自己的数据中台探索之路。

数据中台到底是什么？要不要建？和数据仓库有什么本质的区别？相信很多企业都在关注这些问题。

我认为数据中台的概念非常接近传统数据仓库+大数据平台的结合体。它是在企业的数据建设经历了数据中心、数据仓库等积累之后，借助平台化的思路，将数据更好地进行整合与统一，以组件化的方式实现灵活的数据加工与应用，以更清晰的数据职能组织应对业务的快速变化，以服务的方式更好地释放数据价值的一种方式。

所以，数据中台更多的是体现一种管理思路和架构组织上的变革。在这样的思想下，我们结合自身业务特点建设了马蜂窝的数据中台，核心架构如下：

在中台建设之前，马蜂窝已经建立了自己的大数据平台，并积累了一些通用、组件化的工具，这些可以支撑数据中台的快速搭建。

作为中台的另一大核心部分，马蜂窝数据仓库主要承担数据统一化建设的工作，包括统一数据模型，统一指标体系等。下面介绍马蜂窝在数据仓库建设方面的具体实践。

马蜂窝数据仓库遵循标准的三层架构，对数据分层的定位主要采取维度模型设计，不会对数据进行抽象打散处理，更多注重业务过程数据整合。现有数仓主要以离线为主，整体架构如下：

如图所示，共分为 3 层：业务数据层、公共数据层与应用数据层，每层定位、目标以及建设原则各不相同。

包含 STG（数据缓冲层）与 ODS（操作数据层）两层，这两层数据结构与业务数据几乎一致。

STG：也叫数据准备区，定位是缓存来自 DB 抽取、消息、日志解析落地的临时数据，结构与业务系统保持一致；负责对垃圾数据、不规范数据进行清洗转换；该层只为 ODS 层服务。

ODS：操作数据层定位于业务明细数据保留区，负责保留数据接入时点后历史变更数据，数据原则上全量保留。模型设计依据业务表数据变更特性采取拉链、流水表两种形式。

细分为 DWD（明细数据层）、DWS（汇总数据层）、DIM（公共维度层） 三层，主要用于加工存放整合后的明细业务过程数据，以及经过轻度或重度汇总粒度公共维度指标数据。

公共数据层作为仓库核心层，定位于业务视角，提炼出对数据仓库具有共性的数据访问、统计需求，从而构建面向支持应用、提供共享数据访问服务的公共数据。

DWD：这一层是整合后的业务过程明细数据，负责各业务场景垂直与水平数据整合、常用公共维度冗余加工，以及明细业务标签信息加工。

DWS：汇总数据层按照主题对共性维度指标数据进行轻度、高度聚合。

DIM：对维度进行统一标准化定义，实现维度信息共享。

DWA 层，主要用于各产品或各业务条线个性化的数据加工，例如商业化产品数据、搜索推荐、风控等。

数据模型是对现实世界数据特征的抽象，数据模型的设计方法就是对数据进行归纳和概括的方法。

目前业界主要的模型设计方法论有两种，一是数据仓库之父 Bill Inmon 提出的范式建模方法，又叫 ER 建模，主张站在企业角度自上而下进行数据模型构建；二是 Ralph Kimball 大师倡导的维度建模方法，主张从业务需求出发自下而上构建数据模型。

大数据环境下，业务系统数据体系庞杂，数据结构多样、变更频繁，并且需要快速响应各种复杂的业务需求，以上两种传统的理论都已无法满足互联网数仓需求。

在此背景下，马蜂窝数据仓库采取了「以需求驱动为主、数据驱动为辅」的混合模型设计方式，来根据不同的数据层次选择模型。主要从以下四个方面综合考虑：

其中，ODS 选择保持贴源的范式模型，不做进一步模型抽象，只是从节省存储角度考虑，对该层采取拉链处理。

DWD 与 DWS 基于对构建成本、性能，易用性角度的考虑，主要采取维度模型和一些宽表模型。

宽表模型的本质是基于维度模型的扩展，对整个业务以及全节点信息进行垂直与水平方式整合；同时采用退化维度的方式，将不同维度的度量放入数据表的不同列中，实现业务全流程视图的构建，来提升宽表模型的易用性、查询效率，且易于模型的扩展。

水平整合：水平整合就是将同一业务多数据源的数据整合到一个模型中，如果多数据源业务数据存在交集，则需要按照预设的业务规则选取一份保留，避免整合后的业务数据交叉。

例如商品数据如果未进行主数据管理，不同业务线的商品信息就会散落在各业务系统表中，无法满足企业级的数据分析需求，这时就需要将这些商品数据按照业务主题进行水平整合。

垂直整合：一次完整的业务流转通常要经历多个环节，各节点信息产生的时点不同、储存的数据表不同。垂直整合就是将同一业务中各关键节点信息整合至业务全流程宽表模型中。马蜂窝订单交易模型的构建就采用了这种方式，下文将进行详细介绍。

马蜂窝数据仓库在模型设计上以准确性、易用性、及时性为设计目标，以满足业务人员对数据的多样需求。

马蜂窝数仓模型设计的整体流程涉及需求调研、模型设计、开发测试、模型上线四个主要环节，且规范设计了每个阶段的输出与输入文档。

需求调研：收集和理解业务方需求，就特定需求的口径达成统一，在对需求中涉及到的业务系统或系统模块所承担的功能进行梳理后进行表字段级分析，并对数据进行验证，确保现有数据能够支持业务需求。

模型设计：根据需求和业务调研结果对模型进行初步归类，选择合适的主题域进行模型存放。

确定主题后进入数据模型的设计阶段，逻辑模型设计过程要考虑总线结构构建、模型规范定义等关键问题。

物理模型设计以逻辑模型为基础，兼顾存储性能等因素对逻辑模型做的物理化的过程，是逻辑模型的最终物理实现。物理模型在一般情况下与逻辑模型保持一致，模型设计完成后需要进入评审与 Mapping 设计。

模型开发：就是对模型计算脚本的代码实现过程，其中包含了数据映射、脚本实现、测试验证等开发过程。

单元测试完成后需要通知业务方一起对模型数据进行业务验证，对验证问题做收集，返回验证模型设计的合理性。

模型上线：完成验证后的模型就可以在线上生产环境进行部署。上线后需要为模型配置监控，及时掌握为业务提供数据服务的状况。

我们还将模型的实体和属性说明文档发布给仓库数据的使用者，使模型得到更好地应用。

基于对目前各个部门和业务系统的梳理，马蜂窝数据仓库共设计了 4 个大数据域(交易、流量、内容、参与人)，细分为 11 个主题：

以马蜂窝订单交易模型的建设为例，基于业务生产总线的设计是常见的模式，即首先调研订单交易的完整过程，定位过程中的关键节点，确认各节点上发生的核心事实信息。

模型是数据的载体，我们要做的就是通过模型（或者说模型体系）归纳生产总线中各个节点发生的事实信息。

订单生产总线：

如上图所示，我们需要提炼各节点的核心信息，为了避免遗漏关键信息，一般情况下抽象认为节点的参与人、发生时间、发生事件、发生协议属于节点的核心信息，需要重点获取。

以下单节点为例，参与人包括下单用户、服务商家、平台运营人员等；发生时间包括用户的下单时间、商家的确认时间等。

发生的事件即用户购买了商品，需要记录围绕这一事件产生的相关信息。

发生协议即产生的订单，订单金额、约定内容等都是我们需要记录的协议信息。

在这样的思路下，总线架构可以在模型中不断添加各个节点的核心信息，使模型支撑的应用范围逐步扩展、趋于完善。因此，对业务流程的理解程度将直接影响产出模型的质量。

涉及的业务节点越多，业务流程也就越复杂。从数据的角度看，这些业务过程会产生两种基本的场景形态，即数据的拆分和汇聚。

随着流程的推进，前一节点的原子业务单位在新节点中可能需要拆分出更多信息，或者参与到新节点的多向流程。同样，也可能发生数据的汇聚。

以某个订单为例，下单节点数据是订单粒度的，而到支付节点就发生了数据拆分。数据的拆分、汇聚伴随着总线的各节点，可能会一直发散下去。

鉴于上述情况，在模型实现过程中，我们不能把各节点不同粒度的数据信息都堆砌在一起，那样会产生大量的冗余信息，也会使模型本身的定位不清晰，影响使用。

因此，需要输出不同粒度的模型来满足各类应用需求。例如既会存在订单粒度的数据模型，也会存在分析各个订单在不同时间节点状态信息的数据模型。

基于维度建模的思路，在模型整合生产总线各节点核心信息之后，会根据这些节点信息进一步扩展常用的分析维度，以减少应用层面频繁关联相关分析维度带来的资源消耗，模型会反范式冗余相关维度信息，以获取应用层的使用便捷。

最终建立一个整合旅游、交通、酒店等各业务线与各业务节点信息的马蜂窝全流程订单模型。

为提升数据生产力，马蜂窝数据仓库建立了一套工具链，来实现采集、研发、管理流程的自动化。现阶段比较重要的有以下三大工具：

同步工具主要解决两个问题：

下面重点介绍从源系统同步数据到数据仓库。

马蜂窝的数据同步设计支撑灵活的数据接入方式，可以选择抽取方式以及加工方式。

抽取方式主要包括增量抽取或者全量抽取，加工方式面向数据的存储方式，是需要对数据进行拉链式保存，或者以流水日志的方式进行存储。

接入时，只需要填写数据表信息配置，以及具体的字段配置信息，数据就可以自动接入到数据仓库，形成数仓的 ODS 层数据模型，如下：

我们使用 Airflow 配合自研的任务调度系统，不仅能支持常规的任务调度，还可以支持任务调度系统各类数据重跑，历史补数等需求。

别小看数据重跑、历史补数，这两项功能是在选择调度工具中重要的参考项。

做数据的人都清楚，在实际数据处理过程中会面临诸多的数据口径变化、数据异常等，需要进行数据重跑、刷新、补数等操作。

我们设计的「一键重跑」功能，可以将相关任务依赖的后置任务全部带出，并支持选择性地删除或虚拟执行任意节点的任务：

如下是基于某一个任务重跑下游所有任务所列出的关系图，选中具体的执行节点，就可以执行忽略或者删除。

元数据范畴包括技术元数据、业务元数据、管理元数据，在概念上不做过多阐述了。

元数据管理在数据建设起着举足轻重的作用，这部分在数仓应用中主要有 2 个点：

1）血缘管理

血缘管理可以追溯数据加工整体链路，解析表的来龙去脉，用于支撑各类场景，如：

如下是某一个数据模型中的血缘图，上下游以不同颜色进行呈现：

2）数据知识管理

通过对技术、业务元数据进行清晰、详尽地描述，形成数据知识，给数据人员提供更好的使用向导。

我们的数据知识主要包括实体说明与属性说明，具体如下：

当然，数仓工具链条中还有非常多工具，例如自动化建模工具、数据质量管理工具、数据开发工具等，都已经得到了很好地实现。

有了合理的数仓架构、工具链条支撑数据研发，接下来，就要考虑如何把产出的数据对外赋能。

下面以马蜂窝数据应用利器-指标平台，进行简单介绍。

几乎所有的企业都会构建自己的指标平台，每个企业建立的标准都不一样。在这个过程中会遇到指标繁多、定义不清楚、查询缓慢等问题。

为尽量避免这些问题，指标平台在设计时需要遵循几大原则：

基于以上原则，马蜂窝的指标平台按照精细化的设计进行打造，指标平台组成架构如下图：

其中：

① 数据仓库是指标数据的来源，所有指标目前都是通过数据仓库统一加工的。

② 指标管理包括指标创建与指标元数据管理：数仓负责生产并创建最核心、最基础的指标。

其他人员可以基于这些指标，按照规则进行指标的派生。

元数据管理记录指标的具体来源路径，说明指标的数据来源是数仓表，或者是 Kylin，MySQL 或 ES。

③ 指标字典对外呈现指标的定义、口径、说明等，保证指标的透明化及可解释性。

④ 数据服务接受指标的查询请求，针对不同场景判断查询的成本，选择最优链路进行指标查询，并返回指标查询的结果。

⑤ 多维查询将可以提供查询服务的指标与维度通过界面呈现，用户可以基于维度选择指标或基于指标选择维度，查询具体需要的数据。

⑥ 权限管理贯彻始终，可以支持表级、指标级、维值级别的权限管理。

企业的数据建设需要经历几个大的步骤：

目前大部企业目前都停留在第二个阶段，因为这一步需要足够夯实，才能为第三步打好基础，这也是为什么各大企业要投入很大成本到大数据平台、数据仓库乃至数据中台的建设中。

马蜂窝数据中台的建设才刚刚起步。我们认为，理想的数据中台需要具备数据标准化、工具组件化、组织清晰化这三个核心前提。

为了向这一目标迈进，我们将建立统一、标准化的数据仓库作为当下数据中台的重点工作之一。

数据来源于业务，最终也将应用于业务。只有对数据足够重视，与业务充分衔接，才能实现数据价值的最大化。

在马蜂窝，从管理层，到公司研发、产品、运营、销售等各角色，对数据非常重视，数据产品的使用人数占公司员工比例高达 75%。

大量用户的使用，驱动着我们在数据中台建设的路上不断前进。

如何将新兴技术能力应用到数据仓库的建设，如何以有限的成本高效解决企业在数据建设中面临的问题，将是马蜂窝数仓建设一直的思考。