Apache Druid是基于事件的亚秒级的万亿行响应的开源数据库

Apache Druid是基于事件的亚秒级的万亿行响应的开源数据库

Netflix 使用开源 Druid 分析数据库来了解和量化用户设备如何处理浏览和播放。

一家名为 Metamarkets 的广告技术公司最初于 2011 年将 Druid 设计为分布式实时数据存储，以提供 SaaS 分析。Metamarkets 为广告商提供交互式分析仪表板工具，以了解程序化广告活动的执行情况。它于 2017 年被 Snap 收购。Druid 于 2015 年转移到 Apache 许可证。

Metamarkets博客描述了其最初的需求：“我们的需求是由我们的在线广告客户推动的，这些客户每月的数据量通常超过数千亿事件，需要对最新数据进行高度交互的查询以及任意过滤的能力跨任何维度——数据集包含 30 个或更多维度。例如，一个典型的查询可能是“看看有多少广告是由来自美国、英国和加拿大的 35 至 44 岁的女性高管在周末阅读体育博客时看到的”。

它需要实时访问包含数十亿时间序列事件的商店。数据仓库被排除在外，因为它们的扫描速度太慢，而且缓存速度被击败，因为 Metamarkets 需要进行任意摄取。

1. 关系数据库也不适合：“RDBMS 数据更新本质上是批处理的，通过插入进行的更新会导致查询行锁定。”
2. NoSQL 方法并不好，因为“预聚合需要数小时的处理时间来处理数百万条记录（在约 10 节点的 Hadoop 集群上）。......随着维度数量的增加，聚合和处理时间呈指数增长，超过 24 小时。” 

这意味着没有实时查询。

因此 Metamarkets 决定建立自己的数据存储，并通过其中的并行处理使其具有极大的可扩展性。它具有分布式架构、实时数据摄取、查询实时和历史数据的能力，以及具有数据压缩的列方向以提高扫描速度。使用带有所谓的简洁压缩的位图索引也有助于提高速度。

Druid 可以扩展以每秒执行 260 亿行或更多行的扫描，并且每个节点每秒可以摄取多达 10,000 条记录。Druid 集群中的服务器可以纵向扩展或横向扩展，这提供了比纵向扩展更多的扩展能力。

Druid架构

Druid部署使用商业上可用的服务器，这些服务器被称为节点。有三种基本类型：主节点、数据节点和查询节点。旧数据存储在所谓的深度存储中，这是Druid之外的可插拔存储，如Ceph、NFS、Hadoop（HDFS）或S3。节点运行进程，这些进程可以在专用服务器中运行，被称为节点--或服务器。

• 主节点--主节点、协调员、Zookeeper、元数据存储进程。
• 数据节点--中间管理者/索引者、历史进程。
• 查询节点--经纪人进程和网络控制台。

数据摄取

让我们试着弄清楚发生了什么，并从发生在数据节点或服务器层的数据摄取开始。

可以摄取来自 Kafka、Kinesis、Tranquility 或其他来源的流数据，也可以摄取来自 Hadoop、S3、RDBMS 以及其他来源的批处理数据。中间管理器节点（有时称为 Ingestor 或 Real-Time 节点）处理此问题，并按时间（可配置的持续时间）将数据分段或分区为不可变的压缩列文件，该文件被写入深度存储。 

有三种可能的列类型：时间戳、维度（字段名称）或度量（从其他字段派生的数字数据）。

中层管理者还在创建细分之前对数据进行索引和预聚合。指定时间间隔内的所有传入数据按顺序写入同一段。Druid 使用平面数据模型，而不是嵌套数据模型。

一旦数据进入深度存储，历史节点（Historicals）负责获取数据以响应查询。

主节点

主节点形成一个 Druid 集群控制平面。Overlords 对 Middle Manager 进行数据负载均衡。协调器在历史进程或节点之间进行数据负载平衡，在需要从深度存储加载数据段时通知它们，在不再需要时驱逐段并复制段。

元数据存储包含由中间管理器在 MySQL 或 PostgreSQL 等关系数据库中创建的所有元数据。Zookeeper 进程是一个 Apache 项目，用于当前集群状态管理、内部服务发现、协调和集群领导者选举。

我们需要了解，当中间管理器创建新数据段时，元数据存储会通知协调器。然后将其提供给 Historical，以便可以将其写入底层文件系统。那时，它被从中间管理器中逐出。中层管理器将其预先聚合的段数据保存在内存中，而历史记录将新段写入深度存储。在那里，段是只读的。

如果中间管理器节点出现故障，Zookeeper 将获得由剩余的中间管理器节点重构的数据集。

查询节点和查询流程

有一种单一类型的查询节点，称为 Broker，Web 控制台也位于 Druid 的这一层。代理可以横向扩展以增加实时查询处理能力。

Brokers 以 JSON 查询语言或通过 Druid SQL 从客户端应用程序接收传入查询，并将它们分配给相关的中间管理器和历史记录——它们包含（可以服务）这些数据段。Broker 将传入的查询拆分为子查询，并将它们发送给已识别的中间管理器和历史记录以执行。

历史记录从深度存储中获取请求的数据，而中间管理器获取任何实时数据段。

当返回结果时，它们被合并并输出到客户端。

这样做的最终结果是 Druid 可以查询巨大的数据集，其中可以包括实时数据和历史数据。它最初是一个 adtech 实时查询/分析数据库工具，但在需要类似能力查询大量数据集的应用程序中得到使用，这些数据集不断从事件日志中实时摄取流数据。例如，点击流分析、APM（应用程序性能管理）、供应链、网络遥测、数字营销和风险/欺诈分析。

正如 Metamarkets 所说，“以前需要几分钟或几小时才能运行的超过数十亿行的查询现在可以直接以亚秒级的响应时间进行调查。” Druid 可以处理数 PB 数据存储中的数万亿行数据。

我觉得 Druid 和 Druid 类型的应用程序将得到更广泛的应用，因为分析数字事件数据流以优化流程，并随着时间的推移微调涉及数十亿甚至数万亿事件的企业流程。

Druid 可以在GitHub 上下载，更多信息可以在Druid 项目网站上找到。