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

Konstantin Shvachko commented on HDFS-7240:
-------------------------------------------

It is an interesting question whether Ozone should be a part of Hadoop. There 
are two main reasons why I think it should not.

# With close to 500 sub-tasks, with 6 MB of code changes, and with a sizable 
community behind, it looks to me like a whole new project.
It is essentially a new storage system, with different (than HDFS) 
architecture, separate S3-like APIs. This is really great - the World sure 
needs more distributed file systems. But it is not clear why Ozone should 
co-exist with HDFS under the same roof.
# Ozone is probably just the first step in rebuilding HDFS under a new 
architecture. With the next steps presumably being HDFS-10419 and HDFS-11118.
The design doc for the new architecture has never been published. I can only 
assume based on some presentations and personal communications that the idea is 
to use Ozone as a block storage, and re-implement NameNode, so that it stores 
only a partial namesapce in memory, while the bulk of it (cold data) is 
persisted to a local storage.
Such architecture makes me wonder if it solves Hadoop's main problems. There 
are two main limitations in HDF
a) _The throughput of Namespace operations_. Which is limited by the number of 
RPCs the NameNode can handle
b) _The number of objects_ (files + blocks) the system can maintain. Which is 
limited by the memory size of the NameNode.
The RPC performance (a) is more important for Hadoop scalability than the 
object count (b). The read RPCs being the main priority.
The new architecture targets the object count problem, but in the expense of 
the RPC throughput. Which seems to be a wrong resolution of the tradeoff.
Also based on the use patterns on our large clusters we read up to 90% of the 
data we write, so cold data is a small fraction and most of it must be cached.

To summarize:
- Ozone is a big enough system to deserve its own project.
- The architecture that Ozone leads to does not seem to solve the intrinsic 
problems of current HDFS.

> Object store in HDFS
> --------------------
>
>                 Key: HDFS-7240
>                 URL: https://issues.apache.org/jira/browse/HDFS-7240
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>            Reporter: Jitendra Nath Pandey
>            Assignee: Jitendra Nath Pandey
>         Attachments: HDFS-7240.001.patch, HDFS-7240.002.patch, 
> HDFS-7240.003.patch, HDFS-7240.003.patch, HDFS-7240.004.patch, 
> Ozone-architecture-v1.pdf, Ozonedesignupdate.pdf, ozone_user_v0.pdf
>
>
> This jira proposes to add object store capabilities into HDFS. 
> As part of the federation work (HDFS-1052) we separated block storage as a 
> generic storage layer. Using the Block Pool abstraction, new kinds of 
> namespaces can be built on top of the storage layer i.e. datanodes.
> In this jira I will explore building an object store using the datanode 
> storage, but independent of namespace metadata.
> I will soon update with a detailed design document.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to