背景

常见OLAP引擎包括不仅限于Hive、Spark SQL、Presto、Kylin、Impala、Druid、Clickhouse、Greeplum,与OLTP不同，OLAP更强调SQL的执行速度，分区，强调磁盘I/O，OLTP强调事务，强调并发，强调内存效率以及命中率，OLAP目前开源的很多，但是没有一种能完全解决所有场景，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍，在实际使用过程中，由于各OLAP底层实现不同，在SQL上也有差异，所以切换业务系统的OLAP，其成本也将引起很多问题，本文对主流的Apache Druid、ClickHouse 进行对比。

Apache Druid

介绍

Apache Druid 是一个分布式的、支持实时多维 OLAP 分析的数据处理系统。它既支持高速的数据实时摄入处理，也支持实时且灵活的多维数据分析查询。因此 Druid 最常用的场景就是大数据背景下、灵活快速的多维 OLAP 分析。 另外，Druid 还有一个关键的特点,它支持根据时间戳对数据进行预聚合摄入和聚合分析，因此也有用户经常在有时序数据处理分析的场景中用到它。

特点

优势

• 列式存储格式：Druid使用面向列的存储，这意味着它只需要加载特定的查询所需的精确列。这为仅查看几列的查询提供了巨大的速度提升。此外，每列都针对其特定数据类型进行了优化，支持快速扫描和聚合。
• 可扩展的分布式系统 :Druid通常部署在数十到数百台服务器的集群中，可以提供数百万条记录/秒的摄取率，保留数万亿条记录，以及亚秒级到几秒钟的查询延迟。
• 大规模并行处理：Druid可以在整个集群中并行处理查询。
• 实时或批量采集：Druid可以实时流式采集数据（采集的数据可立即用于查询）或批量采集。
• 自愈，自平衡，易于操作:要将群集扩展或缩小，只需添加或删除服务器，群集将在后台自动重新平衡，无需任何停机时间。如果任何Druid服务器发生故障，系统将自动绕过损坏路由，直到可以更换这些服务器：Druid旨在全天候运行，无需任何原因计划停机，包括配置更改和软件更新。
• 云本机，容错架构，不会丢失数据：一旦Druid采集了您的数据，副本就会安全地存储在深层存储（通常是云存储，HDFS或共享文件系统）中。即使每个Druid服务器都出现故障，您的数据也可以从深层存储中恢复。对于仅影响少数Druid服务器的更有限的故障，复制可确保在系统恢复时仍可进行查询。
• 用于快速过滤的索引：Druid使用CONCISE或 Roaring压缩bitmap索引来创建索引，这些索引可以跨多个列进行快速过滤和搜索。
• 基于时间的分区：Druid首先按时间划分数据，并且可以基于其他字段进行额外划分。这意味着基于时间的查询将仅访问与查询的时间范围匹配的分区。这导致基于时间的数据的显着性能改进。
• 近似算法：Druid包括用于近似count-distinct的算法，近似排序以及近似直方图和分位数的计算的算法。这些算法提供有限的内存使用，并且通常比精确计算快得多。对于精度比速度更重要的情况，Druid还提供精确的count-distinct以及精确的排序。
• 在采集时自动汇总：Druid可选择在采集时支持数据汇总。提前预聚合数据，可以节省大量存储成本并提高性能。

劣势

• 不支持精确去重
• 不支持 Join（只能进行 semi-join）
• 不支持根据主键的单条记录更新

场景

Druid适合于以下场景：

• 插入频繁，但很少更新。
• 大多数查询都是聚合和报告性质的查询（“group by”查询）以及搜索和扫描查询。
• 查询延迟要求为100毫秒到几秒。
• 数据中有一个时间组件（Druid包括具体与时间相关的优化和设计选择）。
• 有多个表，但每次查询只能访问一个大的分布式表，或者查询可能会遇到多个较小的“查找”表。
• 有高基数数据列（例如URL，用户ID），需要对它们进行快速计数和排名。
• 您希望从Kafka，HDFS，文件或对象存储（如Amazon S3）中加载数据。

Druid不适用于以下场景：

