货拉拉大数据离线调度渠道功能优化实践

导言

大数据离线开发渠道作为大数据体系最基础的才能之一，从货拉拉大数据部分建立之初便从0开端搭建，支撑恣意数据库数据交换、丰厚的使命分析方法，并提供完善的一站式交互查询服务。

跟着货拉拉事务在全球范围内、八条事务线上打开，货拉拉大数据团队朝着“深度优化基础才能，高效整合中台体系才能，深耕驱动事务智能应用场景”的方向尽力，越来越多的使命与事务场景的接入，也一起给渠道才能带来了更高的挑战。本文迁就离线渠道最近半年内在满意功用、事务需求下，针对离线调度功能做的优化进行简略介绍。

调度布景&逻辑

货拉拉大数据技能体系作为典型Lambda架构，从建设之初便参考了业界大多数大数据体系，咱们挑选了研制门槛低、保护成本较小的离线链路(即Batch Layer)作为开发重心，一方面因为其时实时数据框架体系尚未成熟，另一方面则是考虑便利快速接入原有事务收益更明显，如下图所示：

跟着货拉拉事务在不同事务线的打开、技能数智化设备完善、数据仓库基础建设逐步成型，离线数据的重心也开端从支撑集团报表转变到如何科学赋能事务。在这个抽象的话题中，离线开发渠道的要害点是如何在确保安稳和安全的前提下，高效支撑数据应用、线上服务、数据智能等多种场景，比方数据智能场景中的特征核算部分，既需要离线数仓与特征体系功用打通，又需要离线核算与特征核算流程保持数据与使命语义一致性，使核算出的成果能加快落到特征查询体系等其他服务存储中运用，如下图所示：

在如上场景中，一方面临离线渠道的功用如使命办理、编排，监控告警，API等提出了更高要求，另一方面使命及实例会肉眼可见大幅度添加。

因为当时离线调度采用了单层实体模型，即根据使命等级配置对当时运转周期生成的可运转实例进行下发式调度。大致完成为：周期性从存储中扫描出契合调度下发条件的使命实例，在内存中对依靠及相关边界条件进行核算后再履行下发，分布式的Runner节点进行具体使命履行操作。这种调度方法最大优势是每个实例都会严格核算一遍依靠及下发条件，调度逻辑准确性SLA能很轻松到达100%，可是同样假如同一周期内实例数到达必定量级，依靠核算和下发环节的延迟有线性恶化或许性，一起给数据库的压力也将添加。据出产环境测试估计，以当时调度方法继续运转，一年内，或许导致实例的平均调度时刻增加到分钟等级，显然调度才能的优化问题亟待解决。

优化计划

针对类似复杂体系的功能问题，战略上一般首先要界说出问题本质，即量化出功能瓶颈，再评价能够优化到达的方针，最终拆解到每个模块/环节能做哪些优化动作。因为前两部分比较冗长复杂，咱们将重点聚集在战术上，即每个模块能够落地的措施上：简略来说优化动作分为短期及中期两阶段，包括削减调度依靠核算量、优化要害环节算法及事务上的分级确保三个部分。

短期计划

前文强调过，日渐增加且不受操控的实例数量关于调度体系的压力在于每逢进行很多进行依靠核算，对应的元数据库的担负都很大，所以咱们能想到的第一个措施便是让每次调度核算的基数能降下来。

调度体系中，在整体角度一般许多使命是没有价值或会影响其它使命的：

• 比方没有上下游依靠，可是每个周期仍然在跑，这种使命既占有调度资源又占用集群资源
• 或许实例使命跑出来但没有数据，虽然不占有集群资源但仍然会运用到调度核算

关于这类使命，咱们统称为僵尸使命，为了便利办理也进行了比较详尽的分类及统计。

僵尸使命及实例整理

如下表所示，关于不同的僵尸使命特征咱们划分了四种类型，分别是数据空、失败、就绪、无依靠；目前离线渠道中存在10W等级的这四种类型的僵尸实例无人办理，并且每天以几百的数量在增加，因而关于存量僵尸使命，能够直接进行冻结或强制成功操作。

针对此类实例，经过强制成功等手法，经统计平均每个使命能优化3秒左右的调度核算时刻。

实例保存战略

跟着时刻的推动，实例也会递增增加，可是目前没有完善的实例整理战略，导致实例一向堆积在数据库中，对数据查询、核算，都产生了很大的压力。因而，完善的数据保存战略，能确保核算资源池的实例数量不会爆炸野蛮式增加。

如下表所示，在确保其最大数据生命周期的前提下(数据-使命生命周期一致性)，咱们对不同周期的使命也制定了不同的保存战略以确保增量实例能一向操控在可接受的范围内。

使命周期	保存战略
月	1年
周	3个月
天	1个月
小时	1周

链路分级

中心链路使命的调度优先级，要始终高于非中心链路使命。当一起满意下发条件时，中心链路使命能够不关注调度时刻，优先下发；一起也增强了中心链路相应的运维、监控等才能，做到优先下发、优先保护、优先办理。

中期计划

另一种比较常见的功能优化思路是空间换时刻，一般是经过损失一部分数据结构的改造或存储，使代码运转耗时得到大幅度改观。离线渠道中这部分优化能够从如下两个角度切入：

内存结构

因为原始的离线渠道元数据大部分存储于Mysql中，且依靠核算流程中会很多用到相关使命的元数据，为了提升调度速度，能够按不同的使命周期将使命详情、使命依靠、使命实例列表映射到内存，这样核算使命实例下发时，可直接运用缓存。当产生重跑、停止、强制成功、状况上报，更新数据库的一起更新缓存。首要流程如下图所示：

算法调整

单层实体模型调度下发最首要的过程是依靠的核算，即自依靠或父依靠。最遍及的情况下（全周期依靠）需要查看被依靠使命的一切实例，假如从元数据库中次序取出会浪费很多时刻，因而咱们针对这两种运用最广泛的依靠类型，进行算法上的调整，使单次依靠核算时刻得到量级上的提升：

现状	改善
自依靠	现有自依靠会依靠历史一切的实例，依靠实例数量:n	新增“前一周期依靠”，依靠实例数量:1，时刻复杂度:O(1)
父依靠	现有父依靠查看每次都会查询数据库，时刻复杂度:O(n)	内存中实例按数据时刻排序，二分法查找，时刻复杂度:O(log n)

高可用

跟着缓存在中心调度流程中的深入运用，中心模块的高可用动作也触及部分改造，首要体现在:

• 上报状况与更新缓存时经过ZK分布式更新确保分区容错
• FailOver时一起要在数据库事务后加上缓存更新及重载动作以确保DB和缓存一致性

如下图所示：

展望

经过评价与测试，当时的优化手法在日核算百万等级实例时仍然会露出相关功能风险，结合事务实际情况 ，从长远来看，调度才能的优化还是要根据整体调度下发机制的改善及相关才能跟进来补充，首要方法有：核算、下发方法重构，定向调度才能补齐等。

调度模式改善

现状	改善
核算方法	被动核算，现有的核算方法为Runner每次请求时触发核算，取优先级最高的实例下发履行	自动核算，新增依靠核算器，当状况改动时，驱动更改实例下发状况，满意依靠条件后，放入待下发行列
下发方法	Runner自动拉取	Base自动推送

定向调度才能

现有的Runner调度为随机运转，在完成定向调度后，可经过指定Runner运转，到达灰度发布的目的，一起防止Runner版本发布影响当时正处于运转状况的使命(导致使命失败或状况不更新等)。

笔者介绍：凌霄｜货拉拉大数据渠道负责人，主导画像、数据API、离线&实时研制渠道等方向