Data

airflow 스케줄러Airflow 스케줄러의 역할Airflow 스케줄러는 모든 태스크와 DAG를 모니터링하며, 해당 DAG가 실행될 수 있는지 주기적으로 확인한다.주기적으로 (매분 또는 설정된 주기에 따라) 활성화된 태스크들을 검사하여 실행할 수 있는지 확인한다.스케줄링 간격에 따른 실행schedule_interval을 1일로 설정한 DAG이 있을 경우, 실행되는 실제 실행 시간은 그 기간이 끝난 후에 시작된다.예를 들어, 2023-01-01에 실행되도록 설정된 DAG은 2023-01-01 23:59가 지나야 실행되며, 실행된 시각은 2023-01-02로 찍힌다. 즉, Airflow는 주어진 기간이 끝난 후, 1번의 주기가 지난 후에 작업을 실행한다.실행 시간 (Execute Time)start_dat..

주요 포인트:ProviderProvider 정의Airflow Provider는 Apache Airflow 내에서 특정 기능이나 외부 시스템과의 통합을 의미한다.Providers는 Airflow가 다양한 외부 시스템, 서비스, 또는 기술과 상호작용하고 지원할 수 있도록 한다.Provider의 목적:Airflow의 Providers는 Airflow가 외부 시스템, 서비스, 기술과 상호작용할 수 있도록 하여 기본 기능을 넘어서는 작업을 처리할 수 있게 한다.모듈화된 아키텍처:Airflow는 모듈화된 아키텍처로 설계되어 있어 다양한 Providers를 쉽게 추가할 수 있다. 이로 인해 Airflow의 기능이 외부 시스템과 상호작용하거나 특정 시스템에 맞게 확장될 수 있다.Providers는 일반적으로 다음과 같..

구성Airflow 주요 구성 요소웹 서버 (Web Server):사용자가 워크플로의 상태와 진행 상황을 모니터링하고 시각화할 수 있는 사용자 인터페이스(UI)를 제공한다.스케줄러 (Scheduler):DAG(Directed Acyclic Graph)에서 정의된 의존성과 일정에 따라 작업의 실행을 조정한다. 작업이 언제(when) 어디서(where) 실행될지 결정한다.메타데이터 데이터베이스 (Metadata Database):DAG, 작업 및 작업 상태와 관련된 메타데이터를 저장하여 영속성 및 장애 복구 기능을 제공한다.실행기 (Executor):작업이 어떻게 실행될지를 정의한다. Airflow는 LocalExecutor, CeleryExecutor, KubernetesExecutor 등 다양한 실행기를 ..

토픽(topic)정의 및 특징데이터를 분류하고 저장하기 위한 기본 단위메시지를 pub/sub 할 수 있는 논리적 채널kafka 클러스터 안에 있는 데이터 스트림db의 테이블과 개념 유사topic은 Producer가 데이터를 전송하고, Conusumer가 데이터를 읽는 단위하나의 Kafka 클러스터에서 다수의 topic 을 생성할 수 있음.각 topic 은 partition 으로 분리되어 데이터를 분산 저장함파티션(partition)정의 및 특징Kafka 토픽을 물리적으로 나눈 단위병렬 처리 및 분산 처리 하기 위해 사용됨각 파티션은 하나의 순서를 가지고 데이터가 특정 순서대로 기록됨오프셋(offset)정의 및 특징Kafka 파티션 내에서 메시지가 저장된 위치를 나타내는 고유한정수 값각 파티션마다 오프셋은..

1. 파티션 개요파티셔닝은 테이블 또는 인덱스를 파티션 단위로 나누어 저장하는 것을 말함.테이블을 파티셔닝하면 파티션 키에 따라 물리적으로는 별도의 세그먼트에 데이터를 저장하며, 인덱스도 마찬가지다.파티셔닝이 필요한 이유에 대해 설명해보자면 인덱스 스캔도 결국 데이터가 일정량이 넘어가는 순간 Random Access가 많아지고, 그렇다고 Full Scan 하기에는 너무 비효율적이다.관리적 측면 : 파티션 단위 백업, 추가, 삭제 변경성능적 측면 : 파티션 단위 조회 및 DML 수행, 경합 및 부하 분산2. 파티션 유형1) Range 파티셔닝파티션 키 값의 범위로 분할파티셔닝의 가장 일반적인 형태이며, 주로 날짜 컬럼을 기준으로 함 (예를 들어, 판매 데이터를 월별로 분할)2) Hash 파티셔닝파티션 키 ..

