小米大数据：借助Apache Kylin打造高效、易用的一站式OLAP解决方案

做者 | 小米大数据

现在的小米不只是一家手机公司，更是一家大数据与人工智能公司。随着小米公司各项业务的快速发展，数据中的商业价值也愈发突显。而与此同时，各业务团队在数据查询、分析等方面的压力一样正在剧增。所以，为帮助公司各业务线解决这些数据方面的挑战，小米大数据团队不断地尝试经过不一样的技术手段打造新的解决方案。

小米大数据，是一支以“融汇公司全景数据，经过数据驱动、AI 赋能公司核心业务”为使命的研发技术团队，目前主要负责设计、完善公司级数据仓库解决方案，提供完备及全链条的数据治理一站式平台，连通各业务线数据，开发通用的画像平台与分析引擎。小米大数据团队的目标，在于不断提高数据产品与服务品质，并依托数据科学、机器学习等技术赋能核心业务。

1 业务团队亟需统1、低门槛的 OLAP 解决方案

2012 年小米大数据团队成立以后，数据平台、用户画像等通用性的技术体系相继在公司内部创建了起来。然而因为业务需求的快速变化，新的挑战也不断随之出现，好比在多维数据分析及 OLAP 需求中所遇到的诸多困难，就是其中的典型。

OLAP 的价值可体如今实现精细化运营、提高数据处理效率、改善数据可视化效果等多个方面。但小米公司内部的业务种类异常繁杂，各业务团队为了具有多维数据分析能力而各自创建了独立的 OLAP 分析系统。这些 OLAP 引擎大可能是采用指标数据先进入 MySQL，再在前端进行展现的方法，而这样就将面临如下问题：

1. 基于 MySQL 的架构，在大数据上的查询效率低下；
2. 业务间 OLAP 引擎不统一，数据管道冗长，数据复用率极低，开发工做周期变长，维护成本增长；
3. 缺少统一的维表和事实表，同主题下数据统计口径不一致；
4. 新增业务须要投入较大的成本才能得到基础的 OLAP 能力。

通过充分的内部沟通以后，发现各业务团队的基础需求主要包括如下四点：

1. 报表能力；
2. 提供 OLAP 查询接口，支持各类即席分析； 尽量下降使用门槛（ETL 以及查询的门槛）；
3. 初级阶段只需支持离线分析需求。

举例来讲，其中最多见的一类需求是——开发资源至关有限的新业务，如何能在 1 天时间内开发出关键指标的多维分析看板？在这种状况下又该如何系统性地设计、搭建技术架构与解决方案？

2 以小米大数据平台核心——数据金字塔体系为基础

为了进一步知足各业务线的实际需求，小米大数据认为有必要基于自行设计的数据治理体系——“数据金字塔”，来开发一套端到端的 OLAP 解决方案。

数据金字塔体系的结构

数据金字塔，是小米大数据平台技术架构中的核心部分，其目标是承载、管理、促进小米公司内的数据生态环境。该体系可将数据由下至上分布在源数据层、中间层、汇总层、应用层，共四个层面中：

• 源数据层：对来源于业务线的数据进行采集、存放等最粗粒度的处理工做。这些业务数据进入源数据层以前，须要遵循科学的打点规范并准备好数据同步策略及工具。


• 中间层：对源数据层的数据进行 ETL，合乎规范的数据表将被存放在该层中。数据表包含事实表和维表，事实表用于记录业务过程的事实数据，而维表则记录维度关系。事实表和维表都须要遵循严格的命名与操做规范。

• 汇总层：公司级或业务级的主题数据都归属于该层。典型的主题表每每会对跨业务线的多张中间表进行汇总。例如小米用户画像，就是来源于公司内部多项业务数据的挖掘汇总而成。主题表是业务数据的高度归纳，基本上能知足业务团队 80% 以上的数据需求。


• 应用层：结合中间层与汇总层中的数据，对其进行优化，并开发定制化的数据能力与工具，或提供业务级甚至公司级的数据服务。 公司各业务线的在线服务日志以及其余数据源的数据（MySQL 等等），可经过数据流服务下沉到 HDFS、Kudu、HBase 等引擎中，通过数据金字塔建模后再提供给业务团队使用。

