Data stores compatible with Amazon EMR

There are a number of different file systems that can be used

1. Hadoop Distributed File System (HDFS) : EC2 local/ephemeral disk is where HDFS  resides.  The obvious disadvantage is that it’s ephemeral storage which is reclaimed when the cluster ends. It can be used for caching the results produced by intermediate job-flow steps during a large EMR job.
2. Local (ephemeral) EC2 disk :  Each EMR node comes with local disk.  This disk works well for temporary storage of data that is continually changing, such as buffers, caches, scratch data, and other temporary content.
3. S3 native : Used for input (data set to be reduced) and output/results.
4. S3 block : Stay away from as not as performant as the other options.
5. HBase : HBase is an open source, non-relational, distributed database that runs on top of HDFS.  HBase works with Hadoop/EMR, sharing its file system and serving as a direct input and output to EMR jobs. HBase also integrates with Apache Hive, enabling SQL-like queries over HBase tables, joins with Hive-based tables, and support for Java Database Connectivity (JDBC).

More information here:
http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-plan-file-systems.html

Distributed File System : Network, Distributed or Clustered ?

I often times hear these three distinct DFSs used to mean one in the same.  This presentation does a nice job of describe how they are different and how they are the same:

http://lvee.org/uploads/image_upload/file/273/savchenko-distributed-fs.pdf


Network File System: A single server (or at least an appearance) and multiple network clients.
Examples: NFS, CIFS

Clustered File System:Servers sharing the same local storage (usually SAN at block level)shared storage architecture.
Examples: GFS2, OCFS2

Distributed file system : “Shared nothing” model, independent servers. intelligent server architecture.
Examples: pNFS, AFS

AWS shared disk options

Here the four options most often discussed when considering NAS/shared disk/storage on AWS:

1. S3 : Sometimes NAS isn't the right solution to the problem; it's just something that's relatively easy to implement.
2. GlusterFS, Lustre, openAFS : implementation of a distributed filesystem (GlusterFS, Lustre, openAFS, etc).  Write performance can be below writing to EBS.
3. S3-back 'filesystem' : Use a S3-backed "filesystem" (such as s3fs or Danilo's yas3fs), which is definitely easier to implement. However, write performance could become an issue.
4. NFS : You could just run NFS on another EC2 instances. However, this will not provide the fault tolerance and scalability that is built into a solution such as GlusterFS, or a solution such a Zadara. With Zadara you can have a central repository/shared file system in a NFS mount that will be accesible from EC2 machines.  You can mount Zadara from EC2 via NFS or iSCSI.
5. Of course, when you are running an Oracle database you will probably not use one of these options.  This would be like putting your on premise Oracle database storage on NFS.