當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Apache Drill 1.4性能增强的简要概述

發(fā)布時間：2023/12/3 编程问答 35 豆豆

生活随笔收集整理的這篇文章主要介紹了 Apache Drill 1.4性能增强的简要概述小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

今天，我們很高興宣布Apache Drill 1.4現(xiàn)已在MapR發(fā)行版中可用。鉆1.4是MAPR生產(chǎn)就緒和支持的版本，可以從下載這里，找到1.4版本說明這里。

Drill 1.4以其高度靈活和可擴展的體系結構為基礎，帶來了多種新功能以及對查詢性能的增強，使其成為Drill社區(qū)非常重要的里程碑。

這是Drill 1.4中可用的關鍵功能/增強功能的列表。

通過更快的限制0查詢改善Tableau體驗
Hive模式/表上的元數(shù)據(jù)（INFORMATION_SCHEMA）查詢加速
通過增強的分區(qū)修剪來優(yōu)化查詢計劃和執(zhí)行
高效地緩存Parquet元數(shù)據(jù)，加快了對大量文件的查詢
改進的窗口功能，資源使用率和性能
表功能
改進的CSV標頭解析
新的和改進的MapR Drill JDBC驅動程序

在此博客文章中，我想專門簡要概述一下最近的一些性能增強功能，即分區(qū)修剪和Parquet元數(shù)據(jù)緩存，這將使您能夠在Drill部署中實現(xiàn)較低的延遲響應時間。元數(shù)據(jù)緩存是Drill 1.2中新增的一項功能，自Drill 1.0以來就存在分區(qū)修剪功能，但在1.4版本中，這兩項功能效率更高，并且涵蓋了廣泛的用例。

讓我從一些背景開始。 Drill旨在在包含多種數(shù)據(jù)類型和數(shù)據(jù)源的大規(guī)模數(shù)據(jù)集上實現(xiàn)交互性能。任何查詢引擎中的性能均由兩部分組成：

解析查詢和創(chuàng)建最佳查詢計劃所花費的時間（又名查詢計劃時間）。

通過從底層存儲系統(tǒng)中檢索和處理數(shù)據(jù)來跨集群中的各個節(jié)點執(zhí)行生成的查詢計劃所花費的時間（又稱為查詢執(zhí)行時間）。

以下是在每個階段中使Drill獲得交互性能的一些核心Drill體系結構元素和技術的列表。如您所見，分區(qū)修剪和元數(shù)據(jù)緩存都是作為查詢計劃一部分應用的優(yōu)化技術的示例。

分區(qū)修剪

像Hadoop這樣的大數(shù)據(jù)系統(tǒng)中的數(shù)據(jù)集大小可能是巨大的，范圍從TB到PB。在某些情況下，數(shù)據(jù)集可能從很小的開始，但是客戶選擇Hadoop是因為他們希望數(shù)據(jù)量顯著且快速地增長。分區(qū)修剪使查詢引擎能夠確定和檢索所需的最小數(shù)據(jù)集來回答給定查詢。讀取小數(shù)據(jù)意味著IO上的周期更少，而CPU上實際處理數(shù)據(jù)的周期也更少。這是應用于傳統(tǒng)DBMS / MPP系統(tǒng)中以實現(xiàn)性能的標準技術，但是由于大數(shù)據(jù)量，在大數(shù)據(jù)環(huán)境中變得更加重要。為了利用分區(qū)修剪作為查詢的一部分，需要根據(jù)您希望從用戶那里獲得的查詢模式對數(shù)據(jù)進行適當?shù)亟M織和分區(qū)。

