今天分享的内容主要分为四个部分，首先会介绍下严选实时数仓的背景、产生的一些问题。然后是针对这些背景和问题对实时数仓的整体设计和具体的实施方案，接着会介绍下在实时数仓的数据质量方面的工作，最后讲一下实时数仓在严选中的应用场景。

1. 背景

严选实时数仓项目是从 17 年下半年开始做的，背景总结为三个方面：

第一个是长链路且快速变化的业务，严选作为一个 ODM 电商，整个业务链度从商品采购、生产、仓库、到销售这个阶段可以在主站 APP
上购买或者分厂购买，然后通过商户配送到达消费者。链度是非常长的，这也决定数据的数据域非常广；严选作为一个成长的电商，会有很多新的业务出现。

第二个是越来越多的实时数据需求，目前需要更多的实时数据来做业务决策，需要依据销售情况做一个资源位的调整；同时有些活动也需要实时数据来增强与用户的互动。如果数据有实时和离线两种方案，优先考虑实时的，如果实时实现不了再考虑离线的方式。

第三个就是越来越高的数据质量要求，因为数据会直接影响业务决策，影响线上运营活动效果，因此对数据质量的要求越来越高。

针对这样的项目背景提出了三个设计目标，第一个是灵活可扩展，第二个是开发效率高，第三个是数据质量要求高。

2. 整体设计和实现

基于这样的设计目标，介绍一下整体的设计和实现方案：

实时数仓整体框架依据数据的流向分为不同的层次，接入层会依据各种数据接入工具收集各个业务系统的数据，如买点的业务数据或者业务后台的并购放到消息队列里面。消息队列的数据既是离线数仓的原始数据，也是实时计算的原始数据，这样可以保证实时和离线的原始数据是统一的。有了源数据，在计算层经过
FLink+ 实时计算引擎做一些加工处理，然后落地到存储层中不同存储介质当中。不同的存储介质是依据不同的应用场景来选择。框架中还有 FLink
和 Kafka 的交互，在数据上进行一个分层设计，计算引擎从 Kafka 中捞取数据做一些加工然后放回
Kafka。在存储层加工好的数据会通过服务层的两个服务：统一查询、指标管理，统一查询是通过业务方调取数据接口的一个服务，指标管理是对数据指标的定义和管理工作。通过服务层应用到不同的数据应用，数据应用可能是我们的正式产品或者直接的业务系统。后面会从数据的分层设计和具体的实现两个方面介绍。

上面是对数据的整体设计，主要参考了离线数仓的设计方案，也参考了业界同行的一些做法。将数据分为四个层次：

首先是 ODS 层，即操作数据层，通过数据采集工具收集各个业务源数据；DWD
层，明细数据层是按主题域来划分，通过维度建模方式来组织各个业务过程的明细数据。中间会有一个 DIM
层，维度数据层主要做一些查询和关联的操作。最上层是 DM 层，通过 DWD
层数据做一些指标加工，主要面向一些分析和应用汇总的指标或者是做多维分析的明细数据。

举例说明一下数据设计流向过程，假如要对严选主类目上当天销售和流量的统计，统计每个类目的销售量和流量从 ODS
层来源两部分，一部分来自访问，这是来源于埋点数据，这种数据通常比较规范，通过一些简单加工，在 DWD
层形成一张商品访问明细表；交易数据来自交易明细表，在 ODS 层来源于订单表和订单购物车表。将两个表汇聚在 DWD
层形成一个交易域的交易明细表，因为统计需要统计到类目维度，所以从 DWD 层向 DM 加工需要从商品维度表做一个关联，这样就可以在 DM
层做一些汇总统计，就可以形成 DM
所需要的指标数据。这里的数据分为两类，一种是实时的，一种是准实时；如果维度比较复杂，如准实时弹幕做一些配置来做到同步，如果有一些关联关系比较简单的就做成实时维表。这样的好处是能实时统计，能比较直观观察。

实时数仓设计分为 5 个主题域，分别是商品、流量、交易、营销、仓配。在这五个主题域下沉淀了 25 个模型，整个实时数仓在线任务数达到 135。基于这样的设计方案能整体实现设计目标。

首先通过主体域的模型复用能够提高开发效率，最常用的就是交易域的实时数据。交易域的交易明细模型能够产生多个集市层模型，交易明细的字段清洗比较规范，一般两天就能开发一个模型，如果模型简单一天就能搞定。第二个就是比较灵活，在
DWD
层封装一些业务逻辑，快速应对一些业务调整。举例说明下，严选上线一个众筹业务，先前对交易定义都是以支付来算，但是众筹交易和支付相隔时间较长，对于离线只需要活动结束再进行统计，但是实时只关注于当天数据，这个时候统计就没有意义。因此需要将众筹数据剔除，实现时只需要在交易明细里面进行过滤，这样集市层所有指标数据都统一更改掉。第三个就是统一，数据都是按照业务域划分，管理和维护都比较方便，对于开发资源分配也比较便利。

然后介绍下技术实现方面的考量，主要分为计算和存储。对于计算方面，有很多实时计算引擎，有 Flink、Storm、Spark
Streaming，Flink 相对于 Storm 的优势就是支持 SQL，相对于 Spark Streaming
又有一个相对好的性能表现。同时 Flink 在支持好的应用和性能方面还有比较好的语义支持和比较好的容错机制，因此构建实时数仓 Flink
是一个比较好的实时计算引擎选择。

