面向大数据的分布式调度

参数的作用域有本地化和全局2种方式，本地化可以设定参数的Key：Value，相同Key的全局不会被覆盖，本地的优先级高于全局;而全局的变量是由上游产生并且进行流转;调度本身规定了不同算子在参数接收方面的追加、解析、编码规范，比如在Shell命令和WebService中追加参数有较大区别。

参数除了作用域还有是否被传递的属性，上游的参数可以有针对性的对下游输出，同样，如果算子接收到上游参数可以选择修改值，但是这种传递是不被修改。

3.3 数据质量实时Check

数据生产在交付之前一般会对数据进行校验，由于大数据生产的过程比较冗长，如果在后期输出数据再进行质量校验，往往发现问题比较滞后。所以在数据的阶段性交付过程就可以对数据进行核验，可以比较早的对数据的问题进行干预，保证数据交付的可靠及时性。

Check算子：针对数据的校验特点，设计了专门算子提供质量保证。数据核验的方式一般有2种：跟自身历史比较、跟其他数据源进行比较。前者只需要对目标数据源进行选择相应的SQL或者标准API来获取当前生产窗口的数据，然后才去同比、环比、滑动窗口的均值、左右边界等方式，时间粒度可以灵活到天、小时、分钟。如果跟其他数据源进行比较则需要对源和目标分别进行描述，可以进行严格相等、区间、浮动率等方式比较，应用的场景以数据交换较多。除了数据比较之外，还提供关键性字段类型、精度、宽度的比较，以及对空置率、重复率、区分度的统计报表产出，比较直观的查看数据的稀疏和分布。 整体和抽样：针对于其他数据源进行比较的方式，常规的是通过宏观的字段抽样的Count方式条数比较，也可以通过对数据类型的Sum、Avg的比较，这里需要注意不同引擎的存储精度略有区别，尽量选择整形字段;除此之外也会增加对明细数据抽样的全列的字段比较，这种比较容易发现字段值的缺失，类型变更等问题。

这里需要说明的是，如果没有配置Check算子，则认为数据生产完就可以进行交付;如果数据的树状结构中有Check算子，则认为在下一个Check算子之间的所有数据生产节点都默认数据可以交付。这样默认操作是因为数据的校验不一定要面面俱到，否则也会带来时间上的损耗，一般情况下我们认为只需要在关键性节点进行核验就可以了。校验失败通过告警的方式中止数据ETL过程，后续可以重试或者人工方式介入处理。

3.4 数据血缘关系

人生哲学解释：血缘关系分析是大数据调度与其他调度之间的区分度较大特征之一，主要解决大数据的“人生哲学问题”：我是谁，从哪里来，到哪里去。而这一切的基础是开放式SQL对数据存取的规范，之后依赖对开放式SQL的解析来完成血缘关系分析，主要包含数据的上游依赖关系和下游的被依赖关系，这2个是通常被涉及到的，除此之外还包含第三个特征：计算逻辑或者口径对外的输出，鉴于大数据在进行计算和挖掘之后数据会被推送到不同的业务场景使用，会造成相同口径指标不同的计算结果，当被提及计算逻辑时，研发同学也无所适从，经常需要追根溯源对代码和过程进行回访，进而导致无益消耗的增加。

所以计算逻辑输出也是常规和减少人力梳理成本的重要特点。

开放式SQL可以对外解释，数据从哪里来，到哪里去的逻辑问题，也会涉及到具体SQL或者API层面的计算口径，但是这里需要提到之前的【黑盒暴露】和研发专注开发ETL的丰富function，黑盒是无法解释计算逻辑的，但是function却可以给出入参、出参的说明，让特征三的提供成本最低。

血缘关系分析的手法一方面依赖SQL属主引擎的语法解析，例如Mysql可以使用Alibaba druid、JSqlparser，GreenPlum、Postgresql可以借助JSqlparser，Impala则需要通过impala-frontend进行语法分析，分析的结果在外卖大数据平台需要精确到单个字段依赖上游的哪些库表、字段;越是精细越是精细在进行大数据回溯的时候就越有针对性，同时也越有利于效率的提高。

在进行大数据回溯的时候越有针对性和利于效率的提高。

针对非SQL方式，例如Hbase、ElasticSearch数据源的依赖，也会同样被映射成不同的文档/表，具体的列簇中的列，source中的key。

总之，数据可解释是血缘关系存在的价值，血缘关系同样和开放式SQL都在ETL的演进中具有里程碑的意义。

3.5 基于表的Transformer演进

在大数据调度中，对用户最直观的展示是某个表是否可以被交付，或者更为精确查看表中的字段哪些具备了可以被交付?这样做是为了让下游数据更好的有选择性的、细粒度的依赖触发动作。所以在大数据调度中会区分出三类角色，从粗粒度到细粒度分别是：Job、Transformer、operator。

图4 三者协作示例

下面解释下三者的分工和协作：

任务(Job)：Job的主要作用是进行数据相关性的统筹，简单来讲是针对表之间、多种数据源之间进行协作的一个统筹，是一个最大粒度的过程，具体调度的实例化过程都是以Job作为入口，其他2个角色都不具备实例化的能力。这里会区分出同样有数据之间依赖，但是并不一定在一个执行频次上的任务，可以采取配置不同的job依赖关系。 转换(Transformer)：一个转换就代表一个表，单独把表拿出来，是因为在大数据的交付过程，表是一个完整的符号，不如库的粒度大，也不像字段太精细无法对外完整表述。 算子(operator)：算子是调度的最细粒度，不可分割。算子的分类根据应用会扩展很多，有控制类型算子，例如启停算子、分发算子、Check算子等。也会有针对数据操作进行封装的功能性算子，比如获取hdfs数据推送到mysql，Ftp到对象存储等;针对大数据调度的功能性算子是针对单个字段或者几个字段的产生，这个完全依赖于数据产生的难易程度和组合回溯的相关性，最终由开放式SQL进行配置，例如其中的一行则认为是对一个算子的功能进行的描述，select字段中的数据获取可以是多个，同样对应的insert中也可以是多个;大数据调度在完成开发之后，后期的更多运维精力就在算子的丰富。算子的实现会考虑到前面提到的灵活和通用的选择。

3.6 基于字段精细化回溯

（编辑：核心网）

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