哈希游戏- 哈希游戏平台- 哈希游戏官方网站

　　数据源层包括客户端埋点、服务端日志以及业务库数据。数仓的分层使用 Flink计算，依次为 ODS 层（数据源层）、DWD 层（进行维表关联与简单数据处理）、DWS 层（指标计算）和 APP 层（针对具体应用场景开发），最终将数据输出至下游存储。下游存储依据业务场景选择不同，ToC 场景多使用内部的 KV 存储引擎 Abase，分析型场景及对内产品、平台则使用 ClickHouse 或 Doris，以供下游业务使用。

　　高 QPS 的维表访问导致 Abase 集群压力大，Flink 任务稳定性差，关联维表成为瓶颈。虽提升维表关联缓存命中率可降低外部请求 QPS，但目前缓存命中率已达 90% 以上，提升空间有限。且并非所有维表都超大且时效性要求高，如离线用户维表和百万级监控规则表都相对较小。数仓大量使用 Abase 这种 KV 存储支持大访问 QPS，但当超出其承受能力时，会带来不可控，因此需摆脱对 KV 引擎的依赖，引入新的维表存储方式。

　　该功能设计分为三个模块，以 Hive 为例。分区发现模块通过 Broadcast 算子监测 Hive 分区，发现新分区时，即向下游下发 Watermark 和表元数据信息；数据构建模块的数据读取算子，可配置大并发用于读取 Hive 维表数据；数据分发模块可以将读取的数据分发到各个 TM 中，根据数据量不同有两种分发方式， 即Broadcast 方式（将全量数据 copy 分发）或根据主键 Hash 分发（适用于数据量较大场景）。

　　基于此简化模型，如上图左下角展示的分钟数据输出，第一列是分钟值，即 Bucket key；第二列是时间位移，用于 Bucket 的时间比较；第三列是指标值。第一、二条数据均为 58 分钟，因此，其属于同一个 Bucket，数据也是正序到来的，因此，Bucket记录为 30 秒；指标值为100的数据，第三条数据正常输出，第四条和第五条数据存在乱序，40 秒的数据先到，20秒的数据后到，因此，Bucket 只记录 40 秒的数据，在20 秒的数据进入后不再更新。这样，通过 Bucket 机制可有效处理重复下发、乱序和回撤数据，不影响小时及天指标聚合结果。

　　对于大状态优化场景，直播间开关播时间和时长不固定，最短不到分钟级，最长 30 天，平均在小时级别。分析 Flink 作业中不同开播时长的状态大小占比发现，state TTL 为七天时，开播时长一天的直播间状态大小占98%，这部分多存储六天；大于一天小于七天的占 1%，也存在多存情况；大于八天的仅占 0.5‰，存在少存情况。该问题的核心是状态固定的 TTL 与直播间动态的 TTL 矛盾，导致 99% 的状态多存，0.5‰状态少存。

　　实现过程中对性能问题进行了优化，如 CompactionFilter 查询性能优化，将实时访问 Abase 优化为批量加载关播直播间数据到本地，判断是否关播，避免Compaction 执行过程中， CompactionFilter 访问外部组件查询阻塞，减少 CP 的时长；Cache选择优化，将本地存储关播直播间的 cache 从内存优化到磁盘，降低 GC 时长；CompactionFilter 调用频次优化，设定 state 存储时长超过两天才调用 CompactionFilter，减少未关播直播间频繁调用导致的 CPU 浪费，同时在 RocksDB C++侧缓存 直播间开关播的结果（CompactionFilter 结果），利用 RocksDB 存储机制，将直播间 ID 放在 group by 语句最前面，顺序存储相同 ID 的状态数据，复用 CompactionFilter 调用结果，避免 JNI 调用带来的性能损耗。

