前言：谈到当下应用最广的大数据技术，很多人都会说是数据分析；而体现大数据分析能力的则是OLAP。在大数据高速发展时期，多个技术团队基于OLAP的应用需求，开发出多种OLAP技术，如Hive、SparkSql、FlinkSql、Impala、Kylin、ClickHouse、Doris等，或者在实现其他应用需求的时候，发现自带OLAP应用能力，如ES。将OLAP需求拆解，可以分类两类：第一类是在存储系统的基础上，发展灵活的OLAP计算引擎，这类引擎可灵活解析多种存储格式的数据，如MapReduce，SparkSQL、FlinkSQL；第二类是基于固定的存储格式或自建存储系统，自定义查询引擎的，如Hive、impala、Kylin、Druid、ClickHouse、Doris。本文将以第二类OLAP技术为主，第一类为辅助，分析OLAP各阶段发展原因和各技术的特性。
一、OLAP研发目的和功能分析
技术的发展源于当下技术状态和应用需求，OLAP引擎的发展历史也如此。大数据技术的起点源于谷歌的三驾马车，2000年左右，谷歌的市场应用服务产生大量数据，对大量数据的存储、处理、分析、应用成为了当时的需求；2005年前后，谷歌发布了大数据领域三篇划时代论文，构建了三个基础能力：分布式文件存储系统GFS，分布式计算框架MapReduce与早期大数据领域存算一体的BigTable；这三种技术就是如今Hadoop基础。这三种技术架构，基本形成了后续OLAP发展基调：存算分离和存算一体。
1.1 Hive的出现和特性
我们回看一下2008年的技术环境，当时的OLAP大数据技术只有HDFS和MapReduce(Hbase偏向数据应用，不算OLAP)。
当时面临着什么问题呢？
对大数据的分析应用，当时除此这两种技术之外，别无选择，但是这套方案对于多数企业来说太重了，特别是MapReduce的编程太繁琐。在没有大数据技术的时候，类似的场景都是用OLTP数据库做处理，OLTP数据库是存算一体的，只需要简单的写DSL语句，就可以完成传统业务的数据分析，这是一种简单又高效的方式，但当时没有这样大数据场景的数据库。
所以当时发展产生了两个方向：一个是在hadoop生态基础上做优化，优化开发和处理性能；另一个是自建存算一体的数据库，借用已有的分布式的思想重构新的存储、计算系统。不同的技术团队基于应用需求，开始了各自的探索和发展，比如当时的hive和百度的PALO。
基于Hadoop生态做优化： 基于已有产品的优化，是最能快速产生成效的方式。在OLAP领域，Hive快速脱颖而出；开始是雅虎开发工程师在开发MapReduce时，发现编程麻烦，于是开发了pig语法，用于转换MapReduce编程任务，但是pig也不是默认的标准语法，Facebook在2010年发布了HIve，可以把SQL语言转换成MapRedcue的计算程序；然后HIve迅速发展，成为后续10年构建离线数仓的标准组件，极大的降低了大数据处理和分析的门槛。
注：Hive是存算分离的技术标准；这里Hive有两个特性，一个是数据处理（MapReduce+UDP函数定制化处理）；一个是OLAP分析。这里需要单独的说处理能力，处理能力是构建离线数仓的基础能力，而围绕离线数仓，大数据制定了标准的数据开发和数据管理规范，有现成的方法论去管理和实现离线数据数据开发，如基于维度模型的星型模型和雪花模型等。
以下是是自建存算一体数据库的探索与发展：
1.2 Druid和kylin的出现和特性
早期OLAP场景围绕着Hive构建生态和优化性能，但是在大量使用过后，发现基于Hive技术架构，存在无法在优化满足的业务需求：实时性；基于Hive构建一套OLAP分析系统，只能做离线指标分析；对于快速得到分析结果的需求场景，当时市场上没有成熟的技术产品；这时，OLAP数据库技术方向，Druid和kylin两个技术团队分别开始了各自的研究。（附加：对于实时需求，灵活计算方面，Saprk在自己的技术架构上研发了Spark-Streaming模块，Flink专门为了解决实时问题而生）
Druid是美国的一个广告技术公司研发的，它们是一家专门做在线媒体的数据服务公司，对实时性要求非常高，原有的大数据方案无法满足业务需求，所以Druid就应运而生；kylin是一个诞生于中国发展计划的产品，实现的功能和druid类似，快速导入大量数据，基于多个维度，快速预计算得到指标结果，这个阶段的OLAP技术被归类为MOLAP；目标是一样的，但是实现思路却完全不同：Druid通过自定义数据模型，对数据维度快速处理，自定义加工和查询方式，实现实时OLAP应用；Kylin通过cube,一种预计算方式，预先定义多个维度索引，查询只扫描索引而不访问详细数据而提速，实现实时OLAP应用。
这个阶段，大数据开始做应用级的实时分析能力，期间ES原本想做搜索引擎的，但是由于其出色的存储和搜索能力，发现在OLAP场景的应用同样适用，ES就这样做到了能力跨界应用。这个阶段主打一个实时性，实时分析；对比HIve离线分析阶段，会发现MOLAP阶段为了实现实时分析性能，损失了数据处理能力，所以Hive面对于Kylin和 Druid，依然有自己独特的特性优势，数据处理能力。
注：MOLAP和ROLAP的区分大致如下图所示：
1.3 impala、ClickHouse和Doris的出现和特性
由各类大数据产品，高效技术架构的出现，最开始存算一体这条路发展的数据库，发现借鉴这些优秀的技术思想，能突破原先架构上的性能瓶颈，这些技术团队开始发力；这些优秀技术，最核心的就是MPP技术的突破。
由于HIve的基础生态绑定太多，Hadoop团队最开始基于Hive，做了一个只算不存的MPP服务impala,共享Hive的元数据，然后利用MPP的计算能力，补齐了HIve实时分析场景的应用功能；虽然功能是满足了，但是Hadoop生态有个无法绕过去的弊端，组件太多，运维麻烦，且Hive的基础架构实时性能不高。
ClickHouse的开发团队，是一家俄罗斯的搜索引擎公司，对于搜索业务，有实时分析的需求；它们的目标就是打造一个专门的OLAP实时分析数据库，利用MPP技术和列存储思想，自建了存算一体的数据库；当CK出来的时候，当时市场上基本没有同等特性的竞品，它解决了HIve+Impala一起才能做得实时OLAP分析能力，比Druid和Kylin在构建数据模型上更简单。2016年左右开源，在即席查询和实时分析场景做到了当时的极致，且具有很好的稳定性；为了满足实时分析，CK专注于单表性能的提升；OLAP实时数据分析的核心架构可以总结为大宽表，CK将大宽表数据生成在落库之前，用以满足实时分析的应用需求。
实际上CK的实时分析应用能力，可以用ES实现，都是基于大宽表实时分析；且都有实时数据API输出数据；但是他们在性能上有一些不同，ES是基于Java开发的，应用类服务对内存要求较多，CK基于C++开发，在一些系统性能上，比Java好些；但是ES不归为OLAP存算一体的数据库，它的核心是搜索引擎，且是一整套的平台方案，采集fileBeat/LogStash,内部单独的存储系统和搜索引擎，还有前端分析和运维的Kibana。总结下来，CK基本能实现实时OLAP的需求场景，只对关联查询的场景存在性能短板（关联查询是数据处理的基础）。
Doris最开始的开发技术团队，是中国的搜索引擎公司百度，同样的实时分析需求，Doris的愿景更大一点，它想打造一个可以拥有数据处理、联邦查询和实时OLAP分析的数据库，基于MPP技术，存储上采用了Hive类似的分区分桶的文件划分思想，但是又借鉴了列存的数据存储模型，自定义了存储数据模型和计算引擎。采用FE记录（java）、BE存算(C++)，兼容了多种存储、计算场景，这难免会造成FE过度包装分类、加工任务调度逻辑的情况，但是瑕不掩瑜。
基于Doris的伟大愿景，大数据实时分析场景的一些必要特性，可以很好的兼容在一起：数据处理和实时分析；实时分析的场景主要是大宽表，数据处理的能力在实时分析中看似没什么用，但是它能很好的兼容多个基于中间维度表的宽表关联使用场景，尽管关联Shuffle性能上对于大宽表会有损耗，但是这个特性在目前实时OLAP技术能力中，从性能和应用能力上基本独一份。
二、现阶段OLAP应用能力分析
2.1 OLAP组件可用能力分析
OLAP数据库的发展主要围绕三个核心能力展开：数据处理，OLAP分析能力，实时数据API接口。技术的发展可分为离线和实时两个阶段：
离线阶段以Hive为主，后续都是在数据处理TPS性能上的提升，tez计算框架，sparkSQL计算框架，FlinkSQL,都是提升计算引擎的处理能力和性能；然后将分析结果数据，写入第三方中间件，后端自定义API提供数据服务。
实时阶段，通过自定义存储模型和计算引擎，包装存算一体的数据库；各种实时OLAP数据库的基础能力是：实时分析能力和实时数据API。
- 其中ClickHouse目标就是构建实时的OLAP分析数据库，他对于单宽表的实时OLAP计算是最直接的，但其解决的应用场景单一，完全是为了满足实时OLAP的业务需求；
- 其中ES由于其存储引擎、搜索引擎以及内置数据API的能力，在实时OLAP场景同样满足：ES的scheam ON Read特性可以让数据写入index的时候不用构建DDL（十分好用的特性）；
- 其中Doris的发展目标愿景不单单是做一个实时分析引擎，细看它的功能，有数据处理，联邦查询，实时分析等多种能力；数据处理可以做离线场景的数仓构建，联邦查询可以做数据中台的数据查询管理，实时引擎可以做实时分析的支撑，只是包装多种功能，对单应用场景的性能造成了一些影响；从Doris的功能分析，这是一个有大愿景的技术团队，只是功能集成得越多，对自身系统的负担越大，希望Doris能在功能基础上，能兼容好各种应用场景的性能。我喜欢精益数据分析作者的一句话：以最大愿景去做最小可行性产品；相信Doris社区能将他们的最大愿景实现，他们的这套技术，是市场上最接近统一离线/实时OLAP分析，存算一体应用这个愿景的团队。
2.2 OLAP组件能力描述
各类OLAP开源技术，在处理、分析、提供结果数据的周期过程中：
Hive就像一个庄稼汉：可以在没有开垦的土地上，使用很多手动工具，开垦、存储、统计；什么都能做，但是效率不高；
impala就像Hive请来的收购商:不负责粮食存储和加工，但是能用它自己的方式，快速的对粮食情况做分析；
Druid和kylin就像个粮站：不负责粮食加工，但是加工好的粮食进入仓库的时候，会有个记录员，然后想知道粮食情况，直接和记录员沟通就好；
ClickHouse就像一个自动化的粮食存储工厂：只要把粮食放到传输带上，检测机器会自动识别分类，当想知道粮食情况的时候，粮食工厂能快速基于条件得到结果；
ES就像一个粮食实验基地：原本是用来检测各种粮食情况的，结果构建的粮食分类系统，在粮食统计的时候依然好用；
Doris就像一个自动化农场：可以在农场内部使用自动化工具，开垦、存储和自动化统计粮食，而且效率高，但是在一些外部交流场景里，受限于农场自己的承载、处理和对接能力。
三、总结
大数据OLAP分析能力，纯计算的有：MapReduce、SparkSql、FlinkSql，这些都是可以灵活构建在存储系统之上，拥有数据处理和分析能力； 存算嵌合的组件有：Hive、Impala、Druid、kylin、ES、ClickHouse、Doris，这些都具备OLAP分析能力，实时分析还拥有实时数据API支持能力（关注QPS性能）。基于离线OLAP分析，数据处理是构建数仓的核心能力，有HIve和Doris；基于实时OLAP分析需求，可选择ES、ClickHous、Doris，核心是大宽表数据模型、OLAP分析能力和实时数据API。
原文地址：https://blog.csdn.net/weixin_42049123/article/details/135443323
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。