Apache Hadoop Filesystem and Its Usage in Facebook
Apache Hadoop Filesystem and Its Usage in Facebook
Apache Hadoop Filesystem and Its Usage in Facebook
Dhruba Borthakur Project Lead, Apache Hadoop Distributed File System [email protected] Presented at UC Berkeley April 4, 2011 http://www.facebook.com/hadoopfs
Outline
Introduction Architecture
of Hadoop Distributed File System (HDFS) Usage of Hadoop in Facebook Data Warehouse mySQL Backups Online application storage
Who Am I?
Apache
Core
(Hadoop, Hive, Scribe) Yahoo! (Hadoop in Yahoo Search) Veritas (San Point Direct, Veritas File System) IBM Transarc (Andrew File System) Univ of Wisconsin Computer Science Alumni (Condor Project)
A Confluence of Trends
Queryable Database
Flexible Schema
Archival Store
Hadoop, Why?
Need
to process Multi Petabyte Datasets Data may not have strict schema Expensive to build reliability in each application. Nodes fail every day Failure is expected, rather than exceptional. The number of nodes in a cluster is not constant. Need common infrastructure Efficient, reliable, Open Source Apache License
Is Hadoop a Database?
Hadoop
A giant step backward in the programming paradigm, Dewitt et el DBMS performance outshines Hadoop Stonebraker, Dewitt, SIGMOD 2009
Parallel Databases A few scales to 200 nodes and about 5 PB Primary design goal is performance Requires homogeneous hardware Anomalous behavior is not well tolerated: A slow network can cause serious performance degradation Most queries fail when one node fails Scalability
rescue!
Hadoop History
Dec
2004 Google GFS paper published July 2005 Nutch uses MapReduce Feb 2006 Starts as a Lucene subproject Apr 2007 Yahoo! on 1000-node cluster Jan 2008 An Apache Top Level Project May 2009 Hadoop sorts Petabyte in 17 hours Aug 2010 Worlds Largest Hadoop cluster at Facebook 2900 nodes, 30+ PetaByte
Log
processing Systems
Facebook,
Recommendation
Facebook
Data
Warehouse
AOL
Facebook,
Video
New
Commodity Hardware
Typically in 2 level architecture Nodes are commodity PCs 20-40 nodes/rack Uplink from rack is 4 gigabit Rack-internal is 1 gigabit
Goals of HDFS
Very
Large Distributed File System 10K nodes, 1 billion files, 100 PB Assumes Commodity Hardware Files are replicated to handle hardware failure Detect failures and recovers from them Optimized for Batch Processing Data locations exposed so that computations can move to where data resides Provides very high aggregate bandwidth User Space, runs on heterogeneous OS
HDFS Architecture
NameNode Cluster Membership Secondary NameNode Client
3. Read/ write dat a
DataNodes NameNode : Maps a file to a file-id and list of DataNodes DataNode : Maps a block-id to a physical location on disk SecondaryNameNode: Periodic merge of Transaction log
Namespace for entire cluster Data Coherency Write-once-read-many access model Client can only append to existing files Files are broken up into blocks Typically 128 - 256 MB block size Each block replicated on multiple DataNodes Intelligent Client Client can find location of blocks Client accesses data directly from DataNode
NameNode Metadata
Meta-data
in Memory The entire metadata is in main memory No demand paging of meta-data Types of Metadata List of files List of Blocks for each file & file attributes A Transaction Log Records file creations, file deletions. Etc HDFS Federation under development
DataNode
A
Block Server Stores data in the local file system (e.g. ext3) Stores meta-data of a block (e.g. CRC32) Serves data and meta-data to Clients - Periodic validation of checksums Block Report Periodically sends a report of all existing blocks to the NameNode Facilitates Pipelining of Data Forwards data to other specified DataNodes
Block Placement
Current
Strategy -- One replica on local node -- Second replica on a remote rack -- Third replica on same remote rack -- Additional replicas are randomly placed Clients read from nearest replica Pluggable policy for placing block replicas
Co-locate
http://hadoopblog.blogspot.com/2009/09/hdfs-block-replica-placement-in-your.html
Data Pipelining
Client
writes block to the first DataNode The first DataNode forwards the data to the next DataNode in the Pipeline, and so on When all replicas are written, the Client moves on to write the next block in file Not good for latency sensitive applications How about writing all replicas in parallel?
NameNode Failure
A
Single Point of Failure Transaction Log stored in multiple directories A directory on the local file system A directory on a remote file system (NFS/CIFS) This is a problem with 24 x 7 operations
AvatarNode
DataNodes send block location information to only one NameNode NameNode needs block locations in memory to serve clients The in-memory metadata for 100 million files could be 60 GB, huge!
DataNodes
Primary NameNode
Active-Standby Pair Coordinated via zookeeper Failover in few seconds Wrapper over NameNode
Client retrieves block location from Primary or Standby Active AvatarNode (NameNode) write transaction read transaction Standby AvatarNode (NameNode)
Active AvatarNode Writes transaction log to filer Standby AvatarNode Reads transactions from filer Latest metadata in memory
NFS Filer
DataNodes
http://hadoopblog.blogspot.com/2010/02/hadoop-namenode-high-availability.html
Rebalancer
Goal:
run when new DataNodes are added Cluster is online when Rebalancer is active Rebalancer is throttled to avoid network congestion
Disadvantages
Does
not rebalance based on access patterns or load No support for automatic handling of hotspots of data
File /dir/file.txt
A A
A A
/dir/file.txt
HDFS Raid
A A A
B B B
C C C
Combine third replica of blocks from a single file to create parity block Remove third replica
RaidNode
Auto fix of failed replicas Reed Solomon encoding for old files
A+B+C
http://hadoopblog.blogspot.com/2009/08/hdfs-and-erasure-codes-hdfs-raid.html
Hadoop @ Facebook
500+
billion pieces of content shared every month (news stories, photos, blogs, etc)
Data Usage
Statistics
20
per day:
TB of compressed new data added per day 3 PB of compressed data scanned per day 20K jobs on production cluster per day 480K compute hours per day
Barrier
New
engineers go though a Hadoop/Hive training session 300+ people run jobs on Hadoop Analysts (non-engineers) use Hadoop through Hive
Warehouse 32K cores, 50 PetaBytes 12 or 24 TB per node Two level network topology
1
Gbit/sec from node to rack switch 4 Gbit/sec to top level rack switch
Oracle RAC
MySQL
Hadoop Scribe
Scribe
Writers
RealBme
Hadoop
Cluster
Web
Servers
Scribe
MidTier
Oracle RAC
MySQL
http://hadoopblog.blogspot.com/2009/06/hdfs-scribe-integration.html
Compiler
for 95%+ of Hadoop jobs @ Facebook Used by ~300 engineers and business analysts at Facebook every month
of all mySQL databases Mysql dump files stored in HDFS Storage for Online Application Apache HBase layered on HDFS HBase is a key-value store 500 TB in size
Useful Links
HDFS
Design: API:
http://hadoop.apache.org/core/docs/current/hdfs_design.html
Hadoop
http://hadoop.apache.org/core/docs/current/api/
My
Hadoop Blog:
http://hadoopblog.blogspot.com/ http://www.facebook.com/hadoopfs