임시

그림 발췌

https://blogs.msdn.microsoft.com/bigdatasupport/2015/09/14/understanding-sparks-sparkconf-sparkcontext-sqlcontext-and-hivecontext/

Cluster에서 운영

- 분산 모드에서 스파크는 하나의 Driver Program과 여러 Worker Node 즉, Master/Slave 구조를 가진다.

Driver는 Worker Node의 Executor와 통신하는데, Driver는 자신만의 자바 프로세스에서 돌아가며, Executor 또한 독립된 자바 프로세스다.

- 하나의 Spark Application은 Cluster Manager라고 불리는 외부 서비스를 사용하여 여러 개의 머신에서 실행 된다.

- Driver: Driver는 Main Method가 실행되는 프로세스로, SparkContext를 생성하고 RDD를 만들고, Transformation과 Action을 실행하는 사용자 코드를 실행하는 프로세스

1) 사용자 프로그램을 Task로 변환

2) Executor에서 Task들의 Scheduling

- Executor: Spark Task를 실행하는 작업 프로세스. Spark application 실행 시 최초 한 번 실행되며, 대개 application이 끝날 때까지 계속 동작하지만, 오류로 죽더라도 Spark application은 계속 실행함

1) Application을 구성하는 작업들을 실행하여, 드라이버에 결과를 리턴

2) 각 Executor 안에 존재하는 블록 매니저라는 서비스를 통해 사용자 프로그램에서 Cache하는 RDD를 저장하기 위한 메모리 저장소 제공

- Cluster Manager: Spark와 붙이거나 뗄 수 있는 컴포넌트. (Yarn, mesos, 내장 Manager 등 다양한 외부 매니저들 위에서 동라가게 함)

Program 실행하기

- 어떤 Cluster Manager를 사용하든 Spark는 사용자 프로그램을 Spark에 submit 할 수 있는  단일 스크립트인 Spark-submit을 제공

$ ./bin/spark-submit <script.py>  //local로 Spark program 실행

$ ./bin/spark-submit --master spark://host  :7077 --executor-memory 10g <script.py>

--master flag는 접속할 cluster의 주소를 지정해주는데, spark:// URL은 Spark의 단독 모드를 사용한 cluster 의미

- Spark-submit –master flag값

1) spark://host:port: spark 단독 클러스터의 지정 포트 접속 (default: 7077)

2) memos://host:port: mesos cluster에 지정 포트 접속 (default: 5050)

3) yarn: yarn cluster 접속 (hadoop directory -> HADOOP_CONF_DIR 환경 변수 설정 필요)

4) local: 로컬 모드에서 싱글 코어로 실행

5) local[N]: N개코어로 로컬모드에서 실행

6) local[*]: 로컬모드에서 머신이 가지고 있는 만큼의 코어로 실행

- executor-memory <MEM>: executor 당 메모리 할당

- 자세한 내용은 spark-submit --help  참고

본 내용은 러닝스파크 책 참고

Accumulator

- Spark의 map()이나 조건 지정을 위해 filter()에 함수를 넘길 때, 보통 Driver Program에 정의된 변수를 사용

(Driver Program과 Worker Node) - 해당 내용은 kkn1220.tistory.com/131에서 참고

- 하지만, 클러스터에서 실행 중인 각각의 작업들은 변수의 복사본을 받아 작업하게 되므로, 업데이트된 내용이 다시 드라이버 프로그램으로 리턴 해주지는 않는다. 이에 Accumulator 변수는 이러한 제한을 풀어준다.

- Accumulator: Worker Node에서 Driver Program으로 보내는 값의 집합 연산에  대해 문법 제공. 가장 흔한 사용 방법 중 하나는, 작업 수행 중에 발생하는 일에 대한 개수를 디버깅 목적으로 헤아림

-> 각 Worker node에 복사본을 전달하고, 어플리케이션 종료 시점에 각 worker node로부터 수집하여 결과를 생성

- 빈 라인수 세기 예제

- 해당 예제에서 Transformation 계산이 끝난 후, 카운터의 값을 출력

- 올바른 값은 반드시 saveAsTextFile이 실행된 다음에 얻을 수 있음. 그 위의 map()은 lazy execution 방식을 따르기 때문에 수반되는 accumulator 값 증가는 반드시 map()이 실제로 실행 되는 시점인 saveAs~ 액션이 수행되어야만 강제하기 때문

요약하면, Accumulator는 다음과 같이 동작함

