DEVIEW2015 DAY2. 수퍼컴퓨팅과 데이터 어낼리틱스

1. 슈퍼컴퓨팅과 데이터
어낼리틱스 프레임워크,
그리고 유니스트의
빅데이터 처리 프레임워크
남범석
UNIST (울산과학기술원)

2. contents
1. 슈퍼컴퓨팅과 빅데이터
2. UNIST의 빅데이터 분석 플랫폼
3. 맺음말

3. 1.
Supercomputing &
BigData

4. Supercomputing
• High Performance Computing
• Scientific Computing
• Data Intensive Computing
• Computational Science
/Rocket Science
• High-end Computing

5. Supercomputing 아키텍처
1980’s 1990’s 2000’s
Source: Top 500

6. Supercomputing Today
- Clusters of commodity (Intel/AMD x86) HW & IBM bluegene
- High-speed, low-latency interconnect (Infiniband)
- Coprocessors (GPU, Xeon Phi)
- Storage area networks (SANs) & local disks for temporary files
Hardware ecosystem

7. High-end Computing & Industry
HPC
ENIAC (1946) 최초 Business Computer (1951)
CERN 통신 시스템(1989)
FTP, Gopher, NNTP (1969)
NCSA Mosaic (1993)
World Wide Web
dot-com bubble (1997~)

8. High-end Computing & Industry
HPC
Active Data Repository (1998)
BigData/Hadoop (2005)
Grid Computing (1998)
Amazon EC2 (2006)

9. HPC & Industry
Innovation & Growth
Money

10. 2008
Source: Top 500

11. Recession & HPC
Exa 스케일? 연간 수천만달러 전기세
Source: AAAS, Top 500

12. BigData: Recession?
Source: Gartner, Apache Foundation
2005

13. BigData? HPC?
Image Source: solar-citrus.tumblr.com
BigData
HPC
Isn’t that what I’ve done
in the past?

14. Hadoop’s Uncomfortable Fit in HPC
Why?
1. Hadoop is an invader!
2. Running Java applications (Hadoop) on supercomputer looks funny
3. Hadoop reinvents HPC technologies poorly
4. HDFS is very slow and very obtuse
Source: G. K. Lockwood, HPCwire Image Source: solar-citrus.tumblr.com

15. HPC Ecosystem
Application level
Middleware
System software
Cluster Hardware
Applications and Community Codes
FORTRAN, C, C++, and IDEs
Domain Specific
Libraries
programming model
Lustre (Parallel
File System)
MPI/OpenMP/
OpenCL/CUDA
Batch Scheduler
(SLURM,SGE)
Linux OS
Infiniband
/Ethernet
SAN/Local
Storage
X86 Servers+
Coprocessors

16. BigData Ecosystem
Application level
Middleware
System software
Cluster Hardware
Mahout, R, etc
MapReduce
programming model
Hadoop File System
HBase
Big Table
Linux OS
Ethernet
Local
Storage
X86 Servers
zookeeper Spark
Hive Pig, etc ...
Virtual Machines and Cloud

17. ADR vs MapReduce
- Data Intensive Computing Framework
- Scientific Datasets 처리
1998 Active Data Repository (ADR)
Processing Remotely Sensed Data
NOAA Tiros-N
w/ AVHRR sensor
AVHRR Level 1 DataAVHRR Level 1 Data
• As the TIROS-N satellite orbits, the
Advanced Very High Resolution Radiometer (AVHRR)
sensor scans perpendicular to the satellite’s track.
• At regular intervals along a scan line measurements
are gathered to form an instantaneous field of view
(IFOV).
• Scan lines are aggregated into Level 1 data sets.
A single file of Global Area
Coverage (GAC) data
represents:
• ~one full earth orbit.
• ~110 minutes.
• ~40 megabytes.
• ~15,000 scan lines.
One scan line is 409 IFOV’s
Source: Chaos project: U.Maryland, College Park

18. DataCutter vs Dryad, Spark
2000 DataCutter
- Workflow 지원 Component Framework
- Pipelined components (filter)
- Stream based communication
class MyFilter : public Filter_Base {
public:
int init( int argc, char * argv[] )
{ ... };
int process( stream_t st[] ) { ... };
int finalize( void ) { ... };
}
Source: Chaos project: U.Maryland, College Park

19. HPC & BigData
HPC 와 BigData 의 공통 해결 과제
1. High-performance interconnect technologies
2. Energy efficient circuit, power, and cooling technologies
3. Power and Failure-aware resilient scalable system software
4. Advanced memory technologies
5. Data management- volume, velocity, and diversity of data
6. Programming models
7. Scale-up? Scale-out?

20. HPC for BigData
Infiniband/RDMA for Hadoop
- Wide adoption of RDMA
- Message Passing Interface (MPI) for HPC
- Parallel File Systems
- Lustre
- GPFS
- Delivering excellent performance
- (latency, bandwidth and CPU Utilization)
- Delivering excellent scalability

