亿级数据下灵活快速查询，充电桩市场霸主如何做？

全国规模最大的新能源汽车充电设施运营商特来电目前项目遍及 282 个城市，面对爆发的业务需求，其基于传统关系型数据库搭建的报表系统性能下降明显。如何高效稳定地基于大数据平台的数据进行多维查询成为大难题，经过多方技术选型与验证，特来电为什么选择了 Kylin？

今天为大家带来“征文赢首届 Kylin Data Summit 门票”活动的第二篇投稿文章，为大家揭秘特来电大数据平台的技术选型之旅。

1. 多维分析平台搭建背景

特来电新能源有限公司（以下简称“特来电”）是青岛特锐德电气股份有限公司的全资子公司，主要从事新能源汽车充电网的建设、运营及互联网的增值服务。特来电采用互联网思维，依靠国际领先的汽车群智能充电技术和系统，创新电动汽车充电商业模式，致力于建设并运营全国最大的汽车充电网。

随着公司业务量的增长，特来电基于传统关系型数据库搭建的各种报表系统，性能下降明显。同时由于大数据平台的的日趋完善，核心业务数据逐步进入大数据平台。数据进入了大数据平台，相伴而来的是各种业务需求，这里主要聚焦在如何高效稳定地基于大数据平台的数据进行多维查询。通过分析，我们面临的主要挑战如下：

1. 亿级别表下任意维度和时间跨度的高效稳定的统计查询。
2. 业务分析的维度越来越多，是否可以提供一个灵活的多维度组合查询的工具，而不是针对不同的维度组合开发不同的报表。

基于以上目标，我们开始搭建大数据的多维分析平台。

2. 多维分析平台技术选型

搭建多维分析平台，首先面临的是技术选型，基于我们对开源框架的使用经验和实际情况，我们主要看业界主流的公司是如何使用应对的，在技术选型上会进行一定的比较，但不会投入比较大的资源进行验证，主张快速的迭代和效果的评估。多维分析平台的技术选型主要是 OLAP 引擎和前端 UI 的选型。

2.1 基本概念、分类

OLAP（Online Analytical Processing）叫联机分析处理，核心是分析，面向应用是分析决策，需要分析的数据级会非常大，可能 TB，甚至 PB 都会有。它的数据更新会稍微慢一些，它的设计一般是反范式的，因为面向分析。常见的是雪花模型和星型模型。

OLAP 的引擎目前主要分为 3 类：ROLAP、MOLAP、HOLAP。

1. ROLAP 即关系型 OLAP，特点是基于关系型数据库，直接基于原始数据做聚合计算。
2. MOLAP 即多维 OLAP，特点是基于一个预定义的模型，提前根据需要查询的维度和指标进行计算，并将存储计算后的结果，后续查询直接基于计算的结果进行查询
3. HOLAP 即混合 OLAP，特点是数据保留在关系型数据库的事实表中，但是聚合后的数据保存在 Cube 中。

HOLAP 聚合后的数据在 Cube 中，选型上同 MOLAP 类似，因此技术选型上主要考虑 ROLAP 和 MOLAP。关于 OLAP 的分类已经经过了很多年的发展，市场上相关的产品也有很多，但是大数据下基于开源组件应该怎么选择？

2.2 核心技术需求

1. 支撑的表的数据量为亿级别的数据表，可以支撑未来 3-5 年的业务需求。
2. 一次查询参与的数据量可以达到亿级别。
3. 数据库需要支持类 SQL，并且相对比较完善。
4. 大部分的查询需要在 20s 之内在页面展现出。
5. 需要支持高并发，系统不会随着数据量的增加，性能急剧下降。
6. 需要一个灵活的前端展示工具，用户可以基于多个业务维度通过自由组合的方式进行查询分析。

2.3 技术验证

2.3.1 ROLAP

按照ROLAP的思路进行了验证，即查询时直接基于原始数据进行查询。

1. SparkSQL、HiveSQL：查询的响应时间在分钟级别，比较稳定。
2. TIDB：在 OLAP 的场景下，针对一次性查询较大数据量时，资源占用比较高，类似于 SQL Server 数据库，需要基于查询条件做针对性的索引。一般我们针对参与数据量较大，并且针对响应时间要求不高，使用 TiSpark 进行离线计算，效果还可以。
3. ES：大部分的查询比较快，但是对于高基数的维度以及分组条件较多时，对于系统资源占用较高，容易影响线上业务。

基于以上，大数据时代有了分布式计算和分布式存储，计算速度和存储量都得到了提升，但是每种大数据工具都有特定的适用场景，目前还没有一个可以全场景覆盖的数据库。以上的测试过程通过水平扩展节点，性能可以进一步得到提升，但是成本比较高。

2.3.2 MOLAP

