聊聊 BI 的黑武器 —— 分仓分库、前置仓，大型集团 BI 数据架构规划思路

大年三十除夕的清晨，迎接新年的最后一篇文章来讲讲大家平时可能很少接触到的一类数据架构。

因为这种架构少有产品化的落地使用，市面上也没有很好的参照。而我们在两年前做我们自己 BI 产品的时候就已经把这个概念给产品化了，所以我们把这种架构就取了一个名字叫做 BI 的分仓分库、前置仓。

讲这个架构之前，我先来讲讲几个失败的案例。具体案例名称就不在这里提了，就说下这几个项目比较共性的需求背景。

共性的需求和场景

十四五规划，数字化转型大背景下，一个集团七八十家公司二级单位，二级以下还有三级、四级。集团要求做所谓的数据中台、大数据 BI，总之最后的要求大概就是做到：拉通数据、一企一屏、集团财务业务一体化的可视化分析，实现资产监管等等。

听上去是不是感觉很熟悉，就像身边的企业集团一样？非常正常，太多类似于这样的需求了。我面对面聊过的这类需求已经不下十家，听到的就更多。

这些案例大概是什么需求背景呢 ？首先要做的就是财务监管方面的各个系统打通。以往是通过数据报送看看基本的报表就可以了，现在要求所有二级财务系统要对接到集团层面，能够看到更详细的、深入的数据分析，这个是一期的规划。二期就是从业务线、业务板块按照同样的方式，所有的业务数据都上来，逐步实现一企一屏、集团管控、集团大屏等等，实现集团视角、业务板块视角、企业视角等可视化分析。

最终的输出大家注意到了吗，都是什么? 都是 BI 可视化分析、大屏可视化，所以 BI 在这些项目里面是一个刚需。难的地方在哪里？在底层数据上，不仅仅是数据清洗、治理，更重要的是数据架构到底应该怎么来构建才更加高效。

第一家是怎么做的呢？底层上了一个大数据架构平台，对外叫数据中台，把所有的二级企业集团的数据全部同步到集团的云端，然后在云端做数据的清洗、合并等等一系列 ETL 加工处理，最后通过 BI 工具做可视化分析。这个实现思路是对的，难就难在只考虑到了数据搬过来上云，忽略掉了数据处理的复杂度。上百家企业的数据如何合并，如何抽象出共性指标，如何打通这些数据。这个项目最终也没有跑起来，死在抽取之后数据加工到出 BI 这个层面，一家企业数据出问题，最后的大数就是有问题，死活不知道问题出现在哪里。

直接把所有数据拿过来放到一个平台，在一个大平台里面做清洗处理，组织架构、维度科目档案统一如何做，指标口径如何统一？一个点出问题处处都是问题。

这个是思路对了，实现难度大，没有考虑到这种复杂性，没有针对性的找到复杂场景下的解决措施。

而下面这个是思路就不对，错得离谱。

第二家的做法是直接在业务系统中对接各个集团财务系统的数据，然后在这个业务系统中做合并，最后作为大的数据出口、数据源为未来集团 BI 所使用。这种架构就是从方向、从根上完全错了，心思就不正。说严重一点，就是很坏。这样一做，基本上就把甲方给完全绑定了，以后说是什么就是什么。即使财务数据相对标准，集中到一个业务平台上，其他的业务数据以后要分析怎么办？

其他看到的几家项目做法介入这两者之间，处理方式和手段基本上就这些。

面临的挑战

这几家面对同样的问题主要是：

第一，各个二级企业（集团) 所用的财务系统各不相同，有用友NC、用友U8、金蝶 EAS、浪潮、还有用友 T 系列的。很多人问为什么当初集团不统一这些系统，大家需要知道一个大型集团的成长都是靠兼并、收购、重组不断的进化的，IT 信息化不统一非常的正常，IT 信息化建设很难提前规划和预判。

第二，各个企业由于自身的业务特点，各个业务系统也不一样，非统建类的系统居多。

第三，即使是同业务板块的下属二级企业，有的企业有相应的业务系统，有的企业就没有相关的业务系统支撑。

这里面的共性挑战是什么？

第一，不同的系统由不同的供应商维护，底层数据字典、数据质量的问题，这么多业务系统要取数，有的还做过二开，数据怎么取的问题，谁来配合解读数据。

第二，集团到底要看什么数据？知道这些数据从哪里取吗？什么时候取哪些数据？七八十家企业，几百个系统，等你整合完，报表什么时候才能出来？

第一家的实现思路没有太大的问题，但是第二家的实现思路实在是不可救药 —— 让各家业务系统供应商提供标准 API 接口，从各个业务系统 API 接口取数全部集中到自身的业务平台中。这里面涉及到多少家供应商资源的协调，需要多少的二次 API 开发工作投入。并且最严重的一个问题是，业务系统不是数据系统、BI 系统，业务系统彼此之间应该是完全独立的，只有数据系统、BI 系统才能完全基于所有业务系统之上，形成各业务系统数据的打通、建模再到支撑 BI 前端可视化。

