项目的方向在哪里？

Question

我觉得火焰生态系统*令人惊讶，因为它涵盖了大多数数据工程用例。2015-2016年期间，人们对这些项目肯定有很大兴趣，但最近却被忽视了。我说这是看github repos的提交。

所以我向社会提出的问题是

-2016年发生了什么，导致失去兴趣？

-是否还有其他以python为基础的库取代了blaze？

火焰生态系统：

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

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

Answer 1

我可以给出一些部分的图片，虽然其他人更多的参与。Blaze既是一个将数据工程思想孵育到发布的开放源码软件包中的总括项目，也是一个专注于对数据帧的符号操作并将其转化为各种后端执行引擎(特别是数据库服务)的软件包。关键的是，Blaze想要成为一个非常广泛的问题的解决方案(开始)！特别是，翻译层变得非常大，很难维护，并试图迎合所有人，限制了符号层可以提供的操作范围。

就伞式工程而言，烈火是成功的。许多在熊熊燃烧中产生的想法渗透到了生态系统中。从Blaze中出来的最突出的单个项目可能是Dask，它最初计划作为Blaze的执行层，实现更大的数据帧操作API，以及其他高级集合和任意图形操作。即使是完全象征性的优化也存在于Dask中，尽管这可能并不是完全的。其他的Anaconda稳定项目，如numba和bokeh，都受到了大火的影响，但我不想在这里谈论它们。

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

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

Answer 2

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

实际上，提交您自己的csv加载程序也同样容易，在这种情况下，表化学项目非常方便。它从csv文件中自动化推断数据类型。