• 需要使用主键对现有记录进行低延迟更新。Druid支持流式插入，但不支持流式更新（使用后台批处理作业进行更新）。
• 需要构建一个离线报告系统，其中查询延迟不是很重要。
• 你想做big joins(将一个大事实表连接到另一个大事实表),可能完成这些查询需要花费你几个小时。

架构

Druid 是微服务架构，可以理解为一个拆解成多个服务的数据库。Druid 的每一个核心服务(ingestion(摄入服务)，querying(查询服务)，和 coordination(协调服务))都可以单独部署或联合部署在商业硬件上。Druid 清晰的命名每一个服务，以确保运维人员可以根据使用情况和负载情况很好地调整相应服务的参数。例如，当负载需要时，运维人员可以给数据摄入服务更多的资源而减少数据查询服务的资源。Druid 可以独立失败而不影响其他服务的运行。

服务与进程

Master 服务，运行Coordinator和Overlord进程，管理数据可用性和提取

• Coordinator进程：负责集群 Segment 的管理和发布，并确保 Segment 在 Historical 集群中的负载均衡。
• Overlord进程：负责接受任务、协调任务的分配、创建任务锁以及收集、返回任务运行状态给客户端；在Coordinator 节点配置 asOverlord，让 Coordinator 具备 Overlord 功能，这样可以减少一个组件的部署和运维。

Query 服务，对外提供数据查询服务，并同时从实时节点与历史节点查询数据，合并后返回给调用方

• Router 进程：可选节点，在 Broker 集群之上的 API 网关，有了 Router 节点 Broker 不再是单点服务了，提高了并发查询的能力。
• Broker进程：负责从客户端接收查询请求，并将查询请求转发给 Historical 节点和 MiddleManager 节点。Broker 节点需要感知 Segment 信息在集群上的分布。

Data 服务，运行历史和 MiddleManager 进程，执行摄取工作负载并存储所有可查询的数据。

• Middle Manage进程：主要是负责数据索引，生成索引文件，并把索引文件先发布到一个共享的存储系统里，我们选择了大家普遍采用的 HDFS 系统；
• Historical进程：主要负责加载索引文件，同时提供历史数据的查询服务；

外部依赖

• Deep Storage: 用于存储 Segment 文件供 Historical 节点下载。Deep Storage 不属于 Druid 内部组件，用户可根据系统规模来自定义配置。单节点可用本地磁盘，分布式可用 HDFS。
• zookkeper:查询节点通过Zk来感知实时节点和历史节点的存在，提供查询服务。协调节点通过ZK感知历史节点，实现负载均衡。统治节点、协调节点的lead选举
• Metedata Storage:存储关于Druid中的metadata，规则数据，配置数据等，可以使用关系型数据库

数据存储

像大多数分析型数据库一样，Druid 采用列式存储。根据不同列的数据类型（string，number 等），Druid 对其使用不同的压缩和编码方式。Druid 也会针对不同的列类型构建不同类型的索引。类似于检索系统，Druid 为 string 列创建反向索引，以达到更快速的搜索和过滤。类似于时间序列数据库，Druid 基于时间对数据进行智能分区，以达到更快的基于时间的查询。不像大多数传统系统，Druid 可以在数据摄入前对数据进行预聚合。这种预聚合操作被称之为 rollup，这样就可以显著的节省存储成本。

ClickHouse

介绍

ClickHouse是一个面向联机分析处理(OLAP)的开源的面向列式存储的DBMS，简称CK, 与Hadoop, Spark相比，ClickHouse很轻量级,由俄罗斯第一大搜索引擎Yandex于2016年6月发布, 开发语言为C++,在2016年开源后，在计算引擎里算是一个后起之秀，在内存数据库领域号称是最快的。由于它有几倍于GreenPlum等引擎的性能优势，所以不少人都选择将其安装云服务器中使用。ClickHouse是一个列导向数据库，是原生的向量化执行引擎。它在大数据领域没有走Hadoop生态，而是采用Local attached storage作为存储，这样整个IO可能就没有Hadoop那一套的局限。它的系统在生产环境中可以应用到比较大的规模，因为它的线性扩展能力和可靠性保障能够原生支持shard+replication这种解决方案。它还提供了一些SQL直接接口，有比较丰富的原生client。

