Integration of VolcanoEngine TOS in Hadoop

Requirements

1. A Volcano Engine account. Use the account to create a TOS bucket.
2. A dev environment that can access TOS. E.g. a local server or a volcano engine cloud server.
3. Install hadoop to the dev environment. Hadoop is installed at $HADOOP_HOME.

Usage

• Compile hadoop-tos bundle tar. The hadoop-tos bundle is not packaged in hadoop final tar file. So we have to compile it manually. Download the hadoop project, and build it with command below.

mvn package -DskipTests -pl org.apache.hadoop:hadoop-tos

• The bundle jar file is placed at $HADOOP_HOME/hadoop-cloud-storage-project/hadoop-tos/target/hadoop-tos-{VERSION}.jar.

• Copy the bundle jar to hdfs lib path. The hdfs lib path is $HADOOP_HOME/share/hadoop/hdfs/lib. Remember copying to all hadoop nodes.

cp hadoop-tos-{VERSION}.jar $HADOOP_HOME/share/hadoop/hdfs/lib/

• Configure properties below.

<properties>
  <property>
    <name>fs.defaultFS</name>
    <value>tos://{your_bucket_name}/</value>
    <description>
      The name of the default file system. Make it your tos bucket.
    </description>
  </property>

  <property>
    <name>fs.tos.endpoint</name>
    <value></value>
    <description>
      Object storage endpoint to connect to, which should include both region and object domain name.
      e.g. 'fs.tos.endpoint'='tos-cn-beijing.volces.com'.
    </description>
  </property>

  <property>
    <name>fs.tos.impl</name>
    <value>org.apache.hadoop.fs.tosfs.TosFileSystem</value>
    <description>
      The implementation class of the tos FileSystem.
    </description>
  </property>

  <property>
    <name>fs.AbstractFileSystem.tos.impl</name>
    <value>org.apache.hadoop.fs.tosfs.TosFS</value>
    <description>
      The implementation class of the tos AbstractFileSystem.
    </description>
  </property>

  <property>
    <name>fs.tos.access-key-id</name>
    <value></value>
    <description>
      The access key of volcano engine's user or role.
    </description>
  </property>

  <property>
    <name>fs.tos.secret-access-key</name>
    <value></value>
    <description>
      The secret key of the access key specified by 'fs.tos.access-key-id'.
    </description>
  </property>
</properties>

• Use hadoop shell command to access TOS.

# 1. List root dir.
hadoop fs -ls /

# 2. Make directory.
hadoop fs -mkdir /hadoop-tos

# 3. Write and read.
echo "hello tos." > hello.txt
hadoop fs -put hello.txt /hadoop-tos/
hadoop fs -cat /hadoop-tos/hello.txt

# 4. Delete file and directory.
hadoop fs -rm -r /hadoop-tos/

TOS

TOS is the object storage service of Volcano Engine. It is similar to ASW S3, Azure Blob Storage and Aliyun OSS, and has some unique features, such as object fast copy, object fast rename, CRC32C checksum etc. Learn more details about TOS from: https://www.volcengine.com/product/TOS.

TOS has 2 modes: the flat mode and the hierarchy mode. In flat mode, there are no directories, all objects are files indexed by the object names. User can use ‘slash’ in the object name to logically divide objects into different “directories”, though the “directories divided by the slash” are not real. Cleanup a logic directory is to clean all the files with “directory path” as prefix.

In hierarchy mode, there are directories and files. A directory object is the object whose name ends with slash. All objects start with the directory object name are the directory object’s consecutive objects, and together they form a directory tree. A directory object can’t contain any data. Delete or rename a directory object will clean or rename all objects under the directory tree atomically.

TOS has some distinctive features that are very useful in bigdata scenarios.

1. The fast copy feature enables users to duplicate objects without copying data, even huge objects could be copied within tens of milliseconds.
2. The fast rename feature enables users to rename one object with a new name without copying data.
3. TOS supports CRC32C checksum. It enables user to compare files’ checksums between HDFS and TOS.

Directory and file

This section illustrates how hadoop-tos transforms TOS to a hadoop FileSystem. TOS requires object’s name must not start with slash, must not contain consecutive slash and must not be empty. Here is the transformation rules.

• Object name is divided by slash to form hierarchy.
• An object whose name ends with slash is a directory.
• An object whose name doesn’t end with slash is a file.
• A file’s parents are directories, no matter whether the parent exists or not.

For example, supposing we have 2 objects “user/table/” and “user/table/part-0”. The first object is mapped to “/user/table” in hadoop and is a directory. The second object is mapped to “/user/table/part-0” as a file. The non-existent object “user/” is mapped to “/user” as a directory because it’s the parent of file “/user/table/part-0”.

The FileSystem requirements above are not enforced rules in flat mode, users can construct cases violating the requirements above. For example, creating a file with its parent is a file. In hierarchy mode, the requirements are enforced rules controlled by TOS service, so there won’t be semantic violations.

List, Rename and Delete

List, rename and delete are costly operations in flat mode. Since the namespace is flat, to list a directory, the client needs to scan all objects with directory as the prefix and filter with delimiter. For rename and delete directory, the client needs to first list the directory to get all objects and then rename or delete objects one by one. So they are not atomic operations and costs a lot comparing to hdfs.

The idiosyncrasies of hierarchy mode is supporting directory. So it can list very fast and support atomic rename and delete directory. Rename or delete failure in flat mode may leave the bucket in an inconsistent state, the hierarchy mode won’t have this problem.

