Druid: A Real-time Analytical Data Store

Druid一种实时数仓，针对的场景和目的，如下比较明确

Druid was originally designed to solve problems around ingesting and exploring large quantities of transactional events (log data).

Our goal is to rapidly compute drill-downs and aggregates(roll-ups) over this data.

这篇文章主要内容是描述Druid的架构，对实时数仓的设计是否有借鉴作用

存储上，

Mysql用来存储元数据配置

Zookeeper用于分布式一致性，选主

Deep Stroage，比如S3，用来放历史数据

节点上，

Real-time Nodes

主要是用于消费和查询实时数据的，

数据会先在内存中建立index，避免oom，到达一定行数阈值，会presist到磁盘，presist的时候会由行存变换到列存格式

一个后台程序会不断的把磁盘上的indexes，进行merge，并且上传到deep storage

下面举了个例子，

何时会flush，presist？何时会merge，上传？

这里还考虑了late data，但是一旦窗口结束，该时间段的数据完成merge和上传，实时节点会拒绝too late 数据

Druid实时节点的scalability和availability，都是依赖kafka来保障的，降低druid本身的设计成本

Historical Nodes

这个节点的设计比较简单了，不涉及写入

只是不变数据segments的加载和查询，为了加载效率，需要实现local cache

Brokers

routers，把查询分解，分别去查询real-time和historical节点

还需要在返回前，merge不同节点的数据，这里merge不是怎么简单的，论文并没有写详细的过程，比如top10，怎么merge

为了提升查询性能，

会增加查询cache，这里只会对historical node的查询结果进行cache，不会cache real-time节点的返回，因为变的太快

Coordinator Nodes

中控节点

管下面这些事，

综合一下，本论文，主要描述冷热数据分离，读写分离的一套实时数仓的架构