对于存储层会依据不同的数据层的特点选择不同的存储介质，ODS 层和 DWD 层都是存储的一些实时数据，选择的是 Kafka
进行存储，在 DWD 层会关联一些历史明细数据，会将其放到 Redis 里面。在 DIM 层主要做一些高并发维度的查询关联，一般将其存放在
HBase 里面，对于 DIM 层比价复杂，需要综合考虑对于数据落地的要求以及具体的查询引擎来选择不同的存储方式。对于常见的指标汇总模型直接放在
MySQL 里面，维度比较多的、写入更新比较大的模型会放在 HBase 里面，还有明细数据需要做一些多维分析或者关联会将其存储在
Greenplum 里面，还有一种是维度比较多、需要做排序、查询要求比较高的，如活动期间用户的销售列表等大列表直接存储在 Redis 里面。

性能优化方面，在计算中采用很多维度关联，如果每一次维度关联都从 HBase 中调用性能受限，因此将维度数据在本地 task
进行一次缓存。聚合去重用一些精度去重算法，如 Hyperloglog，既能保证在一个可接受的数据统计误差，又能比较好的优化存储。存储方面主要针对
MySQL 和 Greenplum 两种场景，在大数据场景下 MySQL 写入压力比较高，在写入之前做一个窗口预聚合，实现延迟和负载均衡，较少
MySQL 的写入压力。对于明细数据写入 Greenplum，明细数据不适合高并发写入，因此会对要写入的表依据主键做哈希，定位要录入的
segment，直接到 Slave 节点，批量写入数据，这样也能有效提高写入的存储量。

3. 数据质量

数据质量分为两个方面来介绍，数据一致性和数据监控。

数据一致性主要针对实时与离线的数据一致性，同一个指标实时与离线都会产出。这两者一致性分为四个方面：

第一，建模方法与分层基本统一，建模基于维度建模，分层也是业内通用方法；

第二，业务上主题域和模型设计同步；

第三，数据接入与源数据统一；

最后，数据产出方面，指标定义和接口都是统一输出。

DWD
层做到主题域与模型同步，按照业务过程来设计模型，这种方法对于实时和离线都是统一的。以交易域为例，在实时和离线都有订单、订单明细、组合装的交易明细，还有加购数据模型，由于开发成本原因实时模型大都是离线模型的子集。在
DM 层会统一定义指标和模型定义的方法，规范对于实时和离线都是适用的，定义模型会指定相应的指标和维度，指标通常是派生指标，通过原子指标 +
时间维度 + 修饰词完成派生指标的定义，再经过定义维度形成模型。

有了模型定义规范具体落地，如果要定义当日主站 PC 端销售，首先定义原子指标流水，时间维度今天，端是
PC，然后定义派生指标，有了派生指标接着定义模型，定义为每天商品销售实时情况，做一个实时与离线的标记，选择其存储，维度选择一个是时间维度、一个是商品维度，然后加入先前的派生指标，最后生成模型。不同模型知识实时和离线标记，调用都是基于同一套接口来调用。

数据监控涉及两个方面，一个是数据平台监控。主要是对任务失败情况监控、异常日志监控、任务失败是 RPS
异常监控。还有任务本身运行正常，但是数据已经处理不过来，由于 Flink 机制，数据挤压到消费管理，通过对 Kafka
数据延迟监控能够及时发现问题。将问题通过监控发现，利用值班流程规范将问题及时发现和处理，及时通报和定期进行修复，来提高整个数据质量。

为了配合数据监控，正在做实时数据血缘。主要是梳理实时数仓中数据依赖关系，以及实时任务的依赖关系，从底层 ODS 到 DIM 再到 DM，以及 DM 层被哪些模型用到，将整个链度串联起来。这样的好处是：

（1）数据 / 任务主动调整可以周知关联的下游；

（2）任务异常及时判断影响范围，通知产品和业务方；

（3）指标异常时借助血缘定位问题。

4. 应用场景

实时数仓应用场景分为三类：数据产品、线上运营活动、业务后台。在线模型数有 84 个，历史总模型数为 110+，大部分数据延迟都在 10s 以内，对于数据大屏这种对延迟要求比较高数据延迟在毫秒级。

数据大屏是最常用的实时数据应用场景，有针对客服业务大屏，如大麦 - 商品数据运营平台、神相 - 流量分析平台、刑天 -
推广渠道管理系统。第二个是线上运营活动，如热销商品榜单、活动用户消费排行、资源位排序转化策略，业务后台仓配产能监控、物流时效监控、库存预警、商品变更通知。

5. 展望

未来展望从三个方面：

第一，性能方面。模型用 MySQL 效率不高，后期迁移到 ES 上；维度表落地到 Redis 上进一步提高吞吐量。

第二，开发效率。开发是 SQL 和 API 两种并存，开发效率不高，后期往 SQL 迁移，由于 SQL 本身局限，进行 UDF 扩展。

第三，数据质量。目前主要是侧面辅助决策，希望对舒适数据准确性校验实现比较通用的规范，开发一些工具完成这些工作。