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_r338906627
 
 

 ##########
 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アプリケーションではネットワークの帯域がボトルネックになるだろうと言えます。
 
 Review comment:
   そんな感じにしました!

----------------------------------------------------------------
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

Reply via email to