关于数据仓库建议、感想

关于数据仓库建议、感想

现代数据仓库之父，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的。不同的数据仓库因为成本运维不多，带来的设计方式也不同。