728x90

Java 설치 

다운로드 


Hadoop 다운로드 

  • hadoop.apache.org 접속
  • Download > Binary 클릭
  • hadoop download
  • 다운로드 후 압축 풀기

환경 변수 등록

  • 시스템 속성 > 환경 변수
  • 윈도우 환경 변수에 JAVA_HOME과 HADOOP_HOME 등록
  • Path에 %HADOOP_HOME%/bin과 %JAVA_HOME%/bin 등록
  • 환경 변수 등록시 디렉토리에 띄어쓰기가 있으면 안됩니다.
    • java의 경우에는 C:\Program Files 하위에 존재하기 때문에 환경 변수 등록시 변경을 해야 합니다.
    • 그래서 설정할 때 Program Files 대신 C:\Progra~1\Java\jdk1.8.0_xxx 형태로 등록해주어야 합니다.

설정 파일 수정

etc/hadoop/core-site.xml

<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://localhost:9000</value>
    </property>
</configuration>

etc/hadoop/hdfs-site.xml

<configuration>
    <property>
        <name>dfs.replication</name>
        <value>1</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>/hadoop-3.3.2/dfs/name</value>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>/hadoop-3.3.2/dfs/data</value>
    </property>
</configuration>
* 참고
name dir과 data dir 생성
위에서 설정한 디렉토리와 동일한 위치에 생성

etc/hadoop/mapred-site.xml

<configuration>
    <property>
        <name>mapreduce.framework.name</name>
        <value>yarn</value>
    </property>
</configuration>

etc/hadoop/yarn-site.xml

<configuration>
    <property>
        <name>yarn.nodemanager.aux-services</name>
        <value>mapreduce_shuffle</value>
    </property>
    <property>
        <name>yarn.nodemanager.env-whitelist</name>
        <value>JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_HOME,PATH,LANG,TZ,HADOOP_MAPRED_HOME</value>
    </property>
</configuration>

Hadoop winutils 다운로드


 HDFS 실행

네임 노드 포맷

$ hdfs namenode -format

hdfs 시작

$ sbin/start-dfs.sh

 hdfs web ui 접속

http://localhost:9870

 yarn 실행

$ sbin/start-yarn.sh

resource manage web ui

http://localhost:8088/

예제 실행

$ hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.2.jar pi 16 10000
728x90
728x90
분산 파일 시스템

                             네트워크로 연결된 여러 머신의 스토리지를 관리하는 팡리 시스템 

 

일반적인 컴퓨터도 분산 파일 시스템을 가지고 있습니다. 

 

 

Google File system(GFS)

 

