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。
