老板问：先建数据仓库才能上BI报表吗？

前段时间，一个搞信息化的朋友找到我，说今年老板安排要上数仓和BI的项目，但他自己对两者之间的配合细节还没想的很清楚，想让我给他展开讲讲。

所以今天想借朋友的这个问题，来跟大家聊聊BI与数据仓库之间的关系。

企业是如何处理数据的？BI和数仓在这中间各自起什么作用？

开始前，咱们先通过一个做菜的例子，来简单了解企业是如何处理数据的，并从中正确理解BI与数仓的作用与关系。

大家都去过餐馆吃饭，你知道吃到的菜肯定不是厨师从菜市场买回来，就直接上给你吃。菜很脏，需要加工处理。那，厨师是怎么做出可口的菜品？就像企业数据是如何从业务系统的杂乱数据到最终整洁易懂的可视化报表数据？

第一步：根据要做的菜品去不同的菜市场采购食材 VS 根据数据需求去不同的业务系统数据库取数

例如我要做西红柿炒蛋，我要先去A菜市场买鸡蛋，再去B市场买西红柿，有点“东市买骏马，西市买鞍鞯”的意思在，因为我要的东西只有这两个地方能给到我。这就像数据，有的数据只能在A业务数据库里取，有的只能在B业务数据库里取，数据来源是不一样的。在这里，我们可以认为菜市场=业务系统数据库，食材=数据。

第二步：把买回来的食材集中起来，放在厨房里完成备菜 VS 通过ETL取数到数据仓库中做清洗转换工作

在这个厨房中，厨师要完成备菜，为后续的炒菜做好食材准备，而这个厨房，就是数据仓库：把数据（食材）从不同的业务数据库中取过来集中处理，其中备菜过程就是数据的ETL过程，对数据做清洗转换，将其转变成可以被展现分析的数据。此处，厨房=数据仓库，备菜=ETL过程。

第三步：将备好的菜放入锅中，制作出可口的菜品 VS 利用BI前端工具，制作出易于理解的可视化报表

我们备完菜后，就需要开始炒菜，要用到炒菜工具，这时BI前端工具就是炒菜用到的工具，把备好的菜拿出来，相当于选择合适的数据来做可视化分析，最终的可视化报表就是餐厅里可口的菜品。每个人都要吃不同的菜，那就要到不同的数据库里去找不同的数据，这就是临时报表需求。

到此，我们用一张图来回顾上面三步，左右对应来理解做菜&企业数据处理间的巧妙对照关系：

再看上图右边，不难看出BI与数据仓库之间的关系为：

BI将来自不同业务系统数据库中的数据进行提取，取出有分析价值的数据做清洗、转换和加载（ETL过程），再合并到数据仓库中进行建模，最终在这个基础上形成可视化分析报表，从而为企业的管理决策层提供数据决策支撑。

也就是说，虽然最终领导只看到了他们想要的分析报表，但这一套系统是需要数据仓库和ETL在背后做数据支撑。

到此，我们能得出初步结论：数据仓库理论上是BI运行的基础，BI需依赖数据仓库去做数据分析。

参考：

再思考：国内数仓建设高成本现状下，先数仓后BI还是唯一出路吗？

读到这你肯定会想问，既然都得出这个结论了，你标题还取“BI的建设是否一定离不开数据仓库”干嘛？这不是明摆着一定离不开吗。

诶，话先别说早，在上方我们确实得出初步结论：数据仓库理论上是BI运行的基础，BI需依赖数据仓库做数据分析。

但回归现实，从对国内近万家企业的数据基础调研结果来看，会发现理论再美好，现实还是给了企业当头一棒。

站在企业角度出发，数据仓库从规划到落地通常需要花费高昂的经济成本和时间成本，但其创造的价值较难提前量化。所以许多有BI需求的企业会找到。他们在数仓巨大的投入成本以及未知的投入产出比的风险面前，没法下定决心去建数仓，也导致其不敢上BI来满足自身的数据需求。

因此，当客户带着这个“先后难题”来找到我们时，也倒逼着我们不断去思考：在国内数仓建设高成本现状下，先数仓后BI还是唯一出路吗？谁能给这些企业其他的解决方法？

先给结论：

数仓是BI的数据来源，因此先数仓后BI仍是唯一出路。但企业可根据自身数据情况建设适合自己的数仓，并非要建设完“完整数仓”，才能上BI。

此处，我们分情况来说明：

1、企业BI建设建立在完整的数据仓库基础上为最佳。

BI可直接连接数据仓库梳理好的DWS层，将其作为公共数据集，即可以让业务同事基于相对规范的公共数据，无需代码，自己可通过拖拉拽的方式进行自助数据分析/简单报表的制作，从而通过数据去发现问题，解决问题。

2、若企业并未建有完整数仓，建议这些想上BI、但无数仓基础的公司，可借助BI工具帮其快速建设轻量级的数仓，分阶段完成BI与数仓的建设。

具体来说，即在企业数仓尚未搭建或分析思路尚未成型时，可先在BI平台内抽取业务系统数据库表，做轻量级的数据处理当中间数据库，快速构建当下企业里最紧急且重要的分析需求应用。在分析结果得到业务部门的初步认可验证后，再拉通各部门认知，统一数据维度事实。最后将数据和复杂分析逻辑逐步沉淀固化到数据仓库/BI平台内，分层建模开发项目。

参考：