iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 13
1
AI & Data

資料工程師修煉之路系列 第 13

[Day 13] Encoding and Evolution(1)

Everything changes and nothing stands still.
—Heraclitus of Ephesus, as quoted by Plato in Cratylus (360 BCE)

上面那段話是書中的引言,數據系統無可避免的需要改變,我們在 Day 3 時有介紹過 Evolvability (進化能力) ,我們設計的系統應該讓改變變的簡單;當資料格式或 schema 有變更時,相對應系統的新版本程式應該要同時部署且執行,然而,在大型的數據系統中,程式變更是不會立即發生的:

  • 於 server-side 部署系統時,你會希望執行 rolling upgrade (滾動式升級),意思為一次只部署新版本的程式到小量的機器上,讓系統能持續運作,且能做到服務不斷線,因此就能鼓勵更密集的釋出新版本程式,讓系統更有 evolvability (進化能力)。

  • 在 client-side,你只能希望 user 能更新應用軟體,所以會有一群沒同步更新應用軟體的 user。

這意味著舊的程式跟新的程式要並行,代表系統要同時:

  • Backward compatibility (向前兼容)

    新程式要能讀舊程式寫入的資料。

  • Forward compatibility (向後兼容)

    舊程式要能讀新程式寫入的資料。

向前兼容很好理解,你在寫與新 schema 有關的程式時就會一併考慮舊的資料該怎麼讀取,向後兼容就有點 tricky 了,代表你的程式要能忽略所有未來可能加入的額外資訊或欄位。

在往後幾天會介紹數個資料編碼方式,包含 JSON, XML, Protocol Buffers, Thrift 和 Avro,然後也會看該如何兼容,最後則會提到資料溝通模式,像 REST, RPC, 訊息佇列。

Format for Encoding Data

資料在程式中通常會以 2 種方式表達 (最少 2 種) :

  • 在記憶體中,資料會以物件、陣列、hash table、樹等等的方式儲存,感謝許多大神,這些資料結構的操作存取是以 CPU 最佳化方模式設計。
  • 當你寫入資料到檔案或透過網路傳遞資料,你必須轉成一連串的位元組,不同的資料結構會讓結果看起來不一樣。

所以,我們必須有某種翻譯方法讓程式得以在這 2 種方式中做切換,從記憶體中的資料結構翻譯成連續的位元組稱為 encoding (編譯),也可稱 serialization (序列化) 或 marshalling (編組);反之稱做 decoding (解譯),也可稱 parsing, deserializationunmarshalling,接下來就來介紹各種不同的 encoding 格式啦!

Language-Specific Format

顧名思義,就是每個程式語言內建的 encoding 格式啦,比如 Java 就是 java.io.Serializable,Ruby 是 Marshal,Python 是 pickle ,除此之外還有其他第三方 library 提供,例如 Java 的 Kryo,這些 encoding 方式看起來方便,但可能會有以下幾個問題:

  • 程式語言被限制住了,例如你很難用 Java 去讀 Python encoding 後的 pickle 檔案。
  • 資料版本通常是後來的想法,當你想快速完成 encoding 工作時,就會忽略了未來向前和向後兼容的問題。
  • 執行效率也是,例如 Java 內建的 serialization 執行效率就很不好

所以正常工程師會選擇其他的 encoding 格式。

然後,為了敘述方便,其他的 encdoing 格式就明天介紹啦!

我們公司只有在做 POC 專案的時候才會考慮用 Language-Specific Format,在正式開發時會全部替換掉,畢竟你不能圖一時的方便然後讓未來的工程想來砍你,有時寫程式時會想像未來接手的工程師都是喪心病狂的瘋子 XD


上一篇
[Day 12] Storage and Retrieval(5) - Column-Oriented Storage
下一篇
[Day 14] Encoding and Evolution(2) - Json, XMO, CSV 和 Binary variants (二進制變體)
系列文
資料工程師修煉之路30

尚未有邦友留言

立即登入留言