[
https://issues.apache.org/jira/browse/HDFS-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893989#comment-15893989
]
Marcell Feher commented on HDFS-7285:
-------------------------------------
Hi Andrew!
Alright, we'll use the "trunk".
Yes, the X axis is the cell/chunk size. These charts reflect preliminary speeds
that we quickly made just to see an approximate comparison against ISA-L. We
are currently working on a more reliable benchmark, I'll post the results when
they are in. Theoretically our encode speed is mostly dominated by the number
of data units and reconstruct speed by the number of lost parity units that
needs to be repaired.
Today we are not compatible with ISA and the built-in plugins (since our plugin
uses the Vandermonde coefficient matrix), but we identified this problem as
well and working actively on the Cauchy matrix implementation. Our goal is to
be compatible and we will reach in the next few weeks.
Our RS plugin, similarly to ISA-L, is implemented in C++ and offered as a
native binary library. The only thing needs to be shipped within the Hadoop
framework is the glue code. Our understanding is that this is the intended way
of shipping new native EC plugins. Some glue code is always necessary in the
framework (like with Liberasurecode). Isn't this the case?
> 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]
