This is an automated email from the ASF dual-hosted git repository.
ianmcook pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/arrow-site.git
The following commit(s) were added to refs/heads/main by this push:
new 9a13e2daf1e Remove `{:target="_blank"}` (#678)
9a13e2daf1e is described below
commit 9a13e2daf1ec399e56e732951feb291559fe10db
Author: Ian Cook <[email protected]>
AuthorDate: Wed Jul 23 19:48:05 2025 -0400
Remove `{:target="_blank"}` (#678)
Partially fixes #677.
---
.../2025-01-10-arrow-result-transfer-japanese.md | 24 +++++++++++-----------
_posts/2025-01-10-arrow-result-transfer.md | 24 +++++++++++-----------
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/_posts/2025-01-10-arrow-result-transfer-japanese.md
b/_posts/2025-01-10-arrow-result-transfer-japanese.md
index b9722a9eb68..077c3dac5d4 100644
--- a/_posts/2025-01-10-arrow-result-transfer-japanese.md
+++ b/_posts/2025-01-10-arrow-result-transfer-japanese.md
@@ -41,7 +41,7 @@ _この記事はデータベースとクエリーエンジン間のデータ交
これはデータを扱っている人がクエリー結果を待っている間によく考える質問です。たくさんの回答が考えられます。もしかしたら、データソースが適切にパーティショニングされていないかもしれません。もしかしたら、SaaSのデータウェアハウスのリソースが足りないのかもしれません。もしかしたら、クエリーオプティマイザーがSQL文を効率的な実行計画に落とし込めなかったのかもしれません。
-しかし、驚くほど多くの場合、クエリ結果をクライアントに転送するために非効率なプロトコルを使っていることが答えになります。[2017年の論文](https://www.vldb.org/pvldb/vol10/p1022-muehleisen.pdf){:target="_blank"}では、Mark
RaasveldtとHannes
Mühleisenは、特にクエリー結果が大きい場合、クエリー結果の転送がクエリー実行時間の大部分を占めることがよくあることを観測しました。しかし、ボトルネックはあなたが予想している場所ではありません。
+しかし、驚くほど多くの場合、クエリ結果をクライアントに転送するために非効率なプロトコルを使っていることが答えになります。[2017年の論文](https://www.vldb.org/pvldb/vol10/p1022-muehleisen.pdf)では、Mark
RaasveldtとHannes
Mühleisenは、特にクエリー結果が大きい場合、クエリー結果の転送がクエリー実行時間の大部分を占めることがよくあることを観測しました。しかし、ボトルネックはあなたが予想している場所ではありません。
送信元から受信先へのクエリー結果の転送は次の3つのステップになります。
@@ -51,11 +51,11 @@ _この記事はデータベースとクエリーエンジン間のデータ交
ネットワークが遅かった時代は、通常はデータ転送ステップ（ステップ2）がボトルネックでした。そのため、シリアライズステップ（ステップ1）とデシリアライズステップ（ステップ3）を高速にする動機はほとんどありませんでした。その代わり、転送するデータを小さくすることに重点がおかれていました。多くの場合は転送時間を短縮するためにデータを圧縮していました。広く使われているデータベース接続API（ODBCとJDBC）とデータベースクライアントプロトコル（MySQLのクライアント・サーバープロトコルやPostgreSQLのフロントエンド・バックエンドプロトコル）はこの時代に設計されました。しかし、ネットワークは高速になり、転送時間が短縮されたため、ボトルネックはシリアライズステップとデシリアライズステップに移�
�きました[^2]。これは大きな結果を生成するクエリーで特に当てはまります。多くのデータエンジニアリングパイプライン・データ分析パイプラインではこのようなクエリーがよく実行されます。
-今でも多くのクエリー結果はレガシーなAPI・プロトコルで転送されています。これらのAPI・プロトコルでは非効率な転送用のフォーマットを使わないといけないので、多くのシリアライズ・デシリアライズオーバーヘッドがあります。[2021年の論文](https://www.vldb.org/pvldb/vol14/p534-li.pdf){:target="_blank"}では、Tianyu
LiらはODBCとPostgreSQLプロトコルを使う例を示しました。この例では、総クエリー実行時間の99.996%がシリアライズ・デシリアライズに費やされていました。これは極端なケースですが、90%以上費やされている実例をたくさん見てきました。今では、データエンジニアリングクエリー・データ分析クエリーのために、シリアライズ・デシリアライズを高速にする転送用フォーマットを選択する強い動機があります。
+今でも多くのクエリー結果はレガシーなAPI・プロトコルで転送されています。これらのAPI・プロトコルでは非効率な転送用のフォーマットを使わないといけないので、多くのシリアライズ・デシリアライズオーバーヘッドがあります。[2021年の論文](https://www.vldb.org/pvldb/vol14/p534-li.pdf)では、Tianyu
LiらはODBCとPostgreSQLプロトコルを使う例を示しました。この例では、総クエリー実行時間の99.996%がシリアライズ・デシリアライズに費やされていました。これは極端なケースですが、90%以上費やされている実例をたくさん見てきました。今では、データエンジニアリングクエリー・データ分析クエリーのために、シリアライズ・デシリアライズを高速にする転送用フォーマットを選択する強い動機があります。
そこでArrowですよ！
-Apache
Arrowオープンソースプロジェクトは[データフォーマット](https://arrow.apache.org/docs/format/Columnar.html){:target="_blank"}を定義しています。このフォーマットはクエリー結果転送時のシリアライズ・デシリアライズを高速にするために設計されています。多くの場合は、シリアライズ・デシリアライズは不要になります。2016年に作られて以来、Arrowフォーマットおよびこのフォーマットを中心に構築された多言語対応ツールボックスは広く使われるようになりました。しかし、Arrowがどのようにシリアライズ・デシリアライズのオーバーヘッドを削減しているかの技術的な詳細はあまり理解されていません。この問題を解決するために、シリアライズ・デシリアライズのオーバーヘッドを削減することを可能にするArrowフォーマットの5つの特徴を�
�します。
+Apache
Arrowオープンソースプロジェクトは[データフォーマット](https://arrow.apache.org/docs/format/Columnar.html)を定義しています。このフォーマットはクエリー結果転送時のシリアライズ・デシリアライズを高速にするために設計されています。多くの場合は、シリアライズ・デシリアライズは不要になります。2016年に作られて以来、Arrowフォーマットおよびこのフォーマットを中心に構築された多言語対応ツールボックスは広く使われるようになりました。しかし、Arrowがどのようにシリアライズ・デシリアライズのオーバーヘッドを削減しているかの技術的な詳細はあまり理解されていません。この問題を解決するために、シリアライズ・デシリアライズのオーバーヘッドを削減することを可能にするArrowフォーマットの5つの特徴を説明します。
### 1. Arrowフォーマットは列指向
@@ -88,7 +88,7 @@ Arrowフォーマットは自己記述的で型安全を強制します。さら
ゼロコピー操作とは、中間コピーをまったく作成せずにあるメディアから別のメディアにデータを転送する操作です。データフォーマットがゼロコピー操作をサポートしている場合、メモリー上の構造はディスク上あるいはネットワーク上の構造と同じになります。そのため、たとえば、メモリー上で使える構造のデータをネットワークから直接読み込めます。このとき、中間コピーや変換をする必要はありません。
-Arrowフォーマットはゼロコピー操作をサポートしています。データの値の集まりを保持するために、Arrowは[レコードバッチ](https://arrow.apache.org/docs/format/Columnar.html#serialization-and-interprocess-communication-ipc){:target="_blank"}と呼んでいる列指向の表形式のデータ構造を定義しています。Arrowのレコードバッチはメモリー上に保持することもできますし、ネットワーク経由で送信することもできますし、ディスクに保存することもできます。レコードバッチがどのメディアにあってもどのシステムで生成されてもバイナリー構造は変わりません。スキーマと他のメタデータを保存するために、ArrowはFlatBuffersを使っています。FlatBuffersはGoogleが作ったフォーマットです。FlatBuffersも、どのメディア上でも同じバイナリー構造になります。
+Arrowフォーマットはゼロコピー操作をサポートしています。データの値の集まりを保持するために、Arrowは[レコードバッチ](https://arrow.apache.org/docs/format/Columnar.html#serialization-and-interprocess-communication-ipc)と呼んでいる列指向の表形式のデータ構造を定義しています。Arrowのレコードバッチはメモリー上に保持することもできますし、ネットワーク経由で送信することもできますし、ディスクに保存することもできます。レコードバッチがどのメディアにあってもどのシステムで生成されてもバイナリー構造は変わりません。スキーマと他のメタデータを保存するために、ArrowはFlatBuffersを使っています。FlatBuffersはGoogleが作ったフォーマットです。FlatBuffersも、どのメディア上でも同じバイナリー構造になります。
これらの設計判断により、Arrowは転送用のフォーマットとしてだけでなく、メモリー上のフォーマットとしてもディスク上のフォーマットとしても使えます。これは、JSONやCSVといったテキストベースのフォーマットやProtocol
BuffersやThriftといったシリアライズされたバイナリーフォーマットとは対照的です。これらのフォーマットは専用の構文を使ってデータをエンコードします。これらのフォーマットのデータをメモリー上で使える構造にロードするには、データをパースしてデコードする必要があります。これはParquetやORCといったバイナリーフォーマットとも対照的です。これらはディスク上でのデータサイズを削減するためにエンコードしたり圧縮したりします。これらのフォーマットのデータをメモリー上で使える構造にロードす�
�めには、展開してデコードする必要があります[^3]。
@@ -102,7 +102,7 @@ Arrowフォーマットは非常に効率よく分析操作できるメモリー
たとえば、CSVはストリーム可能なデータフォーマットです。なぜなら、（もし含まれているなら）ファイルの先頭のヘッダーにカラム名があって、ファイル中のそれ以降の行は順番に処理できるからです。一方、ParquetとORCはストリーム可能ではないデータフォーマットです。なぜなら、データを処理するために必要なスキーマと他のメタデータがファイルの最後のフッターにあるからです。処理を始める前にファイル全体をダウンロードする（あるいはファイルの最後まで移動してフッターを別途ダウンロードする）必要があります[^4]。
-Arrowはストリーム可能なデータフォーマットです。データセットは同じスキーマを持つレコードバッチの列としてArrowで表現できます。Arrowは[ストリーミングフォーマット](https://arrow.apache.org/docs/format/Columnar.html#ipc-streaming-format){:target="_blank"}を定義しています。このフォーマットでは、まずスキーマがあり、そのあと、1つ以上のレコードバッチがあります。Arrowストリームを受信するシステムは受信した順にレコードバッチを処理できます。
+Arrowはストリーム可能なデータフォーマットです。データセットは同じスキーマを持つレコードバッチの列としてArrowで表現できます。Arrowは[ストリーミングフォーマット](https://arrow.apache.org/docs/format/Columnar.html#ipc-streaming-format)を定義しています。このフォーマットでは、まずスキーマがあり、そのあと、1つ以上のレコードバッチがあります。Arrowストリームを受信するシステムは受信した順にレコードバッチを処理できます。
<figure style="text-align: center;">
<img src="{{ site.baseurl
}}/img/arrow-result-transfer/part-1-figure-2-arrow-stream.png" width="100%"
class="img-responsive"
alt="図2：3列の表を転送するArrowストリーム。最初のレコードバッチは最初の3行の値だけを含み、2つめのレコードバッチは次の3行のデータが含まれている。実際のArrowレコードバッチには数千から数百万行が含まれていることもある。">
@@ -113,7 +113,7 @@ Arrowはストリーム可能なデータフォーマットです。データセ
Arrowは表形式のデータをメモリー上で扱うためのデファクトスタンダードなフォーマットとして登場しました。Arrowは言語に依存しないオープンな標準です。様々な言語向けにArrowデータを扱うためのライブラリーが用意されています。たとえば、C・C++・C#・Go・Java・JavaScript・Julia・MATLAB・Python・R・Ruby・Rust・Swift用の公式ライブラリーがあります。主流の言語で開発されているアプリケーションはArrowフォーマットでデータを送受信する機能をサポートできます。JDBCなどのいくつかデータベース接続APIでは特定の言語のランタイムを使わないといけませんが、Arrowフォーマットではそのような必要はありません。
-Arrowの汎用性により、実際のデータシステムを高速化する際の基本的な問題に対処できます。その問題とは、性能向上はシステムのボトルネックに律速するということです。この問題は[Amdahlの法則](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%A0%E3%83%80%E3%83%BC%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87){:target="_blank"}として知られています。実際のデータパイプラインでは、クエリー結果が複数のステージを流れることはよくあり、各ステージでシリアライズ・デシリアライズのオーバーヘッドがあります。たとえば、もし、あなたのデータパイプラインに5つのステージがあり、そのうちの4つのステージでシリアライズ・デシリアライズオーバーヘッドを取り除くことができたとしても、あなたのシステムは速くならないでしょう。なぜなら、残った1ステージのシリ�
��イズ・デシリアライズがパイプライン全体のボトルネックになるからです。
+Arrowの汎用性により、実際のデータシステムを高速化する際の基本的な問題に対処できます。その問題とは、性能向上はシステムのボトルネックに律速するということです。この問題は[Amdahlの法則](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%A0%E3%83%80%E3%83%BC%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87)として知られています。実際のデータパイプラインでは、クエリー結果が複数のステージを流れることはよくあり、各ステージでシリアライズ・デシリアライズのオーバーヘッドがあります。たとえば、もし、あなたのデータパイプラインに5つのステージがあり、そのうちの4つのステージでシリアライズ・デシリアライズオーバーヘッドを取り除くことができたとしても、あなたのシステムは速くならないでしょう。なぜなら、残った1ステージのシリアライズ・デ�
��アライズがパイプライン全体のボトルネックになるからです。
Arrowはどんな技術スタック上でも効率的に動くので、この問題の解決に役立ちます。たとえば、こんなデータフローがあったとしたらどうでしょう。NVIDIAのGPUを積んだワーカーを持つScalaベースの分散バックエンド→JettyベースのHTTPサーバー→Pyodideベースのブラウザーフロントエンドを持つNode.jsベースの機械学習フレームワークを使ってユーザーとやりとりするRailsベースの特徴量エンジニアリングアプリ。問題ありません。Arrowライブラリーはこれらのすべてのコンポーネント間のシリアライズ・デシリアライズオーバーヘッドを取り除けます。
@@ -121,13 +121,13 @@ Arrowはどんな技術スタック上でも効率的に動くので、この問
より多くの商用・オープンソースのツールがArrowに対応するにつれ、シリアライズ・デシリアライズのないあるいは少ない高速なクエリー転送がますます一般的になっています。現在では、多くのデータベース・データプラットフォーム・クエリーエンジンがArrowフォーマットでクエリー結果を転送できます。たとえば、Databricks・Dremio・Google
BigQuery・InfluxDB・Snowflake・Voltron Data Theseusといった商用プロダクトや、Apache
DataFusion・Apache Doris・Apache
Spark・ClickHouse・DuckDBといったオープンソースプロダクトがサポートしています。これにより大幅に高速化しています。
-- Apache Doris:
[「20倍から数百倍」高速化](https://doris.apache.org/blog/arrow-flight-sql-in-apache-doris-for-10x-faster-data-transfer){:target="_blank"}
-- Google BigQuery:
[最大「31倍高速化」](https://medium.com/google-cloud/announcing-google-cloud-bigquery-version-1-17-0-1fc428512171){:target="_blank"}
-- Dremio:
[「10倍以上高速化」](https://www.dremio.com/press-releases/dremio-announces-support-for-apache-arrow-flight-high-performance-data-transfer/){:target="_blank"}
-- DuckDB:
[「38倍」高速化](https://duckdb.org/2023/08/04/adbc.html#benchmark-adbc-vs-odbc){:target="_blank"}
-- Snowflake:
[「最大10倍」高速化](https://www.snowflake.com/en/blog/fetching-query-results-from-snowflake-just-got-a-lot-faster-with-apache-arrow/){:target="_blank"}
+- Apache Doris:
[「20倍から数百倍」高速化](https://doris.apache.org/blog/arrow-flight-sql-in-apache-doris-for-10x-faster-data-transfer)
+- Google BigQuery:
[最大「31倍高速化」](https://medium.com/google-cloud/announcing-google-cloud-bigquery-version-1-17-0-1fc428512171)
+- Dremio:
[「10倍以上高速化」](https://www.dremio.com/press-releases/dremio-announces-support-for-apache-arrow-flight-high-performance-data-transfer/)
+- DuckDB:
[「38倍」高速化](https://duckdb.org/2023/08/04/adbc.html#benchmark-adbc-vs-odbc)
+- Snowflake:
[「最大10倍」高速化](https://www.snowflake.com/en/blog/fetching-query-results-from-snowflake-just-got-a-lot-faster-with-apache-arrow/)
-データ受信側では、データを扱っている人はArrowベースのツール・ライブラリー・インターフェイス・プロトコルを使うことでこの高速化を最大化できます。2025年には、より多くのプロジェクトとベンダーが[ADBC](https://arrow.apache.org/adbc/){:target="_blank"}標準をサポートして、Arrowフォーマットでクエリー結果を受け取ることができるツールの数が増大するでしょう。
+データ受信側では、データを扱っている人はArrowベースのツール・ライブラリー・インターフェイス・プロトコルを使うことでこの高速化を最大化できます。2025年には、より多くのプロジェクトとベンダーが[ADBC](https://arrow.apache.org/adbc/)標準をサポートして、Arrowフォーマットでクエリー結果を受け取ることができるツールの数が増大するでしょう。
このシリーズの今後の記事を楽しみにしていてください。Arrowフォーマットと他のデータフォーマットを比較して、Arrowフォーマットで結果を取得するためにクライアントが使うことのできるプロトコルとAPIを説明します。
diff --git a/_posts/2025-01-10-arrow-result-transfer.md
b/_posts/2025-01-10-arrow-result-transfer.md
index fbadd73c47a..92cf0f1990b 100644
--- a/_posts/2025-01-10-arrow-result-transfer.md
+++ b/_posts/2025-01-10-arrow-result-transfer.md
@@ -43,7 +43,7 @@ _This is the first in a series of posts that aims to
demystify the use of Arrow
This is a question that data practitioners often ponder while waiting for
query results. It’s a question with many possible answers. Maybe your data
source is poorly partitioned. Maybe your SaaS data warehouse is undersized.
Maybe the query optimizer failed to translate your SQL statement into an
efficient execution plan.
-But surprisingly often, the answer is that you are using an inefficient
protocol to transfer query results to the client. In a [2017
paper](https://www.vldb.org/pvldb/vol10/p1022-muehleisen.pdf){:target="_blank"},
Mark Raasveldt and Hannes Mühleisen observed that query result transfer time
often dominates query execution time, especially for larger results. However,
the bottleneck is not where you might expect.
+But surprisingly often, the answer is that you are using an inefficient
protocol to transfer query results to the client. In a [2017
paper](https://www.vldb.org/pvldb/vol10/p1022-muehleisen.pdf), Mark Raasveldt
and Hannes Mühleisen observed that query result transfer time often dominates
query execution time, especially for larger results. However, the bottleneck is
not where you might expect.
Transferring a query result from a source to a destination involves three
steps:
@@ -53,11 +53,11 @@ Transferring a query result from a source to a destination
involves three steps:
In the era of slower networks, the transmission step was usually the
bottleneck, so there was little incentive to speed up the serialization and
deserialization steps. Instead, the emphasis was on making the transferred data
smaller, typically using compression, to reduce the transmission time. It was
during this era that the most widely used database connectivity APIs (ODBC and
JDBC) and database client protocols (such as the MySQL client/server protocol
and the PostgreSQL frontend/back [...]
-Yet many query results today continue to flow through legacy APIs and
protocols that add massive serialization and deserialization (“ser/de”)
overheads by forcing data into inefficient transfer formats. In a [2021
paper](https://www.vldb.org/pvldb/vol14/p534-li.pdf){:target="_blank"}, Tianyu
Li et al. presented an example using ODBC and the PostgreSQL protocol in which
99.996% of total query time was spent on ser/de. That is arguably an extreme
case, but we have observed 90% or higher in [...]
+Yet many query results today continue to flow through legacy APIs and
protocols that add massive serialization and deserialization (“ser/de”)
overheads by forcing data into inefficient transfer formats. In a [2021
paper](https://www.vldb.org/pvldb/vol14/p534-li.pdf), Tianyu Li et al.
presented an example using ODBC and the PostgreSQL protocol in which 99.996% of
total query time was spent on ser/de. That is arguably an extreme case, but we
have observed 90% or higher in many real-world c [...]
Enter Arrow.
-The Apache Arrow open source project defines a [data
format](https://arrow.apache.org/docs/format/Columnar.html){:target="_blank"}
that is designed to speed up—and in many cases eliminate—ser/de in query result
transfer. Since its creation in 2016, the Arrow format and the multi-language
toolbox built around it have gained widespread use, but the technical details
of how Arrow is able to slash ser/de overheads remain poorly understood. To
help address this, we outline five key attributes [...]
+The Apache Arrow open source project defines a [data
format](https://arrow.apache.org/docs/format/Columnar.html) that is designed to
speed up—and in many cases eliminate—ser/de in query result transfer. Since its
creation in 2016, the Arrow format and the multi-language toolbox built around
it have gained widespread use, but the technical details of how Arrow is able
to slash ser/de overheads remain poorly understood. To help address this, we
outline five key attributes of the Arrow form [...]
### 1. The Arrow format is columnar.
@@ -91,7 +91,7 @@ The Arrow format is self-describing and enforces type safety.
Furthermore, Arrow
A zero-copy operation is one in which data is transferred from one medium to
another without creating any intermediate copies. When a data format supports
zero-copy operations, this implies that its structure in memory is the same as
its structure on disk or on the network. So, for example, the data can be read
off the network directly into a usable structure in memory without performing
any intermediate copies or conversions.
-The Arrow format supports zero-copy operations. To hold sets of data values,
Arrow defines a column-oriented tabular data structure called a [record
batch](https://arrow.apache.org/docs/format/Columnar.html#serialization-and-interprocess-communication-ipc){:target="_blank"}.
Arrow record batches can be held in memory, sent over a network, or stored on
disk. The binary structure remains the same regardless of which medium a record
batch is on and which system generated it. To hold schemas [...]
+The Arrow format supports zero-copy operations. To hold sets of data values,
Arrow defines a column-oriented tabular data structure called a [record
batch](https://arrow.apache.org/docs/format/Columnar.html#serialization-and-interprocess-communication-ipc).
Arrow record batches can be held in memory, sent over a network, or stored on
disk. The binary structure remains the same regardless of which medium a record
batch is on and which system generated it. To hold schemas and other metadat
[...]
As a result of these design choices, Arrow can serve not only as a transfer
format but also as an in-memory format and on-disk format. This is in contrast
to text-based formats such as JSON and CSV and serialized binary formats such
as Protocol Buffers and Thrift, which encode data values using dedicated
structural syntax. To load data from these formats into a usable in-memory
structure, the data must be parsed and decoded. This is also in contrast to
binary formats such as Parquet and [...]
@@ -105,7 +105,7 @@ A streamable data format is one that can be processed
sequentially, one chunk at
CSV is an example of a streamable data format, because the column names (if
included) are in a header at the top of the file, and the lines in the file can
be processed sequentially. Parquet and ORC are examples of data formats that do
not enable streaming, because the schema and other metadata, which are required
to process the data, are held in a footer at the bottom of the file, making it
necessary to download the entire file (or seek to the end of the file and
download the footer sep [...]
-Arrow is a streamable data format. A dataset can be represented in Arrow as a
sequence of record batches that all have the same schema. Arrow defines a
[streaming
format](https://arrow.apache.org/docs/format/Columnar.html#ipc-streaming-format){:target="_blank"}
consisting of the schema followed by one or more record batches. A system
receiving an Arrow stream can process the record batches sequentially as they
arrive.
+Arrow is a streamable data format. A dataset can be represented in Arrow as a
sequence of record batches that all have the same schema. Arrow defines a
[streaming
format](https://arrow.apache.org/docs/format/Columnar.html#ipc-streaming-format)
consisting of the schema followed by one or more record batches. A system
receiving an Arrow stream can process the record batches sequentially as they
arrive.
<figure style="text-align: center;">
<img src="{{ site.baseurl
}}/img/arrow-result-transfer/part-1-figure-2-arrow-stream.png" width="100%"
class="img-responsive" alt="Figure 2: An illustration of an Arrow stream
transmitting data from a table with three columns. The first record batch
contains the values for the first three rows, the second record batch contains
the values for the next three rows, and so on. Actual Arrow record batches
might contain thousands to millions of rows.">
@@ -116,7 +116,7 @@ Arrow is a streamable data format. A dataset can be
represented in Arrow as a se
Arrow has emerged as a de facto standard format for working with tabular data
in memory. The Arrow format is a language-independent open standard. Libraries
are available for working with Arrow data in languages including C, C++, C#,
Go, Java, JavaScript, Julia, MATLAB, Python, R, Ruby, Rust, and Swift.
Applications developed in virtually any mainstream language can add support for
sending or receiving data in Arrow format. Data does not need to pass through a
specific language runtime, [...]
-Arrow’s universality allows it to address a fundamental problem in speeding up
real-world data systems: Performance improvements are inherently constrained by
a system’s bottlenecks. This problem is known as [Amdahl’s
law](https://www.geeksforgeeks.org/computer-organization-amdahls-law-and-its-proof/){:target="_blank"}.
In real-world data pipelines, query results often flow through multiple
stages, incurring ser/de overheads at each stage. If, for example, your data
pipeline has five sta [...]
+Arrow’s universality allows it to address a fundamental problem in speeding up
real-world data systems: Performance improvements are inherently constrained by
a system’s bottlenecks. This problem is known as [Amdahl’s
law](https://www.geeksforgeeks.org/computer-organization-amdahls-law-and-its-proof/).
In real-world data pipelines, query results often flow through multiple
stages, incurring ser/de overheads at each stage. If, for example, your data
pipeline has five stages and you elimin [...]
Arrow’s ability to operate efficiently in virtually any technology stack helps
to solve this problem. Does your data flow from a Scala-based distributed
backend with NVIDIA GPU-accelerated workers to a Jetty-based HTTP server then
to a Rails-powered feature engineering app which users interact with through a
Node.js-based machine learning framework with a Pyodide-based browser front
end? No problem; Arrow libraries are available to eliminate ser/de overheads
between all of those components.
@@ -124,13 +124,13 @@ Arrow’s ability to operate efficiently in virtually any
technology stack helps
As more commercial and open source tools have added support for Arrow, fast
query result transfer with low or no ser/de overheads has become increasingly
common. Today, commercial data platforms and query engines including
Databricks, Dremio, Google BigQuery, InfluxDB, Snowflake, and Voltron Data
Theseus and open source databases and query engines including Apache
DataFusion, Apache Doris, Apache Spark, ClickHouse, and DuckDB can all transfer
query results in Arrow format. The speedups a [...]
-- Apache Doris: [faster “by a factor ranging from 20 to several
hundreds”](https://doris.apache.org/blog/arrow-flight-sql-in-apache-doris-for-10x-faster-data-transfer){:target="_blank"}
-- Google BigQuery: [up to “31x
faster”](https://medium.com/google-cloud/announcing-google-cloud-bigquery-version-1-17-0-1fc428512171){:target="_blank"}
-- Dremio: [“more than 10 times
faster”](https://www.dremio.com/press-releases/dremio-announces-support-for-apache-arrow-flight-high-performance-data-transfer/){:target="_blank"}
-- DuckDB: [“38x”
faster](https://duckdb.org/2023/08/04/adbc.html#benchmark-adbc-vs-odbc){:target="_blank"}
-- Snowflake: [“up to a 10x”
faster](https://www.snowflake.com/en/blog/fetching-query-results-from-snowflake-just-got-a-lot-faster-with-apache-arrow/){:target="_blank"}
+- Apache Doris: [faster “by a factor ranging from 20 to several
hundreds”](https://doris.apache.org/blog/arrow-flight-sql-in-apache-doris-for-10x-faster-data-transfer)
+- Google BigQuery: [up to “31x
faster”](https://medium.com/google-cloud/announcing-google-cloud-bigquery-version-1-17-0-1fc428512171)
+- Dremio: [“more than 10 times
faster”](https://www.dremio.com/press-releases/dremio-announces-support-for-apache-arrow-flight-high-performance-data-transfer/)
+- DuckDB: [“38x”
faster](https://duckdb.org/2023/08/04/adbc.html#benchmark-adbc-vs-odbc)
+- Snowflake: [“up to a 10x”
faster](https://www.snowflake.com/en/blog/fetching-query-results-from-snowflake-just-got-a-lot-faster-with-apache-arrow/)
-On the receiving side, data practitioners can maximize speedups by using
Arrow-based tools and Arrow libraries, interfaces, and protocols. In 2025, as
more projects and vendors implement support for the
[ADBC](https://arrow.apache.org/adbc/){:target="_blank"} standard, we expect to
see accelerating growth in the number of tools that can receive query results
in Arrow format.
+On the receiving side, data practitioners can maximize speedups by using
Arrow-based tools and Arrow libraries, interfaces, and protocols. In 2025, as
more projects and vendors implement support for the
[ADBC](https://arrow.apache.org/adbc/) standard, we expect to see accelerating
growth in the number of tools that can receive query results in Arrow format.
Stay tuned for upcoming posts in this series, which will compare the Arrow
format to other data formats and describe the protocols and APIs that clients
can use to fetch results in Arrow format.
