数据中台研发实践

转自：https://www.sohu.com/a/396680882_411876?scm=1002.44003c.17c024f.PC_ARTICLE_REC
作者：颜博，马蜂窝数仓研发总监

1、数据处理架构

下面是一个简单的数据处理架构演进过程：

最早数据仓库的计算只支持批处理，通常是按天定时处理数据，在后期逐步进化到准实时，本质上还是批处理，只是处理频度上得有提升，到小时级，或者15分钟这种。
随着技术不断进步，后期演化出一条新的流处理链路，这个链路和之前的批处理分别处理，然后在服务层面利用大数据的计算能力进行合并，向外提供离线+实时数据服务，这也是著名的lambda架构。
最近几年随着Flink等技术的发展，有一个趋势是流批一体化，在接入层统一采用流式接入，计算层采用统一套框架支持实时计算+离线计算，批处理仅仅作为流处理的一个特殊场景进行支持。整体上可以做到流处理、批处理的自由切换。
流计算和批处理在需求场景上有一些本质区别，前者主要用于支持线上业务场景（比如互联网的推荐、搜索、风控等），而批处理更多是支持离线统计分析。
日出而作，日落而息，大家针对大数据的统计分析习惯不会发生根本性变化，最简单的T+1批处理方式也还是数据应用必不可少的环节。在使用同一套架构上，由于数据源变化&维度变化的多样性，批处理往往面临一些复杂场景，这是采用同一套框架上的一些难点，充分支持好批处理也是将来流批一体框架的发展方向。

2、数仓分层与主题分类

1）数仓分层

与传统ETL不同的，我们采用的是ELT的数据架构，较为适合在互联网，总体分为业务数据层、公共数据层、应用数据层三大层次。

① 业务数据层（ODS层）

原始数据经过缓冲层（STG）的加载，会进入数仓的业务数据层，这一层采用范式建模，基本保持与数据源完全一致的结构，对于变化的数据，使用数据拉链加工与存储。

这一层选用范式建模，是指保持源系统（例如关系数据库）的范式结构，好处主要是：
一次性接入数据源结构，针对需求的变动不用频繁去与数据源对接；
便于业务研发更好地理解数据，同时是也是公司的原始数据资产。
针对变化数据采用数据拉链的好处：

保留历史数据的同时，尽可能少占用存储空间，长期来看，拉链存储比起每天全量保留历史节约大概90%空间；
快速、高效地获取历史任意一天业务系统的快照数据。

② 公共数据层（包括公共明细层DWD，公共汇总层DWS）

公共数据层是数据仓库的核心层，是整个数仓中使用率最高的，这一层主要采用的维度建模思路进行设计，类型包括事务事实、周期快照、累积快照。同时为了方便下游对数据的使用，我们会设计一系列的宽表模型，将不同业务过程中的事实进行统一整合，包括纵向整合&横向整合；对于商品、用户主数据类可能分散在不同的源系统中采用纵向整合；横向整合主要包括交易、内容等行为数据不同业务过程的整合，比如：用户（用户信息、注册信息）购买（下单、支付、结算、覆约、完成）商品（商品信息，商家信息，等），我们会把订单流转业务过程整合放到一张明细表里，同时会研发一些基于用户、或者商品视角的轻度汇总宽表。
宽表非常便于理解和易用，下游应用调用也方便。我们之前也做过一些统计，在调用分布来看，宽表的使用占到70%以上。
虽然宽表的使用在数仓建模中非常普遍，但是也有一些缺陷：
数据冗余较多，在存储、计算、调用较为占资源，建议尽量还是按场景去使用；
宽表整合的信息较多，数据权限不好控制。建议可以根据需求，在有限范围内开放整体宽表权限，或者通过视图或者子表的方式建立不同权限的数据范围，适应不同组织的需求；
宽表通常依赖比较多，会影响数据的产出的时效。

③ 应用数据层（DWA层）

顾名思义，就是偏向应用的数据加工，也可以叫集市层，这一层的设计可以相对灵活，贴近应用即可，总体设计思想仍然可以按维度建模思想为主。

2）主题分类

数仓架构的数据分类两个视角，包括主题视角与业务视角。

① 数据主题视角

最重要的一个视角，也就是咱们经常提到的数仓主题，主题是将企业的业务进行宏观数据抽象，是数据仓库里数据的主要组织形式，划分方法如下：
参照波特价值链，分析企业本身经营的业务（基本活动、支持型活动），分别对应哪些数据；
参照业界通用模型，例如像IBM、TD等针对大型行业（如电信、金融、零售）有一些数据主题的通用划分方法；
对企业的内部数据（线上数据模块、数据字典）进行摸底，确认对应到哪些主题。
划分结果会按照三个层级：主题域-->主题-->子主题。

第一级是主题域，针对相对稳定的主题进行合并，归拢到主题域，利于数据的理解与建立全局的数据资产目录；
第二级是主题；
第三级是子主题，主要针对有些主题下分类较多，比如供应链主题下会包含采购、仓储、配送等子主题。
数据主题划分建议完全互斥，不建议重复。

② 数据业务视角

数据业务域是根据企业经营的具体业务，结合企业的组织架构进行划分，层次和分类可以相对灵活，子分类可以允许重复，因为两条不同的业务域可能经营相同的业务，例如电商、内容下都有会员这个业务。

上图是一个比较典型的内容+电商的数据主题与业务分类。
以上一横一纵两个视角，将数据进行更好的归类，在数据模型设计中会打上相应分类标签，从而让数据研发&数据使用人员统一认知。以上两种分类方式主要应用于核心的公共数据层。
业务数据层、应用数据层并不需要遵循以上分类规则，比如业务数据层（ODS层）是按照数据源进行分类，应用数据层（DWA）是根据具体的应用进行分类。

