이유즈 데엔 여정

1. hostname 설정

- 통신할 서버의 hostname 지정해주기. 

$ vi /etc/hosts

127.0.0.1 localhost 는 살려둬야 한다.

서버 간 통신을 위해 모든 노드에서 지정해주기!

Yarn이란 ? 

하둡의 클러스터 자원 관리 시스템. 

맵리듀스의 성능 향상을 위해 Hadoop2 에서 처음 도입되었지만, 

맵리듀스 뿐 아니라 다른 분산 컴퓨팅 도구도 지원한다. 

Yarn 은 클러스터의 자원을 요청하고 사용하기 위한 API 를 제공한다.

맵리듀스, 스파크 등과 같은 분산 컴퓨팅 프레임워크는

클러스터 계산 계층 (Yarn) 과 클러스터 저장 계층 (HDFS) 위에서 YARN 애플리케이션을 실행한다. 

** Yarn 애플리케이션 수행

리소스 매니저 / 노드 매니저 

두 유형의 장기 실행 데몬을 통해 핵심 서비스를 제공한다. 

- 리소스 매니저 : 전체 자원의 사용량 관리 

- 노드 매니저 : 컨테이너를 구동하고 모니터링

실무에서 데이터를 조회하거나,
우리 회사같은 경우
insert overwrite 를 하는 경우가 굉장히 많은데
( 매일 정합성체크를 하는 입장에서 사용자들 또한
데이터 중복 건을 피하기 위해 insert into 가 아닌 overwrite 를 쓰기를 강력히 권고...)

이 때 테스트를 위함이든 데이터 소급을 위함이든,

특정 컬럼은 제외하고 모든 컬럼을 조회하고싶은 경우가 있다.

이 때 유용하게 쓸 수 있는 쿼리.

<hive-site.xml>
hive.support.quoted.identifiers=none

위의 설정 후

SELECT `(제외컬럼)?+.+` FROM <TABLE_NAME>;


굉장히 편리하다.

스칼라 함수도 이 이름과 같은 함수를 제공하지만,
RDD 함수는 분산 데이터에 적용되며 실제 연산이 지연된다.


ex.

예제 파일의 각 줄을 쉼표로 구분하고, 이를 idsStr RDD 로 구성한 것이다.
이 결과는 Array.toString 메서드가 반환한 값을 출력한 것이다.

( * collect 연산자는 새로운 배열을 생성하고, RDD의 모든 요소를 이 배열에 모아 스파크 셸로 반환한다. )

이는 문자가 아닌 문자열의 '배열' 이다. 이 배열의 배열을 '단일배열' 로 분해하려면,

즉 변환 연산자가 반환한 여러 배열의 모든 요소를 단일 배열로 통합하려는 상황에 flatMap 을 활용하면 좋다.

flatMap은 기본적으로 주어진 함수를 RDD의 모든 요소에 적용한다는 점에서 map 과 동일하다.
다른 점은 익명 함수가 반환한 배열의 중첩구조를 한 단계 제거하고 모든 배열의 요소를 단일 컬렉션으로 병합한다는 것이다.

flatMap 은 map 함수와 달리 1차원 배열을 반환했다.



- sample/take/takeSample

위의 연산자를 사용해 RDD의 요소를 일부 가져올 수 있다.


** sampel 메서드

- 첫번째 인자 : true/flase => 복원/비복원 샘플링
- 두번째 인자 : 각 요소가 샘플링 될 횟수의 기댓값.

- 생략된 세번째 인자 : 시드 (seed) . 인수를 제공하지 않으면 해당인자의 기본 값을 사용한다. 같은 시드는 항상 같은 유사 난수를 생성하기 때문에 프로그램을 테스트하는데 유용하다.


** takeSample
: sample 메서드의 두번째 인자가 기댓값(확률) 이 아닌 정확한 개수 (num) 으로 샘플링 할 때 사용.
val n = intIds.takeSample(false,5)




** take

지정된 개수의 요소들 모을 때 까지 RDD 의 파티션을 하나씩 처리해 결과를 반환한다.
(클러스터의 여러 노드에 저장된 데이터의 일부분)

take 메서드의 결과는 단일 머신에 전송되므로 인자에 너무 큰 수를 지정해서는 안된다.

^ spark_home 이 심볼릭 링크를 가리키도록 설정된 값 확인하기.

