Telecoming 是一家致力于电信运营商计费技术的西班牙公司，核心业务涵盖内容合作、支付技术部署和在线广告等数字娱乐领域，拥有专业的效果营销团队，业务遍布13个国家。使用 Apache Kylin 帮助 Telecoming 大幅度缩短了数据查询时间，加速业务决策，扩大了大数据对公司运营的影响力。下文来自 Telecoming 的 Iñigo Martinez，对 Kylin 版本升级进行了经验分享。
原作者：Iñigo Martinez
原文：https://kylin.apache.org/blog/2019/05/29/kylin-2.4.1-to-2.6.1/
翻译：Rachel、敏丞（翻译经原作者授权，对原文略有改动）
2017 年底，Telecoming 开始在一个新的商业智能项目中使用 Apache Kylin 作为主要的分析数据库。我们最初使用基于 MySQL 的定制报告引擎，到后来基于 AWS Redshift，最后采用完全基于 Hadoop 的解决方案，Kylin 用于生成报表前的最后一环。我们最开始使用 Kylin v2.2.1，2018年年中迁移到 v2.4.1，并于上月迁移到 v2.6.1。Kylin v2.2.1 是我们使用的第一个版本，有一些恼人的 bug 和稳定性问题。这不仅是因为版本不太成熟，还因为我们没有维护 Kylin 的经验。我们在 Cube 级别进行了一些设计更改和优化（在此感谢 Alberto Ramon），帮助我们很大程度上提高了性能和稳定性，但在之后的版本中仍然存在一些问题。
以下是我们的升级经验。
升级目的：
1）Bug 修复。尤其是在创建中间 Hive 表时与视图相关的一个 bug。
2）性能增强。这是大家总追求的。
3）对 HBase 的依赖性降低。HBase 是我们的主要问题来源。部分原因是由于 EMR（AWS）依赖 S3 作为主要的存储（现在我们使用 HDP）。Kylin 经常需要访问表元数据，HBase 的响应速度不稳定。因此，我们希望避免在 HBase 存储元数据，通过 JDBC 将元数据存储到 MySQL。
升级计划：
1）尽量减少停机时间。由于我们的用户大量使用报表系统，因此最大限度地减少 Kylin 的停机时间是非常必要的。
2）易于回滚。如果升级失败，我们需要一种简单的回滚方法。
升级步骤：
1）我们备好一个装有 Kylin v2.6.1 的新 AWS 实例，该实例已经完成了配置和调整。当然，之前我们已经运行了几周的 Kylin v2.6.1 原型并调整了所有配置文件以便正常运行。我们开始迁移时停止了该新实例。它还有一个全新的本地 MySQL v5.7 用于元数据存储，而不是依赖于 HBase。
2）我们停止了 Kylin v2.4.1 上的所有 Cube 构建。我们等到那些正在进行的任务完成了。 因此，在查询方面，虽然没有添加更多数据，但一切正常。
3）当所有构建完成后，我们对 Kylin 元数据（metastore.sh backup）执行了完整备份。 这只花了2分钟。
4）我们对所有 HBase 表执行了 HBase 快照。因此，在升级版本完全失败的情况下回滚就变得简单：恢复元数据+克隆快照到新表（删除已被升级的表）。因为可以在一个命令中运行所有快照命令，因此此过程只需几秒钟。
5）我们在新的 Kylin v2.6.1 实例（metastore.sh restore）上执行了元数据恢复。通过这种方式，所有元数据都可以在几分钟内自动从基于 HBase 的存储迁移到基于 JDBC 的存储。
6）我们从 v2.6.1 升级了 Coprocessor（使用 kylin.sh org.apache.kylin.storage.hbase.util.DeployCoprocessorCLI default all）。
7）我们启动了新版本的 Kylin，并检查确认一切就绪。我们可以查询所有 Cube 并得到正确的响应。
8）完成所有测试后，我们将 DNS 条目指向新的 Kylin v2.6.1 实例，并从中恢复构建过程。当然，Kylin v2.4.1 已被关闭。几天后，我们删除了 HBase 快照以释放存储空间。
可以想象，从查询视角来看，停机时间几乎为零，因为所有的 Kylin 查询都是在 v2.4.1 运行，直到 v2.6.1 准备好为请求提供服务。
回滚计划（实际并未使用）：
回滚计划非常简单。如果出现问题，我们将切换到旧版本，我们将从之前拍摄的快照中恢复所有 HBase 表。此快照包含 HBase 元数据表，因此无需还原元数据。
升级结果：
1）Kylin v2.6.1 比 v2.4.1 更稳定。我们在服务器级别发现的唯一问题是平台级别的内存问题。现在，许多步骤都是基于 Spark 的，并在启动作业时占用一些额外的内存。我们通过调整 Kylin v2.6.1 的 JVM（-Xmx, -Xms）参数轻松解决了此问题。
2）由于 Cube 构建步骤的改进，Cube 构建得更快。
3）UI 响应非常快。以前浏览 Cube 构建列表最多需要10秒，现在它几乎能瞬间完成。
4）解决了一些 bug。以下两个尤为突出：
- 视图中的 Hive 中间表没有添加 uuid 后缀。如果将同一个表用于其他构建，此表可能会在清理阶段被以前的 Job 意外删除，导致构建失败。
- 参数“kylin.job.cube-auto-ready-enabled”无效。在构建一个 Segment 后，它会被自动启用，我们有时不希望这样。
结语：
总的来说，升级过程简单快捷。然而，为了测试升级是否会造成潜在的问题，必须进行大量前期工作。因此，我们构建了一个并行环境，以检查所有新功能是否正常工作，bug 是否得到解决。我们调整了配置文件以满足新版本 Kylin 的要求，例如将元数据存储从 HBase 替换为 MySQL。
升级 Kylin 版本总体来说较简单，但是，必须仔细阅读文档，因为有时需要额外的步骤，当然还要检查参数，以便检测新版本中必须考虑的新特性或变化。为了能在升级失败后迅速恢复，做好备份和(经过测试的)回滚计划也非常重要。
从我们用户的角度来看，解决得最成功的问题是 UI 响应。我们非常高兴看到 Kylin 界面现在能如此快速流畅地响应。从运维方面来看，使用 MySQL 作为元数据存储而不是 HBase 也是一个很大的改进。在 HBase 上编辑 Json 内部的参数可能很困难，因为能编辑修改 HBase 表的应用程序不多。
了解更多大数据资讯，点击进入Kyligence官网