共计 924 个字符，预计需要花费 3 分钟才能阅读完成。
更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
当一家公司的日均解决的数据流量在 PB 级别时，微小的任务量和数据量会对音讯队列（MQ）dump 的稳定性和精确定带来极大的挑战。针对这一问题，火山引擎数智平台推出的大数据研发治理套件 DataLeap，能够为企业提供残缺解决方案，帮忙解决 MQ dump 在极其场景中遇到的数据失落问题。
例如，当 HDFS（一种分布式文件系统）集群某个元数据节点因为硬件故障而宕机。那么在该元数据节点终止半小时后，运维工程师尽管能够通过手动运维操作将 HDFS 切到主 backup 节点，使得 HDFS 复原服务。
但故障复原后，MQ dump 在故障期间可能有数据失落，产出的数据与 MQ 中的数据不统一的状况。此时，技术人员能够在收到数据不统一的反馈后，立刻借助火山引擎 DataLeap 进行故障排查。
目前，火山引擎 DataLeap 基于开源 Flink，曾经实现了流批一体的数据集成服务。
通过 Flink Checkpoint 的性能，Flink 在数据流中注入 barriers 将数据拆分为一段一段的数据，在不终止数据流解决的前提下，让每个节点能够独立创立 Checkpoint 保留本人的快照。
每个 barrier 都有一个快照 ID，在该快照 ID 之前的数据都会进入这个快照，而之后的数据会进入下一个快照。
在排查过程中，火山引擎 DataLeap 基于对 Flink 日志查看以及 HDFS 元数据查看，能够率先定位症结所在：删除操作的反复执行造成数据失落。进一步解释就是，在故障期间，写入数据前的删除操作在 HDFS NameNode 上反复执行，将写入的数据删除造成最终数据的失落。
溯源后，用户能够通过火山引擎 DataLeap 抉择应用文件 State（以后的 Checkpoint id 和 task id）解决该问题，应用文件 State 前后解决流程对比方下图所示：
应用文件 State 后，在 Notify 阶段与 HDFS 交互的 metrics（打点监控零碎）的均匀解决工夫缩小了一半。
目前，企业均能够通过火山引擎 DataLeap 体验到上述 Flink Checkpoint 实际与优化计划，晋升数据价值交付中的效率和品质。
点击跳转 大数据研发治理 DataLeap 理解更多