MOLAP 即根据需要查询的维度提前进行计算好也就是预计算，这个思路实际上很多人在自己业务中经常使用，比如我们会根据电站、结算账户等信息提前归集充电订单相关的信息进行查询。通过研究发现，目前大数据的开源组件基于此思路的数据库 Kylin 应用比较多，并且基于 Kylin 的 KMS 框架（后续章节详细介绍）更是包含了前端展现，这成为技术选型的另一个大的特点，综合分析KMS框架比较贴近我们的技术需求。

1. 亿级别数据量：Kylin 底层 HBase 作为存储，分布式的机制上保证了数据量的增加。
2. 查询性能：Kylin 通过预计算的方式进行查询，速度肯定要优于基于原始数据进行查询，并且针对cube的设计、运行有一套完整的体系和优化方法。
3. SQL：Kylin 的 SQL 支持比较完善，贴近日常的业务开发，应用层使用门槛较低。
4. 可视化的多维查询工具：Saiku 发展时间比较长，基于 MDX 提供了灵活的多维报表的定义、查询、展现工具。这一点非常重要，保证了系统的快速上线，验证。同时提升了数据分析的效率。并且能对接各种不同的数据库，后续可扩展的余地比较大。后续新的数据库只需要开发对应的数据库连接器即可。
   

基于以上，我们决定先期基于 KMS 框架搭建多维分析平台。

3. KMS框架介绍

3.1 框架简介

KMS = Kylin + Mondrian + Saiku 是一个简单的三层架构，Git 上已经有一个整合Kylin、Mondrian以及 Saiku的项目（https://github.com/mustangore/kylin-mondrian-interaction）。

3.1.1 Apache Kylin

Kylin 是 Apache 软件基金会的顶级项目，一个开源的分布式多维分析工具。通过预计算所有合理的维度组合下各个指标的值，并把计算结果存储到 HBase 中的方式，大大提高分布式多维分析的查询效率。Kylin 接收 SQL 查询语句作为输入，以查询结果作为输出。通过预计算的方式，将在 Hive 中可能需要几分钟的查询响应时间下降到毫秒级。

3.1.2 Mondrian

Mondrian 是一个 OLAP 分析的引擎，主要工作是根据事先配置好的 schema，将输入的多维分析语句 MDX（Multidimensional Expressions）翻译成目标数据库/数据引擎的执行语言（比如 SQL）。

3.1.3 Saiku

Saiku 提供了一个多维分析的用户操作界面，可以通过简单拖拉拽的方式迅速生成报表。Saiku 的主要工作是根据事先配置好的 schema，将用户的操作转化成 MDX 语句提供给 Mondrian 引擎执行。

其中 Mondrian 和 Saiku 已经是非常成熟的框架，这里我们简单看下 Kylin 的架构。

3.2 Apache Kylin

Apache Kylin™ 是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的 Hive 表。

Apache kylin 能提供低延迟（sub-second latency）的秘诀就是预计算，即针对一个星型拓扑结构的数据立方体，预计算多个维度组合的度量，然后将结果保存在 HBase 中，对外暴露 JDBC、ODBC、Rest API 的查询接口，即可实现实时查询。主要的使用包含 3 个步骤

1. 通过 Kylin 提供的 UI 界面定义多维分析模型和 Cube。
2. 对定义好的 Cube 进行预计算，并将计算的结果存储到 HBase 中。
3. 查询时通过 Kylin 引擎将查询的 SQL 翻译成 HBase 的 scan 等进行数据的查询。

更多关于 Kylin 的案例、原理、调优，大家可以参考 Kylin 的官方网站（https://kylin.apache.org/cn/）和社区，并可以通过社区邮件进行问题交流。

4. 多维分析平台的架构及应用情况

4.1 业务规划

多维分析报表的创建，除了工具本身之外，对系统数据的处理和设计也是非常之重要，基于目前的使用，主要考虑以下几个问题

1. 多维报表的创建规划过程需要有一套数据分层划分模型，形成方法论、体系，以便指导业务人员进行报表的定义
2. 新的业务需求提出时，需要考虑是基于现有报表增加维度还是增加一个新的报表
3. 多个报表由于业务需求，有重复的维度，重复的维度如何保证数据的一致性

基于以上我们将数据和维度进行了层次划分，业务处理过程采用逐层汇总的方式，进行数据汇总，最后通过 Saiku 进行查询展现。数据分层结构如下：

1. 日志数据：主要包含充电过程中的分钟报文数据、智能运维的分钟报文数据，数据主要存在 HBase、ES、TIDB。
2. 明细数据：主要包含各种不同的业务订单数据。数据主要存储在 SQL Server、ES。
3. 聚合数据：聚合数据为按照不同的业务维度进行聚合的数据。比如：按照电站、结算账户等归集的充电数据。数据主要存储在 ES、Kylin。
4. 公共维度：主要为系统共用的基础数据，比如电站、集控、终端数据。数据公用。

4.2 部署架构

基于 Kylin 的设计架构，我们充分利用现有的 HBase 集群和计算集群，搭建了基于 KMS 的多维分析平台，这里重点介绍一下我们的架构部署情况。先看一下部署架构：