1) Driver Program에서 SparkContext.accumulator(IV) 메소드를 호출하여 초기 값을 가진 Accumulator 를 만든다.

2) 반환 타입은 Accumulator[T] 객체이며, T는 초기 값의 타입이다.

3) Spark Closure의 작업 노드 코드에서 Accumulator에 += 메소드를 써서 값을 더한다.

4) Driver Program에서 value 속성을 불러 Accumulator 값에 접근한다.

여기에서 Worker node의 task에서는 Accumulator의 Value()에 접근하지 못하는 것을 유념! 즉 이 task의 관점에서

Accumulator는 “쓰기 전용” 변수인 셈. 이는 Accumulator가 매 업데이트마다 통신할 필요가 없도록 효율적으로 구현되어 있기 때문

본문의 내용은 러닝스파크 책 참고

Data불러오기/저장하기

- 스파크에서는 Text file, JSON, CSV, object file 등 다양한 파일 포맷을 지원

1) Text파일

- 불러오기

- <변수명> = sc.textFile(<file_path>)

- 새로운 RDD 생성 (Python단어라인 추출하기)

- 저장하기

- result.saveAsTextFile(<output_file_name>)

2) JSON

- 불러오기 

-  가장 간단한 방법은 데이터를 Text File로 불러온 뒤, JSON parser를 사용하여 값들을 매핑

- 데이터 샘플

- 저장하기 //팬더를 좋아하는 사람으로 필터

- result.saveAsTextFile(<output_file_name>)  

3) CSV (Comma Separated Value)

-데이터 샘플

- 10,539 줄의 Traffic

- Comma로 구분이 안되어 있어 , 변환 작업

-데이터 불러오기 (TextFile로 불러오기)

- 전체적으로 CSV 불러오기

- 저장하기

그림 발췌

https://blogs.msdn.microsoft.com/bigdatasupport/2015/09/14/understanding-sparks-sparkconf-sparkcontext-sqlcontext-and-hivecontext/ 

http://bigdatafindings.blogspot.kr/2015/08/some-key-points-about-spark-suffle.html

SparkContext란?

- 스파크에서는 아래 그림과 같이 Driver Program과 Worker Node 내 Executor 간의 통신이 발생한다. 이 Driver는 Executor에게 Task를 할당하게 된다. Executor에서는 Task를 수행하고 종료 시 Driver에게 결과 값을 주게 된다.

- 스파크를 실행하면, SparkContext생성으로부터 시작이 된다. 앞선 예제들을 확인하면 알 수 있듯이, SC를 사용하여 RDD생성을 하였다.

(다만 앞선 예제에서는 로컬 내 실행 되었기 때문에, 위의 그림처럼 노드들에게 Task를 분산으로 나누지는 않았다..)

- 기본적인 SC 시작 방법

- SC(Spark Context) 초기화

- Local: 한 개의 스레드나 단일의 로컬머신에서 동작할 때, 따로 접속할 필요가 없음을 알려주는 값

- My App: Cluster에 접속할 경우, Cluster UI에서 My App이란 이름으로 어플리케이션을 구분할 수 있음

- SparkContext(conf = conf): 최종 SparkContext를 sc변수로 할당

Reduce By Key vs Group By Key

- Reduce By Key: The reduce operation happens for each partition, and then the results will be shuffled.

- 같은 Node의 같은 Key값을 기준으로 값들을 미리 병합하여, 최종적으로 셔플링할 때, 부하를 줄여줌

- Group By Key: 모든 Pair 데이터들이 Key를 기준으로 셔플링이 이루어지는데, 이는 많은 부하가 발생할 수 있음

밑에 그림을 보면 이해하기 쉬운데,  RBK의 경우 미리 노드에서 같은Key들에 대해 값을 미리 병합한 것을 확인할 수 있음

본 내용은 러닝스파크 책에서 긁어옴

Pair RDD

- Spark는 key/value 쌍을 가지는 RDD에 의해 특수한 연산을 제공. 이 RDD를 Pair RDD라 부름

- Pair RDD들은 각 key에 대해 병렬로 처리하거나 Re Grouping할 때 유용

Pair RDD Transformation

- {(1,2),(3,4),(3,6)}

두 Pair RDD Transformation

- rdd1: (1,2),(3,4),(3,6)} rdd2: {(3,9)}

Pair RDD Actions

- {(1,2),(3,4),(3,6)}

RDD 개념

- RDD(Resilient Distributed Dataset)

- Resilient: Memory 내 데이터 손실 시, 다시 생성할 수 있음. 즉, 유실된  파티션을 재연산해 복구 (탄력적)