구글 파일 시스템(Google File System, GFS 또는 GoogleFS)은 구글에 의해 자기 회사 사용 목적으로 개발된 분산 파일 시스템이다.[일반 상용 하드웨어를 이용하여 대량의 서버를 연결하여 데이터에 대한 접근이 효율적이고 안정적이다. 새로운 버전의 구글 파일 시스템 코드이름은 콜로서스(Colossus)이다

 

구글 파일 시스템 - 위키백과, 우리 모두의 백과사전

 

ko.wikipedia.org

 


하둡에서는 HDFS 라는 분산 파일 시스템을 제공합니다. 

대표적인 시스템은 의 특징 : 

  • 범용 하드웨어를 사용하여 분산 파일 시스템 구성
  • 블록 단위 저장
  • 마스터/워커 구조
  • 내고장성(Fault-tolerance)제공
  • 확장성 제공

HDFS Block

하나의 파일을 여러 블록으로 저장

하둡 2에서는 기본 블록 사이즈가 128MB(하둡 1은 64MB)

실제 파일 크기가 블록 사이즈가 적은 경우 파일 크기만큼만 디스크 사용

 

 

해당 사이즈 만큼 블록사이즈로 쪼개진다. 

왜 HDFS Block 은 클까?

  • 일반적인 디스크 블록에 비해 큼(128MB)
  • 탐색 비용 최소화
  • 블록의 시작점을 탐색하는데 적게 걸림
  • 메타 데이터 크기 감소

Blcok 단위 처리 이점

  • 파일 하나의 크기가 실제 하나의 물리 디스크 사이즈보다 커질수 있음   - (1테라 바이트 인 경우 1테라보다큰 파일은 저장할수 없지만 분산 시스템에서 block 단위로 저장하게 되면 여러클러스트로 쪼개져서 저장하기 때문에 1테라보다 더 큰 데이터를 저장할수 있다. )
  • 스토리지 관리 단순화
  • 내고장성과 가용성을 지원하는 복제 기능지원적합 (즉 블록단위로 복사본을 두어서 장애처리할떄 사용가능_)

데이터 노드들이 워커 역할을 담당한다. Namenode는 메타 데이터 즉 어떤 정보가 저장되어있는지 나와있다. 

 

NameNode

메타데이터 관리

  • FsImage(파일 시스템 이미지): 네임스페이스를 포함한 데이터의 모든 정보
  • EditLog:데이터 노드에서 발생한 데이터 변환 내역

 

  • 데이터 노드 관리 

Secondary NameNode

  • Namenode의 Standby 역하링 아님
  • 체크포인트
  • FsImage와 Editlog를 주기적으로 병합
  • 주기적으로 Namenode 와  FsImage를 백업

체크포인트 과정을 살펴보자

에딘 로그에 롤링을 요청합니다.

롤링이랑 현재 로그를 새로운 이름으로 변경하고 기존의 이름으로 새로운 로그에 파일을 생성하는것

롤링을 요청한 후 에딘로그랑 fs이미지를 다운 받습니다. 그후 merge 하고  fsImage를 Namenode로 업로드 해줍니다. 

그후 fs이미지들을 NameNode에서 교체하는 작업을 하게 되고 이를 통해 에딘로그가 커지는것을 방지하고 네임노드가 재구동하는것을 빠르게 실행시킬수 있다. 또한 에딘로그가 커지면서 발생하는 디스크의 문제도 해결할수 있다. 

 

주기적으로 Namenode의 fsImage를 백업하고 난 이후 업데이터된 내용들은 반영이 되지 않아서 데이터가 유실이 될수 있다. 

DataNode

  • 실제 파일을 로컬 파일시스템에 HDFS 데이터를 저장
  • 하트비트를 통한 데이터 노드 동작 여부 전달
  • 저장하고 있는 블록의 목록을 주기적으로 네임노드에 보고

실제 HDFS 에서 파일 저장하는 과정을 보자. 

크기가 374MB이면 3개로 구성이 됩니다. 복제 개수가 2로 설정이 되어있다고 가정을 하고 

블록은 하나의 데이터노드에 저장되는것이 아닌 갯수에 맞게 각각 존재하게 된다. 

HDFS에서 기본 설정은 3입니다. 

이전에도 살펴 보았지만 하나의 DataNode가 장애가 발생하더라도 백업파일로 돌아가게 되어 문제가 없습니다. 

 

HDFS 읽기 연산 

실행되는 과정을 알아보자 

클라이언트에서 파일이 보관된 위치를 클라이언트에 반환을 하고  클라이언트는 DataNode들에게 데이터를 요구하고 읽게 됩니다. 

HDFS 쓰기 연산

파일을 쓰는 경우는 먼저 네임노드들에게 파일 정보 쓰기 요청을 하고 네임노드들에게 쓸 리스트들을 클라이언트에 주게된다.  클라이언트가 파일노드들에게 파일쓰기를 요청합니다. 

 

그리고 DataNode 간에 복제가 진행이 됩니다. 복제가 완료되면 에크 정보를 받게 되고 클라이언트가 모든 에크가 복제 되었다고 정보를 받으면 NameNode에게 완료 되었다고 알려줌. 

HDFS 추가 특징

블록캐싱 기능 제공 :

데이터노드에 저장된 데이터중에서 자주 있는 블록을 블록캐시로 데이터노드 메모리에 명시적으로  캐싱을 할수 있다.

파일 단위로도 캐싱이 가능하다 조인화 같은곳에서 읽기 성능을 향상 시킬수 있다. 

 

 

HDFS Federation 지원 

파일이 많아지기 시작하면 메모리 사용량이 증가한다 이러한 문제를 지원하기 위해서 버전2부터는 Federation 즉 네임노드를 등록하여 사용하게 되는것이고 각각의 디렉토리마다 네임노드를 실행해서 관리하게 합니다. 

그러면 메모리 문제를 해결할수 있습니다. 

 

고가용성(HA)지원

 네임노드의 문제가 발생하면 모든 작업이 중단되고 파일을 읽거나 쓰는것을 할수 없어서 버전2에서는 고가용성(active랑 스탠바이)을 지원하고 

메타 데이터 정보를 유지하고 있다가 Active가 오류가 있으면 스탠바이네임이 작동한다. 

 

728x90
728x90

클러스터(Cluster)란?

-여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합 

클러스터는 확장성을 가지고 있어서 work -node만 추가하면 확장을 하는 구조를 가지고 있습니다. 

Gateway 노드를 따로 두는데 설정파일등을 통해서 클라이언트들의 조건을 통제하것을 수행합니다. 

 

마스터/work Architecture 

철수가 사정상 프로젝트 C를 못하는상황이 생기면 해당 프로젝트를 올바르게 대처를 할수 없기에 

프로젝트 별로 담당자를 한명이 아닌 두명이 담당을 하면서 백업 식으로 일 처리가 돌아가게 됩니다.  

즉 철수가 없더라고 영희가 해당 프로젝트를 처리할수 있습니다. 

사람이 즉 노드가 되어 한 노드가 작동을 못하더라도 다른 노드가 해결을 할수 있습니다. 

 

정상적으로 동작을 하지 않아도 장애상황을 대응 하기 위해 다른 work에 파이션을 저장을 해놔서 큰 문제가 일어나지 않습니다. 

 

클러스터 규모 결정하기 

 

스토리지 용량으로 결정하기

  • 저장될 데이터 크기 예측
  • 복제 전략 결정
  • 저장 기간 고려
  • 필요한 노드 수 결정

예시

 

저장될 데이터 크기 예측

  • 하루에 저장되는 데이터의 크기는 1TB

복제 전략 결정

  • 복제 계수는 3

저장 기간 고려 

  • 3년

필요한 노드 수 결정

  • 서버 한대의 저장 용량 : 5TB*12
  • 70대

스토리지 용량으로 결정하기 - 추가 고려사항

  • 데이터 포맷
  • 데이터 압축 여부
  • 데이터 증가율의 변화

데이터 수집 속도로 결정하기 

  • 데이터 수집 속도 예측
  • 데이터 처리 속도 예측

데이터수집 속도로 결정하기 

  • 1테라비아트 데이터 분석
  • 5분이내에 결과를 저장
  • 쓰기 속도는 디스크당 초당 50MB
  • 디스크 70개가 병렬로 써야함
  • 서버당 디스크가 24개씩 있느 ㄴ경우
  • 약 3대의 서버가 필요

 

클러스터 하드웨어 결정

워크로드에 따른 하드웨어 선정

  • CPU 
  • Memore
  • I/O

AWS에서 EMR 클러스터를 구축할때 어떤 워크로드를 가지고 있냐에 따라 어떤 인스턴스 타입을 선택할지 결정하는것이 워크 로드에 따른 하드웨어 결정을 하는것과 비슷합니다. 


 Hadoop 구성요소 

하둡을 버전을 비교해볼때 크게 변화가 되었습니다.

 

 1.0은 2개의 컴포넌트만 존재하지만 2.0은 중간에 Yarn이 추가가 되어 다른 애플리케이션도 동작을 시킬수 있습니다 

예를 들면 아파치 스파크 flink 등 분산 애플리케이션을 동작을 시킬수 있습니다. 

 

버전 1의 타입 입니다. 

가장 큰 문제점은 namenode가 단일 장애 지점이라서 동기화의 시간차이가 있기때문에 Secondary namenode가 존재해도 일부 데이터가 유실될수 잇는 문제가 있다.

또한, 클러스터 전체 사용률이 굉장히 낮았습니다.

그리고 jobtracker 역시 클래스터 전체 리소스를 관리하기 때문에 부화가 많이 발생을 한다. 

MapReduce외에도 다른 작업을 실행할수 없는 문제점이 있다. 

 

하둡 버전 2.0

1.0과 달리 맵퍼와 리듀서의 슬롯이 별도로 존재하지 않고 둘 다 컨테이너 안에서 동작하여 컨테이너 자체도 따로 슬롯이 ㅅ는것이 아니라 전체 클러스터의 리소스 상황과 요처된 잡의 리소스 요구에 따라 컨테이너가 몇개 실행될지 결정됩니다. 

(jopTracker task tracker 대신에  Resource Manager와 node manager가 추가가 되었습니다.) 

2.0에서는 하둡1.0에서 4만개 이상의 테스크를 동시에 실행하지 못하는 문제를 Resource Manager와 Application Master의 분리로 해결하였습니다. 

 

Hadoop 3

  • Erasure Coding 지원
  • YARN Timeline Service v2 도입
  • Java 8
  • NameNode이중화 기능 강화 

2개이상의 NameNode기능을 제공합니다. 

 


 

728x90

'ML > Hadoop & Spark' 카테고리의 다른 글

Hadoop window 설치  (0) 2022.07.28
Hadoop - HDFS 분산 파일 시스템  (0) 2022.07.21
데이터파이프라인 오케스트레이션  (0) 2022.07.21
데이터 파이프라인 패턴  (0) 2022.07.20
데이터 파이프라인이란?  (0) 2022.07.20
728x90

오케스트레이션이란?
 
여러개의 컴퓨터시스템, 애플리케이션 또는 서비스를 조율하고 관리하는것 
복잡한 Task와 workflow를 쉽게 관리 할수 있도록 도와주는 역할

데이터 파이프라인 예)
구축해주면 한가지 job만 하느것이 아니라 여러가지의 job을 해결해준다. 
 
 

