痛苦的上午

搞了一上午的数据，翻过来覆过去，头都大了。幸好数据仓库的性能确实不错，能经的起折腾，可分析取数总是要到最原始的数据中去查找，这种查找还得假设一个前提，这些数据是准确的。前段时间我就是带着这样的假设，拿着分析报告理直气壮地给客户吹，你们这些数据如此的走势，有问题啊。可客户突然盯着一个数，不可能，在一年前不可能有这个数啊。

于是，分析报告的后面就只能意思意思了，说明不了什么问题，它依赖的数据就是值得怀疑的，回去查明再来吧。

仓库里面的数据，有些字段根本就没有应用用它，也没人关注它。当来了一个新的分析需求，却可能派上用场，可它的质量问题此时根本就没有保证。那些经常使用的信息，大多经过验证，确保无误，即使没有质量验证框架，经过长时间的使用，也是逐步改善。而哪些从未使用的数据如何保证其质量呢？我没想明白，可能只能说，先用着，出了问题再纠正吧。

这是一种态度，也可能是一种比较现实的做法，可不算是积极的。如果用这种态度去跟某些人说话，特别是瞧你不顺眼的，立马就能被批判，"必须完全杜绝这种数据质量问题"。
这是上午的痛苦在数据质量上的反映。

而另一个痛苦，是这新的分析需求，没有中间已经聚集过的表让你去选取数据，只能从原子数据判断。遇到一个复杂的取数逻辑，便产生一些恐惧。问熟悉模型的人，有没有什么中间聚集表让我取数啊？问这样的问题让我有些不好意思，恐怕给人产生一个印象，你这人怎么这么懒呢？

但如果将这些取数的步骤拿出来分解，会发现其中还是有很多是其他分析、其他人做过的查询（可惜，现在并没有这样的信息显示有多少查询是重复的，也许这就需要元数据的力量吧）。

譬如，先得到一个符合某种特征的用户集合，然后根据这些用户套餐，是否包含某些特定套餐，为这些用户打上一个标签。第一步既然从原子数据取，是没办法的，第三步的输入是一个用户集合、一个营销案集合，输出嘛，是一个用户标签集合。

这只是举个例子，推出一种思路——从数据仓库中分析数据，用sql获取数据，是不是可以分解成若干步？将类似的步骤形成一种固定的查询，甚至将这个动作固化到模型设计当中呢？

innovate 20060524
恐怕没有哪个设计师那么厉害，以后的新需求不添加额外的字段，或者ETL一点都不修改就能满足的。关键是改动多大，改动越小，风险就越小。

其实这就涉及到设计问题，包括模型和架构，因为光是模型不行，现在一般说的模型感觉其实是数据集市那块的维度模型，其实整个数据仓库根据复杂程度，可能在不同层次上有不同的模型，去满足数据仓库的基本因素：数据质量、效率和扩展性。

就拿用户特性来说，从不同部门的角度看，可能是完全不同的分类，那么这个层次的分类应该拿到数据集市去重新汇总，不能搞一致性，只有具有普遍的，企业级的定义才能体现在conform table里供所有数据集市享用。

我以前提到过一种架构，就是conform层到数据集市之间有个staging area,其实这个层就是针对数据集市需求的，专门处理部门级刁钻的需求。如果采用这种架构，所有数据集市级的特殊需求，全部在这里改动，其他地方都不动。

例如市场部门有个新需求每月调查哪些开通国际长途用户使用了国际长途，想看看开通这个业务的使用比例和情况，需要按0-50，50-100等等比例分层。这个需求很简单，只是为了说明如何处理相关问题。首先用户使用的业务可以在conform层中全部ETL完毕，这是企业级通用的，可信的数据。那么我们直接把用户账单事实表拿到过渡层，再用某部门的特殊需求进行ETL，生成可查询也可聚集的中间事实表（一般按照分析主题分类，如特殊业务使用事实表，不是一个报表或查询需求一个表），这样前端需求就可以得到满足。这样的特点就是改动小，只需要在过渡层修改，而且前面的ETL成果是可信的，测试也仅仅测试这一步，可以充分地继承，并能满足其它类似的需求，考虑一定的扩展性。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友