7

我发现 blaze 生态系统* 令人惊叹，因为它涵盖了大多数数据工程用例。在 2015-2016 年期间，这些项目肯定有很多兴趣，但最近被忽略了。我这样说是看 github repos 上的提交。

所以我对社区的问题是

- 2016 年发生了什么导致失去兴趣的事情？

- 是否有其他基于 python 的库已经取代了 blaze？

火焰生态系统：

  • Blaze：在不同存储系统上查询数据的接口
  • Dask：通过任务调度和阻塞算法进行并行计算
  • Datashape：一种数据描述语言
  • DyND：用于动态多维数组的 C++ 库
  • Odo：不同存储系统之间的数据迁移

参考资料： http ://blaze.pydata.org/

4

2 回答 2

4

我可以给出图片的一部分，尽管其他人更多地参与其中。Blaze 既是一个将数据工程思想孵化到已发布的 oss 包中的伞式项目，也是一个专注于数据帧的符号操作并将其转换为各种后端执行引擎，尤其是数据库服务的包本身。至关重要的是，Blaze 想要成为解决非常广泛问题的（开始）解决方案！特别是，翻译层变得非常大且难以维护，并且通过试图迎合所有人，限制了符号层可以提供的操作范围。

就总体项目而言，Blaze 是成功的。许多从 Blaze 开始的想法都渗透到了生态系统中。Blaze 中最突出的单个项目可能是 Dask，虽然最初计划作为 Blaze 的执行层，但它实现了更大的数据帧操作 API，以及其他高级集合和任意图形操作。Dask 中甚至存在完全象征性的优化，尽管这可能并不完整。其他 Anaconda-stable 项目，如 numba 和 bokeh 受到 Blaze 努力的影响，但我不会在这里讨论它们。

就 datashape/dynd 而言，这是一个有点拥挤的空间，有许多其他相关项目（xnd、uarray 等）和可以松散地认为是“numpy 2”的想法（即，更全面、更灵活地表示复杂数据布局及其描述）。这还没有真正被社区采用，几乎所有东西都使用 numpy 的类型系统（箭头在内部做的明显例外）。

最后，对于数据格式和 Odo，我鼓励您考虑Intake，它可以看作是继任者，它可以提供更多功能，例如数据源编目，它通过将操作范围限制为读取端来实现这一点。Odo 的大交互网络也是一个多对多问题，变得难以维护，通过保持简单，Intake 希望成为数据加载库的事实上的层和描述位置的主要方式，数据的描述和参数化。不过，Odo 并没有死，所以如果文件转换正是您需要的，您仍然可以使用它。

于 2018-12-06T15:03:49.320 回答
0

我正在寻找一个类似于 odo 的项目，用于将 csv 数据加载到各种来源。一个 odo 问题 ( https://github.com/blaze/odo/issues/614 ) 推荐了 d6tstack，目前似乎已得到维护。

在实践中，滚动您自己的 csv 加载器通常同样容易，在这种情况下，tableschema项目非常方便。它自动从 csv 文件推断数据类型。

于 2020-04-05T23:10:22.310 回答