作者：史少锋 (shaofeng@kyligence.io)，Kyligence 高级架构师
编辑：Sammi
自上世纪以来，联机分析处理 (OLAP) 技术已被企业广泛采用；企业运用 OLAP 分析其业务数据，生成报表，从而帮助业务人员制定商务决策。在当今的大数据时代，OLAP 越来越重要，且面临诸多挑战；而云计算使这种情况更加复杂化。本文介绍了大数据智能科技公司 Kyligence 如何在云上利用 Alluxio 提升其OLAP引擎的性能。
背景
Kyligence 公司 [1] 成立于 2016 年，是一家专注于大数据分析领域的科技公司。 Kyligence 的产品基于 Apache Kylin 的开源技术。
Apache Kylin [2] 是一个开源 OLAP 引擎，可为 Hadoop 上的 PB 级数据场景提供交互式分析（Apache Hadoop 是对大型数据集进行分布式存储和处理的开源软件框架）。Apache Kylin 使用 Hadoop 的并行计算技术，将超大数据集构建到 OLAP Cube 中,通过 ANSI-SQL 查询接口提供亚秒级低延迟响应。
Kyligence 的旗舰产品是 Kyligence Analytics Platform (KAP)。该产品基于 Apache Kylin，并提供了多种高级企业级功能。采用 KAP 后，用户可使用行业标准的数据仓库和商务智能 (BI) 运维方法，访问 Hadoop 上的商业智能功能。在此过程中，KAP 可以简化分析，提供自助式服务，与常用 BI 工具无缝交互。所有这一切无需编程即可实现。
云端面临的挑战
KAP 利用 Hadoop MapReduce 和 Spark 将源数据构建到 OLAP Cube 中；OLAP Cube 存储在 KyStorage 中。KyStorage 是基于分布式文件系统的并针对OLAP场景进行优化的列式存储引擎。在收到 SQL 查询时，KAP 将查询转换成对 KyStorage 的执行计划，并通过 Spark executor 来执行。
在本地部署的集群中，HDFS 是 Hadoop 和 Spark 最广泛采用的文件系统。由于数据存储在本地磁盘，且操作系统会对文件块做缓存，因此 HDFS 的访问性能很出色；另外，HDFS的文件副本默认为 3，提供了相当高的可靠性。
然而在云端，HDFS 并不是最佳选择。云上的Hadoop集群按需创建，根据工作量指标等动态增加或减小节点数。当节点停止时，虚拟机的本地磁盘将被擦除，这样可能导致数据丢失。在这种情况下，AWS S3 和 Azure Blob Store 等云存储服务，因其近乎无限的容量和大于 99.999% 的 SLA，成为最佳替代品。AWS EMR 和 Azure HDInsight 等 Hadoop 产品为这些存储服务提供原生支持。用户可通过 MapReduce、Spark 或定制应用进行透明访问，就像在常用分布式文件系统上一样。
尽管云存储服务的扩展性和持续性好于 HDFS，但其性能受到所租用的虚拟机网络带宽的限制。此外，S3 等云存储服务不是一个真正意义上的文件系统；其元数据操作如 ‘list’ 会比较耗时，’rename’ 操作实际上是 ‘copy’，对于大数据场景来说难以接受。所有这些都使其整体性能差于 HDFS。
KAP 作为一个低延迟的 OLAP 引擎，其性能在很大程度上依赖于分布式文件系统的性能。在引入 Alluxio 之前，移至云端时，用户不得不忍受性能降级，或者切换至HDFS并在 S3 与 HDFS 之间进行备份和恢复，以在性能与持久性之间获得平衡，这使得部署和维护变得复杂，且容易出错。
KAP 如何利用 Alluxio
为了克服云端的存储限制问题，我们决定在存储服务上为 KyStorage 添加一个缓存层，而Alluxio很好地满足了这个需求。
Alluxio [3] 原名 Tachyon，是世界上第一个以内存为中心的虚拟分布式存储系统。它统一了数据访问方式，为上层计算框架和底层存储系统构建了桥梁。应用程序只需连接 Alluxio 即可访问存储在任意底层存储系统中的数据。此外，Alluxio 以内存为中心的架构使得数据访问速度比现有方案快几个数量级。
在大数据生态系统中，Alluxio 介于计算框架或任务(如 Apache Spark、Apache MapReduce、Apache HBase、Apache Hive 或 Apache Flink)与各种存储系统（如Amazon S3、Google Cloud Storage、OpenStack Swift、GlusterFS、HDFS、MaprFS、Ceph、NFS 和 Alibaba OSS）之间。Alluxio 显著提升了大数据生态系统的性能。Alluxio 与 Hadoop 兼容。现有数据分析应用程序，如 Spark 和 MapReduce 程序，可以不修改任何代码，直接在 Alluxio 上运行。
此外，Alluxio 提供分层存储，不仅可以管理内存，还可管理 SSD 和 HDD，让更大的数据集存储在 Alluxio 上。数据在不同层之间自动进行管理，确保热数据在更快的存储层上。
借助 Alluxio，KAP不需要进行代码或架构更改。将 Alluxio 安装在 Spark 运行的每个节点上，将 S3 存储桶或 Azure Blob Store 映射为Alluxio的底层文件系统。然后，配置 KAP 通过 Alluxio 来读取S3 或 Blob Store 中的 KyStorage 文件。首次加载时会有点慢，因为 Alluxio 需要将数据读取到内存中。但此后的访问速度会快很多，因为 Alluxio 会智能地从 Spark executor 运行的本地工作机中返回数据块。
下面是引入 Alluxio 后的架构：
由于热数据缓存在 Alluxio 中，从而改进了读取 KyStorage 的性能，极大提升了KAP查询引擎的性能和吞吐量。我们在 AWS 和 Azure 上分别进行了基准测试，所获得的结果验证了这一推断。
AWS S3 测试
测试信息：
Apache JMeter 在 KAP 上运行 SSB 查询，并禁用查询缓存，因此每次需要从文件系统中读取 KyStorage。我们分别在 S3 和 Alluxio上收集查询性能。下面是在 S3 和 Alluxio 上运行 SSB 的统计信息。
在对比所有查询的平均查询延迟后，我们得到以下结果：
从上图可以看出，Alluxio 上的平均查询延迟为 0.4 秒，在 S3 上为 1.8 秒。KAP 在 Alluxio 上的性能比在 S3 上的性能快 4 倍之多。
Azure Blob Store 测试
为了深入了解 Alluxio 在 Windows Azure Storage Blob (WASB) 上的性能，我们进行了另一项测试。这次，我们选择真实场景（用户画像分析）并添加了使用HDFS的场景，从 Web 应用程序中收集查询样例。在运行多次后，取其平均值。
测试信息：
样例查询如下：
以下是三个存储系统的平均查询时间。
从上图可以看出，本地 HDFS 在 5 个场景中，有 4 个场景的性能是最佳的。Azure Blob Store 的执行时间在所有场景中是最长的。Alluxio 的性能介于 HDFS 和 Blob Store 之间，但与 HDFS 非常接近。平均而言，与直接读取 Azure Blob Store 相比，Alluxio 可助力 KAP 提升 3 至 4 倍的性能。
总结
Alluxio 可以通过使用其透明的命名和挂载 API，跨不同存储系统有效管理数据。采用 Alluxio 后，KAP 可以在云端，在性能、成本和管理之间实现良好的平衡。
参考文献：
[1]Kyligence
[2]Apache Kylin
[3]Alluxio
[4]SSB-Kylin