21. HPC for BigData
Infiniband/RDMA for Hadoop
- Socket 기반의 Java RPC
- HPC는 고속 lossless DMA 통신 사용
Application
Socket
Transport
NIC Driver
NIC
Application
Socket
Transport
NIC Driver
NIC
Buffer
Buffer
Buffer
Buffer
Buffer
Buffer
Buffer
Buffer
Buffer
Buffer
Application
Socket
Transport
NIC Driver
NIC
Application
Socket
Transport
NIC Driver
NIC
Buffer
Buffer
Buffer
Buffer
Source: D.K.Panda, ISCA15 tutorial

22. HPC for BigData
Lustre File System for Hadoop
- Intel HPC distribution for Hadoop
- Map task의 중간 결과물을 Lustre FS 에 저장
Source: Intel

23. HPC for BigData
RDMA 기반 In-Memory Merge
Source: D.K. Panda, ISCA 15 Tutorial
Map 1 Output (sorted)
Map 2 Output (sorted)
Reducer
Map 1 Output (sorted)
Map 2 Output (sorted)
Reducer
1. Sorted map output is divided into small pieces based on shuffle packet size
and size of the key-value pairs
2. As small portion of data is shuffled, merge can take place in memory

24. HPC for BigData
Scale out vs Scale up
1. Scale-out
2. Scale-up
Performance
Performance
Scale-up is more cost-effective
(Microsoft – SOCC 2013)

25. EclipseMR
남범석
UNIST (울산과학기술원)

26. contents
1. 슈퍼컴퓨팅과 빅데이터
2. UNIST의 빅데이터 분석 플랫폼
3. 맺음말

27. 2.
EclipseMR

28. DHT 기반 빅데이터 프레임워크
CHORD DHT(Distributed Hash Table,분산해시테이블)
특징
1. Decentralized Data Structure
2. 결함 내성
3. 확장성 (P2P)
4. 바이너리 서치/Short cut->빠른 데이터 검색
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
{13,14,15} {0,1}
{2,3,4}
{5,6,7}
{8,9,10,11,12}

29. Chord DHT
Consistent Hashing
1. Hash function assigns a key to each node and each data
- key = hash(IP,port)
- key = hash(dataID)
ex) Insert new_data:
10 = hash(new_data)
12 = successor(10)
: successor(X) : actual node following X
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
{13,14,15} {0,1}
{2,3,4}
{5,6,7}
{8,9,10,11,12}
Actual node
Data keys

30. Chord DHT
Join Algorithm
ex) A new server X joins
: 9 = hash(X_IP,X_port)
: 1 = Search(9)
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
{0,1,2,3,
4,5,6,7,8,
9,10,11,12,
13,14,15}
Actual node

31. Chord DHT
Join Algorithm
ex) A new server X joins
:7= hash(X_IP,X_port)
: 1 = Search(7)
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
{0,1,8,9,
10,11,12,
13,14,15}
{2,3,4,
5,6,7}
X

32. Chord DHT
Join Algorithm
ex) A new server Y joins
: 12 = hash(Y_IP,Y_port)
: 7 = Search(12)
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
{8,9,10,
11,12}
{0,1,13,
14,15}
{2,3,4,
5,6,7}

33. Chord DHT
Routing Algorithm
Finger Table
- 자신으로부터 2k 번째 key의 successor
- ex) 노드1 의 Finger Table
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
{13,14,15} {0,1}
{2,3,4}
{5,6,7}
{8,9,10,11,12}
20
21
22
24
k 2k successor(2k)
0 1+1 4
1 1+2 4
2 1+4 7
3 1+8 12

34. Chord DHT
Routing Algorithm
Finger Table
- 자신으로부터 2k 번째 key의 successor
- ex) 노드15 의 Finger Table
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
{13,14,15} {0,1}
{2,3,4}
{5,6,7}
{8,9,10,11,12}
20 21
22
24
k 2k successor(2k)
0 (15+1)%16 1
1 (15+2)%16 1
2 (15+4)%16 4
3 (15+8)%16 7

35. Chord DHT
Routing Algorithm
Decentralized Binary Search
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Decentralized
특징
1. Decentralized Data Structure
2. 결함 내성
3. 확장성 (P2P)
4. 빠른 데이터 검색

36. EclipseMR의 아키텍처
이중 DHT 구조
바깥 DHT: 인메모리 캐시
안쪽 DHT: 분산 파일 시스템
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Key Design Principle
1) 로드 밸런싱
2) 인메모리 캐시 적중율

37. EclipseMR의 아키텍처
File Upload
1) 128MB 청크로 분할
2) 분할된 청크의 Hash Key를
사용하여 저장될 서버 지정
3) Replication
- replication factor = 3
- 지정된 서버의 좌우 actual
node에 저장
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13

38. EclipseMR의 아키텍처
File Upload
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Big File
Chunk-1
Chunk-2
Chunk-n
...

39. EclipseMR의 아키텍처
File Upload
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Chunk-1
Chunk-2
Chunk-n
...

40. EclipseMR의 아키텍처
File Replication
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Chunk-1
Chunk-2
Chunk-n
...

