Druid 是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，旨在快速处理大规模的数据，并能够实现快速查询和分析。尤其是当发生代码部署、机器故障以及其他产品系统遇到宕机等情况时，Druid 仍能够保持 100% 正常运行。

Apache Druid社区在今年初发布了Druid 0.17.0。这是该项目自Apache Incubator毕业以来的第一个版本，因此也是一个重要的里程碑。

Twitter在一年多之前就开始采用Druid，并应用到多个场景中。对于Twitter的实践经验，我们采访了Twitter大数据引擎负责人罗震霄。他将在QCon全球软件开发大会（北京站）2020 分享主题为《Twitter ZB 级实时数据分析实践》的演讲。

罗震霄，Twitter Sr. Staff Engineer，负责 Twitter 大数据引擎的开发与运营，主要负责项目 Druid、Presto、Spark、Hive。在加入 Twitter 之前，在 Uber、Netflix、Facebook 从事大数据相关的研发与管理工作。是 Presto Foundation committer 和技术委员会委员。他于复旦大学获得学士学位，并于 University of Wisconsin Madison 获得硕士学位。

InfoQ：您好，请问Druid自开源以来，有哪些重要的演化？

罗震霄：Twitter用Druid已经有一年多了，从0.15到0.17，这几个版本都比较稳定，主要的变化有：

设计并实现了Native Ingestion，彻底摆脱了对MapReduce的依赖，可以直接Ingest Parquet，ORC文件。
Data Ingestion设计了Indexer Process。
SQL功能持续加强。
方便易用的用户界面。
更全面的Security and Privacy Support，例如 LDAP Authentication and Authorization。

InfoQ：一般的企业，哪些场景需要使用Druid？Twitter为什么选择了Druid？Twitter里有哪些Druid的应用举例？

罗震霄：Druid的主要特点是性能快，规模大，易用性好。

性能可以达到1秒以下，真正实现了大数据的实时性计算；
Druid单群可以扩展至2000台节点以上，很好的满足了企业对大数据规模的要求；
Druid的用户界面非常友好，用户常常可以通过拖拖拽拽进行查询，方便非技术类人员的应用。

Twitter业务有很多实时的大数据需求，我们当时对比了市场上现有的开源方案，在稳定性、扩展性、性能和易用性方面Druid都有一定优势，最后选择Druid。目前来看公司上下对Druid还比较满意。

Twitter所有的user events都通过内部Message Queue导入Druid，用户可以实时对Druid进行查询，也可以在Druid基础上设置各类的监控和提醒。实时监控很好的利用了Druid性能快和方便查询的特性。

Twitter内部用Druid很多，有三大类：其一，将用户行为数据导入Druid，进行实时用户行为分析；其二，通过Druid为广告商提供实时的广告效果分析；其三，利用Druid的实时特性，做实时监控和实时报表。

InfoQ：比如现在某个企业已经有了成熟的Lamda架构的离线实时系统。而Druid也是Lamda架构的，那哪些部分是可以相互Share的吗？

罗震霄：Druid需要自己的存储，可以将Message Queue同时导入离线系统和实时系统（Druid）。

如果对一些数据经过滤后有实时的计算需求，也可以通过Hadoop Distributed File System将数据导入Druid。

一般来说，企业的Message Queue可以共享，Hadoop Distributed File System也可以作为Druid的数据源进行共享。

Twitter现在正在开发Presto Druid Connector，通过Presto实时查询Druid数据，这样企业内部的查询语言，查询系统也可以共享。

因为Twitter数据分析大多数是通过SQL进行的。公司上下对SQL on Druid的需求很高。

现有的DruidSQL功能不太完善，SubQuery、Join都不支持。如果将Druid数据再导入其他存储系统，不仅费时费力，而且很难保证数据的一致性。基于这些考虑，我们决定开发Presto Druid Connector，用Presto对Druid数据提供完整的SQL分析，避免了数据重复，节省了存储空间，而且还可以利用Presto Connector的优势，跨平台进行Join操作，比如，Join Hadoop Data with Druid Data。

