NT형 인간

ETL 설계서 문서화 1~4단계를 거치며 도출된 결과는 ETL 시스템을 위한 상세 구성을 수립하기 위한 문서화 과정이다. 이러한 과정을 완료하기 위해 원천 시스템과 데이터를 사용해야 할 때가 있는데, 이를 위해 원천과 똑같이 복제한 정적 스냅샷인 샌드박스 시스템을 구현할 수 있다. 1단계: 고수준 계획의 도식화 기획 단계에서 정해진 정보들을 통해 매우 간단하게 도식을 그린다. 2단계: ETL 도구 선택 3단계: 기본 전략 수립 ETL 시스템에서 공통적인 컨벤션이나 활동에 필요한 기본 전략을 도출한다. 다음과 같은 것들이 공통 활동으로 여겨진다. 각 주요 원천 시스템에서 추출하는 방법 추출한 데이터를 스테이지에 보관하는 방법 딤멘션과 팩트의 품질을 관리하는 방법 디멘션 데이터의 이력을 관리하는 방법 DW와..

34개의 ETL 서브시스템 ETL 시스템 아키텍쳐는 34개의 핵심적인 서브시스템으로 이루어진다. 서브시스템들은 4개의 주요 프로세스로 구분된다. I. 추출 원천으로부터 데이터의 변화 없이 ETL 환경의 디스크에 쓰는 프로세스 1. 데이터 프로파일링 DW에 적재하기에 적절한 데이터 소스인지, 데이터 소스에 어떠한 데이터가 있는지 등을 파악하는 단계이다. 데이터 프로파일링은 데이터의 내용, 일관성, 구조를 설명하는 기술적 분석 과정이다. SELECT DISTINCT와 같은 쿼리 또한 프로파일링의 일종으로 볼 수 있다. 이 과정을 통해 좀 더 나은 데이터 수집 방법, 개발 일정 등 요구 수준에 맞게 계획을 세울 수 있다. 데이터 프로파일링은 신뢰도 있는 ETL 시스템 구축의 첫번째 단추이다. 2. CDC 시스..

Fact 테이블에서 대리 키(Surrogate key)를 사용할 시의 이점 대리키란, 테이블을 이루는 컬럼들 가운데 유일하게 식별하기에 적합한 단일 후보키가 존재하지 않을 때 추가할 수 있는 임의의 식별번호로 이루어진 후보키(Candidate key)이다. 차원 테이블과는 다르게, 팩트 테이블에선 대리키에 대해 강한 필요성은 없다. 일반적 DW의 백룸(backroom; 사용자에게 보이는 부분이 아닌 시스템 내부를 일컫는다. Kimball은 식당에서의 홀과 주방의 비유를 통해 이를 설명하였다.)인 ETL 작업을 위해 대리키를 적용한다. 팩트 테이블에 대리키를 적용하면 쿼리 성능이 저하되는 대신, 다음과 같은 이점이 있다. 즉각적인 unique 식별 ETL 처리 도중 여러 차원을 탐색하지 않아도 특정 행을 ..

"모든 것을 더 이상 간단해질 수 없을만큼 가능한 간단하게 만들어라" 1. 비즈니스 프로세스 선택 비즈니스 프로세스란, 주문 받기, 송장 발행, 결제 받기, 서비스 요청 처리, 학생 등록, 의료 절차 수행 또는 청구 처리와 같이 조직에서 수행하는 낮은 수준의 활동이다. DW/BI 사용자가 분석하고자 하는 성과 측정값은 비즈니스 프로세스의 이벤트에 주로 포함된다. 2. 그레인 정의 개별 팩트 테이블의 행이 나타내는 내용을 정확히 지정한다. 비즈니스 프로세스가 포함하는 최대한 자세한 속성의 집합을 그레인이라 한다. 고객 판매 거래에서 개별 제품을 스캔할 때마다 한 행, 의사로부터 받은 청구서의 한 항목당 한 행, 창고에 있는 각 품목의 재고 수준에 대한 일일 스냅샷당 한 행 등 비즈니스 프로세스의 이벤트를 ..

Hadoop v1 아키텍쳐 Hadoop v1과 v2의 가장 큰 차이점은 YARN의 존재이다. Hadoop v1의 아키텍쳐에는 YARN(Yet Another Resource Negotiator)이란 자원관리매니져가 없다. MapReduce 작업을 실행하기 위해 작업과 자원을 할당받기 위해 Master node의 역할을 하는 Job Tracker, Worker node의 역할을 하는 Task Tracker가 사용되었다. 사용자는 Map Task과 Reduce Task로 이루어진 작업을 client에 제출한다. client는 작업을 attempt의 단위로 분할하여 Job Tracker에 보낸다. Job Tracker는 자원과 작업 단위를 각 worker node의 Task Tracker에 분배하여 작업을 실행..

