動機

我們花費大量的時間將數(shù)據(jù)從普通的交換格式(比如CSV)，遷移到像數(shù)組、數(shù)據(jù)庫或者二進制存儲等高效的計算格式。更糟糕的是，許多人沒有將數(shù)據(jù)遷移到高效的格式，因為他們不知道怎么(或者不能)為他們的工具管理特定的遷移方法。

你所選擇的數(shù)據(jù)格式很重要，它會強烈地影響程序性能(經(jīng)驗規(guī)律表明會有10倍的差距)，以及那些輕易使用和理解你數(shù)據(jù)的人。

當提倡Blaze項目時，我經(jīng)常說：“Blaze能幫助你查詢各種格式的數(shù)據(jù)。”這實際上是假設你能夠將數(shù)據(jù)轉換成指定的格式。

進入into項目

into函數(shù)能在各種數(shù)據(jù)格式之間高效的遷移數(shù)據(jù)。這里的數(shù)據(jù)格式既包括內存中的數(shù)據(jù)結構，比如：

列表、集合、元組、迭代器、numpy中的ndarray、pandas中的DataFrame、dynd中的array，以及上述各類的流式序列。

也包括存在于Python程序之外的持久化數(shù)據(jù)，比如：

CSV、JSON、行定界的JSON，以及以上各類的遠程版本

HDF5 (標準格式與Pandas格式皆可)、 BColz、 SAS、 SQL 數(shù)據(jù)庫 ( SQLAlchemy支持的皆可)、 Mongo

into項目能在上述數(shù)據(jù)格式的任意兩個格式之間高效的遷移數(shù)據(jù)，其原理是利用一個成對轉換的網(wǎng)絡(該文章底部有直觀的解釋)。

如何使用它

into函數(shù)有兩個參數(shù)：source和target。它將數(shù)據(jù)從source轉換成target。source和target能夠使用如下的格式：

Target???? Source???? Example

Object??? Object????? A particular DataFrame or list

String???? String????? ‘file.csv', ‘postgresql://hostname::tablename'

Type?????????????????? Like list or pd.DataFrame

所以，下邊是對into函數(shù)的合法調用：

?

Note that into is a single function. We're used to doing this with various to_csv, from_sql methods on various types. The into api is very small; Here is what you need in order to get started:

注意，into函數(shù)是一個單一的函數(shù)。雖然我們習慣于在各種類型上使用to_csv, from_sql等方法來完成這樣的功能，但接口into非常簡單。開始使用into函數(shù)前，你需要：

?

在Github上查看into工程。

實例

現(xiàn)在我們展示一些更深層次的相同的實例。

將Python中的list類型轉換成numpy中的array類型

?

加載CSV文件，并轉換成Python中的list類型

?

將CSV文件轉換成JSON格式

?

將行定界的JSON格式轉換成Pandas中的DataFrame格式

?

它是如何工作的？

格式轉換是有挑戰(zhàn)性的。任意兩個數(shù)據(jù)格式之間的健壯、高效的格式轉換，都充滿了特殊情況和奇怪的庫。常見的解決方案是通過一個通用格式，例如DataFrame或流內存列表、字典等，進行格式轉換。(見dat)或者通過序列化格式，例如ProtoBuf或Thrift，進行格式轉換。這些都是很好的選擇，往往也是你想要的。然而有時候這樣的轉換是比較慢的，特別是當你在實時計算系統(tǒng)上轉換，或面對苛刻的存儲解決方案時。

考慮一個例子，在numpy.recarray和pandas.DataFrame之間進行數(shù)據(jù)遷移。我們可以非常快速地，適當?shù)剡w移這些數(shù)據(jù)。數(shù)據(jù)的字節(jié)不需要更改，只更改其周圍的元數(shù)據(jù)即可。我們不需要將數(shù)據(jù)序列化到一個交換格式，或轉換為中間的純Python對象。

考慮從CSV文件遷移數(shù)據(jù)到一個PostgreSQL數(shù)據(jù)庫。通過SQLAlchemy(注：一個Python環(huán)境下的數(shù)據(jù)庫工具箱)使用Python迭代器，我們的遷移速度不太可能超過每秒2000條記錄。然而使用PostgreSQL自帶的CSV加載器，我們的遷移速度可以超過每秒50000條記錄。花費一整晚的時間和花費一杯咖啡的時間進行數(shù)據(jù)遷移，是有很大區(qū)別的。然而這需要我們在特殊情況下，能足夠靈活的使用特殊代碼。

