1 数仓介绍
2 建模理论
建模的目标：性能、成本、效率、数据质量中找到平衡点
2.0 三范式
123要求逐渐严格
- 每一列不可分割
- 属性要完全依赖于主键，不可以只依赖一部分(数据重复很多)案例中主键是学生id和课程，所属系和系主任只依赖学生id
3. 主键以外的字段没有依赖关系
2.1 ER(Entity Relationship)实体模型
Bill Inom用这个建数仓，不现实，哪有那么多时间梳理所有的实体和关系，而且业务也在飞速变化，完全跟不上趟。
ods dwd 基本跟数据库来的数据是同等粒度的，自然符合er关系模型。
2.2 dataVault模型
初衷是有效的组织基础数据层，不是针对分析场景设计的
中心表就是实体id，连接表表示关系(两边的id)，卫星表就是实体的描述。
2.3 维度模型
把表抽象成事实表和维度表两种
2.4 总结
3 技术架构
3.1 工种分类
- 底层开发维护，源码级别
- 应用开发，写spark
- 数据开发，数仓
此处有图
3.2 hive相关
3.2.1 数据类型
为了保证数据不失真，从mysql来的数据，整型都用bigint，字符串日期啥的都用string，有小数点的都用decimal
3.2.2 压缩格式
- 压缩可以减小io网络负担，但是会增大cpu负担，需要平衡
- lzo压缩需要建立索引才支持分割
3.2.3 文件格式
ods: textfile可以便于排查问题，当然orc，parquet也ok，这一层字段基本都要清洗，列式存储没啥优势，优势在于空间小。
dw: orc，parquet都没啥问题，如果上层用了impala就只能用parquet，presto最好用orc，因为之前版本不支持parquet不知道现在支持有没有坑。
3.2.4 内部表外部表
根据场景选择：
计算用的临时表就内部表，spark、flume来的数据就用外部表
3.2.5 hive优化
- union只走一个reduce，用union all 再外面group by 比较好
distinct也是同理
- 减少job数：
给每个表加一个标记字段，union all之后再做聚合统计，这样只有一个job； 先聚合统计完了再union all是多个job
多表join用同字段关联，reduce相同的key就减少job数了
- 并行执行，没啥依赖关系的可以并行
- 任务数控制：
=> map端：split最大最小size，小文件合并
=> reduce端：reducer处理的数据量，reduce数量
=> 输出文件数
- 排序：order by + limit 用的是堆排序，不用非得全局有序，保证topN有序。
- map多承担任务，减少reduce计算成本和数据传输成本
=> map端join 、map端聚合(combiner)
- 数据倾斜
=> 空值都去了一个reduce，空的单独处理再unionall
=> 本身就倾斜的，加一列随机数，group by 随机数，业务字段，外面再套一层group by 业务字段
- 数据裁剪
=> 行数据：分区，where子查询再关联
=> 列数据：没用的字段剔除，列式存储
- 减少IO
3.3 hbase
3.3.1 rowkey设计原则
长度不要太长(影响检索速度)，唯一，散列(避免热点访问)
经常检索的、高标识度的列放在rowkey靠前的位置
有需要的话可以考虑二级索引
