【PPT 下载】案例 | 极光百万级日查询量的应用选型与商业升级

近期在 Kyligence 举办的线上直播分享中，我们邀请到了企业客户极光的李孚煜老师为大家带来 Kylin 在极光的应用以及后期从开源版 Kylin 迁移到商业版 Kyligence 的实践历程，错过现场Live 的同学可以从本文了解极光在大数据场景下的 OLAP 选型考量，以及从开源 Kylin 到企业版 Kyligence 的不停机平滑升级方案。

极光作为国内领先的开发者服务提供商主要提供两部分服务，首先是一些 SaaS 产品，主要是用于市场调查、金融风控、商业地理服务；另外就是广告业务，利用数据帮助用户做好精准营销、RTA 广告优化等业务。

Kylin 在极光业务中的应用

综合来说，Kylin 在以下常见的一些应用场景中为极光提供了 MOLAP 能力，即多维分析能力。

从业务视角来看，Kylin 主要为极光统计、认证、推送、魔链，以及iAPP前端业务做好后台的数据分析，通过这些服务能够让极光的用户快速分析用户来源，提升使用粘性；也能让用户在使用过程中通过简明的数据报表，丰富的统计维度为决策提供数据支撑。

从下游分析来看，Kylin 支撑了 CRM 系统、广告指标、以及 Portal/iPortal 三个主要版块，帮助业务人员查看各平台的统计数据，以及快速获知在广告投放中的曝光量、点击量、点击率在不同时间、渠道、投放位置等维度下的收益情况。Portal/iportal主要由开发人员使用，通过接入 SDK 来查看某一个区域产生的新增背后的影响指标。

极光多维分析面临的技术挑战

极光很多常见的数据统计应用都是典型的 MOLAP 场景，在技术层面面临多重数据挑战：

1）巨大的查询压力，下图可见在一个小时之内，SQL 查询量大概达到了21 W 次之多

2）巨大的数据量，单个数据源表千亿行数据级别，且单个数据源达百TB级别；
3）95% 的查询要求 1 秒内响应，极少数复杂查询不能超过 30 秒；
4）下游较灵活的查询方式, 需支持带有复杂条件的 SQL 查询。

OLAP 工具选型对比

以上挑战也成了极光在 OLAP 应用中选型的重要依据，依托于高 QPS、海量数据查询能力、秒级查询响应，以及灵活查询方式这四个维度对Hive、Spark、Impala、Druid、Clickhouse、Flink 和 Kylin 做了对比选型。

首先，以上工具都能应对巨大数据量的挑战，但在其他关键功能中都会有各自的优劣势。

从高性能高 QPS 并发能力角度讲，Hive、Spark、Impala，这三个都是在 Hadoop 生态圈上的一个支持 SQL 的分布式查询引擎，对高并发场景支持较差。试想下，假如用同样规模计算资源的 Hive 或 Spark，进行每个小时 21 万次的SQL并发高性能查询是几乎不可能做到的。

秒级查询响和数据源极大的数据量级直接淘汰了各种即席查询方案，只有通过预计算才能同时满足这两方面的要求；加之极光面对的相对复杂的多维查询，预计算方案必须能应对非常灵活的聚合条件查询，而 Druid 只做了 Kylin 的 basic cuboid 的预计算，相比之下 Kylin 预计算粒度更细，当查询命中粒度更细的 cuboid 时，Kylin 的查询响应速度比 Druid 快得多，另外，Druid 也无法做到精确去重。

Clickhouse 的性能虽然非常强，但更擅长明细级别的高性能查询，因此在复杂的聚合查询中无法同时满足高性能高 QPS，另外 Clickhouse 与其他列式的工具不同的是其属于 C++ 技术栈，但企业大部分做数据的人员多为 Java 技术栈，选用此组建需要新组建技术栈力量进行运维，而且能否有稳定的运维环境也是需要考虑的一个重要因素。

最后说下实时性取向，Flink 更擅长的是数据摄入的实时性，确保数据从各个平台到统计指标库反映的实时性，而 Kylin 赋能的则是查询的实时性，能够帮助极光很好的响应客户的查询需求。

