22

私は Kafka メッセージを生成/消費するために Kafka スキーマ レジストリを使用しています。たとえば、次のような疑似スキーマの両方の文字列型である 2 つのフィールドがあります。</p> 

{"name": "test1", "type": "string"}
{"name": "test2", "type": "string"}

しかし、しばらく送信して消費した後、スキーマを変更して2番目のフィールドを長いタイプに変更する必要があり、次の例外がスローされました:

Schema being registered is incompatible with an earlier schema; error code: 409

スキーマ レジストリがスキーマのアップグレード/変更を進化させることができない場合、なぜスキーマ レジストリを使用する必要があるのか​​、または Avro を使用する理由を説明する必要があるのか​​ わかりません。

4

4 に答える 4

22

BACKWARD互換モードではフィールドの名前を変更できません。回避策として、スキーマ レジストリの互換性ルールを変更できます。

ドキュメントによると：

スキーマ レジストリ サーバーは、新しいスキーマがサブジェクトに登録されるときに、特定の互換性ルールを適用できます。現在、次の互換性ルールがサポートされています。

下位互換性 (デフォルト):新しいスキーマは、以前のすべてのスキーマで書き込まれたデータを読み取るために使用できる場合、下位互換性があります。下位互換性は、最新のスキーマを使用して常にすべてのバージョンのデータをクエリできるため、Hadoop などのシステムにデータをロードする場合に役立ちます。

前方互換性: 新しいスキーマは 、以前のすべてのスキーマがこのスキーマに書き込まれたデータを読み取ることができる場合、前方互換性があります。上位互換性は、常に最新バージョンであるとは限らない特定のバージョンのデータのみを処理できるコンシューマ アプリケーションに役立ちます。

完全な互換性:下位互換性と上位互換性の両方がある場合、新しいスキーマは完全に互換性があります。

互換性なし:新しいスキーマは、有効な Avro である限り、任意のスキーマにすることができます。

に設定compatibilityするNONEとうまくいくはずです。

# Update compatibility requirements globally
$ curl -X PUT -H "Content-Type: application/vnd.schemaregistry.v1+json" \
    --data '{"compatibility": "NONE"}' \
    http://localhost:8081/config

そして、応答は

{"compatibility":"NONE"}

NONE私は一般的に、絶対に必要でない限り、件名で互換性を設定することを思いとどまらせます。

于 2018-04-13T05:42:34.353 に答える