組織數(shù)據(jù)可以在攝取時完成，或者隨后通過使用各種Hadoop生態(tài)系統(tǒng)工具（例如Flume，Hive，Pig）或作為處理步驟完成，對于MapR，可以通過NFS直接攝取。 Drill支持使用各種類型的存儲插件進行分區(qū)修剪。在基于文件的目錄結構查詢文件系統(tǒng)時以及在查詢Hive表時使用Hive Metastore表分區(qū)信息時，將應用分區(qū)修剪。 Drill本身提供了創(chuàng)建分區(qū)數(shù)據(jù)的功能，這是CREATE TABLE AS語法的一部分。

這是使用Drill SQL語法對數(shù)據(jù)進行分區(qū)的示例。該語句將示例Yelp業(yè)務JSON數(shù)據(jù)集（可以從Yelp下載）轉換為Parquet格式。作為轉換的一部分，數(shù)據(jù)還會根據(jù)州，城市和星號三列進行分區(qū)。

0: jdbc:drill:zk=local> create table dfs.tmp.businessparquet partition by (state,city,stars) as select state, city, stars, business_id, full_address, hours,name, review_count from `business.json`;

上面語句的輸出是在與指定工作空間相對應的目錄中生成的Parquet數(shù)據(jù)。在這種情況下，dfs.tmp工作區(qū)指向文件系統(tǒng)上的/ tmp位置，并且生成的目錄為/ tmp / businessparquet，這是SQL子句中指定的表名。

讓我們獲取CTAS命令生成的文件數(shù)。

NRentachintala-MAC:businessparquet nrentachintala$ cd /tmp/businessparquet/ NRentachintala-MAC:businessparquet nrentachintala$ ls -l |wc -l652

請注意，Drill CTAS命令生成的文件數(shù)量可以在Drill中使用各種參數(shù)進行調(diào)整。但是，默認值匹配CTAS中指定的分區(qū)鍵列將具有的不同組合的數(shù)量。例如，以下SQL語句為您提供了分區(qū)鍵列的不同組合數(shù)。

0: jdbc:drill:zk=local> select count(*) from (select distinct state, city, stars from dfs.yelp.`business.json`) ; +---------+ | EXPR$0 | +---------+ | 652 | +---------+

現(xiàn)在已經(jīng)對Parquet數(shù)據(jù)進行了分區(qū)，使用分區(qū)列（州，城市，星號）上的過濾器進行的查詢可以利用分區(qū)修剪優(yōu)化。僅從磁盤讀取相關數(shù)據(jù)，其余的分區(qū)在計劃時修剪掉。

您可以通過在查詢上運行EXPLAIN PLAN命令或從Drill Web UI（可以從Drillbit節(jié)點的8047端口啟動）中查看配置文件，來輕松檢查是否對給定查詢應用了分區(qū)修剪。

讓我們進行幾個示例查詢，看看是否使用Web UI進行了分區(qū)修剪。

這是一個在兩個分區(qū)列（州和城市）上都帶有過濾器的查詢。

在Web UI中，此查詢的物理查詢計劃如下所示。注意配置文件中突出顯示的“ numFiles”值。這表示從磁盤上讀取了多少個文件以服務查詢。在這種情況下，將讀取652個文件中的9個文件，因為查詢對作為分區(qū)鍵的州和城市列都應用了過濾器，并修剪了剩余的數(shù)據(jù)分區(qū)。檢查讀取的文件數(shù)是確保是否應用分區(qū)的一種簡單方法。

