大数据数仓之报表开发
1. 背景
- 在大数据开发中，主要的数据分析目的可以分为2类。一类是基于历史数据（就算是实时数仓，接收到数据的时候，其实也已经是历史数据了）做数据规律或者结果提取；一类是基于历史数据，训练模型，做未来数据预测或者分类等。
- 如果是前者，基于已有数据做数据规律和数据结果提取，这时候就可以称之为报表开发。
- 参考神策系统，报表开发可以划分固定维度报表开发，一定维度*组合报表开发，*维度报表开发。
- 固定维度报表开发，一般是一些固定指标，但会加一些固定维度，典型的如年，月，日等
- 一定维度内自定义组合分析
- 灵活自定义分析
2. 报表分类
- 从上述描述中可以看到，报表从数据维度和计算难度来看，可以分为3大类
- 固定报表，如果是离线数仓场景，很多时候使用hive，或者spark，或者mapreduce程序，结合脚本定时（一般是每天定时任务滚动计算）执行，就可以将这些指标计算出来。
注意，数仓一般会做分层处理，一般都是将原始数据处理后放入ODS层，ODS层数据处理之后放入DWD层，DWS层结果一般从DWD计算而来。所以整个数据流是有先后顺序的 - 一定维度内组合报表，也就是典型的cube。
- 可以使用hive 的三个语法
with cube
grouping sets
roll up
但注意，这三个语法其实在实际开发中，维度过多时，实际使用并不友好。并且计算之后的结果还需要想办法放到HBase或者mysql来方便外部的快速结果查询
- 可以使用现有工具，druid或者kylin
kylin是纯粹的预计算框架，当设定好需要计算的cube，设定好需要计算的维度组合之后，结合kylin的rest api或者jdbc接口，可以让kylin做每日滚动计算。kylin还会自己把计算后结果放入HBase中（hbase可以提供亚秒级别的数据访问，不过需要基于rowkey或者索引查询）；
druid 则有轻度预先聚合，对数据查询也有加速效果
- 灵活自定义查询，也叫即席查询
- 即席查询要求有很强的计算性能，因为没有做预计算或者预聚合，数据量大时，需要有很强的计算性能才能满足即席查询的秒级要求。
- 神策使用的方案是impala，但应对大量数据的计算，还是会受限于impala本身的限制。据说内部其实也做了很多优化，思路包括一定的预聚合和预计算等，所以神策在国内其实属于领头羊地位，属于独角兽
- presto属于后起之秀，虽然社区内划分了2个分支，但不影响使用。presto的计算性能其实弱于impala，但结合presto的内存表，性能会有很大提升，就是对内存占用以及数据体量会有一些要求。
并且，presto的社区活跃很多，版本迭代快速。有大公司支持，个人人为性能超越impala是预期内的事情。