OLAP 分析已死？真的真的么？!

突发看到一篇文章说OLAP已死的，心想这又是谁在语不惊人死不休。顺手点进去看了眼发现某名奇妙的Apache Druid 就被Diss了。我说大哥，Apache Druid和Apache Kylin都是搞OLAP的，我以为你这文章是给OLAP站台的,科普一下啥叫空间换时间和数据立方体的意义和学术原理。怎么就突然风向大变把你同行Druid兄弟冷不丁一脚踢下去了呢。就那么大个圈子那么多点事。这么赤裸裸的冷不丁冒一句，作为Druid的爱好者，不喘口气都以为全是哑巴。

既然Druid兄弟被Diss了，大头兄弟自然就不愿意了。 我们来看看实际情况吧。 今天我们只说Apache项目，不说背后的技术支撑公司产品（我怕挂上产品您得满地找牙，牙哥都看不下去了）。另外，全文我都给Reference，包括老东家eBay弃用XXX改用Druid我都贴出原文地址。也别怪大头，这是eBay写的，不是大头写的。顺便在看一眼，实际的技术架构上，为什么选择Druid的用户越来越多。（人家选的，不是大头干的）

1

先说Apache 技术的开源社区活跃度

这是Kylin的，我露出日期，让你知道我是公正的。

下面这个是Apache Druid的

两个技术，基本前后脚从社区出来，明显看出Apache Kylin从18年开始有明显的冷淡迹象， Github Star数量我就不放了，怕你挂不住面子啊。

再说代码贡献吧， 来上图

排名前八的贡献，都是Kylin的主创人员。也就是说这项目除了背后的公司撑着外，没有社区的同行愿意贡献了。而且，更主要的是，后面这些主创都没提交了，你们闹哪样，不玩开源了么？你别说你商业化了，商业产品好，Databrick一样商业化公司，看看人家核心主创Reynold Xin，还是持续的在往社区贡献。Confluent也是一样一样的，就连Jun Rao 也不定期的提交点东东上来。你说商业产品好这话站不住脚的。

再来看看咱Druid的贡献生态:

懂行的人都知道，这图代表啥意思？ 这叫不断有新鲜血液加入社区做出贡献，长度不够我只放了前10个，数据都是github上公开的，全量的随时可以自行去看看。我感觉这才是Apache Way。 大头也不说背后的商业公司，你懂的，100 Percent Open Source， Pure Apache Play。

2

说完开源项目流行程度，咱说说技术。 技术上来说，有一个本质的差异，就是Apache Druid 天生就是弱依赖Hadoop。这是他最大的优势，也是Kylin最大的劣势。这里就不细说了。就聊eBay吧,也就是Kylin诞生的地方，是怎么说的。原文我贴出来，免得被说造谣。

https://www.ebayinc.com/stories/blogs/tech/monitoring-at-ebay-with-druid/

这是eBay早年的架构，没说是Kylin，其实我也不知道是不是Kylin，大家都是懂行的，你说这个Custom Cube Generation是什么？

那我再翻译下eBay的原文，也许我英语不好，所以我把英文原文一并贴上来，觉得我翻译有误的，可以直接看英文:

The legacy architecture was designed years ago when the number of events generated by the entire site were in the order of 10 of millions every day. This was scalable at that time and for a few years down the lane.

过去的架构是几年前设计的。当时的上游的事件数量大概是每天数千万事件生成。这个架构在当时还算是可扩展的，并且能用个几年。

There were some of the shortcomings of the legacy architecture over time.

但是，随着时间的推移，这个系统逐渐暴漏出比较大的缺陷。

Cube generation was custom written code for each of the intervals. Generation of data for the current time used to take a few minutes, which was not acceptable for real-time monitoring. This delay increased with the increase in the amount of data.

立方体的生成是每个时间区间一套定制的代码。当前时段的立方体通常需要几分钟才能看到，这对实时监控系统是完全无法接受的。同时，当数据量增大的时候，这个延迟也会被同等放大。

Horizontal scaling of the custom cube generation had less success over time as the amount of data increased.

立方体计算的横向扩展在面对大数据量的情况下越来越难被成功执行。

Slow generation or failure to create cubes in case of very high cardinality of the dimensions (a few hundred thousand to a few million combinations).

对于高基维数据，通常会造成立方体生成更加缓慢甚至是失败。例如有几千万维度的情况下。

老东家eBay弃用这个架构，我相信不止于上面的几个明显的缺陷，肯定还有别的原因。不过这都是后话了，它已经是历史了。我们看看eBay现在用的是什么:

没错啦，赤裸裸的写着Druid !!!, 同时还加了个虚线框框， Kubernetes Deployment. 说好不打脸，咱就不打脸。换这个架构好处是啥，就不说了。原文都贴出来了，自己看吧。

另外再补一句，祖国大陆无数互联网公司都在用Apache Druid作为核心的OLAP引擎，能叫的上名字的，X滴，XX巴巴，XX跳动，还有什么团啦乎啦米啦之类的互联网头部公司，您这是要把人家一众架构师的选型结果都扔到粪坑里么？

说好不打脸，我就不打脸。何必互相伤害呢