분류 전체보기
-
오픈소스에 커스텀 코드가 들어갈 때 어떻게 관리해야할까?오픈소스 프로젝트 2024. 1. 18. 20:04
소개 업무 중 오픈 소스를 사용 중인데 회사 제품에 맞게 커스텀 구현한 코드들이 들어가있다. 이번 버전 출시가 오래 걸려서 오픈 소스 버전을 업데이트 하지 못해 1년 정도 지났다. 그러다보니 Upstream Repo(Conductor OSS Repository)의 많은 변경이 일어났다. 변경을 반영하려다 보니 Merge Confilct 및 파일이 1200개 가량 변경되는 일이 발생했다. 그래서 기존 OSS Repository main branch와 우리가 사용하는 커스텀 코드가 포함되어져있는 Repo의 동기화는 어떻게 하면 좋을지 고민했다. 그러던 와중 시니어 한 분이 OSS 관리하는 방법을 제안해주셔서 방법을 정리 및 공유해보려한다. 과정 아래의 그림은 전체적인 과정이다. 1. 3.13.3 버전의 OS..
-
Spark + Iceberg - 3(Hidden Partitioning)Data Engineering 2024. 1. 17. 20:25
소개 아이스버그의 히든 파티셔닝 기능을 알아보자. 기존 하이브 테이블 파티셔닝은 쿼리 속도를 향상시키기 위해서 파티셔닝을 사용한다. 아래 예시처럼 "event_date" 컬럼이 하나가 추가된다. Insert할 때도 변환이 필요해 불필요한 작업이 늘어난다. INSERT INTO logs PARTITION (event_date) SELECT level, message, event_time, format_time(event_time, 'YYYY-MM-dd') FROM unstructured_log_source 그리고 아래 예시처럼 마지막 event_date를 적어야만 Full Scan을 하지않고 데이터를 가져온다. SELECT level, count(1) as count FROM logs WHERE event..
-
Spark + Iceberg - 2(Partition, Schema evolution)Data Engineering 2024. 1. 16. 22:27
소개 아이스버그 기능 Partition,Schema Evolution에 대해서 살펴보자. 기존 하이브 테이블은 파티셔닝을 변경할 수 없다. 그래서 일별 단위에서 시간별 단위로 변경하려면 새로운 테이블을 만들어야한다. 쿼리도 재작성해야하므로 불편함이 존재한다. 이것을 해결하기 위해서 아이스버그는 Partitioning Evolution을 제공한다. 그리고 Schema에 대한 Evolution을 관리할 수 있다. 아래 예시는 Schema Evolution이 적용되는 예시이다. 1. 테이블에 새로운 컬럼을 추가하는 경우 2. 테이블에 존재하는 컬럼을 삭제하는 경우 3. 컬럼명을 새로 변경했을 경우 4. 컬럼 타입을 변경했을 경우 5. 테이블 컬럼 순서를 변경했을 경우 위 변경들은 메타 데이터 변경이므로 데이터..
-
Spark + Iceberg - 1(소개 및 연동)Data Engineering 2024. 1. 16. 20:25
소개 일반적으로 데이터 플랫폼에서는 HDFS, S3(데이터 저장) + Hive Metastore(메타데이터 저장) + Spark, Trino, Hive(쿼리 엔진) 조합하여 사용한다. 그러나 문제점이 있다. 여러 사용자가 HMS를 공유하기 때문에 OOM이 발생할 확률이 크다. 그래서 이것을 분리하기 위해서 Iceberg를 사용한다. 예를 들어서 사용자1이 TABLE_A에 접근하려고하고 사용자2가 TABLE_B에 접근하려고 하면 하나의 인스턴스를 공유하고 있는 예전과 달리 Iceberg는 각 Table마다 File로 저장하여 관리하기 때문에 서로 영향이 가지않는다. 또한 Hive에 대한 의존성이 없어진다. S3 + Spark만 있으면 실행이 가능하다는 장점이 있다. 결국 트랜잭션을 가진 Datalakeho..