druid.io架构的个人理解学习 part1 part2 翻译

part 1

historical 内存使用

• 从 deep storage 加载segment 到 内存中
• 处理查询，本地结果缓存

Broker 内存使用

• 维持 historical 分布 segment 的全局视图 （ZK 事件订阅）
• 处理查询，本地结果缓存

---

1. 用户查询随机到一台broker
2. broker 能确定要查询的segment 和 historical， 分发子查询到 historical
3. broker 聚合 historical 的 数据，返回给用户

No fault tolerance on the query execution path

broker 必须等所有 historical 返回，有一个 historical 很慢或错误，整个查询就很慢或错误（但是 historical 是有 冗余 备份的，即一个 segment 是存储到好几个historical 的，broker 有全局视图也知晓segment的分布），所以：
为什么一个historical失败时，broker不重试子查询？

zookeeper, broker, historical 的路由问题：

可能发生的现象

1. broker 分发子查询，可能分发到了 一个 已经与 zookeeper 失联的 historical
2. 只要 zookeeper 不给通知 historical 有问题，查询可能一直路由到已经down掉的 historical
3. historical 有问题，一个查询导致卡住，影响到其它所有路由到此historical的所有查询（致命）即： 一个查询就能打垮集群(可用性？)
4. OOM 风险

Huge variance in performance of historical nodes (*)

segments 在 historical 的j均衡，确保一个查询路由到多个 historical 时， 每个 historical 查询尽可能一样的快（通过前面查询分析已经知道：查询是受限制于 最慢 的那个 historical 的）

1. historical 不将 deep storage 存储的 segments 加载到自己的内存和磁盘，而是每次子查询的时候 再从 deep storage 加载 segments, 其最大的缺点： 耗时

即：decoupling of storage and compute （存储 和 计算 去藕）

part2

Issues with ultra-large queries

In ad analytics, time series data sources are generally very “thick”. Reporting queries in our cluster over many months of historical data cover up to millions of segments. The amount of computation required for such queries is enough to saturate the processing capacity of the entire historical layer for up to tens of seconds.(一个大查询可能包含上百万的segment, 占用历史节点多达几十秒，几十分钟)

• 对于实时查询，即使有tier(hot/cold)也没有完全隔离historical
• tier的方式限制的是整个的计算资源，没有再在进程或线程层面做限制

方案1: 类似 Spark 的查询方式 ？
方案2: 隔离做成进程或线程层面的，historical间通信报告查询情况（实现复杂）

Brokers need to keep the view of the whole cluster in memory

维持全局segments分布视图

broker 服务特定datasource,维持需要维持的segments分布视图即可 ?

Design of a Cost Efficient Time Series Store for Big Data

文章链接

Stream processing system

数据分区，将数据按照 interval 进行转换，压缩等，也负责查询

Storage

Computation tree

1. download data of specific partitions and intervals from Storage and compute partial results for them(从存储层加载数据，计算部分结果)
2. merge 第一步处理结果，接收 实时数据
3. 处理第2部的结果，平衡计算资源

原则：

1. Separation of Computation tree and Storage (计算和存储分开)
2. Separation of data ingestion (in Stream processing system) and Storage.（数据消费和存储分开）