源数据层中的数据能够类比为数据湖（Data Lake），包含多种原始数据。通过源数据层的加工，数据会向上进入中间层。在中间层中，将清洗脏数据，统一数据统计口径，再经历一系列的 Join 操做和其余 ETL 过程后，会生成汇总层数据。汇总层的数据一般会更面向主题，且具备必定的通用性，例如订单、画像等等。最后在应用层中，针对业务团队的分析需求，可直接基于汇总层与中间层数据的集合，构建个性化的数据集市。

梳理数据流程，简化数据模型

所以，为了节约重复开发成本，基于上述数据治理体系，小米大数据开发了一系列通过优化的解决方案，其中就包括本文所涉及的核心内容——UnionSQL。

3 利用 Apache Kylin 的特性构建定制化 OLAP 解决方案

OLAP 常见的应用场景可分为数据看板、即席查询这两种，每种场景对于查询效率与数据新鲜度都有着不一样的要求。而在最初阶段下，小米大数据的主要目标是集中精力解决对于离线数据 OLAP 能力的问题。

针对 OLAP 解决方案的技术选型问题，小米大数据鉴于以前在 Elasticsearch 上所积累的经验，对于数据量不太大的业务，首先尝试了基于 Elasticsearch+Logstash+Kibana 的解决方案。尽管 Elasticsearch 在查询效率方面表现不错，也对地理位置信息类数据进行了特殊优化，可是其自己更适用于原始数据的检索，而在数据摄入、查询语法等方面的表现也并非很理想。在此以后，Apache Kylin、Druid、ClickHouse 等方案也成为了候选项，小米大数据在结合了实际业务需求与环境后，决定从如下方面进行考量：

• 可知足大多数需求，支持常见的算子，以及数据的摄入、查询速度足够快；


• 保证良好的 SLA；

• 使用门槛相对较低。

Apache Kylin 架构

做为候选方案之一的 Apache Kylin，基本支持常见的 SQL 语法，并能知足一般状况下的需求。数据摄入主要依赖 MapReduce、Spark 任务将 Hive 中的数据转换为对应 Cube 的 Segment（HFile），效率方面尚可，而在查询速度方面也能提供秒级支持。对于一些如 distinct 等复杂场景而言，Apache Kylin 也提供了高精度但低效，以及高效但存在可容忍偏差，这两种计算方式，以适用不一样的业务场景需求。

在 SLA 方面，鉴于以前小米相关团队在 Hadoop 技术栈上积累的经验，所以一样也能针对 Apache Kylin 而提供良好的 SLA 保障。此外，Apache Kylin 自己的设计与传统数据仓库相一致，学习构建 Cube 的门槛不高，而数据的查询基于 SQL 语法，同时还提供了 JDBC 接口和 Rest API，便于现有系统对接。同时 Apache Kylin 也能较好地与 Apache Superset 等开源可视化方案进行整合，易于进行数据可视化处理。目前小米公司的部分业务已实如今日志进入数据流以后，基于现有解决方案生成数据看板等可视化的功能。

因而可知，Apache Kylin 知足了上述考量要求，并最终做为 OLAP 引擎方案而进入了小米大数据平台的技术架构，而这套完整的 OLAP 解决方案则被命名为 UnionSQL。

4 愈来愈多的内部业务开始受益于 UnionSQL

在引入 Apache Kylin 做为 OLAP 引擎以后，就可将须要进行分析的数据抽象成星型模型，其中的受益之处包括：

1. 只需维护最细粒度的事实分析数据，进行简单的 ETL 处理；
2. 数据流变得更清晰；
3. 维护成本进一步下降。

截止到 2018 年第三季度，小米公司内部已有超过 50 个业务接入 UnionSQL 解决方案, 其中涉及手机、MIUI、小爱同窗、新零售等相关核心业务，Cube 存储空间已超过 50TB，且 95% 的查询都能在 0.35 秒内返回。UnionSQL 的架构以下图所示：

SQL 计划器会将用户的查询进行解析与重排，而 SQL 转发器则会把改写后的结果分发给不一样的引擎。例如，当最终用户想知道某个区域的实时运营活动点击率的时候，会基于 Lambda 架构，将历史数据的查询分发给 Apache Kylin，而实时数据的查询则分发给 Elasticsearch。

