原理分析

pg_lakehouse 是 ParadeDB 推出的一個(gè)開(kāi)源插件，支持對(duì)多種數(shù)據(jù)湖里的數(shù)據(jù)做分析計(jì)算。它的出現(xiàn)，使得 Postgres 能夠像訪問(wèn)本地?cái)?shù)據(jù)一樣輕松訪問(wèn) S3 等對(duì)象存儲(chǔ)，輕松訪問(wèn) Delta Lake 上的表格，具備數(shù)據(jù)湖分析能力。

pg_lakehouse 的查詢計(jì)算能力是通過(guò) Apache DataFusion 來(lái)支持的。DataFusion 是一個(gè)純計(jì)算引擎，它不負(fù)責(zé)存儲(chǔ)，內(nèi)置了幾種數(shù)據(jù)格式支持，并且可以通過(guò) TableProvider 接口支持更多的數(shù)據(jù)輸入方式[ref]。

從原來(lái)上看， pg_lakehouse 提供了一組訪問(wèn)數(shù)據(jù)湖的方法，并將這些方法和 DataFusion 的計(jì)算能力結(jié)合起來(lái)，幫助 Postgres 獲得分析數(shù)據(jù)湖數(shù)據(jù)的能力。

也就是說(shuō)，Postgres 基于 pg_lakehouse 做數(shù)據(jù)湖分析時(shí)，計(jì)算能力主要靠 pg_lakehouse 提供，而不是依賴 Postgres 自身的計(jì)算引擎。Postgres 的價(jià)值在于給用戶提供一個(gè)一致的操作界面，如 SQL dialect、schema view、生態(tài)工具等。

用戶訪問(wèn)數(shù)據(jù)湖的整體交互流程如下：
SQL -(pgsql)-> Postgres --> pg_lakehouse -(FDW, DF understandable SQL Dialect)-> DataFusion

pg_lakehouse 對(duì)數(shù)據(jù)湖的訪問(wèn)，是基于 postgres 外表界面實(shí)現(xiàn)的。有幾點(diǎn)需要注意：

• 集成湖的 catalog 不是必須的。Doris 等湖倉(cāng)一體的數(shù)據(jù)庫(kù)為了簡(jiǎn)化用戶使用，會(huì)做 Multi External Catalog 集成，自動(dòng)導(dǎo)入外表 schema。pg_lakehouse 依然要求用戶在 Postgres 中創(chuàng)建外表。
• pg_lakehouse 支持通過(guò) arrow_schema function 來(lái)自動(dòng)獲取湖中數(shù)據(jù)的 schema
• Postgres 還支持類似這樣的語(yǔ)法批量導(dǎo)入外部 schema（但對(duì)于 lakehouse 的支持程度如何暫未調(diào)研）：import foreign schema public from server duckdb into public;

Thinking in MyDB

對(duì)于 MyDB 來(lái)說(shuō)，計(jì)算引擎部分依然是使用 MyDB 自身的計(jì)算引擎，無(wú)需依賴第三方（如 DataFusion、Volex）。

MyDB 重點(diǎn)是實(shí)現(xiàn)可擴(kuò)展的數(shù)據(jù)湖接入策略，降低接入新存儲(chǔ)、新格式的成本。我們要區(qū)分好 Object Stores、File Format 和 Table Format 三方面的需求，各自做好擴(kuò)展。

Object Stores：

• Amazon S3
• Aliyun OSS
• Tencent Cloud COS
• Huawei Cloud OBS
• S3-compatible object stores (e.g. MinIO)
• Azure Blob Storage
• Azure Data Lake Storage Gen2
• Google Cloud Storage
• Local file system
• potentially any service supported by Apache OpenDAL.

File Formats

• Parquet
• CSV
• JSON
• Avro
• ORC

Table Formats

• Delta Lake
• Apache Iceberg
• MaxCompute

Schema 的集成，要做一些聰明的事情。External Catalog 固然美好，但增加了對(duì)外部系統(tǒng)的依賴，壓力大的情況下，外部系統(tǒng)可能先掛。如果能提供一套快速創(chuàng)建、刷新 External Table 的方法，也不失為一種好的解決方案。

參考

組件說(shuō)明：

ParadeDB is an Elasticsearch alternative built on Postgres. We’re modernizing the features of Elasticsearch’s product suite, starting with real-time search and analytics.

pg_lakehouse is an extension that transforms Postgres into an analytical query engine over object stores like S3 and table formats like Delta Lake. Queries are pushed down to Apache DataFusion, which delivers excellent analytical performance. Combinations of the following object stores, table formats, and file formats are supported.

DataFusion includes several built in data sources for common use cases, and can be extended by implementing the TableProvider trait. A TableProvider provides information for planning and an ExecutionPlans for execution.

DataFusion Motivation
Today, a vast amount of non-operational data — events, metrics, historical snapshots, vendor data, etc. — is ingested into data lakes like S3. Querying this data by moving it into a cloud data warehouse or operating a new query engine is expensive and time consuming. The goal of pg_lakehouse is to enable this data to be queried directly from Postgres. This eliminates the need for new infrastructure, loss of data freshness, data movement, and non-Postgres dialects of other query engines.
.
pg_lakehouse uses the foreign data wrapper (FDW) API to connect to any object store or table format and the executor hook API to push queries to DataFusion. While other FDWs like aws_s3 have existed in the Postgres extension ecosystem, these FDWs suffer from two limitations:
.
Lack of support for most object stores, file, and table formats
Too slow over large datasets to be a viable analytical engine
pg_lakehouse differentiates itself by supporting a wide breadth of stores and formats (thanks to OpenDAL) and by being very fast (thanks to DataFusion).

