常見問題 (FAQ)¶
ADBC 究竟是什麼？¶
ADBC 是
一套以不同語言 (C/C++、Go 和 Java，未來還會增加更多) 撰寫的抽象 API，用於處理資料庫和 Arrow 資料。
例如，ADBC 中查詢的結果集都以 Arrow 資料流的形式傳回，而不是逐行傳回。
一套以不同語言 (C/C++、C#/.NET、Go、Java、Python 和 Ruby) 撰寫的 API 實作，目標是不同的資料庫 (例如 PostgreSQL、SQLite、任何支援 Flight SQL 的資料庫)。
為什麼不直接使用 JDBC/ODBC？¶
JDBC 使用基於列的介面，例如 ResultSet。當處理像 Arrow 資料這樣的欄式資料時，這意味著我們必須至少轉換資料一次，甚至可能兩次
可能在驅動程式或資料庫中進行一次 (可能)，將欄式資料轉換為基於列的格式，以便可以透過 JDBC API 傳回。
當用戶端應用程式從 JDBC API 提取資料時，總是會進行一次轉換 (總是)，將列轉換為欄。
為了符合 Arrow 的「零複製」或「最少複製」精神，我們希望避免這些不必要的轉換。
ODBC 的情況也類似。雖然 ODBC 確實支援 「欄式綁定」，但並非所有 ODBC 驅動程式都支援它，而且使用起來更複雜。此外，ODBC 使用呼叫者分配的緩衝區 (這通常意味著強制資料複製)，而且 ODBC 指定的資料佈局與 Arrow 不完全相容 (無論如何都需要資料轉換)。
因此，我們認為僅僅擴展 ODBC 不足以滿足 ADBC 的目標。ODBC 對於更廣泛的資料庫支援始終很有價值，並且在 ODBC 之上提供基於 Arrow 的 API 是有用的。ADBC 將允許在通用程式庫中實作/最佳化此轉換，為消費者提供更簡單的介面，並提供一個 API，讓 Arrow 原生系統或其他欄式系統可以實作以繞過此包裝器。
為什麼 ODBC/Arrow 不能完全契合
ODBC 透過 區塊游標 提供對批量資料的支援，而 Turbodbc 證明了可以在其之上建構高效能的基於 Arrow 的 API。然而，對於 Arrow 來說，它仍然是一個尷尬的組合
Null 值 (「指示器」值) 表示為整數，需要轉換。
結果緩衝區是呼叫者分配的。這可能會強制不必要地複製資料。ADBC 改用 C 資料介面，在可能的情況下消除複製 (例如，如果驅動程式使用 Flight SQL)。
某些資料類型以不同的方式表示，需要轉換。SQL_C_BINARY 可以為協作的驅動程式和應用程式避開這個問題，但這樣應用程式就必須以不同的方式處理基於 Arrow 和非基於 Arrow 的資料來源。
字串必須以 null 結尾，這將需要在 Arrow 陣列中複製，或者要求應用程式處理陣列中以 null 結尾的字串。
字串是否可以包含嵌入的 null 值是實作定義的，但 Arrow 指定 UTF-8 字串，其中 0x00 是有效的位元組。
由於緩衝區是呼叫者分配的，因此驅動程式和應用程式必須協作才能處理大型字串；驅動程式必須截斷值，而應用程式可以嘗試再次提取該值。
ODBC 使用長度緩衝區而不是偏移量，需要另一次與 Arrow 字串陣列之間的轉換。
ADBC 和 Arrow Flight SQL 有何不同？¶
ADBC 是一個用戶端 API 規範。它沒有定義用戶端和資料庫之間發生什麼，只是應用程式開發人員發出的 API 呼叫。在底層，驅動程式必須接收這些 API 呼叫並與實際的資料庫通訊。另一個角度來看，ADBC 完全是關於用戶端，並且沒有指定網路協定或伺服器端實作。
Flight SQL 是一個線路協定。它指定了要傳送到資料庫的確切命令，以執行各種操作，例如與資料庫進行身份驗證、建立預備語句或執行查詢。Flight SQL 指定了用戶端和伺服器必須實作的網路協定。
另一種看待它的方式：可以僅為資料庫編寫 ADBC 驅動程式作為用戶端程式庫。(例如，此儲存庫中的 PostgreSQL 驅動程式就是這樣實作的，作為 libpq 的包裝器。) 但是向資料庫添加 Flight SQL 支援意味著要麼修改資料庫以執行 Flight SQL 服務，要麼將資料庫置於代理之後，該代理在 Flight SQL 和資料庫之間進行轉換。
為什麼不直接使用 Arrow Flight SQL？¶
由於 ADBC 是用戶端，因此 ADBC 可以支援不支援傳回 Arrow 資料的資料庫，或者透過 Flight SQL 以外的協定支援 Arrow 資料的資料庫。
那麼我們真的需要 Arrow Flight SQL 嗎？¶
Flight SQL 是一個具體的協定，資料庫供應商可以實作，而不是設計自己的協定。而且 Flight SQL 也具有 JDBC 和 ODBC 驅動程式，以實現最大的相容性。
作為一個類比：許多資料庫實作 PostgreSQL 線路協定，以便它們可以存取所有 PostgreSQL 用戶端，包括 JDBC 和 ODBC 驅動程式。(而且 JDBC/ODBC 用戶仍然可以使用其他驅動程式來處理其他資料庫。)
對於 Arrow 生態系統，我們希望資料庫將實作 Flight SQL 線路協定，讓它們可以存取所有 Flight SQL 用戶端，包括 ADBC、JDBC 和 ODBC 驅動程式。(而且 ADBC 用戶仍然可以使用其他驅動程式來處理其他資料庫。)
那麼「ADBC Flight SQL 驅動程式」是什麼？¶
ADBC Flight SQL 驅動程式使用 Flight SQL 線路協定 (資料庫伺服器公開的) 實作 ADBC API 標準 (應用程式與之互動的)。因此，它是一個通用的驅動程式，可以與許多資料庫通訊，只要這些資料庫實作 Flight SQL 即可。
這有點不尋常，因為您會發現大多數資料庫驅動程式和資料庫協定都是為特定的資料庫設計的。但是 Flight SQL 從一開始就被設計為與資料庫無關，ADBC 也是如此。
聽起來它們似乎重疊，但它們是互補的，因為它們在不同的抽象層次上運作。資料庫開發人員只需提供 Flight SQL 服務，這將為他們提供免費的 ADBC、JDBC 和 ODBC 驅動程式，而無需自行建構和維護這些驅動程式。資料庫使用者只需使用 ADBC 作為一個 Arrow 原生 API，即可處理 Arrow 原生和非 Arrow 原生資料庫，無論這些資料庫是否支援 Flight SQL、自訂 Arrow 原生協定，還是不支援 Arrow 原生協定。
那麼「ADBC JDBC 驅動程式」又是什麼？¶
ADBC JDBC 驅動程式，或假設的 ADBC ODBC 驅動程式，將 JDBC API 適配到 ADBC API，以便 ADBC 使用者可以與具有可用 JDBC API 的資料庫互動。雖然這不能提供最佳效能 (您需要為來回轉置資料付出代價！)，但它確實省去了您自己編寫這些轉換的麻煩。
已經存在類似的程式庫；例如，Turbodbc 將任何 ODBC 驅動程式包裝在 Python 的 DBAPI (PEP 249) 中，而 arrow-jdbc 將任何 JDBC 驅動程式包裝在客製化的基於 Arrow 的 API 中。
所有這些 API 如何組合在一起？¶
我們可以根據兩個軸來劃分 API：Arrow 原生與基於列，以及資料庫特定與資料庫不可知。
資料庫不可知的 API 從供應商中抽象出來，包括 ADBC、JDBC、ODBC，以及在一定程度上的 Flight SQL。(如上所述，Flight SQL 仍然需要特定的供應商支援；xJDBC 不需要。)
資料庫特定的 API 由供應商為其系統製作，儘管其他系統最終可能會重新實作這些 API 以實現相容性 (就像 PostgreSQL 線路協定經常做的那樣)。
像 ADBC、Flight SQL 和 BigQuery Storage API 這樣的 Arrow 原生 API 原生傳回 Arrow 資料，或更廣泛地說是欄式資料。這可以為處理大量資料的應用程式帶來效能優勢。
像 JDBC、ODBC 和 PostgreSQL 線路協定這樣的基於列的 API 一次處理單列。對於某些類型的應用程式來說，這可能更方便
什麼是 ADBC 驅動程式管理器？¶
驅動程式管理器 (在 C/C++ 中) 是一個程式庫，它實作驅動程式 API，但在幕後動態載入和管理多個驅動程式。它允許應用程式連結到單個程式庫，但一次使用多個驅動程式。這避免了多個驅動程式之間可能發生的符號衝突，否則這些驅動程式都將在相同的名稱下提供相同的 ADBC API。
如需深入了解，請參閱 驅動程式與驅動程式管理器如何協同運作。
什麼是 ADBC SQL 方言？¶
這是個陷阱題！ADBC 不是 SQL 方言。ADBC 驅動程式需要做的所有事情就是將您的查詢字串傳遞到資料庫，並將結果集作為 Arrow 資料取得。在這方面，它就像 JDBC。(ODBC 有它定義的「標準」SQL 方言；ADBC 沒有這樣做。)
對於一個試圖解決定義與供應商無關的查詢語言問題的專案，請參閱 Substrait。
下一個版本何時發布？¶
沒有固定的發布週期。我們目前目標是每 6-8 週發布一次版本。
一旦版本被標記，專案就會給予 Arrow PMC 至少 72 小時的時間來對發布進行投票。一旦投票結束，套件就會上傳到 PyPI、conda-forge 等地方。因此，即使在發布之後，二進制套件也可能需要一些時間才能可用。
何時/何地發布 1.0 版本？這個專案準備好了嗎？¶
專案的不同部分具有不同的版本號。我們認為某些實作 (例如 Go) 已「準備好 1.0」版本，而其他實作 (例如 Java) 仍處於 1.0 版本之前。驅動程式實作狀態 提供了各個驅動程式實作狀態的粗略概述。