大数据量业务报表实现的思考
最近闲（假）来（装）无（不）事（忙），不（周）用（末）带（娃）娃（奴），在夜阑人静之时总在考虑如何改进A系统的业务报表输出，最近也翻了好些相关书籍以作对比，故今天特刷篇网文当做读书笔记，同时用来记录对比过往的一些实现方式和对未来实现的一些想法，由于准（连）备（夜）充（赶）分（稿），如有出（纰）彩（漏）之处欢迎拍砖，在此万谢，哈哈！
- 数据的困扰
- Hive的引入
- Elasticsearch的引入
- 意淫的对象Apache Kylin
- Apache Kylin行业使用现状
- 未完待续
数据的困扰
A系统作为公式价格相关数据的载体，投入生产两年以来，积累了非常可观的历史数据，而如何分析和使用此些数据背后隐藏的宝藏便是源源不断的业务需求源泉，这也对A系统的分析报表提出了更高的技术需求。
A系统的数据2年以来累积了将近30亿数据左右，而为了更高效的管理和获取这些数据，从而提供亚毫秒级的极速响应，我们大量了采取了分库分表的策略。这种做法，针对A系统这种电商基础服务系统的而言无疑是合适的。然而却在业务数据分析时显得捉襟见肘了，尤其是那些需要多维度汇总统计的报表，此弱点尤为突出。
Hive的引入
由于A系统的数据存在大量的分库分表，做一些简单的查询时可以通过索引表的对付，但若涉及一些统计操作的需求时就无能为力了。因此得益于公司提供的大数据存储能力，我们将业务表的数据放到了大数据，然后引进Hive，通过Hive sql对其进行查询。
然而，Hive 查询操作过程严格遵守Hadoop MapReduce 的作业执行模型，Hive 将用户的HiveQL 语句通过解释器转换为MapReduce 作业提交到Hadoop 集群上，Hadoop 监控作业执行过程，然后返回作业执行结果给用户。因此，Hive 并不适合那些需要低延迟的应用，Hive 并不能够在大规模数据集上实现低延迟快速的查询，例如，Hive 在几百MB 的数据集上执行查询一般有分钟级的时间延迟！
Elasticsearch的引入
Elasticsearch 是一个实时的分布式搜索分析引擎， 它能让你以一个之前从未有过的速度和规模，去探索你的数据。 它被用作全文检索、结构化搜索、分析以及这三个功能的组合 – 摘自ES官方文档
我们将数据实时的同步到了Elasticsearch，得益于Elasticsearch的强大功能，A系统的报表可以通过灵活的http接口实现对数据的检索。同时，Elasticsearch还提供了强大的聚合统计等功能，开发时非常实用方便。另外一个突出的有点就是，其响应非常迅速，相对于Hive分钟级的响应，Elasticsearch基本都是秒出。
然而，随着报表功能的深入开发，其自身设计和定位上的原因，使得Elasticsearch更适合做搜索相关的事情，而在呈现业务报表分析的某些事情上愈发显得有心无力，在这列举一二：
- 多分片下聚合数据的近似精确和不支持向后分页
这里可以通过网上的一个例子加以说明，参考文章：关于Elasticsearch里面聚合group的坑：
假设我们现在，我们有一份商品的索引数据，它有3个shard，每个shard的数据如下所示：
现在我们的需求是，按商品分组求top5的商品，es收到这个请求后，会去搜索这三个shard，然后子每个shard上面取top5，数据如下图所示：
最后，将三个shard的top5的数据，最后做一下汇聚然后最终排序取top5结果如下图：
最后我们发现这个top5的结果，并不是100%精确的，只是一个近似精确的结果值：
Product A在所有top5的shard数据里面都存在，所以它的结果是精确的， Product C仅仅返回了 shard A 和 C里面的top5的数据，所以这里显示50是不精确的， Product C在shard B里面也存在，但是它在 top5里面没有出现，所以group后的结果实际上是有误差的，再来看下 Product Z仅仅返回了2个shards的数据 因为第三个里面不存在，所以它的结果是准确的，最后我们注意下 Product H实际上它的总数是44，横跨三个shard 但是它在每个shard的top5里面并没有出现，所以最终的top5里面也没有这条数据，这样看来最终的top5的值并不是100% 准确的，这一点在设计和使用es的时候需要特别注意。
关于聚合统计的问题，官方文档其实也说明的相当清楚，这是一个性能和准确性权衡取舍的问题，而这些信息都能在其官方文档中详细了解到，有兴趣可以自行了解：
意淫的对象Apache Kylin
Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。 – 摘自官方文档
- Apache Kylin 功能简介
- 可扩展超快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和SuperSet
Apache Kylin 核心概念
Apache Kylin的核心思想是利用空间换时间，将计算好的多维数据中间结果存起来，从而是想数据的快速查询。同时，由于Apache Kylin在查询方面制定了多种灵活的策略，进一步提高空间的利用率，是的这样平衡错了在应用中值得采用，下面将一一阐述Apache Kylin的一些核心概念：
- 星型模型
Apache Kylin 中采用的模型为星型模型（新版本的也开始支持雪花模型了），将通常我们理解的事实表域多张维表进行关联，以下是我从网上摘录的关于星型的描述图片，具体可以参考链接星型模型与雪花模型
- 数据立方
我们以B+树的结构建立了字段的索引，每个B+树结构的字段索引相当于一个数据平面，这样一个全局数据表与其多个重要字段的索引就组成了一个类似于立方体的数据组织结构，我们称之为“ [1] 数据立方(DataCube)”。 –摘自百度百科
- 星型模型
数据立方是OLAP的一个基本概念，而OLAP的多维分析操作包括：钻取、上卷、切片、切块以及旋转等动作，而这些动作就构成了多维分析的基本能力。在Apache Kylin 中是用Date Cube的概念呈现，它定义了使用的模型、模型中的表的维度（dimension:Wiki:dimension）、度量（measure:Wiki:measure ,一般指聚合函数，如：sum、count、average等）、如何对段分区（ segments partition）、合并段（segments auto-merge）等的规则。
Apache Kylin 体系结构
- 为什么要引入Apache Kylin
其一“准”，相对于Elasticsearch的近似精准，ApacheKylin的新版本已经实现了精确去重计数，这是业务报表分析当中相当重要的一块。另外，多维度的存在，也为数据报表钻取等操作提供了大大的便利，查询效率更高。
其二“快”，Apache Kylin提供hadoop上超大数据规模（ 百亿行级别的数据）的亚秒级SQL查询，相对于hive的离线分析的龟速，Apache Kylin可做到快速查询。
其三“全”，Apache Kylin提供了一整套组件，使用期管理后台可以简单快速的创建并提供查询服务；同时也提供了各种协议的查询接口。
- Apache Kylin 接入步骤
应当说Apache Kylin的接入是相当的方便快捷，具体如下几步：
1 确定hadoop上一个星型模式的数据集。
2 构建数据立方体。
3 可通过ODBC, JDBC,RESTful API等接口在亚秒级的延迟内查询相关数据。
Apache Kylin行业使用现状
Apache Kylin的出现使得对大数据OLAP的能力得以大大的加强，环顾行业现状，已经有了可以借鉴，非常成功的现实案例，我搜集了一些，以供后面学习。。。
Apache Kylin在美团数十亿数据OLAP场景下的实践
来了，Apache Kylin在百度外卖流量分析平台的应用与实践~
参考文档
《架构师特刊：Apache Kylin实践（第二期）》 - infoQ
《基于Apache Kylin构建大数据分析平台》 - 清华大学出版社
《大数据架构和算法实现之路-电商系统的技术实践》 - 机械工业出版社
《分布式实时处理系统-原理、架构与实现》 - 机械工业出版社
Apache内部解剖
本文作者：蔡恒旋