feat: support memmap dataset with object store via Multi-Storage Client

[jayya2]

Important

The Update branch button must only be pressed in very rare occassions.
An outdated branch is never blocking the merge of a PR.
Please reach out to the automation team before pressing that button.

What does this PR do ?

Add support for using multi-storage-client to load data from object store and construct memmap-based datasets.

In multi-storage client we provide adaptors such as msc.numpy.* and msc.pickle.* which can handle both object store URLs (starting with msc://...) and POSIX file path (/path/to/your/file), so in theory, we can directly replace
existing usages, for examplenumpy.memmap(...) with msc.numpy.memmap(...).

However multis-storage client is not a required dependency at the moment, so I pre-check the module availability to play it safe in this first introduction PR to multi-storage client library.

Collection: [NLP]

Changelog

• Add specific line by line info of high level changes in this PR.

Usage

• You can potentially add a usage example below

# Add a code snippet demonstrating how to use this 

GitHub Actions CI

The Jenkins CI system has been replaced by GitHub Actions self-hosted runners.

The GitHub Actions CI will run automatically when the "Run CICD" label is added to the PR.
To re-run CI remove and add the label again.
To run CI on an untrusted fork, a NeMo user with write access must first click "Approve and run".

Before your PR is "Ready for review"

Pre checks:

• Make sure you read and followed Contributor guidelines
• Did you write any new necessary tests?
• Did you add or update any necessary documentation?
• Does the PR affect components that are optional to install? (Ex: Numba, Pynini, Apex etc)
  • Reviewer: Does the PR have correct import guards for all optional libraries?

PR Type:

• New Feature
• Bugfix
• Documentation

If you haven't finished some of the above items you can still open "Draft" PR.

Who can review?

Anyone in the community is free to review the PR once the checks have passed.
Contributor guidelines contains specific people who can review PRs to various areas.

Additional Information

• Related to # (issue)

[cuichenx]

Looks good, just one question about MSC: if multistorageclient is a package in the container (so that MULTISTORAGECLIENT_AVAILABLE =True, but the environment is a normal file system, is there any impact to run multistorageclient functions

[jayya2]

Looks good, just one question about MSC: if multistorageclient is a package in the container (so that MULTISTORAGECLIENT_AVAILABLE =True, but the environment is a normal file system, is there any impact to run multistorageclient functions

@cuichenx valid point, two things here:

• we have adaptor functions in MSC to work with both msc:// and normal file path starting with /..., example here, so it shouldn't be a problem here (MSC adaptors should just pass through normal file path to original function, so overhead is expected to be minimal)
• Although, it's also reasonable to let users have the ability to explicitly enable MSC due to various reasons (less familiarity/confidence in a new dependency, etc) so that MSC dep introduced in some other places won't affect SFT training implicitly. It can be either via YAML config or via environment variables. Is this aligned with what you are thinking?

[cuichenx]

Looks good, just one question about MSC: if multistorageclient is a package in the container (so that MULTISTORAGECLIENT_AVAILABLE =True, but the environment is a normal file system, is there any impact to run multistorageclient functions

@cuichenx valid point, two things here:

• we have adaptor functions in MSC to work with both msc:// and normal file path starting with /..., example here, so it shouldn't be a problem here (MSC adaptors should just pass through normal file path to original function, so overhead is expected to be minimal)
• Although, it's also reasonable to let users have the ability to explicitly enable MSC due to various reasons (less familiarity/confidence in a new dependency, etc) so that MSC dep introduced in some other places won't affect SFT training implicitly. It can be either via YAML config or via environment variables. Is this aligned with what you are thinking?

Ah, having the first bullet point is perfect. (I realized you also put this in the description but I missed that earlier).
If going through MSC adaptors has minimal risk or overhead, then I think this is fine. I don't think there is a need to add a config argument to allow user to enable/disable MSC. If they really wanted to they can easily modify the code to achieve that.