如何构建基于XX云存储用户的数据集市

最近一段时间，运营支撑方面技术一直为手工提取运营数据，疲于奔波。

分析原因

一方面是运营的同学不清楚相关业务数据的侧重点，

一方面是我们技术上无法提供全面、多维、清晰的数据。

简单的报表，并不能完全满足业务的需要。

业务同学面对上级领导的深度追问时，往往哑口无言。

另外一月一度的经营分析汇报，数据对运营同学来说也是一个瓶颈。

有没有一种办法？一个方式？

来减轻业务的疑惑，减轻我们技术人员手工提取的过程，提供运营的效率。

让大家在痛苦中是有点快乐呢？

个人认为可以通过构建 数据集市(Data Mart) 来解决部分业务对数据的需求。 
那么什么是数据集市呢？ 这个百度可以有。

那么如构建呢？构建后如何体现呢？如何使用呢？

同学问得很好，这个请看下面分析。

我们先来看哈背景，对产品有一个大概的了解。

项目背景

中国XX云存储是中XXX计算体系框架中云资源的一个重要部分，

它为全网用户提供一个免费、安全、便捷的文件存取服务的产品。

该产品去年6月份试商用到今年正式商用运营,经过几次大的变革，目前已经非常稳定，并且基于多个终端平台都有发布应用。用户数量也在稳步攀升，批量导入用户超1亿，现注册用户数已超过1600W，日均注册新增超 50W，使用空间超过500T，日均上传文件超过40W。该产品不仅面向终端用户，也面向相关的合作应用提供网络存取服务，如 189邮箱、爱音乐，天翼相册、轻笔记等。

了解背景之后我们再来看一下数据支撑运营现状。

目前项目数据支撑方面主要存在以下几个问题。

1、数据量庞大，很多表数据量都过亿，多个表单表容量超过100G。

   目前 经营数据分析和生产环境是一个Oracle数据库，所以对大表数据的全量统计，不仅要等上好几个小时，而且会导致数据库服务性能的急剧下降，影响现网用户体验。这是非常危险的。

2、数据统计涉及业务方向多，激活，活跃，合作应用，套餐等。

   运营的人员有很多，每个运营同学的侧重点各有不同，当现有报表不能满足的情况下。

    往往形成了多对一个的局面，开发人员应接不暇。疲于奔命。

3、数据统计涉及维度多 全国、省、地市、终端、应用、时间等。

   数据的多维度需求，意味着数据提取难度加大，同时满足多维度，

   又不能使数据固态话，这就需要一个灵活的数据模式。

4、运营人员“求知若渴 ”，需求多变。

    新的业务上线，运营人员会想从数据各个方面了解新业务的情况，需求多变、孜孜不倦且无怨无悔对着技术人员。技术人员忙的压力山大。唉，不怪人家，谁叫他们需要的数据我们不能直观的提供呢。

针对以上特点我们主要采用下方式去应对：

1、统计数据过程优化，加强统计基础数据存储， 加强数据预处理， 通过对增量统计来达到对大表全量统计的效果，并且速度更快，维度更高 。

2、完善各业务常需数据固态报表，满足运营日常基础需求。

3、提供业务数据多表、多维度保存方式，提供灵活的数据转换展现模式。

4、对临时不是适合开发的需求提供sql支撑。

上述的优化工作正在紧张的进行中，但是业务的提数需求仍然不断。

能不能减少这种手工需求呢，能不能不需要开发人员介入，业务也可以像搭建积木一样提取数据呢？

万源归终，我们来分析禅道需求从 TASK #617 到 TASK #1958 ，发现50%以上的需求都是涉及到用户相关的，不是查询用户总数就是查询用户清单。

如果可以让运营同学自行提取这些数据，那么我们就减少了这部分的手工工作。

对头，想法很好。

我们开始来关注用户。

天翼云用户主要有7大分析主题分别是 激活 （注册） 、合作应用、活跃、流量、文件、套餐、分享。

涉及到用户维度超过30种（省，地，客户端类型，激活时间，活跃时间，活跃次数，文件个数，类型，套餐等）

专业的工具分析入门条件高， 这些可以让业务自行到平台提取吗？

答案是肯定的 YES 可以。

这个问题可以通过前言中提到的 Data Mart来解决（终于做到前后呼应了，不容易啊）

搭建一个包含用户数据所有维度信息数据集市，让业务同学通过前端页面自行提取。

搭建步骤主要有：