3、数据研发流程

除了合理的架构之外，数据研发的流程也很重要，总体流程如下：

包括需求分析/数据调研、数据模型设计、数据开发&测试、上线发布等流程。
在之前数据中台的核心架构提到不闭门造车，数据研发需要与业务部门充分衔接，比如在数据调研中要与业务研发同学进行线上数据&结构访谈；在数据开发中，与分析&业务同学共同确认标准口径；在数据研发完成后对数据使用方进行数据发布与培训。
以上流程中，除了需求调研，其他部分我们都进行了线上化，包括数据的模型设计，早期我们会手写mapping文档，后期我们逐步把mapping文档进行了线上化，整体的数据模型设计通过模型设计工具完成，包括从概念模型、逻辑模型到物理模型的设计。模型设计完成后，可以一键生成数据知识文档。

4、数据生命周期管理

数据研发完成，还需要关注数据生命周期，一方面数据量的飞速增长不仅仅需要占用大量存储，比如像自建机房，会涉及扩充机柜、机房，往往会面临一些瓶颈；另外一方面，大量的数据会降低数据的计算效率，所以从数据的生成开始，我们就需要考虑生命周期，并且结合数据的使用情况制定数据归档、数据销毁等管理策略。

针对数据已经占用了大量存储资源，可以采取一系列措施进行成本控制，例如：

降存量：通过数据压缩技术、降副本等方式，以及在数据模型更合理的设计，将存量数据存储降低；
控增量：根据数据重要性，可恢复性等考量角度，确认数据的保留周期，并根据周期自动归档或删除；
摊成本：可以通过一些算法，比如数据调用分布、需求来源等，把成本分摊到相应业务部门，让相关业务部门关注到成本。
数据安全也是数据生命周期管理重的一个重要课题，比如针对用户敏感信息，需要在接入时考虑如何加密。一种做法是通过一个独立的物理集群对敏感数据进行隔离与强管控；数据使用中，也需要将数据划分不同的安全或敏感等级（例如有些财务数据的非常敏感，需要谨慎对外开放），根据不同的等级设定不同的访问审批机制。另外，在数据归档、销毁也需要制定好配套的安全管理措施，避免安全风险。

5、数据质量管理

数据质量管理主要包括3个角度：准确性、及时性、一致性。
管理的环节包括：事前、事中、事后、以及事故管理。

针对数据运维的告警发送，传统的方式主要是短信、邮件、电话；随着移动办公工具功能逐步的强大，可以将运维告警以数据接口的方式与这些工具进行对接，将告警发送到企业内部的即时通讯工具。

6、数据应用架构

数据研发最终还是需要赋能到业务&应用，一个合理的数据应用架构是非常关键的，这张图是一个应用架构的简图参考：

从数据的流向上分：

数据仓库（或者数据湖）：负责原始数据的计算，主要将数据落地到HDFS；
数据引擎层：数据加工完成之后，会将数据推送到不同的引擎中，这一层之前提到选择非常多，可以根据自己的场景选择一个混搭组合，比如我们目前选择的有Presto，Kylin，Druid，Mysql；
数据服务层：通过统一化的SQL调用服务，屏蔽底层不同的数据引擎，为上层统一查询提供标准接口；
指标平台：指标平台是一个非常关键的产品，定位于衔接数据研发与数据应用，包括指标的标准定义、逻辑、计算方式、分类等各项内容。指标分类上我们分为标准指标(指标口径经过审核过)、以及非标准指标；
多维查询：这是我们的一个即席查询工具，查询的数据主要来源指标平台，可以选定不同的指标维度组合进行结果呈现，用户可以一次性查询得到结果，也可以将查询结果配置成可视化的报表进行固化。
中间是统一元数据管理：对整个架构中可以对外提供服务的元数据进行统一管理（包括数仓的元数据、查询引擎的元数据、指标元数据等），以及监控这些元数据的调用情况。

最右侧是权限管理：权限管理关乎到数据安全，在设计上需要考虑周全，比如针对表级、指标级、维度级别都可以进行控制；同时产品层面也需要灵活配置权限审批级别与人员。

在面向用户使用层面，我们主要开放的是多维查询&可视化，用户通过多维去查询各类指标&维度数据，得到数据结果列表，再选择可视化配置面板，完成各类图表、表格的自主配置，并发布到个人看板或者业务大盘目录里。也可以将配置的数据看板进行灵活组合，定制成一个小型的数据产品。

7、数据ROI评估

在数据研发中，也要考量数据的ROI，下面是一个简单的ROI模型：

根据活跃度（调用次数等）、覆盖度（通过血缘关系找出依赖数量），以及贡献度（依赖数据的重要等级）来确认数据的价值。同时会评估数据的成本指数（例如计算成本、存储成本等）。
通过以上两者相除，综合得到数据的ROI，针对ROI可以将数据分为不同等级，并相应进行数据治理。比如针对价值低，成本高的数据，可以考虑下线等。

数据研发趋势&关注点

提效：目前借助工具的研发可以把绝大部分数据研发工作线上化，将来借助AI等能力，实现数据处理中包括开发、运维的自动化，提升处理效率；
灵活：流批一体化，包括流处理与批处理自由切换，之前已经提到过，个人认为也是一个发展的趋势；
降本：数据研发链路的成本控制，在数据建设的早期通常不太引起关注，随着数据量不断的积累，往往存储、计算成本成为瓶颈。针对数据建设成本需提前考虑；
算力：我们看到Google，IBM和阿里都在研究量子计算，将来的数据中间层（比如数仓的公共模型）是否可以考虑虚拟化（比如只保留规则&数据结构），具体数据内容在应用发起时，即调即用，更多时候可以不需要占用存储资源。算力的不断提升，有可能会颠覆一些传统数据建设的思路。