数仓的难点在于如何保障数据的一致性，正确性，时效性，性价比的平衡统一

  从业八年来，一直在做数仓相关工作，慢慢的发现数仓的难点在于什么？有人说是模型的构建，比如明细层DWD是按照业务过程来构建事实表，还是按照主题来构建事实表，还有人说是指标的定义，如果划分原子指标，派生指标。其实，我个人觉得这些都是过程，站在最终的结果导向上来看，数仓的痛点就在于如何保障数据的一致性，正确性和时效性的统一，目前看来前路应该是流批一体。
  单就目前还是流批分离的情况下，离线数仓在一致性和正确性上基本没有太大的难点，但是在时效性上，却存在明显的短板。因为全过程的数据一致性，基本上在无论是mpp架构的传统数仓还是基于Hadoop的离线数仓，其业务逻辑的语义，基本可以按照定义好的业务逻辑进行，可以按照标准的建模规范实现一致性。正确性上面，无论是采集阶段的数据清洗，还是后面的数据加工，数据校验，还有数据质量DQC，都可以借助开发经验，或者成熟的数据平台实现。但是时效性，因为技术架构的局限性，基于调度平台的瓶颈，最小粒度做到小时，已经显得有些笨重了，尤其是小文件的快速增长，所以在离线数仓上小时任务是一个痛苦的事情。
  实时数仓还有的解决了时效性的问题，但是在一致性和正确性上面，目前却没有太多的办法，因为目前基于流的计算都是跟着实时需求走的，单个任务实现从明细数据到最终的指标产出，由于产出的逻辑可能存在差异，数据的质量可能存在差异，平台的稳定性不同时段可能不同，导致即使是相同的指标，不同出处可能都会不一致。其次是数据的正确性，在离线数仓投入巨大的人力物力后，如何保障实时数仓的数据的正确性是一个巨大的挑战，目前业界比较厉害的能实现4个9，但是至今都没人敢百分白说他的实时数仓能够实现100%，因为无论是数据乱序问题，还是消息丢失问题，平台稳定性问题，对实时数仓都可能造成影响。或许付出巨大的存储，计算，运维力量能实现5个9，6个9，但是这又会衍生一个性