众所周知，点击率 = 点击 / 曝光，但若是直接在不一样引擎中计算点击率，并将获得的结果相加，就会获得一个错误的点击率。所以，UnionSQL 引擎则会将原始 SQL 进行重写，再分别计算点击量和曝光量，最后在 UnionSQL 引擎中从新计算点击率，并将正确的结果返回给最终用户。

UnionSQL 的核心理念是“快”——上手快、数据更新快、查询响应快，同时还能越用越快。

UnionSQL 解决方案的诸多优点

在上手方面，UnionSQL 基于 SQL 语法向最终用户提供服务，极大地下降了使用门槛，同时还内置支持 Lambda 架构以及多机房访问。最终用户无需了解多种查询引擎，只需经过 SQL 语句描述需求，UnionSQL 就能基于元数据将 SQL 改写后分发给正确的引擎，并以统一的数据格式返回给最终用户。

在数据更新方面，UnionSQL 基于公司内部的数据流服务与 Lambda 架构，成功将数据延迟控制在了 2 分钟时间之内。

在查询响应方面，UnionSQL 基于 Apache Kylin 等优秀的 OLAP 引擎，以及内置的 Cache/ 自动扩容能力，使 P95 查询低于 320 毫秒。

此外，UnionSQL 还能基于慢查询智能优化引擎，可发现问题并提供慢查询优化建议，进行不一样引擎的切换，或 Apache Kylin 中 Cube 的构建优化等，实现查询得越多速度就越快。

Lambda on OLAP 架构

5 三类主要的 OLAP 落地场景

通常状况下，业务团队的 OLAP 需求可大致分为三类——用户画像、数据运营、数据分析。

在用户画像方面，小米拥有公司级的通用画像表，可为各业务提供人群画像支持。以小米之家为例, 该业务的数据进入数据金字塔的汇总层后，能够和通用画像表相结合, 对用户人群进行多维分析。

用户画像分析的效果

在数据运营方面，小米内部的每一项业务均可能会产生海量的数据，那么如何才能让运营人员便捷、 快速地查看整个业务的各项关键性指标以及历史趋势，正是业务团队的刚性需求。以小米音乐为例，运营人员须要天天看到用户活跃状况，以及热门歌曲、热门歌单、播放时长等相关指标。而经过 Apache Kylin 与 Apache Superset 的配合，就能够实现这些指标的快速可视化并展现给运营人员。

在数据分析方面，以小爱同窗的相关业务为例，在一些运营活动中，会主动向用户推送具备引导性的内容。在 2018 年俄罗斯世界杯进行期间，小爱同窗就加入了相似的运营干预。例如，用户向小爱同窗询问与天气相关的问题，小爱同窗在完成回答以后还将加上一个“小提示”，如“世界杯来了，足球知识早知道，坚定不作伪球迷，快对我说：什么是越位”等等。小米大数据团队内部将其称之为“素材”，而要想评估素材的效果，就须要经过数据分析来了解用户后续是否进行了小爱同窗所提示的操做。

6 小米针对 Apache Kylin 进行了诸多定制化扩展

在小米公司内部，针对 Apache Kylin 的开发主要基于社区所发布的版本，根据公司内部业务的具体需求，再进行定制化的改进或扩展，以便更好地服务各业务团队。

在当前阶段下，对 Apache Kylin 的优化工做主要集中在监控与部署、同外部系统的集成与整合、以及服务限制，这三个方面上。

1、监控与部署

在监控方面：

1. 支持 Apache Kylin 将内部 Metrics 推送到 Faclon 监控系统上；
2. 实现做业构建成功时 HTTP 回调以及构建失败时发送短信通知；
3. 支持周期性的 Query 探测，可将 Kylin 集群的实时可用性推送到 Falcon 监控系统上，便于及时报警。

在部署方面：

• 修改了 Apache Kylin 的打包方式，去掉了默认的 Spark、Hadoop 依赖，添加了小米公司内部维护的 Hadoop、Spark、HBase、Hive 版本，并打包成了一个完整的发布包；


• 与公司内部的自动化部署平台进行整合，将发布包和配置进行分离，支持自动化包与配置升级，加快开发与迭代的速度。

2、同外部系统的集成与整合在 HBase 方面：

