[Data] Simplify and consolidate progress bar outputs

[scottjlee]

Why are these changes needed?

Currently, the progress bar is pretty verbose because it is very information dense. This PR:

• Reorganizes progress output to group by relevant concepts and clarifies labels
• Standardizes global and operator-level progress bar outputs
• Removes the use of all emojis (poor rendering on some platforms / external logging systems)

Progress bar before this PR:

Progress bar after this PR:

Will follow up with a docs PR once we merge this change, so that I don't need to continuously modify the docs.

In the future, we should restructure the way progress bars are grouped/tracked, so that we can tabulate the op-level progress bar outputs.

Test script used for generating above screenshots:

import time
import ray

class PreprocessImage:
    def __init__(self):
        pass

    def __call__(self, row):
        time.sleep(0.25)
        return row

class ImageClassification:
    def __init__(self):
        pass

    def __call__(self, batch):
        time.sleep(0.25)
        return batch
    
print("===> starting!")

ds = ray.data.read_images("s3://air-example-data-2/1G-image-data-synthetic-raw/")
ds = ds.map(PreprocessImage, concurrency=5)
ds = ds.map_batches(ImageClassification, concurrency=1)

num_batches = 0
for batch in ds.iter_batches():
    num_batches += 1

print(f"===> Completed {num_batches} batches")

Related issue number

Checks

• I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
  • I've added any new APIs to the API Reference. For example, if I added a
    method in Tune, I've added it in doc/source/tune/api/ under the
    corresponding .rst file.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[raulchen]

• Can we print a message in the beginning explaining all the legends?
• The resource usage section is still very lengthy, do you also plan to simplify it?

[raulchen]

"N queued" actually means N blocks in the input buffer, not number of tasks.
(the previous was already a bit confusing)

[raulchen]

also since we have a "Tasks: " section here. I'm wondering maybe we can also move the actor info after this. Instead of at the very end.

[raulchen]

maybe format it as "Tasks ..., Actors ..., Input blocks ..."

[raulchen]

also, and blocked sign can be part of "tasks"

[bveeramani]

maybe format it as "Tasks ..., Actors ..., Input blocks ..."

+1 something like this seems reasonable to me

[raulchen]

can we hide the pending section if all are 0? (forgot to mention in the previous PR)

[bveeramani]

What do the green and yellow circles represent?

[scottjlee]

green = active, yellow = queued

[scottjlee]

although after reworking the progress bar as suggested above, i have removed the green/yellow emoji

[bveeramani]

maybe format it as "Tasks ..., Actors ..., Input blocks ..."

+1 something like this seems reasonable to me

[scottjlee]

Here is the updated progress bar after addressing initial comments:

The information is better grouped now, but unfortunately it's not any less verbose. I couldn't come up with any intuitive emojis to represent the concepts: CPU, GPU, object store, tasks, actors, and input blocks. Any suggestions here?
@raulchen @bveeramani

These are the best that I/ChatGPT could come up with:

• CPU: 🖥️
• GPU: 🖼️
• object store: 📦
• tasks: 📋
• actors: 🎭 or 👤
• (Queued) input blocks: ⏳

[raulchen]

I couldn't come up with any intuitive emojis to represent the concepts: CPU, GPU, object store, tasks, actors, and input blocks. Any suggestions here?

Maybe just use the initial letters? Seems fine as long as we print a message explaining them.

[bveeramani]

Any suggestions here?

IMO we should err on the side of clarity over conciseness.

Maybe just use the initial letters? Seems fine as long as we print a message explaining them.

Something like this? C, G, O.S, T, A, I.B?

As a general design principle, I'd be cautious to rely on tooltips or extra descriptions to make something understandable.

[scottjlee]

Maybe just use the initial letters? Seems fine as long as we print a message explaining them.

Something like this? C, G, O.S, T, A, I.B?

Yes, that's what i was thinking as well.

As a general design principle, I'd be cautious to rely on tooltips or extra descriptions to make something understandable.

When I was discussing with @omatthew98 offline, our thought was that the progress bar should be as concise as possible, but intuitive enough that the user should only need to look at docs once to understand/remember how to use it. We could print a message linking to docs at the beginning of dataset execution once. Does that sound reasonable?

[bveeramani]

When I was discussing with @omatthew98 offline, our thought was that the progress bar should be as concise as possible, but intuitive enough that the user should only need to look at docs once to understand/remember how to use it. We could print a message linking to docs at the beginning of dataset execution once. Does that sound reasonable?

My preference is still to err on the side of clarity. IMO we shouldn't make reading documentation a pre-requisite to interpreting a user interface, even if you'd only need to read the documentation once. Also, I think single letters would be confusing (e.g., does "G" represent "GPU" or "Giga"?)

[raulchen]

Can we let the operators report num_active/pending_actors explicitly?
Because other operators will use progress_str to report non-actor info, and it's weird to put here.
for the actor pool map operator, the locality info can still be in progress_str

[scottjlee]

i remember we had this discussion a while back, and we decided we didn't want to add operator-specific logic in this code area. should i add a check here, like if isinstance(op, ActorPoolMapOperator) explicitly and get the number of actors for ActorPoolMapOperator?

[raulchen]

We can add the method in PhysicalOperator, and default to return 0

[scottjlee]

BTW @raulchen i still had to leave some ActorPoolMapOperator specific logic, in order to add the locality string (checking the attribute if self.op._actor_locality_enabled which only exists for ActorPoolMapOperator). but we know that if active or pending is true, this must be an operator with actors, so i just use assert isinstance(self.op, ActorPoolMapOperator) check to satisfy type checking. let me know if you prefer another approach

[raulchen]

oh, I think we can still keep the locality info at the end (still reported by progress_str), because it's operator-specific