[讨论] 数据仓库的建模

背景：

1. 一家手游公司。技术栈是
2. 我们最近几个月在试图根据 Kimball 原则来建立数据仓库。

感想： 先说结论。我认为 Kimball 可能并不适合手游数仓的建模。理由如下：

第一，手游业务要求分析师尽早、尽快进行分析。根据我的经验，分析师并不会等所有数据都到位，才进行分析，而是一旦数据满足某一类分析的需求（比如说 engagement ），分析师就会立刻上手。而 Kimball 的问题就在于，太慢了。想要建起来框架，起码要有几个 dim 表和 fact 表，而这些表在每一次新的数据出来之后都有可能要扩充列，实在是太麻烦了。

第二，大宽表有利于列数据库的查询。而且恰当的大宽表能够让分析师尽可能少的 join 。Kimball 固然比 OLTP 少一些 join 但是总体上来说，我觉得还是太多了。

由此我觉得比较适合类似业务的数据仓库应该是：

每一张表都应该和一组分析师的分析强相关。分析师把他们需要的列发给数据组，数据组根据现存的表选择能够做得到，然后通过各种技术直接出一张大宽表。最优选择是分析师直接可以根据这张表出报表或者图表，不需任何其他 join 。

与此同时，数据组必须在 feature 尚未开发的时候，就和程序员敲定数据的输出。比方说分析师需要某某数据，但是这些数据往往不在一个 feature 中，所以就要和程序员说，你得给我一个 connection field 。