워크플로 관리 도구의 필요성
 

  •  스크립트의 한계
  •  워크플로가 복잡
  • Task의 의존 관계가 복잡
  • 실패 시 처리 어려움(결과를 매번 확인해야하며 실패하면 처음부터 다시해야한다.)

 
워크플로 관리도구 기능

  • 스케쥴링
  • Takst 의존관계 정의
  • 실행 결과 알림 및 보관
  • 실패시 재실행

DAG(Directed Acyclic Graph)
방향성(Directed)
간선에 방향이 존재
(그래프에서 노드와 간선으로 이루어져있다.)
비순환(Acyclic)
사이클이 존재하지 않음
 그래프의 한 정점에서 시작하여 다시 시작정점으로 이어지는 간선이 존재하지 않음
 
DAG의 대표적인 예로
게임에서 사용하는 스킬트리입니다. 
특정 스킬을 활성화 하기 위해서는 해당 스킬부터 차근차근 찍어줘야 사용할수잇다.
 

 
 
실제 task들의 의존관계이다. 
DAG의 의한 데이터 구조라고 표현이 되고 task의 의존관계를 dag으로 표현한다. 
 

 
airflow 에서 사용하는 워크플로 

Apach Oozie 도 있는데 Oozie에서만 제공하는 기능만 사용할수 있고, airflow 와 같이 추가적으로 해결을 못하고 코드가 길어지는 단점이 있지만
워크플로워를 누구나 다 동일하게 작성해서 협업이나 유지보수에서는 좋은 장점이다. 
 