目前进入 Kylin 的数据主要来自于 SQL Server 和 Kafka，通过 Kettle、Flume等工具将数据抽取到离线计算集群 Hive 数据库。

数据抽取到 Hive 数据库之后，通过统一的调度工具调用 Kylin 的 Cube 的 build API，按照业务需求对之前定义好的 Cube 进行预计算，计算好的结果存储到 HBase 集群。

考虑到 Kylin build 时占用资源较多，集群部署时，将 Kylin 的 build 节点和查询节点进行了分离。目前 build 节点为 1 台，查询节点为 2 台。Hbase 集群目前和线上的业务公用。

前端展示 Saiku 是个成熟的多维分析展现工具，对接的数据源类型较多，社区开源版本主要提供了 Kylin、MySQL 的支持。在适应性上可以直接和kylin和tidb进行连接使用。由于 Kylin 查询节点部署了2台，为了充分使用 Saiku 的缓存，在 Saiku 端开发了基于用户的负载均衡。同时考虑到我们目前使用的集群，通过自定义开发实现了与 ES 集群的连通性。

4.3  多维报表开发流程

基于日常的应用，确定了多维分析报表定义的基本流程，多维报表开发流程包含了从业务规划分析、定义、上线、监控的整体流程。如下：

4.4 应用情况

目前通过 Kylin 定义的 Cube 有 20+ 个，最大的 Cube 存储已经超过 2T。基于 Saiku 定义的报表目前主要用于公司的运营、运维、充电安全相关的查询。主要的应用场景分为 2 类：T+1模式的 Cube构建；每小时构建。其中最大的查询维度已经接近 100 个。系统应用截图如下：

通过多维分析，主要带来了以下几个方面的提升：

1. 通过前端多维度的灵活的自主查询，分析问题的维度更广、更完整。业务规律更容易得到展现并被分析。
2. 通过多维度的组合，降低了报表开发的个数，降低了开发工作量。
3. 实现了亿级别表下的数据分析能力，并且随数据量的变化性能下降不明显。
4. 通过业务的分层模型、Kylin 的模型、Cube的定义与管理，实现了从业务规划到分析模型上线的全流程管理。

4.5 解决的问题

4.5.1 Saiku相关的提升

1. Saiku 在服务端针对 MDX 做了比较好的缓存管理，为了进一步提升系统性能，开发了基于用户的负载均衡框，保证一个用户访问同一个服务端。
2. 实现了 Saiku 报表与公司 web 框架的集成、报表用户权限的集成。
3. 实现了通过手机进行报表的拖拽、查询的功能。
4. Saiku 服务端增加了对元数据的缓存，提升了查询速度。
5. 禁用 Saiku 在 Kylin 数据库上大小写的转换。
6. 通过扩展开发，实现了对 ES 数据源的支持。

4.5.2 Kylin 相关的优化与应用提升

1. 基于 Kylin 丰富的 API 实现了定时调度、预警监控（与现有系统进行集成）。
2. 实现了 Kylin 调用与现有计算平台的集成，基于 Kylin 的数据流处理，完全通过计算平台进行流程定义与管理。
3. 针对很少变化的维度数据，为了提升性能，采用宽表方式代替星型模型。
4. 针对变化较频繁的数据模型，为了进一步提升模型的可用性、降低维护工作量，在模型层面通过预留字段的方式，降低后期数据结构发生变化时，对模型、Cube 的修改频率。
5. 基于常用的过滤条件，针对性的调整 Cube 的 Rowkey 顺序，使用频率较高的字段在前。
6. 针对每个报表都包含的条件，放入 Cube 的维度，如常用的时间维度。
7. 为了充分利用 HBase 的分布式能力，可以适当提升每次构建对应的 HBase 的 region 个数(kylin.storage.hbase.min-region-count)。更多的优化可以参考 Kylin 官方的案例。

5. 总结及问题

5.1 目前存在的问题

1. 多维分析集群查询对 HBase 的查询内存消耗较大，查询内存会引起 gc，从而影响 HBase 的其他读写服务。
2. 数据结构发生变化，历史数据需要重新刷，运维成本比较高。
3. 历史数据发生变化，需要经常进行历史数据的刷新。
4. 非聚合组的维度进行查询，部分查询较慢。
5. Saiku 前端的灵活性和数据库能力的矛盾。

5.2 下一步的方向

1. 提升运维效率，在某些表上进行 ES 的应用，提升报表的实时性，建立起不同等级的数据表不同的数据库的区分原则。
2. 针对数据的日常刷新和历史数据清理，开发简单的运维工具。
3. 针对报表的执行，进一步增加监控，根据维度组合情况，进一步优化模型的创建。
4. 基于 Kylin 的新版本特性，提升报表的实时性。
5. Saiku 统计数据 和明细数据的联查、 钻取的深入应用。
6. 前端展示 Superset 研究。