背景：
长期在乙方环境的我，见过很多的数仓建设套路；
通常大家都会在前期蒙头开发，排除万难把数仓建设起来，步入平稳期；
这个时候，大家都想把这套数仓产品复制出去服务其他客户；
但是很多时候，当我们走出去的时候会发现，每调研一个同类的客户，数仓的产品复制的概率就很少，基本是要重新开发，重新走一趟；
难点：
顶层设计的区别：不同行业的数仓分析特征是不一样的，估计这个大家没什么异议。但是同一个行业，企业的战略特征不一样也会做成很大差异。
举个例子，同是快消品行业，母婴行业是有依赖性的产品，着重第一笔交易，数据管理上要求找到父母和宝宝；啤酒行业是对产品的信仰选择只局限在店铺内（人们不会因为酒吧没有某某牌子的啤酒而换店），啤酒行业更着重渠道竞争，数据管理上还要看酒桌的付款人；
即使是同是母婴行业，也有不同的企业战略，效应策略的，不同竞争方向。
再即使是同一个企业，在不同阶段，企业的战略动向也会影响数仓的着重设计。
从顶层设计上，就导致了分析框架的变化，不能说不可以复制，但是起码是不能100%复制的。
以偏概全的设计：作为乙方，我们接触客户很可能是甲方企业里面的某个部门，并以此部门为中心设计的数据仓库。须知数据仓库本来就是要面向全企业的，如果没有全企业走通的数仓设计，到下次接触甲方企业另一个部门的时候，拿着冬并西凑的数仓产品，去复制实施，显然是不可取的。
无法统一的业务认知：各个客户的数据分类在建设业务系统时已有定义，大家都已非常熟悉自己的数据分类，很难达成统一；
继续举个例子，在ARE人群分类中，A企业着重招募，在招募阶段甚至还对不同部门的招募业绩进行了挂钩；B企业着重转换，以活动角度进行了划分。这种不同的部门，不同的活动都是需要在数仓建设中加以判断变化的；
再举个例子，A企业认为订单分为（销售，支付，发货，售后）。B企业把发货分为来（出库，在途）。这种业务口径，你别说跨企业，有时候跨部门统一也很了不起了。
先不说顶层业务抽象的问题，一般我们建设数仓也是把这类分类属性固化下来的。如果需要实现产品化数仓，把必须去把这类问题进行配置化，那都是工作量啊。
解决办法：
其实上面说了这么多，也不是没有解决办法，只是难点比较大，而且效果也只能慢慢把复制率填补上。
说几点个人感悟：
选好行业：不是所有行业都能产品化，比较稳定的行业则产品化效率更高，对于变化较大的行业，只可以拿部分模块成果进行复制，有时候很稳住自身数仓模型也已经是很好的事儿了。
定点解耦：数仓一般都具备太多企业特色了，要想产品化，一定要选好分离点，定点解耦，别把企业特色融进去。当然这个是很需要抽象能力了。
不要盲人摸象：一定要基于全域数据进行建模，这个和抽象设计相关的，你接触得越多数据和业务，你才能设计出一个真正贴合的场景；
有时候要大点心：这个是做产品的必要点吧？心血少点都不行，一定要肯推翻之前的设计，快速迭代出最合适的数仓
最后：数仓复制一定是数仓实施方法论，而不只是整个数据仓库的产品。
