现在数据仓库成为企业IT部门的重中之重，但是我们还会发现一些数据仓库项目失败了，大数据技术是过硬的，但是需求没有支撑起来，技术只有与业务相结合才会有价值。
1. 归纳一下我所听说过、遇到过的数据仓库失败的情形：
a. 数据源不停的在改变，特别是日志Event，日志系统不停的在改变，初创公司尤为如此，也有业务数据不停改变的但不能及时获取到；
b. 严格按照常规的数据模型规划、建设数据仓库，特别是加强从数据基础自底而上的构建宽表，形成"好看不好用"的半成品；
作为leader，也许就注重最终的结果，但是作为开发和架构人员必须要在快速支撑需求和遵循基本规范之间取得平衡，以防不断重构，遇到数据不准确和计算逻辑改变就要大动干戈。
2. 作为架构师还需要注意：
a. 数据量增长的情况，根据业务发展的趋势对存储做出合理的规划
b. 伴随数据量增长带来的访问效率下降如何解决？对数据的组织做出合理的规划，否则即使暂时成功的开发成果也会逐渐变得被动。
c. 还有系统收集数据的写入性能，如何在数据量不断增长的情形下不丢失数据
要解决好这些问题才能从数据架构上保障数据仓库项目的顺利使用。
3. 当然还有第三点需要考虑，就是合理的数据校验，我要及时的知道一个成功执行的任务也未必就能得出所希望的结果，可能的原因：
a. 源数据变动，空跑任务；
b. 面对新的业务数据，计算逻辑不能包含，但是可以成功状态结束计算；
c. 其他
现在数据仓库项目调度平台一般做的都比较好，但是如果没有在数据层面做好合理校验，那么也会让数仓人员陷入被动。
最后一点，开发有风险，规划需谨慎，开发数仓除去需要有一个合理全面的规划，还有就是心态，要有GEEK精神，不能怨天尤人，时刻保持警惕，不要让业务人员因为质疑我们的数据对我们失去信心，对leader亦是如此。
