官网文档第一句话："Druid is an open source data store designed for [OLAP] queries on event data"
两个重要关键字：
- OLAP
- event data
所以，druid并不是:
- OLTP系统，不是为实时读写设计
- 支持event data，换句话，不支持更新删除
理想场景：
- 用户行为事件，风控
- 监控数据，报警
逻辑数据：
- 数据有表组成
- 表由多列组成，列分为三种：
a. timestamp column, 时间错列，唯一
b. dimension columns, 字符串类型的列
c. metric columns， 用于计算的列，一般是数字
组成：
Druid集群包括集中节点
- Historical nodes 负责从离线拉segments数据，接收broker的数据请求
- Broker Nodes 接收用户请求
- Coordinator nodes 管理historical nodes和segments的映射关系，balance等
- indexing service
a. middle manager
b. overlord
有实时更新，还需要tranquility服务，tranquility服务负责从流种获取新数据并通过indexing service写入druid - realtimenodes
其中 realtimenode和indexing service功能相同，两种实时更新的方式。realtimenode部署相对简单，但是限制较多。官方已经推荐使用indexing service的方式做实时数据ingesting
重要特性：
- 数据支持持久化到Deepstorage
- hive2.2.0开始支持DruidStorageHandler
- time series data/columnar storage/analytical query/distributed database
- lambda架构，支持batch/realtime两种data injection
- 依赖RDBMS持久化meta信息，依赖zookeeper做coordinate，依赖HDFS做数据持久化和分布式访问
- 不支持更新和删除，只支持新增，限制应用场景
- batch插入保证exactly once，realtime插入不保证
- 只支持单表，不支持跨表join
- 提前按照query granularity做聚合，提高查询效率，降低存储空间。缺点是无法做更细粒度的查询，比如设置 query granularity为1分钟，则不能做秒级查询。
Druid的一些设计特点：
- meta信息存储在zk和rdbms两个地方，其中zk上为简要信息，详细的元信息，比如segment的大小，dimensions和metrics配置，存储在rdbms中
- 过期数据并不删除，只是从zk上清理，deepstorage和rdbms中保留，可以恢复
- zk主要职责如下：
a. segment management
b. service discovery
c. property store.
与其他系统的兼容：
- HDFS, or Cassandra, or Amazon S3, or Google Cloud Storage, or Azure Blob Storage, etc. as “deep storage”;
- Kafka, or RabbitMQ, Samza, or Flink, or Spark, Storm, etc. (via tranquility) as real-time data ingestion source;
- Druid itself, or Graphite, or Ambari, or StatsD, or Kafka as a sink for telemetry of Druid cluster (metrics).
