是什么使Apache Druid非常适合实时分析？( 二 ) _Apache

文章插图

这些节点还使用Zookeeper发现其他节点。如果Zookeeper发生故障，它们将以集群状态的最后快照为数据提供服务。
协调员由于"历史"节点很笨，因此协调员有责任告诉他们该怎么做。具体来说，协调器发出以下命令：

· 将实时节点发布的新细分加载到HDFS中。
· 删除过时的数据。
· 复制数据以实现冗余，以便您可以容忍节点故障。
· 跨多个节点负载均衡数据。

只有一个协调器节点被选为领导者，它负责整个操作，而其余节点仅充当备份者。
协调器从Zookeeper获取最新的群集状态，以及有关应从MySQL服务的段的信息。MySQL的中断以及Zookeeper的中断阻碍了分配或删除新段的能力，但是旧段仍然是可查询的。
那么，什么使其比同行更好？责任分工由于每个节点只关注一个主要问题，因此简化了整个系统的复杂性。所有组件之间的交互最少，集群内通信故障（在读取过程中）几乎不影响可用性。群集通过Zookeeper保持同步。即使Zookeeper掉线了，尽管您将无法创建任何新的段，从而影响写入，但读取仍然可能发生。
列式存储由于druid是为分析查询而设计的，因此它以列导向的格式存储数据。面向列的格式可以提供更好的压缩率（因为单个列中的大多数数据都是相似的）和更好的查询性能，因为通常在分析查询中并非所有列都可以访问，因此仅加载实际需要的数据。对于字符串列，德鲁伊通常执行字典编码，然后应用LZF压缩以减小数据大小。
防止不必要的扫描Druid维护着一个字符串值的倒排索引，这样我们就可以知道在哪个行中可以看到一个特定的值。这允许仅扫描其中存在值的那些行。

文章插图

上表的倒排索引看起来像
Foo：[1,0,0,1,0,1]
Bar：[0,1,1,0,1,0]
其中1表示索引中的行中存在特定键。如果要扫描包含Foo和Bar的所有行，只需对两个索引进行OR 。
基数估计为了获得准确的基数汇总，例如确定每分钟访问您的站点的唯一用户数，您需要将用户存储在某种数据结构（例如HashSet）中，然后对其中的元素总数进行计数。但是，这导致大量空间需求。
另一方面， Druid使用HyperLogLog对其进行性能测试，其准确性约为97％。对于大多数运行分析查询的人来说，这通常很好。您甚至可以通过在索引过程中在摄取时预先计算HLL来使其更快。
预聚集德鲁伊可以在摄取时预聚合数据（称为汇总）。这减少了存储数据的大小，也使聚合查询快得多。在这种情况下，您确实会丢失每行信息，这就是为什么可以在摄取期间将其禁用。
快取Druid在代理上维护每个段的查询缓存，这有助于快速返回结果。它还在历史和实时服务器中缓存数据，以加快扫描速度。

文章插图
> Per segment Cache (from druid whitepaper)

负载均衡协调器以这样的方式分配段：在历史节点之间不偏斜段。它考虑了数据大小，源和新近度，因此还提供了最佳性能，例如普通查询涵盖了跨越最近创建的细分的单个数据源，因此明智的做法是以更高的速率复制最近创建的细分，以使这些查询可以由多个节点提供服务。
基于时间的分区Druid需要用于数据分发和保留的必填时间戳列。包含一年中分布的时间戳的数据按天划分更好，而具有一天中分布的时间戳的数据按小时划分更好。此时间戳还用于在写入Druid时忽略旧事件。按时间分区还有助于更好地分配和复制段。
如果您想了解有关Druid的更多信息，请参考以下链接：