四、OLAP&即席查询
常见的OLAP场景&选型
- Druid 时序型数据的实时OLAP分析
不关心事件明细
数据产生速率快、原始数据量大
以简单指标(sum/count/min/max)为主,去重指标不多(1~2个) - Kylin 基于预计算支持固化查询:指标提取、多维分析、dashboard等
查询模式比较固定、SQL表达
数据规模大、指标数量多、高基数精确去重
对响应时间要求比较严苛(TP99 < 3秒) - Diros 基于MPP高性能计算提供灵活高效的OLAP分析[主要现场计算]
海量明细数据查询
百毫秒的高性能灵活OLAP查询
低基数(千万级内)精确去重的OLAP查询
即席查询引擎对比
Presto 即席(Ad Hoc)查询:需求多变、查询模式灵活、需要大量子查询和表连接操作,支持ANSI SQL
Impala 即席(Ad Hoc)查询:需求多变、查询模式灵活、需要大量子查询和表连接操作,支持hive SQL
五、数据技术
-
数据同步简介
sqoop
flume
kafka -
数据倾斜的处理
数据分布不均union all 拆解 随机数打散 空值过滤
JOIN优化
map join的使用
关联键的空值处理以及类型匹配
谓词下推
去重优化
以下两种仅限于数据量巨大的情况,常规情况还是推荐 count distinct
单个count distinct可用group by代替
多个count distinct可用 distribute by 优化
其他情况
小文件过多:合并小文件
使用transform:case by case的排查
大表关联大表 :模型层面是否可以解决,cache 表
- 数据库常见优化
3.1 优化法则
Do Less or not do! --翻译过来,就是尽量让数据库少做工作、甚至不做工作
Q1:怎么样来理解少做工作?
比如创建索引往往可以提高访问效率,其原理就是将原来的表扫描转换为索引扫描,通过一个有序的结构,只需要少量的IO访问就可以得到相应的数据,因此效率比较高。
数据库就是数据库,不是计算器,减少在数据库中进行排序,计算等
Q2:怎么样来理解不做工作?
比如在系统设计中常见的缓存设计,很多是将原来需要访问数据库的情况,改为访问缓存即可。这样既提高了访问效率,又减少了数据库的压力。从数据库角度来说,这就是典型的不做工作。
Q3:数据库优化要从那些方面入手?
运维管理优化(硬件太老,配置低,参数设置不合理…)
开发优化(表结构,索引,SQL语句…)
架构优化(读写分离,前端Cache…)
3.2 常见优化
设计优化
字段类型尽量统一
字段类型尽量单一
索引设计:主键索引、唯一索引优于普通索引
索引字段选择访问频率高、离散度高的字段
开发优化
少排序,排序尽可能在服务层面实现
过滤字段少用函数