天际数见数据质量巡检架构优化

源宝导读：天际数见平台是一个数据可视化的BI平台，定位于为高层决策提供数据可视化赋能。数据准确性是生命线，如何提前发现数据问题，快速定位和修复问题，成为我们必须攻克的难点。本文将介绍数见平台通过架构优化，提升数据巡检准确率和效率的技术实践。

一、项目背景介绍

天际数见平台是一个数据可视化的BI平台，定位于为高层决策提供数据可视化赋能。数见平台接入多种数据源，屏蔽数据源底层差异，统一将数据呈现给客户。由于数据来源复杂，偶然会出现数据不一致/延迟/抖动等情况，往往是在客户发现问题后反馈给一线，再由一线反馈给技术团队。这种情况不仅给客户造成平台不稳定的错觉，同时沟通过程涉及链条较长导致难以快速定位问题源头。为此数见平台规划了数据质量巡检功能，定时巡检数据准确性/一致性/实时性，并巡检问题的源头，系统第一时间通知相关责任人进行解决。

由于时间紧任务重，团队在较短时间内满足了客户的基本需求，但在使用过程中仍然发现了一些问题，因此决定对该功能进行系统性分析并进行优化。

二、老版本数据质量巡检架构

上图中ERP数据中心即为数见平台数据源的一种（也称之为主题包数据集），可以看出最终接入数见平台的数据链路较长，数据来源较多，与之匹配的数据质量巡检如下图：

说明：DMP为数据可视化平台，RunDeck 为定时任务调度系统，DMP-Proc为任务执行子系统，DMP-Celery为异步任务系统。通过上图可以发现当DMP-Proc子系统处理完成后，通过API和DMP-Celery异步任务系统发生通信，通信完成后DMP-Celery又向DMP-Proc子系统回传消息。

整个巡检逻辑如下图：

通过上图可以发现，DMP-Proc子系统负责向各个节点分发巡检任务，然后处于等待状态，但是由于无法知悉各个节点需要执行的具体时间，因此此处设置了固定等待时间。这种做法实际会造成不必要的时间等待，同时在等待过程中处于协程阻塞状态，无法接收其他巡检任务。若此时系统因为各种原因重启，则该次巡检消息丢失，将永远无法完成直至下次巡检覆盖本次巡检结果。

三、为什么需要重构

通过上面的内容我们可以发现老的数据质量巡检存在以下问题：

链路过长：链路过于复杂，涉及多个子系统，代码业务逻辑难以理解。开发过程十分痛苦，需要在多个系统之间进行切换。涉及链路过多故障发生的机率也随之大幅提升；
子系统之间形成循环通信：子系统之间形成循环通信，使架构变的复杂难以维护，需要精简为单向通信；
系统性能时效性较低：由于使用了通道超时机制，每次检查都需要等待固定的时间，实际业务巡检有长有短，而非花费时间都是统一的；
系统稳定性不足：由于使用了协程常驻内存检测通道消息，当遇到整个子系统重启后或者发生故障，通道消息丢失，该次巡检便无法更新为完成状态。

四、怎样进行优化

1. 精简链路，重新设计表结构，实现每个节点只关注自身业务和节点，中间节点不再处理所有业务，每个节点只关心自身节点数据，完成巡检即更新节点结果，DMP-Proc系统接收到巡检消息后定时轮询各个节点状态，最终更新总状态和结果。

2.通信方式优化为单向通信，子系统不再向中间节点回传信息。由于各个节点只更改本节点数据，不会导致多节点并发更新同一份数据的问题，因此无需再向中心节点回传结果消息。

3.监控超时机制更改为单独的独立协程常驻内存进行监控，不依赖于其他通道传送信息，只依赖于数据库中最终数据。

4.系统启动便开始检测所有巡检节点，及时重启或者异常宕机也不影响。系统每次启动时自动检查状态未结束的巡检节点，重新启动巡检任务。

五、优化效果

架构简单清晰，链路得到精简，各个节点只关心自己的数据，不再回传消息；
巡检数据更加精准，不再有中心节点，不再产生节点结果偶尔被覆盖的情况；
系统稳定性得到较大提升，发布或dmp-proc意外宕机，都不会影响最终巡检结果；
提升巡检效率，一.减少通道不必要的等待时间，提升巡检速度；
客户满意度提升，认可数见平台数据质量巡检体系。

------ END ------

作者简介

曹同学： 研发工程师，目前负责天际-数见平台的后台研发工作。

也许您还想看

Go语言plugin的两种实现方式

在明源云客，一个全新的服务会经历什么？

云客后台优化的“前世今生”(一)

云客后台优化的“前世今生”(二)

回归统计在DMP中的实战应用