실행 결과 알림 및 보관 

복구

실패 시 복구 방법

  • 재시도 -  일시적인 문제를 대응하기에는 좋은것이다. (재시도 횟수가 너무 많으면 task의 오류를 늦게 발견하게 된다.)2~3 회 정도 하는것을 추천하고 아니면 해당 task의 문제를 해결해야한다. 
  • backfill - 일정기간동안 워크플로우를 재실행하는것이다. 한번에 많은\이터를 처리할수 있다.

 

오픈소스 워크플로 관리 도구 비교 

 

 

728x90
728x90

데이터 분석

 외부 데이터, 내부 데이터, 로그데이터 들이 따로 존재하였습니다. 

 

데이터웨어하우스는 대량의 데이터를 처리하고 오래동안 보관하는것에 최적화 되어있습니다.

소량의 데이터를 처리하는것에서는 효율적이지 못합니다.

 

 

정규화된 스키마 vs 스타 스키마 

 

 

일반적으로 RBD는 정규화된 스키마입니다. 

RBD에 있는 데이터를 웨어하우스에 저장하면 비효율적입니다. 

분석을 위한 쿼리로는 비효율적이다. 각각의 테이블들을  조합을 해야하기 때문입니다. 

그래서 다르게 구성된 스키마가 오른쪽 같은 스타 스키마입니다. 

 

