摘要：本文整顿自科大讯飞中级大数据工程师汪李之在 Flink Forward Asia 2021 的分享。本篇内容次要分为四个局部：
- 业务简介
- 数仓演进
- 场景实际
- 将来瞻望
点击查看直播回放 & 演讲PDF
一、业务简介
构建实时数据分析平台是为了更好的解决业务对更高数据时效性的需要，先简略介绍一下业务流程。
从日常的场景说起，当咱们关上手机 APP 时，常会看到广告。在这样一个场景中，波及到了两个比拟重要的角色。一是手机 APP，即流量方；另一个是投广告的广告主，如支付宝、京东会投放电商广告。广告主购买流量方的流量投广告就产生了交易。
讯飞构建了一个流量交易平台，流量交易平台次要的职能是聚合上游流量，上游再对接广告主，从而帮忙广告主和流量方在平台上进行交易。讯飞还构建了投放平台，这个平台更侧重于服务广告主，帮忙广告主投放广告，优化广告成果。
在上述的业务流程图中，APP 与平台交互时会向平台发动申请，而后平台会下发广告，用户随后能力看到广告。用户看到广告的这个动作称之为一次曝光，APP 会把这次曝光行为上报给平台。如果用户点击了广告，那么 APP 也会上报点击行为。
广告在产生之后产生了很多行为，能够将广告的整个过程称为广告的一次生命周期，不仅限于图中的申请、曝光、点击这三次行为，前面可能还有下单、购买等。
在这样一个业务流程中，业务的外围诉求是什么呢？在广告的生命周期中有申请、曝光和点击等各种行为，这些行为会产生对应的业务日志。那么就须要从日志生成数据供业务侧剖析，从日志到剖析的过程中就引入了数仓构建、数仓分层，数据出现的时效性就带来了实时数据仓库的倒退。
二、数仓演进
上图是一个典型的数仓分层框架，最底层是 ODS 数据，包含业务日志流、OLTP 数据库、第三方文档数据。通过 ETL 将 ODS 层的数据荡涤成业务模型，也就是 DWD 层。
最后是建设了 Spark 数仓，将业务日志收集到 Kafka 中再投递到 HDFS 上，通过 Spark 对日志进行荡涤建模，而后将业务模型再回写到 HDFS 上，再应用 Spark 对模型进行统计、剖析、输入报表数据。后续，讯飞沿用了 Spark 技术栈引入了 spark-streaming。
随后逐步将 spark-streaming 迁徙到了 Flink 上，次要是因为 Flink 更高的时效性和对事件工夫的反对。
当初 spark-streaming 的实际是微批的，个别设置 10 秒或是 30 秒一批，数据的时效性顶多是秒级的。而 Flink 能够反对事件驱动的开发模式，实践上时效性能够达到毫秒级。
当初基于 spark-streaming 的实时数据流逻辑较为简陋，没有造成一个数仓分层的构造。而 Flink 能够基于 watermark 反对事件工夫，并且反对对提早数据的解决，对于构建一个业务逻辑齐备的数仓有很大的帮忙。
由上图可见，ODS 的业务日志收集到 Kafka 中，Flink 从 Kafka 中生产业务日志，荡涤解决后将业务模型再回写到 Kafka 中。而后再基于 Flink 去生产 Kafka 中的模型，提取维度和指标，统计后输入报表。有些报表会间接写到 sql 或 HBase 中，还有一些报表会回写到 Kafka 中，再由 Druid 从 Kafka 中被动摄取这部分报表数据。
在整个数据流图中 Flink 是外围的计算引擎，负责荡涤日志、统计报表。
三、场景实际
3.1 ODS - 日志生产负载平衡
ODS 业务中，申请日志量级大，其余日志量级小。这样申请日志（request_topic）在 Kafka 上分区多，曝光和点击日志（impress/click_topic）分区少。
最后是采纳单 source 的办法，创立一个 FlinkKafkaConsumer011 生产所有分区，这可能导致 task 生产负载不均。同一 topic 的不同分区在 task 上可平均调配，但不同 topic 的分区可能会被同一 task 生产。冀望能达到的生产状态是：量级大的 topic，其 task 和 partition 一一对应，量级小的 topic 占用剩下的 task。
解决办法是把单 source 的生产形式改成了多 source union 的形式，也就是创立了两个 consumer，一个 consumer 用来生产大的 topic，一个 consumer 用来生产小的 topic，并独自为它们设置并行。
3.2 DWD - 日志关联及状态缓存
DWD 是业务模型层，须要实现的一个要害逻辑是日志关联。基于 sid 关联广告一次生命周期中的不同行为日志。业务模型记录了 sid 级别的维度和指标。
最后是基于 30s 的 window 来做关联，但这种形式会导致模型输入较第一次事件产生提早有 30s，并且 30s 仅能笼罩不到 12% 的曝光日志。如果扩充窗口工夫则会导致输入提早更多，并且同一时刻存在的窗口随工夫增长，资源耗费也比拟大。
后续改成了基于状态缓存的形式来实现日志关联，即 ValueState。同一 sid 下的日志可能拜访到相应的 ValueState。不过为保障及时输入，将申请、曝光、点击等不同指标，拆分到了多条数据中，输入的数据存在冗余。
随着业务的增长和变动，须要缓存的状态日益变大，内存已无奈满足。于是咱们将状态从内存迁徙至 HBase 中，这样做的益处是反对了更大的缓存，并且 Flink checkpoint 负载升高。但同时也带来了两个问题：引入第三方服务，须要额定保护 HBase；HBase 的稳定性也成为计算链路稳定性的重要依赖。
在 HBase 状态缓存中，遇到一个数据歪斜的问题，某条测试 sid 的曝光反复上报，每小时千次量级。如上图，该条 sid 对应的状态达到 MB 级别，被频繁的从 HBase 中取出并写回，引起频繁的 gc，影响所在 task 的性能。解决办法是依据业务逻辑对 impress 进行去重。
3.3 DWS - 实时 OLAP
在 DWD 层基于 Flink 的事件驱动曾经实现了实时模型，再由 Flink 来生产解决实时模型，从中提取出维度和指标，而后逐条的向后输入。在这个过程中已是能输入一个实时 OLAP 的后果了，但也须要有个后端的存储来承接，咱们因而引入了 Druid。Druid 能够反对数据的实时摄入，并且摄入的后果实时可查，也能够在摄入的同时做主动的聚合。
上图左侧：每张表须要启动常驻工作期待 push 过去的数据。常驻工作被动接收数据，易被压崩；常驻工作异样重启麻烦，须要清理 zk 状态；常驻工作的高可用依赖备份工作，浪费资源。
上图右侧：一张报表对应一个 Kafka 生产工作。生产工作本人管制摄入速率更加稳固；工作可依赖 offset 平滑的失败自启。
3.4 ADS - 跨源查问
Presto 是分布式的 SQL 查问引擎，可从不同的数据源抽取数据并关联查问。但会带来 Druid 的下推优化反对不欠缺的问题。
3.5 流批混合现状
如上图所示是 Lambda 大数据框架，流式计算局部是 Kafka+Flink，批处理则是 HDFS+Spark。
流式计算的特点：
- 响应快，秒级输入；
- 可重入性差，难以反复计算历史日志；
- 流的持续性重要，异样需迅速染指。
批处理的特点：
- 响应慢，小时级输入；
- 可重入性好，可反复计算历史数据；
- 数据按小时粒度治理，个别异样可从容解决。
流批混合痛点：
- 两遍日志荡涤的计算量；
- 两套技术框架；
- 数据一致性问题。
四、将来瞻望
流批混合优化，间接将实时模型输入到 HDFS。
益处是：
- 防止了对日志的反复荡涤；
- 对立了建模的技术框架；
- 反对提早数据对模型的更新。
但也有以下两个问题：
- 实时模型反复，量级更大，计算耗费大；
- 反对数据更新的技术如 Hudi，会扭转模型的应用形式，对后续使用者不敌对。
最初聊一下对 Flink-SQL 的想法：检索近 10 分钟的某条异样日志、疾速评估近 10 分钟新策略的成果都属于即时、微批、即席查问。批处理链路小时级响应太慢；实时检索系统如 ES，资源耗费大。能够利用 Kafka + Flink-SQL 解决上述问题，Kafka + Flink-SQL 也是今后打算尝试的方向。
点击查看直播回放 & 演讲PDF
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～
流动举荐
阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启流动：
99 元试用 实时计算Flink版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc...