大数据处理迷思.md

title	date	tags
大数据处理迷思	2018-11-02 08:30:43 -0700	BigData OLAP

OLAP 系统

No-SQL, New-SQL, 到了最后还是 SQL 好

1. 性能和稳定性的考量, 性能优先(MPP)? or 稳定性优先(DAG/MR)?
2. 让数据更适合被计算
   1. 将计算放在数据附近: Move compute logic, not data. 矛盾: 云, 存储和计算分离.
   2. 做大宽表, 减少 join 开销.
   3. 提前对数据进行分区/分桶/排序, 减少后续计算时候的 shuffle 以及 sort.
   4. 对数据进行预计算, 减少后续计算的聚合开销. 并且预计算等于说自己 own 了数据(多了一步构建 cube 的操作), 且由于是预计算的, 还可以进一步把查询结果 cache 到 Redis 这样的系统中, 下次一模一样的查询来直接用 cache 的 result 就行了, 这个 QPS 超级高.
3. QPS 考量
4. 很重要一点, 客户/业务方要怎么使用我们的系统? 换句话说, 我们能让客户按我们推荐的方式使用我们系统吗? 举例来说, 时间分区列我们推荐使用 date, 但是用户使用到了 timestamp, 造成了很多小文件, 怎么避免这种错误使用?
5. Schema change
6. 数据点更新
7. 如何调配资源
8. 上/下层生态?
9. 客户环境? 自己是否拥有集群环境

什么是一个好的 OLAP 系统

0. 最最重要的: 稳定性
1. 最重要的: 标准 SQL 支持
2. 低延迟, 高 QPS
3. 部署运维简单
4. 支持 schema change
5. 既能查聚合数据, 又可以查明细数据(此条对于预计算系统)

数据分析师之痛

1. 精确去重
2. TopN
3. 多 join/子查询