特点

优势：

• 面向列的DBMS：一个真正的列式存储的数据库管理系统中，除了数据本身之外不应该存在其他额外的数据
• 数据压缩：一些面向列的DBMS（InfiniDB CE和MonetDB）不使用数据压缩。但是，数据压缩确实提高了性能
• 并行处理：多核多节点并行化大型查询，占用当前服务器上可用的所有必要资源
• 分布式查询：在 ClickHouse 中，数据可以驻留在不同的分片上。每个分片可以是一组用于容错的副本。所有分片都用于并行运行查询
• SQL支持：ClickHouse 支持基于 SQL的声明式查询语言，支持的查询包括GROUP BY、ORDER BY、FROM 中的子查询、JOIN子句、IN运算符、窗口函数和标量子查询
• 向量引擎：数据不仅按列存储，而且通过向量（列的部分）进行处理，这样可以实现高 CPU 效率
• 实时更新：ClcikHouse 数据是以增量的方式有序的存储在 MergeTree 中。因此，数据可以持续不断高效的写入到表中，并且写入的过程中不会存在任何加锁的行为。
• 支持索引:ClickHouse支持一二级索引，带有主键可以在特定的时间范围内为特定客户端（Metrica计数器）抽取数据，并且延迟时间小于几十毫秒
• 近似计算：ClickHouse 提供各种各样在允许牺牲精度的情况下对查询进行加速的方法，例如用于近似计算的各类聚合函数、基于数据的部分样本进行近似查询、不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合
• 数据容错：使用异步多主复制。写入任何可用的副本后，数据将分发到所有剩余的副本。系统在不同的副本上保持相同的数据。数据在失败后自动恢复

劣势：

• 由于clickHouse不支持事务操作, 顾不能作为传统数据库来使用(OLTP),以及高请求率的键值访问，Blob或文档存储，超标准化数据；
• 缺乏以高速率和低延迟修改或删除已插入数据的能力；
• 稀疏索引使得 ClickHouse 对于通过键检索单行的点查询效率不高

应用场景

自从ClickHouse2016年6月15日开源后，ClickHouse中文社区随后成立。中文开源组开始以易观，海康威视,美团，新浪，京东,58,腾讯,酷狗音乐和俄罗斯开源社区等人员组成，随着开源社区的不断活跃，陆续有神州数码，青云，PingCAP，中软国际等公司成员加入以及其他公司成员加入。初始在群里讨论技术后续有一些大型公司陆续运用到项目中，介于分享不方便问题解决，建立了相应的论坛。适用场景如下：

• 电信行业用于存储数据和统计数据使用。
• 新浪微博用于用户行为数据记录和分析工作。
• 用于广告网络和RTB,电子商务的用户行为分析。
• 信息安全里面的日志分析。
• 检测和遥感信息的挖掘。
• 商业智能。
• 网络游戏以及物联网的数据处理和价值数据分析。
• 最大的应用来自于Yandex的统计分析服务Yandex.Metrica，类似于谷歌Analytics(GA)，或友盟统计，小米统计，帮助网站或移动应用进行数据分析和精细化运营工具，据称Yandex.Metrica为世界上第二大的网站分析平台。ClickHouse在这个应用中，部署了近四百台机器，每天支持200亿的事件和历史总记录超过13万亿条记录，这些记录都存有原始数据（非聚合数据），随时可以使用SQL查询和分析，生成用户报告。

架构

基本概念

列式存储：开源的列存储数据库管理系统，支持线性扩展，简单方便，高可靠性

向量化：clickhouse实现了向量引擎（vectorized execution engine）,对内存中的列式数据，一个batch调用一次SIMD指令（而非每一行调用一次），不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。

表：clickhouse也一样,具有数据库,数据表的概念,和MySQL一样.

分区：支持PARTITION BY子句，在建表时可以指定按照任意合法表达式进行数据分区操作，比如通过toYYYYMM()将数据按月进行分区、toMonday()将数据按照周几进行分区、对Enum类型的列直接每种取值作为一个分区等，类似于hive中的分区表

