[
https://issues.apache.org/jira/browse/HDFS-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381915#comment-14381915
]
Kai Zheng commented on HDFS-7285:
---------------------------------
Good discussion and plan. But I'm still a little bit confused. [~zhz] was
mentioning EC policies, and thinking about integrating them with other storage
policies (HSM ones); [~jingzhao] said Let's finish the {{zone}} work first.
What term or concept would we use as a final choice ? I'm worrying about this
because it's kinds of messy, we need to choose one and use it consistently,
update the overall design doc, sync with related issues. It also affects the
implementation, for a example, {{setStoragePolicy}} or {{createZone}} for admin
to set an EC policy for a directory...Let's have a conclusion. Thanks.
In my view, if we use something like {{extended storage policy}} (maybe better
than {{EC policy}}), it would be easier to be unified and integrated into
existing HSM storage policies, and also save some DFS commands to create EC
zones. If we use {{EC Zone}}, it might not be so nature if we create a zone
just for a file in case file level policy is needed in future. If we're likely
to support file level EC policy, EC zone for directory sounds more nature.
Since in medium future we only support directory level EC, either one is good,
we just need one and the choice.
> 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)