41. EclipseMR의 아키텍처
File Metdata Decentralization
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Big File
Chunk-1
Chunk-2
Chunk-n
...
Partitionining/Replication 메타데이터
: Hash(Big File)→3

42. EclipseMR의 아키텍처
File Read
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
1) successor(Hash(Big File)→3)→4
2) 노드 4에서 파일 정보 획득
- Chunk 갯수, ACL
분할 정보,복제정보, etc
3) Hash(Chunk-1)→14
Hash(Chunk-2)→5
BigFile 메타데이터

43. EclipseMR의 아키텍처
File Read
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
4) Search_InMemory(Hash(Chunk))
- 인메모리 캐시에서 히트 발생 기대
Chunk-1
Chunk-2
5) If Cache Miss → DHT 파일시스템에서
읽어 캐시에 저장

44. EclipseMR의 아키텍처
Load Balancing
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Q: 만약 Hash 키 13,14,15 가 다른 키에
비해 무수히 많이 엑세스 된다면?
A1: Migration
A2: Replication

45. Cache Migration/Replication:
- 인메모리 캐시의 데이터를
이웃 노드로 복제 혹은 이동
- 마이그레이션 알고리즘:
- Locality-aware Fair 스케줄러
- 인메모리 캐시의 Hash 경계선을
움직여 로드밸런싱 유지
EclipseMR의 아키텍처
Load Balancing
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13

46. - 만일 Application이 key13을 읽기
위해 노드 12의 인메모리 캐쉬 검색.
- Cache Miss 발생 시 로컬디스크가
아닌 이웃한 노드 15에서 읽어야함
→ 성능 저하
- But! 15에 저장된 데이터들은 12에 복제
되어 있어 Local에서 읽음
- 경계가 극단적으로 변하지 않는 이상 로컬
리티 보장
EclipseMR의 아키텍처
Remote Data Access
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13

47. - 로드밸런싱을 위해 Hash Key
경계선을 움직일 경우, Hash Key
경계선의 Decentralization이 어려움
- Leader Election 을 통해 Hash Key
경계선과 Job Scheduling을 담당할
Frontend 노드를 P2P로 결정
EclipseMR의 아키텍처
In-Memory Hash Key Boundary
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13

48. - 최근 데이터 액세스 분포를 사용하여 Hash Key 경계를 분할
Locality-aware Fair Scheduler
In-Memory Hash Key Boundary Management
14 150 1 2 3 4 5 6 7 8 9 10 11 12 13

49. Locality-aware Fair Scheduler
In-Memory Hash Key Boundary Management
0
0.2
0.4
0.6
0.8
1
0
6
12
18
24
30
36
42
48
54
60
66
72
78
84
90
96
102
108
114
120
126
132
138
CDF
server 1: [0,35)
server 2: [35,47)
server 3: [47,91)
server 4: [91,102)
server 5: [102,140)
new task T1 (HK=43)
new task T2 (HK=69)

50. EclipseMR 에서의 MapReduce
Job Scheduler
A
A
B
C
D
E
F
B
C
D
E
F
5
5
11
15
18
26
38
39
47
57
55
EclipseMR
MR application 1 1
2
3
4
4
5
5
3
6
reduce tasks
6
Serv
er
Hash Key Range
A [57~5)
B [5,11)
C [11,18)
D [18,39)
E [39,48)
F [48,57)
- accesses a file (hash key=38)
: data block 5 & 56

51. EclipseMR vs Hadoop & Spark
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
PageRank Sort Word Count Grep KMeans
NormalizedExecutionTime
EclipseMR Hadoop Spark
25x
3x
50x
6x
50x

52. 3.
맺음말

53. Ongoing Works
MachineLearning on EclipseMR
- GPU ML 패키지와 EclipseMR의 통합
Hadoop에서 GPU를
쓰는건 너무 어려워요.
WORLD'S LARGEST ARTIFICIAL
NEURAL NETWORKS WITH GPU
Source: Stanford Al Lab

54. Ongoing Works
Cassandra/NoSQL
- Cassandra 와 EclipseMR의 통합
- NewSQL on EclipseMR
DHT 인메모리 캐싱/RDMA 를 활용한
고속 NewSQL 엔진 개발
14
15
0
1
2
3
4
5
6
7
8
9
10
11
12
13
{13,14,15} {0,1}
{2,3,4}
{5,6,7}
{8,9,10,11,12}

55. Ongoing Works
MPI/RDMA
- 수퍼컴퓨팅 SGE/SLURM 환경에서 수행 가능
EclipseMR은 Hadoop 디
몬이 필요 없으니 수행 가
능합니다. mpirun으로 수
행하세요.
빅데이터처리

56. 맺음말
HPC & Big Data는 공통 과제를 함께 해결
- HPC의 Scale-up technologies를 BigData에 우선 적용
- UNIST 수퍼컴퓨팅센터/초고성능 빅데이터 사업단
- EclipseMR 및 다양한 HPC + BigData 연구 중

57. Q&A

58. Thank You