1. 인덱스 유지 비용테이블 데이터를 변경하면 관련된 인덱스에도 변경이 발생변경된 인덱스 레코드를 찾아가는 비용 + Redo, Undo 생성 비용이 발생그래서 인덱스 개수가 많을수록 DML 성능이 나빠짐Update를 수행할 때, 테이블 레코드는 직접 변경하지만 인덱스 레코드는 Delete 및 Insert 방식으로 처리됨Insert나 Delete 문일 때는 인덱스 모두에 변경을 가해 총 인덱스 개수에 따라 성능이 크게 달라짐그래서 대량의 데이터 처리가 발생할 때, 인덱스를 모두 Drop 하거나 Unusable 상태로 변경한 다음 처리하는게 빠를 수 있다.2. Insert 튜닝가. Oracle Insert 튜닝Direct Path InsertIOT(index-organized table) 는 정해진 key ..

인덱스를 이용한 소트 연산 대체가. Sort Order By 대체아래의 쿼리를 읽을 때 [region + custid] 순으로 구성된 인덱스 사용한다면 sort order by 연산을 대체할 수 있다.인덱스 미리 정렬이 되어있기 때문이라 생각하면 된다.물론 소트해야 할 대상 레코드가 무수히 많고 그 중 일부만 읽고 멈출 때 유용하다고 함인덱스를 스캔하면서 결과 집합을 끝까지 Fetch 한다면 오히려 I/O 및 리소스 사용측면서 손해임select custid, name, resno, status, tel1 from customer where region = 'A' order by custid-------------------------------------------------------------..

데이터 모델 측면에서의 검토자주 사용하는 데이터 엑세스 패턴을 고려하지 않고 물리 설계를 진행하거나, M:M 관계를 해소하지 않아 핵심 프로그램이 항상 소트 오퍼레이션을 수행하여 성능이 저하되는 경우 흔히 접할 수 있다.아래의 상황을 보면 PK 없거나, 적거나 아래의 가입상품 테이블 처럼 소수일 때, 테이블 간소화를 위해 고객별상품라인 테이블로 통합하는 상황이 있다.정합성에는 이슈가 없겠지만, 자주 조회가 일어난다면 성능이 좋을리가 없다.select 과금.고객id, 과금.상품id, 과금.과금액, 가입상품.가입일시 from 과금, ( select 고객id, 상품id, min(가입일시) 가입일시 from 고객별상품라인 group by 고객id, 상품id) 가입상품 where 과금..

1. 소트와 성능가. 메모리 소트와 디스크 소트SQL 수행 도중 Sort 연산은 메모리 공간에 Sort Area에 할당하고 정렬을 수행한다. Oracle에서는 PGA(Program Global Area) 영역에 할당한다.그러나 많은 데이터를 사용할 때는 오버 플로우로 인해 디스크 공간을 사용해야 한다.메모리 (In-Memory) 소트전체 데이터의 정렬 작업을 할당받은 소트 영역 내에서 완료하는 것을 말하며, Internal Sort 또는 Optimal Sort 라고도 한다.디스크(To-Disk) 소트할당 받는 소트 영역 내에서 정렬을 완료하지 못해 디스크 공간까지 사용하는 경우를 말하여 External Sort라 한다.나. 소트를 발생시키는 오퍼레이션Sort Aggregate전체 로우 대상 집계를 수행할..

6. 불필요한 조인 제거1:M 관계인 두 테이블을 조인하는 쿼리문에서 조인문을 제외한 어디에서도 1쪽 테이블 참조하지 않는다면 쿼리 수행시 1쪽 테이블 읽지 않고 M쪽 테이블만 읽도록 쿼리를 변환한다. 이를 조인 제거 또는 테이블 제거라고 한다.아래의 쿼리 및 실행계획 예시를 보면 된다.select e.empno, e.ename, e.deptno, e.sal, e.hiredate from dept d, emp e where d.deptno = e.deptnoRows Row Source Operation ---- --------------------------------------------------- 14 TABLE ACCESS FULL EMP (cr=8 pr=0 pw=0 time=58 us)조인 ..