Apache Kylin 在 eBay 已经运行了 5 年多，并于 2019 年整体迁移到了 eBay 的 Kubernetes 平台 Tess 上，开启了 Kylin on Kubernetes 的时代，系统的可用性和扩展性显著提升，资源的管理与监控也更加简便。目前 Kylin on Kubernetes 已贡献至社区，欢迎多多尝试，一起优化。

01 前言

Apache Kylin 是一个开源的、分布式的分析型数据仓库，提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay 开发并贡献至开源社区。它能在亚秒内查询巨大的表。

Kubernetes 是用于自动部署，扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。Kubernetes 源自 Google 15 年生产环境的运维经验，同时凝聚了社区的最佳创意和实践。

把 Kylin 平台迁移到 Kubernetes 后，可以利用 Kubernetes 优势，让 Kylin 的部署，扩展和维护的成本变得更小。同时这个集成方案也把 Kylin 变成了一种更加原生的云服务。使得用户在云平台上，多了 Kylin 作为 OLAP 计算服务的一种选择。

Kylin 在 eBay 已经运行了 5 年以上，起初直接运行在物理服务器上。此前经历过一次扩容，当时是通过多部署几台物理服务器来实现的。但由于 Data Center 的迁移和 Tech Refresh 的需求，我们便在 2019 年年初，开始了把 Kylin 迁移到云上的计划。并于上半年把 Kylin 整体迁移到了 eBay 的 Kubernetes 平台 Tess 上，开启了 Kylin on Kubernetes 的时代。这个方案的计划和实施主要由 allenma，kyotoYaho，mingmwang，sanjulian 等负责，我们已经把这个方案贡献回社区。相关 PR 请参考：https://github.com/apache/kylin/pull/1182。

02 镜像

关于镜像，我们选择了 Kubernetes 推荐的 Docker：Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux 或 Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何影响。

关于 Kylin 的 Docker，为了解耦我们把它分为了两个 Dockerfile: Hadoop-client 和 Kylin，Kylin 的 Dockerfile 是基于 Hadoop-client 的。考虑到构建速度的原因，我们会把相应的安装包和源文件等存放在本地目录。

1. hadoop-client

上图是 hadoop-client 镜像的目录结构，主要由两部分组成：hdp-clients 和 Dockerfile。hdp-clients 目录下存放相关版本的客户端安装包。Dockerfile 是基于 centos，首先安装 openjdk1.8 和 krb5，然后安装 hadoop-client 目录下的客户端。

2. kylin

上图是 kylin 镜像的目录结构，主要由 4 部分组成：bin，kylin，crontab 和 Dockerfile。

bin 目录下存放着容器启动时必要的一些 shell 脚本，例如启动的脚本，清除日志，检查活性和检查可读性等。

kylin 目录下存放着 kylin 的二进制包。crontab 是为了启动定时任务配置文件，定时去执行清除日志等 shell 脚本。Dockerfile 是基于之前的 hadoop-client，首先安装一些必要的软件，例如：cronie，sudo，unzip等，然后安装 kylin 和关联相关的 hadoop 配置，最后启动定时任务和定制启动脚本。

03 部署

在 Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。这些虚拟集群被称为命名空间（namespace）。用户可以通过命令行去创建，删除和查看现有的命名空间，详细信息请参考命名空间的管理指南文档（https://kubernetes.io/zh/docs/tasks/administer-cluster/namespaces/）。

我们首先通过命令行的方式去创建一个名叫 kylin 的命名空间：

kubectl create namespace kylin

然后在 kylin 这个命名空间下创建 kylin 的服务和部署文件：

kubectl create -f {fileName}

1. Kylin 服务（service）部署：

服务部署文件主要由端口配置（ports），选择器（selector）和服务类型（type）三部分组成。

2. Kylin 服务器（pod）部署

Kylin Pod 分为主要四种模式：查询（query）服务器，工作（job）服务器，综合（all）服务器，接收器（receiver）服务器。主要由 kylin.properties 中 kylin.server.mode 的配置不同的值所决定的。具体详情请参考相关的 pull request（https://github.com/apache/kylin/pull/1182）。下面就是综合（all）模式服务器（同时具有 Job 和 Query 角色）的实例分析。

关于部署文件的话主要由元数据（metadata），容器（container）和卷（volume）的定义组成。

1）我们先来看一下元数据的定义：在元数据(metadata)中，我们定义了相应的选择器（selector）和标签（label）来表明这是一个既有查询也有构建功能的服务器。