ETL 와 ELT

  • 추출: 원본 데이터베이스 또는 데이터 소스에서 소스 데이터를 가져오는 것을 추출이라고 합니다. ETL에서는 데이터가 임시 스테이징 영역으로 들어갑니다. ELT의 경우, 데이터는 데이터 레이크 스토리지 시스템으로 곧바로 들어갑니다.
  • 변환: 변환이란 대상 데이터 시스템 및 해당 시스템의 나머지 데이터와 통합할 수 있도록 정보의 구조를 변경하는 과정을 일컫습니다.
  • 로드: 로드란 정보를 데이터 스토리지 시스템에 보관하는 과정을 말합니다.

 

 

앞서 설명한 바와 같이 ETL과 ELT는 이 세 가지 단계를 서로 다른 순서로 수행합니다. 여기에서 질문이 생깁니다. 데이터 변환 시점은 데이터 리포지토리에 데이터를 로드하기 과  중 어느 쪽이 바람직할까요? 질문에 답변을 하려면 ETL와 ELT를 따로 이해해야 합니다.

 

따라서 변환이 로드 전에 발생해야 하므로 데이터 웨어하우스에서는 ETL을 요구합니다. ETL을 이해하는 데 필요한 몇 가지 세부 사항은 다음과 같습니다.

  • 명확한 워크플로우를 통한 지속적인 프로세스: ETL은 가장 먼저 같은 유형 또는 다른 유형의 데이터 소스에서 데이터를 추출합니다. 그다음, 데이터를 스테이징 영역에 보관합니다. 스테이징 영역에서 데이터는 정제 과정을 거쳐 보강되고 변환되어 마지막으로 데이터 웨어하우스에 보관됩니다.
  • 데이터 엔지니어 및 개발자가 필요한 상세 계획, 감독, 코딩을 하는 데 사용: 데이터 웨어하우징에서 기존의 핸드 코딩 ETL 변환 방식은 엄청난 시간이 소요되었습니다. 프로세스가 설계된 후에도 새로운 정보로 데이터 웨어하우스를 업데이트할 때는 데이터가 각 단계를 거치는 데 시간이 걸렸습니다.
  • 쉽고 빠른 최신 ETL 솔루션: 특히 클라우드 기반 데이터 웨어하우스와 클라우드 기반 SaaS 플랫폼의 경우 최신 ETL의 진행 속도가 훨씬 빠릅니다. Integrate.io 같은 클라우드 기반 ETL 솔루션을 사용함으로써 사용자는 프로그래밍 전문가 없이도 다양한 소스에서 즉각적으로 데이터를 추출, 변환, 로드할 수 있습니다.

 

 

 

 

 

ETL

ETL의 최대 장점

ELT 대비 ETL의 가장 큰 장점 중 하나는 OLAP 데이터 웨어하우스가 사전 구성된다는 특성과 관련이 있습니다. 데이터가 구조화되고 변환되면 ETL을 통해 더욱 빠르고 효율적이며 안정적으로 데이터를 분석할 수 있습니다. 반대로 ELT는 빠른 분석을 요구하는 작업에는 적합하지 않습니다.

