针对大数据的python延迟执行

我正试图思考Python API如何寻找像Cassandra这样的大型数据存储。R、 Matlab和NumPy倾向于使用“一切都是矩阵”公式，并分别执行每个操作。该模型已证明对可以放入内存的数据非常有效。然而，SAS for big data的好处之一是它逐行执行，在移动到下一行之前执行所有的行计算。对于像Cassandra这样的数据存储来说，这个模型似乎是一个巨大的胜利——我们只循环一次数据

在Python中，SAS的方法可能类似于：

with load('datastore') as data:
  for row in rows(data):
    row.logincome = row.log(income)
    row.rich = "Rich" if row.income > 100000 else "Poor"

这是（太？）明确的，但具有只循环一次的优点。对于较小的数据集，与NumPy相比，性能将非常差，因为函数没有使用编译代码进行矢量化。在R/Numpy中，我们将有更简洁、更经过编译的：

data.logincome = log(data.income)
data.rich = ifelse(data.income > 100000, "Rich", Poor")

这将非常快地执行，因为

log

和

ifelse

都是对向量进行运算的编译函数。然而，缺点是我们将循环两次。对于小型数据集，这并不重要，但对于Cassandra支持的数据存储，我看不出这种方法是如何工作的

问：有没有办法保持第二个API（如R/Numpy/Matlab）但延迟计算。也许在最后调用一个同步（数据）函数

---

其他想法？维护NumPy类型语法会很好，因为用户将使用NumPy进行较小的操作，并直观地了解其工作原理。

我对Cassandra/NumPy一无所知，但如果您采用第二种方法（使用NumPy）以合理大小的块处理数据，您可能会从CPU和/或文件系统缓存中受益，从而防止由于数据循环两次而导致的任何减速，而不会放弃使用优化处理功能的好处。

我没有一个完美的答案，只是一个粗略的想法，但可能值得。它以Python生成器为中心，有点像生产者-消费者风格的组合

首先，由于您不想循环两次，我认为没有办法对行进行显式循环，如下所示：

for row in rows(data):
    # do stuff with row

richConsumer = riches()
richConsumer.next()  # advance to first yield
for row in rows(data):
    richConsumer.send(row)
    # other consumers.send(row) here
richConsumer.send(None)  # make consumer exit its inner loop
data.rich = richConsumer.next() # collect result data

现在，将行馈送给（任意数量的）消费者，这些消费者是——不要再阻塞——发电机。但是您将使用生成器的

send

方法。作为此类消费者的一个示例，下面是财富的简图：

def riches():
    rich_data = []
    while True:
        row = (yield)
        if row == None: break
        rich_data.append("Rich" if row.income > 100000 else "Poor")
    yield rich_data

第一个结果（表达式）只是将单个行添加到

中。它做它自己的事情，在这里建立一个结果数组。在while循环之后，第二个yield（语句）用于实际向调用方提供结果数据

回到调用者循环，它可能看起来像这样：

for row in rows(data):
    # do stuff with row

richConsumer = riches()
richConsumer.next()  # advance to first yield
for row in rows(data):
    richConsumer.send(row)
    # other consumers.send(row) here
richConsumer.send(None)  # make consumer exit its inner loop
data.rich = richConsumer.next() # collect result data

我还没有测试过那个代码，但我就是这么想的。它没有基于向量的函数的简洁语法。但它使主循环非常简单，并将所有处理封装在单独的使用者中。其他消费者可以很好地相互堆叠。通过将生成器管理代码推到对象边界等后面，可以进一步完善API。HTH
我不确定我是否完全明白你的意图。这与我的第一个选项相比有何改进？第一个选项只是在行上循环，其中行是底层数据的视图。首先，它确认了需要一个顶级循环。另一方面，我认为您关心的一个问题是将处理代码从循环体中分离出来并放在单独的函数中（您谈到了“编译函数”的优点，尽管我不确定这在Python中有多大意义；但是如果您考虑稍后将这些函数推出C代码，这是非常有意义的）。第三个问题是处理函数的整洁API。考虑到这些限制，我认为这种生产者-消费者的方法是一个很好的折衷方案。但是YMMV。