Abstract
本文工作基于一种针对按需数据仓库维护的增量ETL管道流水线技术，通过管道并行性来同时执行一系列的维护工作，其中每一个维护工作都需要从源本地事务中提取一批增量元组并附带一个提交时间戳，然后计算最终的增量，使相关数据库达到最新的状态。
每一个流水线操作都在一个独立的，不停止的线程中执行一个Job，每处理完一个任务，再新建一个新的。
但是，要连续执行增量连接或维护缓慢变化的维度表，可以同时访问和更新相同的临时表或维表，这些操作可以在不同的作业上工作。如果没有正确的线程协调，可能会产生不一致问题。
本文就将提出集中调度算法来解决这些问题。
Introduction
针对数据仓库实时分析的需求越来越多，不仅需要考虑效率，还要考虑数据的时效性。
为了追求效率，增量ETL技术已经被广泛使用，从源表将增量传递到目标表，而不是从头开始计算。
增量ETL类似于物化视图维护，不同之处在于视图维护作业被包含在内部事务中，以使物化视图在事务上与基表一致，而ETL流通常由外部工具执行而没有完全事务支持。
本文的工作中，一旦有查询产生，会立即出发数据库维护操作，查询会被暂停，同时构建一个维护作业，并传播那些在查询到达时间之前具有提交时间戳但尚未与仓库表同步的源本地事务。 当仓库表更新到最新时，再重启查询操作。
一系列查询的到来要求我们的ETL流程也需要一系列的维护工作，成这一系列工作为一个维护工作链，每个维护工作链都将相关仓库表带到特定查询所要求的正确状态。 为了提高效率，我们利用流水线并行性，并提出了增量ETL流水线的思想。
一个有向无环图 G(V, E)
v ∈ V ETL 传输操作
e ∈ E 用来从提供者到接受者传递数据的内存通道
ETL管道的来源是缓存的输入增量流。 每个数据流缓冲由独立变化数据捕获（CDC）进程捕获并按提交时间戳顺序维护。
Related Work
目前存在的算法考虑执行时间、吞吐量和内存消耗
Ca03、KVS13、GJS12、TPL08
Operator Thread Coordination & Synchronization
Slowly changing dimension (SCD) 3种
Type 2 SCD 是保留所有历史维度的一种SCD，所以有很多行包含相同的business key来表示一条记录的历史，而每行记录还有一个unique surrogate key，在某一个特定时间内有效，而当前可用的版本，结束时间是null。
当源表中的数据改变时，最近的一条数据被替代，null变为当前的时间，一个新行被添加。但是上一个surrogate key的行可能正在被用户查询
异常因没有控制执行队列的三个读写操作进程引起，
item_sk-lookup in Flow 1 和 (update-I old, insert-I new) in Flow 2.
增量join中的潜在异常
An incremental join is a logical operator which takes the deltas (insertions, deletions and updates) on two join tables as inputs and calculates target deltas for previously derived join results
a logical incremental join operator is mapped to three join operators plus two union operators.
Consistency zone
是原始流程图的一个子图。虽然他们经常操作shared mutable object，但他们也不必通过数据管道联通。
一致性区域的概念与嵌套事务相似。
Pipelined Slowly Changing Dimension
建立一个正确的全局序列化调度
CDC组件会首先跟踪source-local事务开始和提交的时间戳，并把他们映射成一个全局的时间戳，最后生成一个全局的序列。
This strict execution sequence can be implemented by the (Java) wait/notify methods as a provider-consumer relationship
in order to guarantee the atomic execution of both update-Iold and insert-Inew at task level, a (Java) cyclic barrier5 object can be used here to let update-Iold wait to start a new task until insert-Inew completes the current one
Pipelined Incremental Join
包含两个一致性区域和一个外部的重复删除操作。
一致性区域同步一个维护Job上的读写线程，一个维护Job只有才所有相关线程都完成时，才可以开始执行。
Consistency-Zone-Aware Pipeline Scheduling
根据调度算法MINIMUM COST (MC) 描述，一个ETL工作流
增量ETL pipline因一致性区域中很多线程的同步执行，所以效率是很低的
其副作用使其看上去向堵塞操作，因此一致性区域中的操作应该被分组，(update-Rold, Rold ∆S), (∆R Sold, update-Sold)
这就是consistency-zone-aware MC
Experiments
original MC and consistency-zone-aware MC TPC-DS benchmark
latencies of maintenance jobs input delta streams have a low or high input ratio