Apache Kylin 权威指南（一）：背景历史和使命

编者按：本文节选自华章科技大数据技术丛书 《Apache Kylin 权威指南(第 2 版)》一书中的部分章节。

背景和历史

现今，大数据行业发展得如火如荼，新技术层出不穷，整个生态欣欣向荣。作为大数据领域最重要的技术的 Apache Hadoop 最初致力于简单的分布式存储，然后在此基础之上实现大规模并行计算，到如今在实时分析、多维分析、交互式分析、机器学习甚至人工智能等方面有了长足的发展。

2013 年年初，在 eBay 内部使用的传统数据仓库及商业智能平台碰到了“瓶颈”，传统架构只支持垂直扩展，通过在一台计算机上增加 CPU 和内存等资源来提升计算机的数据处理能力。相对于数据指数级的增长，单机扩展很快达到极限，不可避免地遇到了“瓶颈”。此外，Hadoop 大数据平台虽然能存储和批量处理大规模数据，但与 BI 平台的连接技术还不够成熟，无法提供高效的交互式查询。于是，寻找到更好的交互式大数据分析方案成为当务之急。

2013 年年中，eBay 公司启动了一个大数据项目，其中有一部分内容就是 BI on Hadoop 的预研。当时，eBay 中国卓越中心组建了一支很小的团队，他们在分析和测试了多种开源和商业解决方案后，发现没有一种方案能够完全满足当时的需求，即在超大规模数据集上提供秒级的查询性能，并基于 Hadoop 与 BI 平台无缝整合等。在研究了多种可能性后，eBay 最终决定自己来实现一套 OLAP-on-Hadoop 的解决方案，以弥补业界的此类空白。与此同时，eBay 也非常鼓励各个项目开源、回馈社区，在给负责整个技术平台的高级副总裁做汇报的时候，得到的一个反馈就是“从第一天起就做好开源的准备”。

经过一年多的研发，2014 年 9 月底，代号 Kylin 的大数据平台在 eBay 内部正式上线。Kylin 在 Hadoop 上提供标准和友好的 SQL 接口，并且查询速度非常快，原本要几分钟才能完成的查询现在几秒钟就能返回结果，BI 分析的工作效率得到几百倍的提升，获得了公司内部客户、合作伙伴及管理层的高度评价，一上线便吸引了多个种子客户。2014 年 10 月 1 日，Kylin 项目负责人韩卿将 Kylin 的源代码提交到 github.com 并正式开源。当天就得到了业界专家的关注和认可。图 1 所示为 Hortonworks 的 CTO 对 Apache Kylin 的 Twitter 评价。

图 1　Hortonworks 的 CTO 对 Apache Kylin 的 Twitter 评论

很快，Hadoop 社区的许多朋友都鼓励 eBay 将该项目贡献到 Apache 软件基金会(ASF)，让它与其他大数据项目一起获得更好的发展，在经过一个月的紧张准备和撰写了无数个版本的项目建议书后，Kylin 项目于 2014 年 11 月正式加入 Apache 孵化器项目，并由多位资深的社区活跃成员做项目导师。

在接下来的一年中，项目组再次做出了极大努力，包括按照 Apache 孵化器要求组建项目管理委员会（PMC）、建立项目网站、整理知识产权并签署必要协议、吸引外部开发者、发展多元化社区、发布多个正式版本等。2015 年 11 月，Apache 软件基金会宣布 Apache Kylin 正式成为顶级项目。

这是第一个完全由中国团队贡献到全球最大的开源软件基金会的顶级项目。项目负责人韩卿成为 Apache Kylin 项目管理委员会主席，也成为 Apache 软件基金会 160 多个顶级项目中的第一个中国人，Apache Kylin 创造了历史。正如 Kylin 的导师，时任 Apache 孵化器副总裁的 Ted Dunning 在 ASF 官方新闻稿中评价的那样：“Apache Kylin 代表了亚洲国家，特别是中国，在开源社区中越来越高的参与度。”

2016 年 3 月，由 Apache Kylin 核心开发者组建的创业公司 Kyligence 正式成立。正如多数成功的开源项目背后都有一家创业公司一样（Hadoop 领域有 Cloudera、Hortonworks 等；Spark 有 Databricks；Kafka 有 Confluent 等），Kylin 也可以通过 Kyligence 公司的进一步投入保证高速研发，并且 Kylin 的社区和生态圈也会得到不断的发展和壮大，可以预见这个开源项目将会越来越好。

在业界极具盛名的技术类独立评选中，InfoWorld 的 Bossie Award 每年都会独立挑选和评论相关的技术、应用和产品等。2015 年 9 月，Apache Kylin 与 Apache Spark、Apache Kafka、H2O、Apache Zeppelin 等一同获得了 2015 年度“最佳开源大数据工具奖”。这是业界对 Apache Kylin 的充分认可和褒奖。2016 年的 InfoWorld 获奖榜单进一步收窄，获奖者数量较前一年减少一半，一些新兴项目如 Google 领导的 TensorFlow、Apache Beam 崭露头角，值得骄傲的是，Apache Kylin 再次登上领奖台，蝉联“最佳开源大数据工具奖”。

