综述
A Comprehensive Survey of OLAP: Recent Trends
<DesigningData-IntensiveApplications>
https://zhuanlan.zhihu.com/p/27461561
Architecture
ddia
各种业务系统的数据存在一个单独的数据库中、专门用于分析型查询，叫数据仓库
分类
-
MOLAP(Multi-dimensional Online Analytical Processing)
预计算出多维Cube（就是一种物化视图），便于查询。例如Kylin
image.png
详细的可以看看DDIA的解释
-
ROLAP(Relational Online Analytical Processing)
image.png
比较典型的是parallel DBMS，使用MPP架构，需要预先定义schema，查询时针对分析型查询有专门优化、有索引，因而比map reduce查的更快(map reduce啥优化都没有，太low level、要优化要索引得自己实现，如下图；即使用HIVE等high level的programming model，个人理解因为数据schema对framework透明，framework就没法针对性的优化查询计划、优化存储方式(比如列压缩，建位图以便计算），再加上存储上很多MPP基于列存、而HDFS、HASE基于行存，这些都是难以靠programming model拉平的差异)
image.png
但是MPP有缺少容错(并行数据库在这方面考虑较少，分布式数据库因为很容易partial failure所以做了很多容错设计。但是MPP压缩效果比HDFS好、达到同样计算性能吃的机器数少，机器数少了故障可能性就远比大型Hadoop集群出故障的可能性小)、伸缩性稍差等缺点，数据量大了就不快了(但是看09年的那篇测评，数据量大了还是比MR快）。MPP介绍、和SQL on Hadoop的对比可以看《探秘MPP数据库》、Hadoop vs MPP、MPP 与 Hadoop是什么关系？、《A comparison of approaches to large-scale data analysis》
并行数据库和分布式数据库的差异可以看《数据库系统实现》
image.png
市面上的MPP数据库有Greenplum、Redshift等
image.png
SQL on Hadoop也算是ROLAP,传统OLAP是基于关系库（和OLTP的关系库不同,针对查询有不同的优化）,商用授权贵;而SQL on Hadoop是基于HDFS，开源免费。目前百花齐放，大致有两种思路，一种是基于已有的计算框架套一个SQL查询层，比如HIVE，一种是仿照MPP思路，自己实现计算层、查询层
MPP快但是难以伸缩扩展（集群大了straggler问题严重)，SQL on Hadoop可伸缩、容错但是慢（因为有大量中间状态写入)，于是又有了试图融合两者优点的MPP on hadoop，例如HAWQ。
那么如何从直觉上理解这些概念？这篇译文（图挂了，可以看这里。另外这篇文章的评论也有相关评论）提供了很好的解释。我个人理解有如下几个设计取舍的关键点：
1. 计算黏性
MPP的设计讲究完全对称、最大化并行（无共享)，数据是单副本、预先sharding好、sharding到每台机器的，计算要绑定到数据节点，每次计算每台机器同时参与，即在计算上追求最大化的无共享、并行性。这种"计算黏性"（我自己编的概念，计算一直黏在同一个节点上、黏在数据上，即使hang住也不让给别人用，或者叫“资源独占式计算”。这种设计下每个Worker是异构的，而MR批处理的设计是每个Worker是同构的）的好处是中间状态无需持久化，可以做到Pipeline。理解如下
image.png
image.png
image.png
那么SQL on Hadoop又是咋回事？本质上MR,Spark都是批处理系统。为什么会有批处理系统？因为MPP有straggler问题、吞吐低的问题，当出现straggler时浪费计算资源hang住不说，在集群机器节点很多时，会频繁出磁盘问题导致系统不可用。如图
image.png
怎么解这个问题？直觉上很容易想到，把任务粒度拆细一点、放弃"计算黏性"改用“资源共享式计算”，“用小石子填充缝隙"，如图
image.png
优点是容错、解straggler、高吞吐，而缺点上文也说了：会有大量中间状态IO。
综上，可以认为这些优劣是关于“计算黏性”的取舍：MPP追求数据黏性，因而可以做到Pipeline、减少IO，但相应的吞吐就低，有Straggler问题；批处理系统放弃黏性、改用资源复用，从而提高吞吐、能通过“推测执行”来解straggler，但缺点就是中间状态IO、任务执行RT慢。
那么如何融合两者的优点? HAQW这种MPP on Hadoop系统做出的优化是：计算黏在节点上可以pipeline让查询更快，但是没有必要黏在数据上(黏在数据上就没法解straggler了）！
image.png
个人理解MPP on Hadoop设计的目的就是MPP+容错，如图：
image.png
2. Schema Awareness
这也是我编的概念，指数据库或者framework是否了解Schema。当数据库了解Schema后，在存储时、在查询时都可以做针对性的优化(存储时比如很多MPP基于列存、而HDFS、HASE基于行存；可以针对性的做列压缩、建位图以便计算，再比如Greenplum这种MPP会预先定义好sharding key，来100条数据可能被sharding到所有机器上，但是hdfs这种不了解schema的存储拿到这100条数据可能就写到同一个block上去了，不够并行化。查询时schema awareness的数据库可以更好的做执行优化），而如map reduce等不了解schema的框架就啥优化都没。
——照这么想的话,MPP on Hadoop还是有优化空间?
-
HOLAP
混合MOLAP和ROLAP -
基于搜索引擎的架构
按照这篇文章
的讲法，搜索引擎架构的系统（Elasticsearch等）相对比MPP系统，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。
数据模型
常用关系模型，因为SQL适合做分析查询。但实现上和OlTP数据库差别很大，有不同的优化方案。
在关系表的设计方面，常见模型为星型模型，变种是雪花模型，但通常是星型模型，因为分析人员用起来方便。
应用：设计OLAP功能时如何选型？
不同类型的需求
OLAP需求大体上分为两类，即席查询和固化查询:
"即席查询：指用户通过手写SQL来完成一些临时的数据分析需求。这类需求的SQL形式多变、逻辑复杂，对响应时间没有严格的要求。
固化查询：指对一些固化下来的取数、看数的需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类需求的SQL有固定的模式，对响应时间有比较高的要求 。"
基于对响应时间的需求，有不同的分类：
image.png
明确了需求，如何选择工具？
《A comparison of approaches to large-scale data analysis》这篇测评是09年的，可以看到MPP远比MR执行快。对于OLAP相关的业务需求往往是在WEB界面上短时间统计出结果，对于短时间运行的任务，Hadoop光启动时间就很长，不适合。14年的网上野生测评也反馈GP远比HIVE快，"但是大部分场景下，依然是秒级甚至分钟级的延迟，距离具体通常意义的实时毫秒级，差距巨大"
image.png
这里的建议是50节点一下用MPP还不错，多了就要考虑批处理。不过这个结论似乎无视了MPP on hadoop
image.png
当然，理论上基于预聚合的系统有更短的RT：
image.png
案例：常见需求与解决方案
-
实时OLAP:时间窗口内统计
例如微博热搜这种统计topN问题，离线的做法是先同步到hdfs，通过批处理框架，计算完了同步到表；实时的方案是Logging+流计算。
例如“爱奇艺实时统计项目”，需求如图：
image.png
使用流计算，接收到新的流数据后调hbase的api增加计数，大致的架构方案如图：
image.png
再比如使用SLS做实时时间窗口内的统计，大致架构为logtail采集——SLS存储——流计算——统计结果写到某个表里
- 实时+历史全量统计
例如实时统计历史topN，咋做？写操作实时update表 set count+1就行，查询时order by count。
那如果统计需求复杂呢？一般来说，实时计算能解决的统计需求，离线计算都能解决，但有些统计计算只能通过离线去算。
方案A.如果查询吞吐不高，可以用MPP及类似的分布式OLAP架构，实时计算；
方案B.如果查询吞吐高，就要考虑写时（异步）计算；但用流计算的话内存存不下历史所有数据、从磁盘读取计算全量数据太慢，因此就要考虑冷热分离，流计算统计热数据并汇总冷数据（可能存在幂等问题）或者在读时汇总冷热睡觉——这就是lamda架构
方案C.自己整一套lambda太复杂了,用基于lambda架构的实时OLAP，例如Druid，相比于传统MPP的优势是支持实时数据注入、能够亚秒级响应OLAP查询（因为做了预聚合所以是写时计算，你自己实现lambda架构查询时也快；相比之下MPP是读时计算）,缺点是牺牲灵活性
网友评论