淘宝大型数据仓库的治理（1）- 数据需求响应慢 实时相应需求

2013-08-25 阿里技术嘉年华

文/通贯

【导读】这是共四篇的数据仓库治理系列，本文是第一篇。作者从实际经验中，总结出了一些大型数据仓库治理中，可能会遇到的问题。本文谈到了“数据需求响应慢”的问题，大数据时代，你值得关注。

 

     数据仓库是继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

简介：传播原创高质量的技术内容