專門的兩兩互換工具往往比通用解決方案快一個數(shù)量級。

Into項目是那些成對地數(shù)據(jù)遷移組成的一個網(wǎng)絡。我們利用下圖展示這個網(wǎng)絡：

每個節(jié)點是一種數(shù)據(jù)格式。每個定向的邊是一個在兩種數(shù)據(jù)格式之間轉換數(shù)據(jù)的函數(shù)。into函數(shù)的一個調用，可能會遍歷多個邊和多個中間格式。例如，當我們將CSV文件遷移到Mongo數(shù)據(jù)庫時，我們可以采取以下路徑：

?將CSV文件加載到DataFrame中(利用pandas.read_csv)

?然后轉換為np.recarray(利用DataFrame.to_records)

?接著轉換為一個Python的迭代器類型(利用np.ndarray.tolist)

?最終轉換成Mongo中的數(shù)據(jù)(利用pymongo.Collection.insert)

或者我們可以使用MongoDB自帶的CSV加載器，編寫一個特殊函數(shù)，用一個從CSV到Mongo的定向邊縮短整個處理過程。

為了找到最有效的路線，我們利用相對成本(引入權重的ad-hoc)給這個網(wǎng)絡的所有邊賦予權重值。然后我們使用networkx找到最短路徑，進而進行數(shù)據(jù)遷移。如果某個邊由于某種原因失敗了(引發(fā)NotImplementedError)，我們可以自動重新尋找路徑。這樣我們的遷移方法是既高效又健壯的。

注意，我們給某些節(jié)點涂上紅色。這些節(jié)點的數(shù)據(jù)量可以大于內存。當我們在兩個紅色節(jié)點之間進行數(shù)據(jù)遷移時(輸入和輸出的數(shù)據(jù)量都可能大于內存)，我們限制我們的路徑始終在紅色子圖中，以確保遷移路徑中間的數(shù)據(jù)不會溢出。需要注意的一種格式是chunks(…)，例如chunks(DataFrame)是一個可迭代的，在內存中的DataFrames。這個方便的元格式允許我們在大數(shù)據(jù)上使用緊湊的數(shù)據(jù)結構，例如numpy的arrays和pandas的DataFrames，同時保持在內存中數(shù)據(jù)的只有幾十兆字節(jié)。

這種網(wǎng)絡化的方法允許開發(fā)者對于特殊情況編寫專門的代碼，同時確信這段代碼只在正確的情況下使用。這種方法允許我們利用一個獨立的、可分離的方式處理一個非常復雜的問題。中央調度系統(tǒng)讓我們保持頭腦清醒。

歷史

很久以前，我寫過into鏈接到Blaze的文章，然后我立即就沉默了。這是因為舊的實現(xiàn)方法(網(wǎng)絡方法之前)很難擴展或維護，也沒有準備好進入其黃金期。

我很滿意這個網(wǎng)絡。意想不到的應用程序經(jīng)常能夠正常運行，into工程現(xiàn)在也準備好進入其黃金期了。Into工程可以通過conda和pip得到，而獨立于Blaze。它主要的依賴為NumPy、Pandas和NetworkX，所以對于閱讀我博客的大部分人來說，它算是相對輕量級的。如果你想利用一些性能更好的格式，例如HDF5，你將同樣需要安裝這些庫(pro-tip，使用conda安裝)。

如何開始使用into函數(shù)

你應該下載一個最近版本的into工程。

?

然后你可能想要通過該教程的上半部分，或者閱讀該文檔。

又或者不閱讀任何東西，只是試一試。我的希望是，這個接口很簡單(只有一個函數(shù)！)，用戶可以自然地使用它。如果你運行中出現(xiàn)了問題，那么我很愿意在blaze-dev@continuum.io中聽到它們。

總結

以上是生活随笔為你收集整理的python处理数据的包_在Python中利用Into包整洁地进行数据迁移的教程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。