|
|
|
|
|
# 095 | Kyligence：阿帕奇麒麟背后的大数据公司
|
|
|
|
|
|
|
|
|
|
|
|
几乎每一个成功的大数据开源项目背后都有一个公司。今天我们故事的主角就是Kyligence这家成立于2016年的公司。这个公司背后的项目就是阿帕奇麒麟。
|
|
|
|
|
|
|
|
|
|
|
|
先来介绍一下阿帕奇麒麟，它的英文名是Apache Kylin，一般业内都简称它为麒麟，这是第一个由中国人主导的阿帕奇开源项目。
|
|
|
|
|
|
|
|
|
|
|
|
麒麟项目由eBay中国公司开发，开发目的是为了解决在Hadoop生态圈里对数据仓库进行实时分析的问题。
|
|
|
|
|
|
|
|
|
|
|
|
和我们提到的其他开源项目解决数据分析的方式不同，阿帕奇麒麟的做法使用的是数据立方（DataCube）模型。
|
|
|
|
|
|
|
|
|
|
|
|
数据立方模型是数据仓库里很成熟的一个模型，它定义了查询可以在哪些维度哪些粒度上进行预计算。这个模型有许多商业化的产品，比如说微软的SQL Server Analysis Service就是这个模型的一个商业化实现。
|
|
|
|
|
|
|
|
|
|
|
|
通常我们说起开源项目解决数据分析问题，做法都是直接在原始数据上进行查询。而数据立方模型则允许系统事先做预计算，并存储一部分预计算的结果，查询可以发生在预计算的数据上，这是一种典型用空间换时间的策略。
|
|
|
|
|
|
|
|
|
|
|
|
这个模型最大的挑战在于，系统现实里到底选择了哪些维度与粒度进行预计算。如果系统对所有维度和所有粒度都进行预计算的话，那么所有查询都会加速，但是随之而来的是额外的存储空间将会非常巨大，远远超过原始数据的大小，这肯定是负担不起的。
|
|
|
|
|
|
|
|
|
|
|
|
所以**如何有效地进行预计算，从而在不浪费空间的情况下，也能极大地缩短查询时间，是所有此类分析软件的核心问题。**
|
|
|
|
|
|
|
|
|
|
|
|
阿帕奇麒麟是一个在Hadoop上基于数据立方模型，通过预计算的方式来提高查询性能的系统。它也是阿帕奇的顶级开源项目之一。
|
|
|
|
|
|
|
|
|
|
|
|
这个系统主要有两个核心的模块。第一个模块是对数据的预计算。这个是用户通过对数据立方的设计，进而产生Hive的查询，并且运行实现的。第二个是数据实际被查询的时候，系统会根据查询和预计算的内容进行匹配，进而改写查询，再从预计算的数据里面算出用户查询的结果。
|
|
|
|
|
|
|
|
|
|
|
|
麒麟是这样进行加速查询过程的：它对数据的导入会进行增量处理，每次导入新的数据以后，麒麟会生成增量文件，增量文件会在合适的时候被合并到主文件里面去。
|
|
|
|
|
|
|
|
|
|
|
|
这样的好处是系统导入数据的速度快，同时系统的查询性能也比较好。
|
|
|
|
|
|
|
|
|
|
|
|
麒麟于2014年10月正式在GitHub上开源，并在一个月以后加入阿帕奇基金会的孵化器，一年后正式毕业，成为阿帕奇基金会的顶级项目。
|
|
|
|
|
|
|
|
|
|
|
|
这既是eBay公司的第一个阿帕奇基金会的顶级开源项目，也是中国人的第一个阿帕奇基金会的顶级项目。
|
|
|
|
|
|
|
|
|
|
|
|
麒麟在eBay公司里面发展势头很好，还获得了美团等很多企业的支持。不过，在2016年的时候，原来在eBay中国开发麒麟项目的主要人员决定离开eBay开始创业，创业的公司就是这家总部位于上海的大数据公司Kyligence。
|
|
|
|
|
|
|
|
|
|
|
|
Kyligence的产品主要有三个：Kyligence分析平台、Kyligence机器人以及Kyligence云托管产品。
|
|
|
|
|
|
|
|
|
|
|
|
其中Kyligence分析平台，我们可以将它理解为阿帕奇麒麟的升级版。Kyligence的机器人则是一个自动化的诊断和分析平台，用于为Kyligence分析平台提供性能诊断等服务。Kyligence的云托管产品等同于云端的Kyligence分析平台。
|
|
|
|
|
|
|
|
|
|
|
|
总体来说，Kyligence分析平台在体系架构上和开源的阿帕奇麒麟比较像，但是很多重要的模块都重新开发了。
|
|
|
|
|
|
|
|
|
|
|
|
举例来说，开源版本的存储使用了阿帕奇的开源项目HBase作为底层的NoSQL存储，但是在Kyligence分析平台里面，这个组件被替换成了Kyligence公司自己开发的新的NoSQL存储，这个存储并没有开源。
|
|
|
|
|
|
|
|
|
|
|
|
我很有幸和Kyligence公司的CEO韩卿见过几次。我们聊到为什么Kyligence分析平台里HBase被替换的问题的时候，他说开源的阿帕奇生态圈里面有很多的好东西，但是这些开源软件又属于半成品，不够达到工业级的质量。
|
|
|
|
|
|
|
|
|
|
|
|
HBase作为一个开源项目来说是够了，但是HBase因为使用了Java，垃圾收集导致的延时现象很常见。这种延时对于一个追求亚秒级响应的查询系统来说，性能上就不能达标了，所以使用自己开发的组件去替换掉那些开源组件，是一个切实可行的做法。
|
|
|
|
|
|
|
|
|
|
|
|
当然，为了开发这些非开源的组件，Kyligence公司也投入了大量的人力物力。所以Kyligence公司并没有打算把这些东西开源出来。于是，和开源的麒麟比起来，这些不开源的组件才是Kyligence分析平台的核心资产。
|
|
|
|
|
|
|
|
|
|
|
|
Kyligence的盈利模式并不复杂。主要是通过卖他们的分析平台（无论是离线的，还是在线基于云的分析平台），然后按年收取费用，这些费用构成了Kyligence的主要收入来源。
|
|
|
|
|
|
|
|
|
|
|
|
Kyligence的想法是，如果大家使用了麒麟，觉得开源版本很好，又想用更好的版本，那么只要收费合理，总是会有人愿意出钱的。
|
|
|
|
|
|
|
|
|
|
|
|
这个做法与MapR的Hadoop发行版非常类似。因为MapR也是自己开发了自己的文件系统，去取代性能一般又不够稳定的Hadoop的文件系统。由于这个文件系统本身并不开放源代码。MapR公司就觉得如果大家用了Hadoop，并且喜欢使用的话，面对自家那个更好的系统，肯定更加愿意用。
|
|
|
|
|
|
|
|
|
|
|
|
当然，Kyligence和MapR的做法是有区别的，区别在于Kyligence系统的开源版和非开源版都是主要由Kyligence维护的。而MapR作为Hadoop的发行商，本身并非是最主要的维护Hadoop开源版的开发者。相反的，Hadoopd发行版是由多家公司联合维护的。
|
|
|
|
|
|
|
|
|
|
|
|
从这个角度来说，MapR要维持自己的文件系统和Hadoop开源版本的文件系统兼容性会比较困难，而Kyligence要维护阿帕奇麒麟和自己家的Kyligence分析平台的兼容性则要容易很多。
|
|
|
|
|
|
|
|
|
|
|
|
作为第一个中国人主导的阿帕奇顶级开源项目，麒麟也给中国人在阿帕奇基金会的活动提供了很多平台。麒麟的多个项目负责人为国内企业在阿帕奇基金会开源它们的项目提供了很多的支持。
|
|
|
|
|
|
|
|
|
|
|
|
从系统的架构来讲，一个通过预计算生成比较多的中间数据的产品，在某些场景下会很出彩。但是这并非是一个通用的系统，所以它适用的场景还是比较有限的。这使得无论是麒麟也好，Kyligence分析平台也罢，可能只适用于某些客户。
|
|
|
|
|
|
|
|
|
|
|
|
这种限制肯定会影响Kyligence公司的发展。然而从这样一个系统过渡到一个更加通用的系统，需要大规模改变整个系统的架构。这几乎是不可能发生的事情。所以我个人对Kyligence的判断是：它会在某些市场里面做得很好，但是市场的蛋糕并不是特别大。
|
|
|
|
|
|
|
