更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群
最佳实际
后面介绍了 DataLeap 数据品质平台的一些实现形式，上面为大家介绍一些咱们在数据量和资源这两个方面的最佳实际。
表行数信息 - 优先 HMS 获取
外部的离线监控中，表行数的监控占比十分大，可能至多 50% 以上的离线规定都是表行数的监控。对于表行数，之前咱们是通过 Spark，Select Count* 提交作业，对资源的耗费十分大。起初咱们对其做了一些优化。在工作提交的过程中，底层引擎在产出表的过程中将表行数记录写入相应分区信息中，咱们就能够间接从 HMS 分区里间接获取表行数信息，从而防止了 Spark 工作的提交。
优化后的成果非常明显，目前对于表行数的监控，HMS 获取行数占比约 90 %，HMS 行数监控均匀运行时长在秒级别。
注：这个性能须要推动底层服务配合反对，比方 Spark 须要把保留在本地 metric 外面的信息写入到 HMS 中，其余数据传输零碎也须要反对。
离线监控优化
这一块是基于 Griffin 的 Measure 来进行，Measure 自身有丰盛的性能，咱们对其进行了裁剪以节约耗时。次要的裁剪和优化包含：
- 裁剪掉局部异样数据收集性能；
- 优化非必要的 join 流程。
另外，咱们也对离线监控的执行参数进行了优化，次要包含： - 依据不同的监控类型，增加不同的参数 (shuffle to hdfs 等)；
- 依据监控个性，默认参数优化（上调 vcore 等）。
举个例子：用户写了 SQL 进行数据的 join，执行引擎能够剖析出执行打算。对于 join 类的操作，shuffle 可能十分大，这种状况下咱们默认会开一些 Spark 参数。依据表行数来预判数据表的大小，如果判断数据表比拟大，会默认微调 vcore 和 memory。以上这些优化都能在肯定水平上晋升性能，目前平台上各类监控的均匀运行时长缩短了 10% 以上。
引入 OLAP 引擎
平台上很多数据表和业务表（除了日志表以外），在数仓下层的表监控数据量不是很大，这种状况很适宜进行 OLAP 的查问。这种状况下咱们在数据探查场景引入了 presto。之前在该场景下通过 Spark 做探查，引入 presto 之后通过疾速 fail 机制，大数据量、计算简单的探查工作 fallback 到提交 Spark 作业，探查工夫中位数从之前的 7min 缩短到目前的不到 40s，成果十分显著。
流式监控反对抽样 & 单 Topic 多 Rule 优化 Kafka 数据抽样
个别流式数据的问题都是通用性问题，能够通过数据采样发现问题。因而咱们开发了数据采样的性能，缩小数据资源的占比耗费。Flink Kafka Connector 反对抽样，可间接操作 kafka topic 的 offset 来达到抽样的目标。比方，咱们依照 1% 的比例进行抽样，原来上 W 个 partition 的 Topic，咱们只须要 ** 个机器就能够撑持。
单 Topic 多 Rule 优化
最早的时候咱们是对一个 Topic 定义一个 Rule，而后开启一个 Flink 工作进行生产，执行 Rule。起初咱们发现一些要害的数据须要对多个维度进行监控，也就是要定义多个维度的 Rule，对每一条 Rule 都开工作去生产是十分耗资源的，所以咱们利用监控不是 CPU 密集型作业的个性，复用读取局部，单 slot 中执行多个 Rule，对 Topic 级别进行繁多生产，在一个工作中把相干 Rule 都执行完。将来演进方向
本文介绍了 Dataleap 数据品质平台的实现和最佳实际，最初谈谈平台将来的演进方向。 - 底层引擎对立，流批一体：目前平台的离线工作大部分是基于 Spark 实现的，流式数据采纳了 Flink 解决，OLAP 引擎又引进了 presto，导致这套零碎架构的运维老本比拟高。咱们看到 Flink 目前的 presto 能力和 Flinkbatch 的能力也在一直倒退，因而咱们后续会尝试切一些工作，做到真正意义上的对立引擎。
- 智能：引入算法进行数据驱动。思考引入 ML 办法辅助阈值选取或者智能报警，依据数据等级主动举荐品质规定。举几个例子，比方咱们能够基于时序算法智能的稳定率监控来解决节假日流量顶峰和平时的硬规定阈值的晋升。
- 便捷：OLAP 对性能晋升比较显著，然而目前咱们只用在了数据探查性能上。后续能够将 OLAP 引擎利用于品质检测、数据据探查、数据比照利用与数据开发流程。
- 优化：比方通过繁多 Job，同时运行多个监控，将监控和数据探查联合。咱们当初在尝试将数据品质的规定生成和数据探查做联合，做到所见即所得的数据和规定的对应关系。
点击跳转大数据研发治理套件 DataLeap 理解更多