火山引擎流批数据质量解决方案和最佳实践.docx

上传人:lao****ou 文档编号:86634 上传时间:2023-02-20 格式:DOCX 页数:18 大小:254.17KB
下载 相关 举报
火山引擎流批数据质量解决方案和最佳实践.docx_第1页
第1页 / 共18页
火山引擎流批数据质量解决方案和最佳实践.docx_第2页
第2页 / 共18页
火山引擎流批数据质量解决方案和最佳实践.docx_第3页
第3页 / 共18页
火山引擎流批数据质量解决方案和最佳实践.docx_第4页
第4页 / 共18页
火山引擎流批数据质量解决方案和最佳实践.docx_第5页
第5页 / 共18页
亲,该文档总共18页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《火山引擎流批数据质量解决方案和最佳实践.docx》由会员分享,可在线阅读,更多相关《火山引擎流批数据质量解决方案和最佳实践.docx(18页珍藏版)》请在第一文库网上搜索。

1、火山引擎流批数据质量解决方案和最佳实践导读:火山引擎的数据质量平台是在多年服务字节跳动今日头条、抖音等业务的过程中打磨出来的。面对今日头条、抖音等不同产品线的复杂数据质量场景,数据质量平台如何满足多样的需求?本文将介绍火山引擎数据质量平台是如何弥合大数据场景下数据质量校验与计算消耗资源大、校验计算时间长的冲突,并介绍数据质量平台是如何用一套架构框架来满足流批方面的数据质量监控。作者I Frank,火山引擎高级研发工程师01什么是数据质量广义上来说,数据质量的定义是数据满足一组固有特性(质量维度)要求的程度。业界通常有6个维度:完整性:指数据的记录和信息是否完整,是否存在缺失的情况。数据缺失主要

2、包括记录的缺失和记录中某个字段信息的缺失,两者都会造成统计结果不准确,所以说完整性是数据质量最基础的保障。在做监控时,需要考虑两个方面:数据条数是否少了;某些字段的取值是否缺失。完整性的监控,多出现在日志级别的监控上,一般会在数据接入的时候来做数据完整性校验。准确性:指数据中记录的信息和数据是否准确,是否存在异常或者错误。一般准确性的监控多集中在对业务结果数据的监控,比如每日的活跃、收入等数据是否正常一致性:指同一指标在不同地方的结果是否一致。数据不一致的情况,多出现在数据系统达到一定的复杂度后,同一指标会在多处进行计算,由于计算口径或者开发人员的不同,容易造成同一指标出现不同的结果。及时性:

3、在确保数据的完整性、准确性和一致性后,接下来就耍保隙数据能够及时产出,这样才能体现数据的价值。及时性很容易理解,主要就是数据计算出来的速度是否够快,这点在数据质量监控中可以体现在监控结果数据是否在指定时间点前计算完成。规范性:指数据是否按照耍求的规则进行存储,如邮箱校验、IP地址校验、电话格式校验等,具有一定的语义意义。唯一性:指数据是否有重复,如字段的唯一值、字段的重复值等。我们对数据质量有一些流程和规范,并针对上述一些维度开发了一套数据质量平台,主要关注数据质量及其生产链路。命名规范数据探查数据对比数据监控指标定义开发规范数据验证任务监控上图展示了在数据开发的流程中,数据质量平台可以提供哪

4、些功能:数据探查:可以根据各种维度来查看数据明细和分布情况。数据对比:开发同学可能经常会发现线上表和测试表不一致,所以我们在任务上线的环节提供了数据对比的功能。任务监控:监控线上数据,提供报警和熔断功能。数据质量平台最有代表性的功能是:对数据开发平台产出的Hive表数据进行主键重复检测,如果存在重复则进行报警。数据质量监控最有用的场景是防止数据问题蔓延到下游。举个例子:数据任务产出一张Hive表,该表可能会同步一些信息到Hive motastorc (HMS) o HMS的主从架构可能存在一定的延迟,假设HMS出现问题,卜游任务可能会读到脏数据,这时如果我们使用数据质量监控,就能及时发现问题,

5、阻止下游任务运行。02数据质量挑战目前我们的数据质量挑战有哪些?可以通过几个用户case 了解一下。User Story 1某流量级产品商业化系统,M级日志条数/秒;希望秒级监控日志延迟、关键字段空值,T+1检测日志波动率。User Story 2某内部业务系统,日志存储ES;希望每5分钟检测上一周期日志波动情况。User Story 3某内部指标平台,业务数据由Hive定期同步到Clickllouse;希望每次同步任务后检查Hive与ClickHouse中的指标是否一致。通过上面的介绍,大家应该也大致清楚了当前数据质量需要解决的问题。可能有些同学会说,数据质量平台我也做过,问题归总起来也不复

6、杂,总而言之就是对数据进行各种计算,对比计算来的阈值即可,一般直接依赖于Spark引擎或者Hive引擎计算即可。确实,其实这也是我们数据质量最开始的样子。那为什么会演化到目前这样,我们面临了一些什么问题?首先是场景需求非常复杂:1、离线监控不再多说了,大家都熟悉,主要是不同存储的数据质量监控,比如Hive或者ClickHouse 。2、字节跳动内部的广告系统对时效性和准确性要求很高,用广告同学的话说,如果用微批系统10 min才做一次检测,可能线上损失就上百万了甚至千万了。所以广告系统同学对实时性要求相对较高。3、另外一个是复杂拓扑情况下的流式延迟监控。4、最后是微批,指一段时间内的定时调度,