- Distributed: Cluster를 통해 메모리에 분산되어 저장 (분산)

- Dataset: 파일을 통해 가져올 수 있음

- RDD는 스파크에서 기본적인 데이터 단위라고 볼 수 있다.  스파크에서의 모든 작업은 새로운 RDD를 만들거나, 존재하는 RDD를 변형하거나, 결과 계산을 위해 RDD에서 연산을 호출하는 것 중의 하나로 표현됨

- RDD는 Lazy Execution!

- Action 함수의 실행 전까지는, 실제로 이벤트가 발생하지 않음

쉽게 말해서, RDD가 새로운 RDD를 만들었다고 가정했을 때(Transformation), 값들은 없는 빈 껍데기만 생성이 된다. 사슬처럼 RDD가 생성이 된다고 해도, 값은 없다.

Action 함수인 count를 했을 때, 비로소 RDD에 값이 들어가는 느긋한 실행?(ㅠㅠ) 방식으로 되어 있다.

그런데 이는 메모리에 값을 쓰고 있지 않기 때문에 성능면에서 상당히 좋은 방법이다.

만약 모든 라인을 로드해서 저장하면 얼마나 낭비겠는가!

RDD Function 종류

- Transformations: 존재하는 RDD에서 새로운 RDD 생성

- RDD의 데이터는 바꿀 수 없음

- map(function): RDD의 각 행별로 기능 수행(ex: 각 행의 ‘abc’가 포함되는 단어 Count하기)

- flatmap(function): RDD의 각 라인별 요소 단위로 매핑

(ex: 각 행들을 하나의 리스트로 통합 된다고 보면 쉬움(1,2,3행 -> 1행으로 통합))

- filter(function): 조건에 맞는 RDD의 행을 새로운 RDD로 생성(ex: 각 행의 길이가 x이상일 때 생성

- distinct(function): 중복 제거(ex:  행에 중복 문자열이 있을 경우 제거)

- {1,2,3,3} 의 값을 가진 RDD Transformation

- {1,2,3},{3,4,5} 두 RDD를 가진 Transformation

- Actions: 실제 수행하는 함수로, 값을 받아옴. 또는 외부 스토리지에 저장

(ex: reduce(RDD 값들을 병렬로 병합 연산), count, take(n) (n개의 리스트 반환) , collect(모든 데이터 반환)등)

- {1,2,3,3} RDD Actions

RDD 예제 (Local 에서 사용)

- RDD 예제 (Line 수 세기)

- 실제 104 라인으로 구성되어 있는 것을 확인할 수 있다. 

(spark 실행을 bin파일 내에서 실행하였기 때문에 상위 경로의 path 사용)

>>>lines = sc.textFile(“../README.md”)

lines이라는 RDD를 생성하면 연산이 즉시 수행되는 것이 아닌, 메타데이터에 요청이 들어왔다는 것만 기록해둠

그런데 때때로 동일한 RDD를 여러 번 사용하고 싶을 때도 있지 않을까? 

-> persist(), cache()있음. [차이점은 cache()는 persist()에서 저장 옵션을 MEMORY_ONLY로 한 옵션과 동일)

(저장 옵션: https://spark.apache.org/docs/latest/programming-guide.html#rd-persistence  참고)

>>>lines.count()

count() 라는 Action을 수행하면 비로소 아래와 같이 각 라인에 데이터가 채워지고 (Lazy Execution), 라인 수를

카운트 하게 된다.

- 앞서 설명한, take(5)의 경우 5라인까지만 출력되는 것을 확인할 수 있다.  

- RDD 예제 (필터링)

- RDD 예제 (RDD 제곱)

-RDD 예제(Word Count)

Apache Spark 설치

1) 필수 요건

- 스파크 자체는 스칼라로 만들어졌으며, 자바 가상 머신(JVM) 위에서 동작함. 그렇기 때문에 자바가 설치가 되어 있어야 됨 (자바에 대한 설치는 별도로 언급 x)

2) Download (http://spark.apache.org/downloads.html)

- 현재 기준(‘17.04.03) 2.1.0 이 최신 버전

- 1,2,3을 선택하고 4번을 누르면 타르볼 파일 설치됨

- 설치는 ubuntu 환경에서 진행하였음

- $tar -xf <spark_file_tgz>

3) pyspark 실행  (Ipython 실행시 : IPYTHON=1 ./bin/pyspark,   Notebook 사용시: IPYTHON_OPTS=“notebook” ./bin/pyspark

- 로그는 현재 Warning 만 나오게끔 되어 있는데, INFO 등 변경이 가능함

- python2.0부터 IPYTHON=1이 바뀜 

- PYSPARK_DRIVER_PYTHON=ipython ./bin/pyspark   or 또는 환경변수를 설정해주는 방법이 있음 

$ export PYSPARK_DRIVER_PYTHON=ipython

$./bin/pyspark)