综合来看，极光的数据平台需求是能够提供灵活查询方式、高 QPS、查询海量数据源的能力，并且确保绝大部分查询在亚秒级响应。基于以上要求及考量，可行选项只有 Kylin 或者是商业版Kyligence。

Kylin 是一个综合的系统，架构本身是可插拔的，比如说像  Build 构建或者查询都可以选用 Spark，当然 Build 也可以选用 Flink。针对后端的存储，社区版默认 Cube 存储是用 HBase，美团使用的后端是 Kylin on Druid，Kylin 商业版以及社区版下一个大版本采用的是 Kylin on Parquet，Kylin 开源版的 Cube 都是存储在 HBase上，但 HBase 的存储结构和coprocessor有限的扩展能力带来了诸多影响，例如做聚合查询需要把数据都扫出来，然后再到单台机器上去做聚合。

实际上基于 Spark 或者基于 Hive 也可以完成 Kylin 快速分析的功能，但需要企业自己把 Kylin 已经提供的功能再做一遍，比如说需要自行去写一个独立的元数据系统，另外在预计算的剪枝规则算法也得自己实现。

从技术架构上来看，选择 Kylin 还有以下原因：

• 提供独立的元数据系统
• 提供成熟的预计算剪枝算法规则
• 实现读写的完全解耦，不需要企业自己去基于 Spark 或是基于 Flink 来实现
• 实际上可以把 Kylin 当做是 Hadoop 上 SQL 查询透明的加速层, 企业习惯使用 Hive 进行查询和数据分析的话, HQL（Hive SQL） 可以不加修改地放在 Kylin 或者企业版 Kyligence 上运行，只不过因为预计算的存在, 查询的速度会快几个量级
• Kylin 还拥有在 Hadoop 生态系统中的唯一性. 目前 Hadoop 生态圈中成熟的MOLAP 解决方案基本只有 Kylin/Kyligence Enterprise 这一个选择

从 Kylin 升级到 Kyligence（Kylin 商业版） 

升级背后的原因

1）开源版平台稳定性较差

• HBase 运维繁琐
  
  

在使用 Kylin 的过程中发现 Kylin 的很多瓶颈是 HBase 带来的，包括运维也非常烦琐，比如说 HBase 需要去做 Rebalance，但如果让 HBase 自行去 Rebalance的话就会把 Kylin 的 相关 region 移动到错误的地方，导致 Kylin 无法找到 Segment，整个流程操作可能都需要人员特殊去操作，造成整个运维会非常繁复。

• Cube 元数据不稳定，异常频繁
• 当 HBase 负载高了之后 Cube 重构修复代价非常高

2）业务查询稳定性/性能较差

• 常用的高基维的查询慢、TopN 性能在社区版较差
• 复合索引查询慢
• 业务优化 Cube 查询能力有限
• 直接面向外部用户，性能要求达不到客户需求

3）人员招聘/稳定性低

• 有 Kylin 相关技能的专业人员招聘困难
• 人才培养周期较长
• 异常定位慢，解决问题周期长，影响线上 SLA

Kylin vs Kyligence（Kylin 商业版）
在经过与 Kyligence 团队的沟通后，可以看到在开源版和企业版在架构上有以下对比：

在使用 Kyligence Enterprise 之后，在极光 Top2000 项目上可以看到 3 个比较关键的指标的性能提升非常明显：

• 汇总新增：90%分位由原先的68秒提升至5秒以内
• 安卓推送送达：90%分位由10秒提升至3秒
• 推送目标数：95%分位由4.5秒提升至2秒内

KE ：Kyligence Enterprise

另外，从查询整体的提升情况来看，下图是 Kylin 和 Kyligence 各自在 1 小时内的查询性能统计对比：

可以看到开源版 Kylin 在每小时查询 83,000 多次的情况下，90% 的分位点的时间是 19.985 秒，也就是说在这个 83,000 的 QPH 的情况下，10% 的查询响应时间接近 20 秒，企业版 Kyligence 在 QPH 在峰值 21 万的情况下只有 2.34% 的查询是超过了1 秒钟，其余 97.66% 的查询都稳定在 1 秒以内，剩下的也大部分是在 5 秒以内，整体性能和稳定性对比开源版都有明显提升。

不停机平滑迁移方案

当计划从开源版迁移至企业版时，主要面临 4 个比较大的挑战：

