[
https://issues.apache.org/jira/browse/HDFS-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15892889#comment-15892889
]
Andrew Wang commented on HDFS-7285:
-----------------------------------
Hi Marcell,
I recommend basing the patch off of the "trunk" branch, we've been pretty
actively working on EC in preparation for alpha3.
I looked at the benchmark results, very interesting! I'm guessing the X axis is
the EC cell size? We've chosen the RS parameters for our built-in EC policies
somewhat arbitrarily, but maybe we should tune them for better performance.
Are there any patterns you see wrt the RS parameters? It looks like the #1
factor is how many parity blocks there are, though there's some weirdness like
10+4 being faster than 9+4. There seem to be differences based on the cell
size, but no pattern I can see.
Another question, is the Chocolate Cloud RS implementation byte-for-byte
compatible with the Hadoop ISA-L and Java RS coder implementations? If not,
it'll be harder for users to experiment with CC RS since it'll require
rewriting data. We'll also need to add a new set of EC policies, which
increases the configuration and maintenance overhead. In this case, I'd like to
see more clear wins and a stable native code release before we put this in a
release.
In the meanwhile, we can also set up a development branch so you can work on
the Hadoop integration. We've also made some progress toward pluggable EC
policies and coder framework, though it's not done yet. If this gets finished,
it'd be a nice way of making your RS implementation accessible to users without
requiring it to be shipped with Hadoop itself.
> 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
> Fix For: 3.0.0-alpha1
>
> Attachments: Compare-consolidated-20150824.diff,
> Consolidated-20150707.patch, Consolidated-20150806.patch,
> Consolidated-20150810.patch, ECAnalyzer.py, ECParser.py,
> fsimage-analysis-20150105.pdf, HDFS-7285-Consolidated-20150911.patch,
> HDFS-7285-initial-PoC.patch, HDFS-7285-merge-consolidated-01.patch,
> HDFS-7285-merge-consolidated-trunk-01.patch,
> HDFS-7285-merge-consolidated.trunk.03.patch,
> HDFS-7285-merge-consolidated.trunk.04.patch, HDFS-bistriped.patch,
> HDFS-EC-merge-consolidated-01.patch, HDFS-EC-Merge-PoC-20150624.patch,
> HDFSErasureCodingDesign-20141028.pdf, HDFSErasureCodingDesign-20141217.pdf,
> HDFSErasureCodingDesign-20150204.pdf, HDFSErasureCodingDesign-20150206.pdf,
> HDFSErasureCodingPhaseITestPlan.pdf,
> HDFSErasureCodingSystemTestPlan-20150824.pdf,
> HDFSErasureCodingSystemTestReport-20150826.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.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
