perf(weave): download dataset with images in rows in parallel

[gtarpenning]

Description

WB-23955

Use the future executor to parallelize row requests. The only issue I can see is when the queue is full, but I think in that case this executes exactly as fast as it currently does.

This pr:

• utilizes the async_batch_processor to handle row download requests, massively speeding up row downloads when rows have objects in them (like images).

Testing

Before	After
29.7s	2.24s

Image dataset test (run eval against downloaded dataset):

size	prod eval time (s)	branch eval time (s)
10	1.92s	0.66s
100	14.66s	0.96s
1000	175.16s	20.16s

[circle-job-mirror]

Preview this PR with FeatureBee: https://beta.wandb.ai/?betaVersion=c2396195c153d89d6857bef2a5a2aec4dabced36

[andrewtruong]

Just want to make sure this is expected:

As written, if you raise anywhere during iteration, no further futures will be returned.

[gtarpenning]

I think in practice table_ref should be defined here. i'll move that check outside the process row fn.

[gtarpenning]

oh, there already is that check at the top. ill make this less aggro but just returning none?

[andrewtruong]

my point here is that if any of the future.result() raises an Exception, then none of the other futures will be yielded. Is that what you intend?

[gtarpenning]

hmm. I think that is what we want right? During an eval, if anything fails I believe we fail the entire thing. Additionally, all i'm doing here is a thin wrapper over the existing functionality that downloaded in the main thread, which definitely would have errored. So I think this is safe. If we in the future decided to allow partial-evals, or "resuming" evals, or fixing errored traces in evals, we might have to rethink this. Unless you can see an obvious alternative?

[andrewtruong]

ok, just want to make sure you thought about it. That makes sense to me :)