【Message Queue - Kafka疑難雜症】Schema being registered is incomp

閱讀時間約 7 分鐘
raw-image


相信對於這一篇感興趣的朋友們都已經玩過kafka的Schema Registry了吧! 沒玩過得朋友也沒關係, 歡迎至「【🔒Message Queue - Kafka】傳輸訊息的標準格式制定者 Schema Registry」了解一下這是什麼玩意兒, 好了, 廢話不多說, 讓我們直接切入主題吧!


我們根據 【🔒Message Queue - Kafka】傳輸訊息的標準格式制定者 Schema Registry 提供的範例, 進行Producer的執行之後, 接著我們因為需求的變更需要增加一個欄位, 因此在「avro_producer.py」調整了schema如下:

 schema = """
{
"name": "Payment",
"type": "record",
"fields": [
{
"name": "id",
"type": "string"
},
{
"name": "amount",
"type": "double"
},
{
"name": "currency",
"type": "string",
}
]
}
"""


接著再執行一次「avro_producer.py」, 就發生了以下的訊息:

confluent_kafka.schema_registry.error.SchemaRegistryError: 
Schema being registered is incompatible with an earlier schema for subject "avro_test-value",
details: [
{
errorType:'READER_FIELD_MISSING_DEFAULT_VALUE',
description:'The field 'currency' at path '/fields/2' in the new schema has no default value and is missing in the old schema',
additionalInfo:'currency'
},
{
oldSchemaVersion: 1
},
{
oldSchema: '{"type":"record","name":"Payment","fields":[{"name":"id","type":"string"},{"name":"amount","type":"double"}]}'},
{
validateFields: 'false',
compatibility: 'BACKWARD'}
] (HTTP status code 409, SR code 409)


這個錯誤訊息主要告訴我們schema的兼容性出了問題, 但究竟為什麼呢? kafka的Schema Registry不是號稱很彈性, 容易擴充嗎? 怎麼今天一擴充下去就GG了呢😢 ?


讓我們再仔細看看內容, 發現到這樣的關鍵字:

 new schema has no default value and is missing in the old schema


這意思就是我們新的Schema欄位並沒有「預設值」, 因此很容易發生向後兼容的問題, 建議我們設計個「預設值」才能夠讓新的Schema成功更新。


讓我們重新調整一下Schema, 對於新欄位「currency」設定「default」值即可:

schema = """
{
"name": "Payment",
"type": "record",
"fields": [
{
"name": "id",
"type": "string"
},
{
"name": "amount",
"type": "double"
},
{
"name": "currency",
"type": "string",
"default": "null"
}
]
}
"""


最後我們重新執行一下「avro_producer.py 」。

raw-image



非常棒👍👍👍 成功了!!!


錯誤訊息關鍵字

  • Schema being registered is incompatible
  • ValueError: no value and no default


結語

仔細的觀察每一條訊息的內文, 我們都能夠從中找出蛛絲馬跡, 再請試著搭配一些AI技巧, 可以讓我們的問題排查速度變得更快, 這篇我們要推薦您閱讀一下「【🔒 江湖一點訣】年中復盤 - AI 潮流下的學習模式轉變與升級」, 幫助您提升效率, 精準的解決問題!