FDW 工作原理：

在 PostgreSQL 中，外部數(shù)據(jù)包裝器（Foreign Data Wrapper，FDW）允許一個(gè) PostgreSQL 服務(wù)器訪問(wèn)外部數(shù)據(jù)源，如另一個(gè) SQL 或 NoSQL 數(shù)據(jù)庫(kù)。FDW 的工作機(jī)制基于 SQL/MED ("SQL Management of External Data") 標(biāo)準(zhǔn)，這提供了一個(gè)框架來(lái)訪問(wèn)和管理存儲(chǔ)在不同數(shù)據(jù)源中的數(shù)據(jù)。PostgreSQL FDW 如何工作主要包括以下步驟：1. 加載和創(chuàng)建 FDW 擴(kuò)展：
第一步是在 PostgreSQL 數(shù)據(jù)庫(kù)中加載和創(chuàng)建相應(yīng)的 FDW 擴(kuò)展。例如，postgres_fdw 用于連接遠(yuǎn)程 PostgreSQL 服務(wù)器，其他 FDW 如 mysql_fdw 用于 MySQL 數(shù)據(jù)庫(kù)連接等。2. 定義外部服務(wù)器和用戶映射：
在 PostgreSQL 中，指定外部數(shù)據(jù)源的詳細(xì)信息，比如服務(wù)器地址、端口、登錄憑證等，并為本地用戶創(chuàng)建映射以授權(quán)遠(yuǎn)程數(shù)據(jù)訪問(wèn)。3. 創(chuàng)建外部表：
定義外部表，這些表代表遠(yuǎn)程數(shù)據(jù)源中的表。這個(gè)步驟將遠(yuǎn)程表的模式映射到 PostgreSQL 中，來(lái)決定哪些列和數(shù)據(jù)類型將被訪問(wèn)。4. 查詢外部表：
當(dāng)本地 PostgreSQL 服務(wù)器上的用戶查詢外部表時(shí)，查詢將被轉(zhuǎn)發(fā)到 FDW。SQL 轉(zhuǎn)化過(guò)程：
當(dāng)一個(gè) SQL 查詢是對(duì)一個(gè)外部表的操作時(shí)，FDW 會(huì)接管這個(gè)查詢，并進(jìn)行以下轉(zhuǎn)換過(guò)程：解析：FDW 分析本地查詢的結(jié)構(gòu)，這通常涉及解析 SQL 語(yǔ)句并理解所請(qǐng)求的目標(biāo)數(shù)據(jù)、過(guò)濾條件、聚合操作和排序需求。轉(zhuǎn)換：然后，FDW 會(huì)把本地 SQL 查詢翻譯（或重寫）成遠(yuǎn)程數(shù)據(jù)庫(kù)系統(tǒng)理解的"方言"。例如，如果遠(yuǎn)程數(shù)據(jù)源是 MySQL 數(shù)據(jù)庫(kù)，postgres_fdw 會(huì)將 PostgreSQL SQL 查詢轉(zhuǎn)換為 MySQL 可以理解的 SQL 查詢。執(zhí)行：轉(zhuǎn)換過(guò)的查詢被發(fā)送到遠(yuǎn)程數(shù)據(jù)庫(kù)，由遠(yuǎn)程數(shù)據(jù)庫(kù)執(zhí)行。結(jié)果獲取：查詢結(jié)果從遠(yuǎn)程數(shù)據(jù)庫(kù)返回到 PostgreSQL 服務(wù)器，并在必要時(shí)進(jìn)行進(jìn)一步的處理（例如，如果一些請(qǐng)求在遠(yuǎn)程數(shù)據(jù)庫(kù)上不能完成，如某些類型的JOIN操作，那么這些操作需要在返回結(jié)果之后由 PostgreSQL 本身完成）。結(jié)果返回：經(jīng)處理的數(shù)據(jù)最終返回給客戶端。這個(gè)過(guò)程的某些環(huán)節(jié)可能依賴特定的 FDW 實(shí)現(xiàn)。比如，并非所有的查詢條件和聚合操作都可以推送到所有類型的遠(yuǎn)程數(shù)據(jù)源進(jìn)行處理?？赡苣承┎僮鞅仨氃诒镜?PostgreSQL 端完成，這取決于 FDW 的功能和遠(yuǎn)程數(shù)據(jù)源的限制。FDW 的優(yōu)勢(shì)之一是它提供了一種透明的機(jī)制來(lái)訪問(wèn)外部數(shù)據(jù)，使得外部數(shù)據(jù)源的表現(xiàn)形式與本地表非常相似，使開(kāi)發(fā)者能以統(tǒng)一的方式查詢和操作數(shù)據(jù)。然而，性能和功能上的限制要依賴于具體的 FDW 實(shí)現(xiàn)和外部數(shù)據(jù)源的能力。