Twitter 실시간 처리를 위해 RabbitMQ를 사용할까 하다가 Zookeeper도 설치되어 있을 겸 Kafka를 사용하여 실시간 처리를 진행하려 한다. Kafka란? Apache Kafka는 실시간으로 Record 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산 데이터 스트리밍 플랫폼이다. 하루에 1조4천억 건의 메시지가 생성되어 이를 처리하기 위해 LinkedIn이 개발한 내부 시스템으로 시작 했으며, Pub-Sub 모델의 메시지 큐 구조를 지닌다. Kafka의 특징 확장성, 높은 처리량, 낮은 지연시간, Fault Tolerance and Reliability, 내구성을 지닌다. Kafka Components Topics 특정 이름이나 분류를 가지는 메시지 스트림을 Topic이라 일컫는다...

Airflow는 Python을 기반으로 DAG를 작성하여 Workflow를 관리하는 도구이다. 수많은 데이터 파이프라인을 Reliable하게 관리, 실행, 모니터링하여 오케스트레이션할 수 있도록 도와준다. Workflow 관리 도구로 Oozie가 있지만, Hadoop과 강한 Coupling을 가지기 떄문에 많은 기업에서 사용되는 Airflow를 익히려고 한다. Airflow의 구성 Scheduler: Workflow를 스케줄링하는 데몬이다. Web Server: Airflow의 웹 인터페이스를 제공하는 웹 서버이다. Flask와 Gunicorn을 이용하여 인터페이스를 제공한다. MetaStore: 메타데이터가 저장되는 데이터베이스이다. 주로 Postgresql을 추천하지만, SQL Alchemy와 호환 ..

실시간의 정의는 사용자의 요구사항에 따라 그 범위가 바뀔 수 있다. 예컨데 수초에서 수십초 간 일어난 이벤트를 작은 배치에 담아 시간적 범위에 따라 처리할 수 있고, 이벤트가 일어난 후 일정 간격을 두는 지연에 따라 처리할 수 있다. Spark Streaming은 Event-driven 아키텍쳐로 구현되어 낮은 수준의 지연시간과 일정한 응답속도를 보장하여 예측 가능한 성공을 제공한다. Event-driven Architecture Event 이벤트란 시스템 하드웨어 또는 소프트웨어 상태의 변화 또는 사건의 발생을 의미한다. 시스템의 다른 부분에 이벤트가 발생했음을 알리기 위해 해당 시스템에서 보내는 메시지 또는 알림을 뜻하는 이벤트 알림과는 다르다. 이벤트는 마우스 클릭이나 키보드 입력과 같은 사용자 또..

Hadoop과는 다른 데이터 처리 방식을 채택한 Spark는 RDD(Resilient Distributed Dataset)라는 새로운 데이터 구조를 개발하였다. Spark에서 내부적으로 연산하는 데이터들은 모두 RDD타입으로 처리된다. RDD의 특징 Immutable, Partitioned Collections of Record RDD 는 여러 분산 노드에 걸쳐서 저장되는 데이터(객체)의 집합이다. RDD는 데이터셋을 생성하여 메모리에 적재시키는 이후로는 변경이 불가능하다. RDD는 다수의 파티션으로 쪼개져 여러 분산 노드에 나뉘어져 관리된다. RDD는 데이터가 저장되어있는 File System에서 메모리상으로 데이터를 로딩할 때, 코드에서 생성되는 데이터를 메모리에 저장할 때 생성된다. RDD 연산 R..

UC버클리 AMP 랩에서 개발한 In-Memory 방식의 분산 처리 시스템이다. 시스템의 목적은 기존 디스크IO에 대한 지연시간 개선, 메모리를 사용하여 반복적인 작업이나 스트리밍 데이터를 효율적으로 처리하기 위해서이다. Spark 프레임워크는 그 중심부에 Spark Core, 그 위에 Spark Streaming, Spark SQL, GraphX 등과 같은 각종 모듈들이 존재한다. Spark Core Spark 전체의 기초가 되는 분산 작업 처리, 스케줄링, 입출력, API 인터페이스의 기능을 제공해준다. Spark SQL SQL문을 기반으로 쿼리를 수행하며 데이터를 처리할 수 있는 질의형 처리 도구이다. Hive 메타스토어를 사용하여 연결할 수 있다. Spark Streaming 실시간 데이터 처리를..