Apache Kylin v2.5.0 正式发布，开源分布式分析引擎

栏目: 数据库 · 发布时间: 5年前

内容简介：日前，Apache Kylin 社区宣布，Apache Kylin 是一个开源的分布式分析引擎，旨在为极大数据集提供 SQL 接口和多维分析（OLAP）的能力。这是继 Kylin v2.4.0 版本后的又一个新功能版本，该版本引入了许多极具价值的改进，包括但不限于以下几类：

日前，Apache Kylin 社区宣布， Apache Kylin v2.5.0 正式发布 。

Apache Kylin 是一个开源的分布式分析引擎，旨在为极大数据集提供 SQL 接口和多维分析（OLAP）的能力。

这是继 Kylin v2.4.0 版本后的又一个新功能版本，该版本引入了许多极具价值的改进，包括但不限于以下几类：

All-in-Spark 的 Cubing 引擎

Kylin 的 Spark 引擎将使用 Spark 运行 Cube 计算中的所有分布式作业，包括获取各个维度的不同值，将 Cuboid 文件转换为 HBase HFile，合并 Segment，合并词典等。默认的 Spark 配置也经过优化，使得用户可以获得开箱即用的体验，相关开发任务是 KYLIN-3427, KYLIN-3441, KYLIN-3442。

Spark 任务管理也有所改进：一旦 Spark 任务开始运行，用户就可以在 Web 控制台上获得作业链接；如果用户丢弃该作业，Kylin 将立刻终止 Spark 作业以及时释放资源；如果重新启动 Kylin，它可以从上一个作业恢复，而不是重新提交新作业。

MySQL 做 Kylin 元数据的存储

在过去，HBase 是 Kylin 元数据存储的唯一选择。在某些情况下 HBase 不适用，例如使用多个 HBase 集群来为 Kylin 提供跨区域的高可用，这里复制的 HBase 集群是只读的，所以不能做元数据存储。

现在我们引入了 MySQL Metastore 以满足这种需求，此功能现在处于测试阶段，更多内容参见 KYLIN-3488。

Hybrid model 图形界面

Hybrid 是一种用于组装多个 Cube 的高级模型，它可用于部分满足 Cube 的 Schema 要发生改变的情况。这个功能过去没有图形界面，因此只有一小部分用户知道它,现在我们在 Web 界面上开启了它，以便更多用户可以尝试。

默认开启 Cube Planner

Cube planner 可以极大地优化 Cube 结构，减少构建的 Cuboid 数量，从而节省计算/存储资源并提高查询性能。它是在 Kylin v2.3 中引入的，但默认情况下没有开启，为了让更多用户看到并尝试它，我们默认在 v2.5 中启用它。算法将在第一次构建 Segment 的时候，根据数据统计自动优化 Cuboid 集合。

改进的 Segment 剪枝

Segment（分区）修剪可以有效地减少磁盘和网络I / O，因此大大提高了查询性能。过去，Kylin 只按分区列 (partitiondate column) 的值进行 Segment 的修剪。如果查询中没有将分区列作为过滤条件，那么修剪将不起作用，会扫描所有 Segment。

现在从 v2.5 开始，Kylin 将在 Segment 级别记录每个维度的最小/最大值。在扫描Segment 之前，会将查询的条件与最小/最大索引进行比较, 如果不匹配，将跳过该Segment 。更多详情请查看：KYLIN-3370 。

在 YARN 上合并字典

当 Segment 合并时，它们的词典也需要合并。在过去，字典合并发生在 Kylin 的 JVM 中，这需要使用大量的本地内存和 CPU 资源，在极端情况下（如果有几个并发作业），可能会导致 Kylin 进程崩溃。因此，一些用户不得不为 Kylin 任务节点分配更多内存，或运行多个任务节点以平衡工作负载。

从 Kylin v2.5 开始，Kylin 将把这项任务提交给 Hadoop MapReduce 和 Spark ，这样就可以解决这个瓶颈问题，更多信息请查看 KYLIN-3471。

改进使用全局字典的 Cube 构建性能

全局字典 (Global Dictionary) 是 Bitmap 精确去重计数的必要条件。如果去重列具有非常高的基数，则 GD 可能非常大，在 Cube 构建阶段，Kylin 需要通过 GD 将非整数值转换为整数，尽管 GD 已被分成多个切片，可以分开加载到内存，但是由于去重列的值是乱序的，Kylin 需要反复载入和载出 (swapin/out) 切片，这会导致构建任务非常缓慢。

该增强功能引入了一个新步骤，为每个数据块从全局字典中构建一个缩小的字典，随后每个任务只需要加载缩小的字典，从而避免频繁的载入和载出，性能比以前快3倍。查看 KYLIN-3491 了解更多信息。

改进含 TOPN,COUNT DISTINCT 的 cube 大小的估计

Cube 的大小在构建时是预先估计的，并被后续几个步骤使用，例如决定 MR / Spark 作业的分区数，计算 HBase region 切割等，它的准确与否会对构建性能产生很大影响。当存在 COUNTDISTINCT，TOPN 的度量时，因为它们的大小是灵活的，因此估计值可能跟真实值有很大偏差。在过去，用户需要调整若干个参数以使尺寸估计更接近实际尺寸，这对普通用户有点困难。

现在，Kylin 将根据收集的统计信息自动调整大小估计。这可以使估计值与实际大小更接近。查看 KYLIN-3453 了解更多信息。