/usr/bin 폴더 -> 전체 시스템의 사용자 프로그램이 저장되는 기본 위치.

실제로 설치된 위치 보려면,

ls -al /경로/

심볼릭 링크 : 파일이나 폴더에 대한 일종의 참조. 심볼릭 링크를 사용하면 파일 시스템 내 서로 다른 두 위치에서 같은 파일에 접근 가능.
!= 파일/폴더의 복사본 아님.
심볼릭 링크가 폴더를 참조하면 마치 실제 타깃 폴더에 들어온 것처럼 심볼릭 링크의 폴더 내부를 탐색할 수 있음.
변경한 모든 내용은 타깃 폴더에 바로 적용되며, 심볼릭 링크에도 반영됨.
ex. vi 로 심볼릭 링크파일 편집 시 타깃 파일 편집한 것과 같음. 두 위치 모두에서 편집내용 확인 가능.

심볼릭 링크에서는 편하게 ex. 자바/ 하둡 형식으로 가능.


----

가상머신에 하둡 설치 시,
사전 준비없이 hadoop fs -ls 명령으로 HDFS 에 접속해 파일 시스템에 쿼리를 수행할 수 있는 것은 가상 머신이 부팅하면서
HDFS 데몬 프로세스를 자동으로 시작했기 때문이다.

start-dfs.sh 로 시작 가능.
---

스파크 커뮤니티는 2개월마다 새로운 버전을 릴리스 할 정도로 활발한데,
여러 버전의 스파크를 관리하고 현재 사용할 버전을 선택할 수 있는 방법 중 하나는

심볼릭 링크 활용 )

이를 사용하면 스파크 버전과 관계없이 모든 스파크 프로그램, 스크립트, 환경 설정 파일에서 스파크 설치 폴더를 참조할 때 항상
지정한 폴더를 사용할 수 있다.

(1) spark shell

스파크를 사용하는 방법은 두 가지다.
1 - 스파크 라이브러리.
: 스파크 api를 사용해 스칼라, 자바, 파이썬 독립 프로그램을 작성하는 것.
애플리케이션 코드를 작성하고 스파크에 제출해 실행한 후, 에플리케이션이 파일로 출력한 결과를 분석하는 과정을 거친다.
2 - 스파크의 스칼라 셸 / 파이썬 셸 사용
: 스파크 셸에서 작성한 프로그램은 셸을 종료하면 삭제되므로 주로 테스트/일회성 작업에 사용됨.

PATH에 스파크 bin 디렉토리를 등록해놓으면 spark-shell / pyspark 를 입력해도 스파크 셸을 실행할 수 있다.


(2) log4j

스파크의 오랜 이전 버전에는 콘솔에 INFO 로그가 상세하게 출력되었지만, 최신 버전은 이 문제를 개선했다. 하지만 일부 유용한 로그마저 출력에서 생략해 다소 불편하다.

스파크의 LOG4J 설정을 변경해 스파크 셸에는 오류 로그만 출력하고 나머지 로그들은 추후 문제 진단에 사용할 수 있도록
스파크 루트 폴더의 logs/info.log 파일에 저장해보자.
(log4j : 자바의 로깅 라이브러리.)

스파크 셸을 실행하면

출력한 내용 중

Spark context : 스파크 접속하고 세션 설정, 잡 실행관리, 파일 읽기/쓰기 작업 할 수 있다.
Spark session

스파크와 교신할 수 있는 일종의 창구이다.



간단 예제) 스파크 API 사용하여 파일 읽어들이고, 줄 개수 세어보기

맨 위의 경로( 루트 디렉토리) 에 테스트 용 파일을 만들어두고,
파일의 전체 줄 개수를 세고,
'dd' 가 등장한 줄만 포함하는 ddLines 컬렉션 새로 만들음.

RDD의 개념

위의 licLines, ddLines 는 마치 평범한 스칼라 컬렉션 같지만,
이는 RDD 라는 스파크 전용 분산 컬렉션이다.

RDD 는 데이터를 조작할 수 있는 다양한 변환 연산자를 제공하지만, 변환 연산자는 항상 새로운 RDD 객체를 생성한다.
즉 한 번 생성된 RDD 는 절대 바뀌지 않는 불변의 성질이 있다.

이는 분산 시스템에서 가장 중요한 장애 내성을 직관적인 방법으로 보장할 수 있다.

RDD 연산자는 크게 변환/행동 두 유형으로 나눈다.

