关于移动应用开发:极客星球-Flink在数据智能公司的探索实践与优化

▌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袤博科技作为当先的数据智能科技平台也在一直摸索和优化本人的大数据平台架构,力求为客户带来更优质的服务。

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据