现在有一些用户在使用Presto Druid Connector，大家还是比较满意的。下一步，我们会进一步提升性能，pushdown各类子运算到Druid。最终的愿景是争取将所有的SQL操作统一到Presto上来。

InfoQ：如果一个系统每天需要处理PB级别的系统，再增加一个Druid这样的存储系统，是不是很大程度上增加了存储空间的压力？原系统和Druid，最好的融合方式是什么样的？

罗震霄：为了性能的提升，Druid需要自己的存储。对Twitter而言，查询速度，和系统的易用性，较之存储空间，更为重要。

Druid需要做自己的存储的原因是：

Druid一个重要的设计目标是实时查询，也就是查询延迟一定要在1秒以下。

现有硬件的基本性能决定，从内存中顺序读取4GB数据的延时在1秒左右，实际应用场景中，我们处理的数据远远大于4GB，所以，没有索引，仅仅靠扫描文件，是不可能达到实时查询要求的。

基于这些考虑，Druid设计并实现了自己的存储格式，主要是列式存储，并应用字典、RLE等方式进行优化。Druid还设计了bitmap索引。在实际应用中，bitmap索引会以mmap方式放在内存中。绝大多数查询可以通过bitmap索引直接找到结果，少数查询会通过列式存储进行有选择性的文件查询。

我们也在开发一些项目，尽量减少不必要的数据重复。比如Presto Druid Connector，通过Presto实时查询Druid数据，这样当用户需要对Druid数据进行SQL分析时，用Presto就可以了，不必要拷贝数据。

InfoQ：Druid和Kylin这样的开源软件主要差别在哪里？

罗震霄：对Kylin实在不太熟悉，不好妄加评论。

我们当时主要考虑的是Druid和Pinot，这两个现在应用比较广泛。相对而言，Druid更稳定一些，社区也更大一些。

InfoQ：目前还有哪些OLAP 平台可供选择？Druid相对有何优势？

罗震霄：现有的OLAP平台比较多，开源方面，有Hive、 Impala、Spark、Presto、Drill、Druid、Pinot等等。

Twitter现在的技术布局：对实时计算，统一于Druid，对秒级到几十分钟级的数据分析，统一于Presto，对小时级别的ETL，统一于Spark。

Druid主要的优势在性能，稳定性，扩展性，和易用性。能够达到1秒以下的实时引擎，只有Druid和Pinot，如果考虑到扩展性和稳定性，Druid的优势比较明显。

InfoQ：在Twitter里，您们定制了关于Druid的哪些开发功能？（与开源版本不同的功能）

罗震霄：主要是四个方面：

对Thrift文件格式的支持，Twitter内部有大量的Thrift文件。
Presto Druid Connector，通过Presto对Druid数据进行SQL分析。
Multi-tenancy Druid，Druid支持不同的用户类型，包括数据安全，隐私保护，和数据隔离。
Native Ingestion，摆脱对MapReduce的依赖，直接导入Parquet文件。

InfoQ：未来，Twitter还计划对Druid开发或加强哪些功能？

罗震霄：主要有以下计划：

Unified Indexing Service，为用户提供方便的一键式导入。
Secure Druid，完整的Druid信息安全，包括LDAP Authentication and Authorization。
Pushdown for Presto Druid Connector，用Presto为Druid提供完整的SQL分析，并充分发挥Druid的性能优势，包括Predicate Pushdown， Aggregation Pushdown，Limit Pushdown。

在QCon北京2020的演讲中，罗震霄老师将会分享Twitter 在ZB 级实时数据分析实践中遇到的经验和教训。还有多位国内外一线互联网企业的技术专家为大家分享新的实时计算和数据分析技术发展趋势，大量真实生产实践案例或许能给你带来新的启发，点击了解详情。

创作场景

Twitter 如何应用 Druid 分析 ZB 级实时数据？