변환 연산자 : RDD의 데이터를 조작해 새로운 RDD를 생성한다. (filter,map 함수)
행동 연산자 : 연산자를 호출한 프로그램으로 계산 결과를 반환하거나 RDD 요소에 특정 작업을 수행하려고 실제 계산을 시작하는 역할을 한다. (count, foreach)


1. map 변환 연산자

parallelize 메서드는 Seq를 받아
Seq 객체의 요소로 구성된 새로운 RDD 를 만든다.
(Seq : 스파크의 컬렉션 인터페이스. 이 인터페이스를 구현한 클래스에는 Array 나 List 등이 있다.)

이 Seq 객체의 요소는 여러 스파크 실행자로 분산된다.
parallelize 메서드는 makeRDD 라고 alias 로 호출할 수 있다.

spark-in-action 공부를 위해 가상머신을 설치하던 중 , 해당 에러를 발견했다. 

내가 하고있던 작업은 

1. 가상 머신을 저장할 폴더를 생성 후, 

2. 책의 깃허브 저장소에서 JSON 형식의 파일을 내려받고,

3. 위의 vagrant box -add ~ 명령어를 사용해 가상머신을 내려받는 것. 

하지만 위의 캡쳐처럼 

bsdtar: Error opening archive: Unrecognized archive format 오류가 났다. 

처음엔 그저 vagrant 프로그램 설치 오류인 줄 알았는데 .. 

알고보니 github 에서 파일을 내려받는 부분이 잘못되었고, 그 때문에 vagrant 명령을 입력해도 해당 파일을 못찾는 오류였다.;;

github 에서 올바르게 파일 다운받기 

 위의 raw 버튼을 누르면, 

창이 뜨면 Ctrl + S 로 다운로드 후 

위치해야 할 경로에 넣어주면 제대로 다운로드가 된다. 

이후 위의 vagrant 명령어를 입력하면 문제 해결 완료 !

나와 같은 오류로 시간낭비 하는 사람이 없길 바라며 ,, ;;

1.  컴포넌트

종류 ) 스파크 코어, 스파크 SQL, 스파크 스트리밍, 스파크 GraphX, 스파크 MLlib

이 글에선 스파크 MLlib, GraphX 를 제외하고 나머지 컴포넌트에 대해 다룬다.

A. 스파크 코어 

스파크 job, 다른 스파크 컴포넌트에 필요한 기본 기능 제공. 

- 여기서 가장 중요한 개념은 RDD 인데, RDD : 분산 데이터 컬렉션 (Dataset) 을 추상화한 객체로,

데이터셋에 적용할 수 있는 연산 및 변환 메서드를 함께 제공한다.

RDD는 노드에 장애가 발생해도 데이터셋을 재구성 할 수있는 복원성을 갖추고있다. 

- 스파크 코어는 HDFS , GluterFD, 아마존 S3 등 다양한 파일 시스템에 연결할 수 있다.

  또, 공유변수/누적변수를 사용해 컴퓨팅 노드 간 정보를 공유할 수있다.

- 스파크 코어에는 네트워킹, 보안, 스케줄링 및 데이터 셔플링 등 기본 기능이 구현되어있다.

B.  스파크 SQL

스파크와 하이브SQL 이 지원하는 SQL을 사용해 대규모 분산 정형 데이터를 다룰 수 있는 기능을 제공한다. 

- JSON, Parquet, RDB테이블, Hive table 등 다양한 정형 데이터를 읽고 쓰는데도 사용할 수 있다.

(*Parquet : 데이터, 스키마를 함께 저장할 수 있는 파일 포맷. 최근 널리 사용된다고 한다. )

- 스파크 SQL 은 DataFrame, Dataset에 적용된 연산을 일정 시점에 RDD 연산으로 변환해 일반 스파크 잡으로 실행한다. 

- '카탈리스크' 라는 쿼리 최적화 프레임워크를 제공하며,

       사용자가 직접 정의한 최적화 규칙을 적용해 프레임워크 확장도 가능하다. 

- 외부시스템은 '아파치 Thrift 서버'를 통해 JDBC, ODBC 프로토콜을 이용하여 쿼리를 실행할 수 있다. 

C. 스파크 스트리밍 

다양한 데이터 소스에서 유입되는 실시간 스트리밍 데이터를 처리하는 프레임워크이다.

지원 스트리밍 소스