1. 首先就是查询并发压力大，每天面对百万级查询请求，同时并发压力大，迁移过程中也要保证原有开源 Kylin 查询准确，不能中断业务
   
2. 项目周期短，开源 Kylin 在使用过程中已经明显支撑不住查询压力，需要快速进行迁移，有 200+ 个Cube，14000+个 segment 待迁移，整个过程不能有停机的问题出现，Cube 存储架构改变后需要去反复确认源数据，确保两边的数据一致性。
3. 同步优化慢查询，需要快速优化高基维、TopN Cube，循环统计慢查询进行优化。
4. 异常定位回溯，Hive 历史会有数据回溯，但对数据校验要求较高，迁移过程中开源 Kylin 故障持续，源数据修复及人工刷新导致校对难度大。

下图是极光从 Kylin 2.6.2 迁移至 Kyligence Enterprise 3.x 的大致流程思路：

前端迁移方案是基于  Nginx 转发，好处是对下游使用者或是业务方完全透明, 不需要配合做任何额外操作. 转发规则的控制全部在 Nginx 中控制，形成灰度的升级，业务人员的日常使用不受任何影响。

想要做好这一步，首先需要设置访问路由，如下图架构，就是把 Kylin 的 Query 查询和 Build 通过 Nginx 在上层完全分隔开，即做成两个 Nginx 分别映射，再通过 MySQL 集群 VIP 去访问，提供给下游访问的唯一的 VIP，下游只需要知道这个 IP 就行，前端不需要改任何东西。

如上图，Query 的 http或者JDBC 请求都是通过同一个 VIP 访问Nginx集群，最终会通过 Nginx 轮询分发给 Kylin 各 Query 节点；nginx可以从API URL可以直接拿到cube名称,  虽然不能获取project名称但是可以通过加入cube/project字典查得所属project. nginx取得cube和project之后, 就可以按需求通过转发规则控制cube或者project粒度的转发, 从而实现查询的灰度上线.

Build 也类似（Build 请求上没有 JDBC，只有http），也是通过 VIP  访问 Nginx 集群，然后 Nginx 根据转发规则去转发给各 Build 节点。Nginx 对 Build 请求的处理略有不同, 从 build 的 request body data 能取得project名称, 但是 cube 名称需要从request body data 的 SQL 中解析. 我们通过 lua 代码从 SQL 中提取了 cube 名称, 从而实现通过转发规则控制 cube 或者 project 粒度的转发.

迁徙过程中有对 Build 构建业务和 Query 查询业务两个模块分开来灰度迁徙，build业务保持双跑, 保持新老集群数据一直方便出问题时随时回退切换. 两边数据核对无误之后按project粒度灰度切换Query业务, 全程下游无感知不停机. 具体细节如下:

（1）Build 迁徙过程中主要使用 Nginx mirror 流量复制的功能来实现迁徙 Cube segment 同步平衡。当然在这之前需要把存量的 Segment 先迁徙过来，另外准备了一个 job 比对工具，每天几个时间段会定时扫描两边的 Segment 差异进行对比，并将不一致的 Segment 进行输出，修复因业务端手动操作 merge/build等导致与ETL正常调度刷新的 Segment 不平衡的情况。

（2）Query 模块迁徙也是类似的方法，通过 VIP 去访问， Nginx 完全控制查询应该转到哪一个集群的转发规则，下游业务对接不需要做任何修改，而且可以做 Cube 级别的切换，就是控制每一个 Cube 去访问每一个集群，而且整个过程是不需要停滞的，下游没有感知。

以上两部分区分开后，先把 Build 迁徙切换完成，然后通过 Nginx mirror 进行 Build 双跑，使两边 Segment 达到同步平衡。然后迁徙 Query 业务模块，Query 可以按照 Cube 或者按照 Project 在 Nginx 中配置进行增量迁移，让下游业务无感知的进行查询业务迁徙。

这种迁徙方案具有一定的普适性，可以用于社区版大版本升级或者社区版往商业版的迁徙。极光在实践中，社区版从 2.1 到 2.6 的跨版本升级和社区版迁往商业版用的都是该方案思路。

如果您对我们的方案感兴趣，欢迎点击这里下载 PPT