kou commented on a change in pull request #36: ARROW-6943: [Website] Translate
Apache Arrow Flight introduction to Japanese
URL: https://github.com/apache/arrow-site/pull/36#discussion_r338918128
##########
File path: _posts/2019-09-30-introducing-arrow-flight-japanese.md
##########
@@ -0,0 +1,172 @@
+---
+layout: post
+title: "Apache Arrow Flightの紹介：高速データトランスポートフレームワーク"
+description: "この記事ではArrow
Flightという高速データサービスを構築するためのフレームワークを紹介します。この1.5年、Flightの開発を進めてきました。Flightの開発者・利用者を探しています。"
+date: "2019-10-13 00:00:00 -0600"
+author: wesm
+categories: [application,translation]
+---
+<!--
+{% comment %}
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements. See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to you under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License. You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+{% endcomment %}
+-->
+
+[原文（English）]({% post_url 2019-09-30-introducing-arrow-flight %})
+
+この1.5年、Apache
Arrowコミュニティーは**Flight**の設計と実装を進めてきました。Flightは高速なデータトランスポートを実現するための新しいクライアント・サーバー型のフレームワークです。Flightを使うと大きなデータセットをネットワーク越しにトランスポートする処理を簡単に実現できます。Flightは特定用途向けに設計されたものではないため、幅広い用途で利用できます。
+
+Flightの実装は、まず、[gRPC][1]を使ったArrow列指向フォーマット（つまり「Arrowレコードバッチ」）のトランスポートの最適化に注力しました。gRPCはGoogleが開発しているHTTP/2ベースのRPCライブラリー・フレームワークで、広く利用されています。gRPCも特定用途向けではなく幅広い用途で使えるように設計されています。これまでFlightをgRPCベースで実装することに注力してきましたが、gRPCでだけ使えるようにしたいわけではありません。
+
+Flightと他のデータトランスポートフレームワークとの大きな違いは並列転送機能です。クライアントとサーバークラスター間で同時にデータをストリームで転送できます。この機能により、簡単にスケーラブルなデータサービスを開発できます。スケーラブルなデータサービスとはクライアント数が増えても大丈夫なサービスです。
+
+Apache Arrow 0.15.0でC++（Pytonバインディングあり）とJavaでFlightを使えるようになっています。
現時点ではベータユーザー向けです。ベータユーザーとはFlight内部の低レベルの改良によりAPIやプロトコルが変わっても適応できるユーザーのことです。
+
+## モチベーション
+
+多くの人がネットワーク越しに大きなデータセットにアクセスすることに関して困っています。リモートのデータサービスからデータセットを読むためのさまざまな転送プロトコルやツールがたくさんあります。たとえばODBCやJDBCです。この10年、ファイルベースでデータを保管することが多くなりました。このときにはCSVやAvroやParquetといったフォーマットがよく使われます。しかし、この方法ではデシリアライズする前に生データをローカルのホストに転送しなければいけないという問題があります。
+
+Apache
Arrowの初期からやってきた作業によりさまざまな方法でデータトランスポートを加速できます。[Arrow列指向フォーマット][2]には次の重要な機能があります。
+
+* 表形式データの「転送用の」表現です。この表現はデータ受信側でデシリアライズが必要ありません。
+*
標準で「バッチをストリーム送信」するためのモードがあります。このモードでは、大きなデータセットを複数の行ごとにまとめて転送します。（Arrowの用語では「レコードバッチ」と呼んでいます。）この記事では「データストリーム」について話します。データストリームとはApache
Arrowプロジェクトのバイナリープロトコルを使った一連のArrowレコードバッチです。
+*
このフォーマットはプログラミング言語に依存していません。このフォーマットは現在11のプログラミング言語がサポートしています。サポートしているプログラミング言語は増え続けています。
+
+ODBCのような標準的なプロトコルの各実装は、通常、それぞれ独自の転送用バイナリープロトコルを実装します。これらのプロトコルは各ライブラリーの公開インターフェイスの表現と相互に変換しなければいけません。ODBC・JDBCライブラリーのパフォーマンスは場合によって大きく異なります。
+
+私たちのFlightの設計で目指していることは、データサービス用の新しいプロトコルを作ることです。このプロトコルは転送用のデータ表現にも開発者向けの公開APIにもArrow列指向フォーマットを使います。こうすることで、データトランスポート関連のシリアライズコストを減らし、分散データシステム全体を効率化できます。さらに、すでに別の用途にApache
Arrowを使っているシステム間では非常に効率的にデータをやりとりできます。
+
+## Flightの基礎
+
+Arrow
Flightライブラリーはデータストリームを送受信できるサービスを実装するための開発者向けフレームワークを提供します。Flightサーバーは次の基本的なリクエストをサポートしています。
+
+*
**Handshake**：クライアントが認証済みかを確認するシンプルなリクエスト。いくつかのケースでは、以降のリクエストのために実装依存のセッショントークンを確立します。
+* **ListFlights**：利用可能なデータストリームのリストを返します。
+* **GetSchema**：データストリームのスキーマを返します。
+*
**GetFlightInfo**：対象のデータセット用の「アクセスプラン」を返します。複数のデータストリームを消費しなければいけないかもしれません。このリクエストにはシリアライズしたカスタムコマンドを含めることができます。たとえば、アプリケーション固有のパラメーターを含めることができます。
+* **DoGet**：クライアントにデータストリームを送信します。
+* **DoPut**: クライアントからデータストリームを受信します。
+* **DoAction**：実装依存のアクションを実行し、結果を返します。つまり、一般的な関数呼び出しです。
+* **ListActions**：利用可能なアクションの種類を返します。
+
+gRPCの「双方向の」ストリーミングサポート（[HTTP/2ストリーミング][9]上に実装されています）を活用して、リクエスト処理中でもデータとメタデータをクライアント・サーバー間でやりとりできます。
+
+単純なFlightの構成は1台のサーバーとそのサーバーに接続し`DoGet`リクエストをするクライアントという構成です。
+
+<div align="center">
+<img src="{{ site.baseurl }}/img/20191014_flight_simple.png"
+ alt="Flight Simple Architecture"
+ width="50%" class="img-responsive">
+</div>
+
+## gRPCごしのデータスループットの最適化
+
+gRPCには多くの利点があります。それらはGoogleが多数の問題を解決したからです。そのような幅広い用途で活用できるgRPCのようなメッセージングライブラリーを使っていますが、大きなデータセットのトランスポートの性能改善にはいくつかの処理を改善する必要がありました。多くのgRPCユーザーは比較的小さなメッセージしか扱っていないからです。
+
+一番よくサポートされているgRPCを使う方法はサービスを[Protocol
Buffers][3]（「Protobuf」と呼ばれることもあります）の`.proto`ファイルで定義する方法です。gRPCのProtobufプラグインはgRPCサービスのスタブを生成します。このスタブを使ってアプリケーションを実装します。RPCコマンドとデータメッセージは[Protobufワイヤーフォーマット][4]を使ってシリアライズします。なぜならFlightでは「普通のgRPCとProtocol
Buffers」を使っているからです。Arrow列指向フォーマットのことを知らないgRPCクライアントでもFlightサービスとやりとりできます。そのようなgRPCクライアントはArrowデータの中身を気にせずに処理します。
+
+Flightの中の主要なデータ関連のProtobufの型は`FlightData`と呼ばれています。一般的にProtobufメッセージの読み書きにはコストがかかります。そのため、C++でもJavaでもgRPCにいくつか次のような低レベルの最適化を実装しています。
+
+*
`FlightData`用のProtobufワイヤーフォーマットを生成します。`FlightData`には送信対象のArrowレコードバッチが含まれていますが、メモリーコピー・シリアライズ処理は一切ありません。
+*
Protobufで表現された`FlightData`からメモリーコピー・デシリアライズ処理なしでArrowレコードバッチを再構築できます。実際には、Protocol
Bufersライブラリーにエンコードされたデータペイロードを触らせないようにしています。
+
+Protobufを使うがProtobufのメッセージパースのオーバーヘッドはなくしたいという両立できない2つのことを両立させようとしているということです。Flight実装は上述の最適化をして高速化しています。素のgRPCクライアントでもFlightサービスとやりとりできますが、素のgRPCクライアントにはこのような最適化はないので、Protobufライブラリーを使って`FlightData`をデシリアライズすることになります。そのため、素のgRPCクライアントを使うといくらか性能が落ちます。
+
+FlightのC++実装でのデータスループットベンチマークの結果での絶対的な性能ですが、ローカルホスト上の終端間のTCPスループットは2-3GB/sを上回っていました。ただし、TLSは無効にした状態です。このベンチマークは約4秒で12GBのデータを転送できることを示しています。
+
+
+```shell
+$ ./arrow-flight-benchmark --records_per_stream 100000000
+Bytes read: 12800000000
+Nanos: 3900466413
+Speed: 3129.63 MB/s
+```
+
+この結果から、FlightとgRPCを使うと相対的にオーバーヘッドはあるが、多くの実際のFlightアプリケーションではネットワークの帯域がボトルネックになるだろうと言えます。
+
+## 水平方向のスケーラビリティ：並列データアクセスとパーティション化したデータアクセス
+
+分散型のデータベースシステムの多くは「コーディネーター」を通してクライアントのリクエストを処理するアーキテクチャーパターンを使っています。クライアントへのデータセットを複数回転送するという明らかに効率に課題がある点はさておき、巨大なデータセットへのアクセスに対するスケーラビリティの問題もあります。
+
+Flightで次のようなシステムを作れるようにしました。それはこのようなボトルネックに取り組まずに水平方向にスケーラブルなデータサービスを作れるシステムです。`GetFlightInfo`
RPCを使ったクライアントのリクエストは **エンドポイント** のリストを返します。返ってくる各エンドポイントにはサーバーの位置と **チケット**
の情報が入っています。チケットはデータセットの一部を取得する`DoGet`リクエストに入れてサーバーに送ります。データセット全体にアクセスするためにはすべてのエンドポイントを処理する必要があります。Flightのストリームは順番に処理する必要はありませんが、順番に処理するための仕組みは用意しています。その仕組みとはアプリケーション固有のメタデータを使えるという仕組みです。順序の情報はメタデータで表現できます。
+
+この複数エンドポイントパターンにはたくさんの利点があります。
+
+* 複数のクライアントが複数のエンドポイントから並行にデータを読み込めます。
+*
`GetFlightInfo`「プランニング」リクエストを提供するサービスは兄弟サービスに処理を移譲できます。これにより、データの局所性の利点を得られたり、単純にロードバランスしやすくなったりします。
+*
分散したクラスター中のノードは異なる役割を引き受けることができます。たとえば、クラスター内の一部のノードはクエリープランニングに責任を持つかもしれません。一方、他のノードはデータストリームリクエスト（`DoGet`または`DoPut`）だけを処理するかもしれません。
+
+次の図はサービスの役割を分けた複数ノードアーキテクチャーの例です。
+
+<div align="center">
+<img src="{{ site.baseurl }}/img/20191014_flight_complex.png"
+ alt="Flight Complex Architecture"
+ width="60%" class="img-responsive">
+</div>
+
+## アクション：アプリケーション固有のロジックでFlightを拡張
+
+`GetFlightInfo`リクエストはデータセットをリクエストするときにシリアライズしたコマンドを透過的に送ることができますが、クライアントはデータストリームの送受信以外の操作をサーバーに依頼できなければいけないかもしれません。たとえば、クライアントは特定のデータセットをメモリー上に「ピン止め」することを要求するかもしれません。ピン止めすることで他のクライアントからの後続のリクエストを高速に処理できます。
+
+Flightサービスは追加で「アクション」を定義できます。アクションは`DoAction`
RPCで実行できます。アクションリクエストには実行したいアクションの名前と追加情報が入っています。追加情報は省略可能です。アクションの結果はgRPCストリームです。このgRPCストリーム中には任意の結果を入れられます。
+
+いくつかアクションの例を紹介します。
+
+* メタデータを見つけるアクション。組み込みの`ListFlights`
RPCでも提供されている機能ですが、`ListFlights`の機能で不十分な場合はアクションで実現できます。
+* セッション固有のパラメーターを設定するアクション。
+
+サーバーはアクションを1つも実装しなくてもよいことに注意してください。また、アクションは結果を返さなくてもよいです。
+
+## 暗号化と認証
+
+Flightは組み込みで暗号化をサポートしています。gRPCの組み込みのTLS/OpenSSLの機能を使っています。
+
+クライアント側・サーバー側ともに拡張可能な認証ハンドラーがあります。この認証ハンドラーを使えば、ユーザーとパスワードのようなシンプルな認証スキーマも使えますし、ケルベロスのような複雑な認証も使えます。Flightプロトコルには組み込みの`BasicAuth`機能がついています。そのため、追加の開発なしでそのままユーザーとパスワードの認証を実現できます。
+
+## ミドルウェアとトレース
+
+gRPCには「インターセプター」というコンセプトがあります。インターセプターを使うと開発者が定義した「ミドルウェア」を開発できます。ミドルウェアは届いたリクエストと送るリクエストを計装する方法を提供します。このような計装用フレームワークに[OpenTracing][6]があります。
+
+ミドルウェアの機能は最近Flightに追加された機能です。そのため、今のところはmasterブランチでしか使えません。
+
+## gRPCを使っているがgRPCだけではない
+
+`DoGet`リクエストでサーバーの位置を指定する方法にはRFC
3986準拠のURIを使っています。たとえば、TLSを使ったgRPCは`grpc+tls://$HOST:$PORT`というように指定します。
+
+Flightサーバーの「コマンド」レイヤーにgRPCを使っているのは妥当だと思っていますが、[RDMA][7]のようなTCP以外のデータトランスポート層もサポートしたくなるかもしれません。設計・開発時間が必要になりますが、おそらく、TCP以外のプロトコル上でデータを転送するときでもgRPCを使えるでしょう。
+
+## はじめかたと今後の話
+
+Flightユーザー向けのドキュメントは作成中です。しかし、このライブラリーはベータユーザー向けには十分に使い物になります。ベータユーザーとは今後1年で発生するだろう軽微なAPI・プロトコルの変更に耐えられるユーザーです。
+
+Flightをためす簡単な方法はPython
APIを使う方法です。なぜならカスタムサーバーもカスタムクライアントもすべてPythonだけで定義できるからです。なにもコンパイルする必要はありません。Arrowのコードにある[PythonでのFlightクライアントとサーバーの例][8]を参考にできます。
+
+実際に使っている例もあります。Dremioは[Arrow
Flightベースの][10]コネクターを開発しました。このコネクターは[ODBCよりも20-50倍よい性能を発揮する][11]ことを示しました。ArrowのコントリビューターであるRyan
MurrayはApache Sparkユーザー向けにFlight対応エンドポイントに接続する[データソース実装][12]を作りました。
+
+最後に今後の話をします。gRPCではない（あるいはTCPではない）データトランスポートをサポートできないか研究開発を進めるかもしれません。ユーザーが使うFlight対応サービスをたくさん開発します。Flightは開発フレームワークなので、ユーザーが使うAPIは高レベルなAPIだけになるようにするつもりです。高レベルなAPIではFlightの詳細と特定のFlightアプリケーションに関連する詳細を隠します。
Review comment:
なるほど！↓にしておきました。
Flightの開発が進むとユーザーが使えるFlight対応サービスが増えていくでしょう。
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
