数据仓库的规模越大，元数据就越能体现出它的作用。就像一本书，如果内容不多，有无目录影响不大，
如果厚达几百页而又没有目录，页码，那么使用这本书简直是受罪。
日常生活也是如此，到处是元数据带给我们的便利。想想我们去图书馆，音像店，甚至是餐馆点菜的菜谱。。。

监控肯定是个好东西，可以让你半夜不用起来做修改，可以让你只带个手机，身处全国各地就知道你关心的数据有没有问题。
在coding的情况下，你可能需要关注：模块是否准点开始运行，运行了有没正常结束，前端对应的表结构是否变动。扩展到商业上，还要监控商业数据波动是否太大。
这几点做好后，基本上就比较放心，对数据的情况也心中有数了。
监控还需防止假报警过多，比如每一天都有a,b,c,d四个模块在不同的时间运行，现在要监控这4个模块的运行情况。
可以有两种监控方法，一种是每个监控时间点都监控四个模块有没完成。
另一种是根据a,b,c,d正常的运行时间段来区分监控。比如a应该每天10点运行，b应该15点运行。这样，在15点之前就不会
收到b没运行的报警。同样的，对于频率为周，月的模块，就更加要分时间段监控了。要不，很容易会对报警麻木。那就很危险了。

整个ETL流程就像一套流水线，起点是总的一个调用模块。它调用3个底层核心模块，一个同步，一个刷新，一个汇总。
每个模块都在不断的判断它的数据源准备情况，如果准备好就开始运行。而不是人为的将3个步骤分成三层，（同步层全部正常后开始刷新层，刷新层全部正常后开始汇总层）。即在一个时间点，数据仓库可能同时存在同步，刷新，汇总操作。这样，利于最大化的缩小某个出错带来的影响。
就像玩多米诺一样，一个点可以触发多个分支往下走，不管哪出错，能第一时间发现出错的地方，然后调整出错骨牌的位置，推倒出错的骨牌即可，后面的会自动正常运作。
要达到这个要求，数据的可重导很重要，这会节省很多ETL测试和维护的时间。基本上加个判断数据是否存在模块，和把模块尽量细化即可。但模块过于细化的话，会造成模块间通信过于频繁，接口太多。所以实际工作中，往往需要在ETL流简单明了和ETL维护速度最快之间寻找一个平衡。

在这里，我们可以讨论ETL的本质，开发方法，对各种ETL重量级工具进行评测。