使用hadoop序列化機制時的一點小問題

2021-08-26 17:28:50 字數 582 閱讀 5240

其實在現在接觸到的資料處理中還沒怎麼碰到到需要自己實現序列化物件的情況。偶然看到一篇文章,說的是由於偷懶而造成序列化和反序列化時造成的不必要的時間和空間消耗。其實如果自己遇到這種問題,應該也會使用同樣偷懶的方法。這裡說明一下,以便提醒自己要這麼做時,是否考慮到了效能方面的問題。

@override

public void write(dataoutput out) throws ioexception

作者在寫乙個writable類時,因為這個類有太多的成員變數(because it had a ton of instance variables),所以索性將這個類先放到乙個位元組陣列中,然後再將此陣列和陣列長度寫出去。這麼做固然減少了相當的**量,但可能帶來的是效能方面的損耗。

作者做了個測試,序列化乙個位元組陣列用了953位元組,而直接序列化變數則只用了296位元組。而且正確的序列化方法使乙個有1600條記錄的sequencefile從1.4gb壓縮到了825mb。

在時間消耗方面,序列化object用了7.2ms,反序列化用了1.7ms。而用stream i/o則序列化只用了76000ns,反序列化用了58000ns。

hadoop的序列化機制

1.緊湊 高效使用儲存空間。2.快速 讀寫資料的額外開銷小 3.可擴充套件 可透明地讀取老格式的資料 4.互操作 支援多語言的互動 hadoop的序列化格式 writable 例 long對應longwritable 序列化在分布式環境的兩大作用 有時候,使用hadoop自帶的一些writable序...

Spring Feign 序列化機制

spring cloud封裝feign,直接使用spring mvc註解以及httpmessageconverters來序列化。在declarative rest client feign中有這麼一段話 大致意思是,feignclient註解上可以指定configuration屬性,但是對於指定的c...

使用序列化和反序列化機制深度複製物件

由於值型別和引用型別在賦值上的不同。在clone乙個物件的引用型別的成員時,一般只是簡單的賦值對物件的引用。此時原有的物件和新賦值的物件會同時引用同乙個成員物件。這種物件clone的方法一般稱為淺賦值或淺表複製。在大多數情況下淺賦值並不是我們希望的clone方式。為了實現深度複製,我們就必須遍歷有相...