关于数据库:火山引擎DataLeap数据质量解决方案和最佳实践二解决方案

4次阅读

共计 2297 个字符，预计需要花费 6 分钟才能阅读完成。

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群

DataLeap 流批数据品质解决方案

产品性能架构
火山引擎 DataLeap 流批数据品质解决方案有 4 个大的性能：

离线数据品质监控：解决批和微批监控场景，反对 Hive、ClickHouse、ES 等多种数据源，并有字段、唯一性等多种监控维度，容许通过 SQL 自定义维度聚合进行监控。
流式数据品质监控：解决流式监控场景，反对 Kafka/BMQ 等数据源。
数据探查：解决数据开发之前对数据内容存疑问题，反对 Hive 数据源。
数据比照：解决新旧表数据一致性问题，反对 Hive/Hive SQL 数据源。
零碎架构

上图是 DataLeap 数据品质平台的零碎架构图，次要分为 5 个局部：
Scheduler：内部调度器，触发离线监控。次要分两种类型：
1. 对外提供 API 调用工作；
2. 定时调度，通过 calljob 调用数据。
Backend：后端服务，偏服务层，解决业务逻辑。次要负责：
1. 品质平台和内部的交互，所有 API 响应都是通过这一层进行；
2. 工作提交：用户在品质平台配置的规定会放到业务存储，Scheduler 被调用后，Backend 会将工作相干的参数配置进行工作提交；
3. 获取品质监控的后果并进行判断，而后和内部零碎进行交互，在须要时发送警报告诉用户。
Executor：平台外围的工作执行模块，集成了一些引擎，例如数据探查应用 OLAP 引擎。品质监控局部应用 Griffin 的 Measure 进行数据统计。
Monitor：是一个绝对独立的模块，次要进行状态服务的流转，提供反复报警等性能。
Alert Center：品质平台强依赖于该平台。它是内部报警服务，接管各种报警事件。
离线数据检测流程
上面看一下离线数据的检测流程。

离线数据的监控、探查、比照的执行流程统一，次要分为 4 步：
1. 监控触发：调度零碎调用品质模块 Backend API；
2. 作业提交：Backend 以 Cluster 模式提交 Spark 作业至 Yarn；
3. 后果回传：作业完结 (胜利、失败)，Driver 将后果 sync 至 Backend；
4. 音讯触发：Backend 依据后果触发相应动作 (例如：报警、音讯提醒)。
咱们总结了一下 Dataleap 数据品质平台的劣势：
调度零碎低耦合：数据品质平台没有和调度零碎强绑定，个别能够用业务零碎的 API 实现相互调用。
事件触发高效，Backend 程度扩大能力强：Backend 是无状态的实例服务，如果品质监控的业务零碎较多，Backend 能够采纳程度扩大的形式部署，接管申请并提交作业。
没有 Quota 限度：平台自身没有保护数据品质监控独自须要的资源队列，而是把这个权限凋谢给用户，用他们本身的资源做资源监控。这样就把 Quota 问题转换成了用户资源问题。
当然任何一个工具都不可能是完满的，数据品质平台临时还有一些待晋升的中央：
非 CPU 密集型查问较重：整个平台的设计是以工作提交的形式实现离线场景的需要。然而起初咱们发现其实不须要启动 Spark 的作业依然会启动一个 Spark 作业，如 ES SQL 查问，这个查问是很重的。
依赖 Yarn 做调度稳定性不高：平台上的工作在资源不短缺或被挤占的状况下，会呈现工作运行或调用很慢。
流式监控执行
对于流式数据的监控，咱们抉择了 Flink 引擎，因为流式数据不同于离线数据，不能用快照的形式低成本拿到过程。所以咱们要依赖一些内部的时序数据库再加规定引擎来展现对数据的监控。

平台上流式数据监控的流程为：
1. 依据规定定义，创立 Flink 作业；
2. 依据报警条件，注册 Bosun 报警事件；
3. Flink 作业生产 Kafka 数据，计算监控指标写 Metrics；
4. Bosun 基于 Metrics 的时序数据，定时检测，触发报警；
5. Backend 接管报警回调，解决报警发送逻辑。
上面着重介绍两个模块的实现。
Executor 实现

Executor 是基于 Apache Griffin 的 Measure 模块革新的一个 Spark Application。性能包含：
适配数据源
数据转化为 DataFrame
规定转化为 SQL 操作
计算结果
Executor 的选型有以下几方面的思考：
扩展性要足够强，可能适配不同的数据源，如 Hive，MySQL 等等
计算性能要较强
反对的监控类型品种须要足够多
思考到以上方面的信息，咱们选用了 Apache Griffin 的 Measure 模块作为 Executor。它基于 Spark 开发，可能适配不同的数据源，并且对于 DSL 做了一系列拓展。基于平台的设计，咱们须要和 Backend 进行较多的互动，并把数据进行回传。其实 Griffin Measure 自身就反对了一些根本的数据品质监控，比方反复值检测、自定义 SQL 等等，这里重点阐明一下咱们对 Measure 模块的革新：
革新数据源、Sink 使其可能通过 HTTP 拜访近程 API；
局部性能加强、批改，例如：反对正则表达式；
流式监控从 Spark Engine 切换为 Flink Engine，优化整体流式监控计划。Measure 自身是 Spark 生态的一部分，只能用 Spark Engine 做理线或者用微批模仿流式做监控。字节跳动外部自身有肯定的 Flink 的能力，并且 Flink 对流式数据的解决能力比微批要好很多，所以咱们就进行了这样的革新。
Monitor 实现
Monitor 模块次要是为了实现失败报警重试和反复报警性能，依据事件类型触发相应事件（反复报警、失败重试等）。因为业务数据全副存储在 MySQL，平台之前的 Monitor 反复报警做的也比较简单，即间接通过轮询的形式从 MySQL 中轮询拉起已报警实例，而后通过反复提交的形式进行报警。