SlideShare uma empresa Scribd logo
1 de 60
Baixar para ler offline
1©MapR Technologies - Confidential
Inside MapR’s M7
How to get a million ops per second on 10 nodes
2©MapR Technologies - Confidential
Me, Us
 Ted Dunning, Chief Application Architect, MapR
Committer PMC member, Mahout, Zookeeper, Drill
Bought the beer at the first HUG
 MapR
Distributes more open source components for Hadoop
Adds major technology for performance, HA, industry standard API’s
 Tonight
Hash tag - #mapr #fast
See also - @ApacheMahout @ApacheDrill
@ted_dunning and @mapR
3©MapR Technologies - Confidential
MapR does MapReduce (fast)
TeraSort Record
1 TB in 54 seconds
1003 nodes
MinuteSort Record
1.5 TB in 59 seconds
2103 nodes
4©MapR Technologies - Confidential
MapR: Lights Out Data Center Ready
• Automated stateful failover
• Automated re-replication
• Self-healing from HW and SW
failures
• Load balancing
• Rolling upgrades
• No lost jobs or data
• 99999’s of uptime
Reliable Compute Dependable Storage
• Business continuity with snapshots
and mirrors
• Recover to a point in time
• End-to-end check summing
• Strong consistency
• Built-in compression
• Mirror between two sites by RTO
policy
5©MapR Technologies - Confidential
Part 1:
What’s past is prologue
6©MapR Technologies - Confidential
Part 1:
What’s past is prologue
HBase is really good
except when it isn’t
but it has a heart of gold
7©MapR Technologies - Confidential
Part 2:
An implementation tour
8©MapR Technologies - Confidential
Part 2:
An implementation tour
with many tricks
and clever ploys
9©MapR Technologies - Confidential
Part 3:
Results
10©MapR Technologies - Confidential
11©MapR Technologies - Confidential
Part 1:
What’s past is prologue
12©MapR Technologies - Confidential
Dynamo DB
ZopeDB
Shoal
CloudKit
Vertex DB
FlockD
B
NoSQL
13©MapR Technologies - Confidential
HBase Table Architecture
 Tables are divided into key ranges (regions)
 Regions are served by nodes (RegionServers)
 Columns are divided into access groups (columns families)
CF1 CF2 CF3 CF4 CF5
R1
R2
R3
R4
14©MapR Technologies - Confidential
HBase Architecture is Better
 Strong consistency model
– when a write returns, all readers will see same value
– "eventually consistent" is often "eventually inconsistent"
 Scan works
– does not broadcast
– ring-based NoSQL databases (eg, Cassandra, Riak) suffer on scans
 Scales automatically
– Splits when regions become too large
– Uses HDFS to spread data, manage space
 Integrated with Hadoop
– map-reduce on HBase is straightforward
15©MapR Technologies - Confidential
But ... how well do you know HBCK?
a.k.a. HBase Recovery
 HBase-5843: Improve HBase MTTR – Mean Time To Recover
 HBase-6401: HBase may lose edits after a crash with 1.0.3
– uses appends
 HBase-3809: .META. may not come back online if ….
 etc
 about 40-50 Jiras on this topic
 Very complex algorithm to assign a region
– and still does not get it right on reboot
16©MapR Technologies - Confidential
HBase Issues
Reliability
•Compactions disrupt operations
•Very slow crash recovery
•Unreliable splitting
Business continuity
•Common hardware/software issues cause downtime
•Administration requires downtime
•No point-in-time recovery
•Complex backup process
Performance
•Many bottlenecks result in low throughput
•Limited data locality
•Limited # of tables
Manageability
•Compactions, splits and merges must be done manually (in reality)
•Basic operations like backup or table rename are complex
17©MapR Technologies - Confidential
Examples: Performance Issues
 Limited support for multiple column families: HBase has
issues handling multiple column family due to compactions. The standard
HBase documentation recommends no more than 2-3 column families.
(HBASE-3149)
 Limited data locality: HBase does not take into account block locations
when assigning regions. After a reboot, RegionServers are often reading data
over the network rather than the local drives. (HBASE-4755, HBASE-4491)
 Cannot utilize disk space: HBase RegionServers struggle with more