所以，这家架构从根上就错了，项目已经启动半年一直无法推进，我上会沟通了一下发现已经无法扭转了，救都救不回来。

集团型 BI 的数据架构实现思路

像这类项目实现思路到底是什么？有没有一些优化的方案或者架构可以供参考借鉴的，这就是我下面接着要说的几个点：

第一，不管是什么样的财务监管、一企一屏、集团 BI 可视化，最终大家都需要注意到，BI 都是最终的出口，这个是最终使用用户唯一能看懂的东西。

第二，一定不会先上来把上百家二级企业的业务系统数据先打通一遍，做整体的数据建模，一定不能这么干。

有的人说我们集团要求业务上云、数据上云，所以数据全部要搬过来。注意，搬过来和打通是两回事，搬过来只是数据到集团的云端了，打通是真正意义上数据的打通、清洗、汇总、合并等一系列的处理。这种打通，不要说上百个系统，就一两个系统的完整打通，按照 BI 建模的方式走一遍基本上就是几个月甚至小半年时间。

第三，一定从需求出发，先梳理分析指标，需要什么指标就看什么指标。不管是财务的，还是业务的，确认多少，再抽取多少，这样可以不用在最初的时候把面铺的过大。举个例子，全部系统打通可能涉及到上百个系统，这个工作量太大。

但是这次梳理出来的一部分指标，可能只涉及到几个系统的打通，阶段性的工作量一下子就降下来了，难度也就下来了。

把这三个点弄明白，我再来讲讲下面的这种架构就容易很多了。

第一，明确集团层面需要看什么数据，看什么数据就抽取什么数据。这种要看的数据从 BI 的视角来说，就是指标和维度，所谓的明细数据就是维度的颗粒度，维度颗粒度越细，数据明细就越细致，定好了就可以了。

第二，既然是集团层面的统一视角，所以这种数据的模板或者格式就是高度统一的，适用于所有的企业。

因此在某一个阶段，二级企业数据到达集团大数据仓库中心之前，因为已经知道了需要获取什么样的数据，所以在二级企业设置前置数据仓库。按照规定的数据格式、模板同步到二级企业的数据仓库中，二级企业的数据清洗过程不是放到集团数据仓库层面，而是在二级企业的数据仓库中完成。

这个就是 BI 数据仓库的分仓分库，前置数据仓库的概念。

这个前置数据仓库服务器可以放到二级企业本地，也可以放到集团统一管理。位置在哪里并不重要，重要的是要降低数据逻辑处理的并发复杂度。

什么叫并发复杂度？比如我有一个大屋子，大屋子里有十个房间，每个房间放了好多杂乱无章的东西，现在要把东西给清理出来拉到大屋子的大厅摆放整齐。

两种处理方式，看看哪种更好：

第一种，直接把每个房间的东西全部拉到大厅里面，然后再分门别类的整理。

第二种，在每个房间整理好，然后再拉出来放到大厅摆放。

大厅就是集团的数据仓库，在房间整理好就是前置数据仓库，明显这种方式更优。全部拉到大厅再来整理，容易手忙脚乱，互相打扰，一个错误全部就乱。

就如同上面的这幅图，各二级企业的数据就像各个农地里面的菜一样，就地分仓处理，处理干净了再合并到总仓中，这种效率非常高。

比如一家集团上百家二级使用的财务系统各不相同，没有分仓分库的话就需要一家一家的进行数据对接。有数据仓库模板的话就相当于各个版本的财务系统只需要对接一次，剩余的直接按照模板复制到各地数据仓库就可以了，七个财务系统版本就对接七次就可以做到。

数据仓库的模板是什么？分析模型、维度、指标、以及维度指标的取数逻辑，这些都可以有效的组织和统一模板，高度复用。

上面的这些架构，我们很早就已经落地了，并且是以产品化数据仓库的形式落地。

场景越复杂、分仓分库、前置仓架构的优势越大

这种架构使用的场景非常的多，集团越大越适合，业务系统版本越多越适合，足够大，高度可复用的效率优势体现的会更加明显。

这种架构具备很强的扩展性和想象力，比如像国资委的国资监管、大型集团的多级 BI 架构、甚至只要有这种带有上下级数据传递整合打通，不管多少级都可以按照这种架构思想来实现，可以把每个分仓无限往下扩展成不同的小仓库，从小仓到大仓，从大仓到总仓。

数据架构这些东西没有什么可神秘的，就像一层窗户纸，一捅就破，关键是在不同的项目中要灵活运用。

本文经授权转载自微信公众号 吕品聊数据  作者 吕品