pydata BLAZE 項目的發展方向在哪里？

Question

我發現 blaze 生態系統* 令人驚嘆，因為它涵蓋了大部分數據工程用例。 在 2015-2016 年期間，這些項目肯定有很多興趣，但最近卻被忽略了。 我說這是看 github 存儲庫上的提交。

所以我對社區的問題是

- 2016 年發生了什么導致失去興趣？

- 是否有其他基於 python 的庫取代了 blaze？

火焰生態系統：

• Blaze：查詢不同存儲系統數據的接口
• Dask：通過任務調度和阻塞算法進行並行計算
• Datashape：一種數據描述語言
• DyND：一個用於動態多維數組的 C++ 庫
• Odo：不同存儲系統之間的數據遷移

參考資料： http ://blaze.pydata.org/

Answer 1

我可以給出部分圖片，盡管其他部分涉及更多。 Blaze 既是一個將數據工程思想孵化到已發布的 oss 包中的傘式項目，也是一個專注於數據幀符號操作並將其轉換為各種后端執行引擎（尤其是數據庫服務）的包本身。 至關重要的是，Blaze 想成為解決范圍非常廣泛的問題的（開始）解決方案，特別是翻譯層變得非常龐大且難以維護，並且試圖迎合所有問題。 限制了符號層可以提供的操作范圍。

就傘式項目而言，Blaze 是成功的。 許多始於 Blaze 的想法滲透到生態系統中。 Blaze 最突出的單個項目可能是 Dask，雖然它最初計划作為 Blaze 的執行層，但它實現了一個更大的數據幀操作 API，以及其他高級集合和任意圖形操作。 甚至完全符號化的優化也存在於 Dask 中，盡管這可能不那么完整。 其他 Anaconda 穩定的項目，如 numba 和 bokeh 都受到了 Blaze 的影響，但我不會在這里談論它們。

就 datashape/dynd 而言，這是一個有點擁擠的空間，有許多其他相關項目（xnd、uarray 等）和可以粗略地認為是“numpy 2”（即，更全面、更靈活地表示復雜數據）的想法布局及其描述）。 這還沒有真正被社區采用，幾乎所有東西都使用 numpy 的類型系統（箭頭在內部做的事情是一個明顯的例外）。

最后，對於數據格式和 Odo，我鼓勵您考慮Intake ，它可以看作是繼承者，它可以提供更多的功能，例如數據源編目，它通過將操作范圍限制在讀取端來實現。 Odo 的大型交互網絡也是一個難以維護的多對多問題，通過使事情變得更簡單，Intake 希望成為數據加載庫的實際層和描述位置的主要方式，數據的描述和參數化。 不過，Odo 並沒有死，所以如果文件轉換正是您所需要的，您仍然可以使用它。

Answer 2

我一直在尋找一個類似於 odo 的項目，用於將 csv 數據加載到各種來源。 一個 odo 問題 ( https://github.com/blaze/odo/issues/614 ) 推薦了 d6tstack ，目前似乎正在維護。

在實踐中，滾動您自己的 csv 加載器通常同樣容易，在這種情況下， tableschema項目非常方便。 它自動從 csv 文件推斷數據類型。