数据仓库真的过时了吗

原标题：数据仓库真的过时了吗

数据仓库真的过时了吗？ 记得在去年有一次大会，我们在大会上正好有一个展位，参观的人很多，正好有一家企业的IT负责人看了下我们的易拉宝，直接扔出了一句：还在搞数据仓库，现在都是敏捷 BI 分析了，说完摇摇头就走了。当然，后面我们又找他聊了很长时间，也是很不容易给聊明白了。

存在这样看法的企业其实不在少数，因为从大的趋势上来看，在BI分析领域我们确实强调敏捷BI自助分析，业务驱动，但这并不意味着数据仓库就过时了。

很多人之所以反对数据仓库，主要就在于数据仓库需要预先建模，基于建好的模型来完成自助分析。当业务变化的时候，预先建模不太方便灵活调整，需要重构和二次调整。所以，不预先建模，而是把建模的选择权交给业务人员，由业务人员自己建模，然后自己组织维度和指标进行分析。

这里面有两个误区，第一个误区就是业务人员自助分析建模，第二个误区就是数据仓库建模不能及时响应用户的业务分析变化。

第一个误区在之前的视频中已经讲解过了，很少有业务人员能够自助建模，因为自助分析有三个前提：建模前底层数据质量、规范性的问题，数据分析思维意识和业务分析意识，这个我就不重复讲了。

重点说第二个误区，数据仓库到底能不能及时响应用户业务分析需求变化。其实，在90%甚至95%以上的企业，是完全可以的。

我这里分三个层次来讲解这个问题：

第一，一个好的数据仓库的模型设计，已经能够充分考虑到业务的扩展性和变化性。比如我们在数据仓库维度建模中讲到的维度一致性，星型和雪花型分析模型其实就可以解决这些问题。后面业务的变化无非就是增加了分析维度，或者维度属性，或者增加了指标，细化了分析模型中的颗粒度。这些调整如果是通过手工写代码和开发调整，一定是很麻烦的，会有很大的改动。当然，在我们派可数据数据仓库平台，不需要我们的BI开发人员去碰底层数据表，不需要手工开发，重新配置分析模型就可以了。所以，我们不存在这个问题。

第二，当业务分析需求变化调整的时候，不管是什么场景，都需要重新建模。区别就在于在数据仓库中我们叫后端或者底层建模。而把这个调整的过程放到前端可视化就叫前端建模，或者业务人员自助建模。但我想说的是，前端建模的确方便了业务用户，但是这种建模很难有复用性，也很难沉淀分析模型。在后端建模只不过将前端的建模过程后移了，在后端提前处理了。虽然后端建模感觉牺牲掉了一定的灵活性，但是这种方式更加稳定。简单来说，就是10个业务用户在前端同时建模，可能会有很多重复的东西，为什么不把这些建模一次性沉淀到后端呢，这样一次调整就同时可以支持到更多的用户，这样不好吗？如果我们对程序开发比较了解，比如像OOP的概念，接口、抽象的概念，应该就能理解我说的问题。

第三，有一个最为隐藏的很难反驳的一个观点。因为不知道可能会分析出来什么，所以业务人员自己想怎么分析就怎么分析，这样不好吗？数据仓库预先建模就阻碍了业务人员自助式的分析，所以确实不好。这样理解是错误的，之所以不知道业务人员要分析什么，让业务人员自助分析，错就错我们的开发人员确实不知道业务人员要分析什么，所以才不会在数据仓库建模。不会，不是指不想，而是因为不懂业务，不懂业务场景，不懂在这个业务场景下能分析什么，所以把这件事情丢给业务人员了，所以这里的不会是因为不知道。

我们并不否认业务自助分析的优点，但也不能否定数据仓库的长处，特别是在一些企业级BI项目的规划和建设上，数据仓库就是整个BI的核心基础，就如同人的腰腹一样，起着承上启下的作用。

我之前作为乙方在为一家甲方工作的时候，BI部门总共就只有3-4个人，支持到了十几个业务部门，几百个业务用户，业务用户自己做了3000多张报表。为什么可以做到，因为底层的数据仓库架构相对比较稳定，持续开发和维护了三年以上的时间。在这个公司，IT和业务的边界非常清楚，IT负责底层数据仓库和建模，业务就基于已经建好的模型自己开发报表。

所以，自助分析，敏捷BI分析是可以做到的，但他们需要依赖一个强有力的数据仓库。

最后，也有人会提到数据仓库在面对大数据量下的挑战，这些是底层数据架构、技术架构的问题，并不能否定它在组织分析模型、建模过程中的作用。技术框架一直在演变，实际上数据仓库结合不同的技术架构也可以做到与时俱进。游戏网