ELT 대비 ETL의 또 다른 커다란 장점은 규정 준수에 있습니다. GDPRHIPAA 또는 CCPA의 규정을 따르는 기업은 고객 개인 정보 보호를 위해 특정 데이터 필드를 제거, 마스킹 또는 암호화해야 하는 경우가 많습니다. 여기에는 이메일을 도메인으로 변환하거나 IP 주소의 마지막 부분을 제거하는 작업이 포함될 수 있습니다. ETL의 경우 데이터 웨어하우스에 데이터를 로드하기 전에 변환하기 때문에 더욱 안전하게 변환을 수행할 수 있습니다.

반면, ELT의 경우에는 먼저 민감한 데이터부터 업로드해야 합니다. 그 결과 시스템 관리자가 액세스할 수 있는 로그에 데이터가 나타나게 됩니다. 또한, ELT를 사용하여 데이터를 변환하면 데이터를 데이터 레이크에 업로드할 때 미준수 데이터가 EU를 벗어날 경우 EU의 GDPR 규정 준수 표준을 의도치 않게 위반할 수 있습니다. 궁극적으로, ETL의 경우 미준수 데이터가 실수로 데이터 웨어하우스나 보고서에 나타나는 일이 절대 없기 때문에 규정 준수 위반의 위험이 낮습니다. 

마지막으로, 데이터 통합/변환 프로세스로서 ETL은 20년 이상 존재해 왔습니다. 즉, 데이터 추출, 변환, 로드 요구 사항을 지원해줄 수 있는 제대로 개발된 ETL 툴과 플랫폼이 많습니다. 또한 ETL 파이프라인 설정에 능숙한 숙련된 데이터 엔지니어를 쉽게 찾을 수 있습니다.

 

ELT 프로세스는 데이터 레이크와도 밀접한 관련이 있습니다. "데이터 레이크"는 OLAP 데이터 웨어하우스와 달리 모든 종류의 구조화된 데이터 또는 구조화되지 않은 데이터를 수용하는 특별한 종류의 데이터 저장소입니다. 데이터 레이크의 경우 데이터를 로드하기 전에 변환해야 합니다. 모든 유형 원시 정보는 형식이나 부족 여부에 상관없이 데이터 레이크에 즉시 로드할 수 있습니다.

데이터를 비즈니스 인텔리전스 플랫폼으로 분석하기 전에도 데이터 변환이 필요합니다. 그러나 데이터 정리, 보강, 변환은 데이터가 데이터 레이크에 로드된 후에 진행됩니다. ELT와 데이터 레이크를 이해하는 데 필요한 몇 가지 세부 사항은 다음과 같습니다.

  • 속도가 빠른 클라우드 기반 서버를 통해 가능해진 신기술: ELT는 최신 클라우드 기반 서버 기술로 덕분에 가능해진 비교적 새로운 기술입니다. 클라우드 기반 데이터 웨어하우스는 거의 무한대의 스토리지 기능과 확장 가능한 처리 능력을 제공합니다. 예를 들어 Amazon Redshift 및 Google BigQuery와 같은 플랫폼의 뛰어난 처리 역량을 기반으로 ELT 파이프라인 구축이 가능해집니다.
  • 데이터 사용 가능 시 모든 것을 수집: ELT를 데이터 레이크와 함께 사용하면 데이터가 사용 가능해지는 즉시 지속적으로 확장하는 원시 데이터 풀을 수집할 수 있습니다. 데이터를 데이터 레이크에 저장하기 전에 특별 형식으로 변환할 필요는 없습니다.
  • 필요한 데이터만 변환: ELT는 특정 분석 시에 필요한 데이터만 변환합니다. ELT 때문에 데이터 분석 프로세스는 느려질 수 있지만 다양한 유형의 메트릭, 예측, 보고서 등을 생성하기 위해 즉시 다양한 방식으로 데이터를 변환할 수 있으므로 유연성은 더 높습니다. 반대로 ETL을 사용하면, 사전에 결정된 구조로는 새로운 유형의 분석이 불가능할 경우 전체 ETL 파이프라인과 OLAP 웨어하우스의 데이터 구조를 변경해야 할 수도 있습니다.
  • ETL보다 안정성이 부족한 ELT: 아직 발전 단계에 있는 ELT 툴과 시스템은 OLAP 데이터베이스와 함께 사용할 수 있는 ETL에 비해 안정성이 떨어집니다. ETL이 설정은 더 힘들어도 대규모 데이터 풀을 처리할 때는 보다 정확한 인사이트를 제공합니다. 또한 ETL 개발자보다 ELT 기술을 사용할 줄 아는 ELT 개발자를 찾기가 더 어렵습니다.

 

 

