dask - pydata BLAZE 项目的方向在哪里？

Question

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

所以我对社区的问题是

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

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

火焰生态系统:

Blaze:查询不同存储系统数据的接口(interface)

Dask:通过任务调度和阻塞算法进行并行计算

Datashape:一种数据描述语言

DyND:用于动态多维数组的 C++ 库

Odo:不同存储系统之间的数据迁移

引用:
http://blaze.pydata.org/

Answer 1

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

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

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

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