乐趣区

关于sql:Flink-Iceberg腾讯百亿级实时数据入湖实战

jiezi

简介： 上海站 Flink Meetup 分享内容，腾讯数据湖的百亿级数据场景落地的案例分享。

本文整顿自腾讯数据湖研发高级工程师陈俊杰在 4 月 17 日 上海站 Flink Meetup 分享的《百亿级实时数据入湖实战》，文章内容为：

  1. 腾讯数据湖介绍
  2. 百亿级数据场景落地
  3. 将来布局
  4. 总结

GitHub 地址
https://github.com/apache/flink
欢送大家给 Flink 点赞送 star~

一、腾讯数据湖介绍

从上图能够看进去，整个平台比拟大，包含了数据接入、下层的剖析、两头的治理 (如工作治理，剖析治理和引擎治理)，再到最上层的 Table Format。

二、百亿级数据落地场景落地

1. 传统平台架构

如上图所示，过来的传统平台架构无非是两种，一种是 Lambda 架构，一种是 Kappa 架构：

  • Lambda 架构中，批和流是离开的，所以运维要有两套集群，一套是 For Spark/Hive，一套是 For Flink。这存在几个问题：

    • 第一是运维的老本比拟大；
    • 第二是开发成本。例如在业务方面，一会要写 Spark，一会要写 Flink 或者 SQL，总体来说，开发成本对数据分析人员不是特地敌对。
  • 第二个是 Kappa 架构。其实就是音讯队列，到底层的传输，再到前面去做一些剖析。它的特点是比拟快，基于 Kafka 有肯定的实时性。

这两种架构各有利弊，最大的问题是存储可能会不对立，导致数据链路割裂。目前咱们平台曾经接入了 Iceberg，上面会依据不同场景，论述遇到的问题及解决的过程。

2. 场景一: 手 Q 平安数据入湖

手机 QQ 平安数据入湖是一个十分典型的场景。

目前的业务场景是音讯队列 TubeMQ 通过 Flink 落地成 ODS 到 Iceberg，而后再用 Flink 做一些用户表的关联，之后做成一个宽表去做一些查问，放到 COS 中，可能会在 BI 场景做一些剖析。

这个过程看似平平无奇，然而要晓得，手 Q 的用户关联维表为 28 亿，每天的音讯队列是百亿级的，因而会面临肯定的挑战。

  • 小文件挑战

    1. Flink Writer 产生小文件

      Flink 写入没有 shuffle，散发的数据无序，导致小文件多。

    2. 提早要求高

      checkpoint 距离短，commit 距离小，放大小文件问题。

    3. 小文件爆炸

      几天工夫元数据和数据的小文件同时爆炸，集群压力微小。

    4. 合并小文件又放大问题

      为了解决小文件问题，开 Action 进行小文件合并，后果产生更多文件。

    5. 来不及删数据

      删除快照，删孤儿文件，然而扫描文件太多，namenode 压力微小。

  • 解决方案

    1. Flink 同步合并

      • 减少小文件合并 Operators；

      • 减少 Snapshot 主动清理机制。

        1）snapshot.retain-last.nums

        2）snapshot.retain-last.minutes

    2. Spark 异步合并

      • 减少后盾服务进行小文件合并和孤儿文件删除；
      • 减少小文件过滤逻辑，逐渐删除小文件；
      • 减少按分区合并逻辑，防止一次生成太多删除文件导致工作 OOM。
  • Flink 同步合并

把所有的 Data 文件 Commit 之后，会产生一个 Commit Result。咱们会拿 Commit Result 生成一个压缩的工作，再给它并发成多个 Task Manager 去做 Rewrite 的工作，最终把后果 Commit 到 Iceberg 表外面。

当然，这外面的关键所在是 CompactTaskGenerator 怎么做。刚开始的时候咱们想尽量地合并，于是去做表的 scan，把很多文件都扫一遍。然而它的表十分大，小文件十分多，一扫使得整个 Flink 立马挂掉。

咱们想了个办法，每次合并完，增量地去扫数据。从上一个 Replace Operation 外面到当初做一个增量，看这两头又增了多少，哪些合乎 Rewrite 的策略。

这外面其实有许多配置，去看达到了多少个 snapshot，或者达到了多少个文件能够去做合并，这些中央用户能够本人设置。当然，咱们自身也设有默认值，从而保障用户无感知地应用这些性能。

  • Fanout Writer 的坑

在 Fanout Writer 时，如果数据量大可能会遇到多层分区。比方手 Q 的数据分省、分市；但分完之后还是很大，于是又分 bucket。此时每个 Task Manager 里可能分到很多分区，每个分区关上一个 Writer，Writer 就会十分的多，造成内存不足。

