大数据专家养成记 一-当今 OLAP 引擎选型的一点思考
大家好，我依然投身在大数据方向，最近一段时间因为工作需要做了很多olap引擎的探索和应用，积累了一些自己的心得，希望和大家做一些分享，也非常希望有不同见解的朋友一起讨论。
一、什么是OLAP
OLAP（On-Line Analytical Processing）联机分析处理，也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。应用在数据仓库，使用对象是决策者。OLAP系统强调的是数据分析，响应速度要求没那么高。
OLTP（On-Line Transaction Processing）联机事务处理，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多维信息的快速分析的特征。主要应用是传统关系型数据库。OLTP系统强调的是内存效率，实时性比较高。
二、一些OLAP引擎的特点研究
- impala。这是一个相对老牌一点的OLAP引擎，底层强依赖于kudu或hive，其他的一概不支持，有很多大厂使用，比如滴滴，在前几年和性能不占优势的hadoop系计算引擎相比，确实十几秒钟能把上千亿、TB级数据的sql查出来让人眼前一亮，但是他的局限性在于是用C++写的，这让很多java系的伙伴望而生畏，毕竟在大数据领域java独领风骚，所以impala的发展自然就被自己限制住了。
- presto。这是facebook开发的一款为了替代impala的引擎，这次比较好的就是改成java语言开发了，而且改进了impala只能支持kudu和hive的弱点，他通过一种connector机制，想支持谁就支持谁，写一个对应的connector就行了，官方提供了应有尽有的connector，所以你能想到的基本都能用。presto就是一个纯计算层，没有存储，配置对应的catalog指定引擎，都可以连，比如你让后端存储是mysql、hive、及所有能通过jdbc访问的存储都可以，甚至excel表格也可以。然而这种MPP架构的引擎有一个弱点，就是如果内存扛不住了就会挂掉，所以稳定性是个问题，那么就有很多人基于稳定性做文章，在其上包装各种稳定性保障的外壳，也使得presto有了很大的应用。京东就出了一本有名的讲presto的书《presto技术内幕》，还是不错的。
- clickhouse。简称CH，是战斗民族（俄罗斯）发明的产品，俄罗斯人民发明的开源软件最有名的有两个，一个是nginx，一个就是这个clickhouse了。clickhouse可以说是一个超级无敌的瓤子，是个单机引擎，把DBMS优化到了极致。但是现在互联网行业最大的部署方式还是分布式集群，所以需要对clickhouse做各种包装，俄罗斯人确实也比较彪悍，官方提供了分布式解决方案，可惜用了一套zookeeper，几乎把clickhouse的瓶颈全都限制在了zookeeper里，一个邪恶的想法：是不是这家伙为了做商业化特意让分布式的clickhouse性能变得极低，好让我们买他的更高性能的商业化产品。不过还好，最近发问说明年就要在分布式方案上做去zk的工作了，让我见到了一丝曙光。社区里因为很多人青睐他的单机性能，所以也做了很多分布式方案改造的尝试，初见成效。
- kylin。是一个应用在T+1场景的olap引擎，提前建各个维度的cube，也就是相当于把你要查的东西全部提前跑出来，到时候直接拿就行了，所以预计算量很大，查询速度很快，这也是他的特点，也是在有限的应用场景管用，比如多维分析，非他莫属了，极快。但是如果说找一个通用性强点的olap引擎，他一定是最不适合的那个。
三、引擎选择的考虑
以上几个OLAP引擎各有优缺点，在没有场景限定的前提下说不上谁好谁坏，所以讲几个方面的考虑来如何选择。如果是T+1场景，也就是没有实时更新的需求，那么presto+hive（数仓）是一个不错的选择，因为一般公司离线数仓都是建在hive上的。如果有实时更新的诉求，而且更新量很大，那么首选impala+kudu，因为kudu的更新性能是很高的，其他的不能匹敌。如果实时更新量不是很大，那么可以用clickhouse，他更新能做但性能一般，但是查询性能很高，但是如果你有大量的join，那么clickhouse又不太合适了，因为他对单表查询是优化到极致的，但是join的性能就不敢恭维了。如果你没有实时更新诉求，但是需要多维查询性能极高，那么就用kylin吧，虽然他配起来很难，改配置也比较麻烦，但是查询快啊。
总之，以上就是我近期对OLAP引擎的调研和应用的一些收获，希望对大家有帮助，有不同观点欢迎留言讨论。