Read and write file

The read behaviour in hadoop-tos is very like reading an HDFS file. The challenge is how to keep the input stream consistent with object. If the object is changed after we open the file, the input stream should fail. This is implemented by saving the file checksum when open file. If the file is changed while reading, the input stream will compare the checksum and trigger an exception.

The write behaviour in hadoop-tos is slightly different from hdfs. Firstly, the append interface is not supported. Secondly, the file is not visible until it is successfully closed. Finally, when 2 clients try to write one file, the last client to close the file will override the previous one.

Both read and write has many performance optimizations. E.g. range read, connection reuse, local write buffer, put for small files, multipart-upload for big files etc.

Permissions

TOS permission model is different from hadoop filesystem permission model. TOS supports permissions based on IAM, Bucket Policy, Bucket and Object ACL, while hadoop filesystem permission model uses mode and acl. There is no way to mapped tos permission to hadoop filesystem permission, so we have to use fake permissions in TosFileSystem and TosFS. Users can read and change the filesystem permissions, they can only be seen but not effective. Permission control eventually depends on TOS permission model.

Times

Hadoop-tos supports last modified time and doesn’t support access time. For files, the last modified time is the object’s modified time. For directories, if the directory object doesn’t exist, the last modified time is the current system time. If the directory object exists, the last modified time is the object’s modify time when getFileStatus and current system time when listStatus.

File checksum

TOS supports CRC64ECMA checksum by default, it is mapped to Hadoop FileChecksum. We can retrieve it by calling FileSystem#getFileChecksum. To be compatible with HDFS, TOS provides optional CRC32C checksum. When we distcp between HDFS and TOS, we can rely on distcp checksum mechanisms to keep data consistent. To use CRC32C, configure keys below.

<configuration>
   <property>
      <name>fs.tos.checksum.enabled</name>
      <value>true</value>
   </property>
   <property>
      <name>fs.tos.checksum-algorithm</name>
      <value>COMPOSITE-CRC32C</value>
   </property>
   <property>
      <name>fs.tos.checksum-type</name>
      <value>CRC32C</value>
   </property>
</configuration>

Credential

TOS client uses access key id and secret access key to authenticate with tos service. There are 2 ways to configure them. First is adding to hadoop configuration, such as adding to core-site.xml or configuring through -D parameter. The second is setting environment variable, hadoop-tos will search for environment variables automatically.

To configure ak, sk in hadoop configuration, using the key below.

<configuration>
  <!--Set global ak, sk for all buckets.-->
  <property>
    <name>fs.tos.access-key-id</name>
    <value></value>
    <description>
      The accessKey key to access the tos object storage.
    </description>
  </property>
  <property>
    <name>fs.tos.secret-access-key</name>
    <value></value>
    <description>
      The secret access key to access the object storage.
    </description>
  </property>
  <property>
    <name>fs.tos.session-token</name>
    <value></value>
    <description>
      The session token to access the object storage.
    </description>
  </property>

  <!--Set ak, sk for specified bucket. It has higher priority then the global keys.-->
  <property>
    <name>fs.tos.bucket.{bucket_name}.access-key-id</name>
    <value></value>
    <description>
      The access key to access the object storage for the configured bucket.
    </description>
  </property>
  <property>
    <name>fs.tos.bucket.{bucket_name}.secret-access-key</name>
    <value></value>
    <description>
      The secret access key to access the object storage for the configured bucket.
    </description>
  </property>
  <property>
    <name>fs.tos.bucket.{bucket_name}.session-token</name>
    <value></value>
    <description>
      The session token to access the object storage for the configured bucket.
    </description>
  </property>
</configuration>

The ak, sk in environment variables have the top priority and automatically fall back to hadoop configuration if not found. The priority could be changed by fs.tos.credential.provider.custom.classes.

Committer

Hadoop-tos provides MapReduce job committer for better performance. By default, hadoop uses FileOutputCommitter which will rename files many times. First when tasks commit, files will be renamed to a output path. Then when job commits, the files will be renamed from output path to the final path. When using hdfs, rename is not a problem because it only changes meta. But in TOS, by default the rename is implemented as copy and delete and costs a lot.

TOS committer is an optimized implementation for object storage. When task commits, it won’t complete multipart-upload for the files, instead it write pending set files including all the information to complete multipart-upload. Then when job commits, it reads all the pending files and completes all multipart-uploads.

An alternative way is turning on TOS renameObject switch and still use FileOutputFormat. Objects are renamed with only meta change. The performance is slightly slower than hadoop-tos committer, because when using TOS rename objects, each file is committed first and then renamed to the final path. There is 1 commit request and 2 rename request to TOS. But with hadoop-tos committer, the object is postponing committed and there is no rename request overhead.

To enable hadoop-tos committer, configure the key value below.

<configurations>
   <!-- mapreduce v1 -->
   <property>
      <name>mapred.output.committer.class</name>
      <value>org.apache.hadoop.fs.tosfs.commit.mapred.Committer</value>
   </property>
   <!-- mapreduce v2 -->
   <property>
      <name>mapreduce.outputcommitter.factory.scheme.tos</name>
      <value>org.apache.hadoop.fs.tosfs.commit.CommitterFactory</value>
   </property>
</configurations>

To enable tos objectRename, first turn on the object rename switch on tos, then configure the key value below.

<configurations>
   <property>
      <name>fs.tos.rename.enabled</name>
      <value>true</value>
   </property>
</configurations>