数仓的理解（二）

四、OLAP&即席查询
常见的OLAP场景&选型

1. Druid 时序型数据的实时OLAP分析
   不关心事件明细
   数据产生速率快、原始数据量大
   以简单指标（sum/count/min/max）为主，去重指标不多（1~2个）
2. Kylin 基于预计算支持固化查询：指标提取、多维分析、dashboard等
   查询模式比较固定、SQL表达
   数据规模大、指标数量多、高基数精确去重
   对响应时间要求比较严苛（TP99 < 3秒）
3. Diros 基于MPP高性能计算提供灵活高效的OLAP分析[主要现场计算]
   海量明细数据查询
   百毫秒的高性能灵活OLAP查询
   低基数（千万级内）精确去重的OLAP查询

即席查询引擎对比

Presto 即席（Ad Hoc）查询：需求多变、查询模式灵活、需要大量子查询和表连接操作，支持ANSI SQL
Impala 即席（Ad Hoc）查询：需求多变、查询模式灵活、需要大量子查询和表连接操作，支持hive SQL

五、数据技术

1. 数据同步简介
   sqoop
   flume
   kafka

2. 数据倾斜的处理
   数据分布不均

   union all 拆解
   随机数打散
   空值过滤
   

JOIN优化

map join的使用
关联键的空值处理以及类型匹配
谓词下推

去重优化

以下两种仅限于数据量巨大的情况，常规情况还是推荐 count distinct

单个count distinct可用group by代替
多个count distinct可用 distribute by 优化

其他情况

小文件过多：合并小文件
使用transform：case by case的排查
大表关联大表 ：模型层面是否可以解决，cache 表

3. 数据库常见优化
   3.1 优化法则
   Do Less or not do! --翻译过来，就是尽量让数据库少做工作、甚至不做工作

Q1：怎么样来理解少做工作？
比如创建索引往往可以提高访问效率，其原理就是将原来的表扫描转换为索引扫描，通过一个有序的结构，只需要少量的IO访问就可以得到相应的数据，因此效率比较高。
数据库就是数据库，不是计算器，减少在数据库中进行排序，计算等
Q2:怎么样来理解不做工作？
比如在系统设计中常见的缓存设计，很多是将原来需要访问数据库的情况，改为访问缓存即可。这样既提高了访问效率，又减少了数据库的压力。从数据库角度来说，这就是典型的不做工作。
Q3：数据库优化要从那些方面入手？
运维管理优化（硬件太老，配置低，参数设置不合理…）
开发优化（表结构，索引，SQL语句…）
架构优化（读写分离，前端Cache…）

3.2 常见优化
设计优化

字段类型尽量统一
字段类型尽量单一
索引设计：主键索引、唯一索引优于普通索引
索引字段选择访问频率高、离散度高的字段

开发优化

少排序，排序尽可能在服务层面实现
过滤字段少用函数