설치가 된 화면이다.

본 내용은 러닝스파크 책을 참고하였음.

Apache Spark란?

- Apache Spark는 범용적이면서도 빠른 속도로 작업을 수행할 수 있도록 설계한 클러스터용 연산 플랫폼

(속도 측면)

- 맵리듀스 모델을 대화형 명령어 쿼리나 스트리밍 처리 등이 가능하도록 확대

- 속도를 높이기 위해 연산을 메모리에서 수행하도록 함. 단, 복잡한 프로그램을 디스크에서 돌리더라도 맵리듀스

보다 뛰어난 성능

(범용적 측면)

- 스파크는 기존에 각각 분리된 분산 시스템에서 돌아가던 배치 어플리케이션, 반복 알고리즘, 대화형 쿼리, 스트

리밍 같은 다양한 작업 타입을 동시에 커버할 수 있도록 설계

-> 이런 워크로드들을 단일 시스템에서 지원하게 됨에 따라 스파크는 실제의 데이터 분석 파이프라인에서도 서로 다른 형태의 작업을 쉽고 저비용으로 연계 가능하게 함

- 스파크는 고수준에서 접근하기 쉽게 설계되어 있어서 파이썬, 자바, 스칼라, SQL API 및 강력한 Lib 내장 지원

-> 특히 하둡 클러스터 위에서도 실행 가능하며, 카산드라를 포함하는 어떠한 하둡 데이터 소스에도 접근 가능

- 맵리듀스가 반복적인 대화형 연산 작업에는 비효율적이라는 것을 발견

-> 스파크는 시작부터 인메모리 저장 장치 및 효과 적인 장애 복구 지원 같은 개념에 기반하여 대화형 쿼리와, 반복성 알고리즘에 빠르게 동작하도록 설계

Apache Spark 구성요소

- Spark는 다수의 작업 머신이나 클러스터 위에 돌아가는 많은 연산 작업 프로그램을 스케줄링/분배/감시역할 수행

1) Spark Core

- 작업 스케줄링, 메모리 관리, 장애 복구, 저장 장치와의 연동 등 기본 기능들로 구성

- RDD(Resilient Distributed Dataset)를 정의하는 API의 기반이 되며, 이것이 주된 스파크 프로그래밍 추상화 구조

-> RDD 는 여러 컴퓨터 노드에 흩어져 있으면서 병렬 처리 될 수 있는 아이템들의 모음을 표현

2) Spark SQL (Spark 1.0부터 지원)

- 정형 데이터를 처리하기 위한 패키지 (Hive 테이블, Parquet, JSON 등 다양한 데이터 소스 지원)

3) Spark Streaming

- 실시간 데이터 스트림을 처리 (로그 파일, 메시지 Queue 등 포함)

4) Mllib

- 다양한 머신 러닝 알고리즘 지원 (Classification, Regression, Clustering, Collaborative Filtering 등)

- Gradient Descent 최적화 알고리즘 같은 저수준의 ML 또한 지원

5) Graph X

- 그래프를 다루기 위한 라이브러리

6) Cluster Manager

- 한 노드에서 수천 노드까지 효과적으로 성능을 확장할 수 있도록 만들어짐

- 이를 달성하기 위해 Yarn, Apache Mesos, 스파크에서 지원하는 가벼운 구현의 단독 스케줄러 등 다양한 Cluster Manager위에서 동작 

맵리듀스는 하둡에서 가장 중요하다고 해도 과언이 아니다.

맵리듀스는 하둡 클러스터의 데이터를 처리하기 위한 시스템으로, 여러 데이터 노드에 Task를 분배하는 방법이다.

맵, 리듀스로 구성이 되어 있으며 사실 이 사이에는 shuffle과 sort 단계가 들어 있다.

처리 과정

1) 맵리듀스는 Name Node의 Job Tracker 데몬에 의해 제어 된다.

2) 클라이언트는 맵리듀스 Job을 Job Tracker에게 보낸다.
3) 이 Job Tracker는 클러스터의 다른 Slave Node들에게 맵과 리듀스 Task를 할당하게 된다. 

