hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zhe Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7285) Erasure Coding Support inside HDFS
Date Thu, 12 Mar 2015 06:10:39 GMT

    [ https://issues.apache.org/jira/browse/HDFS-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358145#comment-14358145
] 

Zhe Zhang commented on HDFS-7285:
---------------------------------

[~jingzhao] This is a great question to discuss and was missing in the above summary; thanks
for bring it up!

In the initial design (page 6 of the latest [design doc | https://issues.apache.org/jira/secure/attachment/12697210/HDFSErasureCodingDesign-20150206.pdf]),
EC policy changes will be lazily enforced by {{Mover}} or a similar tool. The rationales are:
# Conversion between replication and EC is a very important use case; so we do need to support
changing EC policy on files and dirs
# The conversion should be done lazily for the same reason of lazily enforcing HSM policies:
the purpose (saving space) is not urgent and the operation is expensive

bq. If we allow changing the EC schema associated with a directory, we need to make sure for
all the files inside its old EC schema can be found, which means we may need to associate
the schema directly on the files or even blocks (which can be inefficient).
Great point. Adding a little formality might help the discussion here. Essentially every file
or dir has an _desired_ storage policy and an _actual_ one. Luckily, in the context of HSM
we don't need to keep explicitly track of the _actual_ placement policy. EC policies are indeed
more complicated in this perspective. I think we can solve it by doing the following:
# In the storage policy XAttr, always store the _actual_ policy instead of the desired one
# {{Mover}} (or a similar tool) should keep track of a queue of desired changes
# When converting an individual file, keep the old form until the block conversion is done.
Then "flip" the XAttr
# Because of the above, when converting a directory we need to store the new policy XAttr
in some of its files
# Appends should either be disallowed during a conversion, or with more advanced mechanism
like appending to both old and new forms
# A renamed file should materialize and carry over the policy XAttr from the old dir. Then
it will become a nested scenario, where the new dir has policy B and the moved file has policy
A

> Erasure Coding Support inside HDFS
> ----------------------------------
>
>                 Key: HDFS-7285
>                 URL: https://issues.apache.org/jira/browse/HDFS-7285
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>            Reporter: Weihua Jiang
>            Assignee: Zhe Zhang
>         Attachments: ECAnalyzer.py, ECParser.py, HDFS-7285-initial-PoC.patch, HDFSErasureCodingDesign-20141028.pdf,
HDFSErasureCodingDesign-20141217.pdf, HDFSErasureCodingDesign-20150204.pdf, HDFSErasureCodingDesign-20150206.pdf,
fsimage-analysis-20150105.pdf
>
>
> Erasure Coding (EC) can greatly reduce the storage overhead without sacrifice of data
reliability, comparing to the existing HDFS 3-replica approach. For example, if we use a 10+4
Reed Solomon coding, we can allow loss of 4 blocks, with storage overhead only being 40%.
This makes EC a quite attractive alternative for big data storage, particularly for cold data.

> Facebook had a related open source project called HDFS-RAID. It used to be one of the
contribute packages in HDFS but had been removed since Hadoop 2.0 for maintain reason. The
drawbacks are: 1) it is on top of HDFS and depends on MapReduce to do encoding and decoding
tasks; 2) it can only be used for cold files that are intended not to be appended anymore;
3) the pure Java EC coding implementation is extremely slow in practical use. Due to these,
it might not be a good idea to just bring HDFS-RAID back.
> We (Intel and Cloudera) are working on a design to build EC into HDFS that gets rid of
any external dependencies, makes it self-contained and independently maintained. This design
lays the EC feature on the storage type support and considers compatible with existing HDFS
features like caching, snapshot, encryption, high availability and etc. This design will also
support different EC coding schemes, implementations and policies for different deployment
scenarios. By utilizing advanced libraries (e.g. Intel ISA-L library), an implementation can
greatly improve the performance of EC encoding/decoding and makes the EC solution even more
attractive. We will post the design document soon. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message