111會員
251內容數
哈囉,我是阿Han,是一位 👩‍💻 軟體研發工程師,喜歡閱讀、學習、撰寫文章及教學,擅長以圖代文,化繁為簡,除了幫助自己釐清思路之外,也希望藉由圖解的方式幫助大家共同學習,甚至手把手帶您設計出高品質的軟體產品。
留言0
查看全部
發表第一個留言支持創作者!
阿Han的沙龍 的其他內容
為什麼要用Docker安裝? Docker是一個容器化平台, 就類似於我們早期虛擬機的VMWare、Virtual Box…等, 虛擬機平台一般, 只是面向的是伺服端, 供企業快速、簡單、輕量的佈署開發完成的程式軟體, 並將相關的環境依賴皆封裝成一包所謂的映像檔(image), 透過這樣的方式減少因
對於軟體世界中Message Queue有興趣的朋友可以先閱讀這一篇「【資訊軟體知識】井然有序的處理機制 - Message Queue」建立基礎知識之後,再來看看這一篇會更容易進入情境唷! 這次就進入我們一般常見的MQ軟體「RabbitMQ」, 我們先以圖示來了解RabbitMQ的模型架構, 之後
雖然我們的一般的狀況下我們都希望訊息能夠按照順序被處理, 但有時候我們仍希望某些重要的訊息能夠優先被處理,也就是插隊的概念,正好RabbitMQ也有提供這樣需求的解決方案,以下是需要知道的幾個重點。 宣告Queue的時候必須要設定 x-max-priority, 通常10就夠用了。 數字越大優先序越
在進入Message Queue之前我們先來了解一下同步/非同步任務的概念。 菜單稱為訊息(Message), 為工作內容描述。 送出菜單的客人稱為生產者(Producer), 負責建立訊息。 櫃台就相當於Queue, 負責接單並依序處理。 廚師就是消費者的概念, 負責消化Queue裡面的訊息。 採
軟體世界隨著現實應用越來越複雜,需要處理的資料量也就隨之倍數增長,假設我們每一個動作都要等待處理完畢後再回應,那麼勢必對於廣大用戶的使用者體驗大打折扣,因此這個過程如果有一個中間人幫我們處理掉先來後到的流程,那麼是不是我只要將要進行的動作交給中間人即可,而背後處理的服務商則透過中間人依序處理,處理
AMQP協議 Advanced Message Queuing Portocol(高級訊息佇列協議) Producer: 生產者, 負責生產訊息並送到交換機。 Broker: Message Queue的服務器(RabbitMQ…之類的產品) Exchange: 交換器, 它指定訊息
為什麼要用Docker安裝? Docker是一個容器化平台, 就類似於我們早期虛擬機的VMWare、Virtual Box…等, 虛擬機平台一般, 只是面向的是伺服端, 供企業快速、簡單、輕量的佈署開發完成的程式軟體, 並將相關的環境依賴皆封裝成一包所謂的映像檔(image), 透過這樣的方式減少因
對於軟體世界中Message Queue有興趣的朋友可以先閱讀這一篇「【資訊軟體知識】井然有序的處理機制 - Message Queue」建立基礎知識之後,再來看看這一篇會更容易進入情境唷! 這次就進入我們一般常見的MQ軟體「RabbitMQ」, 我們先以圖示來了解RabbitMQ的模型架構, 之後
雖然我們的一般的狀況下我們都希望訊息能夠按照順序被處理, 但有時候我們仍希望某些重要的訊息能夠優先被處理,也就是插隊的概念,正好RabbitMQ也有提供這樣需求的解決方案,以下是需要知道的幾個重點。 宣告Queue的時候必須要設定 x-max-priority, 通常10就夠用了。 數字越大優先序越
在進入Message Queue之前我們先來了解一下同步/非同步任務的概念。 菜單稱為訊息(Message), 為工作內容描述。 送出菜單的客人稱為生產者(Producer), 負責建立訊息。 櫃台就相當於Queue, 負責接單並依序處理。 廚師就是消費者的概念, 負責消化Queue裡面的訊息。 採
軟體世界隨著現實應用越來越複雜,需要處理的資料量也就隨之倍數增長,假設我們每一個動作都要等待處理完畢後再回應,那麼勢必對於廣大用戶的使用者體驗大打折扣,因此這個過程如果有一個中間人幫我們處理掉先來後到的流程,那麼是不是我只要將要進行的動作交給中間人即可,而背後處理的服務商則透過中間人依序處理,處理
AMQP協議 Advanced Message Queuing Portocol(高級訊息佇列協議) Producer: 生產者, 負責生產訊息並送到交換機。 Broker: Message Queue的服務器(RabbitMQ…之類的產品) Exchange: 交換器, 它指定訊息
你可能也想看
Google News 追蹤
Thumbnail
本專欄將提供給您最新的市場資訊、產業研究、交易心法、精選公司介紹,以上內容並非個股分析,還請各位依據自身狀況作出交易決策。歡迎訂閱支持我,獲得相關內容,也祝您的投資之路順遂! 每年 $990 訂閱方案👉 https://reurl.cc/VNYVxZ 每月 $99 訂閱方案👉https://re
Thumbnail
我們在「【Message Queue - Kafka】串流時代的超入門簡介」有介紹到關於Kafka的基礎概念, 那麼本章節主要著重於生產者(Producer)的面向來細部探討, 看看生產者(Producer)究竟是什麼? 有哪些應該要注意的? 我們今天的主題除了說明生產者(Producer)的
Thumbnail
我們在學習kafka的過程中最不習慣的就是不管什麼樣的資料, 在kafka的傳輸過程都會是binary的資料格式, 因此我們在撰寫程式的過程中並不是那麼的直觀, 必須將資料從float、int…資料型態轉型成binary才能順利傳送, 那麼基於這樣的前提之下, python這套程式語言可以怎麼做
Thumbnail
我們在「【Message Queue - Kafka】不斷的試誤…, 用Docker來嘗試安裝Kafka」有介紹如何架設kafka, 其中我們使用環境變數來進行kafka的配置, 但除了環境變數之外, 其實還能夠用檔案配置的方式來對kafka進行配置, 如此一來我們就可以將配置檔與啟動檔完全分開,
Thumbnail
KSQL引擎, 串流形式的SQL? 聽了應該霧煞煞吧! 想像一下傳統的SQL, 是不是一個指令一個動作, 每發送一個指令之後就必須等到查詢/寫入…動作皆完成之後才回應, 然而在Streaming的應用上這顯然不太可行, 每分每秒都有資料流入的情境下, 資料的狀態都在變化, 假設我們一個指令一個動作,
Thumbnail
情境描述 我們在「🔒 阿Han的軟體心法實戰營 - kafka」有關於kafka的教學文章, 那麼在開發過程中我們遇到了 👻 詭異事件, 那就是我們嘗試在做一個檔案串流時, 發現Producer明明傳送了大約16MB檔案大小的封包到kafka, 每一包約(1024 * 1024 ) bytes
Thumbnail
為什麼會有Schema Registry的出現? 因為Kafka的零拷貝原則, 也就是kafka本身並不會去碰觸到訊息也不進行資料驗證, 而是bypass的傳送, 預設都以位元組來傳輸資料會比較有效率, 但位元組誰看得懂啊...。 加上Kafka的特性是生產者與消費者並不能直接溝通, 因
Thumbnail
連接器故名思議就是兩個系統之間的橋樑, 而Kafka Connect正是扮演著這樣的角色, 如圖上, 我們可以透過Kafka Connect將SQL的資料導出到Kafka並導入到MySQL。 豐富的Plugin Confluent Hub提供了各式各樣的外掛套件, 包括了MongoDB、My
Thumbnail
本專欄將提供給您最新的市場資訊、產業研究、交易心法、精選公司介紹,以上內容並非個股分析,還請各位依據自身狀況作出交易決策。歡迎訂閱支持我,獲得相關內容,也祝您的投資之路順遂! 每年 $990 訂閱方案👉 https://reurl.cc/VNYVxZ 每月 $99 訂閱方案👉https://re
Thumbnail
我們在「【Message Queue - Kafka】串流時代的超入門簡介」有介紹到關於Kafka的基礎概念, 那麼本章節主要著重於生產者(Producer)的面向來細部探討, 看看生產者(Producer)究竟是什麼? 有哪些應該要注意的? 我們今天的主題除了說明生產者(Producer)的
Thumbnail
我們在學習kafka的過程中最不習慣的就是不管什麼樣的資料, 在kafka的傳輸過程都會是binary的資料格式, 因此我們在撰寫程式的過程中並不是那麼的直觀, 必須將資料從float、int…資料型態轉型成binary才能順利傳送, 那麼基於這樣的前提之下, python這套程式語言可以怎麼做
Thumbnail
我們在「【Message Queue - Kafka】不斷的試誤…, 用Docker來嘗試安裝Kafka」有介紹如何架設kafka, 其中我們使用環境變數來進行kafka的配置, 但除了環境變數之外, 其實還能夠用檔案配置的方式來對kafka進行配置, 如此一來我們就可以將配置檔與啟動檔完全分開,
Thumbnail
KSQL引擎, 串流形式的SQL? 聽了應該霧煞煞吧! 想像一下傳統的SQL, 是不是一個指令一個動作, 每發送一個指令之後就必須等到查詢/寫入…動作皆完成之後才回應, 然而在Streaming的應用上這顯然不太可行, 每分每秒都有資料流入的情境下, 資料的狀態都在變化, 假設我們一個指令一個動作,
Thumbnail
情境描述 我們在「🔒 阿Han的軟體心法實戰營 - kafka」有關於kafka的教學文章, 那麼在開發過程中我們遇到了 👻 詭異事件, 那就是我們嘗試在做一個檔案串流時, 發現Producer明明傳送了大約16MB檔案大小的封包到kafka, 每一包約(1024 * 1024 ) bytes
Thumbnail
為什麼會有Schema Registry的出現? 因為Kafka的零拷貝原則, 也就是kafka本身並不會去碰觸到訊息也不進行資料驗證, 而是bypass的傳送, 預設都以位元組來傳輸資料會比較有效率, 但位元組誰看得懂啊...。 加上Kafka的特性是生產者與消費者並不能直接溝通, 因
Thumbnail
連接器故名思議就是兩個系統之間的橋樑, 而Kafka Connect正是扮演著這樣的角色, 如圖上, 我們可以透過Kafka Connect將SQL的資料導出到Kafka並導入到MySQL。 豐富的Plugin Confluent Hub提供了各式各樣的外掛套件, 包括了MongoDB、My