Accessing Remote Data with a Generalized File System


colorful big data pattern background

Originally created for the needs of Dask, we have spun out a general file system implementation and specification, to provide all users with simple access to many local, cluster, and remote storage media. Dask and Intake have moved to use this new package: fsspec.


For context, we are talking about the low-level business of getting raw bytes from some location. We are used to doing that on a local disk, but communicating with other storage mechanisms can be tricky, and certainly different in every case. For example, consider the different ways you would go about reading files from Hadoop, a server for which you have SSH credentials, or for a cloud storage service like Amazon S3. Since these are important to answer when dealing with big data, we developed code to complement Dask just for the job, and released packages like s3fs and gcsfs.

We found that those packages, which were built and released standalone, were popular even without Dask, partly because they were being used by other PyData libraries such as pandas and xarray. So we realised that the general idea of dealing with arbitrary file systems, as well as helpful code to map URLs to bytes, should not be buried in Dask, but should be made open and available to everyone, even if they are not interested in parallel/out-of-core computing.


Consider the following lines of code (which uses s3fs):

>>> import fsspec
>>> of ="s3://anaconda-public-datasets/iris/iris.csv", mode='rt', anon=True)
>>> with of as f:
...     print(f.readline())
...     print(f.readline())

This parsed a URL and initiates a session to talk with AWS S3, to read a particular key in text mode. Note that we specify that this is an anonymous connection (for those that don’t have S3 credentials, since this data is public). The object of is a serialisable OpenFile, which only communicated with the remote service within a context; but f is a regular file-like object which can be passed to many python functions expecting to use methods like readline(). The output is two lines of data from the famous Iris Dataset.

This file is stored uncompressed, and can be opened in random-access bytes mode.
This allows seeking to and extracting smaller parts of a potentially large file without having to download the whole thing. When dealing with large data, this is useful for both local data exploration, as well as parallel processing in the cloud (which is exactly how Dask uses fsspec).

Now compare with the following:

>>> of ="")
>>> with of as f:
...     print(f.readline())
...     print(f.readline())
...     print(f.readline())

This uses a different backend for HTTP locations, but has exactly the same API. (The output is slightly different because this version of the dataset includes a header line.)

Remote File Systems

Alternatively, you can work with file system instances, which have all of the methods that you would expect, inspired by the builtinos module:

>>> fs = fsspec.filesystem('s3', anon=True)
{'Key': 'anaconda-public-datasets/iris/iris.csv',
 'LastModified': datetime.datetime(2017, 8, 10, 16, 35, 36, tzinfo=tzutc()),
 'ETag': '"f47788bbfca239ad319aa7a3b038fc71"',
 'Size': 4700,
 'StorageClass': 'STANDARD',
 'type': 'file',
 'size': 4700,
 'name': 'anaconda-public-datasets/iris/iris.csv'}

The point is, you do (almost) exactly the same thing for any of the several backend file systems, and you get the benefit of extra features for free:

  • transparent decompression and text mode with the open() and open_files() functions, the latter of which will expand glob strings automatically
  • key-value dictionary views of directories
>>> m = fsspec.get_mapper('s3://zarr-demo/store', anon=True)
>>> list(m)
>>> m['.zattrs']
  • transactional writing: all files are finalised only when the context ends, and in the case of an exception, will be rolled back/discarded
>>> fs = fsspec.filesystem('s3')  # requires credentials
>>> with fs.transaction:
...     fs.put('localfile', 'mybucket/remotefile')
...     raise RuntimeError        
>>> assert not fs.exists('mybucket/remotefile')

Unified Interface

Intake now depends on fsspec for its file handling. Intake’s purpose is to ease the process of finding and loading data, so being able to browse any file system (or anything that can be thought of as a file system) is important. In the main GUI, you can now select amongst many possible backends, not just local files:

This allows you to select catalogs that may be remote, and have them load remote data too. Of course, you still need to have the relevant driver installed, and indeed to have access to a service matching the protocol (the kwargs box exists to add any additional parameters that the backend may need). For example, in the following image, I can browse S3, and see all of the buckets that I am an owner of as “directories”. This requires no extra configuration, since my S3 credentials are stored on the system.

The Spec

A more subtle point is that a lot of the logic for how to deal with files is common across implementations. The fsspecpackage contains a spec for other file system implementations to derive from, making the process of writing new file system wrappers – which will be compatible with Dask, Intake, and others – a much simpler process. Such implementations will also inherit many of the for-free features.

Therefore, I invite all interested developers to get in touch to see how you might go about implementing your favourite file system.

You May Also Like

Enterprise Data Science
Here Comes The Data Science—And It’s All Right
Did you know that 94 percent of enterprises are using open source technologies for Data Science, and 96 percent of company executives say Data Science is critical to the succe...
Read More
Enterprise Data Science
8 AI Predictions for 2020: Business Leaders & Researchers Weigh In
The first industrial revolution was powered by coal, the second by oil and gas, and the third by nuclear power. The fourth — AI — is fueled by an abundance of data...
Read More
Anaconda Enterprise 5.3 Release
The Anaconda Product Team has released Anaconda Enterprise 5.3, an upgrade focused on platform stability and reliability to support our customers’ needs for continuous innov...
Read More