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

2020/11/20 12:43
阅读数 23

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

一、项目背景介绍

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

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

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

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

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

整个巡检逻辑如下图:

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

三、为什么需要重构

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

  1. 链路过长:链路过于复杂,涉及多个子系统,代码业务逻辑难以理解。开发过程十分痛苦,需要在多个系统之间进行切换。涉及链路过多故障发生的机率也随之大幅提升;

  2. 子系统之间形成循环通信:子系统之间形成循环通信,使架构变的复杂难以维护,需要精简为单向通信;

  3. 系统性能时效性较低:由于使用了通道超时机制,每次检查都需要等待固定的时间,实际业务巡检有长有短,而非花费时间都是统一的;

  4. 系统稳定性不足:由于使用了协程常驻内存检测通道消息,当遇到整个子系统重启后或者发生故障,通道消息丢失,该次巡检便无法更新为完成状态。

四、怎样进行优化

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

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

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

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

五、优化效果

  1. 架构简单清晰,链路得到精简,各个节点只关心自己的数据,不再回传消息;

  2. 巡检数据更加精准,不再有中心节点,不再产生节点结果偶尔被覆盖的情况;

  3. 系统稳定性得到较大提升,发布或dmp-proc意外宕机,都不会影响最终巡检结果;

  4. 提升巡检效率,一.减少通道不必要的等待时间,提升巡检速度;

  5. 客户满意度提升,认可数见平台数据质量巡检体系。

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

作者简介

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

也许您还想看

Go语言plugin的两种实现方式

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

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

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

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

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部