1. 背景

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

Apache Pinot

介绍

Pinot 是一个实时分布式列式OLAP 数据存储和分析系统。由 LinkedIn 开发，为面向站点的用例（如 LindedIn 的 Who viewed my profile、Talent insights 等等）提供实时分析。该项目最初于 2013 年由创建，2015 年开源，于 2018 年 10 月进入 Apache 孵化器，2021年08月02日正式毕业成为 Apache 顶级项目。Pinot 使用 Apache Helix 管理集群资源，并使用 Apache Zookeeper 存储元数据。Piont 在 LinkedIn 得到了广泛的采用，从内部控制面板到面向站点的应用程序。Pinot 从离线数据源（包括 Hadoop 和各类文件）和在线数据源（如 Kafka）中攫取数据进行分析。Pinot 被设计是可以进行水平扩展的。使用它实现低延迟可伸缩的实时分析

特点

优势：

• 面向列的数据库：具有各种压缩方案，如 Run Length，Fixed Bit Length；
• 可插拔索引技术：支持排序索引（Sorted Index），位图索引（Bitmap Index），倒排索引（Inverted Index,），StarTree 索引，Bloom 过滤器，范围索引（Range Index），文本搜索索引（Lucence/FST）， Json 索引，地理空间索引（Geospatial Index ）；
• 具有基于查询和 segment 元数据优化查询/执行计划的能力；
• 支持从 Kafka、Kinesis 等流系统近实时的摄取数据，也支持从 Hadoop、S3、Azure、GCS 等批处理系统摄取数据；也有开箱即用的 Avro 和 JSON 格式
• 类似 sql 的查询语言，支持对数据进行选择、聚合、过滤、分组、排序和 distinct 查询；
• 支持多值字段，支持多值字段，允许你以逗号分隔的值查询字段。
• Kubernetes 上的云原生：Helm chart 提供了一个水平可扩展和容错的集群部署，易于使用 Kubernetes 管理。
• 使用 PrestoDB/Trino 支持本地查找连接和完全连接

劣势：

• Pinot不是数据库的替代品，即它不能用作真值存储源，不能改变数据
• 不是搜索引擎的替代品，即全文搜索，不支持相关性
• 查询不能跨越多个表。

场景

Pinot 是一个实时分布式的 OLAP 数据存储和分析系统。使用它实现低延迟可伸缩的实时分析。Pinot 从脱机数据源（包括 Hadoop 和各类文件）和在线数据源（如 Kafka）中获取数据进行分析，除了实时流摄取外，Pinot 还支持批处理用例，并具有同样的低延迟保证。Pinot 被设计成可进行水平扩展。Pinot 特别适合这样的数据分析场景：查询具有大量维度和指标的时间序列数据、分析模型固定、数据只追加以及低延迟，以及分析结果可查询。

架构

Pinot 旨在提供对大型数据集的低延迟查询。为了实现这一性能，Pinot 以列格式存储数据并添加额外的索引以达到对数据的快速过滤、聚合和分组。原始数据被分解成小的数据分片（shards），每个分片被转换成一个称为段（segment）的单元。一个或多个段一起形成一个表（table），它是使用SQL/PQL查询 Pinot 的逻辑容器。

存储模型

• 表（table）：与传统关系型数据库（RDBMS）类似，Pinot 具有表table的概念，一种引用相关数据集合的逻辑抽象，
• 段（segment） ：Pinot 具有水平扩展的分布式系统架构。Pinot 中的表大小会随着时间的推移而增长。为了解决这个问题，Pinot将数据分解为多个Segment分布在多个节点上。类似于 HA 关系数据库中的分片/分区
• 租户（Tenant）：允许将属于特定逻辑命名空间的所有表分组在单个租户名称下并与其他租户隔离。租户之间的这种隔离为应用程序和团队提供了不同的命名空间，以防止共享表或模式。
• 集群（cluster）：从逻辑上讲，集群只是一组租户，通常，由于 Pinot 支持租户的概念，因此无需创建多个集群。

系统组件

通过与Apache Zookeeper和Apache Helix 的集成，Helix 是一个集群管理解决方案，由 LinkedIn Pinot 的作者设计和创建，通过集成使 Pinot规模可进行线性扩展。Pinot核心组件及组件的主要功能

• controller： 管理集群中的节点， 对Table和Segment的创建、更新和删除操作的处理， 计算Table和Segment在server上的分配
• Broker： 它接收客户端的查询请求，并且将路由到多个服务上（根据路由策略）， 合并接收的查询结果并返回给客户端。
• server：server 它保存一个或者多个物理的Segment
• minion： 可选组件，可用于运行后台任务，例如数据清洗，minion同时优化了Pinot 片段并构建索引，以优化性能

Apache Druid

介绍

Apache Druid 是一款2013年底开源的一个分布式的、支持实时多维 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 清晰的命名每一个服务，以确保运维人员可以根据使用情况和负载情况很好地调整相应服务的参数。例如，当负载需要时，运维人员可以给数据摄入服务更多的资源而减少数据查询服务的资源。

服务与进程

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

外部依赖

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

数据存储

像大多数分析型数据库一样，Druid 采用列式存储，数据存储在datasources 中，类似于传统 RDBMS 中的表。每个数据源都按时间分区，并且可以选择按其他属性在进一步分区，每个时间范围称为一个块，在一个块中，数据被划分为一个或多个段（segment）。每个段都是一个文件，通常包含多达几百万行数据。不像大多数传统系统，Druid 可以在数据提取前对数据进行预聚合。这种预聚合操作被称之为 rollup，这样就可以显著的节省存储成本。

总结

Druid 和 Pinot 不支持点更新和删除，这使Druid 和 Pinot 能够进行更高效的列压缩和更积极的索引，这意味着更高的资源利用率和更快的查询。同时Druid 和 Pinot 都支持从 Kafka 提取流数据。并支持支持Lambda风格的流和批量摄取相同的数据，在 Druid 和 Pinot 中所有数据在时间维度上通常也以指定的间隔进行划分。然后这部分数据被单独“密封”到称为“段”的独立实体中。每个段包括表元数据、压缩的列数据和索引。Druid 和 Pinot 中的数据摄取是“繁重的”，它由几个不同的服务组成，并且它的管理是一个负担。Druid 和 Pinot 具有非常相似的架构，但是Druid 中的“主”节点（Pinot 中也没有）不负责集群中数据段的元数据的持久性，以及段与加载段的查询处理节点之间的映射，此信息保存在 ZooKeeper 中，相比Pinot， Druid的segment分配算法更智能。而Pinot 将大部分段和集群管理逻辑委托给Helix 框架，这两个系统对比商业数据库标准来讲, 都还不算成熟，缺少一些必须要的优化以及功能。