OLAP 系统
No-SQL, New-SQL, 到了最后还是 SQL 好
- 性能和稳定性的考量, 性能优先(MPP)? or 稳定性优先(DAG/MR)?
- 让数据更适合被计算
- 将计算放在数据附近: Move compute logic, not data. 矛盾: 云, 存储和计算分离.
- 做大宽表, 减少 join 开销.
- 提前对数据进行分区/分桶/排序, 减少后续计算时候的 shuffle 以及 sort.
- 对数据进行预计算, 减少后续计算的聚合开销. 并且预计算等于说自己 own 了数据(多了一步构建 cube 的操作), 且由于是预计算的, 还可以进一步把查询结果 cache 到 Redis 这样的系统中, 下次一模一样的查询来直接用 cache 的 result 就行了, 这个 QPS 超级高.
- QPS 考量
- 很重要一点, 客户/业务方要怎么使用我们的系统? 换句话说, 我们能让客户按我们推荐的方式使用我们系统吗? 举例来说, 时间分区列我们推荐使用 date, 但是用户使用到了 timestamp, 造成了很多小文件, 怎么避免这种错误使用?
- Schema change
- 数据点更新
- 如何调配资源
- 上/下层生态?
- 客户环境? 自己是否拥有集群环境
什么是一个好的 OLAP 系统
- 最最重要的: 稳定性
- 最重要的: 标准 SQL 支持
- 低延迟, 高 QPS
- 部署运维简单
- 支持 schema change
- 既能查聚合数据, 又可以查明细数据(此条对于预计算系统)
数据分析师之痛
- 精确去重
- TopN
- 多 join/子查询