当一家公司的日均处理手机流量在PB级别时，非常大的工作量和信息量会让线程池（MQ）dump的稳定和精确性带来极大的考验。

 针对这一难题，火山引擎智慧运营服务平台上线的大数据研发整治模块DataLeap，能够为用户提供详细解决方法，切实解决MQ dump在极端化情景过程中遇到的内容丢失难题。

 比如，当HDFS（一种分布式存储）集群式某一元数据节点因为硬件问题而崩溃。那在该元数据节点停止半个小时后，运营工程师尽管能通过手动式运维管理实际操作将 HDFS 切出主 backup 连接点，促使HDFS 修复服务项目。但故障恢复后， MQ dump 在常见故障期内可能会有内容丢失，生产出来的数据和 MQ 里的数据不一致的现象。

 这时，专业技术人员能够在接到数据不一致反馈后，马上依靠火山引擎DataLeap开展故障排除。现阶段，火山引擎DataLeap根据开源系统Flink，已经实现流批一体的数据聚合服务项目。根据Flink Checkpoint的功效，Flink 在数据流分析中引入 barriers 将数据拆分为一段一段的信息，在没有停止数据流分析解决前提下，让每个节点能够独立建立 Checkpoint 储存自已的快照更新。

图：Flink Checkpoint 根据 Chandy-Lamport 优化算法确保数据的一致性

 据了解，每一个 barrier 都有一个快照更新 ID ，在这个快照更新 ID 以前的信息都是会进入这个快照更新，而之后的信息将进入下一个快照更新。在检查情况下，火山引擎DataLeap根据对Flink 日志查询及其HDFS 数据库查询，能够首先精准定位问题所在：删掉操控的重复执行导致内容丢失。进一步理解就是，在常见故障期内，载入数据信息前删掉实际操作在 HDFS NameNode 上重复执行，将载入的数据删除导致最终数据的遗失。

图：应用文档State 前后左右处理程序比照

 追溯后，用户可通过火山引擎DataLeap选择用文档State（现阶段的 Checkpoint id 和 task id）处理此问题。据了解，应用文档 State 后，公司在 Notify 环节与 HDFS 互动的 metrics（打理视频监控系统）平均等待时间降低了一半。

 现阶段，企业通过火山引擎DataLeap体会到以上Flink Checkpoint实践与改进方案，提高数据信息价值交付里的效率和效果。（创作者：韩江）