「案例」Kylin 在携程的实践（下）

在上期的文章中，携程分享了其当前的架构以及在使用 Kylin 过程中的挑战与心得（戳此处查看）。今天将继续携程的案例，您将看到 Kylin 在携程离线、实时分析场景中的实际应用，及携程对 Kylin 未来的展望。

离线分析案例

携程之前使用的是 OpenTSDB+Hive。采用 Kylin 前，先从 Hive 先生成聚合表，然后导入 HBase，通过 OpenTSDB 去分析，现在积累了接近百亿的数据，随着数据的增长，老的方案已经无法满足业务需求了，而且同步数据成本高，OpenTSDB 没办法支持精准去重响应时间也很差。用了 Kylin 之后，现在的业务规模已经可以支撑上百亿了，目前已经配有 200 个左右的线上活跃的 Cube。

实时分析案例

这个是去年 3、4 月份用户提的新需求。Kylin 现在是上图所示的 Streaming-Cube 的架构，Kylin 接入的是携程的 Hermes，Hermes 是 Kafka 的一个封装。我们现在支持原生 Kafka 接入和 Hermes 接入，底层沿用 MR，因为我们测试过Spark，其实很多的场景上和 MR 相当，效果不是特别明显。

这部分主要是用于度假预订状态告警，度假团队需要去分析用户预订的情况，准确实时地发送给客服人员任何预订失败等错误状况，所以这块对于数据构建落地的时间敏感度比较高。目前，通过一系列优化，Streaming 的构建基本保持在5分钟左右，可以满足一部分业务的需求。但是，更大的挑战是达到一分钟以内，也就是说秒级构建，所以对于我们来说Streaming-realtime 会是一个值得尝试的方向。

展望

携程针对 Kylin 主要有两方面的展望。

① 支持自动构建Cube

这块我们目前在调研，通过分析应用采集的元数据、SQL特征，可以自动地为用户构建 Cube，为用户节约 Kylin 的学习成本，同时减少重复查询对于 MPP 的压力。

② Real-time Streaming的调研和落地

为了能够更加丰富 Kylin 的使用场景，我们打算对 eBay 为 Kylin 贡献的实时流处理技术做进一步调研和落地工作。

Q&A

Q：演讲中提到的构建的 Cube 有 20 个指标，这种情况下去重，是精准去重还是近似去重？有多少个指标呢？

A：用户配的是精确。精确去重指标不会太多。

Q：演讲中提到20个维度的响应时间是亚秒级，有 20 个维度。请问你们做了哪些优化的工作来达到如此快的响应时间？

A：我们构建的时候，对于这种维度多的情况，建议当用户采取了以下 3 种措施来优化查询：

• 使用Mandatory Dimension；
• 实现分布式缓存；
• 配置高基维度的时候，会建议他们把高基维度往前移，这样会更高效地命中 Cube，并减小扫描的数据范围）。

Q：配了 20 个维度，最终产生的 Cube 单日有多大？

A：最大的 Cube 日产生 13 T 的数据。

Q：刚刚提到的监控方案是你们自主研发的，还是有开源的方案可以用？

A：监控是我们自主研发的。我们接入了公司已经成熟的监控平台，避免反复造轮子。

Q：分享里提到的实时5 分钟构建一次，我理解是采用批操作，并不是真正的流，而是把流几分钟拆成一个批次。是吗？

A：对的。

Q：前面讲到底层用的 MR，没用 Spark，因为觉得时间上并没有什么节省。这个是 Spark 本身的原因，还是因为你们的任务还不是很大的量？因为每次 Spark 启任务的时间和MR相比有差别？

A：离线这块目前可以达到要求，所以还没有转成Spark。我们在实时这块用 Spark 的过程中，就是像你说的，每次提交任务就很慢，达不到要求。

Q：是因为频繁提交的问题？不是因为它本身？

A：对，不是因为它本身。我们也在调研如何避免每个构建过程都启动一次 driver。

Q：在我之前的应用场景里，有一个维度特别的高基维，每天增量就很大，我们查询机制里这个维度是必选的。比如说是人的工号，里面放了很多人，然后我们要去预计算，如果说这个维度非常高，数据量会非常大，这种情况下你们会采取什么办法呢？

A：高基字段可以设置下 shard by。

Q：携程每天预计算的集群大概是有多大？

A：离线集群是 2 台物理机，每台 100 多 G 的物理机，查询节点放了 4 台虚机。实时这块，因为用户量目前不多，所以都是建在虚机上，所以内存也不大。

Q：在维度特别大，数据量又很大的情况下，剪枝的话，Cuboid 大概会控制在多少？

A：维度特别大的情况，我们最多是 4096 个 Cuboid。