　　为解决此问题，分析 Flink 流处理和批处理在引擎实现上的差异，在满足Flink 流处理低延迟特性的同时，实现 Flink 批处理的高吞吐。流处理通过 Minibatch 机制保证低延迟，但其 RocksDB 随机访问和 Retract 机制限制了吞吐；批处理虽有高延迟，但通过 sort 排序处理且无 Retract 机制，吞吐较高。因此，我们提出在流作业中动态监测消费积压情况，判断作业对高吞吐或低延迟的倾向性，在当前算子引入 sort 排序算子和动态调整 Minibatch 大小的能力，实现流批执行模式的动态切换。

　　该方案核心步骤包括积压检测、检测结果传递和动态启用 sorter 算子并调整 Minibatch 大小。Flink 作业运行时，Source 算子动态监测 lag size；当 lag size 超过指定值时，向下游算子发送数据时，标记 isBackLog 为 true，聚合算子接收数据后解析该字段，若为 true，则认为当前作业倾向于批处理，启用 sorter，将 Minibatch 的大小间隔调整为 CP 的间隔。

　　淘天集团数据开发团队基于Fluss构建新一代实时数仓，解决数据消费冗余、探查困难及大State运维难题。Fluss融合列存与实时更新能力，支持列裁剪、KV点查、Delta Join及湖流一体，显著降低IO与计算资源消耗，提升作业稳定性与数据探查效率。已在淘天AB实验平台落地，覆盖搜索、推荐等核心业务，通过618大促验证，实现千万级流量、秒级延迟，资源消耗降低30%，State缩减超100TB。未来将持续深化湖仓架构，拓展AI场景应用。

　　本文整理自中国电信集团大数据架构师李新虎老师在Flink Forward Asia 2024的分享，围绕星海时空智能系统展开，涵盖四个核心部分：时空数据现状、实时场景多引擎化、典型应用及未来展望。系统日处理8000亿条数据，具备亚米级定位能力，通过Flink多引擎架构解决数据膨胀与响应时效等问题，优化资源利用并提升计算效率。应用场景包括运动状态识别、个体行为分析和群智感知，未来将推进湖仓一体改造与三维时空服务体系建设，助力数字化转型与智慧城市建设。

　　本文整理自淘天集团高级数据开发工程师朱奥在Flink Forward Asia 2024的分享，围绕实时数仓优化展开。内容涵盖项目背景、核心策略、解决方案、项目价值及未来计划五部分。通过引入Paimon和Hologres技术，解决当前流批存储不统一、实时数据可见性差等痛点，实现流批一体存储与高效近实时数据加工。项目显著提升了数据时效性和开发运维效率，降低了使用门槛与成本，并规划未来在集团内推广湖仓一体架构，探索更多技术创新场景。

　　本文总结了阿里妈妈数据技术专家陈亮在Flink Forward Asia 2024大会上的分享，围绕广告业务背景、架构设计及湖仓方案演进展开。内容涵盖广告生态运作、实时数仓挑战与优化，以及基于Paimon的湖仓方案优势。通过分层设计与技术优化，实现业务交付周期缩短30%以上，资源开销降低40%，并大幅提升系统稳定性和运营效率。文章还介绍了阿里云实时计算Flink版的免费试用活动，助力企业探索实时计算与湖仓一体化解决方案。

　　本文整理自阿里云智能集团 Apache Flink Committer 刘大龙老师在2024FFA流批一体论坛的分享，涵盖三部分内容：数据工程师用户故事、Materialized Table 构建流批一体 ETL 及 Demo。文章通过案例分析传统 Lambda 架构的挑战，介绍了 Materialized Table 如何简化流批处理，提供统一 API 和声明式 ETL，实现高效的数据处理和维护。最后展示了基于 Flink 和 Paimon 的实际演示，帮助用户更好地理解和应用这一技术。

　　本文整理自阿里云智能集团 Flink PMC Member & Committer 徐榜江（雪尽）在 FFA 2024 分论坛的分享，涵盖四大主题：Flink CDC、YAML API、Transform + AI 和 Community。文章详细介绍了 Flink CDC 的发展历程及其优势，特别是 YAML API 的设计与实现，以及如何通过 Transform 和 AI 模型集成提升数据处理能力。最后，分享了社区动态和未来规划，欢迎更多开发者加入开源社区，共同推动 Flink CDC 的发展。