- HDFS, 아파치 카프카, 아파치 플립, 트위터, ZeroMQ, 커스텀 데이터 소스.

- 스트리밍 데이터를 처리할 때는 장애 복원성이 매우 중요한데, 

    스파크 스트리밍은 장애 발생 시 연산 결과를 자동으로 복구한다. 

- 이산 스트림 방식으로 데이터를 표현. 

   => 기징 마지막 타임 윈도 안에 유입된 데이터를 RDD로 구성해 주기적으로 생성한다.

- ver 2.0 에서 정형 스트리밍 API 를 사용해 일괄 처리 프로그램을 구현하는 것처럼 스트리밍 프로그램을 구현할 수 있다.

2. 스파크 프로그램의 실행 과정

만약 한 파일 (ex. 로그파일) 이 여러 노드로 구성된 HDFS 에 분산저장 되어있다면, 

(HDFS 는 파일의 크기를 자동으로 나눠 각 블록을 클러스터의 여러 노드에 나누어 저장한다.) 

가장 먼저 스파프 셸을 시작하고 스파크 클러스터에 연결한 후,

scala 명령을 입력해 HDFS 에 저장된 로그 파일을 메모리에 로드한다. 

이 때 스파크는 데이터 지역성을 만족하기 위해 로그 파일의 각 블록이 저장된 위치를 하둡에게 요청하고, 

모든 블록을 클러스터 노드의 RAM 메모리로 전송한다. 

(* 대량의 데이터를 네트워크로 전송해야 하는 상황을 만들지 않기 위해 데이터 지역성이 필요하다.)

데이터 전송이 완료되면 스파크 shell 에서 RAM 에 저장된 각 블록 (파티션) 을 참조할 수 있다. 

(

이 파티션의 집합 => RDD 가 참조하는 분산 컬렉션. 

즉 , RDD 를 사용하면 비-분산 로컬 컬렉션을 처리하는 것과 같은 방식으로 대규모 분산 컬렉션을 다룰 수 있다. 

사용자는 컬렉션이 여러 클러스터 노드에 분산 저장된다는 사실을 굳이 알 필요가 없고, 노드 장애에 따로 대비할 필요도 없다. 

스파크는 RDD의 컬렉션에 함수형 프로그래밍을 사용할 수 있는 정교한 API 를 제공한다.

이를 통해 (1) RDD의 컬렉션 필터링하거나 사용자정의함수로 컬렉션 매핑하고,

               (2) 누적 값 하나로 리듀스하고,

               (3) 두 RDD 를 서로 빼거나 교차하거나 결합하는 등

다양한 작업 실행할 수 있다. 

)

컬렉션을 변수를 주어 필터링하면 RDD 에는 분석에 필요한 데이터만 포함된다. 

cache 함수를 호출 해 추후 다른 잡을 수행할 때도 RDD 가 메모리에 계속 유지되도록 지정할 수있다. 

** 하둡과 빅데이터 환경에서의 하둡 역할

하둡은 빅데이터를 처리하기 의해 고안됐다.
기업들이 하둡으로 처리하고 있는 데이터에는
클릭 스트림 데이터, 서버 로그, 세그먼트 데이터, 비정형 데이터, 지리적 데이터 등등이 있다.

하둡의 핵심 능력은 '데이터 지역성' 이다.
: 데이터가 저장되는 곳에서 데이터를 프로세싱

하둡은 HDFS 에 데이터를 저장하고 얀(하둡 리소스 관리 시스템)을 사용해 맵리듀스 프로세싱을 클러스터의 노드로 이동한다.
이런 맥락으로 보면 분산 파일 시스템은 데이터를 네트워크를 통해 분산 저장하고 관리하는 파일 시스템이라고 볼 수 있다.

HDFS 스케일 아웃 방식을 사용한다
- 데이터 사이즈가 커질수록 서버를 추가해 전체적인 저장능력을 증가시키는 방식

* 클러스터 컴퓨팅

클러스터 모델을 사용하는 이유는 큰 스케일의 데이터를 처리하는 것에 있다.
때문에 각각의 노드에서 실패한 작업을 단순히 실행하는 것은 의미가 없다.

* 하둡 클러스터들