Apache Kylin 在社区开发者的共同努力下进一步发展和完善，先后发布了 1.6、2.0～ 2.5 多个版本，涵盖近实时流、Spark 引擎、RDBMS 数据源、Cube Planner，支持 Hadoop 3.0 等众多新功能，还有一些新功能正在进行公开 beta 测试，如 Parquet 存储引擎、完全实时流数据等，预计在不远的将来会正式发布。同时，Apache Kylin 用户群也在不断发展壮大，跨越亚洲、美洲、欧洲、澳洲等地。据粗略计算，全球已经有超过一千家企业将 Apache Kylin 用于自身的关键业务分析。

Apache Kylin 的使命

Apache Kylin 的使命是实现超高速的大数据 OLAP 分析，也就是要让大数据分析像使用数据库一样简单迅速，用户的查询请求可以在秒级返回，交互式数据分析以前所未有的速度释放大数据里潜藏的知识和信息，以使我们在面对未来的挑战时占得先机。

为什么要使用 Apache Kylin

自 2006 年 Hadoop 诞生以来，大数据的存储和批处理问题得到了妥善解决，而如何高速地分析数据也就成为下一个挑战。于是各种“SQL-on-Hadoop”技术应运而生，其中以 Hive 为代表，Impala、Presto、Phoenix、Drill、Spark SQL 等紧随其后，它们的主要技术是“大规模并行处理”（Massively Parallel Processing，MPP）和“列式存储”（Columnar Storage）。

大规模并行处理可以调动多台机器进行并行计算，用线性增加资源来换取计算时间的线性下降。列式存储则将记录按列存放，不仅在访问时可以只读取需要的列，更可以利用存储设备擅长连续读取的特点，大大提高读取的速率。这两项关键技术使得 Hadoop 上的 SQL 查询速度从小时级提高到了分钟级。

然而分钟级别的查询响应仍然与交互式分析的现实需求相差很远。分析师敲入查询指令，按下回车键后，需要去倒杯咖啡，静静地等待结果。得到结果后才能根据情况调整查询，再做下一轮分析。如此反复，一个具体的场景分析常常需要几个小时甚至几天才能完成，数据分析效率低下。

这是因为大规模并行处理和列式存储虽然提高了计算和存储的速度，但并没有改变查询问题本身的时间复杂度，也没有改变查询时间与数据量呈线性增长的关系这一事实。假设查询 1 亿条记录耗时 1 分钟，那么查询 10 亿条记录就需要 10 分钟，查询 100 亿条就至少需要 1 小时 40 分钟。

当然，有很多的优化技术可以缩短查询的时间，比如更快的存储、更高效的压缩算法等，但总体来说，查询性能与数据量呈线性相关这一事实无法改变。虽然大规模并行处理允许十倍或者百倍地扩张计算集群，以期保持分钟级别的查询速度，但购买和部署十倍、百倍的计算集群又很难做到，更何况还需要高昂的硬件运维成本。

另外，对于分析师来说，完备的、经过验证的数据模型比分析性能更加重要，直接访问纷繁复杂的原始数据并进行相关分析其实并不是很美好的体验，特别是在超大规模数据集上，分析师们把更多的精力花费在了等待查询结果上，而不是用在更加重要的建立领域模型上。

Apache Kylin 怎样解决关键问题

Apache Kylin 的初衷就是解决千亿、万亿条记录的秒级查询问题，其中的关键就是打破查询时间随着数据量呈线性增长的这一规律。仔细思考大数据 OLAP，我们可以注意到两个事实。

• 大数据查询要的一般是统计结果，是多条记录经过聚合函数计算后的统计值。原始的记录则不是必需的，或者被访问的频率和概率极低。

• 聚合是按维度进行的，而维度的聚合可能性是有限的，一般不随数据的膨胀而线性增长。

基于以上两点，我们得到一个新的思路—“预计算”。应尽量多地预先计算聚合结果，在查询时刻也尽量使用预计算的结果得出查询结果，从而避免直接扫描可能无限增长的原始记录。

举例来说，要用下面的 SQL 来查询 10 月 1 日那天销量最高的商品。

SELECT item, SUM(sell_amount)FROM sell_detailsWHERE sell_date='2016-10-01'GROUP BY itemORDER BY SUM(sell_amount) DESC

传统的方法需要扫描所有的记录，找到 10 月 1 日的销售记录，然后按商品聚合销售额，最后排序返回。假如 10 月 1 日有 1 亿条交易，那么查询必需读取并累计至少 1 亿条记录，且查询速度会随将来销量的增加而逐步下降，如果日交易量提高至 2 亿条，那查询执行的时间可能会增加一倍。

而预计算的方法则会事先按维度[sell_date, item]计算 SUM(sell_amount)并将其存储下来，在查询时找到 10 月 1 日的销售商品就可以直接排序返回了。读取的记录数最大不超过维度[sell_date, item]的组合数。显然这个数字将远远小于实际的销售记录，比如 10 月 1 日的 1 亿条交易包含了 100 万种商品，那么预计算后就只有 100 万条记录了，是原来的百分之一。并且这些记录是已经按商品聚合的结果，省去了运行时的聚合运算。从未来的发展来看，查询速度只会随日期和商品数目的增长而变化，与销售记录总数不再有直接联系。假如日交易量提高一倍到 2 亿，但只要商品总数不变，那么预计算的结果记录总数就不会变，查询的速度也不会变。

“预计算”就是 Kylin 在“大规模并行处理”和“列式存储”之外，提供给大数据分析的第三个关键技术。

图书简介：https://item.jd.com/12566389.html