ELT란?

ELT는 "Extract(추출), Load(로드), Transform(변환)"의 약자입니다. ELT 프로세스에서는 기본 변환을 수행하기 위해 데이터 웨어하우스를 통해 데이터가 활용됩니다. 따라서 데이터 스테이징이 필요하지 않습니다. ELT는 구조화된 데이터, 구조화되지 않은 데이터, 반구조화된 데이터, 원시 데이터 형식 등 모든 데이터 형식에 클라우드 기반 데이터 웨어하우징 솔루션을 사용합니다.

이미지나 동영상 등 데이터 웨어하우스에 넣을수 없어서 나온것이 ELT입니다. 

 

ELT로 트랜드가 바뀌는 추세입니다.

ELT로 바뀌면서 

ELT의 최대 장점

ETL 대비 ELT의 주요 장점으로는 유연성과 새로운 구조화되지 않은 데이터 저장의 용이성이 있습니다. ELT를 사용하면 처음에 정보를 변환하고 구조화할 수 있는 시간이나 기술이 없어도 모든 유형의 정보를 저장할 수 있기 때문에 원할 때 언제든지 모든 정보를 즉시 사용할 수 있습니다. 아울러, 데이터 수집 전에 복잡한 ETL 프로세스를 개발할 필요가 없고 개발자와 BI 분석가가 새로운 정보를 처리할 때 시간을 절약할 수 있습니다. 

기타 ELT의 이점은 다음과 같습니다.

이점 #1: 빠른 속도

데이터 가용성 측면에서 ELT가 더 빠른 옵션입니다. ELT를 사용하면 모든 데이터가 시스템으로 즉시 들어가고, 사용자는 변환과 분석이 모두 필요한 데이터를 정확히 판단할 수 있습니다.

이점 #2: 유지 관리의 번거로움 감소

ELT를 사용하면 일반적으로 사용자는 수동적인 개입이 필요한 유지 관리 계획을 수립하지 않아도 됩니다. ELT는 클라우드 기반이므로 사용자의 수동 업데이트에 의존하지 않고 자동화 솔루션을 활용합니다. 

이점 #3: 신속한 로드

데이터가 웨어하우스에 들어가기 전까지는 변환 단계가 일어나지 않으므로 데이터를 최종 위치에 로드하는 데 소요되는 시간이 단축됩니다. 데이터가 정리 또는 변경될 때까지 기다릴 필요가 없으며, 데이터는 대상 시스템에 한 번만 들어가기만 하면 됩니다.

가장 좋은 ELT 사용 방법

이 게시글에서 설명한 바와 같이 ETL과 ELT의 비교는 여전히 진행 중인 논쟁 대상입니다. 그렇다면 어떤 상황에서 ETL 대신에 ELT 사용을 고려할 수 있을까요? 몇 가지 사용 사례를 소개합니다.

사용 사례 #1:

방대한 양의 데이터를 보유한 기업. ELT는 구조화된 데이터 및 구조화되지 않은 데이터를 모두 대량으로 사용할 때 가장 적합합니다. 대상 시스템이 클라우드 기반일 때 ELT 솔루션보다 더 신속하게 대규모 데이터를 처리할 수 있는 가능성이 높습니다.

사용 사례 #2:

필요한 처리 능력을 다룰 수 있는 리소스를 갖춘 조직. ETL 사용 시, 대부분의 처리는 데이터가 웨어하우스에 들어가기 전에 파이프라인에 존재하는 동안 진행됩니다. 반면 ELT는 데이터가 데이터 레이크에 도달하면 작업을 진행합니다. 목적에 부합하는 데이터 처리에 필요한 요구 사항에 따라 소규모 기업은 데이터 레이크의 이점을 충분히 누리기 위해 필요한 광범위한 기술을 개발 또는 탐색할 만한 재정적 여유가 부족할 수 있습니다.

