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

　　数据源层包括客户端埋点、服务端日志以及业务库数据。数仓的分层使用 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 的间隔。

　　本文整理自阿里云高级开发工程师阮航在Flink Forward Asia 2024的分享，重点介绍了Flink CDC与实时计算Flink的集成、CDC YAML的核心功能及应用场景。主要内容包括：Flink CDC的发展及其在流批数据处理中的作用；CDC YAML支持的同步链路、Transform和Route功能、丰富的监控指标；典型应用场景如整库同步、Binlog原始数据同步、分库分表同步等；并通过两个Demo展示了MySQL整库同步到Paimon和Binlog同步到Kafka的过程。最后，介绍了未来规划，如脏数据处理、数据限流及扩展数据源支持。

　　实时计算架构中，传统湖仓架构在数据流量管控和应用场景支持上表现良好，但在实际运营中常忽略细节，导致新问题。为解决这些问题，提出了流批一体的实时计算湖仓架构——UniFlow。该架构通过统一的流批计算引擎、存储格式（如Paimon）和Flink CDC工具，简化开发流程，降低成本，并确保数据一致性和实时性。UniFlow还引入了Flink Materialized Table，实现了声明式ETL，优化了调度和执行模式，使用户能灵活调整新鲜度与成本。最终，UniFlow不仅提高了开发和运维效率，还提供了更实时的数据支持，满足业务决策需求。

　　实时计算Flink版在稳定性、性能、开发运维和安全能力等方面表现出色。其自研的高性能状态存储引擎GeminiStateBackend显著提升了作业稳定性，状态管理优化使性能提升40%以上。核心性能较开源Flink提升2-3倍，资源利用率提高100%。提供一站式开发管理、自动化运维和丰富的监控告警功能，支持多语言开发和智能调优。安全方面，具备访问控制、高可用保障和全链路容错能力，确保企业级应用的安全与稳定。