| 背景介绍
引子：随着传统基于RDBMS的EDW往大数据的演进的过程中，Batch可处理的数据量越来越大，时间越来越快，但是Ad-hoc的响应速度却始终是大数据的瓶颈。
在2015年 唯品会的数据分析碰到了以下两个瓶颈：第一是数据准备的流程长，第二是缺少合适数据提取和分析工具。
首先，从数据准备流程来看，常见的流程是业务人员提出需求，BI同事定角度、找数据， 如果数据不完善，还得继续找数据开发。这就导致同一个需求，需要和不同的人反复沟通，在沟通过程中参与的人越多，信息衰减也就越厉害。再加上排期的等待，最终的结果一方面可能与初衷有所偏差，另一方面时间一长也失去了对热点关注度，分析变得非常滞后，不能及时的反应线上业务并加以改进。
其次，对于有分析能力的业务侧同学，没有趁手的工具就导致即使有能力准备撩袖子大干一场了也发现巧妇难为无米之炊，大家只能感慨大数据的门槛太高了，又回到了第一点的长时间等待的恶性循环里去了。
我们总结下来，在唯品会这样规模的公司里，数据分析有两个痛点：
需要一个可以自由组合的维度和指标的平台，业务人员可以根据自己的视角自给自足的完成数据提取和分析；
这个平台，不仅数据要够丰富，即使大数据量响应速度也要快。
针对这两个痛点，本着“让大数据成为唯品会的增长引擎”这个目标，我们大数据部门的提供了一套完整的解决方案：自助多维分析平台。我们通过有较高可扩展性的维度建模准备数据，在此之上搭建一套数据查询引擎，并配上操作简单的数据可视化前端，为业务人员搭了数据分析的台子。随着大家数据分析技能的提升，人人都是数据分析师的这个理念就逐渐在公司内部扩展开来了。
唯品会如何使用Kylin
数据和前端是皮和肉，需要通过好的数据引擎才能支撑起来。在数据引擎角度，我们通过一段时间的积累和演进，从基于Presto的ROLAP模型进化到了基于Kylin和Presto的双计算引擎。往超大数据集也要快速ad-hoc响应的方向走近了一步。
第一阶段，我们的目标是在Ad-hoc响应时间<= 10秒的前提条件下，支持：
平均每次查询10亿+明细数据做汇总；
平均每个查询0-15个维度；
平均每个查询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的结合满足了当前的需求，后面我们也会继续探索更多解决方案，寻找下一代的多维分析引擎，在此过程中，欢迎大家与我们一起讨论。 |
