共计 3510 个字符，预计需要花费 9 分钟才能阅读完成。
▌Flink 摸索
1.1：Why Flink
Apache Flink 是一个分布式解决引擎，用于离线和实时的计算。Flink 凭借其极致的流式解决性能和优良的框架设计吸引了泛滥开发者退出，各大厂也都纷纷引入 Flink 作为其次要的流式开发引擎。
Flink 的次要劣势：
- Exactly-once 语义
- 多种高效的窗口计算
- 轻量级的 checkpoint 机制
- 反对 EventTime 及工夫乱序事件
- 高效的反压机制
- 弱小的状态管理机制，可反对超大的状态存储
- 反对流的 join 和维表的 join
- 泛滥的 connector 反对
- 简单事件处理 CEP
- 反对 SQL、自定义 UDF、UDFA 等
Flink 在满足简单性能的同时，QPS 还能够达到百万级别，同时容错性和准确性也能够失去保障，这是 MobTech 袤博科技抉择 Flink 的次要起因。MobTech 袤博科技是寰球当先的数据智能科技平台，累计笼罩设施 155 亿 +，DAU 2.6 亿 +，继续迭代的趣味标签达 6000+。在数据智能产业，以数据利用为主导，交融顶尖的大数据、云计算、人工智能等多元先进技术，打造开发者服务、商业化、AI、Mob 研究院四大版块，为寰球数百个国家和地区的企业、开发者和政府机构提供商业智能解决方案、App 经营赋能计划、企业级 AI 智能计划、数据征询钻研等服务。
1.2 Flink 在 MobTech 袤博科技的集群状况
公司采纳 On-yarn 的运行模式，长时间运行的流工作采纳 Per-Job 模式，局部利用采纳 Session 形式运行。On-yarn 模式简略不便无需关怀保护 Flink 集群状况，只须要配置 Yarn 和部署 Flink Client 即可开发和提交 Flink 工作。Flink 版本从最后的 1.7 一路降级到 1.13，降级至最新版本的起因有三点：
1、因为社区版本迭代较快，如果跨多个版本迭代批改的老本会十分大，所以在小版本迭代的时候抉择降级是最划算的，因为须要改变的代码不会太多；
2、Flink 社区十分沉闷，每个版本都会有较大的性能和性能的晋升，特地是 Flink SQL，这也是咱们思考的重要起因之一；
3、随着版本的迭代开发方式也失去降级，新近次要是基于 stream api 进行开发，开发效率偏低而且性能不是最优的。公司外部逐步搭建起 Flink 流式平台，使开发 SQL 化大大提高了开发效率和程序性能。
MobTech 袤博科技领有独立的流式计算集群，蕴含了 Flink、Spark、Storm 等各种的流计算引擎。而 Flink 应用程序占 80% 以上，大部分过来开发的 Spark streaming 程序在应用 Flink 重构后，资源利用率翻了一倍，同时解决了计算提早、数据背压以及内部资源依赖等问题。
▌Flink 在数据智能企业的利用和挑战
Flink 在 MobTech 袤博科技的利用场景有很多，从实时报表、数据监控、实时画像、机器学习到实时数仓，Flink 在各个环节和业务线都施展了至关重要的作用，为公司带来微小的价值。接下来我将选取几个比拟经典的案例来分享咱们在 Flink 实际中获得的教训成绩。
2.1 经典的多维度 DAU 计算问题
MobTech 袤博科技作为寰球当先的数据智能科技平台，因为笼罩的设施数量微小，所以每天都有大量的日志进入日志零碎；
日均实时处理数据量达 150 亿 +，日均 QPS 20w/s+，数据处理峰值可达 90w/s，DAU 达 2.6 亿 +，MAU 达 12 亿 +，趣味标签体系 6000+；
同时 Flink Checkpoint 达 10G 左右，所以如何精确地计算和存储如此微小的数据成为一大挑战。
单个 Topic 最高 20w/s +，总和曾经超过百万 QPS
计算过程中数据可扩张至千亿以上
挑战 1：大 QPS 下的 UID 去重问题
因为思考到日活的数据量较大，单天的日活已达 2.6 亿 +，周活和月活的能够翻数倍，如果要准确计算 UV 值将会耗费微小的内存和磁盘空间，同时会导致 checkpoint 的后果微小可能呈现提早甚至失败。Flink 有原生的 COUNT DISTINCT 来反对去重计算，采纳的 Split Distinct Agg 形式做聚合，能做到准确去重但效率不高长时间运行上来会越来越慢，同时无奈解决状态太大的问题。起因在于 COUNT DISTINCT 应用了 MapState 作为状态存储，如果单个 Key 的 UID 过大会导致内存溢出同时 State 过大导致 Checkpoint 工夫过长甚至失败。
所以咱们采纳业内罕用的 HyperLogLog 算法做到误差小于 0.1% 的估算形式，单个维度的 Key 对应的 HLL 只有一个对象且大小只和精度无关，重写相似 COUNT DISTICT 的聚合函数即可实现，HLL_COUNT_DISTICT(UID)。
通过优化后 Flink Checkpoint 的大小由原来的 30G 降到 2.5G 左右升高了 10 倍以上的存储压力，同时计算上没有呈现背压的状况。
挑战 2：数据热点问题
在开发的过程中咱们发现某个报表后果只有两个 Key 导致所有数据只进入两个 slot 计算导致热点问题，这类问题借由 Flink 原生对 COUNT DISTINCT 的优化思路 Split Distinct Agg 形式能够很好地解决。SQL 语句如下：
第一次聚合由 group key 和额定的 bucket key 进行 shuffle，bucket key 是应用 HASH_CODE(distinct_key) % BUCKET_NUM 计算的。当第二次 group by day 的时候须要留神的是，因为咱们应用 HLL_COUNT_DISTICT 来代替原生 COUNT DISTINCT，返回类型是 HLL，所以须要自定义 SUM_HLL 对 HLL 对象做累加解决。
通过优化后，背压问题不再呈现，各个 Task 的内存使用量由原来的 8G 调整为 2G，同时能够通过管制 BUCKET_NUM 的大小来进步数据处理的并行度进步处理速度。
在 MobTech 袤博科技曾经有一套欠缺的计算 UV 和解决数据热点问题的 API，这些也曾经集成在 Flink 源码外面无需开发人员再开发或者援用。
2.2 Flink SQL 上的一些改良
2.2.1 反对 EMIT SQL 语法
Flink 的一个十分弱小的个性就是对 Window 计算的反对，Window 有滑动窗口，翻滚窗口，session 窗口，这些窗口性能能够满足不同的简单需要。Flink 触发窗口的条件也比较简单，就是在 Watermark > Window end-time 的时候触发窗口计算并输入。但若有时候咱们须要提前触发窗口的计算并输入呢？则须要在 Flink stream Api 中提供了 Trigger 来提前触发计算，例如咱们须要每 5s 输入一次 1h 翻滚窗口的计算结果。
但这个 Api 有一个小毛病就是即便窗口的后果没有变动也会输入一次，导致雷同后果频繁输入，这个问题咱们批改了局部源码进行修改。但如果咱们须要在 SQL 语法中增加这类逻辑呢？Flink 原生 SQL 是不反对这类语法。在 MobTech 袤博科技外部的流计算平台，因为 SQL 化的推广咱们须要一个 SQL 语法来反对此类需要：
2.2.2 自定义 ES connector
反对 ES 的 xpack 验证，反对定时和批量写出
在利用之前须要在 env 注册 registerCachedFile，将 xpack file 注册。
除了以上说到的一些优化外，团队在 MobTech 袤博科技还做了一些额定的性能优化，例如 SQL 的并行度设置、Repartition SQL 语法反对、Hbase 和 Redis 的维表 Join SQL 语法反对等。
▌将来摸索：实时数仓 & 数据湖
Lambda 架构： 传统的实时数仓采纳 Lambda 架构，架构将数仓分为离线层和实时层，离线和实时各一套计算引擎和解决逻辑。很多的业务需要相应的会有离线工作和实时工作两套，代码上因为无奈专用一套，所以须要写两套逻辑代码，离线用 Spark 做，实时选用 Flink 做。
Flink Kappa 实时架构：在 Lambda 架构后又涌现出 Kappa 架构，OLAP 架构等。
这类架构摈弃了 Lambda 的离线解决局部，全副采纳 Flink 做为计算引擎，存储由 HDFS 替换为 Kafka，最终后果存储为 OLAP 数据库。但问题也很显著，Kafka 无奈存储大量的历史数据，也无奈反对 OLAP 的即时查问，也无奈反对数据的更新删除等操作。
Flink Iceberg 数据湖： 解决了 Kafka 无奈存储大量历史数据问题，同时反对了 OLAP 查问性能，Iceberg 反对流式的读写性能。
▌总结
随着公司的疾速倒退，数据的增长也越来越快，传统的数据处理框架和数据存储系统已慢慢透出弊病，寻找更高效稳固的计算框架引擎和大数据架构是各个数据公司的指标，MobTech 袤博科技作为当先的数据智能科技平台也在一直摸索和优化本人的大数据平台架构，力求为客户带来更优质的服务。