Mike, Thanks for the informative answer. I asked this question because I saw that Alluxio can be used to handle storage for HBase. Plus, we could keep our cluster size to a minimum and not need to add more nodes based on storage capacity. We would only need to size our clusters based on load (cores, memory, bandwidth) instead.
Cheers, Ben > On Mar 25, 2017, at 2:54 PM, Mike Percy <mpe...@apache.org> wrote: > > Kudu currently relies on local storage on a POSIX file system. Right now > there is no support for S3, which would be interesting but is non-trivial in > certain ways (particularly if we wanted to rely on S3's replication and > disable Kudu's app-level replication). > > I would suggest using only either EXT4 or XFS file systems for production > deployments as of Kudu 1.3, in a JBOD configuration, with one SSD per machine > for the WAL and with the data disks on either SATA or SSD drives depending on > the workload. Anything else is untested AFAIK. > > As for Alluxio, I haven't heard of people using it for permanent storage and > since Kudu has its own block cache I don't think it would really help with > caching. Also I don't recall Tachyon providing POSIX semantics. > > Mike > > Sent from my iPhone > >> On Mar 25, 2017, at 9:50 AM, Benjamin Kim <bbuil...@gmail.com> wrote: >> >> Hi, >> >> Does anyone know of a way to use AWS S3 or >
