pydata BLAZE 项目的发展方向在哪里？
Where is the pydata BLAZE project heading?
我发现 blaze 生态系统* 很棒，因为它涵盖了大部分数据工程用例。在 2015-2016 年期间，这些项目肯定有很多兴趣，但最近却被忽略了。我说的是看 github 回购协议上的提交。
所以我向社区提出的问题是
- 2016 年发生了什么导致失去兴趣？
- 是否有其他基于 python 的库取代了 blaze？
blaze 生态系统：
- Blaze：查询不同存储系统数据的接口
- Dask：通过任务调度和分块算法进行并行计算
- Datashape：一种数据描述语言
- DyND：一个用于动态多维数组的 C++ 库
- Odo：不同存储系统之间的数据迁移
参考资料：
http://blaze.pydata.org/
我可以给出部分图片，尽管其他部分涉及更多。
Blaze 既是一个将数据工程思想孵化到已发布的 oss 包中的伞式项目，也是一个专注于数据帧符号操作并将其转换为各种后端执行引擎（尤其是数据库服务）的包本身。至关重要的是，Blaze 想成为解决范围非常广泛的问题的（开始）解决方案！特别是，翻译层变得非常庞大且难以维护，并且试图迎合所有人，限制了符号层可以提供的操作范围。
就伞式项目而言，Blaze 是成功的。许多始于 Blaze 的想法渗透到生态系统中。 Blaze 最突出的单个项目可能是 Dask，虽然它最初计划作为 Blaze 的执行层，但实现了更大的 API 数据帧操作，以及其他高级集合和任意图形操作。 Dask 中甚至存在完全符号化的优化，尽管这可能不那么完整。其他 Anaconda 稳定的项目，如 numba 和 bokeh 都受到了 Blaze 的影响，但我不会在这里谈论它们。
就 datashape/dynd 而言，这是一个有点拥挤 space 的许多其他相关项目（xnd、uarray 等）和想法，可以粗略地认为是 "numpy 2"（即，更全面、更灵活地表示复杂的数据布局及其描述）。这还没有真正被社区采用，几乎所有东西都使用 numpy 的类型系统（箭头在内部所做的值得注意的例外）。
最后，对于数据格式和 Odo，我鼓励您考虑 Intake，它可以看作是后继者，它可以提供更多的功能，例如数据源编目，它通过限制来做到这一点操作范围为读端。 Odo 的大型交互网络也是一个难以维护的多对多问题，通过使事情更简单，Intake 希望成为数据加载库的实际层和描述位置的主要方式，数据的描述和参数化。不过，Odo 并没有死，所以如果文件转换正是您所需要的，您仍然可以使用它。
我一直在寻找一个类似于 odo 的项目，用于将 csv 数据加载到各种来源。一个 odo 问题（https://github.com/blaze/odo/issues/614) recommended d6tstack，目前似乎正在维护。
在实践中，滚动您自己的 csv 加载器通常很容易，在这种情况下，来自 csv 文件的 tableschema project is very handy. It automates inferring 数据类型。
我发现 blaze 生态系统* 很棒，因为它涵盖了大部分数据工程用例。在 2015-2016 年期间，这些项目肯定有很多兴趣，但最近却被忽略了。我说的是看 github 回购协议上的提交。
所以我向社区提出的问题是
- 2016 年发生了什么导致失去兴趣？
- 是否有其他基于 python 的库取代了 blaze？
blaze 生态系统：
- Blaze：查询不同存储系统数据的接口
- Dask：通过任务调度和分块算法进行并行计算
- Datashape：一种数据描述语言
- DyND：一个用于动态多维数组的 C++ 库
- Odo：不同存储系统之间的数据迁移
参考资料： http://blaze.pydata.org/
我可以给出部分图片，尽管其他部分涉及更多。 Blaze 既是一个将数据工程思想孵化到已发布的 oss 包中的伞式项目，也是一个专注于数据帧符号操作并将其转换为各种后端执行引擎（尤其是数据库服务）的包本身。至关重要的是，Blaze 想成为解决范围非常广泛的问题的（开始）解决方案！特别是，翻译层变得非常庞大且难以维护，并且试图迎合所有人，限制了符号层可以提供的操作范围。
就伞式项目而言，Blaze 是成功的。许多始于 Blaze 的想法渗透到生态系统中。 Blaze 最突出的单个项目可能是 Dask，虽然它最初计划作为 Blaze 的执行层，但实现了更大的 API 数据帧操作，以及其他高级集合和任意图形操作。 Dask 中甚至存在完全符号化的优化，尽管这可能不那么完整。其他 Anaconda 稳定的项目，如 numba 和 bokeh 都受到了 Blaze 的影响，但我不会在这里谈论它们。
就 datashape/dynd 而言，这是一个有点拥挤 space 的许多其他相关项目（xnd、uarray 等）和想法，可以粗略地认为是 "numpy 2"（即，更全面、更灵活地表示复杂的数据布局及其描述）。这还没有真正被社区采用，几乎所有东西都使用 numpy 的类型系统（箭头在内部所做的值得注意的例外）。
最后，对于数据格式和 Odo，我鼓励您考虑 Intake，它可以看作是后继者，它可以提供更多的功能，例如数据源编目，它通过限制来做到这一点操作范围为读端。 Odo 的大型交互网络也是一个难以维护的多对多问题，通过使事情更简单，Intake 希望成为数据加载库的实际层和描述位置的主要方式，数据的描述和参数化。不过，Odo 并没有死，所以如果文件转换正是您所需要的，您仍然可以使用它。
我一直在寻找一个类似于 odo 的项目，用于将 csv 数据加载到各种来源。一个 odo 问题（https://github.com/blaze/odo/issues/614) recommended d6tstack，目前似乎正在维护。
在实践中，滚动您自己的 csv 加载器通常很容易，在这种情况下，来自 csv 文件的 tableschema project is very handy. It automates inferring 数据类型。