web-dev-qa-db-ja.com

スキーマをavroに保存する利点は何ですか？

Solrおよびhadoopに入れるために、いくつかのデータをシリアル化する必要があります。

同じためにシリアル化ツールを評価しています。

リストの上位2つは、GsonとAvroです。

私の知る限り、Avro = Gson + Schema-In-JSON

それが正しい場合、AvroがSolr/Hadoopでそれほど人気が​​ある理由がわかりませんか？

私はインターネットでたくさん検索しましたが、これに対する単一の正しい答えを見つけることができません。

どこに言っても、Avroはスキーマを格納するので優れています。私の質問は、そのスキーマをどうするかです。

単一のオブジェクトが複数のファイルブロックに格納されているHadoopの非常に大きなオブジェクトに適している場合があります。これにより、各部分にスキーマを格納すると、オブジェクトの分析が向上します。ただし、その場合でも、スキーマは個別に格納でき、スキーマへの参照だけでスキーマを記述できます。スキーマがありとあらゆる部分に含まれるべき理由はありません。

誰かが私に与えることができる場合Avroが彼らを助けたいくつかの良いユースケースとGson/Jacksonが目的には不十分でした、それは本当に役に立ちます。

また、Avroサイトの公式ドキュメントによると、AvroがSchema + Dataを生成できるようにするには、Avroにスキーマを提供する必要があります。私の質問は、スキーマが入力され、データのJSON表現と同じものが出力に送信される場合、Avroによってどのような追加機能が実現されるのですか？ JSONを使用してオブジェクトをシリアル化し、入力スキーマを追加してそれをAvroと呼んで、自分でそれを行うことはできませんか？

私はこれと本当に混乱しています！

javaapachehadoopsolravro
23
user2250246
  1. 進化するスキーマ

最初に、このようなスキーマをEmployeeクラス用に設計したとします。

{
{"name": "emp_name", "type":"string"},
{"name":"dob", "type":"string"},
{"name":"age", "type":"int"}
}

後で、年齢は冗長であることを理解し、スキーマから削除しました。

{
{"name": "emp_name", "type":"string"},
{"name":"dob", "type":"string"}
}

このスキーマが変更される前にシリアル化されて保存されたレコードはどうですか。それらの記録をどのように読み戻しますか？

これが、avroリーダー/デシリアライザーがリーダーとライターのスキーマを要求する理由です。内部的には、スキーマ解決を行います。古いスキーマを新しいスキーマに適合させようとします。

このリンクに移動- http://avro.Apache.org/docs/1.7.2/api/Java/org/Apache/avro/io/parsing/doc-files/parsing.html -セクション「アクションシンボルを使用した解決」

この場合、アクションはスキップされます。つまり、「年齢」の読み取りは省略されます。フィールドのintからlongへの変更などのケースも処理できます。

これはスキーマの進化を説明するとても素晴らしい記事です http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html

  1. スキーマは、複数のレコードに対して1つのファイルに1回だけ保存されます。

  2. 非常に数バイトでエンコードされたサイズ。

8
Vishal John

スキーマの進化によって解決された重要な問題の1つはどこにも明示的に言及されていないと思います。そのため、新規参入者は非常に混乱しています。

例はこれを明確にします：

銀行がそのすべてのトランザクションの監査ログを保存するとします。ログには特定の形式があり、少なくとも10年間保存する必要があります。また、これらのログを保持するシステムが、これらの10年間すべてで進化するフォーマットに適応することが非常に望ましいです。

このようなエントリのスキーマはそれほど頻繁には変更されません。平均して年に2回としましょう。ただし、各スキーマには多数のエントリがあります。スキーマを追跡しない場合は、しばらくしてから、非常に古いコードを調べて、その時点で存在するフィールドを特定し、さまざまな形式を処理するためのif-elseステートメントを追加し続ける必要があります。これらのすべての形式のスキーマストアでは、スキーマ進化機能を使用して、ある種類の形式を別の形式に自動的に変換できます（Avroは、古いスキーマと新しいスキーマを提供する場合、これを自動的に行います）。これにより、アプリケーションはコードに大量のif-elseステートメントを追加する必要がなくなり、格納されているスキーマのセットを確認することですべてのフォーマットが簡単にわかるため、管理しやすくなります（スキーマは通常、別のストレージに格納され、データには、そのスキーマを指すIDのみがあります）。

スキーマの進化のもう1つの利点は、新しい形式のプロデューサーが、下流のコンシューマーが最初に変更するのを待たずに、新しいスキーマでオブジェクトを安全に作成できることです。ダウンストリームコンシューマは、新しい形式に関連付けられた新しいスキーマを表示できない限り、処理を一時停止するロジックを組み込むことができます。この自動停止は、システムをオンラインに保ち、処理ロジックを新しいスキーマに適合させるのに最適です。

したがって、要約すると、スキーマの進化は、新しいクライアントが自動フォーマット変換を利用して古いフォーマットを読み取るのに役立ち、古いクライアントが新しいフォーマットを理解できるようになるまで、正常な方法で処理を一時停止するのにも役立ちます。

5
user2250246