是什么使Apache Druid非常适合实时分析?


是什么使Apache Druid非常适合实时分析?

文章插图
> Photo by Carlos Muza on Unsplash
 
Apache druid是最流行的在线分析处理(OLAP)开源解决方案之一 。Airbnb和Netflix等许多科技公司都使用它来对每分钟包含数百万个事件的数据流进行查询 。它使公司可以近乎实时地做出决策 。
Druid的主要卖点是它可以轻松扩展到百万RPM的写入速度 , 甚至超过亚秒级的延迟 , 并且在整个操作过程中都具有很高的可用性 。但是如今 , 许多数据库都具有高可用性和亚秒级的延迟 , 那么 , 什么使druid与众不同?
键/值存储 和 Druid
是什么使Apache Druid非常适合实时分析?

文章插图
> From druid's official documentation (http://druid.io/technology)
 
关系数据库(例如MySQL)擅长处理通常具有行级查询的事务性工作负载 。对于分析 , 您需要获取某些列的汇总 , 这需要扫描多个分片上的很多行 。RDBMS不能足够高效地执行实时数据探查 。
就NoSQL键值数据库而言 , 由于您需要查询多个节点上的多个分区 , 因此聚合计算肯定会效率低下 。您可以通过以某种粒度(例如1分钟)预先计算数据并将其存储在密钥中来解决此问题 。但是 , 通过遵循这种方法 , 您将失去在多个窗口上进行浏览的能力 。为所有可能的列组合存储聚集体也是不可行的 , 因为这会导致存储需求呈指数增长 。
Druid旨在解决这些问题 , 即能够在提供低延迟和高可用性的同时探索实时数据和历史数据 。
它是如何工作的?Druid由多个节点组成 , 每个节点扮演不同的角色 。这些所有节点相互协调工作(通常使用Apache Zookeeper进行协调)以提供性能 。
是什么使Apache Druid非常适合实时分析?

文章插图
> Druid Architecture from http://druid.io/docs/latest/design/
 
让我们更详细地讨论每个节点 。如果您已经熟悉节点及其交互 , 则可以直接跳到最后一部分 。
实时(中层管理)这些节点负责处理读写的实时数据 。这些文章特别包括四个主要步骤:
  • · 摄取-将数据写入Druid时 , 它首先进入该节点的内存索引缓冲区 。该缓冲区基于堆 , 事件以行方式存储 。
  • · 持久-为了避免堆溢出 , 该索引会定期保留在磁盘上以提高持久性 。内存中的缓冲区将转换为面向列的存储格式 , 并使其不可变 。然后 , 将持久化的索引加载到堆外内存中以进行更快的查询 。
  • · 合并-定期的后台任务将不可变的块合并为所谓的段 。
  • · 移交-段最终上传到分布式数据存储(称为深度存储) , 例如HDFS , 以提高持久性和可用性 。它还会在MySQL中更新细分的元数据 , 以供其他节点查看 。

是什么使Apache Druid非常适合实时分析?

文章插图
 
历史的这些节点从深度存储加载段 , 然后在其之上提供查询 。在Druid上运行的大多数分析查询大部分时间将进入这些节点 。因此 , 这些节点是集群的主要工作者 。
节点从Zookeeper获得在深度存储中发布的任何新段的信息 。然后下载并加载该细分受众群以进行投放 。节点还在本地磁盘中缓存了一些段 , 这使它们可以在发生某些重启时快速为查询提供服务 。节点还提供读取一致性 , 因为它们仅处理不可变的段 。
历史节点也可以分为多个层次 , 每个层次具有不同的可配置性 。例如 可以将具有较高核心数的节点放在一个层中 , 以为经常访问的数据提供服务 , 而为其他数据提供资源较少的节点 。
ZooKeeper的可用性阻碍了这些节点加载新段的能力 , 但是旧段继续提供服务而没有任何停机时间 。
是什么使Apache Druid非常适合实时分析?

文章插图
> Historical Nodes in action (from druid whitepaper)
 
经纪人Broker所有用户查询都转到代理节点 。然后 , 这些节点将请求重定向到适当的历史和实时节点 , 将结果合并并发送回去 。节点还维护内存中的LRU缓存(可以更改为使用Memcached) 。缓存包含每个段的结果 。但是 , 仅历史节点段的结果是缓存 , 因为实时数据会经常保留更改 。


推荐阅读