更高效的利用Jupyter+pandas進(jìn)行數(shù)據(jù)分析,6種常用數(shù)據(jù)格式效率對(duì)比!

在使用Python進(jìn)行數(shù)據(jù)分析時(shí),Jupyter Notebook是一個(gè)非常強(qiáng)力的工具,在數(shù)據(jù)集不是很大的情況下,我們可以使用pandas輕松對(duì)txt或csv等純文本格式數(shù)據(jù)進(jìn)行讀寫(xiě)。
然而當(dāng)數(shù)據(jù)集的維度或者體積很大時(shí),將數(shù)據(jù)保存并加載回內(nèi)存的過(guò)程就會(huì)變慢,并且每次啟動(dòng)Jupyter Notebook時(shí)都需要等待一段時(shí)間直到數(shù)據(jù)重新加載, 這樣csv格式或任何其他純文本格式數(shù)據(jù)都失去了吸引力。
本文將對(duì)pandas支持的多種格式數(shù)據(jù)在處理數(shù)據(jù)的不同方面進(jìn)行比較,包含I/O速度、內(nèi)存消耗、磁盤(pán)占用空間等指標(biāo),試圖找出如何為我們的數(shù)據(jù)找到一個(gè)合適的格式的辦法!
? 格式說(shuō)明
現(xiàn)在對(duì)本文進(jìn)行對(duì)比的幾種數(shù)據(jù)格式進(jìn)行說(shuō)明。
CSV:最常用的數(shù)據(jù)格式Pickle:用于序列化和反序列化Python對(duì)象結(jié)構(gòu)MessagePack:類(lèi)似于json,但是更小更塊HDF5:一種常見(jiàn)的跨平臺(tái)數(shù)據(jù)儲(chǔ)存文件Feather:一個(gè)快速、輕量級(jí)的存儲(chǔ)框架Parquet:Apache Hadoop的列式存儲(chǔ)格式
? 指標(biāo)說(shuō)明
為了找到格式來(lái)存儲(chǔ)數(shù)據(jù),本文選擇以下指標(biāo)進(jìn)行對(duì)比。
size_mb:帶有序列化數(shù)據(jù)幀的文件的大小save_time:將數(shù)據(jù)幀保存到磁盤(pán)所需的時(shí)間load_time:將先前轉(zhuǎn)儲(chǔ)的數(shù)據(jù)幀加載到內(nèi)存所需的時(shí)間save_ram_delta_mb:在數(shù)據(jù)幀保存過(guò)程中最大的內(nèi)存消耗增長(zhǎng)load_ram_delta_mb:數(shù)據(jù)幀加載過(guò)程中最大的內(nèi)存消耗增長(zhǎng)
注意,當(dāng)我們使用有效壓縮的二進(jìn)制數(shù)據(jù)格式(例如Parquet)時(shí),最后兩個(gè)指標(biāo)變得非常重要。它們可以幫助我們估算加載串行化數(shù)據(jù)所需的RAM數(shù)量,以及數(shù)據(jù)大小本身。我們將在下一部分中更詳細(xì)地討論這個(gè)問(wèn)題。
? 對(duì)比
現(xiàn)在開(kāi)始對(duì)前文介紹的5種數(shù)據(jù)格式進(jìn)行比較,為了更好地控制序列化的數(shù)據(jù)結(jié)構(gòu)和屬性我們將使用自己生成的數(shù)據(jù)集。
下面是生成測(cè)試數(shù)據(jù)的代碼,我們隨機(jī)生成具有數(shù)字和分類(lèi)特征的數(shù)據(jù)集。數(shù)值特征取自標(biāo)準(zhǔn)正態(tài)分布。分類(lèi)特征以基數(shù)為C的uuid4隨機(jī)字符串生成,其中2 <= C <= max_cat_size。
def?generate_dataset(n_rows,?num_count,?cat_count,?max_nan=0.1,?max_cat_size=100):
????dataset,?types?=?{},?{}
????
????def?generate_categories():
????????from?uuid?import?uuid4
????????category_size?=?np.random.randint(2,?max_cat_size)
????????return?[str(uuid4())?for?_?in?range(category_size)]
????
????for?col?in?range(num_count):
????????name?=?f'n{col}'
????????values?=?np.random.normal(0,?1,?n_rows)
????????nan_cnt?=?np.random.randint(1,?int(max_nan*n_rows))
????????index?=?np.random.choice(n_rows,?nan_cnt,?replace=False)
????????values[index]?=?np.nan
????????dataset[name]?=?values
????????types[name]?=?'float32'
????????
????for?col?in?range(cat_count):
????????name?=?f'c{col}'
????????cats?=?generate_categories()
????????values?=?np.array(np.random.choice(cats,?n_rows,?replace=True),?dtype=object)
????????nan_cnt?=?np.random.randint(1,?int(max_nan*n_rows))
????????index?=?np.random.choice(n_rows,?nan_cnt,?replace=False)
????????values[index]?=?np.nan
????????dataset[name]?=?values
????????types[name]?=?'object'
????
????return?pd.DataFrame(dataset),?types
現(xiàn)在我們以CSV文件保存和加載的性能作為基準(zhǔn)。將五個(gè)隨機(jī)生成的具有百萬(wàn)個(gè)觀測(cè)值的數(shù)據(jù)集轉(zhuǎn)儲(chǔ)到CSV中,然后讀回內(nèi)存以獲取平均指標(biāo)。并且針對(duì)具有相同行數(shù)的20個(gè)隨機(jī)生成的數(shù)據(jù)集測(cè)試了每種二進(jìn)制格式。
同時(shí)使用兩種方法進(jìn)行對(duì)比:
1.將生成的分類(lèi)變量保留為字符串 2.在執(zhí)行任何I/O之前將其轉(zhuǎn)換為pandas.Categorical數(shù)據(jù)類(lèi)型
1.以字符串作為分類(lèi)特征
下圖顯示了每種數(shù)據(jù)格式的平均I/O時(shí)間。這里有趣的發(fā)現(xiàn)是hdf的加載速度比csv更低,而其他二進(jìn)制格式的性能明顯更好,而feather和parquet則表現(xiàn)的非常好
保存數(shù)據(jù)并從磁盤(pán)讀取數(shù)據(jù)時(shí)的內(nèi)存消耗如何?下一張圖片向我們展示了hdf的性能再次不那么好。但可以肯定的是,csv不需要太多額外的內(nèi)存來(lái)保存/加載純文本字符串,而feather和parquet則非常接近
最后,讓我們看一下文件大小的對(duì)比。這次parquet顯示出非常好的結(jié)果,考慮到這種格式是為有效存儲(chǔ)大量數(shù)據(jù)而開(kāi)發(fā)的,也是理所當(dāng)然
2.對(duì)特征進(jìn)行轉(zhuǎn)換
在上一節(jié)中,我們沒(méi)有嘗試有效地存儲(chǔ)分類(lèi)特征,而是使用純字符串,接下來(lái)我們使用專(zhuān)用的pandas.Categorical類(lèi)型再次進(jìn)行比較。
從上圖可以看到,與純文本csv相比,所有二進(jìn)制格式都可以顯示其真強(qiáng)大功能,效率遠(yuǎn)超過(guò)csv,因此我們將其刪除以更清楚地看到各種二進(jìn)制格式之間的差異。
可以看到feather和pickle擁有最快的I/O速度,接下來(lái)該比較數(shù)據(jù)加載過(guò)程中的內(nèi)存消耗了。下面的條形圖顯示了我們之前提到的有關(guān)parquet格式的情況
為什么parquet內(nèi)存消耗這么高?因?yàn)橹灰诖疟P(pán)上占用一點(diǎn)空間,就需要額外的資源才能將數(shù)據(jù)解壓縮回?cái)?shù)據(jù)幀。即使文件在持久性存儲(chǔ)磁盤(pán)上需要適度的容量,也可能無(wú)法將其加載到內(nèi)存中。
最后我們看下不同格式的文件大小比較。所有格式都顯示出良好的效果,除了hdf仍然需要比其他格式更多的空間。
? 結(jié)論
正如我們的上面的測(cè)試結(jié)果所示,feather格式似乎是在多個(gè)Jupyter之間存儲(chǔ)數(shù)據(jù)的理想選擇。它顯示出很高的I/O速度,不占用磁盤(pán)上過(guò)多的內(nèi)存,并且在裝回RAM時(shí)不需要任何拆包。
當(dāng)然這種比較并不意味著我們應(yīng)該在每種情況下都使用這種格式。例如,不希望將feather格式用作長(zhǎng)期文件存儲(chǔ)。此外,當(dāng)其他格式發(fā)揮最佳效果時(shí),它并未考慮所有可能的情況。所以我們也需要根據(jù)具體情況進(jìn)行選擇!
-END-
來(lái)源:towardsdatascience、GitHub等?
編譯:劉早起(有刪改)
點(diǎn)擊閱讀原文,3折購(gòu)好書(shū)?