사용 사례 #3: 

최대한 빨리 모든 데이터를 동일 위치에서 사용해야 하는 기업. 프로세스의 마지막 단계에 변환이 진행되면 ELT는 전송 속도를 최우선시하므로 좋고 나쁨을 떠나서 모든 데이터가 추후 변환을 위해 데이터 레이크에 들어가게 됩니다.

 

 

 

요약

  • ETL은 Extract(추출), Transform(변환), Load(로드)의 약자이고, ELT는 Extract(추출), Load(로드), Transform(변환)의 약자입니다.
  • ETL에서 데이터는 데이터 소스에서 스테이징을 거쳐 데이터 대상으로 이동합니다.
  • ELT에서는 데이터 대상에서 변환을 수행하므로 데이터 스테이징이 필요하지 않습니다.
  • ETL은 민감한 데이터가 데이터 대상에 로드되기 전에 정리되므로 데이터 개인 정보 보호와 규정 준수에 도움이 되는 반면, ELT는 더 간단하며 데이터 요구 사항이 많지 않은 기업에 적합합니다.

 

 

이 글을 더 자세히 읽고 싶으면 링크를 타고 가기 바랍니다. 장단점을 표로 나타내어 보기가 편합니다. 

 

 

 

Data Lake란?

링크를 타고 가면  아주 잘 설명이 되어있습니다. 

Data Lake

 

1단계 : 원본 데이터

2단계 : 분석용 데이터

3단계 : 피치 데이터(ML,AI)/ 집계 데이터

 

Data Lake vs Data WareHouse

 

                  데이터 레이크와 데이터 웨어 하우스는 종종 혼동되지만, 이 둘은 동일하지 않으며 그 목적도 다릅니다. 둘 다 빅데이터를 위한 데이터 스토리지 리포지토리라는 것만이 유일한 유사점입니다. 많은 기업들이 데이터 웨어하우스와 데이터 레이크를 모두 사용하여 특정 요구 사항과 목표를 충족합니다.

 

데이터 웨어하우스보고를 위해 설계된 구조화된 데이터 모델을 제공합니다. 이는 데이터 레이크와 데이터 웨어하우스의 주요 차이점입니다. 데이터 레이크는 현재 정의된 용도가 없는 비정형 원시 데이터를 저장합니다. 

데이터는 데이터 웨어하우스에 저장하기 전에 처리되어야 합니다. 이때 데이터 웨어하우스에 어떤 데이터를 포함할지 결정하게 되는데, 이를 "쓰기 스키마(schema on write)"라고 합니다. 

 

데이터를 데이터 웨어하우스에 저장하기 전에 데이터를 정제하는 프로세스는 시간이 오래 걸리고 어려울 수 있으며 몇 개월 또는 몇 년씩 걸리는 경우도 있으므로, 즉시 데이터를 수집할 수 없습니다. 데이터 레이크를 활용하면 즉시 데이터를 수집하여 향후 해당 데이터를 어디에 사용할지 파악할 수 있습니다.

 

데이터 구조 때문에, 정기적인 보고에 어떤 데이터가 필요한지 미리 알고 있는 비즈니스 애널리스트와 다른 비즈니스 사용자가 데이터 웨어하우스를 더 자주 사용합니다.

데이터 레이크는 데이터를 이용해 연구를 수행하는 데이터 과학자 및 애널리스트가 보다 자주 사용하며, 데이터를 사용하려면 고급 필터 및 분석이 적용되어야 합니다.

 

데이터 레이크와 데이터 웨어하우스는 일반적으로 다른 하드웨어를 이용하여 데이터를 저장합니다. 데이터 웨어하우스는 비용이 많이 들 수 있는 반면, 데이터 레이크는 대규모임에도 불구하고 상용 하드웨어를 자주 사용하기 때문에 그보다 비용이 저렴합니다.

 

 

 

 

728x90

+ Recent posts