4) Slave Node는 Task Tracker 데몬에 의해 실행이 된다.

5) Task Tracker는 실제로 맵리듀스 Task를 실행하고, 진행 상황을 Job Tracker에게 전달하는 구조로 되어 있다.

그렇다면, 맵 리듀스는 왜 필요한 것일까???

전통적인(?, 사실 분산 프레임 워크가 나온지 오래 됐지만...더 이전) 데이터 처리 방법은 위와 같다. 매우 큰 데이터를 쪼개서 매칭되는 데이터를 뽑아, 결과를 추출하는 형식으로 되어 있었다.

실제로 빅데이터를 처리하기 위해 위의 구조로는 시간이 너무너무 오래 걸린다.

 아래는 맵리듀스 프레임워크를 통해 결과를 추출하는 방식인데, 기존에 비해 두 가지 큰 이점을 가지고 있다.

1) Taking Processing to the data

2) Processing data in parallel

 즉, 데이터를 처리하는데 있어 병렬적으로 할 수 있다는 것이다.

 사실 위의 예제에서 Very Big Data가 작아보이긴 하지만, 실제 파일은 TB이상의 어마어마 할 것이다.
워낙 방대한 양이기 때문에 처리 프로세스는 간단해야 한다. 이를 위해, 기준이 되는 값이 필요한데 그 기준이 되는 값이 Key가 하나인 맵 구조이다.

내용이 좀 어려웠다. 아래의 사진을 보자.

맵리듀스 프레임워크

- Map Phase: 모든 입력 값에 대해 Map Function 을 적용하는 단계이다. 동시에 실행되는 여러 맵퍼는 각각 입력 데이터의 일부를 처리하는 단계를 포함하게 되는데, 이 여러 맵퍼 간에는 종속성이 없으므로, 서로 독립적으로 작업된다.

여기에서 알아둬야 할 것은, 맵퍼는 Key/Value 쌍의 형태로 데이터를 읽게 된다.

map(key, value) -> List(key, value)

ex) 소문자 바꾸기

input)

map(key, value) -> emit(k.toLower(), v.toLower())

result)

('TEST', 'LOWER') -> ('test', 'lower')

단, 출력 key값이 꼭 입력 데이터 key값과 동일할 필요는 없음(저 toLower()가 아닌, length()로 넣었을 때는 4가 됨)

- Shuffle Phase: 맵 단계로 부터 (key,value) pairs 결과 값에 대한 정렬 단계 

(결과 값들의 키 순서대로 정렬되어 리듀서로 보내게 되는데 이를 sort라 함)

- Reduce Phase: 모든 Pairs를 통일한 키로 조합하여 정렬 된 목록을 생성함.

이 때, key와  value들의 리스트 값이 input값으로 들어옴. Reducer의 Output은 0이거나 Key/Value의 Pairs 값임

이 결과들은 다시 HDFS에 저장됨. (실제로 Reducer는 보통 Input값에 대해 하나의 Key/Value Pairs로 배출되어 사용)

reduce(key, list(values)) -> List(key, value)

예제

이 일련의 과정을 아래의 예제를 통해 설명하고자 한다.

역시, 예제를 통해 보는게 가장 쉽다고 생각~~!

맵리듀스 예제는 Word Count가 가장 많이 사용 된다.

1) Input값 입력: Input값으로 Dear Bear River 1줄, Car Car River 1줄, Deer Car Bear 1줄이 들어 왔다. 물론 이것은 어마어마하게 많은 데이터 일 것이다. 

2) Split: split을 통해 단어를 쪼개는 작업을 수행하였다.

3) Map: 각 key(Deer, Bear, River)와 Value로는 Word Count이기 때문에 1로 지정이 된 것을 확인할 수 있다.

method Map(source, target)

emit(target, 1)

end

4) Shuffling: 각 Key와 Value의 List값이 Sort에 의해 정렬되어 있음을 확인할 수 있다. (B > C > D > R)

5) Reduce: 셔플링을 통해 들어온 Value of List 값을 더하는 작업을 수행하였다. (Word Count)

method Reduce(target, counts[c1,c2...])

sum <- 0

for all c in counts[c1,c2,...] do

sum <- sum + c

end

emit(target, sum)

end

6) Result: Final Result

위의 예제를 통하면 전체적으로 맵리듀스의 흐름을 파악할 수 있을 것이라고 사료된다.

