eMondrian

           

                                                                     

 

         

          联机分析处理OLAP(Online Analytical Processing)是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多维信息的快速分析的特征。其中F是快速性(Fast)，指系统能在数秒内对用户的多数分析要求做出反应；A是可分析性(Analysis)，指用户无需编程就可以定义新的专门计算，将其作为分析的一部 分，并以用户所希望的方式给出报告；M是多维性(Multi—dimensional)，指提供对数据分析的多维视图和分析；I是信息性(Information)，指能及时获得信息，并且管理大容量信息。

         OLAP展现在用户面前的是一幅幅多维视图。维（Dimension）：是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维（时间维、地理维等）。

维的层次（Level）：人们观察数据的某个特定角度（即某个维）还可以存在细节程度不同的各个描述方面（时间维：日期、月份、季度、年）。

维的成员（Member）：维的一个取值，是数据项在某维中位置的描述。（“某年某月某日”是在时间维上位置的描述）。

度量（Measure）：多维数组的取值。（2000年1月，上海，笔记本电脑，0000）。

OLAP的基本多维分析操作有钻取（Drill-up和Drill-down）、切片（Slice）和切块（Dice）、以及旋转（Pivot）等。

钻取：是改变维的层次，变换分析的粒度。它包括向下钻取（Drill-down）和向上钻取（Drill-up）/上卷(Roll-up)。Drill-up是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；而Drill-down则相反，它从汇总数据深入到细节数据进行观察或增加新维。

切片和切块：是在一部分维上选定值后，关心度量数据在剩余维上的分布。如果剩余的维只有两个，则是切片；如果有三个或以上，则是切块。

旋转：是变换维的方向，即在表格中重新安排维的放置（例如行列互换）。

       OLAP对应的数据载体叫做数据仓库，因为它不是数据的生产者，其中的数据都是从其他地方搬运过来的，而搬运和清洗的过程就是ETL流程（Extract-Transform-Load，即数据抽取、转换和加载）。

        

1.Hive
Hive 是一个分布式 SQL on Hadoop 方案，底层依赖 MapReduce 计算模型执行分布式计算。Hive 擅长执行长时间运行的离线批处理，数据量越大，优势越明显。Hive 在数据量大、数据驱动需求强烈的互联网大厂比较流行。近 2 年，随着 Clickhouse 的逐渐流行，对于一些总数据量不超过百 PB 级别的互联网数据仓库需求，已经有多家公司改为了 Clickhouse 的方案。Clickhouse 的优势是单个查询执行速度更快，不依赖 Hadoop，架构和运维更简单。

2.Spark SQL、Flink SQL
在大部分场景下，Hive 计算速度过慢，别说不能满足那些要求高 QPS、低查询延迟的的对外在线服务的需求，就连企业内部的产品、运营、数据分析师也会经常抱怨 Hive 执行 ad-hoc 查询太慢。这些痛点，推动了 MPP 内存迭代和 DAG 计算模型的诞生和发展，诸如 Spark SQL、Flink SQL、Presto 这些技术，目前在企业中也非常流行。Spark SQL、Flink SQL 的执行速度更快，编程 API 丰富，同时支持流式计算与批处理，并且有流批统一的趋势，使大数据应用更简单。

3.Clickhouse
ClickHouse 是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。目前国内社区火热，各个大厂纷纷跟进大规模使用。

ClickHouse 从 OLAP 场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据 Sharding、数据 Partitioning、TTL、主备复制等丰富功能。以上功能共同为 ClickHouse 极速的分析性能奠定了基础。

ClickHouse 部署架构简单，易用，不依赖 Hadoop 体系（HDFS+YARN）。它比较擅长的地方是对一个大数据量的单表进行聚合查询。Clickhouse 用 C++ 实现，底层实现具备向量化执行（Vectorized Execution）、减枝等优化能力，具备强劲的查询性能。目前在互联网企业均有广泛使用，比较适合内部 BI 报表型应用，可以提供低延迟（ms 级别）的响应速度，也就是说单个查询非常快。

但是 Clickhouse 也有它的局限性，在 OLAP 技术选型的时候，应该避免把它作为多表关联查询 (JOIN) 的引擎，也应该避免把它用在期望支撑高并发数据查询的场景，OLAP 分析场景中，一般认为 QPS 达到 1000 + 就算高并发，而不是像电商、抢红包等业务场景中，10W 以上才算高并发，毕竟数据分析场景，数据海量，计算复杂，QPS 能够达到 1000 已经非常不容易。例如 Clickhouse，如果如数据量是 TB 级别，聚合计算稍复杂一点，单集群 QPS 一般达到 100 已经很困难了，所以它更适合企业内部 BI 报表应用，而不适合如数十万的广告主报表或者数百万的淘宝店主相关报表应用。Clickhouse 的执行模型决定了它会尽全力来执行一个 Query，而不是同时执行很多 Query。

4.Elasticsearch
提到 Elasticsearch，很多人的印象是这是一个开源的分布式搜索引擎，底层依托 Lucene 倒排索引结构，并且支持文本分词，非常适合作为搜索服务。并且用 Elasticsearch 作为搜索引擎，一个三节点的集群，支撑 1000 + 的查询 QPS 也不是什么难事，这是搜索场景。

