presto领读 查询引擎翻译
原文鏈接：https://prestodb.io/docs/current/overview/concepts.html#data-sources
?
最近在看presto-分布式SQL查詢引擎的代碼，使用翻譯工具翻譯了一版，有些概念比較難以理解，整理如下：
一、概覽
?
雖然很容易理解語句和查詢，但作為最終用戶，您應該熟悉一些概念，例如stage和split，以充分利用Presto執行有效的查詢。作為一個Presto管理員或一個Presto貢獻者，您應該理解Presto的階段映
射到任務的概念，以及任務如何包含一組處理數據的驅動程序。
這一節為整個Presto中引用的核心概念提供了一個可靠的定義，這些部分按照通用程度進行了排序。
二、服務節點類型
Presto中的服務節點有兩種具體類型：Coordinator和Worker。下面的章節會具體介紹他們之間的區別。
2.1?Coordinator
Presto中的Coordinator節點負責解析查詢語句、生成查詢計劃并調度Presto的Worker節點。它是Presto架構中的“大腦”并且也是presto client連接和提交執行語句的對象。每一個Presto集群都必須有
一個Presto Coordinator和至少一個Worker節點。在開發和測試過程中，單個Presto實例可以通過配置來同時具有這兩種角色。
Coordinator節點會保持對Worker節點的監聽并且協調一次查詢中的執行過程。Coordinator節點會創建一個包含一系列stage的查詢邏輯模型，然后將這些stage轉換為一系列的連接任務，運行在
Presto集群中的Worker節點上。
Coordinator和Worker節點以及client之間通過REST API來進行通信。
2.2 Worker
Worker節點在Presto集群中負責執行任何和處理數據。Worker節點從連接中獲取數據并相互交換中間數據。Coordinator節點負責從Worker節點上獲取數據并返回最終結果到client上。
當一個Presto的Worker啟動時，它會將自身信息廣播到Coordinator中的發現服務中，這使得它在Presto的Coordinator節點的任務執行中是可用的。
Worker節點和其他Worker節點以及Coordinator節點通過REST API進行通信。
三、數據源
本文整體介紹了Presto中的connector、catalog、schema和table等概念。這些在Presto中用于描述特定數據源的基礎信息將會在本章進行具體介紹。
3.1 Connector
Connector讓Prestor能夠適配諸如Hive或是關系型數據庫。你可以認為Connector是一種數據庫驅動。它由Presto的SPI實現，允許Presto通過標準API和外部資源進行交互。
Presto具有幾個內置的Connector：JMX Connector，提供對于內置系統table的系統Connector，Hive Connector和用于提供TPC-H基準數據的TPCH Connector。除此之外，許多第三方開發者也向
Presto貢獻了不同數據源的Connector。
每個Catalog都和一個指定的Connector綁定。如果你檢查Catalog的配置文件，就會發現每一個Catalog都包含了一個強制的屬性connector.name，用于Catalog Manager來針對給定的Catalog創建
Connector。在Presto，可以支持多個Catalog使用相同的Connector來訪問兩個類似的不同數據庫實例。例如，如果你有兩個Hive集群，你可以在一個Presto集群中配置兩個都是用Hive Connector的Catalog，允許用戶從兩個Hive集群中查詢數據（甚至在一個查詢SQL中也支持）。
3.2?Catalog
一個Presto中的Catalog維護了Schema信息和通過Connector連接的數據源信息。例如，你可以使用JMX Connector配置一個JMX Catalog來提供對JMX信息的訪問。當你再Presto上運行一個SQL語
句時，實際上是在一個或多個Catalog上運行。
在Presto中對一個table進行尋址時，表的全限定名稱總是在Catalog中管理。例如，hive.test_data.test的全限定表名會指向hive catalog的test_data schema中的test table。
Catalog在Presto的配置路徑中存儲的屬性文件中定義。
3.3 Schema
Schema是一種組織表的方式。Catalog和Schema定義了一組可以被查詢的table集合。當在Presto中訪問Hive或是類似于MySQL的關系型數據庫時，Schema會將概念轉換為目標數據庫中的對應概
念。其他類型的Connector可以選擇以一種對底層數據源有意義的方式將tale以Schema的形式組織管理起來。
3.4 Table
Table是一組以有類型的命名列組織起來的無序行的集合。這在任何關系型數據庫中都是一樣的。從元數據到table的映射關系定義在Connector中。
四、查詢執行模型
Presto執行SQL語句并將這些語句轉換為執行在由Coordinator和Worker的分布式系統中的查詢。
4.1?Statement
Presto執行與ANSI標準兼容的SQL語句。當Presto文檔引用一個查詢語句時，它指的是ANSI SQL標準中定義的查詢語句，包含子句、表達式和謂詞。
一些堵著可能會好奇為什么本章把Statement和Query兩個概念進行了分離。這是必須的，因為，在Presto中，語句只指向SQL語句的文本標識。在執行語句時，Presto會創建一個查詢和一個執行計劃，它們會在Presto的Worker節點集合中進行分發。
4.2 Query
當Presto解析一個語句時，它將其轉換為一個查詢，并創建一個分布式查詢計劃，然后將其實現為在Presto Worker節點上上運行的一系列相互連接的階段。當你在Presto中檢索有關查詢的信息時，您
將接收到為響應語句而生成結果集所涉及的每個組件的快照。
Statement和Query之間的區別是很簡單的。一個Statement是傳遞給Presto的SQL文本，然而一個Query指的是用于執行Statement而創建的一系列配置項和組件。Query包含stage、task、split、
connector和其他配置以及為產生結果集而協作的data source。
4.3 Stage
當Presto執行查詢時，它通過將查詢執行過程拆分為分層stage來達成目的。例如，如果Presto需要對存儲在Hive中的億級別的數據進行聚合，它會創建一個根stage來對多個stage的輸出，所有這些階
段的設計都是為了實現分布式查詢計劃的不同部分。
構成一個Query的層次stage結構類似樹。每個Query都有一個根stage，來負責聚合其他stage的輸出。Coordinator使用Stage用來對分布式查詢進行建模，但是stage本身并不會在Presto的Worker節
點上運行。
4.4 Task
如上章所說，stage對一個分布式查詢計劃進行建模，但是stage自身不會在Presto的Worker節點上運行。為了理解stage是如何執行的，我們需要了解stage是由分布在Presto集群中的Worker節點上
task集合實現的。
任務是Presto架構中的“work horse”，因為分布式查詢計劃被分解為一系列的階段，然后被翻譯成任務，然后執行或處理分割。一個Presto任務有輸入和輸出，就像一個階段可以并行執行一系列任務
一樣，一個任務與一系列驅動程序并行執行。
4.5?Split
任務是在一個大數據集上分段進行的。分布式查詢計劃的最底層stage會執行從split的Connector中檢索數據的操作，并且分布式查詢計劃的高層中間stage會從其他stage上檢索數據。
當Presto調度一個查詢時，Coordinator會向一個Connector查詢可用于表的split的所有列表。Coordinator會跟蹤哪些機器正在運行哪些任務、哪些任務正在處理哪些split。
4.6 Driver
Task包含一個或多個并行Driver。Driver在數據上運行并且結合運算符來生產輸出，這些輸出稍后將會由一個task來進行聚合并傳遞給另外一個stage中的另外一個task上。Driver是一組Operator實例的
序列，或者你可以認為Driver是一組內存中的Operator的物理集合。它是Presto架構中的最低級的并行性。一個Driver會有一個輸入和一個輸出。
4.7 Operator
Operator消費、轉換并生成數據。例如，一個table scan fetch可以從Connector中獲取數據，并生成可以被其他Operator消費的數據，一個文件operator消費數據并且通過在輸入數據上運行一個謂詞
來產生一個數據子集。
4.8 Exchange
Exchange在Presto節點上為單次查詢的不同stage來傳輸數據。Task向output緩存產生數據并且通過一個exchange client消費其他task產生的數據。
總結
以上是生活随笔為你收集整理的presto领读 查询引擎翻译的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SSR (misa + primer3
- 下一篇： 算法第四版 课后习题答案