dbaplus社群TB@携程机票数据仓库11年技术栈的演进( 四 )


数据质量体系
对庞大的数据仓库实体建设完善的数据质量监控体系 , 光靠人工onebyone设置检验规则是不够的 , 需要对几乎所有的实体建立相应的监控 , 并且不能给大数据集群带来很多额外的计算代价 。 当这样的覆盖面很广的监控完善后 , 配合着元数据信息 , 就有可能在故障的RootCause点第一时间发现故障 , 并可以清晰地知晓故障的影响范围以及故障恢复的流程优先级调度 。
因此 , 建立完善的数据质量体系需要完善元数据管理 , 建立轻量的覆盖面广的质量监控 , 并且对特别重要的流程 , 需要增加额外的业务相关校验 。
1、元数据管理
在生产环境和大数据环境存在多种实体 , 这些实体包括应用、各类表(如SQLServer、MySQL、MongoDB的表等)、消息队列topic、ElasticSearch的index、Hive的表等等 , 这些实体相互关联 , 共同支撑着线上的系统 , 线下的分析 。 对这些信息的治理 , 实体的元数据管理至关重要 。
在数仓体系中 , 元数据主要包含基础信息、血缘关系以及标签 。 基础信息跟数据表相关 , 具体包括表的字段、存储、分区类型等;血缘会涉及到各类的实体 , 表、流程、报表、邮件推送等 , 这些实体之间存在着上下游调用与被调用关系 , 成体系地管理好这些实体之间的关系 , 可以清晰地了解到数仓边界 , 使得对故障的RootCause追溯以及该RootCause带来的影响面评估非常便捷 。 标签是对实体的分类描述 , 如层级是属于哪一层 , 安全是否有涉密 , 重要等级 , 是否有非常重要的流程在上面 , 业务标签是属于订单、前端还是订后 。
2、数据质量相关因素
数据质量的问题其实一般可以在流程执行的日志中看出端倪 , 因为人工排查故障的时候 , 除了常规通过SQL查询验证表的增量、业务主键、某些字段值是否正常 , 另外一个有效手段就是分析运行日志 。
从运行日志中可以获取以下信息 , 流程的开始时间、截止时间流程执行时间、完成状态、每天增量的字节数、增量条数 , 引擎执行的参数 , 在用Spark或者MapReduce执行时消耗资源的情况等等一系列特征 。 通过对各类计算引擎产生日志的分析 , 可以获得各类引擎下记录日志数据的pattern , 从而提取出相关的特征信息 。 遇到特殊的流程或者引擎 , 可以借用其他手段补齐特征数据 , 如用SQL , 用Hadoop的命令 。
dbaplus社群TB@携程机票数据仓库11年技术栈的演进
文章图片
图8数据质量相关特征
这是我们简单的一个日志输出 , 第一张是Spark的执行日志 , 下面一张是MapReduce的执行日志 。
dbaplus社群TB@携程机票数据仓库11年技术栈的演进
文章图片
dbaplus社群TB@携程机票数据仓库11年技术栈的演进
文章图片
图9MR和Spark引擎执行日志示例
有了数据质量特征提取的逻辑 , 实时流程异常发现可以如下实施:我们可以将质量特征数据计算分成两块 , 一块是实时的针对单个流程日志的解析出相关特征 , 一块是离线的基于历史特征数据的统计 。 我们从消息队列中消费实时获取执行完成的流程id和actionid , 通过运维团队提供的详情日志查询接口获取完整日志 , 通过特征解析逻辑 , 解析出实时的流程质量相关特征 , 匹配历史数据 , 应用规则 。 当满足异常规则 , 可以通过元数据信息中的血缘判断影响的范围 , 推送告警信息 。
dbaplus社群TB@携程机票数据仓库11年技术栈的演进
文章图片
图10实时流程异常监控实施方案
应用案例
携程作为平台方 , 对机票价格没有定价权 , 价格由产品提供方来提供 。 在每年航班计划换季的时候 , 产品提供方会有一小部分概率将价格录入错 。 错误的运价 , 特别是很低的错误运价会让航司或供应商蒙受超大的损失 。 本着公平交易的原则 , 携程作为销售平台 , 做了机票价格监控系统 。 上线至今 , 发现了数十起价格异常事件 。