아파치 하둡 소개에 다음 버전으로 간단한 HDFS 사용법에 대해 소개하고자 한다.

소개는 http://kkn1220.tistory.com/120 를 참고

환경 구축: 가상 머신(Virtual box 또는 Vmware, Cloudera)

cloudera는 맵알(MapR), 호트웍스(Hortonworks)와 가장 많이 쓰이는 하둡 배포판이라 사용하게 되었음

또한, 퀵 스타트 버전으로 실행 시 너무 편해서...(귀찮아서 아님)

또한, 별도의 예제는 없고 파일을 올리는 방법 정도로만 소개

가상 머신은 설치가 되었다고 가정

1) Cloudera 설치: https://www.cloudera.com/downloads/quickstart_vms/5-8.html

-> 본 포스팅은 하둡에 대한 소개보다는 스파크로 가기 전 간단한 소개이기 때문에 Cloudera Manager를 설치하는 것이 아닌 Quick start버전 다운

가상 머신에 맞게 다운로드 받으면 된다. (용량이 꽤 크다. 실제로 압축 풀고 그러면 8GB 는 되는듯)

2) Cloudera 실행

-> 가상머신 가져오기 하면 엄청 쉽다.(이미지를 Vmware에서 불러오면 됨. 메모리 설정 등 자동으로 설정 되어 있음)

- 5.8 퀵 스타트 버전은 CentOS 6.7 버전으로 구성 되어 있다.

- 개인적으로 레드햇 계열의 cent os를 좋아하지 않는다. (뭔가 데비안 계열에 비해 딱딱해보임..)

- 키면 아래의 화면으로 처음 시작이 되는데 이클립스도 설치가 되어 있다.

3) Hue

-> Hue는 Hadoop의 Eco system으로 데이터 분석을 제공하는 웹 인터페이스이다.

브라우저 실행 시, 아래의 그림과 같이 Hue탭이 있어 클릭 하면 됨 (Id: cloudera, pw: cloudera)

Hue 로그인 후, 우측 상단의 노란색으로 칠한 부분을 누르면 파일 관리를 할 수 있는데, 초기에는 (당연히) 아무 것도 없음윽 확인할 수 있다.

터미널을 열고, $hadoop fs -mkdir test 를 입력하고, 새로고침을 누르면 정상적으로 폴더가 생성되는 것을 확인할 수 있다.

$hadoop fs -mkdir test

- $hadoop    : 시스템과의 상호 작용을 위해 hadoop명령어 사용

- $hadoop 을 입력하면 Usage를 확인할 수 있다.

- fs또한 마찬가지로 확인 가능....

- cat, chmod, chown, cp, mkdir, mv 등 다양하니 한번 확인해도 나쁘지 않겠다.

- 루트 디렉토리를 확인하면 아래와 같이 확인할 수 있다.

- user 디렉토리 내 하위 폴더를 본 결과, 좀 전에 만든 test폴더가 있는 것 또한 확인 가능하다.

- local에 샘플 데이터를 만들고 HDFS에 업로드 하는 화면은 아래와 같다. (local에서 put 명령어를 통해 HDFS에 업로드가 됨)

Hue에서 test디렉토리 밑에 test파일이 정상적으로 업로드 된 것을 확인할 수 있다.

(다운로드는 -get 명령어 사용   $hadoop fs -get <download_file> <다운로드 받고자 하는 local_path> )

즉, 구조를 확인하면 Cloudera라는 가상 머신을 설치하였고, 가상 머신 내 local영역의 파일을, 별도의 HDFS에 올리는 것으로 보면 되겠다.

위의 예제는 단순 작은 사이즈의 파일을 업로드 하였다.

하지만 큰 파일이라고 가정해보자.

File은 Block 단위로 분할이 된다. 이전 포스팅에서 설명했듯이, 초기에는 크기가 64MB였는데, 2.0부터는 128MB를 지원한다.

이 Block들은 여러 머신에 복제되어 Data Node에 저장이 된다. 그리고 Data Node에 저장이 될 때, Name Node는 어디에 저장이 되어 있는지, 어떻게 구성이 되어있는지에 대한 메타 데이터를 가지고 있게 된다.

위의 그림을 보면 3개씩 복제되어 저장 된 것을 확인할 수 있는데 default가 3개이다.

HDFS에 접근하기 위해서는 다양한 방법이 존재한다.

1) Shell 커맨드 사용: (ex: 위의 커맨드 창에서 $hadoop fs)

2) API 사용

3) 에코시스템: (ex: 위의 Hue 이용)