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

编程问答

drill apache_Apache Drill 1.4性能增强的简要概述

發布時間：2023/12/3 编程问答 34 豆豆

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

drill apache

今天，我們很高興地宣布，MapR發行版中現已提供Apache Drill 1.4。鉆1.4是MAPR生產就緒和支持的版本，可以從下載這里，找到1.4版本說明這里。

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

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

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

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

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

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

通過從底層存儲系統檢索和處理數據來跨集群中的各個節點執行生成的查詢計劃所花費的時間（又稱為查詢執行時間）。

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

分區修剪

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

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

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

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數據。在這種情況下，dfs.tmp工作區指向文件系統上的/ tmp位置，并且生成的目錄為/ tmp / businessparquet，這是SQL子句中指定的表名。

讓我們獲取CTAS命令生成的文件數。

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

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

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

現在已經對Parquet數據進行了分區，使用分區列（州，城市，星星）上的過濾器進行的查詢可以利用分區修剪優化；僅從磁盤讀取相關數據，其余的分區在計劃時修剪掉。

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

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

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

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

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

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

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

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元數據緩存

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

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

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或“解釋計劃”命令中的查詢配置文件顯示了給定查詢是否利用了元數據緩存。

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”表示此命令利用了元數據緩存。

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

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

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

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

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

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

drill apache

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：教程:芯邦扩容U盘CBM2098恢复容量
下一篇： php cdi_Swing应用程序中的C