1、抖音集团数据质量实践,何舒青火山引擎DataLeap数据质量技术负责人,火山引擎DataLeap流批数据质量解决方案,1.数据质量挑战2.解决方案3.最佳实践4.未来演进方向,大纲,什么是数据质量(广义),定义：数据的一组满足固有特性(质量维度)要求的程度,六维度：完整性准确性一致性及时性规范性唯一性,数据质量在抖音集团内部(狭义),数据质量平台针对数据及其生产链路的数据质量管理平台代表功能对数据开发平台产出的 Hive 表数据进行主键重复检测，如果存在重复则进行报警典型场景,注：上图标红文字表示抖音集团数据质量平台具有的功能,应用规模-监控规模：万级别-DAU：千级别,数据任务产出Hive表

2、但是因为HMS 主从延迟,下游任务会读到脏数据，质量监控发现异常，阻止下游任务运行。,01,内部挑战,7,数据质量挑战,User Story 1：某内部指标平台，业务数据由Hive定期同步到ClickHouse；希望每次同步任务后检查Hive与ClickHouse中的指标是否一致；如果不一致，报警并熔断任务,User Story 2：某流量级产品商业化系统，M级日志条数/秒；希望秒级监控日志延迟、关键字段空值，T+1检测日志波动率；,User Story 3：某数据开发团队希望能够规范化数据上线流程；数据上线报告中必须产出新旧数据对比报告。,数据质量挑战,需求场景复杂,海量数据,有限资源,VS

3、,02,解决方案,产品功能架构,离线数据质量监控-解决批和微批监控场景流式数据质量监控-解决流式监控场景数据探查-解决数据内容探查场景数据对比-解决新旧表数据不一致场景,产品功能简介,离线数据质量监控,实时数据质量监控,数据对比,系统架构,图片区域,整体技术框架,Scheduler-外部调度器，触发离线监控Backend-后端服务，服务层Executor-执行器，计算单元Monitor-状态流转服务，提供重复报警等功能Alert Center-外部报警服务，接收各种报警事件,离线数据检测流程,图片区域,离线数据监控、探查、对比，执行流程一致：1.监控触发调度系统调用质量模块Backend AP

4、I2.作业提交Backend以Cluster模式提交Spark作业至Yarn3.结果回传作业结束(成功、失败)，Driver将结果sink 至Backend4.消息触发Backend 根据结果触发相应动作(eg:报警、消息提示),优劣,劣势：1.非CPU密集型查询较重不需要启动Spark的作业仍会启动一个Spark作业，如ES SQL 查询2.依赖Yarn做调度稳定性不够高,优势：1.调度系统低耦合低相比于其他直接依赖于调度系统执行监控2.事件触发，高效；Backend水平扩展能力强事务需要处理好3.没有Quota 限制把Quota 问题转化为用户资源问题,流式监控执行,图片区域,流式监控流程

5、：1.根据规则定义，创建Flink作业2.根据报警条件，注册Bosun报警事件3.Flink作业消费Kafka数据，计算监控指标写Metrics4.Bosun基于Metrics的时序数据，定时检测，触发报警5.Backend接收报警回调，处理报警发送逻辑,Executor 实现,图片区域,注：Executor 基于Apache Griffin 项目中的 measure 改造,Executor(Griffin Measure)是一个Spark Application功能包括：-适配Data Source-数据转化为DataFrame-规则转化为sql操作-计算结果选型原因:-扩展性强，可适配hi

6、ve/mysql等不同data source-计算性能强-支持多种监控类型,改造：-改造Source、Sink 使其能够通过Http 访问远程API-部分功能增强、修改，eg：支持正则表达式-流式监控从Spark Engine切换为Flink Engine，优化整体流式监控方案,Monitor 实现,功能：-提供重复报警、消息失败重试功能-提供executor 心跳异常检测功能架构要点：有状态服务，主节点对外提供服务；主备保证HA接收Backend事件：监控失败、报警内存定时队列，事件性触发机制,03,最佳实践,表行数信息 优先HMS获取,主要流程：1.引擎记录表行数到相应分区信息中2.优先从

7、HMS获取行数，失败则fallback到提交Spark作业效果：HMS获取行数占比约 90%HMS行数监控平均运行时长 5s.,注：这个功能需要推动底层服务配合支持，比如spark 需要把保存在本地metric 里面的信息写入到Hive MetaStore 中，其他数据传输系统也需要支持。,离线监控优化,1.Griffin Measure 模块功能裁剪&优化：裁剪掉部分异常数据收集功能 优化非必要的join 流程2.执行参数优化 根据不同的监控类型，添加不同的参数(shuffle to hdfs etc.)根据监控特性，默认参数优化（上调vcore etc.）效果：各类监控平均运行时长缩短 1

8、0%,21,引入OLAP 加速执行,在数据探查场景：-引入presto-快速fail机制，大数据量、计算复杂的探查任务fallback到提交Spark作业效果：-执行中位数从 7 min 下降至 38s，-presto 成功率 90%注：目前在尝试利用presto加速数据质量监控,流式监控的资源使用优化,1.Kafka 数据抽样Flink Kafka Connector 支持抽样，即直接操作kafka topic 的offset 来达到抽样的目的。比如，我们按照1%的比例进行抽样，原来上W个partition的Topic，我们只需要*个机器就可以支撑。,2.单Topic 多Rule 优化和离线

9、监控相比，流式作业相对而言需要占用更多高优资源利用监控不是CPU 密集型作业的特性，复用读取部分，单slot 中执行多个rule,04,未来演进方向,24,底层引擎统一，流批一体,当前引擎：批式：Spark流式：FlinkOLAP:Presto 未来探索：流&批：FlinkOLAP:Flink Or Presto？,智能、便捷、优化,1.智能基于智能算法实现主动式数据质量问题发现根据数据等级自动推荐质量规则2.便捷数据据探查&数据对比应用与数据开发流程质量报警的自动归因3.优化-单一Job，同时运行多个监控-监控和数据探查结合,26,欢迎加入,欢迎加入 火山引擎DataLeap1.大数据研发治理套件：DataLeap2.开源数据集成引擎：BitSail 还有更多.,