但是，我们这里要讲的内容是 Elasticsearch 的另一个功能，即作为聚合（aggregation）场景的 OLAP 引擎，它与搜索型场景区别很大。聚合场景，可以等同于 select c1, c2, sum (c3), count (c4) from table where c1 in (‘china’, ‘usa’) and c2 < 100 这样的 SQL，也就是做多维度分组聚合。虽然 Elasticsearch DSL 是一个复杂的 JSON 而不是 SQL，但是意思相同，可以互相转换。

用 Elasticsearch 作为 OLAP 引擎，有几项优势：（1）擅长高 QPS（QPS > 1K）、低延迟、过滤条件多、查询模式简单（如点查、简单聚合）的查询场景。（2）集群自动化管理能力（shard allocation，recovery）能力非常强。集群、索引管理和查看的 API 非常丰富。

ES 的执行引擎是最简单的 Scatter-Gather 模型，相当于 MapReduce 计算模型的一趟 Map 和 Reduce。Scatter 和 Gather 之间的节点数据交换也是基于内存的不会像 MapReduce 那样每次 Shuffle 要先落盘。ES 底层依赖的 Lucene 文件格式，我们可以把 Lucene 理解为一种行列混存的模式，并且在查询时通过 FST，跳表等加快数据查询。这种 Scatter-Gather 模型的问题是，如果 Gather/Reduce 的数据量比较大，由于 ES 是单节点执行，可能会非常慢。整体来讲，ES 是通过牺牲灵活性，提高了简单 OLAP 查询的 QPS、降低了延迟。

用 Elasticsearch 作为 OLAP 引擎，有几项劣势：多维度分组排序、分页。不支持 Join。在做 aggregation 后，由于返回的数据嵌套层次太多，数据量会过于膨胀。

ElasticSearch 和 Solar 也可以归为宽表模型。但其系统设计架构有较大不同，这两个一般称为搜索引擎，通过倒排索引，应用 Scatter-Gather 计算模型提高查询性能。对于搜索类的查询效果较好，但当数据量较大或进行扫描聚合类查询时，查询性能会有较大影响。

5.Presto
Presto、Impala、GreenPlum 均基于 MPP 架构，相比 Elasticsearch、Druid、Kylin 这样的简单 Scatter-Gather 模型，在支持的 SQL 计算上更加通用，更适合 ad-hoc 查询场景，然而这些通用系统往往比专用系统更难做性能优化，所以不太适合做对查询 QPS (参考值 QPS> 1000)、延迟要求比较高 (参考值 search latency < 500ms) 的在线服务，更适合做公司内部的查询服务和加速 Hive 查询的服务。Presto 还有一个优秀的特性是使用了 ANSI 标准 SQL，并且支持超过 30 + 的数据源 Connector。

6.Impala
Impala 是 Cloudera 在受到 Google 的 Dremel 启发下开发的实时交互 SQL 大数据查询工具，是 CDH 平台首选的 PB 级大数据实时查询分析引擎。它拥有和 Hadoop 一样的可扩展性、它提供了类 SQL（类 Hsql）语法，在多用户场景下也能拥有较高的响应速度和吞吐量。它是由 Java 和 C++ 实现的，Java 提供的查询交互的接口和实现，C++ 实现了查询引擎部分，除此之外，Impala 还能够共享 Hive Metastore，甚至可以直接使用 Hive 的 JDBC jar 和 beeline 等直接对 Impala 进行查询、支持丰富的数据存储格式（Parquet、Avro 等）。此外，Impala 没有再使用缓慢的 Hive+MapReduce 批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分组成），可以直接从 HDFS 或 HBase 中用 SELECT、JOIN 和统计函数查询数据，从而大大降低了延迟。Impala 经常搭配存储引擎 Kudu 一起提供服务，这么做最大的优势是点查比较快，并且支持数据的 Update 和 Delete。

7.Druid
Druid 是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。Druid 支持更大的数据规模，具备一定的预聚合能力，通过倒排索引和位图索引进一步优化查询性能，在广告分析场景、监控报警等时序类应用均有广泛使用；

Druid 的特点包括：

Druid 实时的数据消费，真正做到数据摄入实时、查询结果实时

Druid 支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发

Druid 的核心是时间序列，把数据按照时间序列分批存储，十分适合用于对按时间进行统计分析的场景

Druid 把数据列分为三类：时间戳、维度列、指标列

Druid 不支持多表连接

Druid 中的数据一般是使用其他计算框架 (Spark 等) 预计算好的低层次统计数据

Druid 不适合用于处理透视维度复杂多变的查询场景

Druid 擅长的查询类型比较单一，一些常用的 SQL (groupby 等) 语句在 druid 里运行速度一般

Druid 支持低延时的数据插入、更新，但是比 hbase、传统数据库要慢很多

与其他的时序数据库类似，Druid 在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，灵活性和扩展性不够，比如缺乏 Join、子查询等。

8.Kylin
Kylin 自身就是一个 MOLAP 系统，多维立方体（MOLAP Cube）的设计使得用户能够在 Kylin 里为百亿以上数据集定义数据模型并构建立方体进行数据的预聚合。

9 eMondrian

eMondrian is a free (R)OLAP server. It is a version of the Mondrian.

eMondrian supports XMLA standard. It allows connecting to eMondrian from Excel, Tableau, Power BI and client tools that use ADOMD.NET library.

    eMondrian (sergeisemenkov.github.io)