than 50-150 regions per RegionServer so a commodity server can only handle
about 1TB of HBase data, wasting disk space.
(http://hbase.apache.org/book/important_configurations.html,
http://www.cloudera.com/blog/2011/04/hbase-dos-and-donts/)
 Limited # of tables: A single cluster can only handle several tens of
tables effectively.
(http://hbase.apache.org/book/important_configurations.html)
18©MapR Technologies - Confidential
Examples: Manageability Issues
 Manual major compactions: HBase major compactions are disruptive
so production clusters keep them disabled and rely on the administrator to
manually trigger compactions.
(http://hbase.apache.org/book.html#compaction)
 Manual splitting: HBase auto-splitting does not work properly in a busy
cluster so users must pre-split a table based on their estimate of data
size/growth. (http://chilinglam.blogspot.com/2011/12/my-experience-
with-hbase-dynamic.html)
 Manual merging: HBase does not automatically merge regions that are
too small. The administrator must take down the cluster and trigger the
merges manually.
 Basic administration is complex: Renaming a table requires copying
all the data. Backing up a cluster is a complex process. (HBASE-643)
19©MapR Technologies - Confidential
Examples: Reliability Issues
 Compactions disrupt HBase operations: I/O bursts overwhelm
nodes (http://hbase.apache.org/book.html#compaction)
 Very slow crash recovery: RegionServer crash can cause data to be
unavailable for up to 30 minutes while WALs are replayed for
impacted regions. (HBASE-1111)
 Unreliable splitting: Region splitting may cause data to be
inconsistent and unavailable.
(http://chilinglam.blogspot.com/2011/12/my-experience-with-
hbase-dynamic.html)
 No client throttling: HBase client can easily overwhelm
RegionServers and cause downtime. (HBASE-5161, HBASE-5162)
20©MapR Technologies - Confidential
One Issue – Crash Recovery Too Slow
 HBASE-1111 superseded by HBASE-5843 which is blocked by
HDFS-3912 HBASE-6736 HBASE-6970 HBASE-7989 HBASE-6315
HBASE-7815 HBASE-6737 HBASE-6738 HBASE-7271 HBASE-7590
HBASE-7756 HBASE-8204 HBASE-5992 HBASE-6156 HBASE-6878
HBASE-6364 HBASE-6713 HBASE-5902 HBASE-4755 HBASE-7006
HDFS-2576 HBASE-6309 HBASE-6751 HBASE-6752 HBASE-6772
HBASE-6773 HBASE-6774 HBASE-7246 HBASE-7334 HBASE-5859
HBASE-6058 HBASE-6290 HBASE-7213 HBASE-5844 HBASE-5924
HBASE-6435 HBASE-6783 HBASE-7247 HBASE-7327 HDFS-4721
HBASE-5877 HBASE-5926 HBASE-5939 HBASE-5998 HBASE-6109
HBASE-6870 HBASE-5930 HDFS-4754 HDFS-3705
21©MapR Technologies - Confidential
What is the
source of these
problems?
22©MapR Technologies - Confidential
RegionServers are problematic
 Coordinating 3 separate distributed systems is very hard
– HBase, HDFS, ZK
– Each of these systems has multiple internal systems
– Too many races, too many undefined properties
 Distributed transaction framework not available
– Too many failures to deal with
 Java GC wipes out the RS from time to time
– Cannot use -Xmx20g for a RS
 Hence all the bugs
– HBCK is your "friend"
23©MapR Technologies - Confidential
Region Assignment in Apache HBase
24©MapR Technologies - Confidential
 Files are broken into blocks
 Distributed across data-nodes
 NameNode holds (in DRAM)
 Directories, Files
 Block replica locations
 Data Nodes
 Serve blocks
 No idea about files/dirs
 All ops go to NN
HDFS Architecture Review
DataNodes save Blocks
Files
sharded into
blocks
25©MapR Technologies - Confidential
 NameNode holds in-memory
 Dir hierarchy ("names")
 File attrs ("inode")
 Composite file structure
 Array of block-ids
 1-byte file in HDFS
 1 HDFS "block" on 3 DN's
 3 entries in NN totaling 1K DRAM
A File at the NameNode
Composite File Structure
26©MapR Technologies - Confidential
DN reports blocks to NN
– 128M blocks
– 12T of disk => DN sends 100K blocks/report
– RPC on wire is 4M
– causes extreme load
• at both DN and NN
 With NN-HA, DN's do dual block-reports
– one to primary, one to secondary
– doubles the load on DN
NN scalability problems
27©MapR Technologies - Confidential
Scaling Parameters
 Unit of I/O
– 4K/8K (8K in MapR)
 Unit of Chunking (a map-reduce
split)
– 10-100's of megabytes
 Unit of Resync (a replica)
– 10-100's of gigabytes
– container in MapR
i/o
10^3
map-red
10^6
resync
10^9
admin
HDFS 'block'
 Unit of Administration (snap,
repl, mirror, quota, backup)
– 1 gigabyte - 1000's of terabytes
– volume in MapR
– what data is affected by my
missing blocks?
28©MapR Technologies - Confidential
NameNode
E F
NameNode
E F
NameNode
E F
MapR's No-NameNode Architecture
HDFS Federation MapR (distributed metadata)
• Multiple single points of failure
• Limited to 50-200 million files
• Performance bottleneck
• Commercial NAS required
• HA w/ automatic failover
• Instant cluster restart
• Up to 1 trillion files
• 20x higher performance
• 100% commodity hardware
NAS
appliance
NameNode
A B
NameNode
C D
NameNode
E F
DataNode DataNode DataNode
DataNode DataNode DataNode
A F C D E D
B C E B
C F B F
A B
A D
E
29©MapR Technologies - Confidential
 Each container contains
 Directories & files
 Data blocks
 Replicated on servers
 Millions of containers in
a typical cluster
MapR's Distributed NameNode
Files/directories are sharded into blocks, which
are placed into mini NNs (containers ) on disks
Containers are 16-
32 GB segments of
disk, placed on
nodes
Patent Pending
30©MapR Technologies - Confidential
M7 Containers
 Container holds many files
– regular, dir, symlink, btree, chunk-map, region-map, …
– all random-write capable
– each can hold 100's of millions of files
 Container is replicated to servers
– unit of resynchronization
 Region lives entirely inside 1 container
– all files + WALs + btree's + bloom-filters + range-maps
31©MapR Technologies - Confidential
Read-write Replication
 Write are synchronous
– All copies have same data
 Data is replicated in a "chain"
fashion
– better bandwidth, utilizes full-
duplex network links well
 Meta-data is replicated in a "star"
manner
– response time better, bandwidth not
of concern
– data can also be done this way
31
client1
client2
clientN
33©MapR Technologies - Confidential
HB loss + upstream entity
reports failure
=> server dead
Increment epoch at CLDB
Rearrange replication
Exact same code for files
and M7 tables
No ZK needed at this level
Failure Handling
Containers managed at CLDB (HB, container-reports).
Container Location DataBase
(CLDB)
34©MapR Technologies - Confidential
Same 10 nodes, but with 3X repl
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
0 1000 2000 3000 4000 5000 6000
Filecreates/s
Files (M)
0 100 200 400 600 800 1000
MapR distribution
Other distribution
Benchmark: File creates (100B)
Hardware: 10 nodes, 2 x 4 cores, 24 GB
RAM, 12 x 1 TB 7200 RPM
0
50
100
150
200
250
300
350
400
0 0.5 1 1.5
Filecreates/s
Files (M)
Other distributionMapR Other Advantage
Rate (creates/s) 14-16K 335-360 40x
Scale (files) 6B 1.3M 4615x
35©MapR Technologies - Confidential
Recap
 HBase has a good basis
– But is handicapped by HDFS
– But can’t do without HDFS
– HBase can’t be fixed in isolation
 Separating key storage scaling parameters is key
– Allows additional layer of storage indirection
– Results in huge scaling and performance improvement
 Low-level transactions is hard
– Allows R/W file system, decentralized meta-data
– Also allows non-file implementations
36©MapR Technologies - Confidential
Part 2:
An implementation tour
37©MapR Technologies - Confidential
An Outline of Important Factors
 Start with MapR FS (mutability, transactions, real snapshots)
 C++ not Java (data never moves, better control)
 Lockless design, custom queue executive (3 ns switch)
 New RPC layer (> 1 M RPC / s)
 Cut out the middle man (single hop to data)
 Hybridize log-structured merge trees and B-trees
 Adjust sizes and fanouts
 Don’t be silly
38©MapR Technologies - Confidential
An Outline of Important Factors
 Start with MapR FS (mutability, transactions, real snapshots)
 C++ not Java (data never moves, better control)
 Lockless design, custom queue executive (3 ns switch)
 New RPC layer (> 1 M RPC / s)
 Cut out the middle man (single hop to data)
 Hybridize log-structured merge trees and B-trees
 Adjust sizes and fanouts
 Don’t be silly
We get these all for
free by putting
tables into MapR FS
39©MapR Technologies - Confidential
M7: Tables Integrated into Storage
No extra daemons to manage
One hop to data
Superior caching
policies
No JVM problems
40©MapR Technologies - Confidential
Lesson 0:
Implement
tables in the
file system
41©MapR Technologies - Confidential
Why Not Java?
 Disclaimer: I am a pro-Java bigot
 But that only goes so far …
 Consider the memory size of
struct {x, y}[] a;
 Consider also interpreting data as it has arrived from the wire
 Consider the problem of writing a micro-stack queue executive
with hundreds of thousands of threads and 3 ns context switch
 Consider the problem of a core-locked processes running cache
aware, lock-free, zero copy queue of tasks
 Consider the GC-free life-style
42©MapR Technologies - Confidential
At What Cost
 But writing performant C++ is hard
 Managing low-level threads is hard
 Implementing very fast failure recovery is hard
 Doing manual memory allocation is hard (and dangerous)
 Benefits outweigh costs with the right dev team
 Benefits dwarfed by the costs with the wrong dev team
43©MapR Technologies - Confidential
Lesson 1: With
great speed
comes great
responsibility
44©MapR Technologies - Confidential
M7 Table Architecture
table
tablet
tablet
partition
segmentsegment
parition
tablet tablet
45©MapR Technologies - Confidential
M7 Table Architecture
table
tablet
tablet
partition
segmentsegment
parition
tablet tablet
This structure is
internal and not
user-visible
46©MapR Technologies - Confidential
Multi-level Design
 Fixed number of levels like HBase
 Specialized fanout to match sizes to device physics
 Mutable file system allows chimeric LSM-tree / B-tree
 Sized to match container structure
 Guaranteed locality
– If the data moves, the new node will handle it
– If the node fails, the new node will handle it
47©MapR Technologies - Confidential
Lesson 2:
Physics. Not
just a good
idea. It’s the
law.
48©MapR Technologies - Confidential
RPC Reimplementation
 At very high data rates, protobuf is too slow
– Not good as an envelope, still a great schema definition language
– Most systems never hit this limit
 Alternative 1
– Lazy parsing allows deferral of content parsing
– Naïve implementation imposes (yet another) extra copy
 Alternative 2
– Bespoke parsing of envelope from the wire
– Content packages can land fully aligned and ready for battle directly from
the wire
 Let’s use BOTH ideas
49©MapR Technologies - Confidential
Lesson 3:
Hacking and
abstraction can
co-exist
50©MapR Technologies - Confidential
Don’t Be Silly
 Detailed review of the code revealed an extra copy
– It was subtle. Really.
 Performance increased when this was stopped
 Not as easy to spot as it sounds
– But absolutely still worth finding and fixing
51©MapR Technologies - Confidential
Part 3:
Results
52©MapR Technologies - Confidential
Server Reboot
 Full container-reports are tiny
– CLDB needs 2G dram for 1000-node cluster
 Volumes come online very fast
– each volume independent of others
– as soon as min-repl # of containers ready
– no need to wait for whole cluster
(eg, HDFS waits for 99.9% blocks reporting)
 1000-node cluster restart < 5 mins
53©MapR Technologies - Confidential
M7 provides Instant Recovery
 0-40 microWALs per region
– idle WALs go to zero quickly, so most are empty
– region is up before all microWALs are recovered
– recovers region in background in parallel
– when a key is accessed, that microWAL is recovered inline
– 1000-10000x faster recovery
 Why doesn't HBase do this?
– M7 leverages unique MapR-FS capabilities, not impacted by HDFS
limitations
– No limit to # of files on disk
– No limit to # open files
– I/O path translates random writes to sequential writes on disk
54©MapR Technologies - Confidential
Other M7 Features
 Smaller disk footprint
– M7 never repeats the key or column name
 Columnar layout
– M7 supports 64 column families
– in-memory column-families
 Online admin
– M7 schema changes on the fly
– delete/rename/redistribute tables
55©MapR Technologies - Confidential
Binary Compatible
 HBase applications work "as is" with M7
– No need to recompile (binary compatible)
 Can run M7 and HBase side-by-side on the same cluster
– eg, during a migration
– can access both M7 table and HBase table in same program
 Use standard Apache HBase CopyTable tool to copy a table
from HBase to M7 or vice-versa, viz.,
% hbase org.apache.hadoop.hbase.mapreduce.CopyTable
--new.name=/user/srivas/mytable oldtable
56©MapR Technologies - Confidential
M7 vs CDH - Mixed Load 50-50
57©MapR Technologies - Confidential
M7 vs CDH - Mixed Load 50-50
58©MapR Technologies - Confidential
M7 vs CDH - Mixed Load 50-50
59©MapR Technologies - Confidential
Recap
 HBase has some excellent core ideas
– But is burdened by years of technical debt
– Much of the debt was charged on the HDFS credit cards
 MapR FS provides ideal substrate for HBase-like service
– One hop from client to data
– Many problems never even exist in the first place
– Other problems have relatively simple solutions with better foundation
 Practical results bear out the theory
60©MapR Technologies - Confidential
Me, Us
 Ted Dunning, Chief Application Architect, MapR
Committer PMC member, Mahout, Zookeeper, Drill
Bought the beer at the first HUG
 MapR
Distributes more open source components for Hadoop
Adds major technology for performance and HA
Adds industry standard API’s
 Tonight
Hash tag - #nosqlnow #mapr #fast
See also - @ApacheMahout @ApacheDrill
@ted_dunning and @mapR
61©MapR Technologies - Confidential

Mais conteúdo relacionado

Mais procurados

MapR 5.2: Getting More Value from the MapR Converged Community Edition
MapR 5.2: Getting More Value from the MapR Converged Community EditionMapR 5.2: Getting More Value from the MapR Converged Community Edition
MapR 5.2: Getting More Value from the MapR Converged Community EditionMapR Technologies
 
Dchug m7-30 apr2013
Dchug m7-30 apr2013Dchug m7-30 apr2013
Dchug m7-30 apr2013jdfiori
 
Syncsort et le retour d'expérience ComScore
Syncsort et le retour d'expérience ComScoreSyncsort et le retour d'expérience ComScore
Syncsort et le retour d'expérience ComScoreModern Data Stack France
 
NYC Hadoop Meetup - MapR, Architecture, Philosophy and Applications
NYC Hadoop Meetup - MapR, Architecture, Philosophy and ApplicationsNYC Hadoop Meetup - MapR, Architecture, Philosophy and Applications
NYC Hadoop Meetup - MapR, Architecture, Philosophy and ApplicationsJason Shao
 
Marcel Kornacker: Impala tech talk Tue Feb 26th 2013
Marcel Kornacker: Impala tech talk Tue Feb 26th 2013Marcel Kornacker: Impala tech talk Tue Feb 26th 2013
Marcel Kornacker: Impala tech talk Tue Feb 26th 2013Modern Data Stack France
 
Hadoop Summit Amsterdam 2014: Capacity Planning In Multi-tenant Hadoop Deploy...
Hadoop Summit Amsterdam 2014: Capacity Planning In Multi-tenant Hadoop Deploy...Hadoop Summit Amsterdam 2014: Capacity Planning In Multi-tenant Hadoop Deploy...
Hadoop Summit Amsterdam 2014: Capacity Planning In Multi-tenant Hadoop Deploy...Sumeet Singh
 
20140228 - Singapore - BDAS - Ensuring Hadoop Production Success
20140228 - Singapore - BDAS - Ensuring Hadoop Production Success20140228 - Singapore - BDAS - Ensuring Hadoop Production Success
20140228 - Singapore - BDAS - Ensuring Hadoop Production SuccessAllen Day, PhD
 
Big Data Performance and Capacity Management
Big Data Performance and Capacity ManagementBig Data Performance and Capacity Management
Big Data Performance and Capacity Managementrightsize
 
Scale 12 x Efficient Multi-tenant Hadoop 2 Workloads with Yarn
Scale 12 x   Efficient Multi-tenant Hadoop 2 Workloads with YarnScale 12 x   Efficient Multi-tenant Hadoop 2 Workloads with Yarn
Scale 12 x Efficient Multi-tenant Hadoop 2 Workloads with YarnDavid Kaiser
 
Hive at Yahoo: Letters from the trenches
Hive at Yahoo: Letters from the trenchesHive at Yahoo: Letters from the trenches
Hive at Yahoo: Letters from the trenchesDataWorks Summit
 
Hive+Tez: A performance deep dive
Hive+Tez: A performance deep diveHive+Tez: A performance deep dive
Hive+Tez: A performance deep divet3rmin4t0r
 
Back to School - St. Louis Hadoop Meetup September 2016
Back to School - St. Louis Hadoop Meetup September 2016Back to School - St. Louis Hadoop Meetup September 2016
Back to School - St. Louis Hadoop Meetup September 2016Adam Doyle
 
February 2014 HUG : Tez Details and Insides
February 2014 HUG : Tez Details and InsidesFebruary 2014 HUG : Tez Details and Insides
February 2014 HUG : Tez Details and InsidesYahoo Developer Network
 
Hadoop configuration & performance tuning
Hadoop configuration & performance tuningHadoop configuration & performance tuning
Hadoop configuration & performance tuningVitthal Gogate
 
Hadoop_Its_Not_Just_Internal_Storage_V14
Hadoop_Its_Not_Just_Internal_Storage_V14Hadoop_Its_Not_Just_Internal_Storage_V14
Hadoop_Its_Not_Just_Internal_Storage_V14John Sing
 
Apache Hadoop YARN 3.x in Alibaba
Apache Hadoop YARN 3.x in AlibabaApache Hadoop YARN 3.x in Alibaba
Apache Hadoop YARN 3.x in AlibabaDataWorks Summit
 

Mais procurados (20)

MapR 5.2: Getting More Value from the MapR Converged Community Edition
MapR 5.2: Getting More Value from the MapR Converged Community EditionMapR 5.2: Getting More Value from the MapR Converged Community Edition
MapR 5.2: Getting More Value from the MapR Converged Community Edition
 
Dchug m7-30 apr2013
Dchug m7-30 apr2013Dchug m7-30 apr2013
Dchug m7-30 apr2013
 
Philly DB MapR Overview
Philly DB MapR OverviewPhilly DB MapR Overview
Philly DB MapR Overview
 
Syncsort et le retour d'expérience ComScore
Syncsort et le retour d'expérience ComScoreSyncsort et le retour d'expérience ComScore
Syncsort et le retour d'expérience ComScore
 
NYC Hadoop Meetup - MapR, Architecture, Philosophy and Applications
NYC Hadoop Meetup - MapR, Architecture, Philosophy and ApplicationsNYC Hadoop Meetup - MapR, Architecture, Philosophy and Applications
NYC Hadoop Meetup - MapR, Architecture, Philosophy and Applications
 
Marcel Kornacker: Impala tech talk Tue Feb 26th 2013
Marcel Kornacker: Impala tech talk Tue Feb 26th 2013Marcel Kornacker: Impala tech talk Tue Feb 26th 2013
Marcel Kornacker: Impala tech talk Tue Feb 26th 2013
 
Yahoo's Experience Running Pig on Tez at Scale
Yahoo's Experience Running Pig on Tez at ScaleYahoo's Experience Running Pig on Tez at Scale
Yahoo's Experience Running Pig on Tez at Scale
 
February 2014 HUG : Pig On Tez
February 2014 HUG : Pig On TezFebruary 2014 HUG : Pig On Tez
February 2014 HUG : Pig On Tez
 
Hadoop Summit Amsterdam 2014: Capacity Planning In Multi-tenant Hadoop Deploy...
Hadoop Summit Amsterdam 2014: Capacity Planning In Multi-tenant Hadoop Deploy...Hadoop Summit Amsterdam 2014: Capacity Planning In Multi-tenant Hadoop Deploy...
Hadoop Summit Amsterdam 2014: Capacity Planning In Multi-tenant Hadoop Deploy...
 
20140228 - Singapore - BDAS - Ensuring Hadoop Production Success
20140228 - Singapore - BDAS - Ensuring Hadoop Production Success20140228 - Singapore - BDAS - Ensuring Hadoop Production Success
20140228 - Singapore - BDAS - Ensuring Hadoop Production Success
 
Big Data Performance and Capacity Management
Big Data Performance and Capacity ManagementBig Data Performance and Capacity Management
Big Data Performance and Capacity Management
 
Scale 12 x Efficient Multi-tenant Hadoop 2 Workloads with Yarn
Scale 12 x   Efficient Multi-tenant Hadoop 2 Workloads with YarnScale 12 x   Efficient Multi-tenant Hadoop 2 Workloads with Yarn
Scale 12 x Efficient Multi-tenant Hadoop 2 Workloads with Yarn
 
Hive at Yahoo: Letters from the trenches
Hive at Yahoo: Letters from the trenchesHive at Yahoo: Letters from the trenches
Hive at Yahoo: Letters from the trenches
 
Hive+Tez: A performance deep dive
Hive+Tez: A performance deep diveHive+Tez: A performance deep dive
Hive+Tez: A performance deep dive
 
Back to School - St. Louis Hadoop Meetup September 2016
Back to School - St. Louis Hadoop Meetup September 2016Back to School - St. Louis Hadoop Meetup September 2016
Back to School - St. Louis Hadoop Meetup September 2016
 
February 2014 HUG : Tez Details and Insides
February 2014 HUG : Tez Details and InsidesFebruary 2014 HUG : Tez Details and Insides
February 2014 HUG : Tez Details and Insides
 
Hadoop configuration & performance tuning
Hadoop configuration & performance tuningHadoop configuration & performance tuning
Hadoop configuration & performance tuning
 
Hadoop_Its_Not_Just_Internal_Storage_V14
Hadoop_Its_Not_Just_Internal_Storage_V14Hadoop_Its_Not_Just_Internal_Storage_V14
Hadoop_Its_Not_Just_Internal_Storage_V14
 
Apache Hadoop YARN 3.x in Alibaba
Apache Hadoop YARN 3.x in AlibabaApache Hadoop YARN 3.x in Alibaba
Apache Hadoop YARN 3.x in Alibaba
 
2. hadoop fundamentals
2. hadoop fundamentals2. hadoop fundamentals
2. hadoop fundamentals
 

Destaque

Introduction to Apache HBase, MapR Tables and Security
Introduction to Apache HBase, MapR Tables and SecurityIntroduction to Apache HBase, MapR Tables and Security
Introduction to Apache HBase, MapR Tables and SecurityMapR Technologies
 
Apache Drill でたしなむ セルフサービスデータ探索 - 2014/11/06 Cloudera World Tokyo 2014 LTセッション
Apache Drill でたしなむ セルフサービスデータ探索 - 2014/11/06 Cloudera World Tokyo 2014 LTセッションApache Drill でたしなむ セルフサービスデータ探索 - 2014/11/06 Cloudera World Tokyo 2014 LTセッション
Apache Drill でたしなむ セルフサービスデータ探索 - 2014/11/06 Cloudera World Tokyo 2014 LTセッションMapR Technologies Japan
 
Hadoop benchmark: Evaluating Cloudera, Hortonworks, and MapR
Hadoop benchmark: Evaluating Cloudera, Hortonworks, and MapRHadoop benchmark: Evaluating Cloudera, Hortonworks, and MapR
Hadoop benchmark: Evaluating Cloudera, Hortonworks, and MapRDouglas Bernardini
 
20151128_SMeNG_態度は変えられるのか
20151128_SMeNG_態度は変えられるのか20151128_SMeNG_態度は変えられるのか
20151128_SMeNG_態度は変えられるのかTakanori Hiroe
 
20150321 医学:医療者教育研究ネットワーク@九州大学
20150321 医学:医療者教育研究ネットワーク@九州大学20150321 医学:医療者教育研究ネットワーク@九州大学
20150321 医学:医療者教育研究ネットワーク@九州大学Takanori Hiroe
 
HBase New Features
HBase New FeaturesHBase New Features
HBase New Featuresrxu
 
Apache Drill で日本語を扱ってみよう + オープンデータ解析
Apache Drill で日本語を扱ってみよう + オープンデータ解析Apache Drill で日本語を扱ってみよう + オープンデータ解析
Apache Drill で日本語を扱ってみよう + オープンデータ解析MapR Technologies Japan
 
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12MapR Technologies Japan
 
MapR Streams & MapR コンバージド・データ・プラットフォーム
MapR Streams & MapR コンバージド・データ・プラットフォームMapR Streams & MapR コンバージド・データ・プラットフォーム
MapR Streams & MapR コンバージド・データ・プラットフォームMapR Technologies Japan
 
20170225_Sample size determination
20170225_Sample size determination20170225_Sample size determination
20170225_Sample size determinationTakanori Hiroe
 
MapR Streams and MapR Converged Data Platform
MapR Streams and MapR Converged Data PlatformMapR Streams and MapR Converged Data Platform
MapR Streams and MapR Converged Data PlatformMapR Technologies
 
Big Data Hadoop Briefing Hosted by Cisco, WWT and MapR: MapR Overview Present...
Big Data Hadoop Briefing Hosted by Cisco, WWT and MapR: MapR Overview Present...Big Data Hadoop Briefing Hosted by Cisco, WWT and MapR: MapR Overview Present...
Big Data Hadoop Briefing Hosted by Cisco, WWT and MapR: MapR Overview Present...ervogler
 
ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan ...
ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan ...ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan ...
ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan ...MapR Technologies Japan
 
Evolving from RDBMS to NoSQL + SQL
Evolving from RDBMS to NoSQL + SQLEvolving from RDBMS to NoSQL + SQL
Evolving from RDBMS to NoSQL + SQLMapR Technologies
 
Docker1.13で変わったことをわからないなりにまとめてみた
Docker1.13で変わったことをわからないなりにまとめてみたDocker1.13で変わったことをわからないなりにまとめてみた
Docker1.13で変わったことをわからないなりにまとめてみたKouta Asai
 

Destaque (20)

MapR & Skytree:
MapR & Skytree: MapR & Skytree:
MapR & Skytree:
 
Introduction to Apache HBase, MapR Tables and Security
Introduction to Apache HBase, MapR Tables and SecurityIntroduction to Apache HBase, MapR Tables and Security
Introduction to Apache HBase, MapR Tables and Security
 
Apache Drill でたしなむ セルフサービスデータ探索 - 2014/11/06 Cloudera World Tokyo 2014 LTセッション
Apache Drill でたしなむ セルフサービスデータ探索 - 2014/11/06 Cloudera World Tokyo 2014 LTセッションApache Drill でたしなむ セルフサービスデータ探索 - 2014/11/06 Cloudera World Tokyo 2014 LTセッション
Apache Drill でたしなむ セルフサービスデータ探索 - 2014/11/06 Cloudera World Tokyo 2014 LTセッション
 
Apache Spark & Hadoop
Apache Spark & HadoopApache Spark & Hadoop
Apache Spark & Hadoop
 
Hadoop benchmark: Evaluating Cloudera, Hortonworks, and MapR
Hadoop benchmark: Evaluating Cloudera, Hortonworks, and MapRHadoop benchmark: Evaluating Cloudera, Hortonworks, and MapR
Hadoop benchmark: Evaluating Cloudera, Hortonworks, and MapR
 
20151128_SMeNG_態度は変えられるのか
20151128_SMeNG_態度は変えられるのか20151128_SMeNG_態度は変えられるのか
20151128_SMeNG_態度は変えられるのか
 
20150321 医学:医療者教育研究ネットワーク@九州大学
20150321 医学:医療者教育研究ネットワーク@九州大学20150321 医学:医療者教育研究ネットワーク@九州大学
20150321 医学:医療者教育研究ネットワーク@九州大学
 
JSME_47th_Nigata
JSME_47th_NigataJSME_47th_Nigata
JSME_47th_Nigata
 
20150827_simplesize
20150827_simplesize20150827_simplesize
20150827_simplesize
 
HBase New Features
HBase New FeaturesHBase New Features
HBase New Features
 
Apache Drill で日本語を扱ってみよう + オープンデータ解析
Apache Drill で日本語を扱ってみよう + オープンデータ解析Apache Drill で日本語を扱ってみよう + オープンデータ解析
Apache Drill で日本語を扱ってみよう + オープンデータ解析
 
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
 
MapR Streams & MapR コンバージド・データ・プラットフォーム
MapR Streams & MapR コンバージド・データ・プラットフォームMapR Streams & MapR コンバージド・データ・プラットフォーム
MapR Streams & MapR コンバージド・データ・プラットフォーム
 
20170225_Sample size determination
20170225_Sample size determination20170225_Sample size determination
20170225_Sample size determination
 
Drill超簡単チューニング
Drill超簡単チューニングDrill超簡単チューニング
Drill超簡単チューニング
 
MapR Streams and MapR Converged Data Platform
MapR Streams and MapR Converged Data PlatformMapR Streams and MapR Converged Data Platform
MapR Streams and MapR Converged Data Platform
 
Big Data Hadoop Briefing Hosted by Cisco, WWT and MapR: MapR Overview Present...
Big Data Hadoop Briefing Hosted by Cisco, WWT and MapR: MapR Overview Present...Big Data Hadoop Briefing Hosted by Cisco, WWT and MapR: MapR Overview Present...
Big Data Hadoop Briefing Hosted by Cisco, WWT and MapR: MapR Overview Present...
 
ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan ...
ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan ...ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan ...
ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan ...
 
Evolving from RDBMS to NoSQL + SQL
Evolving from RDBMS to NoSQL + SQLEvolving from RDBMS to NoSQL + SQL
Evolving from RDBMS to NoSQL + SQL
 
Docker1.13で変わったことをわからないなりにまとめてみた
Docker1.13で変わったことをわからないなりにまとめてみたDocker1.13で変わったことをわからないなりにまとめてみた
Docker1.13で変わったことをわからないなりにまとめてみた
 

Semelhante a Inside MapR's M7

TriHUG - Beyond Batch
TriHUG - Beyond BatchTriHUG - Beyond Batch
TriHUG - Beyond Batchboorad
 
2013 Nov 20 Toronto Hadoop User Group (THUG) - Hadoop 2.2.0
2013 Nov 20 Toronto Hadoop User Group (THUG) - Hadoop 2.2.02013 Nov 20 Toronto Hadoop User Group (THUG) - Hadoop 2.2.0
2013 Nov 20 Toronto Hadoop User Group (THUG) - Hadoop 2.2.0Adam Muise
 
Startup Case Study: Leveraging the Broad Hadoop Ecosystem to Develop World-Fi...
Startup Case Study: Leveraging the Broad Hadoop Ecosystem to Develop World-Fi...Startup Case Study: Leveraging the Broad Hadoop Ecosystem to Develop World-Fi...
Startup Case Study: Leveraging the Broad Hadoop Ecosystem to Develop World-Fi...DataWorks Summit
 
Apache Hadoop YARN - The Future of Data Processing with Hadoop
Apache Hadoop YARN - The Future of Data Processing with HadoopApache Hadoop YARN - The Future of Data Processing with Hadoop
Apache Hadoop YARN - The Future of Data Processing with HadoopHortonworks
 
SD Big Data Monthly Meetup #4 - Session 2 - WANDisco
SD Big Data Monthly Meetup #4 - Session 2 - WANDiscoSD Big Data Monthly Meetup #4 - Session 2 - WANDisco
SD Big Data Monthly Meetup #4 - Session 2 - WANDiscoBig Data Joe™ Rossi
 
Shift into High Gear: Dramatically Improve Hadoop & NoSQL Performance
Shift into High Gear: Dramatically Improve Hadoop & NoSQL PerformanceShift into High Gear: Dramatically Improve Hadoop & NoSQL Performance
Shift into High Gear: Dramatically Improve Hadoop & NoSQL PerformanceMapR Technologies
 
Big Data Analytics with Hadoop, MongoDB and SQL Server
Big Data Analytics with Hadoop, MongoDB and SQL ServerBig Data Analytics with Hadoop, MongoDB and SQL Server
Big Data Analytics with Hadoop, MongoDB and SQL ServerMark Kromer
 
Cloudera Operational DB (Apache HBase & Apache Phoenix)
Cloudera Operational DB (Apache HBase & Apache Phoenix)Cloudera Operational DB (Apache HBase & Apache Phoenix)
Cloudera Operational DB (Apache HBase & Apache Phoenix)Timothy Spann
 
Facebook keynote-nicolas-qcon
Facebook keynote-nicolas-qconFacebook keynote-nicolas-qcon
Facebook keynote-nicolas-qconYiwei Ma
 
支撑Facebook消息处理的h base存储系统
支撑Facebook消息处理的h base存储系统支撑Facebook消息处理的h base存储系统
支撑Facebook消息处理的h base存储系统yongboy
 
Facebook Messages & HBase
Facebook Messages & HBaseFacebook Messages & HBase
Facebook Messages & HBase强 王
 
HDFS- What is New and Future
HDFS- What is New and FutureHDFS- What is New and Future
HDFS- What is New and FutureDataWorks Summit
 
Large-scale Web Apps @ Pinterest
Large-scale Web Apps @ PinterestLarge-scale Web Apps @ Pinterest
Large-scale Web Apps @ PinterestHBaseCon
 
App cap2956v2-121001194956-phpapp01 (1)
App cap2956v2-121001194956-phpapp01 (1)App cap2956v2-121001194956-phpapp01 (1)
App cap2956v2-121001194956-phpapp01 (1)outstanding59
 
Inside the Hadoop Machine @ VMworld
Inside the Hadoop Machine @ VMworldInside the Hadoop Machine @ VMworld
Inside the Hadoop Machine @ VMworldRichard McDougall
 
App Cap2956v2 121001194956 Phpapp01 (1)
App Cap2956v2 121001194956 Phpapp01 (1)App Cap2956v2 121001194956 Phpapp01 (1)
App Cap2956v2 121001194956 Phpapp01 (1)outstanding59
 
Sept 17 2013 - THUG - HBase a Technical Introduction
Sept 17 2013 - THUG - HBase a Technical IntroductionSept 17 2013 - THUG - HBase a Technical Introduction
Sept 17 2013 - THUG - HBase a Technical IntroductionAdam Muise
 
HBase tales from the trenches
HBase tales from the trenchesHBase tales from the trenches
HBase tales from the trencheswchevreuil
 

Semelhante a Inside MapR's M7 (20)

HBase with MapR
HBase with MapRHBase with MapR
HBase with MapR
 
TriHUG - Beyond Batch
TriHUG - Beyond BatchTriHUG - Beyond Batch
TriHUG - Beyond Batch
 
2013 Nov 20 Toronto Hadoop User Group (THUG) - Hadoop 2.2.0
2013 Nov 20 Toronto Hadoop User Group (THUG) - Hadoop 2.2.02013 Nov 20 Toronto Hadoop User Group (THUG) - Hadoop 2.2.0
2013 Nov 20 Toronto Hadoop User Group (THUG) - Hadoop 2.2.0
 
Startup Case Study: Leveraging the Broad Hadoop Ecosystem to Develop World-Fi...
Startup Case Study: Leveraging the Broad Hadoop Ecosystem to Develop World-Fi...Startup Case Study: Leveraging the Broad Hadoop Ecosystem to Develop World-Fi...
Startup Case Study: Leveraging the Broad Hadoop Ecosystem to Develop World-Fi...
 
Apache Hadoop YARN - The Future of Data Processing with Hadoop
Apache Hadoop YARN - The Future of Data Processing with HadoopApache Hadoop YARN - The Future of Data Processing with Hadoop
Apache Hadoop YARN - The Future of Data Processing with Hadoop
 
SD Big Data Monthly Meetup #4 - Session 2 - WANDisco
SD Big Data Monthly Meetup #4 - Session 2 - WANDiscoSD Big Data Monthly Meetup #4 - Session 2 - WANDisco
SD Big Data Monthly Meetup #4 - Session 2 - WANDisco
 
Shift into High Gear: Dramatically Improve Hadoop & NoSQL Performance
Shift into High Gear: Dramatically Improve Hadoop & NoSQL PerformanceShift into High Gear: Dramatically Improve Hadoop & NoSQL Performance
Shift into High Gear: Dramatically Improve Hadoop & NoSQL Performance
 
Big Data Analytics with Hadoop, MongoDB and SQL Server
Big Data Analytics with Hadoop, MongoDB and SQL ServerBig Data Analytics with Hadoop, MongoDB and SQL Server
Big Data Analytics with Hadoop, MongoDB and SQL Server
 
Cloudera Operational DB (Apache HBase & Apache Phoenix)
Cloudera Operational DB (Apache HBase & Apache Phoenix)Cloudera Operational DB (Apache HBase & Apache Phoenix)
Cloudera Operational DB (Apache HBase & Apache Phoenix)
 
Facebook keynote-nicolas-qcon
Facebook keynote-nicolas-qconFacebook keynote-nicolas-qcon
Facebook keynote-nicolas-qcon
 
支撑Facebook消息处理的h base存储系统
支撑Facebook消息处理的h base存储系统支撑Facebook消息处理的h base存储系统
支撑Facebook消息处理的h base存储系统
 
Facebook Messages & HBase
Facebook Messages & HBaseFacebook Messages & HBase
Facebook Messages & HBase
 
HDFS- What is New and Future
HDFS- What is New and FutureHDFS- What is New and Future
HDFS- What is New and Future
 
Large-scale Web Apps @ Pinterest
Large-scale Web Apps @ PinterestLarge-scale Web Apps @ Pinterest
Large-scale Web Apps @ Pinterest
 
Hbase: an introduction
Hbase: an introductionHbase: an introduction
Hbase: an introduction
 
App cap2956v2-121001194956-phpapp01 (1)
App cap2956v2-121001194956-phpapp01 (1)App cap2956v2-121001194956-phpapp01 (1)
App cap2956v2-121001194956-phpapp01 (1)
 
Inside the Hadoop Machine @ VMworld
Inside the Hadoop Machine @ VMworldInside the Hadoop Machine @ VMworld
Inside the Hadoop Machine @ VMworld
 
App Cap2956v2 121001194956 Phpapp01 (1)
App Cap2956v2 121001194956 Phpapp01 (1)App Cap2956v2 121001194956 Phpapp01 (1)
App Cap2956v2 121001194956 Phpapp01 (1)
 
Sept 17 2013 - THUG - HBase a Technical Introduction
Sept 17 2013 - THUG - HBase a Technical IntroductionSept 17 2013 - THUG - HBase a Technical Introduction
Sept 17 2013 - THUG - HBase a Technical Introduction
 
HBase tales from the trenches
HBase tales from the trenchesHBase tales from the trenches
HBase tales from the trenches
 

Mais de Ted Dunning

Dunning - SIGMOD - Data Economy.pptx
Dunning - SIGMOD - Data Economy.pptxDunning - SIGMOD - Data Economy.pptx
Dunning - SIGMOD - Data Economy.pptxTed Dunning
 
How to Get Going with Kubernetes
How to Get Going with KubernetesHow to Get Going with Kubernetes
How to Get Going with KubernetesTed Dunning
 
Progress for big data in Kubernetes
Progress for big data in KubernetesProgress for big data in Kubernetes
Progress for big data in KubernetesTed Dunning
 
Anomaly Detection: How to find what you didn’t know to look for
Anomaly Detection: How to find what you didn’t know to look forAnomaly Detection: How to find what you didn’t know to look for
Anomaly Detection: How to find what you didn’t know to look forTed Dunning
 
Streaming Architecture including Rendezvous for Machine Learning
Streaming Architecture including Rendezvous for Machine LearningStreaming Architecture including Rendezvous for Machine Learning
Streaming Architecture including Rendezvous for Machine LearningTed Dunning
 
Machine Learning Logistics
Machine Learning LogisticsMachine Learning Logistics
Machine Learning LogisticsTed Dunning
 
Tensor Abuse - how to reuse machine learning frameworks
Tensor Abuse - how to reuse machine learning frameworksTensor Abuse - how to reuse machine learning frameworks
Tensor Abuse - how to reuse machine learning frameworksTed Dunning
 
Machine Learning logistics
Machine Learning logisticsMachine Learning logistics
Machine Learning logisticsTed Dunning
 
Finding Changes in Real Data
Finding Changes in Real DataFinding Changes in Real Data
Finding Changes in Real DataTed Dunning
 
Where is Data Going? - RMDC Keynote
Where is Data Going? - RMDC KeynoteWhere is Data Going? - RMDC Keynote
Where is Data Going? - RMDC KeynoteTed Dunning
 
Real time-hadoop
Real time-hadoopReal time-hadoop
Real time-hadoopTed Dunning
 
Cheap learning-dunning-9-18-2015
Cheap learning-dunning-9-18-2015Cheap learning-dunning-9-18-2015
Cheap learning-dunning-9-18-2015Ted Dunning
 
Sharing Sensitive Data Securely
Sharing Sensitive Data SecurelySharing Sensitive Data Securely
Sharing Sensitive Data SecurelyTed Dunning
 
Real-time Puppies and Ponies - Evolving Indicator Recommendations in Real-time
Real-time Puppies and Ponies - Evolving Indicator Recommendations in Real-timeReal-time Puppies and Ponies - Evolving Indicator Recommendations in Real-time
Real-time Puppies and Ponies - Evolving Indicator Recommendations in Real-timeTed Dunning
 
How the Internet of Things is Turning the Internet Upside Down
How the Internet of Things is Turning the Internet Upside DownHow the Internet of Things is Turning the Internet Upside Down
How the Internet of Things is Turning the Internet Upside DownTed Dunning
 
Apache Kylin - OLAP Cubes for SQL on Hadoop
Apache Kylin - OLAP Cubes for SQL on HadoopApache Kylin - OLAP Cubes for SQL on Hadoop
Apache Kylin - OLAP Cubes for SQL on HadoopTed Dunning
 
Dunning time-series-2015
Dunning time-series-2015Dunning time-series-2015
Dunning time-series-2015Ted Dunning
 
Doing-the-impossible
Doing-the-impossibleDoing-the-impossible
Doing-the-impossibleTed Dunning
 
Anomaly Detection - New York Machine Learning
Anomaly Detection - New York Machine LearningAnomaly Detection - New York Machine Learning
Anomaly Detection - New York Machine LearningTed Dunning
 

Mais de Ted Dunning (20)

Dunning - SIGMOD - Data Economy.pptx
Dunning - SIGMOD - Data Economy.pptxDunning - SIGMOD - Data Economy.pptx
Dunning - SIGMOD - Data Economy.pptx
 
How to Get Going with Kubernetes
How to Get Going with KubernetesHow to Get Going with Kubernetes
How to Get Going with Kubernetes
 
Progress for big data in Kubernetes
Progress for big data in KubernetesProgress for big data in Kubernetes
Progress for big data in Kubernetes
 
Anomaly Detection: How to find what you didn’t know to look for
Anomaly Detection: How to find what you didn’t know to look forAnomaly Detection: How to find what you didn’t know to look for
Anomaly Detection: How to find what you didn’t know to look for
 
Streaming Architecture including Rendezvous for Machine Learning
Streaming Architecture including Rendezvous for Machine LearningStreaming Architecture including Rendezvous for Machine Learning
Streaming Architecture including Rendezvous for Machine Learning
 
Machine Learning Logistics
Machine Learning LogisticsMachine Learning Logistics
Machine Learning Logistics
 
Tensor Abuse - how to reuse machine learning frameworks
Tensor Abuse - how to reuse machine learning frameworksTensor Abuse - how to reuse machine learning frameworks
Tensor Abuse - how to reuse machine learning frameworks
 
Machine Learning logistics
Machine Learning logisticsMachine Learning logistics
Machine Learning logistics
 
T digest-update
T digest-updateT digest-update
T digest-update
 
Finding Changes in Real Data
Finding Changes in Real DataFinding Changes in Real Data
Finding Changes in Real Data
 
Where is Data Going? - RMDC Keynote
Where is Data Going? - RMDC KeynoteWhere is Data Going? - RMDC Keynote
Where is Data Going? - RMDC Keynote
 
Real time-hadoop
Real time-hadoopReal time-hadoop
Real time-hadoop
 
Cheap learning-dunning-9-18-2015
Cheap learning-dunning-9-18-2015Cheap learning-dunning-9-18-2015
Cheap learning-dunning-9-18-2015
 
Sharing Sensitive Data Securely
Sharing Sensitive Data SecurelySharing Sensitive Data Securely
Sharing Sensitive Data Securely
 
Real-time Puppies and Ponies - Evolving Indicator Recommendations in Real-time
Real-time Puppies and Ponies - Evolving Indicator Recommendations in Real-timeReal-time Puppies and Ponies - Evolving Indicator Recommendations in Real-time
Real-time Puppies and Ponies - Evolving Indicator Recommendations in Real-time
 
How the Internet of Things is Turning the Internet Upside Down
How the Internet of Things is Turning the Internet Upside DownHow the Internet of Things is Turning the Internet Upside Down
How the Internet of Things is Turning the Internet Upside Down
 
Apache Kylin - OLAP Cubes for SQL on Hadoop
Apache Kylin - OLAP Cubes for SQL on HadoopApache Kylin - OLAP Cubes for SQL on Hadoop
Apache Kylin - OLAP Cubes for SQL on Hadoop
 
Dunning time-series-2015
Dunning time-series-2015Dunning time-series-2015
Dunning time-series-2015
 
Doing-the-impossible
Doing-the-impossibleDoing-the-impossible
Doing-the-impossible
 
Anomaly Detection - New York Machine Learning
Anomaly Detection - New York Machine LearningAnomaly Detection - New York Machine Learning
Anomaly Detection - New York Machine Learning
 

Último

Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
The Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API ManagementThe Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API ManagementNuwan Dias
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
All in AI: LLM Landscape & RAG in 2024 with Mark Ryan (Google) & Jerry Liu (L...
All in AI: LLM Landscape & RAG in 2024 with Mark Ryan (Google) & Jerry Liu (L...All in AI: LLM Landscape & RAG in 2024 with Mark Ryan (Google) & Jerry Liu (L...
All in AI: LLM Landscape & RAG in 2024 with Mark Ryan (Google) & Jerry Liu (L...Daniel Zivkovic
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Commit University
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 

Último (20)

Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
20230104 - machine vision
20230104 - machine vision20230104 - machine vision
20230104 - machine vision
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
The Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API ManagementThe Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API Management
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
All in AI: LLM Landscape & RAG in 2024 with Mark Ryan (Google) & Jerry Liu (L...
All in AI: LLM Landscape & RAG in 2024 with Mark Ryan (Google) & Jerry Liu (L...All in AI: LLM Landscape & RAG in 2024 with Mark Ryan (Google) & Jerry Liu (L...
All in AI: LLM Landscape & RAG in 2024 with Mark Ryan (Google) & Jerry Liu (L...
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 

Inside MapR's M7

  • 1. 1©MapR Technologies - Confidential Inside MapR’s M7 How to get a million ops per second on 10 nodes
  • 2. 2©MapR Technologies - Confidential Me, Us  Ted Dunning, Chief Application Architect, MapR Committer PMC member, Mahout, Zookeeper, Drill Bought the beer at the first HUG  MapR Distributes more open source components for Hadoop Adds major technology for performance, HA, industry standard API’s  Tonight Hash tag - #mapr #fast See also - @ApacheMahout @ApacheDrill @ted_dunning and @mapR
  • 3. 3©MapR Technologies - Confidential MapR does MapReduce (fast) TeraSort Record 1 TB in 54 seconds 1003 nodes MinuteSort Record 1.5 TB in 59 seconds 2103 nodes
  • 4. 4©MapR Technologies - Confidential MapR: Lights Out Data Center Ready • Automated stateful failover • Automated re-replication • Self-healing from HW and SW failures • Load balancing • Rolling upgrades • No lost jobs or data • 99999’s of uptime Reliable Compute Dependable Storage • Business continuity with snapshots and mirrors • Recover to a point in time • End-to-end check summing • Strong consistency • Built-in compression • Mirror between two sites by RTO policy
  • 5. 5©MapR Technologies - Confidential Part 1: What’s past is prologue
  • 6. 6©MapR Technologies - Confidential Part 1: What’s past is prologue HBase is really good except when it isn’t but it has a heart of gold
  • 7. 7©MapR Technologies - Confidential Part 2: An implementation tour
  • 8. 8©MapR Technologies - Confidential Part 2: An implementation tour with many tricks and clever ploys
  • 9. 9©MapR Technologies - Confidential Part 3: Results
  • 10. 10©MapR Technologies - Confidential
  • 11. 11©MapR Technologies - Confidential Part 1: What’s past is prologue
  • 12. 12©MapR Technologies - Confidential Dynamo DB ZopeDB Shoal CloudKit Vertex DB FlockD B NoSQL
  • 13. 13©MapR Technologies - Confidential HBase Table Architecture  Tables are divided into key ranges (regions)  Regions are served by nodes (RegionServers)  Columns are divided into access groups (columns families) CF1 CF2 CF3 CF4 CF5 R1 R2 R3 R4
  • 14. 14©MapR Technologies - Confidential HBase Architecture is Better  Strong consistency model – when a write returns, all readers will see same value – "eventually consistent" is often "eventually inconsistent"  Scan works – does not broadcast – ring-based NoSQL databases (eg, Cassandra, Riak) suffer on scans  Scales automatically – Splits when regions become too large – Uses HDFS to spread data, manage space  Integrated with Hadoop – map-reduce on HBase is straightforward
  • 15. 15©MapR Technologies - Confidential But ... how well do you know HBCK? a.k.a. HBase Recovery  HBase-5843: Improve HBase MTTR – Mean Time To Recover  HBase-6401: HBase may lose edits after a crash with 1.0.3 – uses appends  HBase-3809: .META. may not come back online if ….  etc  about 40-50 Jiras on this topic  Very complex algorithm to assign a region – and still does not get it right on reboot
  • 16. 16©MapR Technologies - Confidential HBase Issues Reliability •Compactions disrupt operations •Very slow crash recovery •Unreliable splitting Business continuity •Common hardware/software issues cause downtime •Administration requires downtime •No point-in-time recovery •Complex backup process Performance •Many bottlenecks result in low throughput •Limited data locality •Limited # of tables Manageability •Compactions, splits and merges must be done manually (in reality) •Basic operations like backup or table rename are complex
  • 17. 17©MapR Technologies - Confidential Examples: Performance Issues  Limited support for multiple column families: HBase has issues handling multiple column family due to compactions. The standard HBase documentation recommends no more than 2-3 column families. (HBASE-3149)  Limited data locality: HBase does not take into account block locations when assigning regions. After a reboot, RegionServers are often reading data over the network rather than the local drives. (HBASE-4755, HBASE-4491)  Cannot utilize disk space: HBase RegionServers struggle with more than 50-150 regions per RegionServer so a commodity server can only handle about 1TB of HBase data, wasting disk space. (http://hbase.apache.org/book/important_configurations.html, http://www.cloudera.com/blog/2011/04/hbase-dos-and-donts/)  Limited # of tables: A single cluster can only handle several tens of tables effectively. (http://hbase.apache.org/book/important_configurations.html)
  • 18. 18©MapR Technologies - Confidential Examples: Manageability Issues  Manual major compactions: HBase major compactions are disruptive so production clusters keep them disabled and rely on the administrator to manually trigger compactions. (http://hbase.apache.org/book.html#compaction)  Manual splitting: HBase auto-splitting does not work properly in a busy cluster so users must pre-split a table based on their estimate of data size/growth. (http://chilinglam.blogspot.com/2011/12/my-experience- with-hbase-dynamic.html)  Manual merging: HBase does not automatically merge regions that are too small. The administrator must take down the cluster and trigger the merges manually.  Basic administration is complex: Renaming a table requires copying all the data. Backing up a cluster is a complex process. (HBASE-643)
  • 19. 19©MapR Technologies - Confidential Examples: Reliability Issues  Compactions disrupt HBase operations: I/O bursts overwhelm nodes (http://hbase.apache.org/book.html#compaction)  Very slow crash recovery: RegionServer crash can cause data to be unavailable for up to 30 minutes while WALs are replayed for impacted regions. (HBASE-1111)  Unreliable splitting: Region splitting may cause data to be inconsistent and unavailable. (http://chilinglam.blogspot.com/2011/12/my-experience-with- hbase-dynamic.html)  No client throttling: HBase client can easily overwhelm RegionServers and cause downtime. (HBASE-5161, HBASE-5162)
  • 20. 20©MapR Technologies - Confidential One Issue – Crash Recovery Too Slow  HBASE-1111 superseded by HBASE-5843 which is blocked by HDFS-3912 HBASE-6736 HBASE-6970 HBASE-7989 HBASE-6315 HBASE-7815 HBASE-6737 HBASE-6738 HBASE-7271 HBASE-7590 HBASE-7756 HBASE-8204 HBASE-5992 HBASE-6156 HBASE-6878 HBASE-6364 HBASE-6713 HBASE-5902 HBASE-4755 HBASE-7006 HDFS-2576 HBASE-6309 HBASE-6751 HBASE-6752 HBASE-6772 HBASE-6773 HBASE-6774 HBASE-7246 HBASE-7334 HBASE-5859 HBASE-6058 HBASE-6290 HBASE-7213 HBASE-5844 HBASE-5924 HBASE-6435 HBASE-6783 HBASE-7247 HBASE-7327 HDFS-4721 HBASE-5877 HBASE-5926 HBASE-5939 HBASE-5998 HBASE-6109 HBASE-6870 HBASE-5930 HDFS-4754 HDFS-3705
  • 21. 21©MapR Technologies - Confidential What is the source of these problems?
  • 22. 22©MapR Technologies - Confidential RegionServers are problematic  Coordinating 3 separate distributed systems is very hard – HBase, HDFS, ZK – Each of these systems has multiple internal systems – Too many races, too many undefined properties  Distributed transaction framework not available – Too many failures to deal with  Java GC wipes out the RS from time to time – Cannot use -Xmx20g for a RS  Hence all the bugs – HBCK is your "friend"
  • 23. 23©MapR Technologies - Confidential Region Assignment in Apache HBase
  • 24. 24©MapR Technologies - Confidential  Files are broken into blocks  Distributed across data-nodes  NameNode holds (in DRAM)  Directories, Files  Block replica locations  Data Nodes  Serve blocks  No idea about files/dirs  All ops go to NN HDFS Architecture Review DataNodes save Blocks Files sharded into blocks
  • 25. 25©MapR Technologies - Confidential  NameNode holds in-memory  Dir hierarchy ("names")  File attrs ("inode")  Composite file structure  Array of block-ids  1-byte file in HDFS  1 HDFS "block" on 3 DN's  3 entries in NN totaling 1K DRAM A File at the NameNode Composite File Structure
  • 26. 26©MapR Technologies - Confidential DN reports blocks to NN – 128M blocks – 12T of disk => DN sends 100K blocks/report – RPC on wire is 4M – causes extreme load • at both DN and NN  With NN-HA, DN's do dual block-reports – one to primary, one to secondary – doubles the load on DN NN scalability problems
  • 27. 27©MapR Technologies - Confidential Scaling Parameters  Unit of I/O – 4K/8K (8K in MapR)  Unit of Chunking (a map-reduce split) – 10-100's of megabytes  Unit of Resync (a replica) – 10-100's of gigabytes – container in MapR i/o 10^3 map-red 10^6 resync 10^9 admin HDFS 'block'  Unit of Administration (snap, repl, mirror, quota, backup) – 1 gigabyte - 1000's of terabytes – volume in MapR – what data is affected by my missing blocks?
  • 28. 28©MapR Technologies - Confidential NameNode E F NameNode E F NameNode E F MapR's No-NameNode Architecture HDFS Federation MapR (distributed metadata) • Multiple single points of failure • Limited to 50-200 million files • Performance bottleneck • Commercial NAS required • HA w/ automatic failover • Instant cluster restart • Up to 1 trillion files • 20x higher performance • 100% commodity hardware NAS appliance NameNode A B NameNode C D NameNode E F DataNode DataNode DataNode DataNode DataNode DataNode A F C D E D B C E B C F B F A B A D E
  • 29. 29©MapR Technologies - Confidential  Each container contains  Directories & files  Data blocks  Replicated on servers  Millions of containers in a typical cluster MapR's Distributed NameNode Files/directories are sharded into blocks, which are placed into mini NNs (containers ) on disks Containers are 16- 32 GB segments of disk, placed on nodes Patent Pending
  • 30. 30©MapR Technologies - Confidential M7 Containers  Container holds many files – regular, dir, symlink, btree, chunk-map, region-map, … – all random-write capable – each can hold 100's of millions of files  Container is replicated to servers – unit of resynchronization  Region lives entirely inside 1 container – all files + WALs + btree's + bloom-filters + range-maps
  • 31. 31©MapR Technologies - Confidential Read-write Replication  Write are synchronous – All copies have same data  Data is replicated in a "chain" fashion – better bandwidth, utilizes full- duplex network links well  Meta-data is replicated in a "star" manner – response time better, bandwidth not of concern – data can also be done this way 31 client1 client2 clientN
  • 32. 33©MapR Technologies - Confidential HB loss + upstream entity reports failure => server dead Increment epoch at CLDB Rearrange replication Exact same code for files and M7 tables No ZK needed at this level Failure Handling Containers managed at CLDB (HB, container-reports). Container Location DataBase (CLDB)
  • 33. 34©MapR Technologies - Confidential Same 10 nodes, but with 3X repl 0 2000 4000 6000 8000 10000 12000 14000 16000 18000 0 1000 2000 3000 4000 5000 6000 Filecreates/s Files (M) 0 100 200 400 600 800 1000 MapR distribution Other distribution Benchmark: File creates (100B) Hardware: 10 nodes, 2 x 4 cores, 24 GB RAM, 12 x 1 TB 7200 RPM 0 50 100 150 200 250 300 350 400 0 0.5 1 1.5 Filecreates/s Files (M) Other distributionMapR Other Advantage Rate (creates/s) 14-16K 335-360 40x Scale (files) 6B 1.3M 4615x
  • 34. 35©MapR Technologies - Confidential Recap  HBase has a good basis – But is handicapped by HDFS – But can’t do without HDFS – HBase can’t be fixed in isolation  Separating key storage scaling parameters is key – Allows additional layer of storage indirection – Results in huge scaling and performance improvement  Low-level transactions is hard – Allows R/W file system, decentralized meta-data – Also allows non-file implementations
  • 35. 36©MapR Technologies - Confidential Part 2: An implementation tour
  • 36. 37©MapR Technologies - Confidential An Outline of Important Factors  Start with MapR FS (mutability, transactions, real snapshots)  C++ not Java (data never moves, better control)  Lockless design, custom queue executive (3 ns switch)  New RPC layer (> 1 M RPC / s)  Cut out the middle man (single hop to data)  Hybridize log-structured merge trees and B-trees  Adjust sizes and fanouts  Don’t be silly
  • 37. 38©MapR Technologies - Confidential An Outline of Important Factors  Start with MapR FS (mutability, transactions, real snapshots)  C++ not Java (data never moves, better control)  Lockless design, custom queue executive (3 ns switch)  New RPC layer (> 1 M RPC / s)  Cut out the middle man (single hop to data)  Hybridize log-structured merge trees and B-trees  Adjust sizes and fanouts  Don’t be silly We get these all for free by putting tables into MapR FS
  • 38. 39©MapR Technologies - Confidential M7: Tables Integrated into Storage No extra daemons to manage One hop to data Superior caching policies No JVM problems
  • 39. 40©MapR Technologies - Confidential Lesson 0: Implement tables in the file system
  • 40. 41©MapR Technologies - Confidential Why Not Java?  Disclaimer: I am a pro-Java bigot  But that only goes so far …  Consider the memory size of struct {x, y}[] a;  Consider also interpreting data as it has arrived from the wire  Consider the problem of writing a micro-stack queue executive with hundreds of thousands of threads and 3 ns context switch  Consider the problem of a core-locked processes running cache aware, lock-free, zero copy queue of tasks  Consider the GC-free life-style
  • 41. 42©MapR Technologies - Confidential At What Cost  But writing performant C++ is hard  Managing low-level threads is hard  Implementing very fast failure recovery is hard  Doing manual memory allocation is hard (and dangerous)  Benefits outweigh costs with the right dev team  Benefits dwarfed by the costs with the wrong dev team
  • 42. 43©MapR Technologies - Confidential Lesson 1: With great speed comes great responsibility
  • 43. 44©MapR Technologies - Confidential M7 Table Architecture table tablet tablet partition segmentsegment parition tablet tablet
  • 44. 45©MapR Technologies - Confidential M7 Table Architecture table tablet tablet partition segmentsegment parition tablet tablet This structure is internal and not user-visible
  • 45. 46©MapR Technologies - Confidential Multi-level Design  Fixed number of levels like HBase  Specialized fanout to match sizes to device physics  Mutable file system allows chimeric LSM-tree / B-tree  Sized to match container structure  Guaranteed locality – If the data moves, the new node will handle it – If the node fails, the new node will handle it
  • 46. 47©MapR Technologies - Confidential Lesson 2: Physics. Not just a good idea. It’s the law.
  • 47. 48©MapR Technologies - Confidential RPC Reimplementation  At very high data rates, protobuf is too slow – Not good as an envelope, still a great schema definition language – Most systems never hit this limit  Alternative 1 – Lazy parsing allows deferral of content parsing – Naïve implementation imposes (yet another) extra copy  Alternative 2 – Bespoke parsing of envelope from the wire – Content packages can land fully aligned and ready for battle directly from the wire  Let’s use BOTH ideas
  • 48. 49©MapR Technologies - Confidential Lesson 3: Hacking and abstraction can co-exist
  • 49. 50©MapR Technologies - Confidential Don’t Be Silly  Detailed review of the code revealed an extra copy – It was subtle. Really.  Performance increased when this was stopped  Not as easy to spot as it sounds – But absolutely still worth finding and fixing
  • 50. 51©MapR Technologies - Confidential Part 3: Results
  • 51. 52©MapR Technologies - Confidential Server Reboot  Full container-reports are tiny – CLDB needs 2G dram for 1000-node cluster  Volumes come online very fast – each volume independent of others – as soon as min-repl # of containers ready – no need to wait for whole cluster (eg, HDFS waits for 99.9% blocks reporting)  1000-node cluster restart < 5 mins
  • 52. 53©MapR Technologies - Confidential M7 provides Instant Recovery  0-40 microWALs per region – idle WALs go to zero quickly, so most are empty – region is up before all microWALs are recovered – recovers region in background in parallel – when a key is accessed, that microWAL is recovered inline – 1000-10000x faster recovery  Why doesn't HBase do this? – M7 leverages unique MapR-FS capabilities, not impacted by HDFS limitations – No limit to # of files on disk – No limit to # open files – I/O path translates random writes to sequential writes on disk
  • 53. 54©MapR Technologies - Confidential Other M7 Features  Smaller disk footprint – M7 never repeats the key or column name  Columnar layout – M7 supports 64 column families – in-memory column-families  Online admin – M7 schema changes on the fly – delete/rename/redistribute tables
  • 54. 55©MapR Technologies - Confidential Binary Compatible  HBase applications work "as is" with M7 – No need to recompile (binary compatible)  Can run M7 and HBase side-by-side on the same cluster – eg, during a migration – can access both M7 table and HBase table in same program  Use standard Apache HBase CopyTable tool to copy a table from HBase to M7 or vice-versa, viz., % hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=/user/srivas/mytable oldtable
  • 55. 56©MapR Technologies - Confidential M7 vs CDH - Mixed Load 50-50
  • 56. 57©MapR Technologies - Confidential M7 vs CDH - Mixed Load 50-50
  • 57. 58©MapR Technologies - Confidential M7 vs CDH - Mixed Load 50-50
  • 58. 59©MapR Technologies - Confidential Recap  HBase has some excellent core ideas – But is burdened by years of technical debt – Much of the debt was charged on the HDFS credit cards  MapR FS provides ideal substrate for HBase-like service – One hop from client to data – Many problems never even exist in the first place – Other problems have relatively simple solutions with better foundation  Practical results bear out the theory
  • 59. 60©MapR Technologies - Confidential Me, Us  Ted Dunning, Chief Application Architect, MapR Committer PMC member, Mahout, Zookeeper, Drill Bought the beer at the first HUG  MapR Distributes more open source components for Hadoop Adds major technology for performance and HA Adds industry standard API’s  Tonight Hash tag - #nosqlnow #mapr #fast See also - @ApacheMahout @ApacheDrill @ted_dunning and @mapR
  • 60. 61©MapR Technologies - Confidential

Notas do Editor

  1. The Namenode today in Hadoop is a single point of failure, a scalability limitation, and a performance bottleneck.With MapR there is no dedicated NameNode. The NameNode function is distributed across the cluster. This provides major advantages in terms of HA, data loss avoidance, scalability and performance. Other distributions you have a bottleneck regardless of the number of nodes in the cluster. With other distributions the most number of files that you can support is 200M at the maximum and that is with an extremely high end server. 50% of the processing of Hadoop in Facebook is to pack and unpack files to try to work around this limitation. MapR scales uniformly.
  2. Another major advantage with MapR is the distributed Namenode. The Namenode today in Hadoop is a single point of failure, a scalability limitation, and a performance bottleneck.With MapR there is no dedicated NameNode. The NameNode function is distributed across the cluster. This provides major advantages in terms of HA, data loss avoidance, scalability and performance. Other distributions you have a bottleneck regardless of the number of nodes in the cluster. With other distributions the most number of files that you can support is between 70-100M. 50% of the processing of Hadoop in Facebook is to pack and unpack files to try to work around this limitation. MapR scales uniformly.
  3. This slide needs a lot of work. Can you look at layout changes?
  4. The Namenode today in Hadoop is a single point of failure, a scalability limitation, and a performance bottleneck.With MapR there is no dedicated NameNode. The NameNode function is distributed across the cluster. This provides major advantages in terms of HA, data loss avoidance, scalability and performance. Other distributions you have a bottleneck regardless of the number of nodes in the cluster. With other distributions the most number of files that you can support is 200M at the maximum and that is with an extremely high end server. 50% of the processing of Hadoop in Facebook is to pack and unpack files to try to work around this limitation. MapR scales uniformly.