在本周的白板演练中，MapR Technologies产品管理高级总监Neeraja Rentachintala概述了开源Apache Drill如何在大型数据集上实现交互式SQL查询的低延迟。 使用Drill，您可以使用熟悉的ANSI SQL BI工具（例如Tableau或MicroStrategy），还可以直接在大数据上进行探索。
对于其他材料：
这是未经编辑的转录：
您好，我叫Neeraja Rentachintala，我是MapR产品管理团队的成员。 今天，我将简短地讨论Apache Drill如何在大规模数据集上实现低延迟性能。
对于不熟悉它的人来说，Apache Drill是一个开源的，交互式SQL-on-Hadoop查询引擎，您可以使用它在大数据之上直接进行数据探索以及BI和即席查询，使用熟悉的ANSI SQL工具，例如Tableau和MicroStrategy。
在接下来的几分钟中，我将讨论使Drill提供这种交互式性能体验的一些核心体系结构元素和功能。
它的核心是Drill，它是一个分布式SQL查询引擎。 Drill中的核心守护程序称为“ Drillbiit”。 该服务将安装在Hadoop集群中的所有数据节点上。 不需要在所有数据节点上安装Drill。 您当然可以做一部分节点，但是在所有节点上安装使Drill能够在查询执行时实现数据局部性。
数据局部性是将处理下推到数据所驻留的节点的能力，而不是试图在查询执行时将数据通过网络传送的能力。
因此，让我们看一下查询执行流程。 它来自客户端的续集-可以是JDBC客户端，ODBC，CLI或REST端点。 查询进入，并且查询被Drillbit接受。 接受请求的Drillbit充当该特定请求的工头或协调者。 作为客户端应用程序，您可以直接提交到钻头，也可以与ZooKeeper仲裁进行对话，这又会将请求吸引到特定的Drillbit。
Drillbit收到请求后，它将传递查询，然后确定执行此特定查询的最佳方法是什么，或执行查询的最佳方法是什么。
因此，除了在查询计划期间了解数据局部性之外，Drill还使我们能够进行各种基于工具和基于成本的优化。
确定最佳查询计划后，Drill会将查询计划分为多个片段，称为片段，即查询计划片段。 因此，Drillbit（协调员Drillbit）与ZooKeeper进行对话，确定集群中还有哪些其他Drillbit。 然后，它获取数据的位置。 通过组合这些信息，它可以确定哪些其他Drillbits可以处理此特定的查询计划片段列表。 然后，它将工作分配给群集中的其他钻头。 每个Drillbit都会对查询计划片段进行自己的处理。 他们将结果返回到原始Drillbit，然后Drillbit将结果返回给客户端。
因此，在执行过程中，每个Drillbit都将与基础存储系统进行交互。 因此，这可能是文件。 （正如我在这里所写的，这是DFS，代表分布式文件系统）。 它可能是HBase，可能是HIive，可能是MongoDB，可能是MapR-DB，可能是Drill配置为可以使用的任何其他存储系统。
这里要意识到的重要一点是，每个钻头都是相同的。 因此，这是一个完全横向扩展的MPP架构。 因此，客户端的请求可以转到任何Drillbit； 这就是Drill缩放的方式。 没有主从架构。 因此，今天，我可以在足以满足需求的一个节点上部署Drill。 我明天可以将其扩展到十个节点。 我可以将其增长到一百个节点，一千个节点。 根据要处理的数据量，取决于要支持的用户数量，取决于要实现的性能，这就是您要达到的目标。 您可以扩展Drill群集，可以缩小Drill群集，而不会遇到网络方面或处理方面的任何瓶颈。 因此，这是一个完全横向扩展的MPP查询引擎。 因此，这是Drill执行过程中的基础元素，可让Drill提供性能。
除了核心的分布式执行外，还有许多其他执行和体系结构元素使Drill可以提供这种性能。 我将简要地详细描述每个特征。
这里的第一个方面是列式执行。 钻在存储和内存中都是柱状的。 那是什么意思呢？ Drill针对Parquet等列格式进行了优化。 因此，如果我使用Drill查询Parquet数据文件，则通过仅读取满足查询所需的特定列，它可以节省磁盘I / O。 不只是那样 数据读入内存后，Drill继续将数据保留为列格式。 因此，Drill的内部数据模型是内存中，列式，分层的数据模型。 因此，好处在于使用列式执行，而Drill无需将数据具体化为新格式。 因此，它可以直接对列数据进行联接，聚合，排序和所有SQL操作，而无需更改结构。 因此，这不仅可以提高性能，还可以节省内存– Drill在查询执行时必须占用的内存空间。 因此，列执行是实现性能的非常基础的元素。
下一个方面与向量化处理密切相关，这与列式执行密切相关。 在传统的MPB数据库系统中，这实际上是数据库系统中相当普遍的技术。 但这对于Hadoop而言是相当新的。 在给定的时间，矢量化处理的思想不是从单个记录中对单个值进行操作，而是让CPU在所谓的“向量”上进行操作。 这些也称为记录批。 向量基本上是表中一组记录的值的区域。 考虑对十亿条记录进行空检查。 向量化处理（其技术前提）是确保您可以真正利用现代CPU设计和深度流水线化的CPU体系结构。 传统上，使用传统的RDMBS类型的系统不会使这些CPU管道保持繁忙，以实现性能和CPU效率。 这是因为核心复杂性，这正是Drill的性能优势真正体现出来的地方。
你们中有些人可能听说过最近宣布的名为Apache Arrow的项目。 正如我提到的，Drill的内存中数据模型是列式分层数据模型。 现在，它实际上是作为一个单独的项目分解出来的，并作为一个名为Apache Arrow的新开源项目对社区做出了贡献。 该项目的目标是真正实现跨各种存储系统和处理框架（例如Kudu，Impala，Spark等）的数据表示的标准化。因此，这是大数据分析的一种标准。
继续，这里的下一个方面是乐观/内存执行。 首先，要实现的一件事是Drill不使用MapReduce，而Drill不使用Spark。 这是一个从头开始构建的引擎，旨在提高复杂数据集和分层数据集的性能。 “乐观”是什么意思？ 这意味着Drill假定在短暂执行查询期间，出现故障（例如硬件故障或节点故障）的机会很少。 它尝试在内存中执行尽可能多的执行，而无需将任何内容写入磁盘以用于检查点和恢复目的。 这个想法是，从技术术语上使用的模型称为“管道执行”。 Drill以流水线方式而不是一次调度一个任务，而是一次调度所有任务。 这些任务正在执行，数据在各个管道之间移动，试图在内存中完成所有工作，并且仅在没有足够内存的情况下才将数据写入磁盘。 这再次是实现秒性能的非常非常核心的方面，而不是传统的基于批处理的范例所看到的分钟性能。
因此，列式执行，向量化处理，乐观的内存中执行–它们都对分布式查询执行功能起到了补充作用。 还有很多。 一个示例是运行时代码编译。 同样，与解释型查询执行相比，运行时代码生成非常高效。 Drill允许您实际上为每个查询和每个操作员生成非常非常高效的自定义代码。 再次这是执行查询的非常有效的方法。 您当然可以在文档中读到更多内容，但是我会说分布式执行以及列执行，向量化处理和内存执行的组合构成了Drill执行的基础。周围的表现。
为了获得性能，Drill围绕优化做了很多事情。 我们将在单独的视频中介绍。 请查看mapr.com。 感谢您的收看！ 
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