这里咱们做了两件事件：

  • 第一是 KeyBy 反对。依据用户设置的分区做 KeyBy 的动作，而后把雷同分区的汇集在一个 Task Manager 中，这样它就不会关上那么多分区的 Writer。当然，这样的做法会带来一些性能上的损失。
  • 第二是做 LRU Writer，在内存外面维持一个 Map。

3. 场景二：新闻平台索引剖析

上方是基于 Iceberg 流批一体的新闻文章在线索引架构。右边是 Spark 采集 HDFS 下面的维表，左边是接入零碎，采集当前会用 Flink 和维表做一个基于 Window 的 Join，而后写到索引流水表中。

  • 性能

    • 准实时明细层；
    • 实时流式生产；
    • 流式 MERGE INTO；
    • 多维分析；
    • 离线剖析。

  • 场景特点

    上述场景有以下几个特点：

    • 数量级： 索引单表超千亿，单 batch 2000 万，日均千亿；
    • 时延需要： 端到端数据可见性分钟级；
    • 数据源： 全量、准实时增量、音讯流；
    • 生产形式： 流式生产、批加载、点查、行更新、多维分析。

  • 挑战：MERGE INTO

    有用户提出了 Merge Into 的需要，因而咱们从三个方面进行了思考：

    • 性能： 将每个 batch join 后的流水表 Merge into 到实时索引表，供上游应用；
    • 性能： 上游对索引时效性要求高，须要思考 merge into 能追上上游的 batch 生产窗口；
    • 易用性：Table API？还是 Action API？又或是 SQL API？

  • 解决方案

    1. 第一步

      • 参考 Delta Lake 设计 JoinRowProcessor；
      • 利用 Iceberg 的 WAP 机制写长期快照。

    2. 第二步

      • 可抉择跳过 Cardinality-check；
      • 写入时能够抉择只 hash，不排序。

    3. 第三步

      • 反对 DataframeAPI；
      • Spark 2.4 反对 SQL；
      • Spark 3.0 应用社区版本。

4. 场景三：广告数据分析

  • 广告数据次要有以下几个特点：

    • 数量级： 日均千亿 PB 数据，单条 2K；
    • 数据源：SparkStreaming 增量入湖；
    • 数据特点： 标签不停减少，schema 不停变换；
    • 应用形式： 交互式查问剖析。

  • 遇到的挑战与对应的解决方案：

    • 挑战一：Schema 嵌套简单，平铺后近万列，一写就 OOM。

      解决方案： 默认每个 Parquet Page Size 设置为 1M，须要依据 Executor 内存进行 Page Size 设置。

    • 挑战二：30 天数据根本集群撑爆。

      解决方案： 提供 Action 进行生命周期治理，文档辨别生命周期和数据生命周期。


*   ** 挑战三：** 交互式查问。** 解决方案：**
    
    *   1）column projection；*   2）predicate push down。

三、将来布局

对于将来的布局次要分为内核侧与平台侧。

1. 内核侧

在将来，咱们心愿在内核侧有以下几点布局：

  • 更多的数据接入

    • 增量入湖反对；
    • V2 Format 反对；
    • Row Identity 反对。

  • 更快的查问

    • 索引反对；
    • Alloxio 减速层反对；
    • MOR 优化。

  • 更好的数据治理

    • 数据治理 Action；
    • SQL Extension 反对；
    • 更好的元数据管理。

2. 平台侧

在平台侧咱们有以下几点布局：

  • 数据治理服务化

    • 元数据清理服务化；
    • 数据治理服务化。

  • 增量入湖反对

    • Spark 生产 CDC 入湖；
    • Flink 生产 CDC 入湖。

  • 指标监控告警

    • 写入数据指标；
    • 小文件监控和告警。

四、总结

通过大量生产上的利用与实际，咱们失去三方面的总结：

  • 可用性： 通过多个业务线的实战，确认 Iceberg 经得起日均百亿，甚至千亿的考验。
  • 易用性： 应用门槛比拟高，须要做更多的工作能力让用户应用起来。
  • 场景反对： 目前反对的入湖场景 还没有 Hudi 多，增量读取这块也比拟缺失，须要大家致力补齐。
    • *

另外～《Apache Flink- 实时计算正过后》电子书重磅公布，本书将助您轻松 Get Apache Flink 1.13 版本最新特色，同时还蕴含出名厂商多场景 Flink 实战经验，学用一体，干货多多！快点击下方链接支付吧～

https://developer.aliyun.com/article/784856?spm=a2c6h.13148508.0.0.61644f0eskgxgo

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

退出移动版