: 하둡이 실행되는 머신들과 그 머신이 데이터를 저장하고 프로세싱하도록 하는 운영 시스템인
데몬, 소프트웨어 프로세스들로 구성된다.
구성 :
-하둡 프레임워크를 운영하는 데몬이 실행될 마스터 노드
-HDFS와 프로세싱을 담당하는 워커 노드들
-엣지 서버들 -> 하둡 클러스터에 접근하는 애플리케이션을 실행한다.
- 관계형 DB (하이브,스쿱,우지,휴 같은 프레임워크의 메타데이터 저장)
- 카프카, 스톰같은 특정 프레임워크를 위한 전용 서버들

하둡은 백그라운드에서 실행되는 일련의 데몬 프로세스들을 통해 스토리지와 프로세싱 역할을 수행한다. 리눅스 시스템에서 이런 데몬은 독립적인 JVM 내에서 동작한다.

클러스터의 노드 종류

1. 마스터 노드
: 클러스터의 작업을 중재한다. CLIENT들은 컴퓨팅을 하기 위해 마스터노드에 접속한다. 각각의 클러스터는 클러스터 크기에 따라 3~6개 정도로 소수의 마스터 노드들을 구성한다.
2. 워커 노드
: 마스터 노드의 지시에 따라 명령을 수행한다. 대부분의 클러스터 노드들은 워커 노드에 해당한다. 실제로 데이터가 저장되고 프로세싱하는 노드이다.


* 하둡이 효과적인 가장 큰 이유는 데이터를 네트워크로 이동하지 않는다. 프로세싱을 하는 노드로 데이터를 이동하는 대신 데이터가 저장된 노드에서 프로세싱한다. 우리는 HDFS 데이터가 저장된 노드로 작업 스케쥴을 조정할 수 있다. 이렇게 하면 네트워크 부담을 줄이고 I/O를 주로 로컬 디스크, 또는 같은 렉으로 제한할 수 있다.

* 하둡 컴포넌트, 하둡 생태계

기본 컴포넌트 위에 다른 컴포넌트를 추가할 수 있다. (EX. 하이브, 피그, 카프카, 스쿱 등)
컴포넌트를 추가하면, 하둡에 저장된 데이터를 처리하고 다른 데이터들과 통합할 수 있다.

** 하둡을 관리하는 것이 무엇인가?

* 하둡 관리

하둡은 장애허용 시스템이다.
하나의 물리적인 디스크나 시스템 전체가 잘못되더라도 실행하고 있는 job 을 망치지 않는다. 스토리지 문제로 인한 오류라면 하둡이 자동으로 다른 노드에서 같은 job 을 실행하기 때문이다.

아파치 카프카 애플리케이션 프로그래밍 책을 본 후 필요에 맞게 변형하여 정리한 내용입니다. 

1. 싱글 브로커로 구성된 카프카 클러스터

상용 파이프라인 아키텍처에 적용하는 것을 고려하면 복제 개수를 2로 잡아야 하지만, 

싱글 브로커로 구성된 카프카 클러스터를 사용하므로 최대 복제 가능 개수 값인 1로 설정.

2. 간단한 웹 페이지 개발

- 버튼을 클릭했을 때 웹 이벤트를 프로듀서로 전송하기 위해 jQuery, Ajax를 사용하여 비동기 호출 코드 생성

- 이름 입력하지 않으면 "이름을 입력하세요" 내용의 alert 창을 띄운다. 

input 태그에 이름이 포함되는 경우 프로듀서 애플리케이션으로 사용할 url 인 localhost:8080에 GET 호출 수행

/api/select로 REST API 를 받을 수 있도록 프로듀서 애플리케이션에서 작성. 

GET 호출과 함께 service, user 파라미터로 웹 이벤트 값을 전달한다. 

3. REST API 프로듀서 개발

spring boot, spring 카프카 기반으로 개발

- 스프링 부트 기반 애플리케이션 개발 위해 gradle에 라이브러리 추가

  (spring-kafka : kafka Template 을 프로듀서로 사용,

   spring-boot-starter-web : REST API를 구현하기 위한 RestController 사용

   gson : 자바 객체를 JSON포맷의 String 타입으로 변환)

(1) REST API를 받을 자바 코드 작성

- application.yml : 스프링 부트에서 사용할 리소스를 사람이 쉽게 읽을 수 있는 형태로 만든 설정 파일

                                스프링 카프카에서 사용하는 클러스터 정보, 직렬화 방식, 옵션들 설정

-ProduceController.java / RestApiProducer.java 생성