2）在 Kylin 的部署文件中，存放着两个容器分别为 kylin 和 filebeat。其中 kylin 是主容器，而 filebeat 是辅助容器（side-car）。

在 Kylin 的主容器中，定义了镜像，资源（resource）请求，启动脚本及参数，对外端口，卷挂载（volumeMounts）等。除此之外，还可以配置自定义的活性（liveness）检测，可读性（readiness）检测。

filebeat 容器是用来收集 kylin 的日志，并统一发送到 elastic search。在这个容器中定义了镜像，资源（resource）请求，启动脚本及参数，卷挂载（volumeMounts）等。

卷（volume）挂载了容器所需要的配置文件和 log 的路径。

3. 部署配置文件

在部署 Kylin 服务器之前，容器中挂载了一些 Secret 或 ConfigMap 是需要预先定义好。通过命令行来创建相应的 Secret 或 ConfigMap，由于配置中有一些敏感文件所以会选用 Secret，如无敏感文件的话可以用 ConfigMap 更为易读：

kubectl create secret generic {secret name} -n kylin --from-file={file path} --from-file={file path}…

03 配套工具

对于 Kylin on Kubernetes 来说，首先需要解决的就是日志收集和分析。关于日志处理，首先在每个部署文件中都会有一个 filebeat 的辅助容器，用来收集当前 Pod 中 kylin container 所产生的所有 log 文件，包括了 kylin.log，kylin.gc.*.current，kylin.out，localhost_access_log.txt，catalina.*.log，localhost.*.log，详细配置请查看配置文件中的filebeat.yml。我们推荐采用 filebeat 和 Elastic Search 的技术栈作为日志收集和分析的解决方案，把日志发送到 ES 里，通过 Kibana 来进行分析。关于搭建 ES+Kibana 的服务的话，可以参考 ES 官方文档（https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-quickstart.html），就不在此做详细介绍了。而关于日志的清理方面，则是利用了定时器任务（cron job）来调用 clean-log.sh 脚本进行定期处理。

由于 kylin 服务依赖于 memcached 来实现查询结果的快速存储和用户的 session 共享。因此创建了一个 memcached on kubernetes 的集群。包括相应的 service 和 statefulset, 可以参考官方 Repo 中的 memcached-service.yaml 和 memcached-statefulset.yaml。

04 收益

这里我谈谈对于这次实践之后，给我们带来了以下的收益：

提高了系统可用性，并且实现了部署的运维过程的自动化。得益于 Kubernetes 的特性，通过使用自定义的活性（liveness）检测和可读性（readiness）检测来自动重启 Pod 和加入服务，使得不需要担心是否有哪台服务器的 kylin 进程挂了而没有及时重启，从而提高了服务的可用性。
扩容（scale up/scale out）变得十分简单。现在只需要修改一下replica的数字就能扩展或者删除一台 kylin 的应用服务器，相比之前部署一台应用服务的难度和成本大大降低。
可维护性得到显著提高。得益于 ConfigMap 和 Sercret，使得 Kylin 镜像和配置文件分离，更新配置和升级 Kylin 变得更加简单。此外，通过 ELK 来集中分析日志，可以方便快速定位出错原因，大大地提高了定位问题和纠错的效率。
借助 Kubernetes 带来的高度可移植性，使得在不同环境之间的迁移，变得逻辑简单而且结果可靠。
系统资源的管理和监控有了简便而且统一的方式，从而可以更加方便地观测硬件资源利用率，如果结合弹性伸缩策略，可以进一步提升资源使用率，从而节省公司 IT 成本。

05 展望

最后再谈谈对于这次实践的不足之处，对于接收器（receiver）的 pod 迁移来说，还需要更多手工干预。需要清理掉本地磁盘的挂载之后，才能做 pod 迁移的工作。之后也需要利用 Kubernetes 的控制器（controller）把这个步骤自动化。

06 快速上手

目前 Kylin on Kubernetes 的第一版经过社区的 review 和测试后，已经成功合并到 Github，请参考 https://github.com/apache/kylin/tree/master/kubernetes 来进行尝试。

以上就是我们实践过程的总结，希望抛砖引玉，各位读者可以多多尝试，有问题欢迎在社区邮件组讨论。

07 参考链接

本文转载自公众号apachekylin（ID：ApacheKylin）。

原文链接：

Kylin on Kubernetes 在 eBay 的实践

创作场景

Kylin on Kubernetes 在 eBay 的实践