[讨论] 数据仓库的建模

[levelworm]

背景：

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

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

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

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

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

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

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

[way2explore2]

你们需要 Google Analytics / EleasticSearhc

[levelworm]

@way2explore2 技术栈是总部决定，所以这个没办法。不清楚 GA 和 ES 能够解决什么问题呢？

[way2explore2]

@levelworm 我的意思是数据仓库不满足你的需求，数据仓库怎么可能会尽早

[levelworm]

@way2explore2 有道理，也许它应该不叫数据仓库。不过名字无所谓了。大致这么个东西就行了。

[Aksura]

@levelworm 这两个理由没看出来和 Kimball 有啥关系。

1. 维度建模划分主题域，并没有“所有数据都到位，才进行分析”这样的要求呀。数据处理过程慢，就怪到方法论上，很奇怪。
2. 查询是否方便，看建的模型呀，怎么就怪到方法论上了。

个人观点，时效、可访问性是技术选型的问题，易用性是建模的问题，和方法论不是直接的关系。

[levelworm]

@Aksura 我觉得你说的有一定道理，很可能是_我们目前在实行的_数据建模并不适合我们的需求。我其实真正不开心的，是经理在没有了解需求之前，就根据之前自己不同行业的经验来建立数据仓库。

不过我不同意第二点，不同的方法论的确会形成不同的模型啊？还是我理解错了？

其实我发这个主题贴，真正的目的是想要看看国内相关行业的朋友是怎么处理这个问题了。考虑到手游的分析大同小异，我觉得很有参考价值。当然既然很有参考价值，可能也就不会轻易说出来，这也属正常。

[venhal]

作为数据分析师，非常同意你的结论。
与你们公司的情况相似，我们这边因为业务变动太大，如果要按照提需求排期建数仓的流程，出来的数据都已经失去时效性了。所以只能我们分析师通过大量建存过的方式每天定时跑自己需要的宽表。
私以为，Kimball 那一套建模比较适合较为稳定的业务，比如销售情况分析、人力情况分析，如果要评估业务效果什么的，肯定是来不及的。