ApacheDruid中的数据模型和查询性能(第一部分：查询性能和分层金字塔模型)

靠数据驱动的应用服务和仪表台会对底层的数据存储的性能及规模提出较高的要求。在当今大数据下的时代，每个应用服务或仪表台都可能在一秒内发出几十甚至上百的查询， 一个设计糟糕的查询就可能摧毁整个用户体验。 本教程详尽阐述了Apache Druid中的数据模型和查询性能间的相互作用关系。我们会帮您深入了解查询请求是如何提交给 Druid 引擎以及 Druid 是如何响应的，并提供了集中优化查询性能的方法和技巧。

首先，我们会讨论我们是如何思考查询性能的。我们的目标是讨论Apache Druid中的数据模型，不过同样重要的是我们要理解数据模型最终是为查询性能而服务的，不然我们还不如随心所欲地导入数据还不在乎导入的数据结构和模型，作为最终目的所有数据模型的讨论都是关于 Druid 查询性能的优化讨论。

其次, 我们会讨论数据模型和查询性能之间的联系，以及它们是如何互相影响的。

最后，我们将介绍如何使用四种最常用的数据模型优化技巧来达到所需要的查询性能：

• 归并
• 分区
• 排序
• 索引

已故伟大的卡尔·萨根(Carl Sagan) 告诉我们如果你想从头开始做一个苹果派，你需要先发明能容纳它的宇宙。类似的，如果想要做一个性能优良的数据类应用，你必须首先理解查询引擎和数据层级是如何协同工作的。

用户所生成的查询请求，会被提交至查询服务器的Broker组件（1），就像下图顶部所展示的那样。自此，查询请求会进行扇出（Fan Out）（2），并分发给数据服务器（Data Server）。每个数据服务器负责处理与自身相关的查询部分（3），最终结果通过扇入（Fan In）传回Broker服务器。Broker组件会合并所有结果（5），然后再将它们返回给用户。

仔细审视这个架构图能帮助我们理解数据模型是怎样影响查询性能。查询请求通过 Broker 运用了扇入和扇出的机制来提高查询效率生成结果。我们会从底部开始，先阐述扇出之后在各个数据服务器节点的查询流程。

这张图被称为查询性能分层金字塔模型(Great Layered Pyramid of Query Performance),帮助我们理解一个查询请求是如何将数据从存储层返回到 Druid 引擎。底下两层是数据服务器 (Data Node) 的行为，上面两层是代表了 Broker 在查询服务器(Query Node)内的行为。扇入机制( Fan In) 发生于这两个部分之间，连接了数据服务器和位于查询服务器的 Broker组件。

在第一讲中，您已经大致了解了查询的机制和分层的金字塔模型。

在后面几讲里，我们会深入解析每个层级里具体的查询细节和性能优化注意事项。

下一篇： Apache Druid 中的数据模型和查询性能 (第二部分：数据服务器查询处理流程)

相关链接：

• Imply 官方网站：https://imply.io/
• Apache Druid 官方网站：https://druid.apache.org/
• Apache Druid 社区用户群：https://www.druidforum.org/
• Apache Druid Github：https://github.com/apache/druid
• 快速上手：https://docs.imply.io/latest/quickstart/
• 预约演示：https://go.imply.io/request-a-demo-mandarin

Imply及Imply属Imply Data, Inc.在美国及/或其他国家均为所有商标。Apache Druid、Druid及Druid商标为Apache Software Foundation在美国及/或其他国家的注册商标或商标。文中所展示的所有其他商标皆为其各自所有者所拥有。