B站大数据质量务实

吉雅

本期作者郭跃鹏软件工程师01 背景数据质量是基于大数据衍生的应用有效与否的重要的前提和保障之一。为了能在大数据上面孵化出更加有深度，更加有竞争力的应用，以及B站高速发展的业务都需要我们数据平台能提供实时的，准确的，可以被信赖的数据。而另一方面，数据平台要向终端用户提供可以信赖的数据，又依赖于整个数据加工链路环境的稳定迭代和健康发展，这涉及到数据平台模型本身的质量，业务调度的可靠，资源调度的高效，以及各种执行引擎的高效协作等等，最后所有这些大数据基础组件的稳定又离不开PAAS, IAAS等基础服务的稳定。总之，可信赖的数据质量是大数据平台核心竞争力的体现，是大数据航母战斗群的预警机。数据质量团队的背后是大兵团级别的组织、协作和保障工作。数据质量的高可信度依赖于业务模型团队，数据质量平台，业务调度团队，计算引擎团队，和各种存储和搜索查询引擎等兄弟舰队通力合作和鼎力支持。02 目标快速发现和修复问题是我们大数据质量团队的使命。我们有接近1亿的日活用户依赖于我们的数据，为了服务于这些用户，我们每天有30w+的任务处理40PB左右的数据，实时管道每天消费处理6万亿条的事件和日志，为了杜绝用户用错数据的风险，经过我们持续迭代，分阶段，我们逐步的实现了如下三个子目标。流程化流程化不是一句空洞的口号，是我们长期被事故狂轰乱炸后的经验的总结，是一条行之有效的解决问题的办法。通过流程化，对于一些容易出事故的隘口，定义一些标准的流程SOP，让运维同事对照SOP可以准确无误的上线操作和监控。流程化挑战的地方很多，如如何在复杂的业务中设计出来一套成熟的流程，能全面而且稳定地解决问题。如如何监控我们的系统，到底监控哪些指标？都是需要团队仔细思考和打磨的。最后，流程化接入的成本也要在设计时仔细考量，因为业务千差万别，如何做到业务方接入低成本或者无成本，这对我们的设计的易用性和可扩展性提出来很高的要求。自动化如果说流程化是对B站人工运维场景的总结，那自动化就是对这些运维场景的工业化，自动化让我们彻底的离开了手工时代。这对我们的设计的全面性，兼容性，以及稳定性都提出来更高的要求。智能化智能化是运维迈向自由之路的必然选择，在数据量大，场景多，容易出故障，人员经验不足的情况下，智能化对我们的设计提出来与时俱进的新要求。03 理论与实践数据质量问题是一个大家都非常关注的问题，也正因为数据质量利益方多，管理和沟通容易陷入各说自话的困境。为了避免沟通时无的放矢的困境，我们先正本清源，对数据质量问题具体化，概念化。数据质量可以从很多方面来量化，我们结合B站自身的实际，我们将数据质量问题限定为以下几类。完整性数据是否完整，主要现象为表的条数是否有丢失。唯一性考察的数据集里面是否有数据重复，这个分全量粒度和增量分区粒度。时效性数据可用性的时间维度的要求，这点相信大家对实时数据感受比较明显，但离线也有时效性问题。准确性数据是否按照符合预期的逻辑在产出，如身份证，年龄逻辑上是否自洽。一致性两个数据源之间的数据是否一直，如sum(A.b where A.c ='Shanghai') = sum(B.b)以上划分不一定存在完美的正交划分。一个具体的质量问题，可能既有一致性的特征，也有准确性的特征。数据质量问题本身就是这样，不是非此即彼的划分。我们不必陷入形式主义的困扰。通过上述标准，让不同的利益方沟通更加有效，让我们能快速落地数据质量目标，是我们设立这个标准的目的。?3.1 数据质量理论技术的驱动是需求，大多数用户的需求大概是这样子的：“当我的业务数据，今天的条数的波动大于30%的时候，请给我打电话告警。”不论各个团队什么场景，怎么表述，需求的表象千差万别，经过我们数据质量团队的经验总结(Copyright)，用户的数据质量需求已经被高度抽象为技术上的三段式：?3.1.1 数据质量模型针对高度抽象的需求，我们的整体技术架构设计如下：架构中重要的工作流如图紫色部分所示，一个数据质量问题，我们将它抽象成一个workflow，拆解为三个子stage 。Recording获取需要监控对象的数据质量特征，如表条数这个指标。对于Recording，它的设计面临的挑战之一是，按照业务的场景，我们的监控对象会驻留在各种不同的异构数据源里（Hive, Mysql, Kafka, Hudi, OLAP等等）。这就要求我们，一方面要统一的抽象出这个监控对象，另外一方面，我们需要兼容支持不同的数据源是异构的这个现实。第二个挑战是Recording的结果是什么？不同的场景对于这个结果有不同的诉求。我们数据质量平台经历了多次迭代，如对不同需求CaseByCase的处理而后续难以维护和升级等，找到了一套标准来抽象Recording。那就是，一方面，这个监控对象的数据质量特征必须是可量化的。第二个，对于数据平台来说，这个量化最好是用类SQL的语法来表达监控对象的数据质量特征。通过这套标准，我们能最快速的迭代用户的需求，也能让不同的利益方理解并跟踪大家的诉求。经过多次迭代，我们沉淀出150+中的典型数据质量特征，我们把这些特征做成典型标准库，以便用户能快速选择适合自己场景的数据质量标准。另外一方面，在查询这个特征的时候，我们需要兼容异构的数据源，我们抑制了自己再造轮子的冲动，充分利用开源的框架来connect到不同的异构数据源。我们目前支持的可以被检测的数据源包括但不仅限于：HiveMysqlIcebergClickhousekafkaHudi最后，由于数据平台的环境的多元性，我们有很多场景的数据源是不容易通过数据质量平台connect 连通的。这个问题可以通过push gateway来解决的。用户需要在数据质量平台注册一次，注册这个指标的含义，后续客户端就可以把数据质量特征通过push gateway推送到数据质量平台，后续的检查告警就会被数据质量平台包圆了。Checking判定这个指标是否满足告警的条件，如M