分片：clickhouse集群由分片shard组成,每个分片又可以通过副本replication组成

副本：数据存储副本,一般是为了数据安全而设计,在大数据存储框架中比较常见

引擎：顾名思义,就是数据库中使用的引擎,不过clickhouse不一样,可以针对数据库和数据表选择引擎.传统如mysql也是可以针对数据表选择引擎如InnoDB MyISam等

系统架构

HDFS、Spark、HBase和Elasticsearch这类分布式系统，都采用了Master-Slave主从架构，由一个管控节点作为Leader统筹全局。而ClickHouse则采用Multi-Master多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。这种多主的架构有许多优势，例如对等的角色使系统架构变得更加简单，不用再区分主控节点、数据节点和计算节点，集群中的所有节点功能相同。所以它天然规避了单点故障的问题，非常适合用于多数据中心、异地多活的场景。

• Column与Field:Column和Field是ClickHouse数据最基础的映射单元。内存中的一列数据由一个Column对象表示,在大多数场合，ClickHouse都会以整列的方式操作数据，但凡事也有例外。如果需要操作单个具体的数值 ( 也就是单列中的一行数据 )，则需要使用Field对象，Field对象代表一个单值。,与Column对象的泛化设计思路不同，Field对象使用了聚合的设计模式。在Field对象内部聚合了Null、UInt64、String和Array等13种数据类型及相应的处理逻辑。
• DataType:数据的序列化和反序列化工作由DataType负责,DataType虽然负责序列化相关工作，但它并不直接负责数据的读取，而是转由从Column或Field对象获取。
• Block与Block流:ClickHouse内部的数据操作是面向Block对象进行的，并且采用了流的形式。Block对象可以看作数据表的子集。Block对象的本质是由数据对象、数据类型和列名称组成的三元组，即Column、DataType及列名称字符串。仅通过Block对象就能完成一系列的数据操作。
• Table:在数据表的底层设计中并没有所谓的Table对象，它直接使用IStorage接口指代数据表。表引擎是ClickHouse的一个显著特性，不同的表引擎由不同的子类实现。
• Parser与Interpreter:Parser分析器负责创建AST对象；而Interpreter解释器则负责解释AST，并进一步创建查询的执行管道。它们与IStorage一起，串联起了整个数据查询的过程。Parser分析器可以将一条SQL语句以递归下降的方法解析成AST语法树的形式。不同的SQL语句，会经由不同的Parser实现类解析。
• Functions 与Aggregate Functions:ClickHouse主要提供两类函数—普通函数（Functions）和聚合函数（Aggregate Functions）。普通函数由IFunction接口定义，拥有数十种函数实现，采用向量化的方式直接作用于一整列数据
• Cluster与Replication:ClickHouse的集群由分片 ( Shard ) 组成，而每个分片又通过副本 ( Replica ) 组成。这种分层的概念，在一些流行的分布式系统中十分普遍

总结

ClickHouse是纯列式存储OLAP，适合数据规模不大情况下的单机且单表的数据分析,分布式是通过全局配置文件，达到集群相互知晓各自维护各自的数据，让用户自己写入水平扩展性很好查询/写入能力随机器数线性增加。ClickHouse最大的特点就是快，但是ClickHouse缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据；没有完整的事务支持，不支持二级索引。

Druid是预计算引擎与MOLAP （基于多维数据组织的OLAP实现 ），适合那种数据量大，对实时性要求高且响应时间短，以及维度较少且需求固定的简单聚合类查询(sum，count，TopN)，多以storm和flink组合进行预处理；而不适合需要join、update和支持SQL和窗口函数等复杂的adhoc查询。Druid的核心是时间序列，把数据按照时间序列分批存储，十分适合用于对按时间进行统计分析的场景，但是与其他的时序数据库类似，Druid在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，灵活性和扩展性不够，比如缺乏Join、子查询等；Druid保证数据实时写入，但查询上对SQL支持的不够完善(不支持Join)，适合将清洗好的记录实时录入，然后迅速查询包含历史的结果