上2篇文章主要谈的是通过atlas来展示表与表的元数据管理，仓库中还有一个极其重要的就是分布式调度器。从我对调度器的认知，大概有以下3种类型调度器：1. 按照线来跑JOB，对于JOB之间的多级交叉依赖无能为力，比如OOZIE 2. 按层来执行JOB，把JOB分层，一层一层跑，这种通常是自己开发 3. 根据JOB依赖关系来跑，通常也是自己开发。
以上3种调度器第三种当然是最好的，根据依赖自动跑对应的JOB，而OOZIE对于线级别的依赖执行完全没有问题，一旦多条线的JOB有依赖，无能为力，分层跑的调度器太浪费时间，比如ODS层跑了几个JOB，按理依赖的JOB就可以执行了，但是由于是按照层级别来跑JOB，所以依赖无法执行，只能等待ODS层完成了才执行下一层。
现在来谈谈第三种调度器的设计，既然要根据依赖来自动执行对应的JOB，那么首先要有JOB依赖才行。 这也是为什么引入了atlas，JOB之间的依赖实际是由表级别的依赖转化过来的，知道了表的依赖，自然就知道了JOB依赖。现在的问题是，atlas并不会记录JOB名称，光依靠atlas来完成JOB依赖是不可行的，另外这个也和你底层JOB的构成有关系。我这里主打的ETL工具是kettle，所有的SQL都是通过，不仅仅是HIVE，包括presto等全部放在kettle中来执行。
整个JOB依赖关系的设计猜想：解析所有kettle JOB，获取源表，比如insert overwrite table test select * from test1，那么获取JOB名称及test，有了JOB名称和源表的对应关系，再从atlas取出依赖表及对应的JOB，JOB之间的关联自然就有了。 这里涉及2个点，一个是图数据库janusgraph的使用，一个是解析所有kettle job的方式。
先说说如何解析kettle job，获取SQL再解析SQL获取源表，这块相对比较简单，整个工作如下：
1. kettle job 本身是xml文件，所有SQL都在XML里的SQL标签里，只要我们取出SQL标签的内容，自然就获取了SQL。可以通过java程序去解析XML或者直接用kettle XML组件解析。我选用了后者。
再过滤SQL标签内容:
2. 接下来就是解析所有的SQL，可以通过开源的或者商业的SQL解析器来解析SQL，拿到源表。我使用的是general sql parser商业版，整体效果还不错，但是也会有一些BUG还没解决。
解析工作结束就基本完成了，因此表之间关系是通过atlas获取的，只要你会使用janusgraph，就很容易获取依赖。
未完待续.......