现代数据仓库之父,William H.Inmon大师的著作:《数据仓库(Building the Data Warehouse)》定义:
数据仓库是:面向主题的、集成的、稳定的、面向时间的数据集合。
数据平台之问(当前问题现象)
需求响应慢
一个需求就得半个小时,一个小时之久,降低了数据变现、问题排查速度。
数据质量不可靠
经常存在数据不一致情况,有如下可能,
1:上下游出错,如上游etl数据库导表同步延迟,同步失败
2:统计方式不一致,如统计ip地域时,有可能因为ip数据字典文件不一致,导致统计地域值不同。
3:哥们,你真的算错了,你再看看脚本与需求
数据不可信
老大有一天突然问你,你这个数准吗,你经得起质疑吗,敢于拍着胸口说,That's correct。
数据就是自己的招牌,不要砸了自己的招牌。
维护成本高
数据冗余,带来的更新成本,一致成本
运维,补数据成本
元数据管理成本
数据安全不可控
传统的业务系统天生就带有安防性质,数据分散在多个业务系统与数据库,数据泄露,也会隔离在某个业务领域。
而数据仓库则不然,业务的覆盖范围广,时间周期长,数据泄露的损失非常大。
数据仓库
星形模型
事实表被维度所包围,且维度表没有被新的表连接。(3g注册类似)
雪花模型
事实表被多个维度表,一个或多个层次所包围。
雪花模型一般再处理大的,且相对静态的层次时候使用。(传统行业,事实表关联多个层次的维度表)
多维模型
层次数据陆,只有一个结构(立方体Cube)相当于一个多维数组,宽维度表。(类似3g tmp_user_info多维度建模)
维度建模
数据的粒度与层次
注册的渠道,一级渠道还是四级渠道。
缓慢变化维
用户的个人信息,地址,比如user表(少量变动,除了完全覆盖还有什么更好地办法)
快速变化维
用户的好友,积分,产品的价格(用到的时候,单独etl)
大维度,迷你维
宽维度表基础之上,可以抽出小的维度表
价值稀释比(价值/时间)
数据的价值随着时间的变化。
业务建模
用户事实表(分区表)
性别、年龄、学校。。。
注册事实表(分区表)
注册方式、注册渠道、注册版本。。。
登录事实表(分区表)
登录方式、地域、登陆版本。。。
激活事实表(分区表)
激活渠道、激活版本、平台、appid。。。
保留率事实表 (临时表)
第二批次:围绕注册、登陆、用户开展的,每天etl形成后统计
客户端action事实表(临时表)
第二批次:围绕action行为动作、版本、app_id、平台。。。
客户端接口事实表(临时表)
同上
hive数据仓库
hadoop数据仓库
存储成本 | etl耗时 | |
---|---|---|
hive | 低廉 | 时间长 |
传统RDW | 高 | 时间段 |
hadoop相比传统关系数据仓库etl耗时,但是存储成本低廉,因此更适合针对统计分析业务,建立宽维度表,降低多次etl带来的时间消耗。
比如统计全站用户登陆 ,全站3g用户登陆,全站3g性别为男用户登陆,这其中的etl结果都可以多次复用,减轻存储成本。
tips、感想
注册、用户、登陆是公司核心,流量是基础,其他产品围绕流量变现。
数据仓库建模,第一要保证所有原始数据入库,保证数据可追查、可变现。
第二针对核心业务,用户、注册、登陆,etl,形成大表,便于查询,按天分区
第三对于在核心业务之上,衍生出来的第二批次业务,只保留当天etl表,历史etl数据不再保存
需要考虑数据仓库现状,是基于hadoop&hive的,还是oracle的。不同的数据仓库因为成本运维不多,带来的设计方式也不同。