프로듀서의 acks, 메시지 키 직렬화, 메시지 값 직렬화 선언

스프링 부트 실행 애플리케이션 선언 위해 @SpringBootApplication 어노테이션 포함된 실행 클래스 생성.

public static void main에서 SpringApplication.rum() 메소드 호출함으로써 스프링 부트를 실행할 수 있다. 

사용자 웹 이벤트를 객체로 받기 위해 VO 형태로 클래스 작성. 

timestamp : REST API를 호출받은 시점을 메시지 값에 넣는 역할

                     이 값을 변수에 넣으면 컨슈머에서 병렬처리되어

                     적재 시점이 달라지더라도 최종 적재된 데이터의 timestamp 값을 기준으로 호출시간 정렬 가능!!

userAgent : REST API를 호출받을 때 받을 수 있는 사용자 브라우저 종류.

실질적으로 REST API를 받는 역할을 하는 클래스

(2) 하둡 적재 컨슈머 애플리케이션 개발

컨슈머 애플리케이션 개발 전 어떤 스레드 전략으로 데이터를 적재할지 정하고 시작해야 함. 

하둡에 데이터를 적재하는 컨슈머 애플리케이션은 하둡과 카프카 클라이언트 라이브러리를 기반으로 개발한다. 

하둡과 연동하기 위해 필요한 라이브러리

slf4j-simple : 로그 작성

kafka-clients : 카프카 컨슈머 API 사용

hadoop-client : 하둡 연동 API 사용

컨슈머 스레드들을 실행하는 자바 main 스레드. 컨슈머에 필요한 설정을 미리 정의해서 각 컨슈머 스레드에 Properties 인스턴스를 넘긴다.

컨슈머의 안전한 종료를 위한 셧다운 훅 로직이 포함된다. 

ConsumerWorker :  HdfsSinkApplication에서 전달받은 Properties 인스턴스로 컨슈머를 생성, 실행하는 스레드 클래스. 

토픽에서 데이터를 받아 HDFS에 메시지 값들을 저장한다.

어떤 방식으로 데이터를 적재하느냐는 데이터를 최종 적재하는 타깃 애플리케이션이 기능 지원 여부에 따라 다르다. (HDFS는 flush, append 둘 다 지원 가능)

나는 HDFS에 flush 방식을 사용하여 데이터를 적재하는 로직 적용

- flush 방식 : 시간 또는 개수를 기준으로 데이터를 저장. 여기서는 개수를 기준으로 버퍼에 쌓인 데이터가 10개가 넘은 경우 데이터 저장하도록 함. 

컨슈머 멀티 스레드 환경은 동일 데이터의 동시 접근에 유의해야 한다. 여러 개의 컨슈머가 동일한 HDFS 파일에 접근을 시도한다면 교착 상태에 빠질 수 있는 위험이 있기 때문이다. 

교착상태  :  ( 두 개 이상의 작업이 서로 상대방의 작업이 끝나기 만을 기다리고 있기 때문에 결과적으로 아무것도 완료되지 못하는 상태 )

이를 위해 어떤 로직으로 HDFS에 데이터를 저장할지 생각해야 함. 

가장 간단하면서도 명확한 방법은 파티션 번호에 따라 HDFS 파일을 따로 저장하는 것이다. 

1개의 컨슈머 스레드는 1개 이상의 파티션에 할당된다. 해당 컨슈머 스레드에 할당된 파티션을 assignment() 메서드를 통해 확인하고 데이터들을 각 파티션 번호를 붙인 파일에 저장한다. 

기능 테스트

위에서 사용자의 웹 이벤트를 수집하는 파이프라인을 만들기 위해 토픽을 생성했고, 프로듀서, 컨슈머, 커넥터까지 개발했다. 

개발된 코드들을 로컬 개발환경에서 실행하기 위해 

1. REST 프로듀서 실행

2. 하둡 적재 컨슈머 실행

1. brew로 하둡 설치

brew install hadoop

2. 경로찾기 

/usr/local/Cellar/hadoop/3.3.0/libexec/etc/hadoop/~~~~.sh

- 버전은 잘 확인해보기

- hadoop-env.sh, Core-site.xml, mapred-site.xml, hdfs-site.xml 총 4개 파일 수정필요

3. 하둡 실행 시 기본 파일 시스템 하둡으로 설정하기 위해 fs.defaultFS 값을 hdfs://localhost:9000으로 설정