「如何实现流动式软件发布」线上课堂开课啦,快来报名参与课堂抽奖吧~ 了解详情
写点什么

基于 Flink 的严选实时数仓实践

2019 年 2 月 28 日

基于Flink的严选实时数仓实践

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


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 扩展。


第三,数据质量。目前主要是侧面辅助决策,希望对舒适数据准确性校验实现比较通用的规范,开发一些工具完成这些工作。配套 PPT 下载,请识别底部二维码关注社区公众号,后台回复【杭州大数据】


作者介绍:


杨雄,网易严选数据技术与产品部资深研发工程师。浙江大学硕士毕业加入网易,曾参与邮箱大师、有钱、严选等多个产品的数据研发工作,在大数据开发和数据仓库都有一定经验,目前主要负责严选实时数仓构建和应用。


2019 年 2 月 28 日 16:23304

评论

发布
暂无评论
发现更多内容

OpenHarmony 1.1.0 LTS 版本正式发布

开放原子开源基金会

开源 开放原子开源基金会 OpenHarmony

flutter开发环境搭建,京东面试真题解析,分享PDF高清版

欢喜学安卓

android 程序员 面试 移动开发

领域驱动设计101 - 分层

luojiahu

领域驱动设计 DDD

COBIT2019中核心模型(目标)、设计因素、治理系统和系统组件的关系

ming_hgm

cobit

redis Redis缓存穿透解决方案

Sakura

四月日更

65w字!阿里分布式开发小册Github新开源!原理实践双飞

程序员小毕

Java 程序员 架构 面试 分布式

Boss直聘转发超120W次Java全栈面试题!已帮我拿下5个Offer!

Java架构追梦

Java 面试 架构师 全栈面试题 阿里巴巴面经总结

C++ 虚函数表剖析

赖猫

c++ C/C++ 封装、继承、多态

前端开发解决异步回调必备技能——Async/Await和Promise

三掌柜

vuejs 前端进阶 签约计划

潮汐交替,价值重组:2021数字化转型看什么?

脑极体

framework源码,Android学习路线指南,已整理成文档

欢喜学安卓

android 程序员 面试 移动开发

Java高手是怎样炼成的?阿里P8技术大牛这份手写笔记告诉你答案!

Java架构之路

Java 程序员 架构 面试 编程语言

某招聘平台流出一套超级全面的《Java面试题总结》被疯狂转发近百万次,已助我拿下5个大厂offer。

Java架构之路

Java 程序员 架构 面试 编程语言

架构实战营模块一作业

刁寿钧

架构实战营

Dubbo 学习笔记(一) Hello,Dubbo

U+2647

dubbo 四月日更

读《非暴力沟通》

箭上有毒

读书笔记 4月日更

别当工具人了,手摸手教会你 Jenkins ! 码农很低调

比伯

Java 程序员 架构 计算机 技术宅

你看起来很美味?独家揭露视频推荐系统AI秘方

白洞计划

DEX领域第一个运用整合思维的DeFi协议 SumSwwap潜力巨大

币圈资讯

【资深猎头分享】程序员面试如何避坑?

Java架构师迁哥

从Spring框架中的一个BUG来分析锁使用的问题

郑印

Java spring

刚刚!字节跳动发布了 1179 个 Java 岗,平均薪资40K

钟奕礼

Java 编程 程序员 架构 面试

面面俱到!四面阿里拿offer后,才发现师哥给的面试笔记有多强大

互联网架构师小马

Java 程序员 面试 阿里 找工作

【LeetCode】丑数Java题解

HQ数字卡

算法 LeetCode 4月日更

In-depth Java synchronized

shniu

Java并发 并发编程 Monitor

HBase三个重要机制

五分钟学大数据

HBase 4月日更

我是收藏一把好手

yes

学习

211本科面试阿里挂了:分布式+限流+通讯+数据库被问懵了!

码农之家

Java 编程 程序员 面试 刷题笔记

火爆火爆!最新分享给大家:Boss直聘转发超80W次的一套超全面试题总结

比伯

Java 架构 面试 程序人生 计算机

王者级Java核心文档,靠着这份开发手册知识原理清单,我拿下了8个offer

Crud的程序员

Java 编程 程序员 架构

数万人跪求!阿里P8大牛手写的《Java程序性能优化实战笔记》,GitHub标星已高达十万!

Java架构之路

Java 程序员 架构 面试 编程语言

基于Flink的严选实时数仓实践-InfoQ