一、分部（步）实现

      优化 分析各 主题模块  。优化完成后，不仅得到该主题的 统计相关信息数据，

     最终 还会 得到一张用户关于该主题的多维度实体视图。

     如用户激活模块通过优化后我们得到了，日激活信息表 NETDISK_USER_ACTIVEYYYYMMDD 、

     分区域 用户激活日统计表 STAT_ACTIVE_USER_DAILY 、

     分区域用户激活累计表 STAT_ACTIVE_TOTAL_DAILY 、

     用户来源统计表 STAT_MARKETING_DAILY 、

     合作应用激活用户统计日表 STAT_APPUSER_DAILY 、

     合作应用激活用户累计表 STAT_TOTAL_APPUSER 等。

     最后得到激活 维度实体视图 表 STAT_USERACTIVE_TOTAL ，里面包含所有累计激活用户的激活相关的维度。

二、统一聚合

     多主题多维度实体视图聚合，形成用户主题的数据集市。

     最后以激活 维度实体视图 表 STAT_USERACTIVE_TOTAL为基础，外连接其它6大主题视图。

三 、定期更新

    可以根据实际情况、选择合适的时间定期更新数据集市。

    

那么统计的优化过程和聚合过程技术上如何处理呢？

我主要是采用 ETL技术概念来实现的。

具体处理规则是：

一、宏观输入输出

从对数据源的整个宏观处理分，看看一个ETL过程的输入输出，可以分成下面几类：

1、大小交

一般会直接进行Descartes 乘积处理，如果大表的量非常大，会采用空间换时间的代价，将大表中不需要的关注的列删除，尽量减少整体的大小，以及其他索引和sql语句优化处理。

2、大大交

同样去掉不需要的属性，将索引和SQL语句优化用到极致。还有一种需要注意的可以采用横向分解表。

3、行列转换（站着进来，躺着出去）

事务系统中为了提高系统灵活性和扩展性，很多信息放在代码表中维护，所以它的“事实表”就是一种窄表，而在数据仓库中，通常要进行宽化，从行变成列，所以称这种处理情况叫做“站着进来，躺着出去”。有些时候也是为了满足前端层现的需要，将表进行行列转置。在ORACLE使用Decode，case when的方式对表进行宽表化。窄表变宽表的过程主要体现在对窄表中那个代码字段的操作。这种情况，窄表是输入，宽表是输出，宽表的粒度必定要比窄表粗一些，就粗在那个代码字段上。

4、基本聚集。

数据仓库中重要的任务就是沉淀数据，聚集是必不可少的操作，它是粗化数据粒度的过程。聚集本身其实很简单，就是类似SQL中Group by的操作，选取特定字段（维度），对度量字段再使用某种聚集函数。但是对于大数据量情况下，需要对聚集算法的多次优化，例如是直接使用SQL的Group by，还是先排序，再处理。

5、特殊函数聚集

按照方差，偏差等函数聚集。可以通过ORACLE的分析函数实现，根据特殊应用有此类要求。一般比较少。

6、特殊取数

例如：按某一关键字段值需要取操作记录中最有最后有效的记录，需要用到oracle中的row_number() over (partiton by 用户 order by 时间 desc)的方式获取过滤；

二、微观规则

1、原封照搬，将表中的数据不做处理，直接通过insert into ......select ...的方式获取。

2、字段运算：比如文件大小不满1KB的round处理等。

3、参照转换：把表中多条记录整合为一条记录，其值用内嵌表或者一个字段存储（其中用分隔符隔开），如用户使用客户端等。

4、字符串处理：主要处理不符合格式要求的字符串的值。

5、空值判断：分情况区别对待

1）如果存在空值的属性作为group by的条件处理，就采用自定义的缺省值填充，例如：增加"TELEWEB"的自定义活跃端的标识；

2）如果存在控制的属性会作为将来where中的子句，例如：在有些fact table中的表示时间的起止日期，startdate为起始时间，用Enddate为终止时间，我们一般保留enddate的NULL，不作空值处理。

6、日期转换

对于数据聚集或者保留数据痕迹按照yyyy-mm-dd或yyyy-mm的格式统一保存，以及聚集中的日期格式转换等。此字段也作为建立分区表的依据，使用ORACLE的日期运算函数进行日期运算。

8、聚集运算

结合上面的宏观中聚集规则处理，进行多重的concept hierarchy，包括shcema hierarchy（province->city，Month->day）和set-grouping hierarcy（0..100,100..200,200..500,500..1000,1000......etc）。hierarchy运算一般实现的有sum,count,avg,min,max等number聚集的。

三、优化手段

因为设计海量数据的处理，必须采用各种手段对数据的优化预处理，对硬件改良的情况，主要采用软技术手段：

1）使用space换time和time换space的策略；

2）表的适度cut；主要对dimession的cut，事实表中属性字段的cut；

3）采用partition、index来实现。在使用partition、index还需要比较其中不同partition、不同index之间的差异比较，进行性能评估。例如：一般在fact table中，对diemession属性都不采用normal index，采用BITMAP index，B-tree index等；对于LIKE的条件采用function index的方式实现等等。