7、有些Kafka导入ES的流式场景,需要每隔几分钟对比下前一周期。此外,字节跳动各种产品会产出海量的日志数据,我们需要用有限的资源来满足大家对质量监控的需求。面临这些挑战,我们的解决方案是什么?03流批数据质量解决方案产品功能架构火山引擎流批数据质量解决方案有4个大的功能:离线数据质量监控:解决批和微批监控场景,支持Hive、ClickHouse. ES等多种数据源,并有字段、唯一性等多种监控维度,允许通过SQL自定义维度聚合进行监控。流式数据质量监控:解决流式监控场景,支持Kafka/BMQ等数据源。数据探查:解决数据开发之前对数据内容存疑问题,支持Hive数据源。数据对比:解决新旧表数据一致

8、性问题,支持Hive/Hive SQL数据源。任务开发平台/监控结果04系统架构SchedulerData ProfilingBatch Data QualityStreaming Data QualityData ComparisonMonitor ModuleProfiling ModuleMonitor ManageMonitor AlertData ProfilingData ComparisonRule TriggerTrigger ModuleExecutorSubmitWriteAccuracyOLAP EnginePrestoApache Griffin MeasureComp

9、letnessBatchSpark SQLMonitorValidity ESStreamingWriteConsistencyUniquenessKafkaEvent GlanceAlert CenterAlert ServerMetrics上图是数据质量平台的系统架构图,主要分为5个部分:Scheduler:外部调度器,触发离线监控。主要分两种类型:对外提供API调用任务;定时调度,通过calljob调用数据。Backend:后端服务,偏服务层,处理业务逻辑。主要负责:质量平台和外部的交互,所有API响应都是通过这一层进行;任务提交:用户在质量平台配置的规则会放到业务存储,Schedule

10、r被调用后,Backend会将任务相关的参数配置进行任务提交;获取质量监控的结果并进行判断,然后和外部系统进行交互,在需要时发送警报通知用户。Executor:平台核心的任务执行模块,集成了一些引擎,例如数据探查使用OLAP引擎。质量监控部分使用Griffin的Measure进行数据统计。Monitor:是一个相对独立的模块,主要进行状态服务的流转,提供重夏报警等功能。Alert Center:质量平台强依赖于该平台。它是外部报警服务,接收各种报警事件。离线数据检测流程下面看一下离线数据的检测流程。SchedulerActorVBackendTrigger ModuleAlert Module

11、monitorresulttriggermonitorcreatealertsendalertAlertServicesendstatus/ resultsubmitspark job离线数据的监控、探查、对比的执行流程一致,主要分为4步:1、监控触发:调度系统调用质量模块Backend API;2、作业提交:Backend以Cluster模式提交Spark作业至Yarn:3、结果回传:作业结束(成功、失败),Driver将结果sync至Backend;4、消息触发:Backend根据结果触发相应动作(例如:报警、消息提示)。我们总结了一下数据质量平台的优势:调度系统低耦合:数据质量平台没有和

12、调度系统强绑定,一般可以用业务系统的API实现互相调用。事件触发高效,Backend水平扩展能力强:Backend是无状态的实例服务,如果质量监控的业务系统较多,Backend可以采用水平扩展的方式部署,接收请求并提交作业。没有Quota限制:平台本身没有维护数据质量监控单独需要的资源队列,而是把这个权限开放给用户,用他们自身的资源做资源监控。这样就把Quota问题转换成了用户资源问题。当然任何一个工具都不可能是完美的,数据质量平台暂时还有一些待提升的地方:非CPU密集型查询较重:整个平台的设计是以任务提交的方式完成离线场景的需求。但是后来我们发现其实不需要启动Spark的作业仍然会启动一个S

13、park作业,如ES SQL查询,这个查询是很重的。依赖Yarn做调度稳定性不高:平台上的任务在资源不充足或被挤占的情况下,会出现任务运行或调用很慢。流式监控执行对于流式数据的监控,我们选择了 Flink引擎,因为流式数据不同于离线数据,不能用快照的方式低成本拿到过程。所以我们要依赖一些外部的时序数据库再加规则引擎来展示对数据的监控。平台上流式数据监控的流程为:1、根据规则定义,创建Flink作业;2、根据报警条件,注册Bosun报警事件;3 Flink作业消费Kafka数据,计算监控指标写Metrics;4、Bosun基于Metrics的时序数据,定时检测,触发报警;5、Backend接收报

14、警回调,处理报警发送逻辑。卜.面着重介绍两个模块的实现OExecutor 实现Apache Griffin MeasureAccuracyValidityConsistencyCompletnessUniquenessBatchStreamingSpark SQLFlinkESKafkaExecutor 是基于 Apache Griffin 的 Measure 模块改造的一个 Spark Applicationo 功能包括:适配数据源数据转化为DataFrame规则转化为SQL操作计算结果Executor的选型有以下几方面的考虑:扩展性要足够强,能够适配不同的数据源,如Hive, MySQL等等计算性能要较强支持的监控类型种类需要足够多考虑到以上方面的信息,我们选用了 Apache Griffin的Measure模块作为Executor。它基于Spark开发,能够适配不同的数据源,并且对于DSL做了一系列拓展。基于平台的设计,我们需要和Backend进行较多的互动,并把数据进行回传。其实Griffin Measure本身就支持了一些基本的数据质量监控,比如重复值检测、自定义SQL等等,这里

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 应用文档 > 汇报材料

copyright@ 2008-2022 001doc.com网站版权所有   

经营许可证编号:宁ICP备2022001085号

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有,必要时第一文库网拥有上传用户文档的转载和下载权。第一文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知第一文库网,我们立即给予删除!



客服