00-00 Screen : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {129.5 rows, 501.5 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 731 00-01 Project(name=[$0], city=[$1], stars=[$2]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {129.0 rows, 501.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 730 00-02 SelectionVectorRemover : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {129.0 rows, 501.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 729 00-03 Limit(fetch=[5]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {124.0 rows, 496.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 728 00-04 Limit(fetch=[5]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {119.0 rows, 476.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 727 00-05 Project(name=[$2], city=[$1], stars=[$3]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 114.0, cumulative cost = {114.0 rows, 456.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 726 00-06 Project(state=[$1], city=[$2], name=[$0], stars=[$3]) : rowType = RecordType(ANY state, ANY city, ANY name, ANY stars): rowcount = 114.0, cumulative cost = {114.0 rows, 456.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 725 00-07 Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath [path=/tmp/businessparquet/0_0_111.parquet], ReadEntryWithPath [path=/tmp/businessparquet/0_0_114.parquet], ReadEntryWithPath [path=/tmp/businessparquet/0_0_115.parquet], ReadEntryWithPath [path=/tmp/businessparquet/0_0_110.parquet], ReadEntryWithPath [path=/tmp/businessparquet/0_0_109.parquet], ReadEntryWithPath [path=/tmp/businessparquet/0_0_113.parquet], ReadEntryWithPath [path=/tmp/businessparquet/0_0_116.parquet], ReadEntryWithPath [path=/tmp/businessparquet/0_0_117.parquet], ReadEntryWithPath [path=/tmp/businessparquet/0_0_112.parquet]], selectionRoot=file:/tmp/businessparquet, numFiles=9, usedMetadataFile=false, columns=[`state`, `city`, `name`, `stars`]]]) : rowType = RecordType(ANY name, ANY state, ANY city, ANY stars): rowcount = 114.0, cumulative cost = {114.0 rows, 456.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 724

現(xiàn)在，通過添加另一個帶有stars列的過濾器來擴展上述查詢，該過濾器也是一個分區(qū)鍵。

請注意，此查詢的物理計劃如下所示，“ numFiles”僅顯示為1。因此，Drill必須讀取652個文件中的1個才能回答查詢。查詢中基于分區(qū)的過濾器越多，查詢就可以指向數(shù)據(jù)的特定子集。這可能會導致巨大的性能改進。但是請注意，您的查詢可能非常復雜，在這種情況下，從分區(qū)修剪中獲得的性能優(yōu)勢可能無法與查詢的處理成本相提并論。但是，在大多數(shù)簡單和中等查詢中，這將是很大的幫助。同樣，利用分區(qū)修剪的最重要方面是弄清楚常見的查詢模式并相應地對數(shù)據(jù)進行分區(qū)。花一些時間來調(diào)整您的部署。

00-00 Screen : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {40.5 rows, 145.5 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1005 00-01 Project(name=[$0], city=[$1], stars=[$2]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {40.0 rows, 145.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1004 00-02 SelectionVectorRemover : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {40.0 rows, 145.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1003 00-03 Limit(fetch=[5]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {35.0 rows, 140.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1002 00-04 Project(name=[$3], city=[$1], stars=[$2]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 30.0, cumulative cost = {30.0 rows, 120.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1001 00-05 Project(state=[$1], city=[$2], stars=[$3], name=[$0]) : rowType = RecordType(ANY state, ANY city, ANY stars, ANY name): rowcount = 30.0, cumulative cost = {30.0 rows, 120.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1000 00-06 Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath [path=/tmp/businessparquet/0_0_114.parquet]], selectionRoot=file:/tmp/businessparquet, numFiles=1, usedMetadataFile=false, columns=[`state`, `city`, `stars`, `name`]]]) : rowType = RecordType(ANY name, ANY state, ANY city, ANY stars): rowcount = 30.0, cumulative cost = {30.0 rows, 120.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 999

Parquet元數(shù)據(jù)緩存

Hadoop部署的另一個共同特征是文件系統(tǒng)上的文件數(shù)量。我們已經(jīng)看到客戶使用Drill查詢成千上萬的文件，用于報告和ETL用例。 Drill的與眾不同的功能之一是它能夠處理自描述數(shù)據(jù)格式（例如Parquet）并即時發(fā)現(xiàn)模式。 Parquet將有關數(shù)據(jù)的元數(shù)據(jù)存儲為文件頁腳的一部分，并且包含諸如列名，數(shù)據(jù)類型，可空性和其他列特性之類的信息，以及圍繞數(shù)據(jù)布局的參數(shù)（例如行組大小）。 Drill將這些信息作為計劃時間的一部分。盡管Drill具有在查詢時發(fā)現(xiàn)此元數(shù)據(jù)的能力，但是對于存在許多文件的用例來說，這可能是一項昂貴的操作。從Drill 1.2開始，我們引入了在Drill中緩存Parquet元數(shù)據(jù)的功能。緩存元數(shù)據(jù)后，可以根據(jù)需要刷新它，具體取決于數(shù)據(jù)集在環(huán)境中的更改頻率。

以下是使用緩存元數(shù)據(jù)的命令。該命令可用于文件夾或單個文件。

0: jdbc:drill:zk=local> REFRESH TABLE METADATA dfs.tmp.BusinessParquet; +-------+-----------------------------------------------------------+ | ok | summary | +-------+-----------------------------------------------------------+ | true | Successfully updated metadata for table BusinessParquet. | +-------+-----------------------------------------------------------+ 1 row selected (0.455 seconds)

Web UI或“解釋計劃”命令中的查詢配置文件顯示了給定查詢是否利用了元數(shù)據(jù)緩存。

0: jdbc:drill:zk=local> select name, city, stars from dfs.tmp.businessparquet where state='AZ' and city = 'Fountain Hills' and stars= '3.5' limit 5;

請注意，以下配置文件中突出顯示的“ usedMetadataCacheFile = true”表示此命令利用了元數(shù)據(jù)緩存。

00-00 Screen : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {40.5 rows, 145.5 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1279 00-01 Project(name=[$0], city=[$1], stars=[$2]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {40.0 rows, 145.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1278 00-02 SelectionVectorRemover : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {40.0 rows, 145.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1277 00-03 Limit(fetch=[5]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 5.0, cumulative cost = {35.0 rows, 140.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1276 00-04 Project(name=[$3], city=[$1], stars=[$2]) : rowType = RecordType(ANY name, ANY city, ANY stars): rowcount = 30.0, cumulative cost = {30.0 rows, 120.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1275 00-05 Project(state=[$1], city=[$2], stars=[$3], name=[$0]) : rowType = RecordType(ANY state, ANY city, ANY stars, ANY name): rowcount = 30.0, cumulative cost = {30.0 rows, 120.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1274 00-06 Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath [path=/tmp/BusinessParquet/0_0_114.parquet]], selectionRoot=/tmp/BusinessParquet, numFiles=1, usedMetadataFile=true, columns=[`state`, `city`, `stars`, `name`]]]) : rowType = RecordType(ANY name, ANY state, ANY city, ANY stars): rowcount = 30.0, cumulative cost = {30.0 rows, 120.0 cpu, 0.0 io, 0.0 network, 0.0 memory}, id = 1273

分區(qū)修剪和元數(shù)據(jù)緩存的結合可以為各種查詢帶來巨大的性能提升，尤其是在臨時查詢/報告用例的情況下。我們將在隨后的博客文章中提供有關這些優(yōu)化以及其他各種Drill性能功能和最佳實踐的更深入的信息。

有關Drill 1.4功能的更多詳細信息和文檔，請參見MapR文檔和Drill文檔。祝賀Drill社區(qū)有了另一個重要的里程碑。祝您鉆Kong愉快！

這是您可以開始使用Drill的多種方法：

在10分鐘內(nèi)在筆記本電腦上開始使用Drill
將Drill與Hadoop結合使用-MapR沙箱和教程
嘗試使用Amazon Web Services進行鉆取
將Drill下載到您的MapR集群
按需訓練
詳細的分步教程

翻譯自: https://www.javacodegeeks.com/2016/01/brief-overview-performance-enhancements-apache-drill-1-4.html

總結

以上是生活随笔為你收集整理的Apache Drill 1.4性能增强的简要概述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇：安卓小车控制（安卓小车）
下一篇：交叉编译指定运行时库路径_运行时vs编译