Apache Kylin 在唯品会大数据的应用

背景介绍

引子：随着传统基于 RDBMS 的 EDW 往大数据的演进的过程中，Batch 可处理的数据量越来越大，时间越来越快，但是 Ad-hoc 的响应速度却始终是大数据的瓶颈。

在 2015 年 唯品会的数据分析碰到了以下两个瓶颈：第一是数据准备的流程长，第二是缺少合适数据提取和分析工具。

首先，从数据准备流程来看，常见的流程是业务人员提出需求，BI 同事定角度、找数据， 如果数据不完善，还得继续找数据开发。这就导致同一个需求，需要和不同的人反复沟通，在沟通过程中参与的人越多，信息衰减也就越厉害。再加上排期的等待，最终的结果一方面可能与初衷有所偏差，另一方面时间一长也失去了对热点关注度，分析变得非常滞后，不能及时的反应线上业务并加以改进。

其次，对于有分析能力的业务侧同学，没有趁手的工具就导致即使有能力准备撩袖子大干一场了也发现巧妇难为无米之炊，大家只能感慨大数据的门槛太高了，又回到了第一点的长时间等待的恶性循环里去了。

我们总结下来，在唯品会这样规模的公司里，数据分析有两个痛点：

1. 需要一个可以自由组合的维度和指标的平台，业务人员可以根据自己的视角自给自足的完成数据提取和分析；
2. 这个平台，不仅数据要够丰富，即使大数据量响应速度也要快。

针对这两个痛点，本着“让大数据成为唯品会的增长引擎”这个目标，我们大数据部门的提供了一套完整的解决方案：自助多维分析平台。我们通过有较高可扩展性的维度建模准备数据，在此之上搭建一套数据查询引擎，并配上操作简单的数据可视化前端，为业务人员搭了数据分析的台子。随着大家数据分析技能的提升，人人都是数据分析师的这个理念就逐渐在公司内部扩展开来了。

唯品会如何使用 Kylin

数据和前端是皮和肉，需要通过好的数据引擎才能支撑起来。在数据引擎角度，我们通过一段时间的积累和演进，从基于 Presto 的 ROLAP 模型进化到了基于 Kylin 和 Presto 的双计算引擎。往超大数据集也要快速 ad-hoc 响应的方向走近了一步。

第一阶段，我们的目标是在 Ad-hoc 响应时间 <= 10 秒的前提条件下，支持：

1. 平均每次查询 10 亿 + 明细数据做汇总；
2. 平均每个查询 0-15 个维度；
3. 平均每个查询 1-5 个指标。

根据这个目标，我们选择使用 Presto 作为计算引擎，Presto MPP 的架构 + 通过 Hive Connector 直接访问 HDFS 上的数据，为我们提供良好的 Ad-hoc 响应速度和相对较低的维护成本。为了满足高 Ad-hoc 响应速度的需求，常见的做法是把 HDFS 上处理完的数据同步到 Ad-hoc 响应友好的数据库中，比如 GreenPlum 或 Hbase 等，但这样的缺点是虽然速度上去了，但数据模型在 Hive 和 Ad-hoc 库中需要维护两份并保持一致，维护的成本非常高。Presto 的 Connector 机制很好的解决了这个问题，同时他的计算能力也满足了我们第一阶段的需求。

然后我们通过 SQL Parser，将前端拖拽或事件描述的对象转化为 SQL，同时完成 SQL 的变形和性能优化，把计算引擎和用户操作连接在一起，完成了第一阶段的目标。

自助多维分析平台一阶段逻辑架构

随着业务的不断增长，在自助多维分析平台上逐渐出现了很多维度和指标组合类似、频率较高的查询，这些查询有着明显的模式，且通过分析我们了解到这些维度和指标的组合是业务部门常用的核心数据。这些查询反复的在 Presto 上执行，显然不是最佳选择，也达不到业务部门提出的新目标，核心数据查询响应时间 <=3 秒。此时，Kylin 就成了我们的首选。我们的数据引擎的架构，也从单纯的操纵 SQL 扩展到计算引擎的路由。通过读取 Metadata 并根据规则，在 Kylin 和 Presto 两个计算引擎之间路由，我们可以在不显著提高数据模型维护成本的前提条件下，通过 Kylin 对关键数据做预计算，提高核心数据的响应速度。

为什么选择 Kylin

