Flink在转转商业实时数仓的应用

• 一、业务背景
• 二、数仓建设面临的挑战
• 三、数仓的实现方案
• 3.1、数仓的整体方案
• 3.2、Flink在实时数仓中的应用
• 四、结语

一、 业务背景

数据中心是商业化平台的核心模块之一，花钱打广告，效果如何是每个广告主都关心的事情，所谓的效果，作为二手电商平台，就是怎样帮商家把货很好的卖出去，数仓建设是数据中心的基础，能够实时、准确、稳定地输出效果数据是数仓要解决的核心问题。

广告数据的流转过程：

整个链路横跨多个业务，数据方面，广告主最直接的感受是曝光增加，紧接着符合用户诉求的广告商品，用户会进行浏览，浏览完觉得还不错，一般会跟商家进行沟通：是不是包邮、能不能更便宜等，双方协商一致后，用户确认购买，会进行下单操作，然后支付，至此，数据链路走完了，会产生6个核心指标：曝光、点击、计费、咨询、下单、支付。

在Flink之前，实时效果指标采用小时粒度离线统计，延迟2小时，对业务不友好。

二、数仓建设面临的挑战

• 如何能够方便的聚合多方数据源
• 广告关乎收入，如何保障数据准确性、稳定性、实时性
• 能具备框架层面的可复用性，易扩展性
• 发生异常能快速失败、报警、方便重跑且具备数据一致性
• 能满足查询实时和离线2种场景的数据

三、数仓的实现方案

3.1  数仓的整体方案

3.1.1 架构选型

随着大数据应用的发展，业内逐渐形成一些成熟的数仓架构，如Lambda和Kappa，考虑到Kappa架构对历史数据回放的成本较大以及平台的支撑能力，最终选择Lambda架构，Lambda主要分3层：

• 批处理层（Batch layer）：负责根据全量历史数据来生成视图，速度慢，但几乎能修复所有问题；
• 速度处理层（Speed layer）：负责实时处理新来的大数据，延迟低，几乎收到即可使用，可能不如批处理的结果完整或准确，待批处理结束后该视图可被替换；
• 服务层（Serving layer）：负责响应查询，输出结果

拆好层次，整体数仓有了清晰地结构，离线数仓负责批处理层，实时数仓负责速度层，数据服务专门负责数据类的查询出口。

3.1.2 落地方案选型

报表分内部决策和ToB（广告主）2种场景，原本考虑都用OLAP引擎，但由于运维成本问题，OLAP引擎存在数据不稳问题，最终在应用层针对内部决策和ToB采用2套方案，内部决策采用OLAP分析器，ToB采用自定义逻辑加MySQL和Redis存储。

另外，ToB业务对查询也做了柔性处理：跨天后昨日的离线数据输出之前，会继续用昨日的实时数据，同时在页面上做提醒。

3.2 Flink在实时数仓中的应用

本文着重对flink的实现过程进行展开，flink作为第3代流处理框架，比storm有更强的吞吐能力（可以参考美团的一份实验数据https://tech.meituan.com/2017/11/17/flink-benchmark.html），比spark streaming有更低的延迟（spark是微批处理，延迟在秒级；flink是流事件驱动，延迟在毫秒级），且支持TB级的状态管理和灵活的时间窗口。

3.2.1 创建执行环境

设定checkpoint（简称ck）的时间周期、执行模式、超时时间以及状态后端（这里采用hdfs）

3.2.2 定义数据源（DataSource）

当前业务主要处理2种指标：基础指标和效果指标：

• 基础指标包括曝光数、点击数、花费；
• 效果指标是指给客户带来的转化，属于点击的后链路指标，包括留言人数（直接/间接）、私信人数（直接/间接）、下单数（直接/间接）、支付数（直接/间接）、GMV（直接/间接）；

基础指标只需根据自己的流数据做计算，效果指标涉及归因规则，需要多流之间做运算，归因有2种：

• 直接效果：针对同一商品，当天点击且在当天形成转化；
• 间接效果：近14日内点击过该商家的广告后，对该商家形成的转化；

1）基础指标数据源，点击和计费共用一个topic放在一个流里

2）效果指标和点击数据源做流合并，合并后在一个流内共享state，以便于做运算

3.2.3 ETL

主要按照服务层需要的维度，构建key分桶和reduce，这里重点介绍下UV和效果指标计算过程

3.2.3.1 计算UV

如下图所示，借用flink的状态管理，将结果保持在状态中，以便任何ck重跑都保持Exactly-once

3.2.3.1 计算效果指标

1）自定义双流处理函数（flink支持最多2个流的join），先声明2个状态：点击状态、效果指标状态，点击保留14天是为了计算间接效果，效果指标保留3小时是为了应对效果数据先到，而点击延迟，多等待3小时

2）处理点击数据流

3）处理效果数据流

3.2.4 定义sink时间窗口

采用滚动窗口，按照机器处理时间，每10秒下发一次。

3.2.5 sink

1）自定义sink处理器

2）由于整个数据计算都在flink内存中进行，输出结果不用额外加工或累加，所以存储Redis采用Hash.hmset覆盖

3.2.6 整个作业的DAG图如下，每秒处理27m数据，state大小维持在6G，稳定运行1年半

四、结语

Flink完美解决了业务对实时性的痛点，从2小时提升到2分钟，强大的API可灵活扩展。数仓建设是一个持续迭代的过程，实时数仓主要解决时效问题，离线数仓用来保障数据的完整性和准确性，当前方案在现状环境下是一个比较适合的方案，但依然存在双份计算的问题，后期可以考虑混合模式，对非核心指标采用Kappa。