Apache Kylin™ 是一个开源的分布式分析引擎，提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的 Hive 表。
其特征包括：
- 可扩展超快 OLAP 引擎：Kylin 是为减少在 Hadoop/Spark 上百亿规模数据查询延迟而设计
- Hadoop ANSI SQL 接口：Kylin 为 Hadoop 提供标准 SQL 支持大部分查询功能
- 交互式查询能力：通过 Kylin，用户可以与 Hadoop 数据进行亚秒级交互，在同样的数据集上提供比Hive更好的性能
- 多维立方体（MOLAP Cube）：用户能够在 Kylin 里为百亿以上数据集定义数据模型并构建立方体
- 与 BI 工具无缝整合：Kylin 提供与BI工具的整合能力，如 Tableau，PowerBI/Excel，MSTR，QlikSense，Hue 和 KXCY-BD-VIZ（跨象乘云™大数据可视化探索平台）
其他特性还包括：Job 管理与监控 / 压缩与编码 / 增量更新 / 利用 HBase Coprocessor / 基于 HyperLogLog 的 Dinstinc Count 近似算法 / 友好的 Web 界面以管理，监控和使用立方体 / 项目及表级别的访问控制安全 / 支持 LDAP、SSO 等。
同时，伴随链家业务线的拓宽和发展，以及数据生态的建设，数据规模快速增长。从 2015 年大数据部门成立至今，集群数据存储量为 9PB，服务器规模为 200 台 +。与此同时，数据需求也随着业务的发展落地不断增长，如统计分析、指标 API、运营报表等，不同业务需求差异较大，维度越来越多，需要定制化开发。面对数十亿行级别的数据，低延迟响应的特性，保障服务稳定、数据准确，链家的数据分析引擎经历了如下的发展历程。
链家 OLAP 平台及 Kylin 使用
链家 OLAP 平台结构（By 邓钫元），于 2016 年底搭建。Kylin 采用集群部署模式，共部署 6 台机器，3 台用于分布式构建 Cube，3 台用于负载均衡查询，query 单台可用内存限制在 80 G。同时，计算集群一旦运行大任务，内存压力大的时候，Hbase 就会性能非常差，为避免和计算集群互相影响，Kylin 集群依赖独立的 Hbase 集群。同时，对 Hbase 集群做了相应的优化，包括：读写分离、SSD_FIRST 优先读取远程 SSD、并对依赖的 HDFS 做了相应优化。
由于 Kylin 只专注预计算，不保存明细数据，对于即席查询和明细查询，通过自研 QE 引擎实现，底层依赖 Spark、Presto、HIVE，通过特定规则，路由到相应查询引擎执行查询。多维分析查询，由 Kylin 集群提供查询服务，可实现简单的实时聚合计算。
当前 Kylin 主要查询方为指标 API 平台，能根据查询 SQL 特征，做相应缓存。指标 API 作为数据统一出口，衍生出其他一些业务产品。使用统计，如下：Cube 数量 350+，覆盖公司 12 个业务线。Cube 存储总量 200+ TB，数据行万亿级，单 Cube 最大 40+ 亿行。日查询量 27 万+，缓存不命中情况下，时延 < 500ms (70%), < 1s (90%)，少量复杂 SQL 查询耗时 10s 左右。
Kylin 应用场景及使用规范
适用场景：数据规模大，非实时，目前能支持小时级别；维度组合和查询条件组合在可预见的范围内；查询条件扫描范围不会太大；不适合需要大范围模糊搜索排序的场景（类似 Search）。 如何能规范的使用 Kylin 很重要，在 Kylin 建设初期，踩过很多坑。并不是程序的错误，而是未能详细了解 Kylin 使用流程及规范，逐渐摸清积累了一些经验，沉淀到公司 wiki，供相关人员参考。大致如下：
一、维度优化，预计算的结果需要存储到 Hbase，且支持实时查询，因此，在配置维度时，要考虑到存储和查询的优化。包括：维度的编码，根据维度的值类型，选择合适的存储类型，可节省空间，加快 Hbase scan 效率；可根据业务需要，对维度进行分片存储，增加查询的并发度，缩短查询时间；基数允许范围内的维度，尽量采用字典编码；对于分区字段，一般格式为 yy-MM-dd hh:mm:ss，若只需要细化到天级别，可保存为数字类型 yyMMdd，极大降低维度基数。
二、根据 Hbase 的查询特性，rowkeys 是由维度组合拼接而成，因此要考虑到以后查询场景：对于查询频繁的维度，在设置 rowkeys 时，优先放在前面。
三、维度组合优化，由于维度的组合影响最终的数据量，因此如何能减少维度的组合，是 Cube 配置时所要考虑的。根据业务需要，及 Kylin 支持的特性，可进行的维度组合优化有：使用衍生维度，只物化维度表的主键，牺牲部分运行时性能进行实时 join 聚合；使用聚合组，将相关维度内聚成一组，并在聚合组内，根据维度的特征，配置强制维度、层级维度、联合维度。聚合组的设计可以非常灵活，例如，高基数的维度，可以单独一个 group。
四、及时清理失效数据。由于构建过程出错或者集群故障，会导致一些垃圾文件，随着时间积累的一些无用 segment，不但占用存储空间，增加 namenode 内存压力，以及占用 Hbase、HIVE 及 Kylin 元数据空间，因此需要定期清理掉，保持存储环境干净。
应该实时监控集群状态，重点关注 Cube 构建和查询的低延迟，不断优化数据模型及 Cube 的设计和存储，根据用户真正的需求，在存储、构建及查询性能间找到最佳的平衡点。