Hive（avroテーブル）をスキーマレジストリに統合する方法は？

Question

Hiveは、Avroスキーマを定義できる2つのテーブルプロパティを提供します。avro.schema.literalおよびavro.schema.url（前者は、スキーマを処理するhdfsパスまたはhttpエンドポイントを指定できます）。私は自分のスキーマサービスとしてSchema Registryを使用したいのですが、問題が大きなJSONオブジェクトに包まれたそのendpoints戻りスキーマです：

要求：

GET /schemas/ids/1 

応答：

HTTP/1.1 200 OK 
Content-Type: application/vnd.schemaregistry.v1+json 

{ 
    "schema": "{\"type\": \"string\"}" 
} 

リクエスト：

GET /subjects/test/versions/1 

応答：

HTTP/1.1 200 OK 
Content-Type: application/vnd.schemaregistry.v1+json 

{ 
    "name": "test", 
    "version": 1, 
    "schema": "{\"type\": \"string\"}" 
} 

上記の応答はHiveによって解析できません。

Answer 1

これまでのところ、スキーマレジストリ（純粋なavroスキーマを扱う）の前にプロキシサービスを置いて、HAProxyでスケールすることを考えました。スキーマレジストリ自体には、読み取りのためにscalable architectureがあるようです。

からスキーマにアクセスするためのURLを指定：正直に言うと私はAvroSerDe hive documentationでavro.schema.urlプロパティに関する段落が理解していません。 httpスキーマの場合、この はテスト用および小規模クラスタ用に機能しますが、スキーマがジョブの各タスクから少なくとも1回はアクセスされるため、 はURLプロバイダに対するDDoS攻撃になります。ウェブ サーバーなど）。 にこのパラメータを使用する場合は、テスト以外の設定には注意してください。

私の提案は実行可能な解決策だと思います。

スキーマを中央リポジトリに保存すると、スキーマの進化と後方/前方互換性の確認が可能になるため、AvroSerDeのドキュメントで推奨されているhdfsパスを定義するよりも優れています。

Answer 2

私はあなたと同じことをやっています。私はhttps://github.com/confluentinc/schema-registry/issues/629を記録して、これを簡単にするためにスキーマレジストリを強化しました。うまくいけば、プロジェクトはこの考えを受け入れてくれることを願っています。それは実装するための単純な拡張でなければならないようです。