手机上如何做网站,如何自己做一个app软件,wordpress salient,wordpress 添加角色作者简介 九号#xff0c;携程数据技术专家#xff0c;关注数据仓库架构、数据湖、流式计算、数据治理。 一、背景 元数据MetaData狭义的解释是用来描述数据的数据#xff0c;广义的来看#xff0c;除了业务逻辑直接读写处理的那些业务数据#xff0c;所有其它用来维持整个… 作者简介 九号携程数据技术专家关注数据仓库架构、数据湖、流式计算、数据治理。 一、背景 元数据MetaData狭义的解释是用来描述数据的数据广义的来看除了业务逻辑直接读写处理的那些业务数据所有其它用来维持整个系统运转所需的信息数据都可以叫作元数据。比如数据表格的Schema信息任务的血缘关系用户和脚本任务的权限映射关系信息等等。 在数据仓库的建设质量的评估中一个必不可少的评价指标就是数据产出的及时性特别是对于P0级别的流程及时性指标的好坏一方面决定了下游应用方能否准时地获取所需的业务指标直接影响到业务的工作效率另一方面也反映了相应指标的数据架构的合理程度。 数据及时性顾名思义就是测试数据需要按时产出。及时性重点关注的三个要素是定时调度时间、数据任务优先级以及数据产出deadline。其中任务的优先级决定了它获取数据计算资源的多少影响了任务执行时长。数据deadline则是数据最晚产出时间的统一标准需要严格遵守。这三要素中属于业内统一认知且在质量保障阶段需要重点关注的是数据deadline这也是我们优化数据流程产出的最终评判标准。 二、问题 上述部分已经阐述了数据及时性的重要性和评判标准在通常情况下为了提升数据及时性需要投入人力对重点数据流程进行优化。 但针对数据仓库业界来讲对于一个重要的数据结果其上游可能存在几十个层级数百个不同的数据处理任务从最初的数据到最终的结果数据流转过程极其复杂传统的通过人工逐个排查的方式去定位影响数据流程产出的问题节点存在如下的三项缺点 1覆盖的任务范围有限2效率低下判断标准不统一判定准确率不高3无法形成知识沉淀依赖于个人能力 如果数据流程未能充分优化一方面会存在数据结果产出时间不稳定影响数据的及时性另一方面也会造成计算资源和存储资源的浪费并且也不易于后续维护。 三、方案 为了避免上述的问题提升数据流程优化的效率和质量我们采用了从血缘元数据出发的方案。在数仓任务的执行中都会依赖于一个调度系统组件目前业内通用的是以DAG为核心的工作流系统数据流程中的每个任务都会设置定时执行或者配置上游依赖这些设置的上游依赖就是我们方案中需要的调度血缘的元数据。 基于上述的血缘数据我们的方案中需要实现以下两个功能 基于任务之间的血缘关系生成所有上游任务的层级依赖数据 以调度系统本身的元数据作为出发点调度系统自身的元数据就包含了一个任务的上游和下游依赖基于这个数据通过层级递归的扫描就可以得到指定根节点任务的所有上游任务的层级依赖结果。 设计合理的算法定位到有问题的任务 在上一步骤得到指定根节点任务的所有上游任务的层级依赖结果后通过如下三种逻辑定位有问题的任务 1定位过度分层JobA的下游只有JobA1在使用且JobA是JobA1产出的关键路径也即JobA1的产出时间由JobA决定那么此种情形下我们可以把JobA的逻辑合并到JobA1这样一方面可以减少大数据任务的启动消耗时间和获取资源的时间另一方面也可以减少依赖层级方便后续维护。 2定位重复依赖在较复杂的数据流程中会出现如下的情况JobB2依赖JobB1和JobB而JobB1也同时依赖JobB简化后的情况如下图 此时我们就可以检查JobB2的逻辑考虑任务内容中涉及到JobB的逻辑合并到JobB1从而可以实现流程依赖和代码逻辑的合并优化降低维护成本提升整体产出时间。 3定位关键路径:在完成上述两个步骤后整个流程从结构上已经基本没问题如果要进一步优化产出时间需要针对特定任务进行调优此时可以基于已有的上游层级依赖数据计算得到每个层级的最晚产出的任务Id这些任务Id串联在一起就是影响整个流程产出的关键路径然后对关键路径上的任务进行调优。 上述方案的整体设计图如下 四、案例 在对酒店订单明细宽表的优化过程中基于前期的元数据建设主要的工作内容分为以下三个步骤 1调度优化。调度优化的出发点是合理分配同步任务的优先级将非核心任务的数据同步延后。从而降低0到2点酒店订单宽表核心流程执行期间的集群资源压力。 2模型优化。在这一步骤中我主要是从两个方向出发 减少跨层级重复依赖避免相似逻辑代码的出现提升数据结果的复用能力。避免滥用分层对冗余的分层、中间表进行合并减少任务调度链路的层级减少Job数量节省Job的启动时间。 3任务优化。通过调整参数设置、SQL逻辑优化的方式对具体任务进行优化需要优化的任务。这一步骤的工作也就是传统认知中的任务优化。 其中第二步和第三步就是基于本文中的方案快速定位到问题任务整体优化后的效果如下 酒店订单明细宽表的7日平均产出时间由2:51提前到1:36提升45%全流程任务总数量从211个降到145个减少32%可控上游依赖任务(非外BU任务)总数量由180降到117减少35%关键链路调度层级由11层减少到6层且其中两层是外部BU任务 五、展望 基于元数据和血缘建设本方案后续有如下三点可以深入优化 跨多层判断重复依赖。由于上述实际案例中的酒店订单流程相对不复杂在仅进行一层的重复依赖判断后就已经达到了比较满意的优化效果所以为继续进行多层重复依赖的判断但从血缘结构上是可以支持多层判断的。定位多Job中重复/相似逻辑。多个任务依赖同一个上游任务可以人工进行判断是否存在可合并的重复/相似逻辑这一点如果要提升效率需要再结合表的血缘关系一起判断。多数据流程的优化。在数仓的工作中一个主题域产出的结果表通常会存在多张在进行整个主题域流程的优化或者重构中也可以利用本案的思想结构化进行优化工作提升效率。 【推荐阅读】 贝叶斯结构模型在全量营销效果评估的应用节约60%开发工时离在线一体化数仓系统在携程旅游的落地实践提速10倍StarRocks 指标平台在携程火车票的实践携程火车票基于因果推断的业务实践 “携程技术”公众号 分享交流成长
