① Presto Web UI
Presto Web UI 可以用來檢查和監控Presto集群，以及運行的查詢。他所提豎咐供的關於查詢的詳細信息可以更好的理解以及調整整個集群和單個查詢。
需要注意的是，Presto Web UI所展示的信息都來自於Presto系統表，關於Presto系統表之後文章中再補充，這里不再多說；
當你進入Presto Web時，你將會看到如同1所示的界面：主要分為上下兩部分，上面描述了集群信息，下面是查詢列表；
Running Queries
當前在集群中正在執行的查詢的個數。包含所有用戶提交的查詢；例如，如果Alice正在執行兩個查詢，Bob正在執行五個查詢，那麼在這個指標下顯示的是7。
Queued Queries
當前集群隊列中正在等待的查詢的個數，也是包粗纖念含所有用戶的查詢。隊列中的查詢表示這些查詢正在等待Coordinator根據Resource Group的配置為他們安排調度；
Blocked Queries
集群中被阻塞的查詢的個數；被阻塞的查詢意味著該查詢因為缺少可用的Splits或者資源而無法繼續執行（關於Splits的概念 以及查詢何時被阻塞可以參考上一篇文章：Presto On Everything）；
Active Workers
集群中當前活躍的節點的個數；任何手動會自動添加或刪除的節點都會注冊到Discovery 服務，同時這里展示的數字將會更新、
Runnable Drivers
集群中可運行的Drivers的平均數量（當Task被創建之後，他為每一個Split實例化一個Driver，每一個Driver就是一個Pipeline 中Operators的實例，並對來自Split的數據進行處理，一旦Driver完成，數據將會被傳給下一個Split），
Reserved Memory
集群中Reserved Memory的大小，單位是bytes。(關於Reserved Memory的概念請參考上一篇文章：Presto On Everything)
Rows/Sec
集群中所有查詢在每一秒鍾處理的行數
Bytes/Sec
集群中所有查詢在一秒鍾處理的總共的Bytes
Worker Parallelism
Worker的並發總數，在集群中運行的所有Worker和所有查詢的CPU Time總和
WBE UI首頁下部分就是查詢列表的展示，當前列表中可以展示的查詢的數量時可以配置的。如圖二所示
如圖所示你可以根據一些條件過濾和定位你想要的查詢；同時提供了搜索輸入框用於定位查詢，輸入的值會匹配很多項，包括：用戶名、查詢發起人，查詢source，查詢ID，resource group甚至sql文本，和查詢狀態。同樣你可以根據後面預設的一些狀態（running, queued, finished, and failed）對查詢進行篩選；
最左邊的控制項允許你確定顯示的查詢的排序順序、重新排序的時間以及要顯示的查詢的最大數量。
下面的每一行表示一個查詢，左側如圖三所示岩困，右側為查詢的SQL文本；
根據圖三可以觀察當前查詢的細節； 對於每個查詢運行，左上角的文本是查詢ID，圖三中為： 20190803_224130_00010_iukvw
前面是YYYYMMDD_HHMMSS格式的日期，具體的時間是當前查詢運行時的時間，後半部分是一個自增的計數器，00010的含義表示這個查詢時Coordinator重啟以來第10個查詢，最後的字元：iukvw，是隨機生成的Coordinator的標識符，每次coordinator重啟會充值標識符和計數器。
後面緊跟的三個值： ec2-user , presto-cli , 以及global 分別表示，提交該查詢的用戶，查詢的來源，當前查詢的Resource Group。在實例中，當前查詢的用戶是ec2-user，查詢時通過Presto-cli提交的，如果你在Presto CLI中提交SQL 時使用--user指定用戶，那麼界面該查詢展示的就是你所指定的用戶。至於查詢來源除了Presto-CLI之外也可以是：Presto-jdbc ，當你使用JDBC連接Presto時。
圖三最下面的9個指標對應下面的表格；
Completed Splits : 查詢的已完成Splits的數目。這個例子顯示了25個已完成的Splits。在查詢執行的開始時和執行完成時這個值是0。當查詢正在進行期間這個值會一直增加
Running Splits : 查詢中正在運行的運行Splits的數量。當查詢完成時，這個值總是0。但是，在執行過程中，隨著Splits的運行和完成，這個數字會發生變化
Queued Splits ： 當前查詢里出於隊列中的Splits數。當查詢完成時，這個值總是0。但是，在執行期間，這個數字會發生變化。
Wall Time ： 執行查詢所花費的Wall Time。即使在分頁結果時，此值也會繼續增長。
Total Wall Time : 此值與Wall Time相同，但它也包括排隊時間。Wall Time不包括查詢排隊的任何時間。這是您觀察的總時間，從您提交查詢到您接收結果。
CPU Time ： 處理查詢所花費的總CPU時間。這個值通常比wallTine時間大，因為如果使用四個CPU花費1秒來處理一個查詢，那麼總的CPU時間是4秒。
Current Total Reserved
Memory ：當前用於查詢執行總的reserved memory使用。對於已完成的查詢，此值為0.
Peak Total Memory ： 查詢執行期間的峰值總內存使用量。查詢執行期間的某些操作可能需要大量內存，了解峰值是多大是很有用的
Cumulative User Memory ： 在整個查詢處理過程中使用的累積內存。這並不意味著所有的內存都是同時使用的。它是累積的內存總量。
Presto Web UI中的許多圖標和值都有彈出的工具提示，當您將滑鼠懸停在圖像上時，這些工具提示是可見的。如果您不確定某個特定值代表什麼，這將非常有用。
當正在運行的查詢在等待某些東西(如資源或要處理的其他Splits)時可能會發生BLOCKED狀態。看到查詢往返於此狀態是正常的，但是如果查詢陷入BLOCKED狀態，可能存在許多潛在的理由，這可能表明當前查詢或者集群可能存在問題，如果發現有查詢卡在這個狀態，那麼應該檢查集群的狀態和相關配置，也可能是這個查詢需要非常大的內存或者計算開銷很大。 此外，如果客戶端沒有獲取到返回的結果，或者不能足夠快地讀取結果，反壓機制也會使查詢處於BLOCKED狀態
如果查詢長時間出於PLANNING狀態，這通常發生在較大的復雜的查詢中，因為查詢要進行大量的規劃和優化處理；但是如果你經常看到這個狀態，並且查詢出於該狀態很長時間，那很可能是因為coordinator內存問題導致的（之前曾遇到過因HiveMetaStore服務而導致的長時間的PLANNING狀態）。
通過點擊查詢ID可以跳轉到該查詢的明細界面，如圖四所示
Overview頁麵包括查詢列表的查詢細節信息如圖4.1下：
最下面為Stage部分如圖5所示
這是一個簡單的SELECTCOUNT(*)的查詢，所以只有兩個stages
Stage0 是一個單任務的Stage，運行在coordinator上並且合並來自Stage1的Task（共4個）的數據，以完成最後的聚合；
Stage1是一個分布式的Stage，他在所有的Worker上執行Task，這個Stage負責讀取數據並進行部分聚合；
其中每個Stage的指標如下：
TIME—SCHEDULED
在完成Stage的所有Task之前，該Stage被調度的時間。
TIME—BLOCKED
因等待數據被阻塞的時間
TIME—CPU
Stage中所有Task的總共的CPU時間
MEMORY–CUMULATIVE
在整個Stage 運行期間的累積內存。這並不意味著所有的內存都是同時使用的
MEMORY—CURRENT
當前stage總共的reserved內存，當查詢結束時，改值為0
MEMORY—BUFFERS
當前正在等待被處理的數據所消耗的內存
MEMORY—PEAK
該Stage的峰值總內存。查詢執行期間的某些操作可能需要大量內存，了解峰值是多少是很有用的。
TASKS—PENDING
Stage中待完成的Task的數量，執行完成時，為0
TASKS—BLOCKED
stage阻塞Task的數量。當查詢完成時，這個值總是0。但是，在執行過程中，隨著Task在阻塞狀態和運行狀態之間移動，這個數字會發生變化
TASKS—TOTAL
已經完成的Task的數量
最後的圖6描述了Stage更多的細節：
如圖6中指標具體含義如下表所示：
ID：Task的標識符，StageID.TaskID,中間用點分割，如0.0即Stage0的第0個任務
Host：Task運行所在的Worker節點
State ：Task的狀態：PENDING , RUNNING , or BLOCKED
Pending Splits：Task的掛起的Splits的數量。此值在Task運行時更改，並在Task完成時顯示0
Running Splits：Task 中正在運行的Splits的數量，在Task運行時改變，Task完成後顯示0
Blocked Splits：Task 中出於阻塞狀態的任務數，Task完成後為0
CompletedSplits：Task完成的Splits的數量
Rows：Task處理的行數
Rows/s：每秒處理的行數
Bytes：Task處理的位元組數
Bytes/s：Task每秒處理的位元組數 |
Elapsed：Task調度期間 wall time的總和
CPU Time：Task調度期間CPU時間總和
Buffered：當前等待被處理的緩存數據大小
Live Plan頁面中你可以實時查詢執行處理過程；如圖7所示
在查詢執行期間，計劃中的計數器在查詢執行過程中更新。Plan中的值與Overview選項卡中描述的相同，但是它們在查詢執行計劃上實時覆蓋。 查看此視圖有助於可視化查詢被阻塞或花費大量時間的位置，以便診斷或改進性能問題
Stage Performance提供了查詢處理完成後Stage 性能的詳細可視化。如圖8所示
該視圖可以看作是Live Plan視圖的下鑽，在Live Plan視圖中可以看到Stage中Task的operator pipeline。計劃中的值與Overview選項卡中描述的值相同。 查看此視圖有助於了解查詢在何處卡住或花費大量時間，以便診斷或修復性能問題。您可以單擊每個operator來訪問詳細信息
② presto中如何提取文本中的純漢字
沒辦法提取純文字。
Presto是一款功能強大的分布式sql查詢引擎。
Presto是專門為程序員查詢大數據研究開發的，能夠支余謹洞持gb到pb位元組大小的海量數據，提高了資料庫晌蘆搜索的回應速度，豎枯只需要幾秒就可以得到搜索結果，大大節省了搜索時間，提高效率。
③ 在presto SQL中兩個with as 函數怎麼union在一起
向表中插入搏衡兄行。
INSERT INTO table_name query1
目前尚不支基襲持指定列名。
因此， 查詢語句中的列與要插入的表中的列必須完全攔弊匹配。
例如：
INSERT INTO orders SELECT * FROM new_orders;INSERT INTO cities VALUES (1, 'San Francisco');NSERT INTO cities VALUES (2, 'San Jose'), (3, 'Oakland');
④ Linux裡面presto作用是什麼
Presto是一個開源的分布式SQL查詢引擎，適用於互動式分析查詢，數據量支持GB到PB位元組。
Presto的設計和編寫完全是為了解決像Facebook這樣規模的商業數據倉庫的互動式分析和處理速迅肆度的問題。
Presto支持在線數據查詢，包括Hive, Cassandra, 關系資料庫以及專有數據存儲。一條Presto查詢可以將多個數據源的嘩孫數據進行合並，可以跨越整個組織進行分析。
Presto以分析師的需求作為目標，他們期望響應時間小於1秒到幾分鍾。 Presto終結了數據分析的兩難選擇，亂昌鏈要麼使用速度快的昂貴的商業方案，要麼使用消耗大量硬體的慢速的「免費」方案。
目前用的不是很多。
⑤ presto查詢數據怎麼實現分頁
在Spark,Storm橫行的時代，spark由於耗用內存高而很難滿足這種改良的需求，Storm由於和hive不是一個套路，本身實時流處理的思路也和我們的需求差距較大，所以，
尋求一個能提供類似SQL查詢介面，並且速度比較接近於實時，能利用現有集群硬體的實時SQL查詢引擎成為一個現有hive的替代查詢引擎。
⑥ Hive表數據質量校驗的設計與開發
一張Hive計算完成後，開發者會希望知道計算結果是否符合預期，比如是否有臟數據，是否數據量符合預期。這里就有兩個問題，一個是校驗什麼，另一個是怎麼校驗。
Hive表的校驗自然是跑SQL最方便，每當Hive表更新完要執行SQL校驗，需要考慮兩個問題
基於上述考慮，就要選擇既省資源，又快的計算引擎，MapRece可直接排除，備選方案是Spark SQL和Presto。
回過頭看校驗要執行的SQL，大部分是簡單SQL，例如count(), min/max等，Presto在這種簡單查詢展示出了非常優異的性能，無論消耗資源，還是執行時間都很好。實際測試中，一張2億行的表查詢最新的總行數，執行select count() from table_name，只消耗了2.4 CPU-Second，執行時長也是2秒左右，消耗的資源和運行時長都可忽略不計。Presto跑的快的原因有很多，不用去yarn上申請資源，對orc文件查詢做了很多優化，簡單查詢會直接基於orc的meta做計算，具體原因就不在贅述。
相同的SQL，Spark SQL一般的執行時間都要多很多，消耗的資源也會更多。不過兩著對資源的計算方法肯定是不一樣的，所以不能完全保證Presto更省資源，此處沒有嚴格考證。
還有一些復雜的SQL，比如大表畝鬧的欄位唯一性校驗，Presto很容易出現內存不足的異常，這時候可以考慮切換到Spark SQL來執行，至少保證能運行成功。
我們記錄了每個枚舉值，在表中出現的次數，每天記錄一個值，久而久之可以形成變化趨勢，可以發現某些業務細節的波動，發現異常的用戶行為。
還嘗試了對關鍵業務指標做了統計值校驗，比如N個商品銷量的最大最小、中位數、90%位數、平均數、標准差等，同樣是每天採集並形成變化趨勢，可以發現異常業務情況，Presto自帶了這些演算法。
在數倉小組內迅碰罩部，給重要表加上規則，再也不用擔心報表出現重大問題，而一無所知。
功能上線後有冷啟動的問題，用戶不了解，也不能感知產品價值，所以很少有用戶主動配置。於是我們通過默認的表級行數波動校驗，採集每次表更新完的最新行數，發現異常波動，幫助用戶發現問題，逐漸吸引用戶使用。偶爾還會有用戶驚嘆，這么隱蔽的問題也能被發現，這就體現了業務監控的價值。隨後我們通過培訓、開發者訪談等方式，逐步推廣。
後續有不少開發者，純粹為了執行校驗規則，發現業務異常數據，而把業務數據導入Hive中。也有DBA來查看採集到的數據量波動，來觀察DB的數據量吵跡增長情況。
數據質量是個很大話題，除了數據准確性，至少還包括數據產出及時性、表間的數據一致性，用戶甚至會把任何的數據看不懂都認為是數據質量問題，有些可能只是理解上的偏差。給Hive表配置了數據質量校驗規則，只是一定程度保證了准確性，要真正解決數據質量問題，還需要更多技術和規范的努力。
⑦ presto sql如何忽略中英文括弧匹配
中英文括弧是不同的符號，匹配不上很正常。
可以通過下面幾種方式處理：
1. 統一輸入，所有公司名在輸入的時候都把括弧統一成中文或英文（直接用字元串替換就行了），搜索的時候也統一一下。
舊的數據可以直接操作資料庫替換（操作前記得備份）
2. 搜索前將括弧替換為通配符，使用like做條件檢索。
如：搜索關鍵字 你好（北京）信息技術有限公司
則sql語句生成為 where companyname like '你好%北京%信息技術有限公司' （如果之前是用 = 作條件的話，兩邊不加% ，如果之前就是用like，在之前的條件中調整）
⑧ presto 配置 優先順序
presto主要配置文件如下： catalog/:配置各數據源的信息。presto是由facebook開源，基於內存的分布式查詢引擎。支持多數據源，可支持PB級海量數據查詢，本身不作數據存儲。由於基於內存查詢，減少了IO開銷，故查詢效率很高，但不適用於多表聯合查詢。
拓展資料：
1、presto架構 ：
與眾多分布式框架類似，由某組件進行請求處理以及分發任務至各執行節點。在presto架構中，Coordinator即為這樣的角色。負責解析SQL，生成執行計劃，分發任務到各節點。 Worker即各實際執行查詢的節點。worker收到任務後,通過各種connector取各數據源中的數據。 Discovery service即聯系Coordinator及Worker的服務。Worker啟動會向Discovery server注冊服務，Coordinator向Discovery server獲取Worker節點信息。
2、Presto因其優秀的查詢速度被我們所熟知，它本身基於MPP架構，可以快速的對Hive數據進行查詢，同時支持擴展Connector，目前對Mysql、MongoDB、Cassandra、Hive等等一系列的資料庫都提供了Connector進行支持。是我岩舉們常用的SQL on Hadoop的解決方案。那麼我們今天就來看一下，當我們選擇Presto作為我們的查詢引擎之後，我們需要考慮的問題。
3、單機維度
GENERAL_POOL每次內存申請時，都會判斷內存使用量是否超過了最大內存，如果超過了就報錯，錯誤為「Query exceeded local memory limit of x」，這保護了Presto會無限申請內存，只會導致當前查詢出錯。同時，如果該節點的GENERAL_POOL可使用內存以及可回收內存為0，那麼認為該node為Block node。RESERVED_POOL可以認為是查詢最大的SQL，其能滿足GENERAL_POOL的內存限制策略，那麼肯定會滿足RESERVED_POOL的策略(復用了GENERAL_POOL策略)。
4、Resource Groups
Resource Groups 可以認為是Presto實現了一個弱資源限制和隔離功能。其可以為每個group指定隊列大小、並發大小、內存使用大小。為每個group設置合理的hardConcurrencyLimit(最大並發數)、softMemoryLimit(內存最大使用值)及maxQueued(隊列大小)一方面可以使不同業務影響降低，另一方面也大概率粗扒碧避免OOM問題，當此攔然善於運用user及做下二次開發，就可以讓Presto支持多用戶共用同一分組和許可權認證功能。
⑨ 什麼是大數據的主流框架
市場上有許多可用的框架。其中一些更受歡迎，例如Spark，Hadoop，Hive和Storm。Presto在效用指數上得分很高，而Flink具有巨大的潛力。
1. Apache Hadoop
Hadoop是基於Java的平台。這是一個開放源代碼框架，可跨集群排列的一組硬體機器提供批處理數據處理和數據存儲服務。Hadoop同樣適用於可靠，可擴展和分布式的計算。但是，它也可以用作通用文件存儲。它可以存儲和處理PB的信息。Hadoop由三個主要組件組成。
2. Apache Spark
Spark框架由加利福尼亞大學伯克利分校成立。它是具有改進的數據流處理的批處理框架。藉助完整的內存計算以及處理優化，它保證了極其快速的集群計算系統。
3.Apache Storm
Apache Storm是另一個引人注目的解決方案，專注於處理巨大的實時數據流。Storm的主要亮點是可伸縮性和停機後的迅速恢復能力。
4. Apache Flink
Apache Flink是一個開源框架，同樣適用於批處理和流數據處理。它最適合於集群環境。該框架基於轉換–流概念。它也是大數據的4G。它比Hadoop – Map Rece快100倍。
5. Presto
Presto是最適合較小數據集的開源分布式SQL工具。Presto配備了協調員以及各種工人。當客戶提交查詢時，將對這些查詢進行解析，分析，計劃執行並分配給協調員在工作人員之間進行處理。
6. Samza
Apache Samza是有狀態的流，准備與Kafka共同開發的大數據系統。Kafka提供數據服務，緩沖和容錯能力。
⑩ presto簡介
MapRece不能滿足大數據快速實時adhoc查詢計算的性能要求，Facebook2012年開發，2013年開源
基於內存的並行計算，Facebook推出的分布式SQL互動式查詢引擎 多個節點管道式執行
支持任意數據源 數據規模GB~PB 是一種Massively parallel processing（mpp）(大規模並行處理)模型
數據規模PB 不是把PB數據放到內存，只是在計算中拿出一部分放在內存、計算、拋出、再拿
多數據源、支持SQL、擴展性（可以自己擴展新的connector）、混合計算（同一種數據源的不同庫 or表；將多個數據源的數據進行合並）、高性能、流水線（pipeline）
數據倉庫 互動式略弱的查詢引擎 只能訪問HDFS文件 磁碟
但是presto是無法代替hive的
基於spark core mpp模式 詳細課件spark sql一文
cube預計算
時序，數據放內存 索引 預計算
不適合多個大表的join操作，因為presto是基於內存的，太多數據內存放不下的
如果一個presto查詢查過30分鍾，那
就kill吧，說明不適合 也違背了presto的實時初衷
相當於MySQL的一個實例，
相當於MySQL的database
大內存、萬兆網路、高計算能力
presto 查詢引擎是一個Master-Slave的拓撲架構
中心的查詢角色 接收查詢請求、解析SQL 生成執行計劃 任務調度 worker管理
coordinator進行是presto集群的master進程
執行任務的節點
presto以插件形式對數據存儲層進行了抽象，它叫做連接器，不僅包含Hadoop相關組件的連接器還包括RDBMS連接器
具體訪問哪個數據源是通過catalog 中的XXXX.properties文件中connector.name決定的
提取數據 負責實際執行查詢計劃
將coordinator和worker結合在一起服務；
worker節點啟動後向discovery service服務注冊
coordinator通過discovery service獲取注冊的worker節點
1、coordinator接到SQL後，通過SQL語法解析器把SQL語法解析變成一個抽象的語法樹AST，只是進行語法解析如果有錯誤此環節暴露
2、語法符合SQL語法，會經過一個邏輯查詢計劃器組件，通過connector 查詢metadata中schema 列名 列類型等，將之與抽象語法數對應起來，生成一個物理的語法樹節點 如果有類型錯誤會在此步報錯
3、如果通過，會得到一個邏輯的查詢計劃，將其分發到分布式的邏輯計劃器里，進行分布式解析，最後轉化為一個個task
4、在每個task裡面，會將位置信息解析出來，交給執行的plan，由plan將task分給worker執行
1、如果某個worker掛了，discovery service 會通知coordinator
2、對於query是沒有容錯的，一旦worker掛了，query就執行失敗了，與其在這里容錯不如直接執行
3、coordinator 和discovery service 的單點故障問題還沒有解決