火山发动机的数据质量平台在击败当今头条新闻，杜林和其他业务的服务字节的过程中进行了抛光。今天，当今的头条新闻和杜林等复杂的数据质量方案，数据质量平台如何满足各种需求？
本文将介绍火山引擎数据质量平台如何带来数据质量验证和计算消耗资源的冲突以及在大数据方案中长期检查计算时间，并介绍如何使用一组架构框架来满足数据质量平台流量批准方面质量监测。
从广义上讲，数据质量的定义是满足一组固有特征（质量维度）的要求的数据程度。行业中通常有6个维度：
我们有一些有关数据质量的过程和规格，并为上述某些维度开发了一组数据质量平台，主要关注数据质量及其生产链接。
上图显示了数据质量平台在数据开发过程中可以提供的功能：
数据质量平台的最具代表性功能是重复数据开发平台生成的Hive表数据的主要关键数据。
数据质量监视的最有用场景是防止数据问题扩散到下到达范围。例如：数据任务产生一个蜂巢表，该表可能会将某些信息与Hive Metastore（HMS）同步。HMS的主要和次要体系结构可能具有一个某些延迟。假设HMS存在问题，下游任务可能会读取脏数据。目前，如果我们使用数据质量监控，我们可以及时找到问题，以防止下游任务运行。
当前的数据挑战是什么？您可以通过几个用户学习。
用户故事1
流量重量产品的商业化系统，M级日志的数量/秒；我希望第二级监视日志延迟，密钥字段的短值和t+1检测日志波动率。
用户故事2
在内部业务系统中，日志存储ES；我希望每5分钟在上一个周期中检测到日志的波动。
用户故事3
在内部指标平台中，业务数据定期从Hive到Clichouse同步；我希望在每次同步任务之后，检查Clickhouse中的指示器是否。
通过上述介绍，每个人都应该粗略地理解当前数据质量需要解决的问题。一些学生可能已经说过我也完成了数据质量平台，并且问题并不复杂。简而言之，计算数据。与阈值计算相比，它通常可以直接依靠火花发动机或Hive Engine计算。
首先是场景要求非常复杂：
此外，字节将为各种产品生成大量日志数据，我们需要使用有限的资源来满足每个人的质量监控需求。
面对这些挑战，我们的解决方案是什么？
火山发动机流批量数据的质量解决方案具有4个大功能：
上图是数据质量平台的系统体系结构图，该图主要分为5个部分：
离线数据检测过程
让我们看一下离线数据的检测过程。
离线数据监视，检测和比较的执行过程一致，主要分为4个步骤：
我们总结了数据质量平台的优势：
当然，任何工具都不是完美的。暂时还有一些地方可以改进：
流监视执行
为了监视流数据，我们选择了Flink Engine，因为流数据与离线数据不同，并且无法以低成本方法获得该过程，以使用快照。因此，我们需要依靠一些外部时间安排数据库加规则引擎以显示数据的监视。
在平台上流式数据监视的过程是：
下面介绍了两个模块的实现。
执行程序是基于Apache Griffin的度量模块转换的火花应用程序。该功能包括：
执行人的选择有以下考虑：
考虑到上述信息，我们选择了Apache Griffin的度量模块作为executor。它是基于Spark，它可以适应不同的数据源，并且已经对DSL进行了一系列扩展。基于平台设计，我们需要与后端进行更多互动并将数据返回。实际上，格里芬度量本身支持一些基本的数据质量监控，例如重复检测，自定义SQL等。这里的焦点显示了我们对测量模块的转换：
监视器模块主要是为了实现故障警报和重复Thelarm函数的故障，根据事件类型的类型触发相应的事件（重复警报，失败等）。由于业务数据都存储在MySQL中，在平台重复警报之前，监视更简单，即直接从旋转方法中的MySQL查询中取出警报实例，然后重复提交警报。
随着监视规则的越来越多，图书馆的压力将很大。Monitor的扫描也遇到了一些瓶颈。因此，我们升级了监视器的技术结构。特定转换内容包括：
较早介绍了数据质量平台的某些实现方法。以下介绍了数据量和资源两个方面的一些最佳实践。
在内部离线监视中，桌线数量的监视比例非常大，至少50％的离线规则可能是监视这些台词的数量。对于表行的数量，我们先前已提交家庭作业通过Spark，选择“计数”*，它消耗了大量资源消费。
稍后，我们进行了一些优化。在提交任务的过程中，基础引擎记录了表行的数量到输出表期间的相应分区信息，我们可以直接从HMS分区获得表行信息的数量避免提交火花任务。
优化效果非常明显。目前，对于对表行数量的监视，HMS采集约为90％，HMS行监视的平均操作时间位于第二级。
注意：此功能需要促进基础服务的支持。例如，Spark需要编写存储在HMS本地度量标准中的信息，并且需要支持其他数据传输系统。
这件作品是基于格里芬的措施。测量本身具有丰富的功能。我们将其及时剪切。主要的裁缝和优化包括：
此外，我们还优化了离线监视的执行参数，主要包括：
例如：用户为数据编写了SQL。执行引擎可以分析执行计划。对于联接类的操作，洗牌可能很大。在这种情况下，我们将默认打开一些SPARK参数。
根据表线的数量，可以预测数据表的大小。如果数据表相对较大，则默认情况下会罚款-tune vCore和内存。上面的优化可以在一定程度上提高性能。目前，该平台上各种监控的平均运营时间缩短了10％以上。
平台上的许多数据表和业务表（日志表除外），仓库上部的表监视数据的数量不是很大，这种情况非常适合OLAP查询。
在这种情况下，我们在数据探索方案中介绍了Presto。在这种情况下，它是通过Spark探索的。引入PRESTO后，引入了快速失败机制，并将大量数据量和计算复杂勘探任务后备退回到Spark操作中。效果非常重要。
KAFKA数据采样
一般流数据的问题是一个普遍的问题，可以通过数据采样发现问题。因此，我们已经开发了数据采样功能以减少数据资源的比例。FlinkKafka Connector支持采样，可以直接操作Kafka主题的Officet。为了实现抽样的目的。例如，我们根据1％的比例进行采样。最初，我被用于分区主题。我们只需要一台机器来支持它。
单主题多-RUN优化
最早，我们将规则定义为一个主题，然后打开了一个flink任务，以进行消费和执行规则。Later，我们发现某些关键数据需要监视多个维度，即定义多个维度的规则。每个规则消费是非常耗时的。因此，Features，重用读数，在单个插槽中执行多个规则，对主题级别进行单一的消费，并在一个任务中执行相关规则。
本文介绍了数据质量平台的实现和最佳实践，最后讨论了该平台的未来发展方向。
问：数据质量问题是非常时间的 - 成本非常高的成本。您对数据质量问题的归因分析有任何工作吗？
答：这个问题是一个非常核心的痛苦点。在这里我们可以介绍我们当前的想法：与Byte Beating Algorithms结合使用数据钻的学生，即每个数据链接的数据检测。如果发现质量问题，请找到上游数据通过一些类似于血液与田间关系的关系上游。在场时，我们正在采取这种探索方式+过程，以尽快了解上游数据，并且对这些部分的分析并未取得任何进展暂且。
问：数据质量封闭循环如何：例如，谁通过数据质量问题解决了谁？如何衡量数据质量？
答：谁将解决数据质量问题？谁在关注数据的质量，谁去推动，谁开发数据，谁解决了数据的质量。这是一个协作的问题。
如何衡量数据质量？我们有一些治理指标，例如警报量，任何核心警报率。
问：如何确保结束数据一致性？
答：末端到端数据的一致性不是可以解决的单个工具，并且可能需要一些解决方案，例如从末端报告的数据，与埋入的点系统结合在一起，以确定数据验证发布版本是准确的。内容是准确的。EssenceHowever，我认为目前在整个行业中缺少末端到端数据的一致性。如果业务方面存在问题，很难调查。如果您监视数据链接的每一层，则可能相对简单地调查，但是这种方法的成本相对较大。