Segments and 数据存储
如上图所示，加载数据到Druid需要先进行索引。在创建索引的过程中Druid可以对数据进行分析、添加索引结构、压缩和调整布局尝试优化查询速度。对列数据进行一系列快速的操作列表如下：
1.转换为列模式
2.创建位图索引
3.使用各种压缩算法：
所有的列使用LZ4压缩
所有的字符串列采用字典编码/标识以达到最小化存储
对位图索引使用位图压缩
索引过程的输出成为一个"segment"（此处不想翻译成段，破坏了语意），Segments是Druid数据存储的基本存储结构。Segments包含一个数据集内的各种维度和度量值，以列的排列方式存储，以及这些列的索引。
Segments存储在LOB文件存储结构的"deep storage"中。在进行查询时，通过历史节点首先下载数据到历史节点的本地磁盘然后将磁盘数据映射到内存。
如果历史节点挂掉，它将不能对外提供查询它本地加载的Segments的服务，但是这些Segments还是存储在Deep Storage中，其他的历史节点还可以很轻松的把需要的Segments下载下来对外提供服务。这就意味着，即使从集群中移除所有的历史节点，也能够保证存储在Deep Storage中的Segments不会丢失。同时也意味着即使Deep Storage不可用，历史节点仍然可以对外服务，因为节点已经从Deep Storage中将相应的Segments拉取到了本地磁盘。
在集群中保存一个segment，需要将一条segment的元数据添加到元数据实例中，这条元数据是segment的自我描述，包含segment的schema、segment的大小、segment在Deep Storage中的存贮位置。这些元数据信息使Coordinator（协调器）知道集群能够对外提供哪些数据服务。
容错
正如上面所说的历史节点，即使一个历史节点挂掉，其他的历史节点也可以替代它，不必担心数据丢失。
1.Coordinator（协调器）可以配置成快速失败转移的方式运行，如果没有正常运行的协调器，对数据拓扑的改变请求将会停止（不会有新的数据进来，也不会对现有的数据做负载均衡），但是系统仍然能够继续运行。
2.Broker（代理节点）可以并行运行或者配置成快速失败转移的方式。
3.Indexing Service（索引服务）运行过程中对于摄入的任务进行备份，其中的coordination具有快速失败转移的功能。
4.Realtime（实时数据节点）依赖于传递数据流的语义，多个可以并行处理的相同的流，它们定期在磁盘中设置检查点，最终把这些检查点数据推送到Deep Storage。这样做是为了从失败中可以恢复数据。如果仅将数据保存在本地磁盘，可能会出现本地磁盘损坏不可用，就会造成磁盘数据丢失。
5."deep storage"文件系统不可用，新的数据将不能够添加到集群中，但是集群仍然可以对外提供服务。
6.如果元数据存储不可用，Coordinator（协调器）将不能够从系统中发现新的segment，但Coordinator仍然可以通过现在已经存在的segment视图模式操作segment。
7.ZooKeeper如果不可用，不能够对数据拓扑进行更改，但是代理节点仍然可以通过最近的数据拓扑视图对外提供查询服务。
查询处理
查询请求首先进入Broker（代理节点），代理节点将与已知存在的segment进行匹配查询。代理节点将选择一组机器，这组机器可以提供需要的segment的服务，将查询写入到这组机器的每台指定目标segment的服务器。在一次查询中，历史节点的查询和实时节点的查询的处理过程都会进行，然后返回结果。代理节点将历史节点和实时节点返回的结果合并，返回给查询请求方。甚至在看到一条数据之前，代理节点可以对不匹配的查询进行优化。
在代理节点优化数据的基础之上，可以采用更细粒度的索引。在看到结果数据之前，索引结构中的每一segment都允许历史节点来计算哪些行是符合过滤器要求的。过滤器可以对位图索引做所有的布尔判断计算，从来不会直接就看到数据。
一旦代理节点知道与当前查询相匹配的行，它就可以访问它所关心的列而不必再加载数据。将没用的查询数据扔掉。
内存使用
Druid不只是用内存，当我们第一次构建Druid时，Druid确实只是用内存，但是随着时间的推移，对成本和性能的权衡，会停止一直使用内存来操作数据，我们添加了对数据处理是用memory-map的能力，允许操作系统对内存中的数据进行分页处理。我们的生产集群首先要配置每一个提供服务节点的可用内存大小。