首先，Kylin 利用空间换时间，从原理上已经确保了 Ad-hoc 响应速度达标，和 Oracle CUBE/ 物化视图的原理相同易于理解。

第二，Kylin 支持 SQL，这对于数据分析而言至关重要，同时满足我们一个 SQL 在不同计算引擎之间路由的需求。

另外，Kylin 的 SQL on Hbase 的实现也很好的解决了 Hbase 不易查询的问题。第三是支持 Dimension-Fact 的 join，这极大的解耦了数据模型和计算引擎之间的关系，不像 ES 或 Pinot 只支持单表，还有为他们专门处理数据的额外工作。第四是对数据开发来说，创建和管理 CUBE 比较简单，且透明化了 MR 和 HBASE 同步。第五是可以很方便的在调度系统中调用 Kylin API 定时刷新 CUBE。综上所述，Kylin 对于一个数据分析系统来说是一个好的解决方案。

经过一段时间的测试和线上运行，我们在之前把 Kylin 覆盖到核心指标的查询基础上还扩展到了在 Presto 上查询需要 30 秒以上的指标和维度组合上。因为这类查询往往需要扫描大量的基础数据，在 Kylin 上预计算可以有效的较低资源使用。另一方面，基于自助多维分析平台的业务场景，我们也在以下两个场景中不启用 Kylin。第一是维度的基数大于 1 亿的场景，主要是由于大基数的维度加载的 Kylin Server 的内存中容易引起 OOM。第二是数据模型经常变化的主题，在 Kylin 中维护 CUBE 的成本就很高了，每次变化都需要重建 CUBE，重刷数据，这显然与我们提高复用降低重复开发的初衷不符。对于这两个场景，由 Presto 完成计算也可以很好的满足需求。

基于以上的原则，目前我们累计有 20+ 个 CUBE，10+T 存储，最大 CUBE 记录数上千亿，覆盖了 23% 的查询。同时，Ad-hoc 的响应速度也令人满意。Kylin 的平均响应速度是 Presto 的 10.5 倍，中位数响应速度是 Presto 的 4.5 倍。

唯品会对 Kylin 做的改进

针对唯品会的痛点，我们也在开源框架的基础上进行了修改。基础升级方面，我们针对自助多维分析平台的需求进行了升级。比如，在查找 CUBE 的时候，仅当 CUBE 内数据包含 SQL 查询的时间范围才命中 CUBE，避免给用户不完整的数据集。同时我们采集了 Kylin 运行中 metadata，并给予这些数据提供 SQL 分析 API 以解析 Kylin 能运行的 SQL 子查询。另外一些 BUG 修复也提交到了社区。

除此之外，我们基于 Presto+Kylin 双引擎的架构，开发了 Presto on Kylin 这个功能。通过在 Presto 侧增加 Kylin Connector，我们支持了 Kylin 与 Hive 数据源的跨源 Join，支持 Raw data 汇总后的数据和 Kylin Cube 数据 Join。为了支持以上两个功能，我们在 Kylin 增加了 Explain 功能简化了 Cube 命中探查的复杂度。同时，为了进一步降低数据开发寻找查询组合的复杂度，我们开发了 Cube Advisor，通过统计分析 Presto SQL 获得所有维度和指标的组合频次，根据最常使用和响应时间长两个条件，推荐合适的 Cube 定义建议，数据开发可以直接根据推荐的建议创建 Cube。

下一步，我们会改造 Kylin 维表的 Cache 机制，解决大基数维表不能创建 CUBE 的问题，同时进一步扩展 CUBE Advisor 支持一键生成 CUBE 的功能并能够支持自动刷新历史数据，降低人工维护成本。同时，将 Kylin 的应用推广到报表类数据产品。

在提高大数据分析 Ad-hoc 响应速度的路上，可谓八仙过海各显神通，我们通过 Presto 和 Kylin 的结合满足了当前的需求，后面我们也会继续探索更多解决方案，寻找下一代的多维分析引擎，在此过程中，欢迎大家与我们一起讨论。

讲师介绍

谢麟炯，唯品会大数据平台高级技术架构经理，主要负责大数据自助多维分析平台，离线数据开发平台及分析引擎团队的开发和管理工作 ，加入唯品会以来还曾负责流量基础数据的 采集和数据仓库建设以及移动流量分析等数据产品的工作。

感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。