1. 支持 HBase 0.98，可设置 HBase 命名空间，经过 HBase Namespace Quota，避免 Apache Kylin 在共用 HBase 集群时建立太多的表；
2. 支持 HBase 使用独立的 HDFS 集群。

在用户管理方面：

因为安全性问题，公司内部没法使用 LDAP 服务，所以修改了 Apache Kylin 的用户管理功能，将其用户密码加密存储在了 Kylin 的元数据中，并增长了新的用户管理功能，以便管理员直接添加用户或修改相关权限。

3、服务限制

为避免最终用户误用，保证服务质量，而在 Apache Kylin 社区版本的基础上添加了一些必要限制：

1. 限制 Query 中 IN 语句里值的个数，避免过大 in values 从而致使请求变慢；
2. 限制 Query 的最大长度以及一个 Query 执行涉及的 Segment 个数；
3. 限制 Segment 构建数据的膨胀率，使膨胀率超过限制的构建直接失败，经过线下的方式再单独协助最终用户优化及调整 Cube；
4. 在线上环境中增长了对 Cube 的最大数据量限制， 避免 HDFS 过量使用；
5. 添加了构建过程当中如 distinct 等聚合函数使用 buffer 大小的限制，避免在 HBase 上写入一个 Key-Value 存储过大的数据。

此外，对于一些具备通用性质的修改，小米内部相关团队也将会逐步反馈给社区。

7 将来将尝试进一步解决多租户支持问题

尽管 Apache Kylin 项目已发展地较为成熟、稳定，但其在小米公司内部环境下的推广与使用过程当中，仍然还有一些问题须要进一步解决，好比针对多租户的支持问题。

目前 Apache Kylin 对多租户并不友好，仅支持不一样构建做业运行在不一样的 Hadoop 队列上。 在开启安全的 Hadoop、Hive、HBase 集群上，若是最终用户使用相同的 Kerberos 账号， 以及相同的 HDFS 路径与和 HBase 命名空间，将很难避免不一样项目之间互相产生影响。

将来计划以项目为基本单位，支持设置独立的 Kerberos 账号，可设置 HDFS、HBase 空间和名称，隔离不一样项目的 Kerberos 权限及存储空间的使用，避免出现不一样用户之间的互相干扰。

8 更多探索未完待续

借助 Apache Kylin 的诸多特性，UnionSQL 解决方案为小米公司内部各业务团队提供了简洁、快速、统一的数据查询服务，实现了对公司核心业务的赋能。

随着在内部业务上的落地与应用，小米大数据团队在 UnionSQL 上，还针对支持跨境 OLAP 能力以及 Lambda 架构等方向，进行了更多的深刻实践。在后续的文章中，小米大数据将进一步介绍小米公司在这些不一样技术方向上的探索过程，敬请关注！

小米大数据负责人 司马云瑞

“UnionSQL 是小米大数据的核心项目，其目的就是为了“快”—— 上手快、数据更新快、查询速度快、越用越快。Apache Kylin 在该项目中不只扮演着举足轻重的角色，同时也成为了 UnionSQL 架构的核心组成部分。在通过长达一年的实战演练以后，Apache Kylin 的查询效率、稳定性及可扩展性都完美地达到了最初的既定目标，并已开始在公司内部进行大规模推广。Kylin 做为全球华人的首个 Apache 顶级项目，通过多年时间的沉淀与积累，在大数据领域中正发挥着愈来愈重要的做用。小米公司期待和社区共同推动 Apache Kylin 的发展与演进。”

Apache Kylin PMC 史少锋

“小米做为一家领先的智能设备与互联网服务供应商，近些年发展十分迅速，业务遍布海内外，已成为国人为之骄傲的品牌。随着大数据与人工智能技术的成熟与普及，以数据为驱动的发展模式愈来愈获得承认。咱们很高兴看到 Apache Kylin 成为小米大数据平台的核心 OLAP 引擎，为众多数据分析师与业务团队创造价值。小米一直以来都是开源软件的积极参与者和贡献者，为开源社区贡献了不少很是好的组件和功能。在过去的时间里，咱们与小米大数据团队进行了深刻的探讨和交流，将来咱们会继续合做，将小米积累和沉淀的诸多经验和实践回馈给 Apache Kylin 社区。”

【特别感谢小米云技术、小米运维等相关团队的工程师们共同参与了本文内容的撰写】