![](http://chuansongme.com/static/img/essay/980/157570/0.jpg)
文/通贯
【导读】这是共四篇的数据仓库治理系列,本文是第一篇。作者从实际经验中,总结出了一些大型数据仓库治理中,可能会遇到的问题。本文谈到了“数据需求响应慢”的问题,大数据时代,你值得关注。
数据仓库是继ERP之后失败率最高的IT项目。在项目还没立项的时候,会给老板呈现各种美好。而实施到一定阶段的时候,老板会发觉太多的华而不实,要什么没什么,做点变更比造航母还难。渐渐地,实施人员失去信心,老板失去决心,减少投入。项目慢慢地陷入泥潭.....
数据仓库项目失败的原因不外乎两点:
1)初级选型和架构不合理,不适应变化。
2)就是缺少有效的治理。
数据仓库的治理就是预知和发现问题,然后控制问题不发生以及解决问题。
大型数据仓库治理,首当其冲的就是“数据需求响应慢”的问题。有如下场景:
老板把你叫过去:
问:昨天成交额是多少
答:我回去查一下,半小时后告诉你。
老板的心顿时凉了半截。这半个小时,对于你是多么地紧迫,对于老板确是度日如年。
半小时后,你告诉他:数字是xxx亿。
老板接着问:xx类目成家额是多少。
答:半小时后....
我们的现实情况可能比这还更糟,有些数据说不清,理还乱,一周都不一定能把数据算出来。
数据仓库是面向决策的,面向分析的。数据仓库需要能快度的响应数据需求。如何解决这一问题呢?
80%的数据需求是相对固定的,20%的需求是比较随意的。相对固定的需求主要是业务的监控数据,例如: 某天UV多少,PV多少,收入多少。。。。,这些需求的指标是固定的,变化的只是维度组合,以及数据的粒度层次。举个例子,以店铺经业务为例,运营人员关心的指标无非是UV,PV,订购人数,订购金额,但是他们会从多个维度去看,如时间维度,店铺星级,店铺类型,主营类目。数据粒度指的是在某一维度上,要看到那个层次,以类目为例,是看一级类目呢还是叶子类目,以地域为例,是看省分布呢还是到市级。我们可以将业务方常用的维度组合以及粒度层次开发成固定的报表,开发支持裁剪和钻取的OLAP报表,提供灵活的维度和粒度组合查询分析。
80%的人日常工作中只关心1-2张报表,不超过10个指标。我们的数据中上有数千张报表,就算按照业务目录查找,找个数据都会非常困难。所以,仪表盘很重要,可以针对不同的业务开发不同的仪表盘,将用户最关心的数据,用最直观的方式展现出来。如果业务发展很庞大,仪表盘的用户也很多,也会导致数据很凌乱,这时候就需要更加个性化的数据展现形式,即数据门户。每个角色或者用户都可以自定义自己关心的数据指标,放在一个简洁的页面中。
另外20%的数据需求,没有包含在报表,仪表盘和数据门户中,需要case by case开发统计,费时费力。经过长期的总结会发现,这部分需求有如下的特点。首先是数据计算口径较特别,例如月销售额大于2000的卖家人数。其次,跨业务,例如统计订购了小艾分析的量子用户的销售额区间分布,包含了第三方产品订购业务、量子业务,又包含淘宝主站业务。其次,依赖细粒度数据。需求的随意性,导致必须从细粒度的数据中统计数据,需要考虑的口径多,计算时间长。为了满足这类需求,最好能提供一个快速自助查询细粒度数据的平台,将个性化的操作交给最终用户,解放数据仓库工程。
上述内容,主要从数据展现产品的角度,将需求拆分为金字塔结构,分层次地提供多种数据产品,满足数据需求。
要实现上述目标,还需要搭建层次清晰数据仓库模型,将数据分为细粒度、初步汇总、高度汇总的金字塔结构的数据层,分别覆盖100%,90%,80%的数据需求。要求数据仓库模型指标定义规范统一、层次分明、业务主题清晰、高度解耦。
【嘉年华推荐】
今天没有餐后甜点推荐。周日就好好看看技术文章,这也是这个账号的初衷。
此外,昨天盘点了一下目前的订户图,数据如下:
目前男女比例大概是3:1,可见技术宅都是男生的谣言不攻而破。而女同学们,一部分是wawa推荐过来的萌妹子,另一部分是程序媛。此外,目前每天还有很多此类回复让后台应接不暇:
有没有技术宅愿意来帮忙解答问题的?愿意的话请给我留言,在保证妹子们的隐私并且征得妹子的情况下,后台先将妹子的问题匿名发给你,你直接回复,然后后台转发给妹子,有的话赶紧回复 #报名# 哈。
明天看报名效果决定下一步行动:)
--
微信名称:阿里技术嘉年华
微信号:alibabatech
简介:传播原创高质量的技术内容