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 的类型系统（arrow 内部所做的值得注意的例外）。

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