面向大数据的分布式调度

通过邮件或者短信的方式对不符合预期返回标识的进行中止，同时通过邮件或者短信等方式对预先设置的用户或者用户组发出警告。报警触发的机制可以在宿主机单台时候触发，也可以在一定占比的宿主机在一定的时间窗口超过了阈值，触发报警。同时也要支持报警的屏蔽，用在进行运维或者升级部署、运维接管的情况。

上面是很多常规调度拥有的一些特征，这些是在分布式场景下的延伸需求，从单点简单的逻辑到多节点的协作统筹在工程层面无疑增加了额外辅助，这些都是在业务演进中逐步完善起来，而高可用、高效率是在分布式环境下做出的改变。

三、大数据分布式调度

大数据分布式调度，在上面通用调度的基础上又进行了具体跟数据特征相匹配的改良。主要是从数据的流程层面进行梳理，用来解释数据的上下游、血缘关系的问题，具体又有哪些特征是针对大数据的呢?

3.1 数据扇入扇出

大数据的存储和检索方案很多，因大数据特征之一就是多样性，为了满足多样的业务场景会有不同的引擎或者存储选择，在多样化解决方案的同时，造成了数据之间进行交换变得复杂，引擎之间的数据存取规则都有个性化的支持，比如Hbase的数据到Mysql和ElasticSearch(以下简称ES)，涉及到Hbase的读取和后续后面两者的数据存入，这种对于Hbase就是一对二的数据扇出，但是在数据在Hbase中通过Get或者Scan方式获取后，要插入数据需要了解后面2者的存储结构，甚至是索引结构。所以类似这种跨引擎(或者跨版本，不同API)的方式，为了保持通用，需要进行需求的抽象，在外卖平台针对数据的交换定义了一套开放式SQL，这个框架对数据引擎的存和取分别作了抽象，在不同的目标引擎中有具体的实现，所以就有一些约定的规范。

图2 开放式SQL扇入扇出流程图

主键：数据必须存在业务主键或者联合主键，目的是为了保证数据在聚合或者更新的时候有依据。主键在Nosql的引擎中作为RowKey，在关系数据库中作为主键，在ES中作为主键key。对于Kudu来讲也是主键，针对数据的upsert就可以有依据的进行更新或者插入。 数据列：数据列的变更会稍微复杂，如果在关系数据库中会涉及到增加、变更列，但是在Hbase、ES中基本不需要主动扩展列，只需要对数据变更就可以了。 分区字段：对于事实表数据，在大数据量的情况下，为了检索效率和数据存放最优，一般会提供分区和桶的策略，针对Hive、Impala、GreenPlum的引擎会额外增加分区字段，分区可以是一级到多级，一般业务场景下第一分区为日期，根据实际业务需求可以变更更细粒度或者其他业务字段。在一般Mysql、Postgresql、Hbase这种引擎中不需要单独增加分区字段。 数据更新范围：大数据的数据交换，一般为了提高效率会进行多批次的并发处理，这就需要在一批次的数据进行分割，一般情况下会按照单一字段的进行截取，字段的类型以时间戳(create_time、update_time)居多，也可以根据主键的key排序后分批次获取，在源数据引擎允许的情况下，按照多批次的并发query可以做到很好的数据获取，把串行的操作截断成多段的并发;这种在同一个任务多时间批次的情况下也很重要，每个批次会界定本批次设计数据更新的范围。数据更新范围使用前一般会获取本次更新的数据量，可以根据原目标引擎单个批次的最优性能计算出offset。 多步骤过程：多步骤顾名思义就是数据的准备不是一蹴而就的，例如在3个Mysql库、Postgresql、Oracle中获取员工信息，而员工编号是统一的，最终数据在DB2中汇聚在一起，最基础的步骤是三份数据汇入到Oracle中，这就涉及到前面通过key做数据的Merge，这里会涉及到数据的插入和更新，但是如果有key存在并且不同数据源目标数据列清楚的情况下，三份数据早到和晚到场景都没有太大区别。第二步骤则根据汇总完的数据分析出一个过滤场景下的聚合信息，这步骤的场景作为计算数据源，再次进行数据的扇出插入结果。第三步骤可以把第一步的临时结果进行删除。所以在多步骤的场景下数据是分步骤完成了汇聚、聚合和删除。 更新类型：百度外卖大数据实践的开放式SQL场景有Insert(大批明细场景)、Update(数据后续更新)、Insert Once(聚合结果插入)、Insert Temp(临时结果缓存)、Delete(善后处理场景)，在这些组合操作类型的场景下，需要在是线上增加一个执行优先级的信息，如果区分优先级会按照从前到后的步骤执行，如果没有设定则可以并发操作。 黑盒暴露操作：黑盒操作是在通过开放式SQL的存取原则情况下，对无法按照约定规范操作的情况下实行的一种妥协方式，目的有两个：一方面要把黑盒对数据依赖过程必须对外暴漏，这样是为了后期梳理数据血缘关系提供素材;另一方面通过黑盒来满足数据处理的灵活性，比如对json负责xpath的选择，集中缓存优化方案;黑盒虽然通过规范暴露了依赖源数据，但是也造成了对外不好解释数据的处理过程，同时这种黑盒一般针对表或者多个字段，精细化程度不够。

开放式SQL是大数据在做数据ETL的一个规范标准，目的在数据的交换和流动是通过配置的范式来完成，并非是通过硬编码或者单纯组件化的方式。编码更多的是要提供丰富的解析函数，更优秀的中间大结果集的Cache和复用。开放式SQL提供了数据从哪里来，到哪里去的哲学问题，同时也可以进行对外阐述对数据做何种操作，这是在为后期数据血缘关系提供最基础的指导，在发展过程中，百度外卖大数据平台也经历了如下的不同阶段。

图3 分布式调度的演进过程

3.2 协作参数一致性

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!