은유 개발 블로그

나는 왜 책을 읽는가? 그리고 어떻게 읽어야하는가

은유 — Sat, 6 Jun 2026 17:53:20 +0900

"왜 읽는가"라는 질문이 생긴 순간
책은 정제된 정보다 — 인터넷과 책의 결정적 차이
책은 뇌를 능동적으로 훈련시킨다 — 신경과학이 말하는 독서의 효과
책은 다른 삶을 간접 경험하게 한다 — 문학이 주는 것
고전은 변하지 않는 정수다 — AI 시대에도 대체되지 않는 것
책은 나만의 언어와 주관을 만들어준다 — 표현력과 사유의 연결
어떻게 읽는가가 결과를 바꾼다 — 능동적 독서의 가치
소유가 아닌 사유를 위해

"왜 읽는가"라는 질문이 생긴 순간

언제부터인가 유튜브에 책을 요약해주는 채널들이 넘쳐나기 시작했다. 15분짜리 영상 하나로 300페이지 분량의 책을 끝낼 수 있다고 한다. 심지어 방송에서도 그런 수요를 포착했는지, 고전 문학과 인문학 책을 요약하고 해설해주는 교양 예능 프로그램까지 생겨났다.

이게 단순한 취향의 변화일까. 경향신문 보도에 따르면 한국 성인 독서율은 1994년 86.8%에서 2021년 40.7%로 절반 이하로 떨어졌다. 더 눈에 띄는 건 그다음이다. 20대의 13.5%, 10대의 19.6%가 유튜브나 영상 콘텐츠를 독서의 한 형태로 인식한다고 답했다. 책을 읽지 않는 게 아니라, 영상을 보는 것으로 읽었다고 여기는 것이다. 그 사실이 묘하게 마음에 걸렸다. 틀렸다고 단정 짓기는 어렵지만, 무언가 중요한 것이 조용히 사라지고 있다는 느낌을 지울 수가 없었다.

그런 콘텐츠를 보다가 문득 이런 생각이 들었다. 나는 왜 직접 책을 읽는 걸까. 요약본으로도 내용은 알 수 있는데. 줄거리를 아는 것과 책을 읽는 것은 같은 일인가.

그 질문이 생긴 순간, 나는 내가 책을 읽는 이유를 처음으로 진지하게 생각해봤다.

1. 책은 정제된 정보다

인터넷에는 정보가 넘친다. 검색 하나로 수천 개의 글이 쏟아진다. 그런데 이상하게 읽고 나면 머릿속에 남는 게 없다. 정보의 양과 이해의 깊이가 비례하지 않는다는 느낌.

https://www.youtube.com/watch?v=ehIdjNaJyIw

이유가 있다. 이동진 평론가는 인터넷의 정보는 아직 도정되지 않은 쌀과 같고, 책은 밥상에 올라온 쌀밥과 같다고 말한다. 책은 편집자와 저자를 거쳐 오랜 시간 걸러진 정보다. 독자가 직접 진위를 가릴 필요 없이, 이미 어느 정도의 신뢰가 보장된 형태로 도착한다. 인터넷 정보가 90%의 사실과 10%의 오류를 무작위로 섞어 제공한다면, 책은 그 비율이 훨씬 뒤집혀 있다.

요약 콘텐츠는 어떨까. 내용은 전달된다. 그러나 줄거리는 전체를 설명하지 않는다. 저자가 하나의 문장을 고르고, 다음 문장으로 이어지는 맥락, 그 사이에 쌓인 밀도 — 그런 것들은 요약본에 남지 않는다. 결국 요약본으로 책을 '소비'할 수는 있어도, 책을 '경험'하기는 어렵다.

2. 책은 뇌를 능동적으로 훈련시킨다

읽는다는 것은 생각보다 훨씬 능동적인 행위다.

글을 읽을 때 우리는 눈으로 텍스트를 쫓고, 의미를 추론하고, 앞뒤 문맥을 연결하며 스스로 결론을 끌어내야 한다. 영상은 속도와 방향을 제공자가 결정하지만, 책은 독자가 직접 페이스를 정하고 멈추고 되돌아가며 읽는다. 그 과정 자체가 사고력 훈련이다.

뇌과학적으로도 흥미롭다. 독서 중에는 시각 피질, 언어 영역(베르니케·브로카), 그리고 계획·판단·충동 조절에 관여하는 전두엽이 동시에 활성화된다.[1] 특히 전두엽의 전전두피질은 주변의 불필요한 자극을 억제하는 역할을 하는데, 독서가 이 부위를 반복적으로 훈련시킨다. 단순히 내용을 이해하는 것을 넘어, 읽는 행위 자체가 뇌 구조를 바꾼다.

더 나아가, 어떤 책을 읽느냐도 중요하다. 셰익스피어의 은유적 표현을 읽는 동안 뇌를 관찰해보면, 전두엽이 유독 활발하게 활성화된다.[2] 이유가 있다. 은유란 서로 다른 영역에 있는 것들을 이어붙이는 작업이다. 멀리 떨어진 개념들을 연결할수록 뇌는 더 광범위하게 작동한다. 답을 빨리 주는 책보다 은유가 가득한 책이 뇌에 더 자극이 되는 이유다. 사전은 은유가 0%인 책이라는 말이 있는 것처럼, 문학을 읽는다는 건 정보를 얻는 것을 넘어 뇌 전체를 가동시키는 일이다.

한 가지 더 주목할 부분이 있다. 스마트폰과 소셜미디어는 빠르고 즉각적인 도파민 보상을 제공한다. 스크롤 한 번에 웃음이 나오고, 알림 하나에 기분이 올라간다. 그러나 성숙함이란 지연 보상 — 느리게 오는 보상을 견디는 능력 — 을 기르는 것이다. 책은 그 훈련에 가장 적합한 도구다. 당장 결론이 나오지 않아도 천천히 읽어가며 마지막 페이지에서 무언가를 얻는 경험. 그 과정에서 뇌는 침착함을 관장하는 세로토닌과 이성적 사고를 돕는 아세틸콜린이 활성화된다.[3] 흥분하지 않고 차분하게 텍스트를 따라가는 것 자체가 감정과 충동을 조절하는 훈련인 셈이다.

스마트폰이 주의를 끊임없이 분산시키는 시대에, 책은 긴 호흡의 집중을 가능하게 하는 거의 유일한 도구다. 나는 한동안 책을 멀리하면서 점점 한 가지 일에 오래 집중하기 어려워지는 자신을 발견했다. 책으로 돌아오면서 그 감각이 천천히 회복되는 걸 느꼈다. 이건 이론이 아니라 경험이다.

3. 책은 다른 삶을 간접 경험하게 한다

나는 지금까지 한 번의 삶밖에 살지 못했다. 당연한 말이지만, 이 말이 실감 나는 순간이 있다. 내가 경험해보지 못한 감정, 내가 한번도 처해본 적 없는 상황 앞에 설 때다.

책 — 특히 문학 — 은 그 간극을 메워준다. 뇌는 간접 경험과 직접 경험을 신경학적으로 거의 구분하지 못한다.[4] 소설 속 인물의 상실을 따라가면서 실제로 상실을 경험한 사람의 감각 회로가 활성화된다. 그렇게 독서는 경험의 총량을 늘려준다.

더 실용적으로 말하면, 다양한 삶을 읽다 보면 세상을 이해하는 틀이 풍부해진다. 같은 사건도 어떤 틀로 보느냐에 따라 전혀 다르게 해석된다. 책을 많이 읽은 사람은 그 틀이 많다. 하나의 현상을 여러 각도에서 볼 수 있는 능력이 생긴다.

5. 고전은 변하지 않는 정수다

AI 시대가 되면서 정보를 얻는 방법이 달라졌다. 기술 서적이나 실무 관련 책을 사던 습관이 어느 순간 사라졌다. 필요한 정보는 검색과 AI로 더 빠르고 정확하게 얻을 수 있으니까. 그 변화는 자연스러웠고, 솔직히 크게 아쉽지 않았다.
카프카나 리액트, 플러터 등 이 기술은 10년뒤에도,20년뒤에도 꾸준히 사용될까? 그렇지 않다. 지금만해도 업데이트되고있고 명맥은 유지되고있지만 앵귤러나 뷰는 사용자수도 이전에 비해서 리액트에 비해서 떨어지고 배우려는 사람도 줄어들고있다. 기술은 시대의 맥락과 환경에 의해서 바뀌고 재정의된다.

그런데 고전은 달랐다. 아무리 기술이 발전해도, 고전이 주는 것은 쉽게 대체되지 않는다. 고전은 시대의 에센스다. 산업혁명이 일어나고, 전쟁이 나고, 인터넷이 세상을 바꿨어도 고전은 내내 읽혀왔다. 수백 년을 살아남은 텍스트에는 단순한 정보가 아니라, 시간의 검증을 통과한 인간의 본질적인 물음들이 담겨 있다.

이탈로 칼비노는 말했다. "고전이란 결코 다 말하기를 끝내지 않는 책이다."[5] 스무 살에 읽은 고전과 서른 살에 읽는 고전은 같은 텍스트지만 다른 책처럼 느껴진다. 책은 가만히 있는데, 읽는 사람이 달라져 있기 때문이다. 고전은 정보를 전달하는 책이 아니라, 지금의 나를 비추는 거울에 가깝다. 그리고 다양한 시대와 독자들이 겹겹이 쌓아올린 해석의 층위가, 내가 미처 보지 못한 각도를 보여준다.

나는 마음이 어수선할 때 고전을 찾는다. 빠르게 변하는 세상에서 변하지 않는 무언가를 손에 쥐는 느낌. 그 안정감은 정보에서 오는 게 아니라, 오래된 것과 나 사이의 조용한 대화에서 온다.

6. 책은 나만의 언어와 주관을 만들어준다

작가는 말을 수집하는 사람이다. 예를 들면 미용실에 가면 미용실의 언어를 다 수집한다. 머리 자를 때 쓰는 보자기, 그걸 커트보라고 한다. 재미있는 말이 나오면 작가들은 바로 수집한다.

알쓸신잡 프로그램에 나온 소설가 김영하는 작가는 언어를 수집하는 사람이라고 말했다. 길을 걷다가, 대화를 나누다가, 어떤 특별한 표현을 발견하면 마음속에 담아두는 사람. 그렇게 모인 언어들이 쌓여 그 사람만의 문체가 된다.

독자도 마찬가지다. 좋은 책을 읽다 보면 자신도 모르게 좋은 문장을 흡수하게 된다. 문해력은 읽는 것으로 키워지고, 읽기가 쌓이면 쓰기도 달라진다.[6] 내가 쓸 수 있는 말의 범위가 넓어지고, 내가 표현할 수 있는 감정의 결이 세밀해진다.

더 실용적인 차원도 있다. 세상은 여전히 글로 평가받는다. 논문, 계약서, 기획안, 보고서 — 중요한 것들은 대부분 글의 형태로 존재한다. 한글로 쓰여 있다고 해서 누구나 다 이해하는 게 아니다. 수능 국어가 사실상 언어 처리 속도의 시험이듯, 빠르고 정확하게 글을 이해하는 능력 그 자체가 문해력이다.[7] 독서는 그 능력을 기르는 가장 직접적인 훈련이다.

나는 글을 쓰고 싶다는 욕구가 있다. 인정받고 싶은 마음도 있고, 경험을 기록해두고 싶은 마음도 있다. 그런데 막상 쓰려고 하면 종종 막힌다. 내가 느끼는 것을 정확하게 표현할 단어가 없거나, 문장의 구조가 어색하거나. 그 갈증을 채워주는 것이 결국 독서다. 책을 읽는다는 건, 쓰기 위한 준비이기도 하다.

한 걸음 더 나아가, 나는 요즘 책을 다 읽고 나면 짧게라도 독후감을 쓰려고 한다. 독후감을 쓰는 건 확증 편향과 에코체임버에서 벗어나기 위해서다. 책에 공감했다면, 왜 공감했는지. 동의하지 않았다면, 어디서 생각이 갈렸는지. 그 과정을 글로 남기면서 저자의 시선을 그냥 받아들이지 않고 나의 주관으로 걸러내게 된다. 읽는다는 것은 받아들이는 것만이 아니라, 대화하는 것이기도 하다.

7. 어떻게 읽는가가 결과를 바꾼다

같은 책을 읽어도 어떻게 읽느냐에 따라 남는 것이 다르다.

연필이나 형광펜을 들고 읽는 습관은 단순한 취미가 아니다. 손글씨를 쓰는 것이 기억력에 도움이 된다는 사실은 노르웨이 연구진들이 밝혀낸 바 있다.[8] 밑줄을 그으며 읽는다는 건 그 문장을 한번 더 처리한다는 뜻이다. 읽고 지나치는 것과, 멈추고 표시하는 것 사이에는 생각보다 큰 차이가 있다.

나는 책갈피를 사용하지 않는다. 다음번에 이어서 읽을 때, 지난번 읽었던 부분을 되짚으며 다시 시작한다. 몇 줄 되돌아가는 사이 흐름이 돌아오고, 어제의 독서와 오늘의 독서가 자연스럽게 연결된다. 빠르게 진도를 나가는 것보다, 느리게 몸에 새기는 편이 훨씬 남는 게 많다.

독서를 통해 집중력이 달라진다는 사실을 나는 직접 경험했다. 어렸을 때는 1분도 채 지나지 않아 다른 생각에 빠져들기 일쑤였다. 그것이 책을 꾸준히 읽으면서 서서히 바뀌었다. 이제는 집중하려고 마음먹으면 집중할 수 있게 됐다. 책이 나를 훈련시킨 것이다.

소유가 아닌 사유를 위해

다시 처음 질문으로 돌아온다. 왜 직접 읽는가.

지식을 소유하고 전달하는 시대는 끝나가고 있다. AI는 방대한 데이터를 학습하고 전달하는 일에서 이미 인간을 훨씬 앞섰다. 그런데 흥미로운 건, AI 분야 스스로가 '학습'만으로는 부족하다는 걸 증명해왔다는 점이다. 더 많은 데이터를 학습시키는 것만으로는 한계가 있었고, 그 결과 AI 인프라의 무게중심이 학습에 최적화된 GPU에서 추론에 특화된 TPU와 LPU로 이동하고 있다. 기술 자체가 이미 방향을 가리키고 있다. 더 많이 아는 것보다, 아는 것을 어떻게 연결하고 예측하느냐가 중요해지는 시대라는 방향으로.

그렇다면 책을 읽는다는 것은 무엇인가. 나는 처음에 책이 지식을 쌓는 도구라고 생각했지만, 지금은 다르게 본다. 책은 추론을 훈련하는 도구다. 저자의 논리를 따라가며 나의 생각과 맞대어보고, 낯선 삶의 맥락에서 패턴을 읽어내고, 서로 다른 영역의 개념을 연결하는 것 — 그 모든 행위가 추론과 예측, 연결의 반복이다. 그 과정에서 쌓이는 것이 있다. 감각이라고 불러도 좋고, 직관이라고 불러도 좋다. 책이 길러주는 그 감각이, 내가 가진 지식을 실제로 써먹을 수 있게 만든다.

물론 추론도 곧 AI가 더 잘 해낼지 모른다. 그래도 독서를 멈추지 않을 이유가 있다. 지식을 소유하기 위해 읽는 게 아니라, 사유하기 위해 읽는 것이니까. 소유는 대체될 수 있지만, 사유는 그 자체로 삶의 방식이다.

나는 더 잘 생각하고 싶다. 더 풍부하게 느끼고 싶다. 더 정확하게 표현하고 싶다. 그 세 가지 욕망이 나를 책으로 이끈다.

책은 느리다. 하지만 그 느림이 핵심이다.

Summary

지식을 소유하는 시대에서 추론하는 시대로 — 책은 그 추론 감각을 기른다
독서의 이유: 정제된 정보 / 뇌 훈련 / 지연 보상 / 간접 경험 / 고전의 정수 / 언어·주관 축적
어떻게 읽느냐도 중요하다: 능동적 독서(밑줄, 메모, 독후감)가 결과를 바꾼다
결국 더 잘 생각하고, 느끼고, 표현하기 위해 읽는다

YTN 사이언스 투데이, 〈독서로 뇌를 춤추게 하라!〉, https://youtu.be/XEFSi-DszSE?t=265 ↩︎
인지심리학 교수 김경일, 〈책 읽어드립니다 — 햄릿편〉↩︎
가바사와 시온, 《당신의 뇌는 최적화를 원한다》↩︎
〈성인 53%가 1년에 책 한 권도 안 읽는 시대, 여전히 우리가 '책'을 읽어야 하는 이유〉, https://www.youtube.com/watch?v=ehIdjNaJyIw ↩︎
이탈로 칼비노, 《왜 고전을 읽는가》(Perché leggere i classici, 1991)↩︎
신종호 교수(서울대 교육심리학), 〈서울대 교수님이 알려주는 서울대 공부법〉, https://www.youtube.com/watch?v=LGvAjqNKnhc ↩︎
슈카, 〈슈카쌤 리즈 시절 시험비법〉, https://www.youtube.com/watch?v=9k8VcV88Le0 ↩︎
조병영 교수(국어교육과), 〈문해력을 키우는 방법〉, https://youtu.be/3AYOEguUb9Y?t=986 ↩︎

[SLASH 24]전천후 데이터 분석을 위한 DW 설계 및 운영하기

은유 — Sun, 12 Oct 2025 23:59:46 +0900

고민의 시작

의사 결정자가 체결된 월간 주문건수를 면밀히 사렾봐야할때나, 주문테이블, 체결 테이블, 데이터 필터링 등 복잡
분석을 진행하기 전에 데이터를 찾고 전처리하는 시간을 줄일 수 없을까?→ 위 과정을 미리 해둔 데이터가 있다면 좋지 않을까?

토스 증권에서 운영중인 Active User 테이블

특정 지표를 설정하고(act_type 이라는 명칭으로) 다양한 관점에서 측정한 테이블을 만들어내는 파이프라인을 만들어서 사용

위와같은 형식으로 100개가 넘는 act_type이 정의되어있음

au_list라는 곳에 로그들을 다 밀어넣고 au_list는 daily로 존재하니 그거를 다시 montly, weekly, au_last(최종적으로 액티베이션 된 레코드 테이블), au_first(최초 인입된 레코드)로 구분하여 다시 적재
s_au는 토스증권의 특이한 케이스라고 보면되는데 매일매일 혹은 최근 7~30일간 액티베이션 된 유니크 유저수를 집계한 테이블
이렇게 만들어놓으면 액트타입만 정의를 해놓으면 월간 주간 일간으로 무언가 데이터 처리를 쉽게 할 수 있다는 장점이 있음

AU테이블의 풀고자 했던 문제점

테이블과 컬럼 네이밍 컨벤션이 없어서 테이블이 일관되게 보이지 않는 문제

→ 여러가지 주제를 한통에 담았을때 마트성이다는 의미에 m_ 접두사를 사용함 f, d, m이라는 접두사를 통해서 네이밍 컨벤션 규칙을 만듬(f,d는 팩트앤 디멘션 모델을 차용해서 팩트 테이블, 디멘션 테이블을 의미)

접두사 다음으로는 액트 타입을 한통에 넣은 것이기 때문에 액트타임 모음이라는 명칭을 붙임
세번째 ukey는 어떤 컬럼값 기준으로 aggregation되는지를 표시
마지막 영역은 어떤 기한 텀으로 되어있는지 서픽스로 붙게됨

act_type별로 집계해야 하는 지표를 담아내지 못하고 모든 act_type에 적용되는 일반적인 공통의 지표만 담고있는 문제

각 act_type별 최초 activation된 기록이 실버 레이어로만 존재하고 사라짐→ au_list테이블에는 공통 지표값만 저장되어 확장성이 떨어짐

변경 이후 실버 테이블을 다 버리지않고 액트타입별로 각각의 완성된 마트테이블로 구축하고 특수하게 집계해야하는 컬럼들을 반영함

복귀, 기존유저를 집계할 수 있는 정보가 없는 문제

테이블을 애드훅하게 그때마다 생성해야했고 관리의 어려움이 커짐

유저별 activation된 기점으로 여러가지 분석 measure를 담을 dimension 정보를 추가로 생성

신규여부, 복귀여부 등을 쉽게 구할 수 있음

변경된 파이프라인 DAG

추가로 고려했던 사항

테이블 생성 로직 코드의 재활용성 높이기

f_02_daily_table.py파일 하나로 최대한 모든 경우를 처리할 수 있도록함
파일 5가지로 모든 act_type을 커버할 수 있도록함

작업 병렬도를 높이기

테이블이 많아지면 read time이 높아져서 act_type별 spark session 설정 최적화와 불필요한 step을 줄이며 작업 병렬도를 높이는데 집중함
airflow에 priority_weight라는 기능이 있는데 이걸 사용해서 오래걸리는 task들을 먼저 돌리도록 함
pyspark의 executor, memory size, suffle_partitions를 커스텀하게 셋팅

실버 stock_visti 테이블 하나로 골드테이블 3개를 만들 수 있음

backfill을 쉽게 할 수 있는 dag 구성

로그데이터의 특성상 프론트에서 코드 변경시 하루 이틀정도 백필해야할 경우가 생기는데 백필 dag를 잘 구성해두지 않으면 그때마다 힘든 과정이 됨
airflow variable을 사용해서 돌리고싶거나 제외하고자하는 act_type을 json형태로 입력해서 백필

특정 테이블만 돌려야하는 경우, 테이블 스펙을 적으면 해당 테이블만 백필이 되도록 구성

많은 기간을 선택해서 백필을 하면 메모리가 넘쳐서 터질 수 있으니 기간을 잘라서 보낼 수 있도록 구성
예를들어 split_date_unit에 30을 입력하면 30일만큼 task를 잘라서 생성함

최종적인 AU 테이블 사용법

이전에는 m로그 테이블을 뒤져가면서 봐야했지만 dw설계 이후에는 단순 select 쿼리로 가능
기존에는 많은 join과 계산 쿼리가 들어갔어야하지만 이후에는 간단한 sql코드로도 가능

앞으로 남은 과제

신규 act_type을 쉽게 추가할 수 있는 admin 화면 구축하기→ 현재 완료
AU 테이블을 가지고 SQL LLM bot 생성하기

늦은 GCP AI Agents Live + Labs Seoul 후기

은유 — Sun, 28 Sep 2025 17:14:57 +0900

아침일찍부터 등록대기하려고 줄서있는 모습

7월 8일 8시30분부터 코엑스 컨벤션센터에서 AI Agents를 주제로 구글클라우드에서 컨퍼런스를 진행했다. 사람들이 엄청 줄서있는데 접수 데스크가 여러개고 확인히 상당히 빠르게 진행되어서 줄선거에 비해서 비교적 수월하게 입장 티켓과 중요한 점심식사 쿠폰 목걸이를 받을 수 있었다.

7월달에 한 컨퍼런스를 왜 이제 올리느냐고한다면...그간 바빴다는 핑계밖에 댈 일이 없지만, 반대로 왜 7월달에 열린 이벤트를 이제서라도 올리려고 한다면 할말이 많다. 기대감을 가지고 참석한 만큼 실망감도 그만큼 컸기 때문인데 할말들을 머리속으로 생각하고 정리하다가 개인적인 일정들과 얽혀 늦어졌다고...밖에 일단은 더이상 할말이 없다.

실망감에 대한 내용은 나중에 후술하도록할텐데 일단 시작은 좋았다.

012

첫 오프닝은 흔히 과학 커뮤니케이터로 알려진 바 있는 궤도와 구글클라우드 대표, AMD 대표, 구글 클라우드 엔지니어디렉터 맷 톰슨이 나와서 개막을 알렸다.

구글클라우드는 삼성이랑 협헙해서 AI 로봇도 만들고있다는 소식과 AMD 대표는 GPU만큼 CPU도 중요하다면서 EPYC이라는 데이터센터 전용 cpu를 내놓았고 모멘텀이 좋다는 소식도 전달했다.

구글클라우드 엔지니어디렉터 맷 톰슨은 재미나이 CLI를 통해서 커맨드라인으로 코드를 빠르고 품질 좋게 만들고 구글에서 4분에 1은 이미 ai로 작성되고 있다고 빠르게 변화하는 코딩문화를 연설했다.

오프닝과 밥까지 완벽했다. 아마 추측컨대 코엑스가 그랜드 인터컨티넨탈 호텔과 이어져있다보니까 호텔에서 주문한 호텔식 도시락으로 배달이 온게 아닌가 싶다. 왜냐하면 거기에 나와있던 직원들이 호텔직원처럼 보였기 때문에...아무튼 맛도 좋았고 배부르게 먹을 수 있었다. 여기까지는 아주 반복했다...여기까지는..

이후 오후부터는 목걸이에 적힌 트렉4인 데이터 프로페셔널 핸즈온이 예정되어있었다. 사전에 미리 신청을 받은 사람에 한해서 핸즈온 세션을 들을 수 있었기 때문인데, 위와같은 순서로 구글클라우드에 관련된 데이터 분석에 대한 핸즈온 강의를 들었다.

사실 광고반 자랑반이었던 오프닝과 여러 세션들, 그리고 참가부스들을 참고 볼 수 있었던건 오늘의 이 핸즈온 세션을 위해서였는데 결론적으로 말하면 나는 이 핸즈온 세션을 전혀듣지못했다.

사전에 신청을 했음에도 불구하고 그리고 무려 20분전에 세션을 하는 홀앞에 기다렸었는데 그때부터 이미 마감이라는 말을 전해들을 수 밖에 없었다. 그 주변에 나와같은 다른 일행들도 많이 볼 수 있었는데 다들 항의를 하거나 하는수없이 발걸음을 옮기며 되돌아갈 수밖에 없었다.

설명으로는 제한된 좌석때문에 선착순으로 입장이 가능하다고한다. 하지만 나말고도 꽤 많은 인원이 핸즈온을 듣지못하고 돌아간 것 같은데, 비참석자를 감안해서 사전 예약을 받았다고 하더라도 미리 사전에 홀의 인원수를 체크해서 과도한 오버부킹을 받지 않도록 해야하지 않나하는 아쉬움이 남는다.

심지어 이 핸즈온을 위해서 오기전에 가이드 링크를 통해서 핸즈온 랩에 가입도 하고 사전준비도 열심히 마쳤는데...그런 수고가 무색해지는 순간이 아닐 수 없었다. 그래서 돌아오는 길에 꼭 이거에 관련된 글을 블로그에 남겨야겠다고 다짐했다.

그래서 사실 이걸 위해서, 그리고 이 핸즈온 내용을 남기려고 블로그 글을 쓰려고 계획했지만 사실 알맹이는 없는 글이 되었기는 하지만 그래도 이왕 힘내서 서울까지 찾아간거 다른거라도 열심히 보고 듣고 즐기자는 심정으로 볼만한 세션과 부스들을 찾아보고 돌아다니기 시작했다.

데이터독 부스에가서 설명을 들었는데 AIOps 모니터링을 통해 알람을 받고 그 알람이 어떤 원인 때문에 오게되었는지 심지어 그 이슈에 원인 분석과 해결 코드까지도 받아볼 수 있는 점들을 흥미롭게 봤다.

이후에 AI기반 통합 데이터 분석서비스 전략과 활용 사례 소개 세션이 그대로 현업적인 측면이나 활용성면에서 많이 알아갈 수 있지 않을까하는 기대로 듣기로 결정.

01234567891011

이 세션은 패션업게 CEO가 CVR(구매율)을 5%에서 20프로로 목표를 끌어올리기위한 가상 사례를 제시했다.
피팅서비스 AI 모델을 구상했고 상품 이미지를 착장을 하고 정해진 프롬프트로 VEO를 통해서 빠르게 만들 수 있었다.
기업의 취향 데이터를 취합해서 구매자에 성향에 맞춰서 동영상을 생성해서 자체 학습 모델을 만드는 플랫폼을 만들 수 있었다.
정형과 비정형을 ML과 AI로 분석하고 타겟서비스, 추천서비스들이 최근에는 가능해졌다. 최근에는 생성형 AI가 나와서 설계부터 적용까지 AI네이티브에 초점을 맞추고있다
파이프라인을 구축하고 분석, 쿼리 설계까지 제미나이가 지원한다
AI 플랫폼을 위한 통합 데이터 - 빅쿼리 테이블에 멀티모달 데이터를 저장 가능
AI기반 데이터 분석 ->빅쿼리에서 자연어로 파이프라인 빌드가 가능하다. 날짜포맷이나 다국어 변환같은 것들을 제미나이로 가능하다
- 쿼리 생성 역시 자연어로 가능하다
- 운영 자동화쪽에서 스파크잡도 튜닝해준다
데이터링 에이전트, 세일즈 에이전트, 등 에이전트화해서 에이전트들끼리 통신해서 지속적으로 트레이닝하는 것이 최종적인 목표
삼성전자 글로벌 마케팅실에서 실제 사례 공유
AI를 사용해서 핫휠 디자인을 자동으로 생성 개발 기간을 단축 하루에 30개씩 이미지 생성
마이클스는 아트박스같은 개념의 스토어 genAI 사용해서 개인화 타겟팅, SMS 클릭률 41프로 상승
데이터가 일관성이 없고 수작업에 데이터 관리 의존함→ 빅쿼리와 제미나이를 통해서 end-to-end 분석 프로세스
렉킷은 데톨, 페로드 리카드는 앱솔르트 보드카로 유명한 주류 프랑스 회사→ genAI도입으로 마케팅비 절약 퍼포먼스 상향

사실 그렇게 큰걸 기대한 아니지만 다른 세션들도 그렇지만 거의 제미나이 홍보나 자랑이라고밖에 생각이 들지않았다.

홀밖에 나와있는 AI에이전트 구축하기라는 구미가 당기는 부스도 있었다. 나만 그렇게 느끼는건 아닌지 시간이 어느때건 거의 20분가량은 줄서야할 정도로 줄이 길게 서있었다.

실제로 참여해서 내가 만든 투자용 AI Agent다. 이런 시연이 늘상 그렇듯이 자유도가 그렇게 높지않은편이라서 정해진 포맷이 있고 나는 그걸 선택, 선택해서 마지막 완성품만 관람하는 식이다. 그냥 한가지 인상깊었던건 완성된 에이전트가 코드로도 확인할 수 있다는 점이었고 나머지는 그렇게 큰 감흥은 없었다.

결국 그냥 핸즈온에 참석하지 못한 분한 마음을 풀고자 AI Playground라고 여러 기업들이 참석해서 개인정보와 사은품을 트레이드하는(?) 곳에 가서 내 개인정보를 주고 여러 사은품들을 받아서 쓰린 마음을 달래고 집으로 돌아왔다.

2025 KafkaKRU(카프카 한국 사용자 모임) 2회 밋업 참석 후기

은유 — Thu, 11 Sep 2025 00:44:13 +0900

지난 9일에 여의도 IFC Three 건물에서카프카 밋업을 진행했다. 내가 들어가있는 카프카 오픈 채팅방에서 관련 공지가 떠서 확인했는데 때마침 내가 관심있어하는 주제인 AutoMQ와 아이스버그에 관련된 세션이 있어서 기대를 가지고 바로 신청했다. 커뮤니티나 채팅방에 제법 회원수가 있었고 35명만 뽑는 자리라서 제법 경쟁이 치열했지만 참가비 5000원을 바로 결제를 하고 다행이 참가 확정 안내 메일을 받아볼 수 있었다. 막상 참석하고보니 자리도 꽤 여유로웠고 참석하지 않은 사람도 있어서 좀더 규모있게 진행되었어도 괜찮겠다는 생각이 들었다.

이건 호스트분께서도 장소가 처음이다보니 미처 예상치 못한 부분이라면서 환영사와 함께 추신을 덫붙였다.

밋업은 협찬 기업인 IBM의 건물에서 진행되었고 건물 화장실을 들르는 길에 인상깊은 IBM 로고를 보았다.

아이비엠 말그대로 눈이랑 벌이랑 M인데, 직관적이면서도 살짝은 아재스럽고 세로로 모아보니 사람 캐릭터 형상같기도하고 재밌어서 사진으로 남겨봤다.

순서는 등록과 함께 명찰과 디너박스를 받고 밥을 먹으면서 대기를 하면 세션과 네트워킹 시간이 진행된다. 하지만 사진에서 세션을 보면 아이스버그를 전혀 확인할 수 없는데, 호스트분의 말로는 갑자기 발표자분이 오늘 몸이 안좋아져서 취소가 되었고 급하게 IBM의 미리 준비된 세션으로 대체되었다는 소식을 전달받았다. 저 두개의 세션때문에 참석했던 터라 큰 낭패가 아닐 수 없으나 그래도 아직 autoMQ 세션은 남았으므로 물이 반이나 남았다는 긍정적인 마인드로 회피기동.

그리고 특히 밥이 맛있었다. 나는 고작 5000원만 냈을 뿐인데 이리 황송히 대접해주시다니. 불고기가 살짝 단것 빼고는 구성과 맛, 흠잡을때 없었다. 안에 물티슈와 구취제거용(?)폴로사탕도 들어있어서 어떤 분이 의뢰를 맡겼는지는 모르겠지만 아주 센스있었다. 세션이 취소된거에 한층 뿔나있던 전부 수그러들었다. 완전 선녀인 이번 밋업!

밥을 맛나게 먹고 첫번째 세션부터 듣기 시작!

kafka 그 이상: Enterprise를 위한 EDA의 완성 - 김민지님

왜 EDA(이벤트 드리븐 아키텍처)?→ 이제는 시대가 많이 바뀌어서 AI까지 등장. 새로운 아키텍처에 맞는 구조에 대해서 생각하다 예전보다 느슨한 결합, 배치보다는 실시간 처리, 실시간 데이터 수집 및 분석 중요도가 많이 올라갔다는 것을 확인
기업들은 여러 이슈들이 존재함 중복없이 잘 재사용할 수 있을지, 포맷이 달라지는 경우
- 하나의 관리 화면에서 토픽 생성 및 배포해서 낭비되는 리소스가 없는지 모니터링 가능
- 이벤트 게이트웨이를 통해서 이벤트 접근 및 유량 관리
- GUI로 드래그 앤 드랍으로 이벤트를 결합하고 내장된 필터와 표현식을 통해 데이터 재처리 가능
플링크 기반에 gui를 통해 데이터 프로세싱 가능
카프카를 이벤트 스트림즈로 랩핑해서 지원함
표준화된 api 형식으로 토픽을 정의가능→ 서로 다른 조직들끼리 이벤트를 쉽게 검색에 도움

개인적으로는 특히 데이터 프로세싱에서 타임윈도우를 설정하는 부분에 UI로 직관적으로 시간을 표시해줘서 설정하는데 도움이 될것같다

더 이상 kafka만 몰아주지 마세요: 로그는 AutoMQ로 흘려 보내기 - 정유진님

LGU+ 컨플루언트 카프카 사용중
cdc를 이용한 트랜잭션 보장
퍼블릭 1.6억건, 프라이빗 0.6억건 메세지 사용중

플루언트d가 수집해서 오픈서치로 수집
로그 위주기때문에 오브젝트 스토리지를 활용해서 비용 효율적인 데이터 보관을 목표 그러기위에 리서치중에 AutoMQ를 발견함

autoMQ
- 카프카api와 완전 호환
- 유연한 스케일인 스케일 아웃 가능
- stateless한 브로커가 특징
- 오브젝트 스토리지에 저장해서 브로커가 재시작 교체되도 데이터 보존
- 오브젝트 스토리지를 사용해서 레이턴시를 생각해야하지만 실시간성보다는 비용 효율에 초점을 맞춤

스트림을 더 똑똑하게: Instana로 가시화한 Kafka 모니터링

비즈니스 속도에 맞춰서 통합적으로 AI기능이 주입되어서 자동화 기술을 처리
옵저버빌리티가 중요→ 외부에서 바라봐도 한눈에 이해할 수 있게 만드는 솔루션
통합 모니터링
과거 데이터로부터 이상 징후를 감지해서 alert 발송

뭔가 카프카나 인스타나가 여러 모니터링을 지원하는 어플리케이션 중에 하나일 뿐이고 그냥 세션이 펑크나서 급조한 느낌으로 제목에 카프카를 끼워넣은 느낌이 있기는 하지만, 아무튼 들으면서 데이터독같은 느낌이구나~생각이 들면서 저번 구글 AI 에이전트에서 데이터독을 소개할때가 생각났다.

이런식으로 AI 기능을 통해서 에러 로깅을 분석하고 해결방안까지 내주는 솔루션을 업데이트했다고 했는데 비슷한 솔루션들끼리 진화도 비슷하게 하고있구나하는 생각이 들었다.

사실 세션 세개중에 두개가 IBM 제품에 대한 내용이라서 돈내고 제품 광고하는거 들으러 온거 아닌가 하는 의구심도 들긴했지만 앞서 언급한대로 밥이 너무 맛있었고, (설문지를 내고)받은 선물도 딱 내가 필요로하던 거라서 나름 간만에 여의도 외출도하고 좋았다. IBM이라는 기업에 대해서는 알고있었지만 컨플루언트나 AWS외에도 IBM에서도 Saas서비스를 하고있었구나하는 몰랐던 것도 알게되었고 여러가지로 손해는 아니었던 것 같다.

다만 예정되어있던 네트워킹시간이 아무래도 강제적이지는 않았다보니까 I성향이 짙은 개발자들이 모여서 그런가 대부분 귀가를 선택했다. 나는 좀더 다른 사람들이 어떻게 카프카를 사용하고 있는지도 들어보고 싶었는데..(물론 아무나 붙잡고 물어볼 용기는 없었음)

그래서 나도 다른 개발자들처럼 귀가를 선택했지만 다음 밋업때는 강제적이라도(물론 바쁜 사람은 예외) 그룹을 지어서 대화를 나누게 만들어주셨으면 좀더 내향적인 개발자들이 네트워킹을 하기 편하지 않았을까하는 생각이 든다.

트리노에 고가용성을 더해줄 Trino Gateway

은유 — Wed, 13 Aug 2025 18:45:27 +0900

개요

트리노 게이트웨이는 로드 벨런서, 프록시 서버, 멀티 클러스터를 위한 다양한 설정이 가능한 라우터 역할을 함
lyft가 개발한 후 오픈소스화한 프로젝트 현재는 Trino 레포지토리 하위에 존재

Pain point

코디네이터의 HA가 불가능하기 때문에 Trino의 코디네이터는 SPOF라서 장애 상황에 취약함(코디네이터 장애시 모든 실행중인 쿼리 중단)
코디네이터의 큐가 한정되어있어서 워커의 자원이 충분하더라도 모든 쿼리의 파싱과 분석, 최적화가 하나의 코디네이터에서 처리되기 때문에 쿼리 수가 증가하면 코디네이터의 CPU/메모리 부하가 급증하여 대기시간이 증가함
업데이트시에 클러스터가 중지됨. 롤링업데이트가 되더라도 기존에 워커에서 작업중인 쿼리가 초기화됨

Advantages

고가용성 확보
특정 워크로드나 특정 쿼리 및 데이터소스를 라우팅해서 용도별, 팀별로 클러스터 구성가능 보안 및 쿼리 안정성 확보
사용자 중단없이 무중단 업그레이드 가능
클러스터 상태 모니터링 가능

Use cases

SKT
- HA(High Availability)의 용도로 사용

오픈소스 Trino를 활용한 전사 데이터 분석 시스템 구축기

Trino를 활용한 전사 데이터 분석 시스템 구축기

techtopic.skplanet.com

Naver
- 하나의 URL로 두개의 클러스터를 접속하며, 무중단 배포를 해야했음
- 한번에 많은 양의 쿼리가 요청이 오면 리소스 기아문제로 퍼포먼스가 안좋아짐 기존에는 클러스터 큐상태를 고려해서 리소스 그룹으로 CPU, 메모리, 동시성에 리미트를 걸어둠
- 이후에 헤더키를 통해서 클러스터에 분배

게이트웨이를 이용해 쿼리 특성별로 클러스터 자동 전환(스케줄 쿼리, 애드훅 쿼리, 숏텀 클러스터) ->라우팅 용도로 사용

Helm 설치

helm install tg --values ./trino-gateway-values.yaml trino/trino-gateway --namespace=presto

Values

백엔드로 사용할 postgresql or mysql 정보 입력(사전에 gateway 또는 임의의 데이터베이스 생성이 선행되어야함)

dataStore:
    # -- The connection details for the backend database for Trino Gateway and Trino query history
    jdbcUrl: jdbc:postgresql://localhost:5432/gateway
    user: user_name
    password: passwoard
    driver: org.postgresql.Driver

동일 환경에서 Trino를 두 개 이상 배포할 때 생기는 JWT 토큰 인증문제 - TroubleShoting

ERROR	http-worker-143	io.trino.server.InternalAuthenticationManager	Internal authentication failed
io.jsonwebtoken.security.SignatureException: JWT signature does not match locally computed signature. JWT validity cannot be asserted and should not be trusted.

환경이 같으면 같은 클러스터로 인식해서 내부 인증 토큰 불일치로 생기는 문제로 두 클러스터가 서로 다른 JWT 토큰을 사용하려고할때 동일한 서명 키를 공유하지 않으면 인증에 실패함

Solution1

  node.properties: |
    node.environment=standby
    node.data-dir=/data/trino

클러스터의 environment의 이름을 서로 다르게 지어줘서 아예 다른 인증키를 사용하도록함

Solution2

# 두 클러스터 모두 동일한 값으로 설정
internal-communication.shared-secret=<your-shared-secret-here>

두 클러스터에 해당 옵션 추가로 인증키 공유하도록 설정

로드밸런싱

select 1;
select 2;
select 3;
select 4;
select 5;
select 6;
select 7;
select 8;
select 9;
select 10;

위 sql문을 차례로 실행시켰을때 각 sql 라인별로 클러스터에 다르게 요청되는 것을 트리노 게이트웨이 히스토리에서 확인할 수 있다.

Routing-rules

airflow나 superset, 앱 서비스 등 다양한 요청에 대해서 원하는 클러스터로 라우팅되도록 설정해줄 수 있음
쿼리의 성격별이나 장애상황에 더이상 특정 클러스터에 큐가 쌓이지 않도록 분배하는 등 다양하게 활용 가능
아래 테스트는 dbeaver에서 들어오는 쿼리를 trino-main 클러스터에만 실행하도록 라우팅룰을 설정하는 예제

configmap

apiVersion: v1
data:
  routing-rules.yaml: |
    name: "dbeaver"
    description: "if query from dbeaver, route to dbeaver group"
    actions:
      - 'result.put("routingGroup", "dbeaver")'
    condition: 'request.getHeader("x-trino-source") contains "DBeaver"'
kind: ConfigMap
metadata:
  name: routing-rules

values

# Routing Rules 활성화
routingRules:
  rulesEngineEnabled: true
  rulesType: FILE
  rulesConfigPath: "/etc/routing-rules/routing-rules.yaml"
  rulesRefreshPeriod: "1m"
  
...

volumes:
  - name: routing-rules
    configMap:
      name: routing-rules
      items:
        - key: routing-rules.yaml
          path: routing-rules.yaml

volumeMounts:
  - name: routing-rules
    mountPath: "/etc/routing-rules/routing-rules.yaml"
    subPath: routing-rules.yaml
    readOnly: true

configmap을 볼륨마운트해서 사용

라우팅룰이 적용된 모습을 게이트웨이 대시보드에서 확인할 수 있다

클러스터의 라우팅 그룹을 변경

Routing rule에 의해 특정 클러스터에만 쿼리가 라우팅된 모습을 확인할 수 있다

ETC

Resource Group

쿼리 리소스 관리 및 제한

# 리소스 그룹 생성
curl -X POST http://localhost:8080/trino/resourcegroup/create \
  -d '{
    "name": "resourcegroup1",
    "softMemoryLimit": "100%",
    "maxQueued": 100,
    "softConcurrencyLimit": 100,
    "hardConcurrencyLimit": 100
  }'

Selector

쿼리를 어떤 리소스 그룹에 할당할지 결정하는 규칙 시스템

# Selector 생성 - airflow 사용자의 INSERT 쿼리를 특정 그룹으로 라우팅
curl -X POST http://localhost:8080/trino/selector/create \
  -d '{
    "priority": 1,
    "userRegex": "airflow_user",
    "sourceRegex": "airflow",
    "queryType": "insert",
    "resourceGroupId": 1
  }'

[트러블슈팅]DuckDB에서 복수의 parquet파일에 접근할때 컬럼을 못찾는 문제

은유 — Sun, 30 Mar 2025 23:55:44 +0900

SELECT
    a, b, c, d, f
FROM
   read_parquet("s3://some-data/schema_name/table_name/base_date=*/*", hive_partitioning=true)
WHERE
    base_date = '2025-03-26'

S3에 있는 하이브 파티셔닝된 폴더에 parquet파일이 저장되어있다고 했었을때, 위와 같은 쿼리로 duckdb sql같은 메소드를 사용할때 아래와 같은 에러가 발생한다.

---------------------------------------------------------------------------
BinderException                           Traceback (most recent call last)
File <timed exec>:1

BinderException: Binder Error: Table "read_parquet" does not have a column named "f"

Candidate bindings: : "d"

LINE 7:     a, b, c, d, f
                        ^

read_parquet함수를 사용할때 "f"라는 컬럼이 없다면서 뜨는 에러인데 여기서 문제는 해당 parquet파일을 열어보면 모든 로우에 f라는 컬럼이 존재한다는 사실이다.

이는 아스테릭을 사용해서 복수의 파일을 읽을때 다른 파일에 해당 스키마가 존재하지 않을 때 발생하는 에러인데, 해결 방법과 함께 원인도 함께 알아보도록 하자.

문제 원인

https://duckdb.org/docs/stable/data/multiple_files/combining_schemas#combining-schemas

Combining Schemas

Examples Read a set of CSV files combining columns by position: SELECT * FROM read_csv('flights*.csv'); Read a set of CSV files combining columns by name: SELECT * FROM read_csv('flights*.csv', union_by_name = true); Combining Schemas When reading from mul

duckdb.org

다중 파일들을 가져올때 duckDB는 정책적으로 이 파일들의 스키마들을 합친다. 이는 각 파일마다 다를 수 있는 고유의 스키마가 존재할 수 있기 때문이다. DuckDB는 다중 파일의 스키마 통합에 두가지 방식을 제공한다.

컬럼 위치 기준 방식
컬럼 이름 기준 방식

DuckDB는 기본적으로 첫번째 파일을 기준으로 스키마를 읽고 컬럼 위치에 따라서 후속파일의 스키마를 통합한다. 1번 방식이 default값이다. 하지만 이 방식은 모든 컬럼이 동일하다는 가정에서 유효한 방식이다.

1번 방식은 다음과 같은 예를 통해서 설명할 수 있다.

flights1.csv

FlightDate|UniqueCarrier|OriginCityName|DestCityName
1988-01-01|AA|New York, NY|Los Angeles, CA
1988-01-02|AA|New York, NY|Los Angeles, CA

flights2.csv

FlightDate|UniqueCarrier|OriginCityName|DestCityName
1988-01-03|AA|New York, NY|Los Angeles, CA

위와 같은 다른 복수의 두개의 파일이 있다고 했을 때 Duckdb는 컬럼의 위치로 통합을 해서 아래와 같은 결과를 구성한다.

FlightDate	UniqueCarrier	OriginCityName	DestCityName
1988-01-01	AA	New York, NY	Los Angeles, CA
1988-01-02	AA	New York, NY	Los Angeles, CA
1988-01-03	AA	New York, NY	Los Angeles, CA

따라서 파일의 스키마가 다를 경우에는 union_by_name 옵션을 사용해서 DuckDB가 대신해서 모든 컬럼 이름을 읽도록 설정할 수 있다.(2번 방식)

2번 방식은 다음과 같은 예를 통해서 설명할 수 있다.

만약 컬럼이 추가되거나 컬럼명이 변경되어서 다른 스키마의 복수의 파일을 읽으려고 할때는 이름으로 통합하는 방식이다. 이 작업은 앞서 설명한 바와 같이 union_by_name이라는 옵션을 통해서 사용할 수 있다.

flights3.csv

FlightDate|OriginCityName|DestCityName
1988-01-01|New York, NY|Los Angeles, CA
1988-01-02|New York, NY|Los Angeles, CA

flights4.csv

FlightDate|UniqueCarrier|OriginCityName|DestCityName
1988-01-03|AA|New York, NY|Los Angeles, CA

이 파일들의 컬럼들을 위치 기준으로 통합하려고 한다면 서로 컬럼의 숫자가 다르기 때문에 오류가 발생한다. union_by_name 옵션을 통해 컬럼을 통합하면 찾지 못한 값은 NULL로 설정되어 올바르게 통합된다.

FlightDate	OriginCityName	DestCityName	UniqueCarrier
1988-01-01	New York, NY	Los Angeles, CA	NULL
1988-01-02	New York, NY	Los Angeles, CA	NULL
1988-01-03	New York, NY	Los Angeles, CA	AA

해결방법1

위에 나온대로 union_by_name 옵션을 통해 이름으로 통합하는 방식으로 변경한다.

SELECT
    a, b, c, d, f
FROM
   read_parquet("s3://some-data/schema_name/table_name/base_date=*/*", hive_partitioning=true, union_by_name = true)
WHERE
    base_date = '2025-03-26'

해결 방법2

SELECT
    a, b, c, d, f
FROM
   read_parquet("s3://some-data/schema_name/table_name/base_date=2025-03-26/*", hive_partitioning=true)
WHERE
    base_date = '2025-03-26'

위와 같이 where절을 통해 명시할 수 있는 부분이라면 최대한 해당 파티션안에 명시해서 접근해서 가져오는게 훨씬 속도도 빠르고 해당 스키마만 가져올 수 있다. 풀스캐닝을 피할 수 있는 편법인 셈이다.

다만 이 방식은 where절에 있는 필터 조건이 파티션 되어있을 경우에 사용할 수 있는 방식이므로 애초에 폴더안에 여러 파일로 구성되어있다면 사용할 수 없다.

따라서 스키마를 검사해서 달라진 파일의 위치를 duckDB가 읽는 것의 뒷부분으로 파일 이름을 바꿔서 위치시켜준다면 1번 방식으로 읽을 때 가장 첫번째 파일을의 스키마의 컬럼 기준으로 읽기 때문에 해당 쿼리가 접근하려는 쿼리의 기준 파일을 맨 위에 위치시켜주도록 하는 것이 가장 최소한으로 수정하고 해당 문제를 피하면서 빠르게 파일을 스캔할 수 있는 방법이다.

%%time
df = duckdb.execute(query2).fetchdf()

# CPU times: user 12.2 s, sys: 3 s, total: 15.2 s
# Wall time: 4min 52s

참고로 해결방법1과 같이 union_by_name 옵션은 모든 파일의 스키마를 읽어야하기 때문에 메모리 소비를 증가시킬 수 있고 속도도 느려진다. 내 기준으로 위의 쿼리는 약 5분정도 걸렸었는데, 해결 방법2를 통해서 문제를 해결하면 해당 파일을 가져오는데 2초가 걸렸다. 무려 150배의 시간 차이가 발생하는 것이다.

이를 감안한다면 특히 파일의 갯수가 많아질수록 메모리의 소비도 많고 시간도 오래걸리는 이름을 통한 통합 방식은 지양해야겠다.

[SLASH24]토스뱅크 오픈소스로 Hadoop 클러스터 구축기 정리

은유 — Sun, 16 Mar 2025 23:10:06 +0900

배경

클러스터를 왜 다시 구축하게 되었는가

토스뱅크의 초창기에는 임팔라와 HUE를 통해서 빅데이터를 다루었음
인증은 엑티브 디렉토리, 인가는 아파치 센트리를 통해서 제공
임팔라가 대화형 쿼리에 장점이 있었지만 모든 문제에 만능은 아니었기에 사용자들이 한계를 느꼈지만 다른 도구들은 보안을 적용하기에 제한이 있었고

그래서 하둡 클러스터 전반적으로 보안을 적용해서 액티브 디렉토리에 케베로스를 추가했고 아파치 레인저를 통해 모든 서비스에 인증 인가가 붙도록 변경함
결론적으로 임팔라 뿐만이 아니라 빅데이터 문제를 풀기위해 알맞은 솔루션을 사용자들이 선택하여 사용할 수 있도록 만들었음

오픈소스만을 사용하여 Hadoop 클러스터 구축하기

이런 새로운 오픈소스 프로젝트를 배포하고 관리하기 위해서 Apache Bigtop, Ansible, Apache Ambari를 사용해서 빌드와 하둡 클러스터에 설치를 하게 됨

빅탑은 하둡 패키지들을 빌드하는데 사용됨 사내 깃 저장소에서 소스를 받아와서 빌드를 하고 사내 레포에 업로드하고 ambari가 설치된 장치들에 패키지를 설치하도록 되어있음
ambari는 마스터 워커 구조로 되어있고 마스터에서 하둡 컴포넌트 설치, 중지 명령을 내리게되면 워커들이 이 명령들을 수행하는 구조로 되어있음
Ansible은 호스트를 프로비저닝하는데 사용됨, 커널 파라미터 튜닝, ssh키 셋팅, 시스템 셋팅 데몬 등
하지만 왜 직접 빌드해서 사용하는가?
- 바이너리 파일을 제공하지 않는 경우도 있음
- 업그레이드를 하긴 어렵고, 패치를 필요한 상황이 있음
- 복잡한 버전 의존성

오픈소스 따라가며 Hadoop 클러스터 유지보수하기

코드만 가져오지 말것→ git 히스토리까지 그대로 가져오기(커밋이 고정된 release tag쪽에서 가져오기)
패치가 있지만 업그레이드하기 어려운 경우→특정 패치 버전의 commit hash를 알아서 - cherry-pick 명령어를 통해서 커밋하고 conflict가 생기면 알맞게 해결한 후 특정버전의 패치만 반영
하둡에 kerberos인증을 적용하고 프로메테우스 매트릭을 수집할때 인증을 빼고 수집할 수 있는 화이트리스트 기능이 있는데 리소스 매니저와 잡히스토리 서버에는 적용이 되지않는 버그가 있었음→ 이 부분을 먼저 사내에서 수정해서 사용하고 있었는데 upstream에도 반영해서 오픈소스 기여로 후반영하게 됨

오픈소스 기여 사례 공유

Cloudera HUE
- 사용자 권한이 아닌 hue 계정의 권한으로 접근하는 문제 발견→ 접속한 사용자의 권한으로 HDFS file browser를 사용할 수 있도록 수정
Apache Hadoop
- NameNode audit 로그가 압축되지 않아 디스크를 너무 많이 차지하게 됨
- log4j rotate 시에 gzip 압축을 사용하도록 개선
- 로그 롤링은 잘되고있었지만 압축이 되도록 수정
Apache Spark
- hadoop auth_to_local이라는 설정이 있음 excutor쪽에서 kerberos의 full principal name이 보존되지 않는 문제가 발생
- https://issues.apache.org/jira/browse/SPARK-44976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759201#comment-17759201

오픈소스에 어떻게 기여하나?
- 프로젝트마다 나름의 규칙이 있고 공식 문서 및 readme.md 등을 참고하여 기여
- 보통은 jira 티켓이나 PR리뷰를 통해 기여함
오픈 소스 기여시 장점은 바로 리뷰→내부 코드에도 production 수준에 맞는 수준으로 반영하는데 도움이 됨(메인테이너나 리뷰어들에게 피드백을 해줌)

클러스터 전환간 알게된 사실

레인저는 중앙에 레인저 어드민이 있어서 운영자가 레인저 정책을 레인저 어드민에 적용하면 각 서비스 플러그인에 이 정책이 옮겨가서 인가가 알맞게 적용되는 방식

임팔라로 예를 들어보면 레인저 임팔라 플러그인에 하둡 sql 정책이 적용되게 되고 HDFS를 읽어들일 때는 레인저 HDFS 플러그인을 통해서 HDFS 정책이 적용되게 됨
레인저의 한계→ 테이블 레벨까지만 되고 컬럼 레벨까지는 제어가 안됨→ 컬럼 레벨까지 제어하고 싶다면 사용자에게 HDFS 권한을 빼서 Spark를 사용하지 못하게 막고 사용하는 쿼리엔진에서 Ranger를 통해 제어하도록함

요약

Bigtop + Ambari + Ansible → Hadoop 클러스터 구축 및 운영
오픈소스 코드까지 따라가기
오픈소스는 꽁짜가 아니다→ 기술을 follow해야하는 인원들이 필요함
오픈소스로 주도적인 클러스터 운영

느낀점

하둡 에코스스템 내에서 어떻게 인증과 인가를 관리하는지에 대해서 알게되어서 보안이 가장 중요한 금융 도메인에서는 각 사용자들이 데이터를 접근할 때 그리고 데이터를 다룰 때 어떻게 구성해야하는가에 대해서 알게되었다.
오픈소스를 사용하는 측면에 대해서는 나름 많은 오픈소스 프로젝트를 구축하고 사용해보면서 체감은 했지만 기여에 대해서 생각해본 적은 거의 없었는데, 최근들어 여러 영상이나 커뮤니티에서 오픈소스 프로젝트에 대한 이야기를 들을 일이 많아졌다. 아래 첨부한 유튜브 영상도 그 내용중에 하나고. 내용은 오픈소스 컨트리뷰터로 활동하면서 개발자로서 성장과 동시에 커리어로도 함께 성장이 이루어졌다는 내용인데. 실제로 내가 직접 사용하는 프로젝트에 기여하고 내가 기여한 프로젝트가 실제로 많은 사람들이 사용하고 교류가 이루어진다면 그것이 커리어와 실력의 향상을 떠나서 뿌듯한 일이 될 것이라는 생각이 든다.

https://youtu.be/QbDpdjSWnmI?si=H3KgsL8CdhL1_DW6

올해 아주 작은 기여부터 하나씩 시작하는 것을 목표로 이전과 다른 시선으로 오픈소스 프로젝트를 바라보며 내가 기여할 수 있는 방향을 모색해야겠다.

(if Kakao 2024)최적의 CDC 시스템 구축기 세션 정리

은유 — Sun, 2 Mar 2025 02:13:25 +0900

CDC

CDC란 Change Data Capture의 약자로 데이터베이스에서 발생하는 변경 사항을 실시간으로 추적하고 기록하는 기술
쿼리기반과 로그기반 두가지 CDC 방식이 있는데 쿼리 기반은 주기적으로 풀스캔 쿼리를 실행하게된다면 DB에 부하가 가해짐, 로그 기반은 트랜잭션 로그 기반으로 변경 사항을 추출하기 때문에 DB에 부하가 일어나지 않음
CDC의 사용 사례

고민사항

여러가지 카카오 데이터들중에 민감 데이터는 마스킹이나 파싱을 통해서 파이프라인에 어떻게 녹여야하는지 많은 고민을 함
초대규모 데이터를 어떻게 빠르게 처리해야할지
정합성 검증을 어떻게 해야할지
효율적인 적재 시스템이란 무엇인지

Debezium

가장 대중적인 트랜잭션 로그 기반 CDC 오픈소스
카프카 커넥트 기반으로 동작
다양한 DBMS 지원
실시간으로 오프셋 기록하며 재 연동시 마지막으로 읽은 오프셋 시점에서 복구 가능
증분 스냅샷 기능 지원→ 스냅샷시 테이블락킹을 회피하기위해서 활용함

일반적인 debezium 파이프라인의 모습. 소스 디비로부터 카프카 커넥터(디비지움)이 카프카 토픽으로 적재한 데이터를 싱크커넥터가 타겟디비로 처리해서 보내줌

파이프라인 구조

1년동안 운영하고 있는 현재 파이프라인 구조 스파크가 정합성에 문제가 없는지 매일매일 확인
현재 약 300개의 테이블, 총 2.3TB, 하루 약 1.4억개 레코드를 처리하고 있음
파이프라인 구조중에 Flink CDC도 결국 디비지움 기반의 CDC 오픈 소스
Flink CDC를 도입함으로 얻은 이점
장애 처리 효율성 향상
카프카 싱크 커넥터
JDBC Sink Connector
SMT

정합성 검사

매일 스파크 배치잡으로 정합성 검사 수행
전체 레코드 비교하는 것도 있고 너무 많으면 일단위 변화분 레코드만 비교해줌
매일 오전 알림을 통해 확인

운영시 발생한 이슈와 해결 과정

이슈1

스키마 변경을 실시간으로 반영하지 않는 이유→ 지표 계산 로직과 호환이 깨질 수 있음, 민감 데이터가 보안존 외부로 나올 수도 있음
그래서 DDL 이벤트가 발생하면 알림을 주고 사람이 직접 확인하고 반영 및 재연동을 진행하게 됨

플링크 실행상태를 유지하면서 DDL 이벤트 이후 이벤트를 타겟에 반영하지 않음
이후 DDL 쿼리를 확인하여 반영 가능한 쿼리인지 확인하고 GTIDs를 활용하여 재연동을 진행

이슈2

테이블당 하나의 토픽생성→ 과도한 카프카 토픽 생성→ 이는 부하의 원인이 됨→ 항상 테이블 특성과 스키마가 동일한 샤딩된 테이블에 한해 하나의 토픽으로 합치는 것을 고민

샤딩된 테이블들은 하나의 카프카 토픽을 공유하고 카프카 커넥트에서 메시지를 보고 타겟 테이블을 선택
메세지의 데이터베이스와 테이블명을 사용하여 토픽 이름을 변경함→ JDBC Sink 커넥터의 기본설정이 테이블명을 설정하지 않으면 토픽명을 테이블 명으로 적재하기 때문에 메세지를 보고 타겟 테이블을 선택하도록 커스텀 SMT 구현

이슈3

null 값이 기본 값으로 바뀌어서 적재됨→ 카프카 커넥트 라이브러리에서 카프카 메세지를 json 객체로 변환시 null값 대신 기본 값을 사용(카프카 3.5버전에서 해결), 카프카 커넥트-jdbc 라이브러리 관련해서 json 객체를 수행될 쿼리로변환시, null 값 대신 기본 값 사용
카프카 커넥트는 라이브러리 버전을 업데이트하였고 JDBC 싱크 커넥터는 커스텀 SMT를 구현해서 대응

Iceberg

오브젝트 스토리지 기반 CRUD가 지원되는 오픈소스 테이블 포맷
아이스버그를 사용함으로써 반복되었던 MySql 테이블 덤프가 제거되고 카프카 의존성이 제거됨
필요한 만큼 자원을 할당할 수 있기 때문에 소싱 시간이 개선됨(스파크 자원할당)
카프카 의존성이 제거되어 기존 디비지움의 change event 포맷을 사용하던 것에서 플링크의 RowData 포맷을 사용할 수 있게됨

compaction

플링크는 항상 Merge-on-Read 방식으로 아이스버그에 데이터를 적재
컴팩션은 데이터 파일과 삭제파일을 합쳐 새로운 데이터 파일을 생성하는 것
컴팩션이 필요한 이유: 플링크는 체크포인트 마다 새로운 데이터 파일과 삭제 파일을 계속 생성하는데 조회시 합쳐야되는 파일 수가 시간이 흐를 수록 증가하기 때문에 주기적으로 컴팩션을 해서 합쳐진 파일들을 만들어야지 조회시 성능이 유지됨

스냅샷 만료 및 고아 파일 제거

스냅샷 만료
고아 파일 제거
민감 데이터는 보안을 위해 주기적으로 과거 상태와 파일들을 삭제하고 있고 일반 데이터는 하둡 블록 사이즈보다 작은 파일들이 계속 생성되면 파일 I/O 성능에 부정적이라 삭제를 진행함

샤딩 테이블을 하나의 테이블로 합침

여러 플링크 잡에서 하나의 아이스버그 테이블에 커밋을 수행하면 동시성 이슈로 간헐적 커밋 실패가 발생함 커밋 재시도 횟수를 늘려서 해결할 수 있으나 실 환경에서는 안정적 운영이 중요하기 때문에 반영하지는 않기로함

소감

생각보다 꽤 재미있는 세션들이 많았다. 지금까지 정리한 것은 데이터 엔지니어 직군만 따로 정리한거고 그냥 시간 날때마다 몇몇개는 따로 공부한다는 느낌보다는 감상한다는 느낌으로 쭉 봐도 괜찮을 것 같다. 예를 들어 DBA is free! MongoDB 자동업그레이드 시스템 개발기를 봤는데, 200개 이상의 클러스터를 업그레이드하는데 기간이 너무 길고 반복되서 비효율적이라는 것을 느낀 카카오 DBA가 자동화를 통해 3분만에 업그레이드를 할수있도록 구현한 구현기를 설명하고 있다. 이외에 MMORPG 실시간 알림 서비스 개발기나 카카오 서비스들은 어떻게 CI/CD를 하는가?라던가 다양한 도메인의 서비스를 하는 만큼 각 서비스를 어떤 방식으로 구현하고 유지보수하는지에 대한 내용들이 나와있어서 보는 눈이 즐겁다.

특히 오늘 정리한 이 CDC파트는 내가 사내에서 가장 크게 맞닿아서 하고있는 부분이기도해서 더욱 재미있게 본 것 같다 특히 증분스냅샷 부분이 몰랐던 부분이라서 흥미로웠다. 우리는 그냥 작은 테이블들은 스냅샷을 사용하고 큰 테이블들은 기존 방식인 스파크 배치와 더불어 위에 이어서 현재시점부터 cdc를 적용하는 식으로 활용하고 있는데 플링크 CDC를 사용하는 방식도 검토해볼만할 것 같다. 부록처럼 아이스버그에 대한 내용도 요새 부쩍 아이스버그에 대한 내용들이 많이 들려와서 아이스버그의 오픈소스 방향성이 이전보다 확실히 더 클라우드 친화적이 되어가고 있다는 생각이 들었다.

if kakao 2024 주키퍼 없이 운영하는 카프카 운영 노하우 세션 정리

은유 — Tue, 11 Feb 2025 23:09:12 +0900

if kakao 2024 컨퍼런스에서 재밌거나 나에게 유용하다고 생각하는 세션들을 정리하는 포스팅입니다. 원래는 세션들을 하나의 포스트에 정리하려고 했었는데 영상 하나의 길이가 30분이 넘어가고 다 중요하다고 생각해서 하나하나 정리하다보니 막상 생각보다 너무 길어지게 되어 세션별로 글을 나누게 되었습니다.

시작하기전에

발표배경
- 카카오에서 2022년 if 카카오에 카프카 운용후기를 발표했는데 당시 Kfrat모드를 적용할 예정이었던 것을 소개한 적 있음
- 2022년 발표당시 3.3.1버전이었고 현재 3.8.0을 사용하고 있음
- 버전이 올라가면서 여러 패치와 성능 개선이 있었음 발맞춰서 Kraft 모드로 변경함

주키퍼 없는 카프카

기존 주키퍼의 문제점

리더 파티션 변경이 이루어졌을 때 주키퍼와 카프카 컨트롤러 그리고 다른 브로커들에게 전달하는 과정이 많아서 특정 브로커가 중간에 문제가 생겼을 때 이전 정보와 변경된 정보의 혼합으로 인해 각자 다른 파티션을 리더로 인식하는 문제가 발생

주키퍼에서 컨트롤러로 정보를 전달할 때 통신이 지연되는 일이 종종 발생함 그 사이에 브로커는 잘못된 정보를 가지고 있음
이후 카프카는 점진적으로 주키퍼와의 의존성을 끊으려는 노력을 했고 3.3.1버전부터는 KRaft 모드를 제공해서 완전히 주키퍼와의 의존성을 덜어내려고함

KRaft Mode의 소개

Kafka Raft를 줄여서 Kraft로 표현
변경 사항을 모든 노드가 동일하게 가질 수 있게하는 Raft 알고리즘을 사용함
Raft는 Reliable, Replicated, Rebundant And Fault-Tolerant의 줄임말

KRaft Mode의 구성

컨트롤러와 브로커로 역할이 나누어지고 노드라는 이름로 통칭함
- 리더가 죽더라도 즉각 리더를 변경하여 메타데이터를 신속하게 갱신이 가능
컨트롤러와 브로커 역할을 동시에 할 수도 있음 이를 컴바인 모드라고 하는데 production환경에서는 이를 권장하지는 않음

KRaft Mode의 용어

Leader와 Follower는 흔히 알지만 Kraft 모드로 오면서 새로운 용어들이 많이 추가됐다.
Voter: Leader와 Candidate로 전환할 수 있는 복제본을 말함→ 컨트롤러
Candidate: Leader가 Heartbeat에 응답하지 않아 만료될 때, Voter들이 자기 자신을 후보자로 등록하여 선거를 진행함
Observer: 클러스터에는 속해 있으나 쿼럼으로 구성되어있지 않은 노드들→ 브로커
Epoch: Raft 알고리즘에서는 Terms라고 하며 선거할 때마다 올라가는 수치

Kraft Mode의 장점

주키퍼의 단점을 보완함→처리량 및 대기 시간(딜레이) 감소
안정성 및 소프트웨어 간소화
모니터링 및 관리가 쉬워짐
신속한 컨트롤러 장애 조치

신속한 컨트롤러 장애 조치

벤치마크 결과 장애시 복구 시간이 약 93% 단축 되었으며 이는 스냅샷이라는 존재때문임
메타데이터 캐시에 지속적으로 쌓이는 로그들을 일정 주기로 체크포인트로 쌓이고 이 체크포인트를 이용하여 빠른 복구가 가능→ 증분분만큼만 빠르게 복구 가능

구성과정

카카오에서는 Dev→ CBT→ Prod 순으로 23년 1월을 시작으로 1년이상의 서비스 과정을 거쳐 현재의 Prod 환경까지 실서비스 중
주키퍼 기반 설정때는 broder.id를 고유번호로 사용하며 zookeeper.connect를 통해 주키퍼와 이어주었지만 Kraft 설정에서는 노드별로 어떤 임수를 수행할지 결정해줄 수 있음
주키퍼에서 알아서 지정해주었기 때문에 이전에는 Cluster ID에 대해서 크게 신경 쓰지 않았지만 KRaft 모드를 사용하게 되면 자체적으로 생성 및 저장이 필요함

Dev를 1년 이상 유지한 이유

KIP-996 티켓에서 네트워크 파티션 발생시 선출이 무한히 진행되어 쿼럼이 붕괴되는 문제가 있어서 아직도 이 문제는 해결되지 않았고 이 증상을 막기 위해 컨트롤러를 꼭 3대로 구성되어야함을 권장함
스플릿 브레인 문제가 있었고 3.7.0버전 이상에서 해결됨

벤치마크 및 모니터링툴

벤치마크 워크로드 툴 trogdor
- 카프카 바이너리 내부에 있는 툴 커맨드, API 등을 통해 task 실행 가능
카프카 모니터링 jmx_exporter
시스템 모니터링 node_exporter

안정성 테스트

Trogdor를 통해서 초당 2M 이상 레코드, 초당 2.5GB 이상의 데이터를 인입시켜 스플릿 브레인 문제가 발생하는지, 네트워크와 파워 제거시 Epoch의 증가추세와 브로커에서 복구 시간도 함께 살펴보고자 했음

강한 부하 환경에도 스플릿 브레인 문제는 발생하지 않았고 파워플러그 제거때는 epoch가 소폭 증가, 네트워크 단절에서는 epoch가 대폭 증가함
리플리카, 쓰레드, 압축과 관련된 설정을 중점적으로 확인함

num.replica.fetchers값과 log.cleaner.threads값에서 병목 지점을 발견했고 벤치마크 테스트를 통해서 적당한 값을 찾아 처리량 향상을 할 수 있었음

partitioner.adaptive.partitioning.enable=ture
- 고의적인 지연을 발생시켜 테스트했을 때 부하 불균형 상태에서 SUSP는 다른 파티셔너(RRP, USP)에 비해서 몇배 크게는 몇천배까지 차이가 났으므로 해당 옵션을 true로 해서 사용하기를 권고함

향후 계획

단기계획: 기존의 KRaft 쿼럼 구성 정보는 정적 설정 파일로만 지정이 가능해서 구성 정보를 변경하려면 모든 컨트롤러를 다시 재시작해야하는 문제가 있음 이를 재시작하지 않아도 동적으로 쿼럼 구성 정보를 변경할 수 있는 API를 추가하고자함
장기계획: 컨트롤러가 3대라서 콘트롤러를 5대로 증가해서 KIP-995이 개선되기를 기다리고있음

세션 소감

헬름으로 사용할때도 이전 주키퍼를 사용할 때와 다르게 Cluster ID가 업그레이드시 꼭 필요했음
kafka-ui는 사용하고있지만 Lag 모니터링을 위해 kminion을 따로 사용하고 있고 kminion이라는 것도 처음 알게됨
압축 벤치마크가 인상깊었음 그냥 기본값으로 사용하고있었는데 기본값은 cpu나 초당 데이터 인입 등 시스템 전반적으로 악영향이 있다고 하니 압축을 사용하는 것이 더 비용효율이 높을 것 같다→ 브로커와 파로듀서의 압축 타입을 일치 시켜줘야하므로 디비지움에서도 zstd로 압축을 해줘야함. debezium은 2.0버전부터 binlog 데이터를 zstd로 압축을 지원함
개인적으로 주키퍼때문에 많이 힘들었는데 Kraft로 도전적으로 올렸음에도 불구하고 production에서 안정적으로 구동하고 있음 규모가 크지않아 컨트롤러가 3개인데 그 이상은 브레인스플릿 문제가 생길 수 있다는 사실도 이 세션을 통해서 처음 알게됨

네이버 DAN24 플링크와 아이스버그를 활용한 데이터 웨어하우스 세션 정리

은유 — Sun, 19 Jan 2025 02:24:29 +0900

요즘 ~을 곁들인을 주제로한 세션들이 많아졌다

DAN24

DAN은 platform의 한국어 표현으로 네이버가 공유하는 플랫폼의 역할과 비전을 공유하는 네이버의 통합 컨퍼런스라고 한다. 근데 이왕 한국어표현을 가져올거면 DAN까지 단이라고 하지..처음에는 데이터 어쩌구 네이버의 줄인말인줄 알았다.

아무튼 네이버 컨퍼런스가 열린다는 소식을 듣고 신청을 하려고했는데 추첨제가 아닌 선착순이었고 무려 5분도 채 되지 않아서 접수가 마감되었다는 소식에 허탈함과 함께 컨퍼런스 영상이 올라오기만을 기다렸다.

그리고 드디어 컨퍼런스 영상이 올라왔고 세션들 중에서 제일 보고싶었던 해당 세션을 보고 내용을 정리해봤다. 사실 여러 다른 세션들도 정리하고 싶었으나 이번 컨퍼런스는 ML이나 AI에 많이 초점이 맞춰지고 내가 관심있는 엔지니어링 분야쪽은 그렇게 많지 않았어서 결과적으로 컨퍼런스에 참가하지 못했어도 크게 아쉽지는 않았다.

다음에는 카카오 컨퍼런스에 있는 세션들 중에 내가 관심있어하는 세션들을 모아서 정리해볼 예정이다.

Universal Log Data Warehouse

현재 네이버는 수많은 서비스를 제공
로그 분석을 위해서 각 서비스마다 로그 웨어하우스를 만든다면 리소스 낭비가 발생
이런 상황을 방지하기 위해서 범용적인 웨어하우스가 필요
이를 위해 기존에는 HBASE를 커스텀해서 범용적인 데이터 레이크하우스를 운영하고 있었음
오랜 기간 운영하면서 높은 안정성과 높은 스키마 자유도가 있었지만 로그라는 특성에는 맞지 않아서(시간베이스이기 때문에 random access방식인 hbase의 특성과 맞지않음) 조회속도가 느리고 타 쿼리엔진에서 사용하기가 힘들었음
그래서 결국 새로운 로그 데이터 웨어하우스의 필요성 대두
새로운 로그 데이터 웨어하우스의 목적

CQueryHub Architecture

CQueryHub를 구성하기 위한 테이블포맷 라이브러리

데이타브릭스 제품을 사용하지 않아서 델타레이크를 제외하고 프라이머리 키와 오토컴팩션을 제공하는 후디는 데이터의 관리효율면에서 장점이 있음 아이스버그는 다양한 플랫폼과 쿼리엔진을 지원하기 때문에 현재 운영중인 시스템과의 호환성면에서 장점이 있음
Hudi와 Iceberg를 직접 POC를 해봤을때 데이터 양이 많아지면 Auto Compation 작업시 타임아웃이 발생하며 사용이 불가하지만 Iceberg는 매우 안정적으로 동작하였음→ 기존 시스템과 호환되며, 안정적으로 동작하는 Iceberg를 선택하게됨
Iceberg는 Spark, Flink를 스트리밍 라이브러리로 사용 가능
기존에 Storm의 사용 경험이 존재했기 때문에 Storm과 유사한 방식으로 동작하며 확장 가능성이 있는 Flink를 선택

lassifier는 뭉쳐있는 로그들을 각 데이터셋별로 별개의 kafka 토픽으로 분리하는 역할을 함
의존성 제거 및 데이터 셋 별로 설정 추가로 관리 효율성을 올림
만약 제외할 로그들을 정적으로 관리한다면 변경될때마다 플링크를 재시작해야하므로 무중단으로 파이프라인을 운영한다는 기준에 불충족하므로 보완이 필요함
Writer부분에서 로그들을 파싱하고 Iceberg 테이블 스키마에 맞게 변환하여 저장함
Control Center에서 작업에 대한 모든 설정, 규칙, 리소스를 관리하고 데이터셋에 대한 파이프라인 자동 생성, 삭제, 수정 및 스키마 관리를 할 수 있음→ 운영자동화, 관리효율 높임

Flink Cluster

플링크 클러스트는 크게 JobManager와 TaskManager로 구성됨
JobManager가 모든 작업을 관리하기 때문에 HA없이 구성되어 이 JobManager가 Down되면 작업정보가 유실될 수 있음
TaskManager에는 실제 작업이 수행되며 N개의 TaskSlot이 존재하고 1개의 TaskSlot에서 1개의 Task 수행
플링크는 세션 모드와 어플리케이션 모드가 존재함

제한된 장비내에서 최적의 구성방법을 고민했을 때 AIDA 데이터 플랫폼이 프로젝트 단위로 운영되는 성격에 착안해서 프로젝트마다 별개의 Session 모드의 Flink 클러스터를 생성하기로 함
클러스터 전체에 영향을 주는 k8s의 CPU는 고정시켜두었고 개별 어플리케이션별 조절 가능한 Parallelism으로 리소스 사용량을 조절함
파이프라인의 안정성을 위해서 플링크 JobManager의 HA 구성이 필요

Data Integrity

로그 컬렉터가 at least once 정책으로 운영 중이기 때문에 중복이 존재할 수 있음
writer과정에서 deduplicator 과정을 통해 중복제거
유니크키를 캐시에 저장 후 이후 처리하는 데이터와 동일한 유니크키가 있는지 확인하는 과정을 통해서 중복을 제거함
Flink의 KeyBy 기능을 이용하여 같은 유니크키는 항상 같은 deduplicator로 전송되도록 설정함
유니크키는 메모리에 저장하기 때문에 너무 많은 유니크키가 저장되면 OOM이 발생되며 어플리케이션이 중지될 수 있음→ 최근 일정기간만 저장하도록 하고 이후 중복된 로그는 Iceberg 테이블에 주기적으로 검사하여 중복 로그 삭제하는 airflow dag를 추가함
캐시는 휘발성이라 어플리케이션이 재시작하면 캐시가 삭제되어 중복제거 불가능한 문제→ Flink에서 제공하는 State를 이용하여 체크포인트마다 캐시를 State로 저장하고 Flink가 재시작될 때 State를 이용하여 캐시를 복구해서 문제 해결→ State 크기가 커지면 State를 저장하는 시간이 체크아웃 주기보다 길어지면 에러가 발생하니 주의 요망

Data Cleaning

사용자는 로그를 단순 문자열로 보내고 있음 문자열을 Java Object로 파싱하고 아이스버그 스키마에 맞게 맵핑 작업
아이스버그의 필드명은 Case Insensitive하기 때문에 특정 특수문자만 사용가능함
데이터값이 변경되지 않는 선에서 타입을 변경해서 null로 값이 들어가는 것을 방지
그럼에도 불구하고 정상 처리 되지 않은 데이터는 일부 null로 저장되는 경우가 있음 오류에 대해 생산자에게 리포팅을 함→ 오류에 대해 사용자는 데이터를 버리거나 실패 정보를 함께 저장, 별도 테이블로 저장 등을 선택할 수 있음

Data Loading

실제로 데이터 웨어하우스에 파일을 쓰고 그에 대한 Commit을 수행하는 부분
커밋은 플링크의 체크포인트시 수행하며 체크포인트는 플링크의 중간저장지점으로 이를 이용해 플링크의 내결함성을 지원함
아이스버그는 크게 메타데이터 파일과 데이터 파일로 구성되어 있음

Current & Future

24년 6월 정식 오픈 5개월간 운영중
수백개의 프로젝트, 수백개의 테이블, 초당 수십만개 , 일간 수십억개 계속해서 처리중
급작스러운 로그 양 증가시 수동 대응 필요했음 앞으로는 자동으로 트래픽이 증가되도록 해야함
OLAP 워크로드에 최적화하기 위해서 데이터별 커스터마이즈 기능 제공필요(다양한 파티션, key sort, z-order 등)

마무리

아, CQueryHub는 다른 프로젝트나 라이브러리 이름이 아니라 네이버에서 웨어하우스 플랫폼을 부르는 명칭인 것 같다. 이 세션을 보고느낀 건 요즘 아이스버그의 언급이 커뮤니티나 여러 회사의 사용기 같은게 이전보다 확실히 늘어나는게 체감된다는 정도? 그런점에서 후디와 아이스버그, 델타레이크를 비교하는 장표가 있는데 개인적으로 가장 좋았던 부분이다.

2024년 결산 및 회고 그리고 2025년 계획

은유 — Sun, 5 Jan 2025 23:38:16 +0900

매해 블로그를 통해서 한해를 마무리하고 한해를 되돌아보는 글을 쓰고 그리고 그안에 인상깊었던 사건들과 그리고 인상깊게 보았던 창작물들을 나름 시상식 느낌처럼 시상하면서 마무리하곤 했다.
올해도 역시 어김없이 올해 가장 인상깊었던 사건들과 어떻게 지냈는지를 회고하고 올해 보았던 작품들과 또 그 작품들에 대해서 베스트 워스트를 꼽고 마지막으로 해가 바뀌어 올해 2025년은 어떤 마음가짐과 계획을 가지고 움직여야할지를 다짐과 함께 남기며 다시한번 공증받으려고 한다.
우선 2024년에 기억나는 가장 큰 몇가지 사건들을 나열해보려고 한다.

격정적인 해 2024년

2024년은 되돌아봤을 때 나에게 감정적으로 가장 큰 격동의 시기였지 않나 싶다. 인생에 있어서 가장 큰 슬픔을 맞이하게 된, 그런 일이 있다면 지금은 아니고 싶은 세상에서 가장 큰 이별을 24년 초에 맞이했고 그 이후로 시간이 어떻게 흘러가나 싶었을 정도로 눈떠보니 어느새 12월이고 이미 지난 해가 된 이후다.
어떻게보면 그 감정들을 수습하려고, 그리고 최대한 복잡하고 힘들게 지나면 잊을 수 있으리라는 생각에 부단하게 움직였었던 것 같다. 주변의 지인들의 도움도 컸고 가족들과의 연대에도 많이 기댔다.
그러던 연말에 오랫동안 안했(기도하고 못했)던 연애를 하게되서 또 내가 이래도 되나싶을 정도로 기쁜 나날들을 보내게 되었다.
지금 생각하면 내가 무슨 생각으로 보냈나싶을 정도로 흘러가듯 지내온 것들도 많고 나라는 사람에 대해 그리고 주변인에 대해 많은 것들을 알 수 있는 한해여서 고맙기도하고 또 때론 밉기도하고 복잡하고 미묘한 감정이다.

그래도 여전히 읽는다

작년부터는 독서 스타일이 조금 바뀌게 되었다. 이전에는 오로지 종이책에만 의존하고 정해진 순서와 책을 정해놓고 각잡고 시간을 분배해 읽어내려 갔다면 24년부터는 밀리의 서재를 구독해서 밀리의 서재와 종이책을 병행해서 읽게되었다. 이것은 일련에 나에게 어떤 변화가 있었는데 첫번째로 알뜰요금제에 밀리의 서재가 포함된 요금제로 구입하게 됨으로써 대략 만원 이만원 요금제였고 밀리의 서재가 보통 월에 만원정도 육박하는 구독요금이었기 때문에 내가 밀리의 서재를 잘 활용만 한다면 거의 공짜로 핸드폰을 이용하는 것과 같은 효과가 있었다.
그리고 밀리의 서재를 이용하게 되면서 23년도에 비해서 확실히 텍스트를 읽는 양이 늘어났다. 23년은 한해동안 읽은 책이 6권밖에 되지않았는데 올해는 거의 20권에 달할 정도로 내가 목표로 하는 양도 거의 채웠고 개인적으로도 만족할만큼 성과를 이루었다.
밀리의 서재를 활용하게 되면서 스마트폰과 태블릿을 이용해서도 읽을 수 있기 때문에 장소나 시간에 관계없이 틈틈이 읽을 수 있다는 점이 이 변화에 가장 크게 기여하지 않았나 싶다.
그래서 조금 책을 읽는 스타일이 바뀌었다. 단순히 종이책을 책상 앞에 앉아서 읽었던 기존의 스타일로는 내가 원하는 수준의 양과 질을 챙길 수 없었고 좀더 가볍게 접근하자는 생각이 유효했다.
종이책으로 읽는 책과 밀리에서 읽는 책을 구분하고 조금 가볍게 접근하는 내용이나 소설류는 밀리를 통해 틈틈이 읽는 전략으로 병행하니 읽는 양이 훨씬 늘었다.
아직 이 방법을 정착한지 1년밖에 안되었으니 앞으로도 좀더 이 방법에 익숙해지고 노력하면 이 양을 유지하거나 더 늘어날 수도 있겠다는 생각을 하게되었다.

어쩌다 발표까지

https://metafor.tistory.com/275

dbt Meetup에서 'dagster로 알아보는 dbt'를 주제로 발표한 후기

데이터 오케스트레이션 dagster와 dbt에 대해서 알아보기dagster데이터 오케스트레이션을 강조하는 스케줄러op로 파이프라인의 잡을 정의하며 op로 이어놓은 workflow들은 job으로 구현한다각각 op와 job

blog.metafor.kr

이미 블로그 포스팅을 통해 소개한 바 있지만, 이전에 23년에 한국 데이터 엔지니어 2회 모임에서 세션 하나를 맡아서 발표한 경험이 있었다. 그런데 이번에 블로그를 통해서 dbt 커뮤니티 운영자가 연락을 해왔고 dbt와 dagster를 주제로한 블로그 포스팅 내용을 기반으로 해서 dbt meetup에서 스피커로 참여해 dagster로 알아보는 dbt를 주제로 발표를 하게되었다.
의도하지는 않았지만 23년 이후로 해마다 발표를 하게된 셈인데, 이렇게 된거 25년도 한번 이런 기회가 있다면 내가 공유하고 싶은 내용이나 무언가 한 내용을 가지고 많은 사람들 앞에서 발표하고 공유하는 시간이 있으면 좋겠다는 생각이 들었다.

2024년 나만의 작은 시상식

올해 역시 작년에 이어서 회고에 한해동안 보았던 다양한 매체들에서 가장 재밌게 본 것들과 아쉬웠던 것들을 한줄평과 함께 남겨보면 좋을 것 같다. 올해는 책이 늘어난 만큼 오히려 영화의 비중이 많이 줄어들어서 아쉽다. 내년에는 좀더 영화를 많이 챙겨보면 좋을 것 같다.

올해의 영화

에브리씽 에브리웨어 올 앳 원스는 발상이 재밌었다. 나도 한번쯤 생각해본 생각인데 사람들이 전혀 하지 않을 어떤 행동을 함으로써 갑자기 악마를 소환한다던가…? 그런 재밌는 상상들을 영화로 잘 조합해서 가족에 대한 이야기와 잘 풀어냈던 것 같다
최악은 많기는 했지만 그래도 하나 억지로 뽑자면 킬링 로맨스…?사실 그냥 중간에 그만봐도 될정도였는데 어떻게 끝까지 봤나 싶을 정도였다. 그래도 뭐 어떤 말을 하고싶었는지 정도는 알아들었다.

올해의 예능

생각보다 24년에는 많은 예능과 드라마, 애니를 봤는데 역시 하나를 꼽자면 흑백요리사. 많은 센세이셔널한 짤들과 밈을 만들고 요리에 대해 한번 새로운 취미로 만들고싶다는 생각도 들었다.
번외로 애니와 드라마중에서 꼽자면 86과 눈물의 여왕
최악은 이때 갑자기 뭐에 삘받았는지 회귀나 먼치킨, 대충 이름 긴 애니메이션류를 많이 보기시작했는데 그런 것들 전부를 뽑고싶다…지금 생각해보면 왜봤나 싶을 정도로 아마 24년도에 이렇게 예능류 양이 늘어난건 그런 애니메이션들을 많이 보게된 영향이 가장 크지 않았을까

올해의 책

23년도에는 평가를 내릴 수 없을 정도로 그 표본이 너무 적었었는데 24년도는 드디어 어느정도 무엇이 제일 좋았고 나빴는지를 판가름 할 수 있을 정도로 늘어났다.
가장 좋았던 것은 홍학의 자리다. 원래 이런 스릴러류를 좋아하기는 했지만 책이 아니면 구현할 수 없는 트릭을 가지고 몰입도 있게 잘 구현해냈다. 특히 밀리의 서재를 시작하는 책을 이 책으로 하지않았다면 밀리의 서재로 읽을 그 나머지 책들도 탄력이 잘 붙지 않았을 것 같다는 생각이 들정도로 첫스타트를 잘 끊어줬다.
가장 안좋았던 것은 오늘 밤, 세계에서 이 사랑이 사라진다 해도. 이 작품은 몰입도는 꽤 있었지만 그래서 뭘 말하고싶었는지를 모르겠고 그냥 신파만 강조한 듯한 일반적인 일본소설류에서 느낄 수 있는 감성만 있다는 느낀 책이었다.

작년 목표 점검

작년의 목표는 다음과 같다.

~~주말을 잘 활용할 것, 공부와 운동 내실을 다지는 시간으로~~
상반기에 AI 뉴스 봇 레터, 하반기에 투두 앱 만들어서 런칭하기
- 관련 내용 정리해서 컨퍼런스에서 발표
~~테니스, 클라이밍, 런닝 꾸준히 하기~~
~~책 많이 읽기 최소 20권 이상~~
~~블로그 포스팅 최소 월에 2회 이상, 연 24회 이상 달성하기~~
~~일본어 문자를 다 외운다~~
하반기에 추가한 일본어 문자를 다외우는거까지 꽤 생각보다 많이 이루어내서 나름대로 흡족하게 생각하고 있다. 그래서인지 좀더 자신감이 붙어서 내년에도 잘해낼 수 있을거라는 생각이 든다. 그래서 크게 작년 목표에 대해서 코맨트할 내용은 없는 것 같다.

새해 목표 및 다짐

그래서 작년 목표에 이어서 계속 이어지는 것들 그리고 지금의 방향성에 맞추어서 조금 더 현실적으로 수정한 내용들을 더해 새해 목표를 세웠다.

JLPT 2급 취득
영어 및 일본어 말하기 실력 키우기
플러터 개인 사이드프로젝트 시작하기
책 많이 읽기 최소 20권 이상
블로그 포스팅 최소 월에 2회 이상, 연 20회 이상 달성하기
자격증 취득
- sqld 자격증 취득
- sap 자격증 취득
꾸준히 코딩테스트 연습하기
컨퍼런스 발표 1회 이상
카프카 이해도 높이기

일본어의 경우 크게 생각이 없다가 갑자기 하반기에 재미가 들려서 하기 시작했는데 생각보다 잘 맞고 재미있어서 꾸준히 하게되었다. 일본어 문자를 외운 것을 추진력 삼아서 여러 책들과 회화 공부를 하고싶어졌다. 영어는 뭐 누구나 그렇듯이 평생의 숙제처럼 하게되는 것 같다.
언어를 해두게 되면 취직이나 정보 수급, 여행 등 다양한 바리에이션으로 인생에 도움이 되는 것 같다. 그런 점에서 언어는 알아두면 앞으로의 인생을 살아가는데 도움이 되었으면 되었지 나쁠 일은 전혀 없다는 생각이 든다.
그외에 책이나 포스팅의 경우는 현재의 방향과 양이 적당하다고 생각해서 유지를 하고 좀더 언어나 커리어적인 방향성으로 맞춰졌다.
그리고 계속 미루어두기만했던 플러터로 만드는 사이드프로젝트는 반드시 올해에는 작업 시작해서 런칭까지 만들어내자는 생각이 들었다. 작년 내내 하자고 하자고 생각만 해놓고 너무 유기해놓은 오래된 생각처럼 느껴졌지만 이제는 더이상 물러날 곳이 없다.
종합하자면 올해는 언어와 개인 커리어에 대해서 좀더 집중적으로 내실을 다지는 한해로 만들었으면 좋겠다.

dbt Meetup에서 'dagster로 알아보는 dbt'를 주제로 발표한 후기

은유 — Sun, 22 Dec 2024 23:29:40 +0900

데이터 오케스트레이션 dagster와 dbt에 대해서 알아보기

dagster데이터 오케스트레이션을 강조하는 스케줄러op로 파이프라인의 잡을 정의하며 op로 이어놓은 workflow들은 job으로 구현한다각각 op와 job은 데코레이터로 정의된다하나의 스크립트에 다수의 p

blog.metafor.kr

처음 스피커 제안을 받은 것은 저번달, 데이터 오케스트레이션 dagster와 dbt에 대해서 알아보기라는 블로그 포스팅에 댓글이 시초였다.
서울 dbt 커뮤니티 관리자 혜릭님께서 밋업 스피커로 모시고싶다는 댓글을 받고 고민하다가 연말을 장식하는 이벤트이자 나에게 좋은 기회가 될 수 있을 것 같아서 메일로 연락을 주고 받았다.
필요한 톤앤매너와 주제를 확정하고 최종적으로 dagster로 알아보는 dbt라는 주제로 dbt밋업에 참여해 세션 하나를 공유하게 되었다.
개인적으로는 한국 데이터 엔지니어 2기 모임때 디비지움관련해서 한번 발표한 적이 있었는데 그 이후로 대외적인 발표는 두번째다.
그래도 해마다 한번씩은 발표를 하게 되는 것 같아서 내년에도 기회가 된다면 어떠한 주제로든 발표를 하게되면 좋을 것 같다는 생각이 든다.
이번은 dbt 밋업에서 발표한 후기와 더불어 dbt meetup에서 발표한 내용을 공유하려고 한다.
기존에 포스팅한 데이터 오케스트레이션 dagster와 dbt에 대해서 알아보기라는 포스팅과 전반적인 내용과 기조는 비슷하지만 dbt meeup이었던 만큼이나 좀더 dbt에 대해서 느낀점과 왜 dbt를 도입하지 않게 되었는지 등 dbt에 대한 느낀점에 대해 좀더 분량을 늘렸고 dagster에 대해 조금 지엽적인 부분은 과감히 세션 시간의 할애를 위해서 지웠다.

https://www.meetup.com/ko-KR/seoul-dbt-meetup/events/304791613/?eventorigin=group_past_events
dbt meetup에 참여하고 싶었지만 시간이나 여건상 참석하지 못한 사람들에게 도움이 되길 바란다.

Not a Meetup member yet? Log in and find groups that host online or in person events and meet people in your local community who share your interests.

www.meetup.com

차분한 분위기에서 시작된 밋업

밋업에서 받은 반다나

처음 모임장소에 들어가자마자 커뮤니티 관리자 혜릭님이 맞이해주셨고 체크인을 도와주셨다. 나는 발표자 특혜(?)로 모자와 반다나 한장을 받을 수 있었다. 사실 에코백이 좀더 탐나긴했었는데…물어보기라도 할 걸 처음에 발표 준비하는데 너무 긴장하기도하고 정신을 집중하느라고 차마 물어보질 못했다.
일단 기존에 다른 밋업들도 자주 참여했었는데 가장 비교적 처음든 느낌은 MBTI I인분들만 모아두신 것같다는 느낌이 들 정도로 되게 차분한 분위기에서 시작되었다는 점이다.
나는 개인적으로 한국 데이터 엔지니어 모임에서 이 밋업에 참여하신다는 분들이 계시다는 소식을 들어서 미리 단체 카톡방에서 알게된 분들과 테이블을 같이하게 되어서 그분들과 소통하고 명함 교환도 하게되었다.
테이블에 음료수가 놓여져 있어서 자유롭게 마실 수 있었고 나중에 발표가 끝나고 피자와 맥주를 함께 먹으며 다른 회사들의 상황과 dbt에 대한 의견 등을 나눴다.
조금 아쉬웠던 것들은 다른 밋업들은 조금 자리를 옮겨가면서 자유로운 분위기속에서 커뮤니케이션이 이루어졌었는데 다들 소극적인 성향이신 것도 있고 이미 테이블 자리가 고정이 되어버려서 더 많은 사람들과 이야기를 나누거나 명함을 교환하지 못한 것은 조금 아쉬웠다.
물론 고정된 테이블로도 충분히 얘기가 길어지고 재밌어서 충분히 만족스러웠고 좋았지만 한국 데이터 엔지니어 모임에 가서도 볼 수 있는 조합이었어서 조금 다른 직군이나 다양한 회사의 의견을 보고 듣고싶었던게 있었는데 이건 내가 좀더 적극적으로 움직일 수도 있었는데 그러지 못했던 잘못도 있으니까 밋업에 대한 아쉬움은 아니고 개인적으로 왜 그렇게 하지 못했을까에 대한 회고적인 내용이다.

DAGSTER와 함께 알아보는 DBT

dagster와 함께 알아보는 dbt는 사실 회사에서 airflow 이외에 모던 아키텍처 스케줄러가 여러개 있고(prefect, mageAI, dagster…)각각 poc해서 진행하던 중에 내가 맡아서 담당했던게 dagster였고 dbt와 함께 사용하면 시너지가 날 것 같아서 추가적으로 poc중에 더해서 알아본 것을 포스팅했는데 혜릭님이 보시고 발표를 부탁해주셔서 부랴부랴 재구성해서 이렇게 스피커로 발표하게 되었다.
앞서 얘기했던 것처럼 포스팅은 좀더 dagster에 비중이 있었는데 다시 만들면서 짜잘한 내용은 덜어내고 좀더 dbt를 사용했을 때의 느낀 것들을 추가적으로 담았다. dbt보다는 dbt와 함께 사용할 툴에 Dagster가 있고 어떤 도구인지 정도 알고 가면 충분히 얻어갈게 있을 것이라는 생각이 든다.
그래서 제목을 다시 바꿔본다면 ‘dagster 근데 이제 dbt를 곁들인’정도가 될 것 같다.

dagster

사용자가 데이터 워크플로우를 정의, 예약 및 모니터링할 수 있는 데이터 오케스트레이션 툴, 일반적인 워크플로우 툴처럼 사용자가 데이터 워크플로우를 정의하고 스케줄링 할 수 있다.
dagster는 다양한 데이터 도구 및 플랫폼과 잘 통합되어 다양한 데이터 환경에서 사용성을 향상시킴
- dbt, Airflow, Airbyte, DuckDB, Fivetran, Databricks, Slack, Spark…
python 데코레이터를 사용해서 함수 기반으로 op와 job을 정의
airflow에서도 x-com을 지원하기는 하지만 메모리 등 제약이 있는 반면에 dagster는 op간 변수 상속이 용이함
UI가 직관적이고 op간 리니지 관계가 job단위가 아닌 글로벌 스코프 단위로도 확인할 수 있음

이외에도 메타데이터, 예를들어 테이블을 썼는데 row count를 웹에서 확인하고 싶다던가 plot 라이브러리를 통해서 만든 이미지도 웹에서 표시할 수 있어서 좀더 웹에서 직관적으로 보여지는 부분에서 강점이 있다.
물론 airflow도 가능은 하지만 로그를 찍어서 보는 등 방식이 web ui에서 직관적으로 볼수 있는 방향은 아닌데 dagster는 이런 메타데이터들을 직접 표시해준다.

op

가장 작은 단위로 개별 작업을 수행한다. airflow의 task와 유사하다.
각각의 op는 별도의 input과 output을 가질 수 있으며, op간 변수 상속이 가능하다

Asset

머신러닝 모델, S3, 데이터베이스의 테이블, API와 같은 오브젝트들을 asset이라고 추상화
데이터 네이티브한 작업들이 주로 이 Asset에 포함됨
airflow에서 오퍼레이터 개념
op와의 차이점은 에셋은 데이터 네이티브한 작업이고 op는 컴퓨팅 워크플로우의 단계를 정의하는데 주로 사용됨

이런식으로 데코레이터를 통해서 asset들을 파이썬 코드로 정의하고 데이터베이스 소스에 쿼리를 날리고 위에 task와 의존성있게 바로 다음 쇼핑리스트 함수가 실행되는 구조.
airflow는 꺽쇠(>>)를 통해서 dag의 방향을 결정하는데, 덱스터는 이런식으로 데코레이터 파라미터에 deps의 값을 통해서 의존성 관계를 표현함

dbt-native ochestration

실제로 이 예제는 덱스터 공식홈페이지에서 가져온 것, 거기에 설명도 dbt-native ochestration이라고 써져있다.
여기에 잡을 보면 에어바이스에서 데이터베이스에서 EL을 받은 데이터를 dbt를 통해서 조인해서 마트로 만들고 그 테이블을 파이썬 컴퓨트 작업을 통해서 모델을 만들었다.
실제로 dagster를 사용하면 dbt 프로젝트에서 가져온 쿼리들을 자동으로 의존성을 표시해주고 심지어 여기에 표시된 airbyte나 다른 에셋들과의 의존성까지 정의를 내려서 스케줄을 걸어줄 수 있다.
가운데의 dbt는 코드로 덱스터에서 만든 의존성이 아니라 dbt내에서 매크로로 정의된 ref펑션을 읽어서 업스트림과 다운스트림을 표시한다.
해당 에셋이 어떤 에셋인지(airbyte인지 dbt인지) 보여주는 부분도 airflow와 다른 차별화된 점이라고 생각한다.

JOB

여러 op 또는 asset을 결합하여 특정 작업을 수행한다. job은 op간의 실행 순서를 정의한다.
센서나 스케줄을 정의
airflow로 치면 dag를 만드는 것

dbt

ELT에서 T(transformation)를 담당
오픈소스인 dbt-core와 cloud버전인 DBT Cloud가 존재
SQL base의 transformation만 가능하고, 대신 jinja template을 활용해서 다양한 처리를 제공함

분석가와 엔지니어의 통합

예를들어 이런식으로 sql쿼리가 있다고 했을 때 ref함수로 소스를 표시하면 자동으로 dbt가 의존성 관계를 만들어준다. 그래서 관리하기 편하다는 장점이 가장 크다.
일적으로 카프카를 주로 다루는데 카프카에서 k-sql라는 프로세싱 모듈이 있다. sql로 카프카의 토픽들을 제어할 수 있는 도구인데, 이 k-sql을 통해서 분석가나 엔지니어 모두 편하게 sql을 통해서 스트림을 생성하거나 토픽을 제어할 수 있다. sql은 개인적으로 분석가들과 엔지니어, 그리고 실무자들까지도 다루는 언어중립적인 특성이 있기 때문에 모두가 한 장소에서 공유하고 소통할 수 있다는 장점이 있다고 생각한다.
그래서 이 dbt는 통합성에 강점이 있다. 하나는 다른 플랫폼과의 통합성이고 다른 하나는 분석과 엔지니어링에 통합이 하나다.
앞서 말했던 것처럼 dbt를 단일로 쓰는 것보다는 덱스터나 airflow 등 다른 툴들과의 통합했을 때 더 시너지가 나고, sql이라는 언어중립적인 표현방식을 통해 좀더 소통과 관리가 원활하게 이루어진다는 점 때문

dbt의 기본 구조

그냥 단순히 sql만 다룰 줄 안다고해서 dbt를 바로 사용하기에는 조금 어려움. 이와같은 기본 구조를 일단 숙지해야함

models: transformation 관련 쿼리를 정의
macros: 쿼리에 활용될 사용자 정의 함수 등을 정의
dbt profile: dbt에서 쿼리를 실행할 때 어떤 쿼리엔진 또는 DB를 사용할 것인지 정의(ex. spark, postgresql, trino, duckDB…)
dbt_project.yml: project에서 사용되는 model에 대한 설정을 정의할 수도 있고 모델별로 {{ config() }}로 설정할 수도 있음

모델 정의

materialized라는 항목으로 모델의 타입을 정의할 수 있음
table: 실제 테이블로 생성
view: view로 생성
incremental: 증분 처리할 경우 사용, is_incremental()과 함께 쓰임
ephemeral: 임시 테이블(실행할 때만 잠깐 생성됐다가 실행 후 삭제)

데이터 거버넌스 관리

간단하게 로컬에서 각 테이블 명세를 문서화하고 확인할 수 있음
연결된 데이터베이스 카탈로그 관리
dbt docs generate
dbt docs serve

의외로 가장 마음에 들었던 점은 dbt를 사용하면 이 데이터 거버넌스 관리가 자동으로 따라온다는 점이었음. 물론 discription이나 세부적인 내용은 추가적으로 작성해야하지만 자동으로 파싱된 의존성 관계나 프로젝트 구조, 데이터베이스 연결된 상황 등을 한번에 로컬에서 관리하고 작업할 수 있다는 점이 매리트가 있다고 느낌

dbt를 테스트하면서 느낀점

애드훅하게 빠르게 테스트나 결과를 확인해볼 수는 없어서 간단한 문법 오류나 중간 테이블 확인 등 롱 쿼리 작업, 디버깅 등의 불편함
DBT 하나에 데이터 리니지를 자동으로 명세하고 탐색할 수 있고 관리할 수 있는 장점
여러 모던 아키텍처 도구들과 통합이 용이(airbyte, prefect, dagster, airflow 등)
팀 규모의 활용과 배포를 위해서는 유닛 테스트와 함께 CI/CD 기반이 필요

dbt로 전환하지 않은 이유

dbt로 전환을 했느냐하면은 일단 지금 현상태에서는 dbt를 사용하지 않는 방향으로 poc를 통해서 결정됨

첫번째로 dbt로 옮기기 위해서는 기존에 쿼리방식으로 동작하는 airflow에 있는 쿼리들을 dbt로 옮기고 dbt에 맞춰서 매크로나 모델을 설정해야하는데 그 노동 대비 효율이 크지 않았음. 추가적으로 기존에 이미 자체적으로 개발을 통해서 내부 쿼리를 파싱하는 라이브러리를 만들었고 이를 통해서 태스크간 테이블 리니지 관계를 표현할 수 있었음.

두번째로 dbt에서 스파크를 사용하려면 스리프트 서버를 이용해 연결해야했는데 기존에 사용하고있는 스파크 오퍼레이터 방식은 airflow에서 원하는 리소스를 설정하면 쿠버네티스상에 task 개별 스파크오퍼레이터가 떠서 task간 간섭이 없고 독립적으로 돌아가고있고 이미 검증되고 안정된 프로세스였음. dbt의 스리프트 서버를 사용하면 스파크 클러스터를 항시 운용하면서 Dynamic Allocation을 통해서 잡을 제출하는 식이 될것같은데 충분한 검증이 필요해보임

데이터 거버넌스도 사실 저희는 데이터허브나 아문센을 따로 또 직접 운영하고 사용하고 있기 때문에 따로 dbt에서 제공하는 리니지나 거버넌스가 그렇게 큰 매리트로 다가오지는 않음.

즉 종합하면 대안이 이미 있었기 때문에 나중에라면 몰라도 지금 당장은 여유나 이유가 크지 않았음

그래서 언제 dbt를 사용하면 좋을까?

에어플로우에 dbt를 표시하기 위해 Astronomer-cosmos라고 하는 라이브러리도 테스트를 해봤었는데 조금 다른 기존 에어플로우 스케줄과의 의존성 관계나 센싱하는 것이 살짝 커스텀이 필요한 부분을 제외하면 무리없이 적용이 가능했음. 그래서 이런식으로 다른 스케줄러들과 충분히 이식 및 통합이 가능하다는 장점이 있기 때문에 여기서 설명한 댁스터 이외에도 에어플로우나 프리펙트, 댁스터와 같은 것들과 어울려 사용하기에 적합함.

데이터 거버넌스를 한번에 관리하고 싶은 경우와 쿼리를 체계적으로 관리하고 싶은 경우.
dbt하나로 다른 데이터허브나 아문센 등을 사용하지 않아도 테이블의 목적이나 명세, 의존성 등을 체계적으로 정리할 수 있다는 점.
데이터플랫폼을 운영하다가 보면 항상 시간이나 리소스 부족으로 인해서 미쳐 마트작업 이후에 테이블에 대한 문서화까지 이루어지지 않는 부분들이 많은데 특히 아무리 좋은 툴을 써도 이원화가 되면 데이터브릭스처럼 ai로 어느정도 부분 자동화가 이루어져서 컬럼 설명이 자동으로 적히거나 그런게 아니라면 대부분 사람이 접속해서 직접 해줘야하는게 대부분임. 그런것들을 dbt한곳으로 모으고 하나의 레포에서 일원화해서 관리한다는 것은 그런 툴들간의 전환에 필요한 비용을 줄일 수 있는 장점이 있다.

애널리틱엔지니어가 존재하는 곳.
애널리틱스엔지니어는 분석과 엔지니어 중간 단계에 있는 성격의 직군. 사실 앞서서 sql을 사용한다는게 언어중립적이고 통합할 수 있는 장점이 있다고 말했는데 생각보다 엔지니어적으로나 모델이나 매크로같이 챙겨줘야할 것들이 많이 있다. 그래서 이런 것들이 이용하는 모두에게 인지가 되어있어야 한다. 오히려 스트릭트하게 분석이나 쿼리 업무랑 엔지니어업무랑 나뉘어져있으면 오히려 dbt가 애매하거나 회색지대처럼 여겨질 수도있어서 차라리 이 회색지역을 맡는게 에널리틱 엔지니어 직군이 적합하다는 생각이 든다.

개발자가 영어도 잘해야 하나요?

은유 — Sun, 24 Nov 2024 02:26:47 +0900

사실 책 제목이 아닌 다른 제목으로 하고 싶었는데, 책 제목 자체가 이미 후킹하기에 좋은 내용으로 꾸며져있어서 그냥 그대로 책의 제목을 인용해서 이 글의 제목으로 하기로 결정했다.
이 제목에 이끌려 이 글을 읽게 된 사람도 분명 있을 것이다. 나역시도 이 책을 그런 사유로 출판사에 리뷰이벤트 신청을 했고 운좋게 당첨되어서 이렇게 서평을 남기게 되었다.
제목에 대한 이야기를 이어서하자면 “개발자가 영어도 잘해야 하나요?”대답에 대한 나의 개인적인 대답은 반드시 그렇지는 않다.
다만 저자는 점차 원격근무가 활성화되고 초연결사회로 변화함에 따라서 글로벌화되면서 커리어 성장에 분명히 도움이 된다는 점을 강조하며 최신 개발 트렌드나 기술들은 언제나 항상 영어로 먼저 쓰여지기 때문에 영어는 개발 생산성을 향상시키는 도구라고 말한다.
나는 항상 개발자들에게 언어란 도구라고 생각해왔다. 파이썬, 자바, 자바스크립트, go 등 다양한 언어들이 있고 수많은 언어를 하는 사람이 있지만 결국 사용하는 사람은 개발자고 어떻게 그 언어를 다루는지는 사용자에게 달려있다. 즉, 아무리 어떤 언어가 어떤 특성을 가지고 있다고 하더라도 쓰는 사람이 백분 활용하지 못한다면 결국 그 언어를 사용하는 의미가 없다. 그래서 나는 언어를 여러가지 다루는 프로그래머들은 그렇게 장점이라고 생각하지는 않는다. 물론 여러가지의 각 언어의 탄생 배경이나 철학을 이해하고 그 특징을 잘 살려서 다루는 사람도 분명 존재하기는 하겠지만 하나의 언어도 그렇게 다루기 힘든데 여러개를 동시에 다루기는 더욱 더 힘들다는 생각 때문이다.
어쩌면 불과 비유할 수도 있겠다. 불은 인류 역사상 가장 큰 발견이다. 불로 인해 고기를 익혀 먹을 수 있어서 좀더 단백질 섭취가 자연스러워졌고 영양의 섭취는 물론 에너지를 얻을 수 있고 어둠을 밝히는 여러가지 용도로 사용할 수 있다. 하지만 불을 잘못다루면 화재는 물론 큰 재앙으로까지 번질 수 있을만큼 불은 그야말로 도구였고 그것을 사용하는 사람에 따라서 최고의 혜택이 될수도 있고 최악의 벌이 될수도 있는 셈이다.
이런 여러가지 프로그래밍 언어와 불, 그리고 영어는 어쩌면 개발자들에게 이런 도구인 셈이다. 개발함에 있어서 영어가 반드시 필요한 것은 아니지만 익혀두고 올바르게 사용할 줄 안다면 언제나 우리에게 도움을 줄 수 있는 도구역할을 해준다. 이 책은 그런 영어의 도구적 역할에 대해 챕터를 나누고 설명하고 있다.

개발자가 영어를 놓지 말아야 할 4가지 이유

https://yozm.wishket.com/magazine/detail/2829/

개발자가 영어를 놓지 말아야 할 4가지 이유 | 요즘IT

저는 다국적 IT 회사에서 10년 가까이 일하면서 다양한 나라의 개발자와 엔지니어를 만났습니다. 오랜 기간 그들과 협업하는 과정에서 개발자의 영어 구사 능력에 자연스레 관심을 가지게 되었

yozm.wishket.com

요즘IT 피드를 구독하면서 보게된 내용인데 이 책과의 내용과도 연관이 있어보여서 가져왔다.
다국적 IT 회사에서 10년 가까이 일하면서 다양한 나라의 개발자와 엔지니어를 만난 글쓴이는 회사에서 만난 한국인 개발자들이 다른 나라 개발자에 비해 뒤지지 않은 실력임에도 불구하고 오로지 영어 때문에 온전히 평가를 받지 못하는 모습을 보고 영어에 관심을 가지게 되었고, 그 관심을 토대로 영어를 놓지 말아야 할 이유를 4가지로 요약했다.
첫번째, 개발 언어는 영어 베이스이고 관련 기술 문서도 영어로 쓰여 있다. 말그대로다. 번역된 다른 언어들이 있지만 기본적으로 오픈 소스의 개발자들이 흔히 부르는 도큐먼트들 역시 영어로 먼저 쓰여지고 그 영어를 원문으로해서 다양한 언어로 번역되어진다. AI나 번역기로 번역하는 것은 원래 내용을 재가공하는 과정에서 원 콘텐츠를 100% 전달하지 못할 가능성이 있다.
두번째, 개발할 때 나를 도와줄 인터넷, AI와도 결국 영어로 소통해야 제대로다. 인터넷에 개설된 웹사이트의 63.7%가 영어로 쓰여있다. 막대한 데이터베이스 양 차이로 인해 구글에서는 당연 한글로 검색하는 것보다 영어로 검색하는 것이 더 제대로 된, 그리고 많은 양의 검색 결과를 확보할 수 있다. 대다수의 AI 언어 모델들은 영어로 학습하는 양이 다른 언어로 학습하는 양 대비 약 1000배 많다고 한다. 당연히 영어로 질문하고 영어로 받는 프롬프트 엔지니어링이 더 좋은 퀄리티의 대답을 받을 수 있는 지름길이다.
세번째, 변수명과 주석 모두 영어로 적어야 할 상황이 많다. 개발자라면 변수명 짓는 것을 한번쯤 고민해본적이 있을 것이다. 변수명을 영어로 적는 것은 이견이 없겠지만 주석까지 영어로 적어야한다고? IT 아웃소싱 트랜드 때문이다. 해외 고객사 또는 협력 업체와 영어로 코드를 논해야할 상황들이 점점 늘어나고 있고 해외 개발 인력의 국내 유입도 점점 늘어나고 있기 때문이다.
마지막 네 번째, 본인의 결과물과 작업 의도를 설명함에 있어서 당당해지기 위해서 글쓴이는 일을 하면서 자신이 자신있게 만든 결과물임에도 불구하고 프레젠테이션에서 영어가 부족하다는 이유 하나만으로 가만히 앉아만 있던 것을 많이 봐왔다고 한다. 누군가에게 당당하고 자신감을 가지기 위해서 영어를 배우자는 이유이다.

개발자를 위한 영어 12시제 활용 가이드

https://yozm.wishket.com/magazine/detail/2548/

개발자를 위한 영어 12시제 활용 가이드 | 요즘IT

개발자에게 영어는 선택이 아닌 필수 역량 중 하나인데요. 대부분 프로그래밍 언어가 영어로 되어 있고, 최신 기술과 각종 개발 관련 자료가 먼저 영어로 작성되기 때문입니다. 더불어 점차 글

yozm.wishket.com

저자는 요즘 IT에도 책의 내용의 일부를 기고했는데, 내가 책에 대해서 일부를 발췌해서 가져오는 것보다는 저자가 직접 보라고 올린 내용을 올리는 게 아무래도 저작권이나 의도를 생각하면 더 맞을 것 같아서 링크를 달아둔다.
영어 시제에는 현재, 과거, 미래 시제가 있고 각 시제는 단순형, 진행형, 완료형, 완료 진행형으로 이뤄져 있다.
이를 표로 정리해보면 다음과 같다.

위 링크에 들어가면 해당 시제별로 개발자 영어에서 사용되는 예제 문장들과 함께 알아볼 수 있다.
책도 위 포스팅과 비슷한 형식이다. 영어 기초와 단어, 표현들을 예문들과 함께 설명하고 IT 도메인에서 주로 사용하는 표현이나 약어들은 무엇인지 등을 설명한다.
예를들어 내가 제일 유용하게 생각했던 것은 단축어 부분이다.

GDPR: General Data Protection Regulation(일반 데이터 보호 규정)
SLA: Service Level Agreement(서비스 수준 계약)
RFC: Request For Comments(의견 요청)
TFFB: Time To First Byte(첫 바이트까지 시간)
WFH: Work From Home(재택 근무)

내가 몰랐던 도메인 관련 단어들을 알 수도 있었고 평소에 자주쓰는 단어를 한국식으로 잘못 발음하는 경우도 교정할 수 있어서 더 원어민스럽게 해당 단어를 사용할 수 있게되었다. 특히 프론트엔드, 백엔드, 앱개발자 등 직군별로 어떤 영어 단어들을 자주 사용하는지 그 뜻과 함께 명시해두어서 자기 직군이 아님에도 다른 직군들이 자주 쓰는 단어나 방식들을 파악해서 스크럼이나 대화할 때 더 이해하기 쉽게 접근할 수 있게 되어서 자기 직군의 단어만 주의깊게 읽을 것이 아니라 다른 직군의 단어들도 주의깊게 읽고 이해하고 넘어가면 많은 도움이 될 것 같다.
이외에도 미국 대학원 진학을 위한 영어나 방법을 설명하거나 해외 개발자 취업을 위한 영어는 어떤 게 있고 어떻게 준비해야하는지까지 담겨져있어서 한번에 책을 읽듯이 쭉 읽는 것보다는 자신에게 필요한 파트를 반복적으로 공부하듯이 읽는 것이 좋아보인다.
2월에 우아한테크세미나에서 ‘글로벌 개발자로 성장하는 소프트웨어 실무 영어’라는 1시간 반짜리 세션이 유튜브에 공개되어있는데 이것도 함께 참고해서 보면 다각도로 개발자들을 위한 영어를 학습하는데 도움이 될 것이라 판단이되어서 이 영상을 마지막으로 글을 마친다.
(길벗 출판사의 후원을 받아 서평을 작성했습니다)

나의 매일 아침을 깨우는 뉴스레터들

은유 — Sun, 27 Oct 2024 02:15:07 +0900

나는 매일 아침 뉴스레터를 읽는 것으로 하루를 시작한다

마치 거실에서 아버지가 아빠다리로 앉아서 신문을 정독하는 것처럼 나 또한 아침을 여는 루틴이 한가지가 있다. 매일 평일 아침에 나는 메일과 함께 omnivore를 통해 피드들을 읽는 것이다. 옴니보어는 사용자가 웹에서 읽고 싶은 컨텐츠를 저장하고 관리할 수 있도록 돕는 무료 오픈 소스 어플리케이션이다.
이 프로그램으로 기사나 뉴스레터, 문서 등을 저장하고 나중에 읽을 수 있도록 정리하는 기능을 제공하는 흔히 말하는 Read–it-Lator 앱이다.
웹스크래핑뿐만이 아니라 다양한 플랫폼을 지원해서 모바일이나 테블릿과 같은 다양한 환경에서 피드들을 확인할 수 있으며 옵시디언과 연동하여 스크랩한 기사나 피드들을 글에 인용하거나 스크랩하기도 편리하다.
옴니보어에 관련된 글은 아니므로 이만 중략하도록 하고 옴니보어는 내가 뉴스레터를 보는 한가지 방법이라서 소개한 것뿐이고 그냥 모든 것이 귀찮다 싶으면 그냥 메일을 통해서 확인하는 것도 하나의 방법이다.
다만 여기서 소개하는 몇 가지 일부 웹 형식에 맞지 않는 메일 같은 경우는 옴니보어로 확인했을 때 깨져서 보이는 경우가 있다. 그런 경우에는 따로 메일을 통해서 뉴스레터들을 받아보고 있는데, 그런 경우는 따로 표기를 해서 소개하도록 하겠다.
다시 뉴스레터에 대한 이야기로 넘어가자면 나는 실제로 이 뉴스레터를 꾸준히 읽기 시작한지 2년이 넘어가기 시작했고 내적으로나 외적으로 많은 성장을 하고 있다는 것을 체감적으로 깨달을 수 있었다.
예를 들어 다양한 분야에 정보들을 빠르게 수집함으로써 트렌드에 있어서 빠르게 다가가고 소통하기도 쉬웠고 업무에 있어서도 새로운 기술들을 빠르게 적용해 볼 수 있었다. 아이디어를 얻는 것은 물론 다양한 활동에 근거와 살을 붙여나가며 어떠한 행동에 당위성과 자신감을 얻게 되었다.
매일 아침 습관처럼 시작한 뒤로 처음에는 버거웠지만 점점 자연스럽게 안하면 뭔가 어색한 상황이 되어버렸다.
자기개발을 하고는 싶은데 막상 어떻게 시작해야하는지 모르겠다면 내가 구독하고 있는 피드들과 뉴스레터들을 이 포스팅에 전부 공개할 예정이니 마음에 드는 스타팅 포켓몬을 고르는 기분으로 하나씩 구독해서 매일 출근 시간에 조금씩 읽어보는 것으로 시작해보면 어떨까.

뉴스

14F 뉴스레터

https://www.the14f.com/
14F 뉴스레터는 MBC 산하에서 발행하는 뉴스레터로 매주 월요일, 수요일, 금요일 오전 6시에 발송된다.
최신 이슈, 경제, IT 등 다양한 소식들을 쉽고 재미있게 선별하여 소개한다.
어원은 뉴미디어뉴스국이 위치한 미디어센터 14층에서 14F로 지었다고 한다.
주 타겟은 2~30대로 정치 뉴스보다는 타겟층이 관심을 가질만한 사회, 경제분야의 이슈를 주로 소개한다.

14F 뉴스레터

www.the14f.com

캐릿

https://www.careet.net/
캐릿은 대학내일에서 운영하는 MZ 세대를 위한 트렌드 분석 뉴스레터
최신 트렌드와 MZ 세대의 행동 양식을 깊이 있게 다루며 독자들에게 유용한 정보를 제공한다.
매주 화요일 아침에 발송
최신 유행하는 아이템이나 밈 등 트렌드를 한눈에 파악할 수 있어서 요즘 세대들이 관심있어하는 것은 무엇인지 일목요연하게 파악할 수 있어서 보고있는 뉴스레터

캐릿 Careet

트렌드를 읽는 가장 빠른 방법

www.careet.net

테크

D2 블로그

http://d2.naver.com/d2.atom
RSS로 피드를 등록해서 보고 있는 네이버 개발 블로그
다양한 분야의 개발과 관련된 분야가 올라오고 있어서 제목을 보면서 흥미로운 글 위주로 보고 있다

당근 테크 블로그

https://medium.com/feed/daangn
3개월 전 이후로 글이 안올라오고 있긴하지만 데이터쪽에서는 꽤 양질의 글들이 자주 올라오고 있어서 보고있다.
미디엄으로 되어있으며 미디엄 페이지 안에는 머신러닝, 엔지니어링, 데이터, 검색, IT스타트업, 브랜드/마케팅, 아카이브 등 분야별로 카테고리가 나뉘어져있다.

우아한형제들 기술블로그

https://techblog.woowahan.com/feed/
유명한 배달의민족을 만든 우아한형제들의 기술블로그

Daily dev log

http://daily-devblog.com/
https://awesome-devblog.netlify.app/ 에 등록된 개발자의 블로그를 팔로잉하며 전일자에 등록된 글들을 매일 아침 메일로 한꺼번에 모아서 보여준다.
옴니보어로 웹에서 보면 찌그러져 보여서 메일로 구독중이다.
현재 내 블로그도 awesome-devblog 목록에 올라와 내가 글을 올려도 해당 메일에서 확인할 수 있다.

바이라인뉴스 네트워크

https://byline.network/newsletter/
IT 전문 기자들이 모여 만든 온라인 미디어 플랫폼으로 주로 IT 및 기술 관련 뉴스를 다룬다
일간 바이라인에 요일별로 에디터들의 사담을 적어놓는데 은근히 읽는 재미가 있다
IT전반에 걸친 이야기부터 찐 기술적이고 디테일한 이야기까지 폭넓게 다루고 있는 것이 장점

일간 바이라인 – 바이라인네트워크

바이라인네트워크는 매일 아침 뉴스레터 '일간 바이라인'을 구독자님들께 보내드립니다. 일반적으로 언론사의 뉴스레터는 전날 기사를 홍보하기 위한 수단입니다.

byline.network

GeekNews

https://news.hada.io/
슬랙봇으로도 볼 수 있고 RSS로도 구독할 수 있다 가장 추천하는 건 Weekly로 이메일 구독하는 것
매주 월요일 아침에 발송되며 GeekNews 중 엄선한 뉴스를 발송한다.
직접 글을 등록할 수도 있고 직접 만든 제품이 있다면 홍보도 가능하다.

GeekNews - 개발/기술/스타트업 뉴스 서비스

개발 뉴스, 기술 관련 새소식, 스타트업 정보와 노하우, 세상의 재미난 것들을 좋아하는 사람들을 위한 뉴스 사이트. 이메일 뉴스레터/트위터/슬랙 봇으로 구독 가능

news.hada.io

Nomad Coders

https://nomadcoders.us16.list-manage.com/subscribe?u=a99b43453db5050f1f26b2744&id=4313d957c9
한번도 노마드 코더에서 강의는 사서 본적은 없지만 유튜브 채널과 뉴스레터는 구독해서 챙겨보고 있다
가볍고 재미있게 새로운 기술들과 트렌드들을 소개하고 커뮤니티 역할도 해서 다른 사람들이 만든 사이드 프로젝트나 스터디 모임, 작업 공간 공유 등 다양한 개발 관련 팁과 소식들을 얻을 수 있다.

Nomad Coders

Nomad Coders Newsletter 44,031 명의 구독자와 함께 성장하고 있어요! 최신 개발 Dev 뉴스. IT 이슈 등 개발자의 일과 성장에 도움이 되는 정보를 모아 보내드려요. AI 소식, 사이드프로젝트, UIUX, 서비스기

nomadcoders.us16.list-manage.com

데브IT냥

https://www.hanbit.co.kr/devletter/
데브잇냥이라고 읽는다 고양이 캐릭터를 마스코트로 사용한다.
다양한 개발 분야의 이슈들을 소개하고 한빛의 IT 도서도 소개한다 그런데 이제 냥체를 곁들인
한빛에서 운영하는 데브레터

데브레터 구독하기

구독하기 안녕~ 한빛냥이야. IT밥 먹고 키보드 소리 들으며 졸다보니 혼자 보기 아까운 소식들이 하루가 멀다 하고 눈에 띄더라고. 그래서 개발자들 사이사이를 요리조리 돌아다니면서 흥미로운

www.hanbit.co.kr

요즘IT

https://yozm.wishket.com/magazine/
요즘IT로 바뀐 이후에는 구독방식이 조금 까다로워졌다 뉴스레터를 받고자하는 해당 이메일로 회원가입을 해야해서 옴니보어를 사용한다면 옴니보어에서 받은 메일로 요즘IT에 가입해주어야한다.
최신 IT트렌드랑 기술들을 넘어서 제품에 대한 리뷰나 가이드 등 다양한 분야의 글들을 사용자 참여를 통해 선정된 필진들의 글들을 모아서 보여준다.

요즘 사람들의 IT 매거진, 요즘IT

매일 업데이트되는 요즘 사람들의 IT 이야기! 개발, 디자인, 기획, 다양한 IT 콘텐츠와 함께 성장해보세요.

yozm.wishket.com

정보 및 기타

ㅍㅍㅅㅅ

https://ppss.kr/feed
rss피드로 구독
언론형식이기는 하지만 보도성 게시물 보다는 논설 성격이며 가벼운 글들도 많이 올라온다
필자의 주관들이 많이 개입되기 때문에 팩트를 확인하기보다는 그냥 가볍게 흥미위주로 읽기에 좋다
동기부여되는 글이나 자기개발에 좋은 내용들이 많이 올라온다

EO planet

https://page.stibee.com/subscriptions/174446
스타트업에 관련된 소식들을 다루고있다. 다양한 아이템들이나 창업자들에게 필요한 정보들을 담고 있다.
창업 스토리나 성공 스토리, 프로덕트에 대한 관점 이야기 등 유튜브 인터뷰 영상도 그렇고 창업을 꿈꾸고 있거나 제품을 만드는 사람이라면 한번쯤 구독해서 보는 것도 좋겠다.

스타트업 탐험가들의 필수템 : 이오레터

창업가부터 직장인까지 스타트업을 탐험하는 사람들은 매일 이오플래닛에 모인답니다. 이오플래닛에 모인 이야기들을 매주 이오레터를 통해 만나보세요! -일주일에 딱 한 번 : 금요일 오전 11시

page.stibee.com

Fig.1

https://www.fig1.kr/
<사소한 것들의 역사>와 <최초의 브랜드>를 번갈아가면서 소개한다.
사소한 것들의 역사는 전자기기의 역사나 음식의 역사 등 다양한 분야의 역사를 다루고 있다.
최초의 브랜드는 각 브랜드에 가장 오래된 브랜드의 이야기를 다룬다. 만년필의 가장 오래된 브랜드 워터맨이나 화장품의 가장 오래된 브랜드 산타 마리아 노벨라 등
격주 월요일 오전 발송

Fig.1

Fig.1은 우리 주변의 사소한 물건에 대한 역사를 조명하고 있습니다.

www.fig1.kr

트렌드라이트

https://trendlite.stibee.com/
커머스 버티컬 뉴스레터로 업계 전문가가 커머스 제품들을 리뷰하고 인사이트를 제공한다.
필자가 업력과 내공이 있어서 유용한 것과는 별개로 챙겨보고있다.
업계를 바라보는 전문가의 인사이트가 남달라서 어떤 사건에 있어서 분석하는 포인트만 알아가도 좋을 듯 싶다.
매주 수요일 아침 발송

트렌드라이트

Curated Trend, Essential Insight

trendlite.stibee.com

어피티

https://uppity.co.kr/
2030세대를 대상으로 경제 뉴스부터 금융 상식, 재테크 정보를 쉽게 설명해주는 뉴스레터
머니레터와 잘쓸레터로 구분되며 머니레터는 경제 관련 뉴스와 금융 상식, 잘쓸레터는 돈을 잘쓰는 팁에 대해서 제공하고 있다.
구독자들의 재무 목표와 상태를 받아서 컨설팅을 해주는 컬럼도 진행하고 있어서 비슷한 나이대에 어떻게 자금을 운용하고 있는지 등을 참고하면서 보고있다.

홈 - UPPITY 어피티

MZ 세대의 돈 이야기, 35만 명이 선택한 경제 미디어. 뉴스레터, 영상 콘텐츠를 통해 서비스를 제공하며, 월~금 오전 8시에 발송되는 경제뉴스 메일링 서비스, 머니레터를 운영하고 있습니다.

uppity.co.kr

주말랭이

https://onemoreweekend.co.kr/
주말에 무엇을 할지 고민하는 사람들을 위해 유용한 정보를 제공
매주 금요일 아침 8시에 발송
다양한 활동과 장소를 큐레이션하여 주말을 더욱 의미 있게 보내고, 바쁜 일상 속에서 여유를 찾고자 하는 사람들을 대상으로 한다.
맛집, 카페, 전시회, 콘서트 등 다양한 주말 활동을 추천한다.

주말에 뭐하지? 주말랭이 뉴스레터

주말에 진심인 사람들이 모인 커뮤니티

onemoreweekend.co.kr

페퍼노트

https://maily.so/pepper.note
‘그런 건 어떻게 알았어?’할 때 ‘그런 것’들을 전해주는 잡학사전같은 뉴스레터
독자들에게 다양한 분야(과학, 역사, 언어, 수학, 문화, 취미, 기술 등)의 지식을 공유
fig.1과 더불어 재밌게 보고있는 레터

페퍼노트

당신의 삶에 양념 같은 지식을! '그런 건 어떻게 알았어?' 할 때 '그런 것'들을 전해 드립니다.

maily.so

꾸준히 무언가를 읽는다는 것

꾸준히 무언가를 정해진 시간에 읽는다는 것은 단순히 정보를 습득하는 것 이상의 가치를 지닌 것 같다. 책을 읽을 때는 뇌의 시지각 영역, 그리고 정보를 종합해 계획하고 판단, 충동조절 자기 억제 등에 관여하는 전두엽이 활성화된다. 시간을 통제하고 주변 상황에 불필요한 정보들을 억제하는 전전두엽의 활성화로 차분하게 아침을 시작할 수 있고 세로토닌이 분비되는 아침에 주의력과 집중력을 향상시켜 글을 읽을 수 있다. 매일 아침에 뉴스와 신문을 읽는 습관은 정보를 습득하는 것 이외에 당신에게 충분히 큰 도움을 줄 수 있다는 말이다.
언급한 뉴스레터들을 제외하더라도 다양하고 많은 뉴스레터들이 있지만 개인적인 성향이나 발행이 종료되었거나 너무 많은 양은 오히려 시간을 낭비하게 되는 것같아서 비슷한 성격의 레터들은 단축을 하면서 여러가지 이유들로 제외하고 실제로 내가 지금까지 꾸준히 읽고있는 뉴스레터들만 언급했다.
하지만 이외에 다양하고 많은 분야와 좋은 뉴스레터들이 분명이 존재한다. 그런 것들은 이 포스팅의 댓글로 서로 공유하는 시간으로 마무리했으면 한다.

글또 10기를 참여하며 가다듬는 마음가짐 기록

은유 — Sat, 12 Oct 2024 01:24:27 +0900

글또를 만나게 된 계기

처음 내가 글또를 알게 된 것은 내가 구독하고 있는 daily Dev Blog라는 메일링 서비스에서 였다. 이 메일링 서비스들은 개발 블로그들을 큐레이팅해서 매일마다 해당 블로그에 피드에 글을 쓰면 자동으로 아침에 목록들을 발송해주는 서비스다. 오랫동안 해당 서비스를 구독해오면서 특정 기간동안에 글또라는 명사가 들어간 글들이 한창 많이 올라오던 때가 있었다. 그래서 궁금해서 몇 번 그런 글들을 찾아보고 글또라는 명사에 대해서 검색해보고나서야 글또가 글쓰는 또라이가 세상을 바꾼다는 슬로건으로 6개월동안 지원자들이 각기 블로그에 2주에 1회 이상 글을 의무적으로 작성하는 커뮤니티 프로젝트다.
글또에 참여한 사람들은 서로 피드백도 주고받고 글을 작성하지 않아서 얻게되는 예치금 패널티를 받지 않기 위해 반강제적으로 글쓰기를 하게된다.
나같이 계획만 무성하고 막상 실천하지 않은 사람들에게는 등을 떠밀어주는 아주 안성맞춤인 프로젝트가 아닐 수 없다.
하지만 내가 글또를 통해 발행된 글들을 보고있을 때는 이미 해당 기수의 모집이 끝났을 때였고 나는 아쉬움을 뒤로하며 다음 기수가 시작할 때 알람을 받을 수 있도록 메일을 등록해두었다.
그렇게 기다리다가 글또라는 존재를 내 머릿속에서 거의 잊어갈때쯤, 메일이 왔다.

10기를 모집한다는 메일이다. 드디어 나에게 기회가 찾아왔다. 나는 단번에 구글 입력폼을 채웠고 지원서를 제출했다.

글또를 시작하며 가다듬는 마음가짐

아쉽게도 이번 글또 10기는 마지막 기수다. 글또를 운영하는 변성윤님이 개인 사정으로 인해서 이번 기수까지만 진행한다고 한다. 내게는 이 글또가 처음이자 마지막인 셈이다. 첫만남부터 이별을 생각해야한다니 아쉬울따름이다. 하지만 이 아쉬움을 최소화하기 위해서는 국밥에 마지막 남은 국물까지 싹싹 털어넣는 것처럼 글또의 취지를 백분살려서 이용하고 또 활용해야한다.
사실 글또에서 강제하는 것은 “2주에 한번 블로그에 글쓰기”, 이것을 제외하고는 모두 자신이 하기 나름이다. 글또라는 틀안에서 그냥 글만쓸지 아니면 더 적극적으로 활동해서 많은 것을 얻어갈지는 얼마나 더 글또에 투자하는지에 따라 다르다는 이야기다.
나 혼자 블로그를 운영하며 글쓰기를 진행한지 어느덧 10년이 넘은 것 같다. 물론 그중 개발 블로그를 운영한 것은 절반이 채 안 되지만 글의 빈도나 퀄리티가 들쭉날쭉하고 년초에 다짐했던 매달 2-3개의 글을 올리기로 약속한 다짐은 이제 거의 동력을 잃고 지지부진해진다.
어쩌면 글또는 나에게 기회다. 동력을 잃어버린 글에 다른 사람들은 어떻게 글을 쓰는지 모티베이션을 받고 피드백을 받으며 꾸준히 글을 쓰게 앞으로 나아가도록 나를 항상 활주로로 불러세우게 만들어줄 것이다.
그에 발맞추어 나도 마음가짐을 새로이 해야겠다. 연초에 품었던 열정과 다짐을 다시 새롭게 가다듬어 글또를 적극 활용해서 커리어뿐만이 아니라 많은 만남과 활동의 장이 되었으면 하는 바람이다.

글또 활용방법

글또는 단순히 2주에 한번씩 글을 쓰는 프로젝트가 아니다. 글또에 참여하게 된 인원들은 각자 직군별로 커뮤니티에 모이게 되며, 해당 직군에 정해진 조별로 제출된 글들을 보고 피드백을 남기거나 자칫 조회수없이 뭍히게 되는 글들을 모니터링도 해주게 된다.
그리고 평소에 궁금했던 사항들이나 주제가 있다면 글또 구성원들에게 언제든지 커피챗을 요청해서 친분도 나누고 궁금했던 점도 해결할 수 있다.
마음이 맞는 사람들끼리 모여서 소모임을 만들어 꾸준히 활동할 수도 있다. 나는 개인적으로 재택이나 혼자하는 취미가 많아서 주로 집에서만 있게되는 일들이 많았는데 이번 글또 활동으로 다양한 소모임에 참여해 주말을 채워나갈 생각이다. 단순 개발과 관련된 글과 활동뿐만이 아니라 기타 여가생활들까지 함께할 친구들을 만들어준 셈이다.

일단 개인적으로 관심있는 취미들의 소모임에 참여하고 꾸준히 러닝기록과 일본어 공부한 것들을 올리고 있다. 참고로 아리가또라는 소모임은 대체로 -또로 소모임 이름이 정해져서 드립을 참을 수 없어서 아리가또로 만든 소모임이다. 일본어를 공부하고 공유하는 동아리인데 어차피 일본어 공부도 하고있었어서 잘됐다싶어서 매일매일 꾸준히 일본어를 공부하고 업데이트하고 있다.
글또에서 어떤 만남이 기다리고 있을지, 어떤 내적성장을 가져올지 끝나고 난후에 회고를 하면서 이글을 다시 읽고 내가 되새겼던 마음가짐과 활용하자고 마음먹었던 것들이 잘 지켜지는지 기대가 된다.

데이터 오케스트레이션 dagster와 dbt에 대해서 알아보기

은유 — Tue, 9 Jul 2024 23:08:28 +0900

뭔가 비웃는거 같다...

dagster

데이터 오케스트레이션을 강조하는 스케줄러
op로 파이프라인의 잡을 정의하며 op로 이어놓은 workflow들은 job으로 구현한다
각각 op와 job은 데코레이터로 정의된다
하나의 스크립트에 다수의 pipeline을 포함할 수 있으며 이를 통해 여러 workflow를 구현가능하다→하나의 스크립트를 repository라 정의
각각의 op는 별도의 input과 output을 가질 수 있으며, op간 변수 상속이 가능하다
Op: 가장 작은 단위로, 개별 작업을 수행한다.
Asset: job의 결과물로 생성된 데이터 또는 자료
Job: 여러 op를 결합하여 특정 작업을 수행한다. job은 op 간의 실행 순서를 정의한다
op와 asset은 task 단위라는 성격은 같지만 프로세싱하는 주체의 유무와 데펜던시의 업다운스트림 관계에 따라서 명칭이 갈린다.
- Assets은 데이터와 리니지에 초점을 맞추고 운영은 컴퓨팅 작업에 초점을 맞춤
- Assets은 의존성을 인식하는 반면에 op는 그래프에 배치되기 전까지는 의존성을 알지 못함
- Assets은 데이터를 정의하고 관리하는 데 사용되며, op는 컴퓨팅 워크플로우의 단계를 정의하는 데 사용됨

// asset example
@asset
def logins(website_events: DataFrame) -> DataFrame:
   return website_events[website_events["type"] == "login"]

// op example
@op
def extract():
    ...

@op
def transform(extracted_data):
    ...

@op
def load(transformed_data):
    ...

아키텍처

기본적으로 웹서버와 데몬, 코드 저장소는 항상 떠있고 task 실행시 일시적으로 익스큐터가 동작해서 작업한 뒤 사라지는 형식. airflow 쿠버네티스 잡 오퍼레이터와 유사함
- 웹서버는 레플리카셋을 가질 수 있으나 데몬은 단독 실행만 가능(큐잉 역할을 하기 때문인듯)
에어플로우와 유사하지만 코드 저장소를 따로 둔다는 것과 워커가 존재하지 않는다는 차이가 있음→셀러리 익스큐터를 사용하더라도 항상 떠있지는 않는듯

특징

dbt, snowflake, csv, Fivetran, TensorFlow 등 다양한 에셋을 통해 데이터를 모델링할 수있음→airflow의 오퍼레이터와 유사하지만 좀더 가시적으로 보고 관리할 수 있음

리니지 관계를 job 단위가 아니라 글로벌 스코프로 확인할 수 있다.
굳이 이것을 위해서 넘어가기에는 큰 피쳐도 아니고 마이그레이션 비용이 더 커보임

기대한 것

코드 최소화
- 번거로운 작업 없이나 코드 푸시 없이 웹 콘솔이나 간단하게 작업 가능한지->불가능
작업 간 휴먼 에러 최소화
- 코드 최소화하는 이유이기도 하며 테스트코드를 통해서 어느정도 극복 가능함
의존성 표현
- dagster는 화면에서 좀더 깔끔하게 사용하는 외부 객체나 의존성들을 표현함

dbt 모델을 어떻게 표현하는가

from dagster_airbyte import build_airbyte_assets
from dagster_dbt import load_assets_from_dbt_project
from dagster import asset, Definitions
from .constants import AIRBYTE_CONNECTION_ID, DBT_PROJECT_DIR

airbyte_assets = build_airbyte_assets(
    connection_id=AIRBYTE_CONNECTION_ID,
    destination_tables=["orders", "users"],
    asset_key_prefix=["postgres_replica"],
)

dbt_assets = load_assets_from_dbt_project(project_dir=DBT_PROJECT_DIR)

@asset(compute_kind="python")
def order_forecast_model(daily_order_summary: pd.DataFrame) -> np.ndarray:
    train_set = daily_order_summary.to_numpy()
    xdata, ydata = train_set[:, 0], train_set[:, 2]
    return optimize.curve_fit(f=model_func, xdata=xdata, ydata=ydata, p0=[10, 100])[0]

defs = Definitions(
  assets=[*airbyte_assets, *dbt_assets, order_forecast_model]
)

따로 의존성을 코드로 표현하는 것이 아닌 dbt에서 sql의 from절의 변수명을 파싱해서 upstream과 downstream을 표시

{{ config(materialized='table') }}

select 1
from {{ ref('coalition_agent_schedule') }}

dbt

ELT에서 T(transformation)를 담당
오픈 소스로 활용할 수 있고, DBT Cloud 같이 유료 버전도 있음
SQL base의 transformation만 가능하고, 대신 jinja template을 활용해서 다양한 처리(ex. 사용자 정의 함수)를 제공함
ex) base_orders, base_payments model을 통해 orders라는 모델을 만듦

select
  orders.id,
  orders.status,
  sum(case when payments.payment_method = 'bank_transfer' then payments.amount else 0 end) as bank_transfer_amount,
  sum(case when payments.payment_method = 'credit_card' then payments.amount else 0 end) as credit_card_amount,
  sum(case when payments.payment_method = 'gift_card' then payments.amount else 0 end) as gift_card_amount,
  sum(amount) as total_amount

from {{ ref('base_orders') }} as orders
left join {{ ref('base_payments') }} as payments on payments.order_id = orders.id

기본 구조

models: transformation 관련 쿼리를 정의
macros: 쿼리에 활용될 사용자 정의 함수 등을 정의
dbt profile: dbt에서 쿼리를 실행할 때 어떤 쿼리엔진 또는 DB를 사용할 것인지 (ex. spark thrift server, postgresql, etc.)
dbt_project.yml: project에서 사용되는 model에 대한 설정을 정의...할 수 있지만 모델별로 {{ config() }}로 설정할 수 있음

모델 정의

materialized라는 항목으로 모델의 타입을 정의할 수 있음

table: 실제 테이블로 생성
view: view로 생성
incremental: 증분 처리할 경우 사용, is_incremental()과 함께 쓰임
ephemeral: 임시 테이블(실행할 때만 잠깐 생성됐다가 실행 후 삭제).

문서화 가능

간단하게 로컬에서 데이터 거버넌스 관리 가능

dbt docs generate

dbt docs serve

요청 자동화 관점

on_schema_change→컬럼 추가요청
1. 모델이 변경할때 대한 설정, dbt의 기본 설정은 ignore. 이 설정을 append_new_columns로 설정하면 스키마가 추가되는 경우에 컬럼이 append될 수 있음→incremental의 경우이고 테이블이 설정되어있으면 전체 적용
materalized: table→테이블 추가요청
1. sql문을 통해서 바로 쿼리 변경없이 추가 가능
astronomer-cosmos
1. dbt 모델을 파싱하면서 의존성을 파악하고 airflow task로 그려줌
2. DbtTaskGroup 인스턴스를 사용해 dbt run, dbt test 명령어를 하나의 task group 내에서 실행할 수 있도록 여러 모델을 task group 단위로 묶을 수 있음
3. RenderConfig 인스턴스의 select argument를 사용하면 특정 모델만 선택하여 그룹 생성 가능

def test_dag():
    event_summary = DbtTaskGroup(
        group_id="eventSummary",
        project_config=ProjectConfig(DBT_PROJECT_PATH),
        profile_config=profile_config,
        render_config=RenderConfig(
            select=["eventSummary"]),
        operator_args={
            "vars": '{"ds": {{ params.ds }} }',
        },
        default_args={"retries": 2},
    )
    
    event_summary

ExternalTaskSensor
- 단 astronomer-cosmos만으로는 다른 파이프라인과 DBT 모델 간의 의존성을 해결할 수 없음 ExternalTaskSensor를 활용한 당근마켓의 예처럼 ExternalTaskSensor를 활용하면 쉽게 라이브러리로 만들 수 있을 것으로 보임

DBT와 Airflow 도입하며 마주한 7가지 문제들

안녕하세요. 당근 데이터 가치화팀의 Henry예요.

medium.com

spark나 Trino, duckDB 등 다양한 엔진을 프로세싱에 사용할 수 있음

장점

dbt docs를 통해서 테이블 명세나 리니지 등을 쉽게 확인하고 작업시에 참고할 수 있음
엔지니어의 도움없이 쉽게 칼럼 추가, 테이블 추가 자동화, 테스트 자동화(로컬에서도 가능)
여러 모던 아키텍처 도구들과 통합이 용이하다(airbyte, prefect, dagster 등)

단점

결국 코드 작성 및 푸시를 해야함(초반 허들 및 교육 필요)
애드훅하게 결과를 확인할 수 없기 때문에 간단한 문법 오류나 디버깅하기가 불편함
배포를 위해서는 유닛 테스트와 함께 CI/CD 기반이 되어야지 쓸만할듯

결론

제로베이스에서면 몰라도 airflow를 운용하고있는데 굳이 dagster로 마이그레이션하거나 추가할 필요성은 없어보임
cosmos도 많이 발전하긴 했지만 dbt를 운용하고 있다면 의존성 표현과 스케줄러를 위해서 dagster도 괜찮은 선택 같아보임

스파크에서 지원하는 압축 알고리즘 비교

은유 — Wed, 26 Jun 2024 23:54:14 +0900

압축 알고리즘 비교

Configuration - Spark 3.5.1 Documentation

Spark Configuration Spark provides three locations to configure the system: Spark properties control most application parameters and can be set by using a SparkConf object, or through Java system properties. Environment variables can be used to set per-mac

spark.apache.org

현재 스파크 3.5 기준 압축 알고리즘으로 snappy, gzip, lzo, brotli, lz4, and zstd 지원

snappy

구글에서 2011년에 발표한 자체 개발한 무손실 압축 알고리즘
spark default 설정
적당한 압축률 대비 빠른 압축/해제가 목표
다른 압축 방식 대비 CPU를 덜 사용하고 초당 250MB정도를 압축함

gzip

GNU zip의 줄임말이며 초기 유닉스 시스템에 쓰이던 압축 프로그램을 대체하기 위해 만들어짐 현재 널리 사용되는 무손실 압축 알고리즘
deflate 알고리즘을 사용하여 추가적인 헤더와 체크섬으로 오류 검출에 강점
압축률이 높고 호환성이 좋지만, 압축/해제 속도가 상대적으로 느림

lzo

deflate 압축에 비해 더 높은 압축 속도, gzip보다 더 적은 cpu 리소스
snappy와 유사하지만 압축률이 근소하게 더 높음
빠른 압축/해제 속도를 통해 실시간 데이터에 특화
압축률이 다른 알고리즘에 비해 낮은 편

brotli

구글에서 2013년 발표한 압축 알고리즘
텍스트 압축에 적합하기 때문에 웹 브라우저 등에서 콘텐츠 압축에 사용됨
2020년부터 AWS CloudFront에서도 지원
gzip과 유사한 압축률을 제공하지만 압축 및 해제 속도가 더 빠름
메모리 사용량이 다른 알고리즘에 비해 많은 편

lz4

매우 빠른 속도에 특화된 무손실 압축 알고리즘
압축률은 Deflate 등에 비해 낮지만 속도가 최대 10배 이상으로 매우 빠름
값을 빠르게 전송하거나 저장해야하는 환경에서 자주 사용

zstd

페이스북에서 개발한 무손실 압축 알고리즘
자체 벤치마크상 gzip보다 압축률이 더 높으며 비슷한 해제 속도를 보임
원래는 1~22까지 압축 레벨을 정할 수 있는데 스파크에서는 지원하지 않는 것으로 보임

종합

lz4가 가장 속도가 빠르지만 압축률이 낮고 크기와 속도 절충점으로 zstd가 가장 나아보임
lz4는 실시간 데이터 처리, lzo는 자주 액세스해야하는 프로그램에, Brotli은 웹 성능에(http압축)에 특화되어있어서 좀더 범용적인 zstd, gzip을 대상으로만 평가진행
아래 config 설정을 통해서 spark에서 parquet를 쓸 때 압축코덱을 zstd로 변경 가능

spark.conf.set("spark.sql.parquet.compression.codec","zstd")

벤치마크 결과

다른 사이트들의 벤치마크 결과

heap

How We Saved Millions in SSD Costs by Upgrading Our Filesystem

During COVID we experienced rapid growth in the amount of data we ingest. This post details some of the problems this caused us and how we solved them.

www.heap.io

lz4는 ~4.4x 정도의 압축률을 보임 하지만 zstd는 ~5.5x까지의 압축률을 보여줘서 22%개선
많은 벤치마크에서 zstd가 lz4보다 속도가 느리다고했지만 테스트 결과 쿼리 성능은 변하지 않고 쓰기 쿼리 시간도 절반으로 감소됨

2. AWS, 트위터

AWS는 S3의 압축을 gzip에서 zstd로 바꿔서 30% 정도 크기를 줄였음 | GeekNews

Yann Collet가 만든 zstd가 얼마나 쓸데없는 것을 줄여줬냐는 질문에 대해서, Adrian Cockcroft가 대답한 내용S3의 Exabyte 규모에서 30%는 엄청난 규모의 비용 절감임트위터도 HDFS에서 zstd로 바꾸면서 매년

news.hada.io

사실상 압축 알고리즘 비교 및 벤치마크를 진행하게 된 계기, aws와 트위터 등에서 zstd로 바꾸고 30%정도 비용 절감을 했다는 해커뉴스

3. 우버

https://www.uber.com/en-TW/blog/cost-efficiency-big-data/

분석을 위해 데이터레이크에 100 페타바이트의 GZIP과 SNAPPY 압축을 사용되었고 그중에 크기가 큰 상위 10개 Hive 테이블을 골라 ZSTD로 변환한 후 크기 감소를 확인함
snappy에서 zstd로 변환에서는 약 39% 감소한 것으로 나타남

스토리지 절감뿐만이 아니라 일반적으로 gzip/snappy에 비해 zstd를 사용했을 때 하이브 쿼리에서 vCore사용 시간 또한 감소하였음

4. zstd

https://github.com/facebook/zstd

GitHub - facebook/zstd: Zstandard - Fast real-time compression algorithm

Zstandard - Fast real-time compression algorithm. Contribute to facebook/zstd development by creating an account on GitHub.

github.com

Compression Speed vs Ratio

Decompression Speed

zlib은 Deflate 압축 알고리즘을 C언어로 구현한 구현체
zstd쪽 자료인 것을 감안해서 봐야함

5. 리눅스 커널 벤치마크

https://linuxreviews.org/Comparison_of_Compression_Algorithms

Comparison of Compression Algorithms

GNU/Linux and *BSD has a wide range of compression algorithms available for file archiving purposes. There's gzip, bzip2, xz, lzip, lzma, lzop and less free tools like rar, zip, arc to choose from. Knowing which one to use can be so confusing. Here's an at

linuxreviews.org

압축
- 속도: zstd(1core)>gzip(parallel)>lz4(빠르지만 압축률이 낮음)>gzip(normal config)
- 용량:zstd>gzip>lz4
압축해제
- lz4>gzip>zstd(no option)

실제 데이터 대상 벤치마크

직접 가지고있는 데이터로 테스트를 해봤을 때 평균적으로 gzip은 31~36%, zstd는 39~42%정도 snappy 대비 저장 용량이 감소한 것을 확인할 수 있었다.
3번 테이블은 MB라서 데이터를 확인하기 힘들어서 보기편하게 x10으로 보정함
우버의 벤치마크 결과와 매우 비슷한 결과
trino, spark fetch 및 프로세싱 속도는 네트워크 상태, 인터프리터의 런타임 상황에 따라서 계속 뒤바뀌어서 비교가 무의미했음

결론

압축 알고리즘을 zstd로 변경시 성능적인 손실은 최소화하면서 최소 39%~최대 42%정도의 저장 비용을 절약 할 수 있음

도파민과의 전쟁 회고

은유 — Mon, 10 Jun 2024 01:33:02 +0900

도파민과의 전쟁을 결심하다

문득 침대에 널브러져 유튜브 쇼츠를 하염없이 바라보며 시간을 축낸적이 있지 않은가? 나의 경우가 그랬다. 잠깐만 쇼츠를 보고자 마음먹어도 넘기다보면 한시간은 우습게 시간이 훌쩍 지나가 있다.
쇼츠만 보면 다행이다. 남는 시간 쪼개서 틈틈이 커뮤니티를 보는 시간도 많아서 합하면 꽤 많은 시간을 도파민을 생성시키는 것들에게 투자하고 있다.
문제는 이 행동에는 관성이라는 것이 있어서 내가 문득 즐겁지도 않은데 이것을 습관적으로 계속해서 다음글, 다음 숏츠를 넘기며 보고있다는 점이다.
스탠포드 신경학 교수 앤드류 후버만은 “만약 당신이 즐겁지도 않은 행동을 하면서 왜 이러고 있지? 라는 생각이 든다면 도파민 중독을 의심해보십시요.”라고 말한다.
사실 도파민 중독이라는 말은 없다. 정확히는 도파민이라는 뇌내 신경 물질도 있고 중독이라는 증상의 학명도 있지만 합쳐서 도파민 중독이라는 학명은 존재하지 않는다. 풀어서 이야기하자면 도파민을 일으키는 알콜 중독이나 도박 중독과 같은, 다른 무언가의 중독은 존재할 수 있다.

일상 생활에 지장이 생기는 것만 아니면 중독까지의 증세는 아니다. 중독이라고 불리려면 일상생활에 문제가 생겨야할 정도인데 쇼츠를 많이 보더라도 밥도 잘먹고 회사나 학교를 잘다닌다면 그냥 우리는 의학적으로 숏츠라는 컨텐츠를 다소 많이 즐기고 있다고 보여질뿐 중독의 증세는 아니라도 판단할 수 있는 것이다.
숏츠나 커뮤니티를 보는 것 자체는 문제가 아니다. 자기가 적절한 선에서 소비하고 즐긴다면 건전한 취미고 해소방향성이다. 정신의학과 신영철 교수는 숏츠를 즐기는 것 때문에 일상에 지장이 생기거나 숏폼으로만 도파민이 올라갈 정도로 다른 즐거움이 없다면 중독이고 위험한 것이 맞지만 그렇지 않다면 잘 조절하고 있다는 것이니 그냥 보라고 권한다.
다만 진짜 문제는 너무 숏츠와 커뮤니티의 일회성 발화 주제들을 소비하며 도파민을 얻기 때문에 남는 것이 없고 점점 이러한 경로로만 도파민을 충족하고 있기 때문에 도파민 수용체가 점점 줄어들어 나중에는 숏츠나 커뮤니티를 제외하면 도파민을 얻지 못하게 되는 것이 걱정되었다.
마치 시험기간에 걱정하면서 정작 공부는 안하고 딴짓을 하는 것처럼 이런 생각들을 가지고 있으면서도 나는 일상생활에 지장없으니까 중독은 아니야~자기위로를 하면서 계속 커뮤니티나 숏츠를 즐기고 있던 중에, 그런 나에게 경종을 울리는 일련의 사건들이 연달아 터진다.

맹목적으로 새로운 도파민을 찾는 나를 발견

그저 그것에 멈춰섰다면, 평범하게 취미로 여가시간으로만 커뮤니티 컨텐츠들과 숏츠를 소비했었더라면 지금도 꾸준히 별 의식없이 그것들을 소비하면서 지냈을 것이다. 하지만 문제의식을 느끼게 해준 일련의 사건이 있었다.
가정적이기로 유명한 연예인들이 마약 연루 되었다는 사건, 몇몇 인플루언서들이 잘못된 행실이 발각되어 속되게 ‘나락’에 가게된 사건들 등 하루가 멀다하게 연이어 터지는 소식들에 커뮤니티와 댓글창은 불타고 있었다.
나역시도 대중들중 하나였고 소식 하나하나에 함께 분노하거나 열심히 새로운 소식이 없나 더 찾아보게되는 나를 발견하게 되었고 하루를 마치고 스프린트를 마무리하며 회고를 진행하게 되었을 때 그런 행동들이 나의 감정을 소모하는 일이고 에너지를 낭비하는 일이며 시간을 낭비하는 행동이라는 것이 느껴졌다.
돌아오는 것이 없는 그저 도파민을 충족시키기 위한 탐닉은 내가 원하든 원하지 않든 간접적으로 그 일련의 상황들을 악화시키는데 일조하고 있다.
많은 사람들이 생산적으로 사용하고 옳은 일에 사용할 에너지와 감정들을 단순히 즐거움과 쾌락을 위해서 소비하고 씹어 넘긴다는 것은 사회적으로 보았을 때도 큰 손실이 아닐 수 없다.
성숙하다는 것은 지연보상, 즉 나중에 보상오는 것을 견디는 것이다. 빠르고 즉각적인 보상을 느끼는 것보다 느리고 천천히 돌려받게 되는 보상을 받는 것을 쫓아야 더욱 성숙한 사람이고 성숙한 사회라고 말할 수 있을 것이다.
따라서 빠르게 도파민을 얻었던 지난 시간과 과오들을 느리게 도파민을 얻고 성취감을 얻는 것들로 채워넣자.
도파민은 나쁜 것이 아니다. 도파민 분비 실험을 일례로 들자면 어떤 사람이 눈앞에 공을 던지거나 칼로 위협했을 때 그 사람의 인지 능력이 엄청나게 확장된 것을 확인했다. 도파민 분비로 인해 그 사람이 가진 능력치를 끌어낼 수 있었던 것이다.
도파민을 이용해서 성취감을 얻고 그것을 통해 지속가능한 자기개발을 이루어내는 것이 목표이다.
그래서 나는 커뮤니티와 숏츠 등의 빠르고 자극적인 컨텐츠를 소비하는 대신에 다음과 같은 것들을 대체하기로 했다.

책 읽기
커리어와 연관된 공부하기
뉴스와 유익한 블로그 글들을 읽기

하지만 결심한 이후로도 여전히 나는 무의식적으로 커뮤니티와 숏츠를 빈번하게 드나들었고 시간 조절에 실패하는 모습을 여러번 회고를 통해 확인할 수 있었다. 무언가 극단의 조치가 필요해보였다.

나의 무분별한 소비를 멈춘 몇가지 방법

내가 실제로 행했던 방법중에 가장 효과적인 방법은 애초에 시작도 못하게 접근 루트를 차단하는 방법이다.
어른들이 육아할때 아이들의 스마트폰 시간을 어플리케이션 등을 통해 물리적으로 차단하는 것과 아주 유사하다.
내가 스스로 조절하지 못한다면 외부(혹은 프로그램)의 도움을 받는 것이 필요하다.

인스타그램을 지운다

나는 인스타그램을 통해서 친구의 소식이나 스토리를 접하게 되었는데 그 외에는 사실 피드를 꾸민다던가 내 소식을 올린다는 것은 잘 하지 않았다.
인스타는 나의 생활에 아무런 영향도 미치지 않을 것이라 생각한것도 잠시 얼마전에 내 핸드폰의 스크린타임 분석 결과를 봤는데, 꽤나 많은 부분 인스타그램이 스크린 타임을 차지하고 있는 것으로 나왔다. 단순히 스토리만 보고 릴스는 안봐서 쉽게 생각했는데 그렇지 않았구나라는 생각이 들어 과감히 인스타그램을 탈퇴하고 어플리케이션을 삭제했다.

유튜브 계정을 새로 생성해서 구독목록을 생산성, 공부 위주의 목록으로 대체해서 채운다

나에게는 두개의 유튜브 계정이 있다. 지금까지 그냥 보면서 마음에 드는 것들을 마구잡이로 구독한 계정과 생산적이고 나에게 도움되는 정보들만 제공해주는 채널들만 구독한 계정. 이렇게 두개는 서로 독립적인 목록을 가지고 있고 유튜브를 이용한 사람들을 알겠지만 구독 목록의 차이는 알고리즘의 차이로도 이어진다. 유용한 정보를 제공하는 채널만 구독해둔 계정은 계속해서 유용한 정보만 메인 페이지에 표시해준다.
실수로 쇼츠를 누르더라도 유용한 정보를 제공하는 쇼츠들만 보여주니 쉽게 빠져나오기도 용이하다.
다만 이 계정에서 잘못해서 흥미위주의 영상을 클릭했다면 시청기록에서 해당 영상을 반드시 지워주어야한다. 유튜브는 구독한 목록을 통해서도 영상을 추천해주지만 시청한 기록을 통해서도 다음 영상을 추천해주기 때문이다.
이렇게 분리한 계정으로 옮겨두고 기본계정으로 사용하다보면 내가 시간이 남고 진짜 흥미로만 단순히 여가생활을 즐기기 위한 수단으로써 내가 필요로할때만 유튜브를 시청할 수 있어서 조절이 가능하다.

쇼츠를 누르지 않는다

유튜브 메인에서 쇼츠가 뜬다면 오른쪽 위에 x버튼을 누러 다음부터 쇼츠는 뜨지않게 설정해두자, 또는 크롬 확장프로그램을 통해서 쇼츠를 아예 메뉴에서 없애주는 프로그램도 있으니 이를 적극 활용해보는 것도 방법이다.
다만 위에 생산성 위주의 목록을 구독한 계정이라면 메인에서 쇼츠 목록만 지워주는 것만으로도 효과가 클것이다. 보다 더 극단적으로 강제하고 싶다면 확장 프로그램 등을 활용해서 제한하는 것도 좋다.
또한 확장 프로그램에 특정 사이트를 블럭해주는 확장도 있으니 이를 활용하면 무의식적으로 특정 커뮤니티에 접근하는 것을 미연에 방지할 수 있다.

커뮤니티에 가입하지 않고 댓글을 달지 않는다

이 수칙은 사실 이번 기회에 지키게 되었다기보다는 오래전에 성인이 된 이후부터 내 마음속에 규칙을 정하고 나름 잘 지켜오고 있다. 가입을 하고 로그인을 하는 과정은 생각보다 귀찮다. 아무리 하고싶은 말이 있더라도 그때의 감정일뿐 가입하고 로그인하려는 동안에 사라져서 의욕또한 사라진다. 애초에 그정도로 사라질 마음과 글이라면 쓰지 않는 것이 오히려 자신에게 더 득이 된다.
그래서 나는 지금까지 블로그 글과 같이 항상 돌아보고 고쳐쓰는 글들이 아니면 커뮤니티에 가입도 안하고 글을 쓰지도 않는 원칙을 고수하고 있다.

시작이 반이다

그렇다면 지금 커뮤니티 글이나 숏츠를 단 한번도 보지 않느냐고 묻는다면, 그것은 아니다.

다만 위와 같은 상황들을 강제하며 내가 원하는 시간에 원하는 만큼 볼 수 있게 조절할 수 있게 되었다고는 단언할 수 있다.
어느 정도 습관이 된 이후로는 내가 의도해서 접속하는 것이 아니라 무의식적으로 접근하는 것은 완전히 사라졌다.
실제로 한단계 뎁스를 두는 것은 물리적으로나 심리적으로 큰 도움이 된다. 시작이 반이라는 말이 있다. 운동을 하기 위해 헬스장까지 가기만 한다면 나머지는 쉽다. 마찬가지로 숏츠나 커뮤니티에 글들에 한번 물꼬를 틀기 시작하면 끝도없이 보기 시작한다. 이미 시작해버린 순간 빠른 자극을 통해서 다음을 갈구하게 되는 것이다.
나는 숏츠나 커뮤니티를 들어가는 것이 어떤 매커니즘이나 생각을 통해서 내가 이것을 즐겨야지, 혹은 어떤 목표가 있어서 이것을 찾아야지하고 의도해서 접근하는 것이 아니라 무의식적으로 아무생각도 없이 내 손가락이 알아서 움직이는 것을 깨달았고, 계정을 따로 두거나 사이트 블럭 확장 프로그램을 통해서 번거롭게 사이트 도메인을 allow하는 뎁스를 두게하는 것만으로도 나는 그런 무의식적인 행위의 대부분을 멈출 수 있었다.
아예 시작조차도 하지 못하도록 막는 것이다.
마치 카드나 통장도 하나로 사용하는 것보다는 여러개로 목적별로 구분지어 나누고 거기서 돈을 사용하다보면 통장에 돈을 옮기는게 귀찮아서라도 그 안에서 활용하려는 노력을 하게 되는 것과 같다.
어떻게 보면 스스로 간단한 조작으로 막혀있던 것(예를 들어 사이트 블럭이나 유튜브 계정 전환 등)을 풀고 계속 커뮤니티나 숏츠를 즐길 수 있지만 생각할 '틈'과 '여유'를 둠으로써 내가 스스로 결정할 수 있는 시간을 가졌고 자연스럽게 무의미한 시간들을 줄일 수 있었다.
혹시나 나처럼 숏츠와 자극적인 이슈거리에 빠져서 무의미한 일생에 대한 회의감을 느낀 적이 있다면 위에 써놓은 몇가지 방법들을 적극 추천하고 싶다.

당신의 인덱스는 안녕하신가요?(커버링 인덱스)

은유 — Sun, 31 Mar 2024 21:10:38 +0900

인덱스를 적용하는 이유

인덱스는 데이터베이스 내의 데이터를 빠르게 찾을 수 있도록 도와주는 데이터 구조이다. 인덱스를 사용하지 않은 상태에서 데이터를 검색하면, DBMS는 요청된 데이터를 찾기 위해 테이블의 모든 행을 순차적으로 검색해야 한다. 이러한 과정을 풀 테이블 스캔(Full Table Scan)이라고 하며, 대량의 데이터가 저장된 테이블에 풀 스캔을 할 경우에 많은 시간이 소요될 수 있다.
인덱스를 적용하면, DBMS는 인덱스를 통해 데이터의 위치를 빠르게 찾아 접근할 수 있게 되어 검색 속도가 향상된다. 대부분 인덱스를 설명할 때 책의 목차에 비유하는 이유도 이 때문이다.
인덱스는 검색 시간과 쿼리 실행 시간을 단축시킴과 동시에 테이블 전체가 아닌 인덱스 내에서 스캔하기 때문에 DB에 부하도 최소화 할 수 있는 장점이 있다.
하지만 인덱스는 데이터베이스 내에서 인덱스를 저장할 공간을 필요로 하며, 데이터의 추가, 삭제, 수정 작업 시 인덱스도 같이 업데이트가 되어야 하기 때문에 DB의 공간적인 특성과 추가나 수정이 빈번한 테이블인지 테이블의 특성에 따라서 알맞게 설계되어야 한다.

커버링 인덱스란?

일반적으로 인덱스를 설계한다고 하면 여러가지가 복합적으로 검토되어야 한다. 예를 들어 어떤 컬럼이 SELECT, WHERE절, JOIN절, ORDER BY 절 등에서 자주 사용하는 지, 어떤 컬럼이 선택도가 높고 중복된 값이 적어 검색 결과가 전체 데이터의 작은 부분만을 차지하는 지 등
여기서 커버링 인덱스는 쿼리를 충족시키는 데 필요한 모든 데이터를 갖고 있는 인덱스를 커버링 인덱스(Covering Index)라고 부른다.
위에 인덱스 조건을 만족하는 테이블을 찾아 인덱스를 걸었다고 할 때, 이 커버링 인덱스 조건을 만족하는지 확인하려면 EXPLAIN 쿼리를 사용하면 된다.
EXPLAIN 쿼리의 결과 값 중에서 Extra 컬럼을 확인해보면 다음과 같은 표기로 나뉜다.

Using Where: DB의 엔진으로 필터링 될 때 Using where로 풀림 즉, 스토리지 엔진에서 불필요하게 많은 데이터로 엑세스 한다는 의미이므로 인덱스 설계가 제대로 되지 않았을 가능성이 높음
Using Index: 커버링 인덱스 상태
Using index condition: 인덱스 컨디션 푸시다운으로 WHERE 조건을 스토리지 엔진에 전달하여 스토리지 엔진에서 필터링된 데이터를 전달함. 역시나 스토리지 엔진에서 데이터를 엑세스하므로 인덱스 설계가 제대로 되지 않았을 가능성이 높음
빈값 - 일반적인 쿼리

위와 같이 Using Index로 나온다면 커버링 인덱스가 잘 적용되었다는 뜻이다. 그렇다면 커버링 인덱스를 만족하기 위해서(Using Index)어떻게 해야할까?

커버링 인덱스를 만족하는 인덱스 만들기

카디널리티가 높은 순에서 낮은 순으로 구성
- 카디널리티는 해당 컬럼의 중복된 수치를 나타낸다.
- 예를 들어 성별은 남과 여밖에 없으므로 카디널리티가 낮고 주민등록번호는 고유하므로 카디널리티가 높다
- 인덱스의 최대의 효율을 뽑아내기 위해서는 해당 인덱스로 많은 부분을 걸러내야하기 때문에 카디널리티가 높은 것을 잡아야 한다.
- 만약 복합 인덱스를 건다면 카디널리티가 높은 순에서 낮은 순으로 구성하자
- SELECT count(distinct col1) FROM table 쿼리를 통해서 카디널리티를 구해서 비교해보기
SELECT와 WHERE 조건에 걸리는 것으로 INDEX를 구성
- SELECT절에 무심코 *를 썼다면 이제부터는 index를 건 컬럼을 명시해주자
- WHERE절도 마찬가지이다
비교 연산이나 서브쿼리는 지양
- like절 특히 문자열 시작부분이 아닌 중간이나 끝 부분을 검색하는 패턴 ex)%검색어
- 부정 연산자: NOT EQUAL(<>), NOT IN, NOT LIKE 등의 부정 연산자
- 계산이 포함된 조건 ex)column + 1 = 10

무작정 인덱스는 검색성능 향상에 좋을 것이라는 착각을 가지고 인덱스를 생성했다면 다시한번 위와 같은 사항을 점검해서 자신이 올바르게 인덱스를 사용해서 쿼리하고 있는지 확인해보고 인덱스를 활용해야겠다.

SparkSQL에서 증분 테이블 처리하기

은유 — Sun, 25 Feb 2024 21:49:36 +0900

배경

ETL처리시 Spark를 통해 Trasfroming을 하는데 1000만 로우가 넘는 테이블을 이관하며 기존 Overwrite하는 방식이 아닌 증분되는 양만큼만 반영하기로 함
updated_at 컬럼으로 증분되는 양만 읽어서 기존 테이블에 upsert를 하는 방식
현재 운영하는 데이터웨어하우스는 일반적인 RDB가 아닌 HDFS기반이므로 불변성을 위해서 upsert를 할 수 없음

옵션

Hudi or Delta Lake or Iceberg와 같은 동시성이 제공되는 오픈소스를 사용한다
- 현재 실시간 테이블을 위해서 Delta Lake를 사용되고 있지만 이관을 위해서는 따로 사용하고 있지 않으므로 다른 테이블과 사용성 및 통합을 위해서 해당 옵션은 보류
SQL 윈도우 함수를 통해서 증분된 만큼 처리하고 기존 값과 UNION한다.
- 해당 방법으로 진행

트러블슈팅

spark.sql("""
SELECT
		*
FROM (
    SELECT
				column_lists...,
        tmp_num,
        row_number() over(partition by id order by tmp_num desc) as row_rnk
    FROM (
        SELECT a.*
        FROM (
            SELECT *, 1 as tmp_num FROM db.table_name
            union all
            SELECT *, 2 as tmp_num FROM table_name_new
        ) a
    ) b
) c
where c.row_rnk = 1
""").write.mode("overwrite").insertInto("db.table_name",overwrite=True)

두번째 방안으로 위와 같이 spark sql을 처리시 다음과 같은 에러가 난다.

AnalysisException: Cannot overwrite a path that is also being read from.

원인

문제는 spark에서 같은 경로를 읽고 있을 때 그 경로를 덮어쓰려고 할 때 발생됨. 아래 두가지 이유로 추정됨

InsertIntoHadoopFsRelationCommand가 정적 파티션 삽입으로 실행될 때 실행 전에 읽는 주소가 쓰는 주소를 포함하는지 확인하기 때문(참고)
동일한 경로로 읽고 쓰려고 할 때, spark 자체 지원인 parquet를 사용해서 읽으면 동시에 메타데이터를 캐싱하기 때문에 읽는 동안 쓰기 작업을 수행할 수 없음(스파크 문서의 해당 단락 참조)

해결

1. temp DB를 거치는 방법

https://stackoverflow.com/questions/38746773/read-from-a-hive-table-and-write-back-to-it-using-spark-sql
위 링크와 같은 방식으로 SaveAsTable 혹은 아예 insertInto를 통해 temp 테이블을 만들고 그 테이블과 UNION 하면 읽는 것과 쓰는 테이블이 달라진다.

Read from a hive table and write back to it using spark sql

I am reading a Hive table using Spark SQL and assigning it to a scala val val x = sqlContext.sql("select * from some_table") Then I am doing some processing with the dataframe x and finally comi...

stackoverflow.com

하지만 쓰는 테이블이 두개로 나누어지고 심지어 같은 데이터를 공유한다. 테이블양이 많아지면 양적인면 속도적인면 모두 비효율적이므로 이 방법은 지양하도록 한다.

2. spark의 convertMetastoreParquet의 옵션을 false로 설정

spark.conf.set("spark.sql.hive.convertMetastoreParquet", "false")

spark.sql.hive.convertMetastoreParquet 설정을 false로 설정하면, Spark SQL은 Hive의 SerDe를 사용하여 Hive metastore Parquet 테이블을 읽고 쓰게 된다. 이는 Spark 자체 Parquet 지원을 이용하는 것이 아니라 Hive 방식을 사용하게 됨.
presto로 읽을 때도 hive serde를 통해서 읽으므로 이 설정을 적용해도 presto에서 문제없이 테이블을 읽을 수 있음

참고문서

Read from a hive table and write back to it using spark sql

I am reading a Hive table using Spark SQL and assigning it to a scala val val x = sqlContext.sql("select * from some_table") Then I am doing some processing with the dataframe x and finally comi...

stackoverflow.com

HiveQL을 Spark SQL로 이전 시 발생하는 문제 해결하기

들어가며 안녕하세요. LINE Plus Messaging Data Eng Dev (NP) 팀에서 데이터 엔지니어로 일하는 정우영입니다. 최근 HiveQL(Hive SQL) 작업을 Spark SQL로 이전하는 과제를 진행했습니다. 주로 INSERT OVERWRITE TA...

engineering.linecorp.com

Parquet Files - Spark 3.5.0 Documentation

spark.apache.org

혼자공부하는 머신러닝+딥러닝 책 리뷰

은유 — Sun, 18 Feb 2024 23:16:34 +0900

머신러닝과 딥러닝에 대한 공부를 시작하게 된 계기

나는 직업적으로 데이터 엔지니어라는 직군을 가지고 있고, 최근들어 GPT모델을 사용한 생성형 AI 모델의 급성장과 생태계 파괴수준의 시장에서의 영향력은 아무래도 일반적인 사무직보다 더 크게 다가왔고 실제로도 많은 일처리 방식이나 생활 양식에 등 다방면에 걸쳐서 변화를 이끌어냈다.
물론 이러한 일련의 과정들이 없었더라도 직장에서 데이터 사이언티스트와의 협업이라든가 모델링이 필요한 업무의 요구사항이라든가 이것을 배워야한다는 필요성과 가치는 항상 느껴오고 있었다.
다만 아직 업무에 적응하기도 바쁜데… 배워야할 것들이 아직 태산인데…따위와 같은 핑계 아닌 핑계들로 인해서 뒤로 미루고 애써 못본 척을 해야했다.
하지만 이제는 진짜로 뛰어들어야 할 때다. 더이상 늦춰지면 영영 기차가 떠나가 버릴지도 모르겠다는 생각이 들정도로 발등에 불이 튀었다. 그래서 머신러닝과 딥러닝에 업무로써 직접적인 도입을 실천하기 보다는 점진적으로 조금씩 그 개념부터 차근차근 살펴나가기로 했다.
그 첫걸음이 바로 이 ‘혼자공부하는 머신러닝+딥러닝’이다. 우선 가장먼저 책의 제목부터 마음에 들었다. 독학을 강조하면서 그만큼 쉬운 이해와 설명을 내포하고 있는 제목이다. 실제로도 그랬다. 한빛 마켓과 김 팀장이라는 가장의 회사와 인물을 예로 들어서 다양한 업무상 겪게되는 문제들을 머신러닝과 딥러닝을 통해서 해결한다.
읽는 이들은 이러한 예시들을 통해서 어떻게 머신러닝이 실제 현실에서의 문제들을 어떤 방식으로 풀어나가는지를 보여주고 있다.

그래서 머신러닝이 뭔데?

머신러닝은 규칙을 일일이 프로그래밍하지 않아도 자동으로 데이터에서 규칙을 학습하는 알고리즘을 연구하는 분야이다. 한마디로 데이터 속에서 어떠한 규칙을 발견하고 그러한 알고리즘을 모델이라고 부르기도 한다.
많은 머신러닝 알고리즘 중에 인공 신경망을 기반으로 한 방법들을 통칭하여 딥러닝이라고 부른다.
보통 프로그램은 누군가 정해준 기준대로 일한다. 예를 들어 앞에 빨간불이 있으면 멈춰, 초록불이면 가! 이런 식이다. 하지만 머신러닝은 그런 기준을 정해주지 않아도 알아서 빨간불이면 멈추고 초록불이면 간다. 당연히 머신러닝은 만능이 아니고 한계점도 분명히 존재한다. 수많은 데이터를 통해서 학습을 시켜줘야하며 그 데이터의 질은 좋아야하며 설사 그렇다고 하더라도 모델의 score가 100%가 되기는 아주 힘들다. 이 알고리즘의 스코어를 올리기 위해서 다양한 회귀 알고리즘이 있고 이 책에서는 그런 방법들 또한 소개하고 있다.

쉽게 설명한다고 했지만 여전히 어려워

솔직히 말해서 6장까지는 이미 파이썬을 어느정도 알고있기도 하고 scikit-learn이나 케라스 등 이미 접해보거나 귀동냥으로 조금씩 줏어들어서 익숙한 내용들이 많았다. 하지만 이후 딥러닝 파트에서 부터는 저자가 아무리 쉽게 설명한다고 하더라도 딥러닝 이외에 수학이나 통계에 관련된 원론적인 개념들과 기반지식이 필요했기 때문에 지면관계상 생략한 것들을 필요로하는 내용들이 빈번하게 요구되면서 바로 단번에 이해하기 힘든 부분들이 많았다.
특히 심층 신경망이나 옵티마이징하는 부분처럼 신경망에 관계된 내용은 특히 그랬다. 그래도 희망적인건 어설프게나마 대충 어떤 내용이겠거니하고 추측은 가능하겠더라는 것이다.
전에 데이터 엔지니어 관련된 모임에서 발표를 공유하는 파트에서 머신러닝과 관련된 주제로 발표하시는 분들이 더러있었다. 그런분들의 발표는 거의 대부분 그냥 이런게 있구나하는 정도로만 넘어가고 전혀 이해하지 못했었는데 그래도 앞으로는 어느정도 방향성을 가지고 말하고 있구나 정도의 윤곽은 잡고싶다.
당연히 아직도 먼 이야기이긴 하지만 이 책을 발판으로 삼아 앞으로 다양한 책들과 강의로 더욱 발돋 움해야겠다.

나는 노션을 버리기로 결심했다

은유 — Tue, 13 Feb 2024 00:44:50 +0900

초기 노션의 의도나 어플리케이션의 만듦새가 그당시에 크게 혁신이라고 느끼고 많은 이들이 같이 쓰고 느껴봣으면 좋겠는 마음에 장황하게 노션을 소개하는 포스팅 글을 올릴 만큼이나 신봉자에 가까웠다.
당시 많은 메모앱들을 사용하고 있었고 노션을 알게됨으로 인해서 단번에 노션 하나로 통합해서 모든 것을 노션으로 기록하고 클립핑하고 정리하기 시작했다.
하지만 나는 최근 몇가지 이유로 인해서 노션을 더이상 기록저장이나 정리용도로 사용하지 않기로 결심했다.

첫번째, 쓰지 않는 잡다한 기능들이 추가되면서 앱 자체가 무거워지기 시작했다. 사실 초기 노션부터 무겁고 느리다는 지적은 쭉 있었다. 현재까지 이를 노션팀에서 인지하고 수정하고 보완하는 작업이 진행되고 있지만 앱이 가진 한계가 있다보니 이를 완전히 극복하기는 힘들어보인다. 원하는 문서를 찾는 검색기능뿐만이 아니라, 하나의 문서의 글이 길어지면 페이지 로딩 자체가 느려지면서 빠르게 원하는 요소들만 접근해서 살펴보기 어려워졌다. 특히 메모는 아이디어가 떠오를 때마다 바로 즉각적으로 적는 것이 중요한데, 그 즉각성이 떨어진다는 느낌이 들었다.
두번째, 예쁘게 작성하는 것에 매몰되어 공들여 페이지를 만들어도 보지 않고 묵혀두는 일들이 비일비재 해졌다. 노션에는 비교적 간편하게 문서를 예쁘게 꾸밀 수 있어서 예쁘게 정리할 수 있다. 하지만 노력에 들인 것에 비해서 정리해놓고 펼쳐보지 않는 노트들이 많아져서 무엇을 위한 메모인지 목적성이 모호해졌다. 이것은 단순히 사용자가 의도적으로 노트를 펼침으로써 극복할 수 있지만 뎁스나 접근성(속도나 검색 등도 종합해서)이 떨어지면 자동적으로 문서를 덜 찾아보게 된다.
세번째, 앞선 문제의식에 나아가서 더 노트에 활용도를 높히고 생산성을 높히기 위한 방법론 중에 하나인 제텔카스텐을 사용해서 메모하려면 노션은 최선의 선택은 아니라는 것을 깨달았다. 옵시디언이라는 다른 대체제가 존재했고 그것을 활용해 메모하는 습관을 들이려고할 때 최적화된 방식으로 구현되는 것을 목표로 해야겠다는 생각이 들었다.
이 세가지를 이유로 생산성이라는 하나의 목적을 두고 노션으로의 통합이 아닌 각자 필요한 기능과 성능에 따라서 도구들을 재편해서 사용해야겠다는 문제의식과 목표가 생겼고 나는 여러 생산성 도구들을 알아보고 각 도구들의 쓰임새에 맞게 사용처를 알맞게 개편하기로 했다.

현재 사용하고 있는 생산성 도구들

여러 생산성 도구들을 비교하고 분석해보면서 최종적으로 사용하게될 도구들은 아래 세가지다. 노션을 완전히 대체하기보다는 노션의 부족한 점들을 각자 보완하고 앱의 특성과 목적에 맞게 사용할 생각이다. 우선 각 앱들간의 장단점들을 먼저 살펴보면 어떻게 사용하면 좋을지 파악하기 쉬울 것 같다.

노션

장점
- 웹퍼블리시를 통해 공유나 협업을 위한 기능들이 유용함
- 다양한 템플릿이나 뷰 제공으로 스프린트나 다양한 뷰로 데이터를 볼 수 있어 정리의 용의함이 있음
- 생각보다 웹페이지 클리핑 기능이 좋다
- 멀티플랫폼 지원
- 최근 유료지만 AI관련된 기능 및 API를 다수 지원함
단점
- 블럭이나 페이지가 늘어날 수록 속도가 느림
- 프로그램이 메모리를 많이 먹음
- 태그 기능 미지원

업노트

장점
- 빠르다
- 웹을 제외하고 멀티플랫폼을 제공
- 평생 요금제를 제공하는 가격적 메리트($29.99)
- 동기화가 잘됨
- 잦은 업데이트와 피드백
- 다양한 import나 export를 제공
단점
- 데이터베이스를 모아서 보여줄 수 있는 방법이 없음
- DB로 관리가 안되다보니 투두리스트의 경우 누적해서 보거나 추적하기가 힘듦→새롭게 그날그날 새로운 페이지를 생성해서 써야함
- 데이터가 중앙화로 인해서 보안이나 유출에 대한 문제에 대해서 자유롭지 않음

옵시디언

장점
- 플러그인을 통한 확장성과 코드를 통한 커스터마이징이 무궁무진
- 탈서버, 로컬에 저장하므로 플랫폼의존도가 적으며 마크다운 파일로 저장되어 다른 이기종 전환에 유리함
- 제텔카스텐 기법을 적용하기에 최적화 된 기능 제공
- 프로그램이 가벼움
- 멀티플랫폼 제공하지만 동기화 기능은 유료로 제공(우회할 수 있는 여러 방법들이 있지만 제한적임)
단점
- 커스텀하기 좋다보니 오히려 주객전도되는 느낌으로 커스텀에 시간을 많이 투자하게 됨
- 싱크가 유료이거나 서드파티를 사용해야하는데(아이클라우드나 드롭박스 등)다른 온라인 동기화 서비스들에 비해서 완벽한 네이티브를 기대하기는 힘듦

메모리 기준으로는 노션≥옵시디언>업노트 순으로 가볍다. 옵시디언은 확장때문에 좀 무거워진 느낌이 있어서 확장없이 기본으로만 사용한다면 업노트와 거의 비슷한 수준인 것 같다.
결론적으로 각 장단점을 살리는 방향으로 상호보완하여 세가지 프로그램 모두 운용하기로 결정하였고 각 프로그램의 역할을 다음과 같다.
우선 노션은 칸반보드나 스프린트 템플릿 등 유용한 데이터뷰를 제공하기 때문에(옵시디언도 플러그인을 이용하면 사용할 수 있지만 비교적 복잡하고 예쁘지 않다.)개인용 회고나 스프린트, 칸반보드로 추적, 그리고 협업이나 간단한 문서를 공유할 때 웹퍼블리싱 용도로 사용하기로 하고 나머지 기록들에 대해서는 옵시디언과 업노트로 옮기기로 결정했다.
여기서 중요한 것은 업노트는 PARA형식, 옵시디언은 제텔카스텐 형식으로 메모형식을 각각 바꿔 기록하기로 했는데 이것은 추후에 다른 포스팅에서 다루기로 하고 지금은 그냥 간단하게 업노트는 초벌용 노트 및 퀵 노트, 또는 빠르게 아이디어를 스케치하는 용도로 사용하고 있고 옵시디언은 글쓰기와 생산성 중심으로 글을 쓰기 위한 재료들을 수집 및 나만의 언어로 재가공하는 영역으로 사용하고 있다는 정도만 정리하고 넘어가면 좋을 것 같다.
지금 옵시디언의 사용방식에 대해서 언급하기 시작하면 플러그인부터 시작해서 제텔카스텐 방식까지 할 얘기가 너무 길어질 것 같아서 우선은 여기까지만 정리하고 다음을 기약하도록 하겠다.

사실 여기서 빠진 설명은 클리핑 정도가 되겠는데, 노션의 웹 클리퍼의 성능이 좋아서 클리퍼도 노션으로 저장하고 확인할까 생각하다가 예상치도 못하게 옴니보어라는 서비스를 발견하고 옵시디언과 옴니보어를 통합해서 사용하기로 결심했다.

옴니보어를 활용해서 Feed와 뉴스레터, 웹클리핑을 한번에 해결하기

여러 도구를 살펴보았던 것들중에 각 도구들의 특징과 장단점이 명확했었는데, 단 한가지 웹클리퍼 도구로써의 각 도구들은 조금씩 그 성능의 차가 애매했다. 웹 클리퍼들을 비교하면서 한가지 놀라웠던 것은 노션의 웹 클리퍼의 성능이 다른 프로그램들에 비해서 좋다는 것이다. 업노트의 웹브라우저 확장의 경우는 그냥 없다고 생각하는 게 좋을 정도로 셀렉터 없이 문서를 다가져오고 옵시디언은 클립핑을 사용할 수 있기는 하지만 방식이 조금 조잡하고 설정이 조금 필요하다. 노션은 거의 아무런 설정없이 아주 간편하게 필요한 엘리먼트만 적절하게 가져오고 다른 곳들에서 접근이 안되는 문서들도 잘 가져온다. 그 이외에 포켓이나 feedly로 기존에 조금씩 사용하고 있었어서 그것도 고려를 했었지만 성능이 애매한 부분도 있었고 유료로 사용해야하는 기능도 있고해서 배제하기로 했다.
그래서 결국 노션으로 클리핑해서 아카이빙하고 확인할까하고 생각하다가 한가지 걸리는 점이 있었다. 클립핑 성능은 마음에 들었지만 처음 노션을 버리기로 결심했던 요소. 바로 자주 손이 안간다는 점이었다.
노션으로 웹페이지들을 아카이빙하면 말그대로 아카이브만하고 찾아보질 않을 것 같다. 이렇게 노션을 버리고 다양하게 프로그램들을 번갈아 사용하는 목적에는 생산성을 늘리고 유기적으로 수집한 것들을 글쓰기에 활용하기 위함인데 그 역할을 제대로 해줄 수 있을 것 같지 않았다.
그러던 중 옵시디언과 통합해서 사용할 수 있는 옴니보어와 readwise에 대해서 알게되었고 이 둘을 비교하던 중에 최종적으로 옴니보어를 사용하기로 했다.
우선 옴니보어는 무료이고 readwise는 유료였다는 이유가 가장 크기도했고, readwise에서는 캔들이나 다양한 e-book에서의 밑줄이나 요약을 제공해주기도하고 메일로 클립핑한 것과 밑줄친 것들에 대해서 요약을 보내주기도 하지만 사실 킨들을 사용하지 않는 나로서는 굳이 필요이상의 기능이었다. 그래서 굳이 유료로 사용하지 않아도 옴니보어에서 제공해주는 클립핑, 피드와 뉴스레터 구독 기능만으로도 충분했다.

옴니보어?

옴니보어를 처음 들어보는 사람들도 많을 것이다. 나도 이번에 옵시디언의 활용법을 찾아보다가 우연히 소개영상을 보게되면서 알게되었는데, 옵시디언을 굳이 사용하지 않더라도 기존에 메일 클라이언트나 웹 브라우저로 계정을 접속해서 메일링을 구독하고 있는 사람, RSS를 통해 피드를 구독하고 있는 사람, 웹클리핑 확장을 통해 특정 웹페이지를 아카이빙하는 사람들이라면 옴니보어를 사용하면 하나로 통합해서 사용할 수 있다. 게다가 무료로! 심지어 iOS와 안드로이드, 패드 등 다양한 멀티플랫폼 앱을 제공한다.
이를 read-it-later app이라고 통칭하는데, 앞서 소개한 readwise와 옴니보어 이외에 포켓, 인스타페이퍼, feedly 등이 유명하다.
여러가지 read-it-later앱 중에서 왜 옴니보어를 선택했느냐고 묻는다면, 이중에 옴니보어가 옵시디언 플러그인을 제공하며 메일링, 웹클리핑, rss 피드 모두를 무료로 제공하는 공통 분모를 가진 앱은 옴니보어가 유일했기 때문이다.
옴니보어는 오픈소스로 이미 github에 저장소가 공개되어있으며 셀프호스팅으로 직접 운영할 수도 있고 직접 코드를 기여할 수도 있다. 물론 지금은 무료로 웹에서 모든 기능을 제공하고 있기 때문에 굳이 서버가 있더라도 호스팅할 필요는 없다. 게다가 가장 큰 장점이라고 한다면 현재 사용하고 있는 옵시디언의 옴니보어 플러그인을 통해 내가 스크랩한 아티클들과 뉴스레터들을 옵시디언으로 가져와 동기화할 수 있다는 것이다.

기존에 피드는 feedly를 통해서, 아티클은 노션이나 포켓을 통해서, 뉴스레터는 spark 메일 앱 클라이언트를 통해서 각자 따로 분산해서 관리하고 있었는데 옴니보어를 사용하고 난 이후로부터는 feedly와 노션, 포켓, spark 모두를 옴니보어 하나로 통합해서 사용하고 있다.
옴니보어의 대한 설명은 해당 도큐먼트로 대체하며 줄이도록 하고, 이 글의 주된 내용인 생산성에 집중하기 위해 옴니보어를 사용하게 된 의의와 과정들을 설명하도록 하겠다.

아카이빙으로 끝나지 않고 글의 소재로 만들기

글쓰기에 가장 중요한 과정은 참조가 되는 문서들을 수집하고 계속 나에게 노출시키는 것이다. 제텔카스텐 기법의 글쓰기 방식은 그것에 특화되어있고 그 도구로써 옵시디언은 글을 쓰는 소재들을 모으고 갈무리하는 작업을 하기에 최적화 되었다. 그래서 옴니보어를 통해서 웹 서핑을 하다가 얻은 인사이트가 담긴 아티클들을 담고, 매일 구독한 피드와 뉴스레터들 중에 좋은 구절을 하이라이팅으로 표시한 것들을 옵시디언으로 가져와 다른 글들의 레퍼런스로 삼는 것이 큰 모티프이다.
핵심은 담은 글들을 모두 가져오는 것이 아니라 옴니보어의 하이라이팅 기능을 통해서 밑줄친 일정 부분만 발췌해서 가져오는 것이다.
필요한 것은 옴니보어 웹 클리퍼 확장과 옵시디언의 옴니보어 커뮤니티 플러그인, 그리고 옴니보어 계정이다.

하이라이트 모드에 들어가면 아티클이나 뉴스레터, 피드들에서 내가 밑줄치고 메모한 것들이 리스트되어 나와있다. 이 목록들을 옵시디언 옴니보어 플러그인에서 설정한 주기와 태그값대로 정리되어 옵시디언에 동기화되어 저장된다. 이어서 나는 이 노트들을 알맞게 태그를 추가하거나 연결성을 추가하며 관리를 한다.

노션을 버린다고는 했지만...

제목에 노션을 버리기로 결심했다고 당당하게 적어놓기는 했지만 사실 일정부분 노션에 의존하고 사용하는 부분들이 많다. 이는 다른 앱들로는 대체할 수없는 분명 노션만이 가진 장점이 있는 부분이기 때문에 그 장점을 취하되 그 한계점을 파악함하고 동시에 그것을 보완해줄 수 있는 다른 것들로 채워넣었기로 했다.
애초에 생산성을 위해 사용했던 앱이 생산성을 얻을 수 없다면 다른 생산성 있는 것을 위한 앱으로 바꾸거나 시도를 해보는 것이 필요했다.
한창 여러가지 시도를 통해서 나만의 최적화된 생산성 극대화 템플릿을 만들었고 아직 초기이기는 하지만 이전에 하나로 통합해서 메모들을 관리하는 것에 비해서 훨씬 생산성도 올랐고 좀더 유기적으로 메모를 활용하는 것이 가능해졌다.
이 글은 이에 일부, 그 활용법에 대해 잠깐 맛보기로 공유하는 글이다. 아직 PARA나 제텔카스텐, 그리고 옵시디언의 활용법 등 다양하게 할 이야기가 많지만 이 이야기들은 차후에 조금씩 전달하도록 하겠다.

2023 어느덧 4년차 개발자 회고

은유 — Sun, 7 Jan 2024 22:38:22 +0900

어느덧 4년차 개발자

눈 깜짝할 새에 4년차 개발자가 되었다. 개인적으로 이 시점이 커리어적으로 가장 중요한 순간이라는 생각이 든다. 시니어는 아니지만 그렇다고 주니어라고 치기에는 애매한 연차. 여기서 얼마나 더 잘 갈고 닦느냐에 따라서 앞으로의 커리어가 더욱 상승 곡선을 그릴지 아니면 완만하게 그냥 흘러가게 될지 결정짓는 변곡점이라는 생각이다.
내가 주니어 시절 항상 이직하거나 리더와 미팅을 할 때 가장 먼저 주안점을 두고 물어 보았던 질문이 하나 있다.

"일에만 집중할 수 있는 환경인가요?"

안타깝게도 첫번째 회사는 일에만 집중할 수 없는 수직적인 구조였고 정치적이거나 업무 이외에 불필요한 다수의 의미없는 행동들을 강요받았던 환경을 겪었기 때문에 병적으로 그저 아무것도 신경쓰지 않고일만 할 수 있는 환경에 집착했다.

그때는 맞고 지금은 틀리다

하지만 지금은 업무를 대하는 방식을 조금 다르게 접근해야할 필요성이 느껴졌다. 주니어때는 일만 바라보면서 그저 단순한 양적인 실력을 늘리는 것이 중요했지만 지금은 어느정도 자신만의 기준이 생겼고 메타인지가 생겼으며 업무의 프로세스가 생겨서 노하우와 일정을 컨트롤하는 일종에 근육이 생겼다.
그렇게 됨으로써 점차 시야를 넓게 보는 안목이 생겼고 단순히 할당받은 일만 잘한다고 해서 더이상 성장할 수 있을 것 같지 않았다.
문서 작성은 물론이고, 필요한 아키텍처를 미리 조사하고 POC하며 필요성을 리더에게 설득하는 능력, 업무 프로세스를 정립하고 그것을 랜딩하기 위해서 PR하는 능력 또한 업무를 하는 사람에게 필요한 능력이라는 것을 깨달았다. 단순히 할당된 것을 구축하고 유지보수하는 것만으로는 더이상 발전을 이룰 수 없는 것이다.
그래서 앞으로는 누가 시키지 않더라도 상황에 맞게 필요한 솔루션들을 미리 리서치해서 그때그때 먼저 제안할 수 있는 사람이 될 수 있도록 앞으로의 커리어는 동향 파악은 물론 조리있게 그것을 잘 포장해서 전달하는 능력 또한 연마하도록 노력해야겠다.

2023 가장 핫한 주제

ChatGPT, 생성형 AI는 작년 초부터 수면위로 떠오른 아주 뜨거운 주제이다. 작년 1월에 출시한 지 2개월 만에 월간 활성 사용자 수 (MAU) 1억명을 넘어섰다. 이는 틱톡이 9개월, 인스타그램이 30개월 걸려 도달했던 기록이다. 굳이 수치를 제하고 봐도 ChatGPT가 등장하고 나서부터 그와 맞춰서 급변하는 생태계와 우후죽순 늘어나는 프로덕트들은 굳이 필드에 있지 않아도 익히 느껴질 정도니까 말이다.
AI를 활용한 프로덕트들이 대거 늘기 시작했고 주변 개발자들은 생성형AI 등을 활용해서 업무의 생산성을 높혔다. 아마 눈에 보이지는 않지만 코딩이나 작업 등에 AI를 활용함으로써 신입 한명뽑을 정도의 맨파워는 이미 직무를 보고있는 담당자들이 나눠서 처리하지 않았을까?
덕분에 신입들은 취직하기 더 힘들어졌을 것이라는 생각이 든다. 단순히 이것만이 이유는 아니고 최근 부트캠프 시장의 활성화, 관심의 집중 등으로 시장의 크기나 인풋이 훨씬 늘어난만큼 요구사항도 더 다양해지고 커트라인 또한 올라가는 등 여러가지 요인이 있겠지만 단순히 생각했을 때, 간단한 업무는 AI를 활용해서 빠르게 처리할 수 있으니 신입이 경험을 쌓을 기회조차 박탈당해버린 것은 아닐까하는 생각이다.
조금 큰 일이라는 생각이 든다. 일자리가 금방 대체될까봐서가 아니다. 이전부터 이런 변화의 기류는 이미 알고있었고 나름 빠르게 대처하고 대응하고 있다고 생각하며 데이터 엔지니어로의 직무전환을 생각했었다. 하지만 예상보다 더 빠르게 변화의 파도가 몰려오는 기분이다.
그래서 2023 하반기에는 발등에 불이 떨어진 것처럼 머신러닝과 딥러닝에 대해서 공부하기 시작했다. MLOps의 직무전환을 염두 해두며 앞으로의 미래를 준비해야겠다.

2023 잘한 일

올해 새롭게 시도하며 그것이 잘 정착되면서 시스템화 시킨 것들이 있다. 마음먹고 런칭하면서 잘 될까 고민했지만 예상보다 물흐르듯이 잘 흘러가는 느낌이 들어서 올해 2024년에는 이 시스템을 잘 활용해서 아웃풋으로 이끌어내는 한 해가 되었으면 좋겠다.
첫번째로 옵시디언을 작년에 사용해보자고 마음먹고 여러가지 방법론들을 공부하고 적용하려는 과도기를 거쳐 결국 제텔카스텐 방식을 도입하여 메모를 하기 시작했다. 아직은 괄목할만한 성과나 가시적인 결과로 보여지지는 않지만 올해 2024년에는 천천히 쌓아둔 메모를 토대로 하향식 글쓰기가 아닌 상향식 글쓰기로 더 높은 생산성을 이루리라 기대한다.
두번째로 업무에서만 사용하던 스프린트를 개인에게도 적용해서 하반기부터 스프린트 플래닝과 칸반을 이용한 작업 수치화를 시작하고 있다. 플래닝하면서 내 맨파워를 스스로 인식할 수 있었고 나의 역량에 맞게 계획을 세우고 실천하기 시작했다. 하반기에 급격하게 포스팅이 늘어난 것은 이 스프린트의 계획한 것을 실천하고자하는 나의 노력이 어느정도 반영된 결과이다.
클라이밍이나 테니스 등 기존 헬스만 했던 나의 운동 생활이 더 폭넓고 새롭게 배우기 시작했다. 아직 재미를 붙여나가고 있는 단계지만 새로운 취미에 대해 접근해 나가는 과정이 늘 새롭고 짜릿하다.
여행을 자주 가고 주말에 가족들과의 여가 시간이 늘어났다. 전에는 여행에 대해서 부정적ㅡ이라기 보다는 아무 생각이 없었으나, 휴가를 가고 다른 환경에서 리모트 근무를 진행하면서 퓨즈를 잠시 꺼두듯, 일과 멀어져서 아무런 생각도 안하는 시간이 나에게 도움이 된다는 사실을 깨달았다. 업무로 복귀했을 때 집중도와 몸의 피로도가 확연히 이전과는 달라졌다는 것이 체감되었기 때문이다.

어릴 때 여행을 다니는 것도 경험이다

앞서 서술한 것과 같이 어렸을 적 여행을 가는게 무슨 경험이냐, 그냥 집에서 누워서 유튜브 보고 넷플릭스 보면 그게 힐링이고 그게 경험이지라는 생각을 했었다.
백패킹을 하며 고생하는 여행도 아니고 단순이 돈쓰고 놀러다니는 여행이 무슨 경험이 될까?
사실 놀러 해외여행가는 그 자체는 큰 경험이 아니라는 것에는 동의한다. 다만 비교 대상이 무엇인가에 따라서 조금 다를 것 같다. 만약 20대 때 아무것도 안하고 그저 집안에서 게임만 하고 앉아서 넷플릭스, 유튜브만 보고있는다면 여행이라도 다니면서 뭐라도 해보는 것은 아주 큰 경험이고 가치가 될 수 있다.
물론 그 시간에 일을 하거나 어떤 것을 배운다던가 한다면 그게 더 가치있는 경험이 될 수도 있다. 그렇지만 그 어떤 것도 하지 않는 것보다는 어딘가로 멀리 떠나서 혼자 스스로 있을 수도 있고 혼자 계획도 세워보고 말이 통하지 않는 사람과 대화해보려고 노력해보고, 어떤 것을 비교하면서 살 수도 있고, 고정되어 있는 세상과 환경에서 벗어나려는 이러한 시도들은 충분한 경험이 된다. 그것이 비록 놀기 위한 목적이라고 하더라도.
새로운 환경에서 그저 쉰다고하면 쉬는 것으로의 가치가 있을 것이고, 무언가 본다고하면 보는 것으로서의 가치가 있을 것이고, 추억을 남긴다고하면 남기는 것만으로도 가치가 있을 것이다.
그렇게 따지면 여행은, 돈에 여유가 있다면 비교적 가장 쉽고 편하게 경험을 얻을 수 있는 가성비있는 방법이라 할 수 있다.

2023 아쉬운 일

플러터로 앱을 만들기 시작하거나 런칭을 하반기에 목표로 했었는데 첫삽을 뜨기는 커녕 아직 시작도 못하고있다. 아이디어는 가지고만 있고 아직 다른 일들과 살아가는 일상에 치이다보니…는 핑계고 이번년도에는 기필고 플러터를 통해서 간단한 앱이라도 MVP로 만들어서 런칭하고 사용자들과 직접 의견들을 들어보고 소통해보는 경험을 가지고 싶다
역시나 책이나 블로그 글들이 당초 계획했던 목표수보다 모자랐다. 블로그는 연말에 몰아서 작성해서 그럭저럭 목표에 발끝은 닿았지만 책은 정말 컴퓨터 도서를 포함하더라도 눈물없이는 볼 수 없는 수치다. 최근 밀리의 서재도 구독하고 나름 독서의 습관을 다시 들여가고 있으니 2024년에는 좀더 발전한 모습을 기대해 봐도 좋을 것 같다.

2023 결산

올해도 작년에 이어서 회고에 한해동안 보았던 영화나 매체들을 보며 나름 재밌게 보았고 아쉬웠던 것들을 나누어서 한줄평과 함께 남기면 뭔가 권위는 없지만 연예 대상이나 연기 대상처럼 한해를 마무리하는 느낌이 날 것같다. 올해는 작년에 비해서 생각보다 감상하는 시간이 줄어들었던 것 같다. 외부 활동을 좀 늘렸던 것에 여파일 수도 있다.

2023 올해의 영화

최고도 최악도 없이 평이했지만 굳이 꼽자고 한다면 슬램덩크 극장판이 직접 영화관 가서 봤기도 했고 그 감동도, 현장감도 충분히 느낄 수 있었던 작품이다. 추억을 되살리는 향수는 덤.
최악은 넷플릭스에서 본 정이. SF에 대한 기대감 때문에 봤으나 CG도 짜치고 스토리, 개연성 모든 것들이 다 별로였다.

2023 올해의 TV Show

로키 시즌2가 올해 제일 재밌게 본 드라마다. 올해 초였다면 더 글로리였으나 역시 연예대상도 그렇고 한해의 하반기, 마무리 될때즈음에 인상이 남으면 좀더 고평가해주는 게 나에게도 작용했던 것일지도 모른다. 밤새서 한번에 다 볼정도로 침체기, 내리막길이었던 마블 작품중에 단연 돋보였던 작품이다.
이외에 무빙, 더 글로리 등 쟁쟁한 경쟁작들이 있었다.
엄청 최악까지는 아니지만 굳이 뽑자면 쿠팡플레이에서 보았던 유니콘이다. 배우들은 다 개성있고 연기도 잘했지만 각본이 너무 B급에 인터넷에서 긁어 모아둔 글들을 에피소드로 구성한 느낌 때문에 상당히 언밸런스하고 기괴했다. 그렇다고해서 유니콘이라는 소재에 장점이 부각된 것 같지도 않고. 좋은 배우풀을 가지고도 이러지도 저러지도 않은 것이 아쉬운 작품

올해의 책

올해의 책이나 최악의 책도 데이터베이스가 쌓일 만큼 읽지못해서 올해도 절차부심을 다짐하며 내년으로 이월.

작년 목표 점검

~~주말을 잘 활용할 것. 수동적인 자세가 아닌 적극적으로 모임에 참여하자!~~
매달 컴퓨터 서적 한 권과 책 한 권을 구입하자(다 읽든 안 읽든)
- 책 많이 읽기 최소 15권 이상
블로그 포스팅 최소 월에 2회 이상, 연 24회 이상 달성하기
~~차량 구매~~
근골격근 양을 키워서 72kg까지 찌우기
~~카프카 이해도 높이기~~
자격증 따기
- AWS 및 컨플루언트
영어 회화 배우기
상반기에 앱 만들어 런칭하기
~~테니스와 클라이밍 꾸준히 배우기~~

작년 목표이다. 영어 회화를 배우기로 한거는 올해부터 ChatGPT를 활용해서 한번 회화를 해보겠다고 막연하게 생각하고 있지만 아마 하반기쯤 본격적으로 하게될 것 같다. 이런식으로 또 내년으로 이월하게 되는 것은 아닐지. 그래도 희망적인 건 작년보다 많이 목표를 완수한 갯수가 늘어났다는 점이다. 책 읽기와 포스팅은 작년에도 역시 달성횟수를 채우지 못했지만 퍼스널 애자일 및 스프린트를 도입하게 되면서 꾸준하게 트래킹하기 시작했고 새로운 글쓰기 방법을 도입해서 올해는 아마 달성할 수 있으리라 기대한다.

그 이외에 테니스와 클라이밍을 꾸준히 배우기 시작한 것도 마음에 든다. 기존에 헬스만 다녔었는데 좀더 액티비티하고 유산소 가능한 운동을 하는 것도 뭔가 성격이나 다른 활동에도 긍정적인 효과를 가져올 것 같다.

앱을 만들어서 런칭하지 못한 것은 올해 꼭 이루도록 해야겠다.

새해 목표 및 다짐

그래서 작년 목표들을 발판삼아 이월되고 수정된 목표는 다음과 같다.

주말을 잘 활용할 것, 공부와 운동 내실을 다지는 시간으로
상반기에 AI 뉴스 봇 레터, 하반기에 투두 앱 만들어서 런칭하기
관련 내용 정리해서 컨퍼런스에서 발표
테니스, 클라이밍, 런닝 꾸준히 하기
책 많이 읽기 최소 20권 이상
블로그 포스팅 최소 월에 2회 이상, 연 24회 이상 달성하기

과감하게 정리해야할 부분들은 정리하고 부스팅해야할 부분은 목표를 더 높게 수정했다.
글쓰는 분야를 확장해야겠다. 블로그 포스팅이라고 한다면 여태까지 리뷰하거나 기초적인 내용, 개념적인 부분이나 공부한 걸 그대로 옮겨 적는 것에 지나지 않았다. 좀더 하나의 프로덕트를 보고 다각도에서 접근하거나 새로운 인사이트를 만들어낼 수 있는 포스팅이나 커리어나 인생 전반적인 느낀점 등 좀더 나의 개인적인 주관과 생각을 담아 생산적인 글쓰기를 하도록 다채롭고 뻔하지 않은 글쓰기를 하도록 올해는 노력해야겠다.
개인 프로젝트 상반기에 하나 하반기에 하나, 두 개를 작업해 연내 런칭하고 서비스하고 운영까지 하고 싶다. 관련해서 작업했던 내용을 컨퍼런스나 모임에서 하나의 주제로 묶어서 발표하는 것도 가능하다면 해보고싶다.
올해는 내실을 다지는 계기로 도약하기 위한 밑거름으로 만드는 한해로 꾸며봤으면 좋겠다.

책 카프카 데이터 플랫폼의 최강자 리뷰

은유 — Sat, 30 Dec 2023 20:19:45 +0900

무작정 카프카에 대해서 공부해보기

최근 회사에서 카프카를 프로젝트에 사용하게 되면서 여러 블로그나 도큐먼트들을 전전하며 파편적인 지식들만을 얻다가 카프카를 유지보수하게 될 일이 많이 생기게 되면서 기존 카프카의 기본적인 개념만 알고있었던 나는 실질적으로 어떤 아키텍쳐로 카프카가 활요오디는지 그리고 운영할 때 알아둬야하는 지식이나 주의해야 할 점은 무엇인지 등에 대해서 전반적으로 알아보려고 마음먹었을 때. 마침 이 책을 사두었던 것이 기억나서 꺼내서 다시 읽게 되었다.
다만 동명 저자의 최신 개정판인 '실전 카프카 개발부터 운영까지'라는 책 또한 구매하게 되어서 살짝 이 책의 위치가 애매해지게 되었는데, 그렇다고 아예 안읽을 수도 없어서 우선 가볍게 이 책을 읽고 다음으로 '실전 카프카 개발부터 운영까지'라는 책을 읽기로 결정했다.
'실전 카프카 개발부터 운영까지'는 이 책의 개정판이라는 개념보다는 이 책이 워낙 발행일도 오래전이고 카프카의 버전도 많이 바뀌다보니 최신의 경향과 기술을 담는 것에는 한계가 있어서 저자가 아예 새롭게 쓴 책에 더 가깝다.
기본적인 설계나 카프카의 구성 자체는 동일하기 때문에(최근에 카프카의 코디네이터로 주키퍼에서 크래프트로 변경된 것을 제외한다면)이 책으로 카프카 자체만 놓고 보기에는 부족함이 없겠다 싶어서 이 책을 먼저 읽기 시작했다.
다만 나와 상관없는 내용(설치 환경과 같은)이거나 너무 현재 사용하는 스택에서 동떨어진 것들은 그냥 이런게 있구나하고 읽고 넘어가는 식으로 진행하기로 했다.

카프카란 무엇인가?

카프카는 미국의 대표적인 비즈니스 인맥 소셜네트워크 서비스인 링크드인에서 처음 출발한 기술로, 대용량, 대규모 메시지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼이다.
카프카와 기존의 메시징 시스템과 가장 다른 특징 중 하나는 바로 디스크에 메시지를 저장하고 유지하는 것이다. 일반적인 메시징 시스템들은 컨슈머가 메시지를 읽어가며 큐에서 바로 메시지를 삭제한다. 하지만 카프카는 컨슈머가 메시지를 읽어가더라도 정해져 있는 보관 주기 동안 디스크에 메시지를 저장해둔다.(리텐션)

이 책을 통해 알게된 사실

카프카SQL에 대한 내용이나 카프카 스트림즈 아키텍처와 스트림 파이프라인에 나이파이를 활용한 내용 등이 나에 카프카 지식에 대해서 알고싶었지만 몰랐던 블랙박스의 영역이었는데 이 책을 통해서 간접적으로 체험하고 그 개요를 알게되었다.

이 책의 장점과 단점

장점

자바와 파이썬 등 다양한 언어로 예제를 보여줘서 각자 필요한 언어에 맞게 프로듀서나 컨슈머를 제작하거나 이해할 수 있다.
카프카 뿐만이 아니라 카프카를 활용하는 다양한 스택들을 보여줘서 어떤 환경과 프로덕션 레벨에서 카프카의 운영이 이루어지는지 간략하게 파악할 수 있다

단점

다양한 언어의 예제만큼이나 자신한테 필요없는 부분이 많다. 다 알아두면 좋지만 취사 선택하기에 환경 셋팅 부분이나 언어부분 등은 스킵해서 봐야할 부분들이 많다.
책이 출간한지 꽤 된 책이다보니 오래된 스택들이나 지금은 잘 사용하지 않는 프레임워크들이 등장한다.

PrestoSQL to Trino Migration 할 때 주의할 점

은유 — Fri, 22 Dec 2023 23:07:44 +0900

prestoSQL to Trino라고는 하지만 prestoSQL은 사실 Trino로 리브랜딩되기 전의 이름이므로 Trino의 메이저 업데이트라고 봐도 무방하다.
이 포스팅에서는 트리노의 메이저 업데이트 할 때 신경써야할 점들을 모은 내용이다. 사실 메이저 업데이트를 진행한 것은 아주 오래전이고 구성한 인프라별, Trino에 설치한 플러그인별로 증상이 상이하며 지엽적인 내용이 될 가능성이 높다고 생각해서 그 당시 포스팅으로는 작성하지 않고 있었던 찰나에 그래도 부분적으로 나마 나와 동일한 증상을 겪고 있을 사람들을 위해 기록을 남긴다.

메이저 업데이트를 하는 것보다 새로 설치하는 것이 낫다

항상 앞자리가 바뀌는 업데이트를 진행할 때마다 느끼는 생각이다. 업데이트를 진행하다보면 지금당장은 티가 안나더라도 어디선가 호환성이 안맞는 부분들이 생겨나고 그 호환성을 고쳐 나가보면 어느새 시간이 훌쩍 지나가 버린다. 그렇게 조금씩 마개조하고 뒤돌아보면 이럴꺼면 굳이 업데이트하는 것보다 다 날리고 새로 설치하는게 더 빨리 걸렸을 뻔 했다는 후회섞인 생각이다.
하지만 이미 새로 설치하기에 관련해서 얽힌 의존성들이 많아서 섣불리 리셋하기도 힘든 상황이다.
어쩔 수 없이 하나씩 맞물려있는 것들과 함께 수정해주자.

superset이 1.x 버전대인 경우

FROM apache/superset:1.1.0

USER root
RUN pip install sqlalchemy-trino
USER superset

superset 이미지 안에 sqlalchemy-trino를 설치해준다.
- 최신버전의 경우에는 이미 설치되어있음
연결시 기존 presto://이 아닌 trino://로 연결Tableau 데스크탑 및 Dbeaver 등 JDBC 드라이버 변경
https://trino.io/docs/current/client/jdbc.html

JDBC driver — Trino 435 Documentation

JDBC driver The Trino JDBC driver allows users to access Trino using Java-based applications, and other non-Java applications running in a JVM. Both desktop and server-side applications, such as those used for reporting and database development, use the JD

trino.io

Tableau 데스크탑 및 DBeaver 등 JDBC 드라이버 변경

https://trino.io/docs/current/client/jdbc.html

JDBC driver — Trino 435 Documentation

trino.io

기존 prestoSQL의 드라이버와 호환되지만 최신 드라이버를 사용하는 것을 권장
태블로 데스크탑 이용자
- Windows
  - C:\\Program Files\\Tableau\\Drivers 폴더 안에 위에 링크를 눌러 다운받은 jar파일을 위치
- Mac
  - /Users/<username>/Library/Tableau/Drivers 폴더 안에 링크를 눌러 다운받은 jar파일을 위치
DBeaver 이용자
- 기존과 커넥션 셋팅값은 동일하되 연결하는 데이터베이스만 Trino로 바꿔서 연결하면 자동으로 드라이버 다운로드가 진행

Hive connector(json-serde)

오류 코드:FAB9A2C5 Query failed (#20220120_055754_00024_sydpk): deserializer does not exist: org.openx.data.jsonserde.JsonSerDe 추출을 만들 수 없습니다.
태블로에서 발생하는 json 직렬화 문제 해결을 위해 json-serde jar파일을 build해서 hive폴더에 넣어준다.
https://docs.aws.amazon.com/ko_kr/athena/latest/ug/json-serde.html
https://github.com/rcongiu/Hive-JSON-Serde
https://github.com/trinodb/trino/issues/5602

GitHub - rcongiu/Hive-JSON-Serde: Read - Write JSON SerDe for Apache Hive.

Read - Write JSON SerDe for Apache Hive. . Contribute to rcongiu/Hive-JSON-Serde development by creating an account on GitHub.

github.com

Error when reading JSON table with TIMESTAMP: java.lang.ClassCastException: class java.sql.Timestamp cannot be cast to class jav

Hi, We are getting the below error when timestamps are null in hive json tables java.lang.ClassCastException: class java.sql.Timestamp cannot be cast to class java.lang.Number (java.sql.Timestamp i...

github.com

JSON SerDe 라이브러리 - Amazon Athena

Hive 및 OpenX 라이브러리는 JSON 데이터가 줄 바꿈 문자로 구분된 레코드와 함께 한 줄(형식이 지정되지 않음)에 있을 것으로 예상합니다. Amazon Ion Hive SerDe는 이러한 요구 사항이 없으며 Ion 데이터

docs.aws.amazon.com

hudi-bundle

hudi에서 만든 테이블을 보기 위해서 필요한 번들 라이브러리 필요
COPY ./hudi-trino-bundle-0.11.0-SNAPSHOT.jar /usr/lib/trino/plugin/hive/
해당 라이브러리 jar파일을 hive 라이브러리 안에 위치
https://mvnrepository.com/artifact/org.apache.hudi/hudi-trino-bundle

헤더 값 변경

기존 헤더와 trino로 리브랜딩되면서 바뀐 헤더 값 문제
351부터 HTTP 클라이언트 프로토콜 헤더값이 Trino로 변경되었다. 나머지 클라이언트에서의 요청이 기존 버전에 맞춰져있다면 먼저 이 부분을 변경해주고 일시적인 용도로만 변경하자
protocol.v1.alternate-header-name=Presto
다른 클라이언트들도 버전을 맞춰줬다면 다시 해당 옵션을 지워준다.
https://trino.io/blog/2021/01/04/migrating-from-prestosql-to-trino.html
https://trino.io/docs/current/admin/properties-general.html#protocol-v1-alternate-header-name

General properties — Trino 435 Documentation

join-distribution-type Type: string Allowed values: AUTOMATIC, PARTITIONED, BROADCAST Default value: AUTOMATIC Session property: join_distribution_type The type of distributed join to use. When set to PARTITIONED, Trino uses hash distributed joins. When se

trino.io

Migrating from PrestoSQL to Trino

As we previously announced, we’re rebranding Presto SQL as Trino. Now comes the hard part: migrating to the new version of the software. We just released the first version, Trino 351, which uses the name Trino everywhere, both internally and externally.

trino.io

늦은 두번째 트리노 밋업 참여 후기

은유 — Mon, 4 Dec 2023 22:13:32 +0900

세션만 달라지고 장고나 제공해주는 티셔츠, 음식 등은 지난번과 비슷했다. 두번째 세션까지 sk에서 주로 세션도 준비하고 했지만 다음번 세션부터는 다른 다양한 회사들이나 참여자들을 기다린다고 하니 다음번 세션이 좀더 기대된다. 사실 첫번째 세션이 좀더 원론적이고 좀더 미래지향적인 내용들이 많았어서 개인적으로 세션은 첫번째 세션이 더 마음에 들었다.

Trino를 위한 실시간 Kappa 아키텍처

트리노 소개

페더레이트를 통해 이종디비간 연산
분산 쿼리 엔진으로써 대용량 데이터 쿼리 효율적 처리

실시간 Kappa 아키텍처

람다 아키텍처는 코드 중복과 시스템 복잡도 증가 하지만 카파 아키텍처는 코드 중복 제거와 복잡도 감소
목표
- 데이터 정합성
- 낮은 지연 시간
- 높은 처리량
- 대용량 데이터 쿼리 지원
이벤트를 트리노 카프카 커넥터를 통해 읽음→한계가 있음 낮은 저장 효율로 장기 데이터 저장소로 활용하기 힘듬
카프카 티어드 스토리지를 통해 낮은 저장 효율 완화→하지만 제한적인 predicate push down으로 낮은 조회 성능으로 한계가 있음
실시간 처리 엔진을 통해 쓴 테이블 포맷을 트리노가 읽도록 하는 것으로 문제 해결
실시간 처리 엔진 목표
- 데이터 정합성
- 낮은 지연 시간
- 높은 처리량

스파크 스트리밍 vs 플링크
- Exactly Once 보장
- 높은 지연시간 v.s 낮은 지연시간
벤치마크상 플링크가 낮은 지연시간을 보임
체크포인트
- 특정 시점의 실시간 어플리케이션의 상태
- 장애 복구 시 마지막 체크포인트 사용
- 체크포인트 주기마다 커밋→체크포인트 주기→지연 시간 비례
체크포인트 딜레마를 해소하기 위해서 트랜잭션 테이블 포맷이 필요함→아이스버그, 후디, 델타레이크→아이스버그 선택
z-value
- 정렬 대상 필드를 사전 순서 이진 표현으로 변환 후 변환된 이진 표현을 interleaving한 값
계층 구조의 데이터 쿼리→sort
여러필드가 복합적으로 유사한 데이터 쿼리→z-Order

읽기 성능 극대화

데이터 양을 줄이는 대신 읽기 성능을 극대화하는 경우
RediSearch Connector를 통해서 트리노에서 테이블 형태로 ㅂ임
하이브쿼리 대비 157~만이천배 성능 차이

Trino 속 Online aggregation

online aggregation이란?

어그리게이션이란 여러 행의 값을 입력 받아 하나의 결과값을 출력하는 함수
- count, sum, max …
데이터 증가하면 속도가 느려지는 문제가 있음
메모리 부족, 디스크I/o, 네트워크 대역폭 부족 등 다양한 원인
이런 문제들을 해결하기위해서 등장한 온라인 어그리게이션→데이터를 실시간으로 처리하면서 중간결과를 저장하여 복잡한 집계연산을 효율적으로 수행하는 기술

online aggregation의 예

평균구하는 예

Trino 속 online aggreation

각 워커의 State들이 하나의 워커에 모여 combine. out이라는 값이 코디네이터에 전달되어 return
분산 병렬 연산
실시간으로 처리, 중간결과를 저장, 분산 병렬 연산

Non-disruptive update Trino cluster

업데이트하기 두렵다…트리노에서 지원해주지 않는다…
Lyft/Presto gateway
- zero downtime은 불가능하고, 특정 BI에 연결된 presto만 자원을 사용함
- 차라리 proxy load balancing router를 직접 만들어서 처리하자해서 만듦
nextUri가 없다면 통신 반복 종료
canary deployment
- Worker level graceful shutdown 진행
쿠버네티스를 사용하고 있다고 하셨는데 쿠버네티스에서 블루-그린 디플로이먼트를 제공하는데 사용하지 않은 이유? 아까설명한 자원문제때문인지→기존 쿼리를 실행한 사용자가 실패하기 때문에 중단없이 배포하고 싶었음

제3회 Kakao Tech Meet 늦은 후기

은유 — Fri, 1 Dec 2023 19:49:08 +0900

예쁜 사내 카페테리아 인테리어

판교 카카오 본사에서 카카오 테크밋을 한다고해서 주제도 마침 관심있는 카프카세션도 있고 나머지도 흥미로운 주제들인 것 같아서 참여하기로 했다. 하지만 아뿔사 내가 판교에 간다는것, 그리고 판교에서 주차를 한다는 것은 미처 상상도 하지 못했다. 따로 주차지원이 되는건 2시간까지가 한정이고 그 이후로는 살인적인 요금을 지불해야하므로 급하게 모두의 주차장을 통해서 일일권을 끊어서 사용했다.

근처 공용주차장을 믿고 무장정 차를 끌고갔는데, 판교의 평일 공용주차장은 이용을 아예 못한다고 보면된다. 그렇다고 대중교통을 이요하자니 조금 애매하고...아마 다음부터 판교에서 이런 밋업을 진행하게된다면 이러한 여건상 앞으로 가기 조금 꺼려질 것 같다.

그외에 카프카 세션 발표가 내가 자주 블로그와 유튜브, 책을 통해 익히 알고있는 최원영님이었다는 사실과 끝나고나서 개인적으로 몇가지 질문을 주고받았던 것들이 기억에 남는다.

신뢰성 있는 카프카

애플리케이션을 만드는 3가지 방법

정확히 한번 (exactly once)를 달성하기 위한 노력

카프카 소개

스트림처리에 특화
프로듀서 - 브로커 - 컨슈머

방법1)프로듀서의 메세지 전달 신뢰도

네트워크 장애로 acknowledgement가 전달되지 않아 record가 중복 적재될 가능성이 있음
멱등성 프로듀서를 통해서 해결→ ENABLE_IDEMPOTENCE_CONFIG=ture로 설정
3.0부터는 true가 default값
브로커가 PID와 seq를 가지고 있다가 중복 적재 요청이 오면 적재하지 않음

방법2)토픽 to 토픽의 메시지 전달

토픽 컨슈머에 장애시 중복이 발생할 가능성이 있음
트랜잭션을 사용해 아토믹한 과정을 묶어줌
트랜잭셕 프로듀서 설정 및 트랜잭션 프로듀서 초기화→전송이 완료된 토픽과 커밋을 묶음
일반적으로 컨슈머에서 커밋하지만 이런 경우 sendOffsetsToTransaction에서 커밋
앤드투앤드까지 레이턴시가 증가할 가능성이 있음

컨슈머의 중복 적재 방지

유니크 키를 활용한 멱등성 컨슈머
- 유니크 키를 지원하는 데이터베이스에 적재할때 유용
Upsert를 활용한 멱등성 컨슈머
- 중간 결과값도 저장(upsert 형식으로), 최종 데이터도 저장
- 몽고디비에서 지원하는 방식
Write-ahead log를 활용한 컨슈머
- WAL파일을 활용해 적재되었는지 다시한번 확인하는 로직
- 복잡해질 수 있는 단점

내부 활용 사례

스마트 메시지 서비스
- 몽고디비에 텀블링 윈도우 단위로 주기마다 모델링 계산을 통해 타겟팅 개발
- upsert방식을 통해 중복방지

마무리

가장 중요한 것은 어느 정도 전달 신뢰성을 가질 것인가 정말로 필요한가? 장애로 판단하고 넘어갈 수 있는가를 종합적으로 판단

폭증하는 카카오톡 트래픽에 대처하는 방법

카카오톡의 메시지

전송

최대 44.8k의 메시지 전송 모든 요청을 합치면 62만건
신년이나 월드컵 등의 이벤트 시기에 메시지 트래픽 폭증

자동 대응 시스템 구축

백그라운드 로그인→사용자가 서버에 접속하지 않는 경우 푸시 전송 푸시를 받으면 tcp연결로 로그인 유지하며 로그인 없이 메시지 확인 가능
2016 경주 지진 발생 지진 여파로 카카오톡 장애 발생→백그라운드 로그인 때문에 발생→지진 안내문자로 백그라운드 로그인 수행→카카오톡 로그인 서버 접속 시도→전국민이 백그라운드 로그인 시도→모든 스레드가 로그인 요청으로 할당으로 메시지 전송 실패
예측할 수 없는 이벤트에 대해서 자동 대응 구축 필요성
활성화된 스레드 비율로 부하 레벨을 할당→부하 레벨에 따라 백그라운드 로그인 차단 비율을 나눠서 처리
이후 포항 지진에서 자동 대응 시스템 테스트 유동적으로 대응해서 메시지를 원활하게 보낼 수 있게 되었음

교통 관리 시스템 구축

새로 도입한 시스템에서 장애 발생하면서 전체 서버군으로 장애가 퍼짐
백그라운드 로그인이 아니라서 트래픽을 막을 수 없었음
자동 대응 시스템만으로는 해결 불가→요청 별 전용 도로를 만들면 되지 않을까?→모든 스레드가 로그인을 점유하지 않도록 처리
매니저라는 객체가 연결, 메시지 전송, 채팅방 진입 등의 요청을 스레드 할당→각 요청들이 골고루 처리

월드컵 도중 트래픽 변화

카타르 월드컵에서 조규성이 동점골 넣을때 트래픽이 가장 높았음
교통관리 시스템이 있어서 당시에는 장애발생이 나지 않았음
처리 실패는 올랐지만 전체 시스템 장애로 번지지 않음

마무리

당장에 필요한 트래픽만 처리하는 것이 중요
자원을 요청별로 배분하여 특정 요청이 점유하지 않게 해야 한다
트래픽 처리를 위해 아직 개선할 여지는 많이 남아있다

DKAPTCHA - 지도 이미지와 음성을 활용한 어뷰징 방지 전략

DAPTCHA 개발 배경

봇에 의한 트래픽이 전체 웹사이트에 30프로에 해당
계정 탈취 시도, 판매 및 범죄에 재활용
실시간 모니터링을 통해 사용자 피해 방지 진행중

DKAPTCHA란?

카카오에서 자체 개발한 켑챠, 봇인지, 사람인지 판단하는 켑챠 기술의 일종으로, 주 용도는 스팸, 보안 위협, 웹 스크래핑, 서비스 악용 방지
기존 켑챠들은 니즈를 충족하지 않음, 기술적 독립성 확보, 기술 내재화
완전한 기술적 제어를 위해 개발
사용자 시인성 저하 최소화, 사용자 친숙성 고려, 카카오 어뷰징 대응 맞춤화한 켑챠
지도 데이터 활용 재생성 소스 음성에 다양한 왜곡을 가해 음성 합성

매커니즘

지도 이미지에 POI라는 지명데이터를 넣고 봇에 인식을 저해 할 수 있는 하얀 워터마크를 추가→인식 방해 이미지 처리를 통해 최종적인 켑챠 이미지 완성
여러 OCR을 통해 인식율을 확인, 고도화 진행
워터마크는 잘 인식하고 주요 POI는 잘 인식 못하는 방향으로 인식률 검사하고 내부적으로 여부 판단

사용자 사용성에 대한 고민

켑차를 만났을 때 서비스 이탈율에 영향을 미칠 수 있음
맵 데이터가 익숙한 경험의 연결로 사용자에게 친숙한 경험을 기반으로 한 켑챠 제공
시각 장애인을 위한 켑챠 지원

향후 발전사항

ML을 위한 퀴즈의 고도화
- 주변 지명과 유사도가 높은 워터마크를 생성
- 유사도 높은 지명과 워터마크를 배치하고 관련한 문제를 냄으로써 어뷰저 혼동
나중에 히스토리가 쌓였을 때 정상 유저와 어뷰저의 행동 패턴을 분석하고 필터링 진행

데보션 카프카 사용자 밋업 후기

은유 — Thu, 30 Nov 2023 18:32:45 +0900

첫번째 세션 발표자분께서는 코로나로 인해서 불참하시게 되어서 세션이 취소가 되었다. sk에서 데보션을 런칭하게 되면서 활발한 사용자 유도를 하기위한 독려 행사도 겸하기도 하는 듯 많은 경품행사와 프로모션이 진행되었다. 나는 그 많은 기회를 다 비켜가면서 당당히 하나도 상품을 받지 못했다.(...)

내가 애용해서 읽고있는 카프카책의 저자이신 고승범님께서 그곳에 계실줄 알았으면 책을 가지고 가서 사인을 받을 걸 그랬다. 내심 아쉬웠던 부분.

세션은 전반적으로 무난했으나 첫번째 세션이 취소되어서 조금 아쉬움 마지막 세션을 제외하면 카프카에 중점적으로 하는 세션이라기보다는 카프카가 곁들어진 느낌.

두번째 세션같은 경우는 인증/인가에 대한 개념을 익히기에는 좋았으나 카프카에 실 적용하기에는 규모에 따라서 오히려 허들이 될수도 있겠다는 생각이 듬, 다양하고 큰 조직에서는 필수적으로 적용해야하겠지만 우리처럼 내부적으로 사용하거나 부분적으로 사용하는 조직에서는 오버스펙이라는 생각이 들음.

다음에 또 진행하게 된다면 참여할 용의가 있음

1000만 회원, MAU 500만을 위한 빅데이터 아키텍처

무신사 데이터 아키텍처

거래액과 회원수가 늘면서 데이터 아키텍처 변화의 필요성을 느낌
문제가 바로 해결 불가능한 문제는 구조 개선을 통해 문제 해결(그 과정에서 아키텍처 의사결정 기록을 남김)
긴 기간의 데이터를 운영 DB에 바로 접속해서 조회→거래액 증가에 따라 점점 느려짐
- 이를 DB의 데이터를 파일 기반으로 저장하여 분산 처리 할 수 있는 환경을 구축
- S3와 EMR을 사용해서
near-realtime 추천
- 개발할 수 있는 시간이 없어서 SASS 서비스를 통해서 API GW + Kinesis를 통해 실시간 데이터를 수집
API GW + Kinesis가 사용량 늘어남에 따라 비용 급증 오토 스케일이 동작하지만 타임아웃 다수 발생
- API를 직접 개발하고 Kinesis를 MSK로 대체로 개선

물리적 데이터 아키텍처 & 논리적 아키텍처

데이터브릭스를 사용해서 델타레이크와 유니티 카탈로그로 데이터 관리(사내 직원 수 증가에 따른 관리 용의성)
데이터 플랫폼을 잘만들면 데이터를 더 잘 활용할 수 있다 그러기 위해서 데이터의 구조를 잘 만들어 두는 것이 중요하다
데이터 거버넌스를 통해 논리적 데이터 아키텍처를 구축
오브젝트+액티비티들을 정형화해서 저장→메트릭(액티비티로 부터)와 디멘전으로 나눔

더 많은 동료가 데이터에 접근하게 하기

팀 빌딩을 위해 기존 스칼라 스파크 코드를 pySpark로 변경
PySpark Wrapping으로 json을 통해 ETL하도록
convention을 정해서 airflow task id로 어떤 코드인지 유추가 가능하도록 함
SQL, Python Notebook, BI 환경 제공
표준 가이드와 카탈로그 만들어놓음

Q&A

데이터 브릭스를 사용하면서 권한 관리가 편함, 오픈소스 기반이어서 문제해결하기도 편함
환경적인 이유때문에 GCP의 빅쿼리가 아니라 spark를 활용. 다양한 테이블을 조인하고 페더레이트하는 기능이 마음에 들었음
해쉬된 아이디로 실명 데이터 처리
데이터 카탈로그와 거버넌스를 유니티 카탈로그로 처리
파이어베이스 gtm으로 액티비 데이터 수집

카프카 클러스터 인증/인가의 중요성

인증 인가의 중요성

Producer
- 특정 토픽/파티션에 추가할 메시지를 생성하여 브로커로 전송
- 관련 없는 토픽에 포맷이 다른 메세지를 추가하면?
Consumer
- 특정 토픽/파티션의 메시지를 읽어 감
- 다른 컨슈머 그룹에 참여하여 메시지를 가져가면?
CLI 도구
- 누구나 다운로드 받아서 사용 가능
- 토픽/클러스터/클라이언트 설정 조회/변경
- 토픽 생성/변경/조회/삭제
- 컨슈머 그룹 오프셋 조회/변경
- 인증/인가 구성이 없으면 누구든 모든 기능을 사용할 수 있음
- 컨슈머/프로듀서가 사용하고 있는 토픽을 삭제하면?
휴먼 에러를 방지하기 위해서 인증 인가가 필요함

클라이언트 인증 프로토콜

인증 없음
- PLAINTEXT
  - 클라이언트(프로듀서, 컨슈머, 어드민 클라이언트) ↔ 브로커간 평문 통신
- SSL
  - 클라이언트 ↔브로커간 암호화 통신
인증 사용
- SASL_PLAINTEXT
  - SASL 인증 프로토콜 평문 통신
- SASL_SSL
  - SASL 인증 프로토콜 암호화 통신
SASL(Simple Authentication and Security Layer)
- 인증 메커니즘을 협상하고, 인증 모듈에 인증 과정을 위임하는 프로토콜

인증 구성 : out of the box

SCRAM 인증 메커니즘
- 챌린지 값들을 가지고 값을 만들어서 서로 비교
- 네트워크 상에서 유저네임과 패스워드를 주고받지 않음
- 주키퍼에 계정 정보 보관→kraft모드에서는 카프카 스토리지에 저장→계정 추가 및 수정 삭제 용의
- 보안성이 확보 되어 있으며 카프카와 가장 잘 통합되어 있음
- CLI 도구 및 API 제공
OAUTHBEARER 인증 메커니즘
- KIP-768을 통해 kafka 3.1.0에서 릴리즈
- clientcredentials만 지원하는 것이 단점
- 브로커 구동시 OIDC서버에서 JWKS 키셋을 가져옴
- 로그인시 토큰 제출하고 키셋에서 받은 키와 대조해서 OIDC서버에서 발급한 토큰인지 확인 validation 통과되면 접근 권한 부여
SSL/TLS or mTLS
- Secure Socket Layer
  - 네트워크를 통한 모든 송수신 데이터를 암호화
  - 인증과는 별도로 분리된 레이저
  - 카프카 브로커용 인증서 필요
  - 제로카피 기능을 못써서 좀 느려질 수 있음
  - 암복호화로 인한 CPU 부하 증가
- SASL과 결합하여
  - 여러 인증 메커니즘과 결합하여 사용가능
  - SASL_SSL/(GSSAPI,PLIN,…)
- mutual TLS
  - 양방향 TLS 인증
  - 클라이언트용 인증서 필요
  - 클라이언트 인증서를 서버에서 확인
- kafka SASL/OAUTHBEARER 인증 구성 메뉴얼 공개

인가 구성

ACL
Delegation Token(위임토큰)
- 인증 방법중에 하나

Confluent Kafka x Google Cloud Tech Day 정리

은유 — Wed, 29 Nov 2023 16:55:55 +0900

6월달에 갔었던 행사라서...사실 지금 올리는게 무색하긴 하지만 정리 및 복기하는 겸 겸사겸사 올리게 된다. 카프카에 대해 막 관심이 올라가던 시점이라 신청해서 갔었는데 사실 전반적으로 아는 내용이기도하고 막 건질만한 내용은 크게 없었던 것 같아서 그냥 열심히 컨플루언트 홍보하는 내용만 있어서 다음부터 카프카를 목적으로는 가고싶은 생각이 크게 안들것 같은 행사였다. 컨플루언트쪽에서 주최한거라서 당연한 거긴 하다만

그래도 중간에 퀴즈같은게 있어서 맞춰서 책 한권을 꽁짜로 받아서 기분좋은 마음으로 집에 오긴했다.

데이터 스트리밍을 통한 실시간 데이터 활용 by Confluent

개요

19년도부터 구글 클라우드가 GCP 마켓플레이스에서 제공 및 과금 파트너쉽
맞춤형 추천, 실시간 거래, 도착 예상 시간 등 실시간 데이터 스트리밍이 필요한 시대
스트림 데이터를 처리하기 위해 아파치 카프카를 많이 활용함
기존 데이터 플랫폼
- 다른 시스템과 통합하기 어려운 경직된 아키텍처
- 비싼 초기 비용과 지속적인 유지보수 비용
- 제한된 분석 기능으로 인해 비즈니스 인사이트 발견이 느림
클라우드 기반 데이터 플랫폼
- 스토리지와 컴퓨팅을 분리하고 사용량 기반 요금제를 활용하여 TCO 절감
- 전반적인 유연성 및 비즈니스 민첩성 향상
- 머신 러닝과 같은 고급 기능을 갖춘 확장 가능한 분석으로 실시간 의사 결정 지원
실시간 처리, 사기 감지, 데이터 거버넌스
컨플루언트 Saas, 설치용 셀프매니지드 제공(클라우드나 온프레미스에 설치)

컨플루언트 클라우드를 왜 사용해야하는가

클라우드 네이티브(KORA엔진, 아파치 카프카 소스와 다름)
멀티 리전 및 AZ를 통한 99.99% uptime SLA
코라엔진
- 주키퍼대신에 KRaft로 구현됨
- kafka 클러스터를 더 많은 파티션과 토픽으로 확장 가능해짐
- 안정성 및 장애 조치 성능 향상
- 브로커를 늘리지 않고도 백엔드에 있는 오브젝트 스토리지를 써서 유연성을 높힘(스토리지 분리)
대부분의 카프카 비용은 네트워크비용에서 상당히 많이 들어가게됨
데이터를 검증하는 데이터 퀄리티 기능이 포함
플링크 인수함→컨플루언트에 플링크의 sql서비스를 24년도에 어나운스할 예정
Azure, AWS, GCP 등 다양한 클라우드나 리전에서 사용할 수 있음

구글클라우드 빅쿼리를 활용한 실시간 데이터 분석

Citizen Data Scientist
- 현업에서 업무를 아는 사람이 데이터 분석을 하는 시티즌 데이터 사이언티스트가 필요함
ai나 머신러닝이 쉬워져야한다는 것이 트렌드와 방향성
서버리스 형식으로 fully managed 형식으로 제공
Cloud DataFlow는 분산처리 프레임워크 like spark
전통적인 DW와는 다르게 스트리밍 데이터를 초당 기가바이트를 넣을 수 있다
전통적인 DW는 정제해서 넣어야하는데 빅쿼리는 원본 그대로 넣고 JSON 등 다양한 형태로 가져다 쓸수있다
검색인덱스 기능을 넣을 수 있다(bigsearch)

3회 수군수군 데이터엔지니어 밋업 후기

은유 — Sat, 25 Nov 2023 22:41:40 +0900

수군수군 2회차에 이어서 3회에도 참여했다. 지난회와 조금 다른점들이 조금 눈에 띄었는데 지난회에 비해서 좌석이 다소 협소하다는 점과 기존에 피자와 치킨이었던 것에 비해 서브웨이로 단촐(?)하게 차려진 음식이 바뀌었다는 점, 그리고 생각보다 발표하는 내용과 주제들과 수준이 이전에 비해서 상당히 깊고 심오해졌다는 점이다.

전에는 POC같이 그냥 소개하는 수준의 내용도 부담없이 발표하고 토론하는 분위기었다면 좀더 실질적이고 경험적인 내용으로 변했다. 덕분에 나도 한번 발표를 해볼까 싶다가도 수준미달이 되어버릴 것 같은 두려움에 금새 그 마음을 접어버렸다.

기존에는 자리가 테이블로 잘 나뉘어져있어서 편하게 노트북하면서 세션들을 들을 수 있었는데 쇼파자리랑 테이블자리가 나뉘어져있고 모두 각자 모여서 이야기하기는 좋지만 스크린을 보고 앉기에는 다소 불편한 구조로 되어있고 와이파이도 없어서 일단 메모장에 오프라인으로 메모했다.

그래도 사실 세션보다는 네트워킹이 주 목적이었기 때문에 그전에 비교해서 아쉽다뿐이지 막 크게 거슬리는 단점까지는 아니었다. 대신에 이번에는 다양한 굿즈들을 받을 수 있어서 좋았다.

입장해서 네임택이랑 먹을 것, 굿즈 등을 받고나서 어디에 앉을지 고민하고 있던 찰나에 때마침 전에 카카오 테크밋업때 뵈었고 익히 저서와 유튜브, 블로그 등을 통해 잘 알고있던 최원영님이 계셨다. 저번에 판교에서 한번 인사를 나누었던 적이 있어서 반갑게 인사를 나누고 그 옆자리에 앉아서 세션들을 감상했다.

브라우징 코파일럿 RAG 도입기

브라우징 코플릿→ 보고있는 페이지 요약
파인튜닝, RAG를 활용 고민
새로운 컨텐츠에 즉각 대응을 위해 RAG를 선택
유튜브 자막 리스트로 전달
HTML은 특정 태그 제거 후 전달
PDF 전체 텍스트 전달
전체 내용이 필요한 것이 아니고 llm context 크기 제한 때문에 청크 조각을 냄
OpenAI 임베딩 API 호출이 제일 좋은편임
질의문 키워드 추출(LLM사용), 백터 검색+키워드 검색=하이브리드 검색

챌린징 했던 부분

청킹 사이즈
- 크게 쪼개면 임베딩 생성 비용 문제
- 정확도와 비용 사이의 트레이드오프
IO 작업 문제 없이 처리
- 오리지널과 청크 소스 동시에 async하게 동작
- OPENAI RPM limit에 맞춰 제한→ 엘라스틱서치의 스루풋 또한 조절
검색 키워드 제대로 뽑기
- 유저가 질문에서 특정 키워드를 입력하지 않는 이상 벡터서치로 넘기고있음

컨텐츠에 대한 이해

계층 구조 검색
- 청크를 트리 형식으로 나눠서 자름
- 레벨별로 추상화
- → 광범위한 질문에 따라 레벨별로 인덱싱해서 찾음
멀티 벡터 검색
- 예상 질문 만들어서 임베딩
- 오는 질문에 대해서 추상화된 질문을 만들고 추상화된 질문과 구체적인 질문으로 검색을 한다

kafkaStream을 이용한 changeLog 따라잡기

광고에 필요한 소재를 신디케이트하는 일을 하고있음
대형 쇼핑몰들의 상품들을 구글 ads account의 ad 그룹에 상품들을 매칭(Item matcher)
item matcher와 product를 실시간으로 매칭(M:N)

OLAP 개념과 서비스 소개

OLTP와 OLAP
- oltp 동시성 보장 crud, indexed
- 트렌젝션이 아닌 aggregate에 특장점
- oltp에서 olap으로 넣어주는 형태
큐빙
- 멀티 디멘전
- MOLAP, ROLAP, HOLAP
상용 OLAP 솔루션
- redshift, athena
- bigQuery
- Azure Synapse Analytics
레드시프트는 아테나에 비해 10배 빠른 성능 최적화에 따라 성능이 달라짐
RPU 최소 32 기준 시간당 14달러→ 월 1000만원 가량→ 비쌈....
킬린→ 하둡온리, 킬린과 드루이드가 양대산맥이었음→ 하둡기반이었기 때문에
클릭하우스는 다른 서비스와는 다르게 shared-Nothing Architecture로 단일 솔루션
- 다이나믹 메터리얼스 뷰를 제공해 소스를 계속 부으면 계속 어그리게이션된 뷰를 제공함 대신 새롭게 확장하기가 쉽지않음
- 카프카를 통해서 인입을 받을 수 있지만 배치에 더 좀 더 적합
- 이베이, 우버, 디즈니에서 자주 사용
드루이드
- 확장 가능한 형태의 분산 시스템
- segment→ 타임시리즈 단위로 잘개 쪼갬 큐빙을 미리하고 결과물을 뿌려줌
- 클러스터 형태기 때문에 리소스 자원이 커짐
Pinot
- 세그먼트 형태로 데이터 저장
- 드루이드보다 다양한 인덱서를 제공해서 그에 따른 쿼리속도 제공
세가지 비교하자면→클릭하우스는 실시간을 보장할 수 없으며 확장할 때 불편하지만 커뮤니티가 가장 활발
- 드루이드는 아키텍쳐에 대한 이해가 있어야하고 실시간에 최적의 성능을 낼 수 있음→ 유지보수 관리에 대해 스타트업같은 작은 규모의 회사에서는 힘듦
- pinot 드루이드와 유사하지만 좀더 단순화됨 복잡한 쿼리에 대한 처리가 제한적

네트워킹 시간이 오히려 짧게 느껴짐

다양한 회사들로 부터 인프라 구성은 어떻게 했는지, 경험담 같은 것들을 주고받으면서 시간이 빠르게 지나갔다.
이번에는 명함을 많이 가져가서 다행이 많이 뿌려서 좋았다.
세션 시간에 비해서 네트워킹 시간이 짧게 느껴질 정도로 시간이 부족했다.
발표와 네트워킹 시간의 다양한 사람들을 보면서 나의 부족함을 깨닫고 최근에 너무 자기개발에 부진했던 게 아니었는지 다시한번 생각해보는 계기가 되었다.
나를 일깨워준 여러가지로 가길 잘했다고 생각하는 모임이다.

토스 slash23 데이터 세션 정리

은유 — Sat, 1 Jul 2023 08:20:54 +0900

은행 데이터플랫폼 오픈소스로 전환하기

기존 정보계 시스템의 문제점

토스뱅크는 초기에 타은행 시스템 구조를 그대로 따와서 구축이 되었고, 타 은행들과 동일하게 계정계, 채널계, 정보계 세가지 영역으로 구성됨
mysql뿐만 아니라 MongoDB같은 NoSQL도 하둡으로 보내 분석에 활용하고 있다
보고서를 위해서 이런 데이터들을 오라클엑사로 다시 보내야하는 문제가 있어서 불필요한 데이터 이동이 생김
오라클 엑사의 비용이 하둡에 비해 10배나 높았으므로 하둡으로 시스템을 통합하려는 목표

기존에 잘 돌고 있는 정보계 시스템을 옮기는 방법

Concern & Challenge
1. 기존에 잘 돌고 있는 것을 무엇으로, 어떻게 대체할 것인가
2. 기존 시스템과 동일한 값임을 어떻게 보장할 것인가
3. 이미 구축한 상황에서 옮기는데 드는 비용이 더 클 것같다

토스뱅크에서는 쿠버네티스에서 대부분 환경이 구성되어있기 때문에 스케일링이 쉬움

대부분의 DW에서는 PK만 지원되도 무방하므로 스토리지 부분에서는 HDFS와 KUDU를 조합해서 오라클엑사를 대체

시중에 나와있는 솔루션들은 db에 부하를 적게주기 위해서 파일베이스 기반으로 읽음

xStream API가 Dictionary Building 및 Logmining Session Spawn으로 Live 환경에서는 Throughput이 약 20배 이상까지도 차이가 난다

에어플로우를 사용하여 공통 DB를 통해 이기종간 태스크 선행조건을 확인했다.→1번문제 해결
오라클에서 공통마트를 가져와 하둡에서 정합성을 검증하는 정합성 batch를 돌려서 주기적으로 돌림→정합성 batch를 1~2주간 확인하면서 틀리지 않는걸 확인하면 다시 하둡데이터를 오라클로 이관
처음에는 임팔라로 이관하는 방법을 생각, 하지만 임팔라는 암시적 형 변환이 지원되지 않아서 숫자형 변수를 하려면 dicimal로 꼭 캐스팅을 해줘야함. 그래서 많은 쿼리에 캐스트를 해줘야했고 몇 지원안되는 함수 때문에 마이그레이션 비용이 컸음
반면 스파크는 암시적 형 변환이 지원되고 오라클 문법 대부분 지원됨(단, Merge Into는 delta Lake, Hudi, IceBerg와 같은 스토리지 필요→100개 넘는 배치 프로그램 바꾸는데 1명의 개발자가 1달도 안걸리는 등 임팔라 대비 비용 축소

토스뱅크에서는 GoCD를 통해서 제3자검증, 서비스/배포 책임자 검증, 배포 이력 관리를 하고 있다

앞으로 방향성

차세대 DW 시스템(후디, 아이스버그 등)
CDC 시스템 고도화(noSQL CDC 구축 예정)
스쿱을 대체할 Nifi 도입 준비

Kafka 이중화로 다양한 장애 상황 완벽 대처하기

토스증권에서 카프카가 어떻게 활용되는지

사용자에게 실시간으로 제공하는 거래소정보, 로그, 분석 등에 카프카를 활용하고 있음
카프카 자체가 가용적으로 디자인된 아키텍처이고 모니터링으로 대응 프로세스를 통해 클러스터의 일부 노드 장애는 극복이 가능하지만 IDC 전면 장애의 경우에는 IDC 이중화가 안되어 있다면 치명적임
- 증권사는 IDC 장애에 대응하도록 메인 IDC와 떨어진 IDC에 DR(Disaster REcovery)를 구축해야함
DR은 보통 Active-Standby로 구성함 Standby가 장애시 Active로 전환
- 하지만 장애 상황이 발생했음에도 Standby를 잘 관리해주지 않으면 버전문제나 장애가 해결이 안되는 경우가 발생하기 때문에 토스증권에서는 평소에도 Active-Active로 이중화 구성해서 사용중

카프카의 STATE의 일관성을 어떻게 유지할지 고민해보고 이중화를 구성하는 것이 포인트

이중화를 통해 양쪽 IDC로 유저의 트래픽이 각 50%씩 나눠 가지고 있음
특이한 건 한쪽 IDC만 컨슈머가 존재함→메세지 미러링을 통해서 전체 합치면 메세지양이 200%가 되기때문에 컨슈머가 양쪽에 붙으면 두 배 중복해서 소비하는 상황을 방지하기 위해서

모니터링

클러스터에 발생하는 메트릭 정보를 프로메테우스로 수집하고 타노스 룰러를 이용해서 정의한 조건이 충족되면 알림을 주는 방식으로 모니터링 구현
클러스터 로그는 엘라스틱서치를 통해 에러 로그 발생을 엘라스틱얼럿으로 받고있다
현재 시계열 데이터의 이상 징후를 탐지하는 머신러닝 모델도 개발하고 있음

대규모 로그 처리도 OK! Elasticsearch 클러스터 개선기

토스증권에서는 하루 수십억건 로그를 엘라스틱서치로 검색하고 분석하고있음
- 일일 6TB, 약53억 건
- 90일 리텐션 570TB, 4800억 건
거의 대부분 로그 검색과 분석은 최근 보름 이내의 로그를 대상으로 하기에 Hot-Warm 아키텍처로 도입해서 운영하기로 함→Hot Node보다 3배 더 큰 디스크를 가진 Warm Node를 구성 후 생성된 지 오래된 인덱스는 Warm 이동하도록 인덱스 생명주기 관리 정책을 구성함, 90일 리텐션 설정

엘라스틱 서치 튜닝

점점 적재되는 양이 많아지면서 클러스터 내부 오류가 잦아짐
- 매무 많은 Fielddate 메모리 사용
- 빈번한 Long GC 발생
- Stop the World
- 인덱스 맵핑에서 일부 필드 설정에 필드데이터 옵션을 잘못 사용한 경우
- mapping Explosion
  - 입력으로 들어오는 json key가 많으면 동적으로 스키마를 업데이트하는 과정에서 리소스를 많이 사용해 클러스가 불안정해짐
  - 따라서 동적 필드 매핑을 사용하지 말고 구조화되지 않은 문자열이 들어가는 필드는 text타입, 그 외에는 keyword, numeric등으로 맵핑되도록 하는 것이 중요

엘라스틱서치가 불안정해지면 맨먼저 인덱스 맵핑을 봐주는 것이 좋다 그 다음으로 샤드를 살펴봐야한다
프라이머리 샤드를 더 늘린다면 샤드가 특정Node에 쏠리지 않게 샤드의 수를 Hot 노드의 배수로 설정하는게 좋음

로그스태시에서 벡터로 전환

로그스태시는 JVM기반으로 시스템 자원을 많이 사용함, 파이프라인이 늘어나면 날수록 메모리를 많이 사용하게됨→경량화 필요
- vector
- fluentd

다양한 유즈케이스가 있는 fluentd지만 로그 가공이 로그스태시나 벡터에 비해 불편하다는 판단에서 최근 급성장하고 있는 vector로 선택
- 벡터는 로그스테시처럼 코드로 유연하게 작성할 수 있다는 강점
- 공식 홈페이지의 메뉴얼이 잘되어있음
- 프로메테우스로 로그파이프라인 모니터링을 쉽게 구현 가능
- 최근 급격히 관심을 받으며 스타수로 플루언트디를 넘어섬

데이터센터 확장

각 IDC마다 클러스터를 복제해서 사용한다는 것은 비용이 크게 증가함에 따라서 IDC 간에 하나의 클러스터를 구축할 수 있는 방법에 대해서 고민
노드들이 빈번하게 통신하는데 데이터 센터 간의 네트워크 레이턴시가 높으면 클러스터 전체적으로 성능저하가 발생해 엘라스틱 서치에서는 권장하지 않음
가까운 IDC간의 레이턴시 정도면 조금의 지연보다 비용절감으로 오는 효과가 더 크다는 판단

느낀점

카카오 사태를 반명교사 삼아 DR에 대해 대처하기 위해서 많은 준비를 한 것 같다. 꼭 그 사태때문만이 아니라 원래부터 증권이나 뱅크쪽은 DR에 대해 더 다른 도메인보다 중요하긴 하지만….
왜 다른 오픈소스가 아니라 이 오픈소스여야하는지 이유를 들어 설명하는 부분이 좋았다. 어떤 트레이드오프 때문에 선택했는 지를 각자의 회사마다 개인마다 다르기 때문에 지금 어떤 것이 가장 최우선인지 중요한 가치가 무엇인지에 더 집중해야겠다.

2회 수군수군 데이터 엔지니어 모임 후기

은유 — Tue, 30 May 2023 01:42:17 +0900

링크드인쪽에서 몇몇분들을 중심으로 데이터 엔지니어 모임을 개최한다고는 소식을 전해들었다. 링크드인을 개인적으로 따로 하지는 않아서 1회 밋업때 발표 자료인 당근마켓의 에어바이트 발표를 재밌게 봤던 기억이 있다. 그래서 혹시나 이 밋업이 다음번에도 진행되면 참석하면 좋겠다는 생각에 찾고 찾아서 수군수군 데이터 엔지니어 메일링 서비스에 가입했고 그 기억도 잊어버릴 어느 즈음해서 잠들어있는 줄만 알았던 수군수군 데이터 엔지니어 발신자를 통해서 메일이 하나 날아왔다.

https://page.stibee.com/subscriptions/226823

수군수군 데이터 엔지니어 밋업 메일링 리스트

언젠가 또 개최될 수군수군 데이터 엔지니어 밋업 개최 소식을 메일로 받아보고 싶으시다면 이메일을 적어주세요.

page.stibee.com

이 페이지에가면 밋업 개최 소식을 메일로 받아볼 수 있으니 관심있는 데이터 엔지니어라면 구독을 해두자

밋업은 역삼역에 있는 구글 코리아 GFC건물에서 진행됐다. 아마 구글코리아의 카페테리아로 보이는 곳에서 진행이 됐는데 입장하자마자 건물 출입을 위한 QR코드와 이름이 적힌 명찰을 받고 웰컴 드링크(?)인 한맥의 맥주를 받아서 각자 보이는 자리에 앉았다.

나는 I이자 아싸답게 구석에 아무도 안 앉아있는 자리에 조용히 가서 앉아 있었는데 다행이 하나둘씩 삼삼오오 모여서 어느새 4명이 꽉차있는 테이블이 되었다.

가볍게 인사를 나누고 다같이 과자와 맥주를 먹으며 준비된 세션을 보았다.

백터 유사도 검색으로 추천 서비스 구현하기

빅쿼리는 회사에서만 사용하는 쿼리 엔진에서 파생됐다
빅쿼리의 수행 연산은 dremel을 통해서 진행되며 아파치 드릴로 오픈소스 버전이 나옴

보통은 two stage로 나뉨 retrieval->ranking
two tower model을 활용해 사이드 피쳐들을 모두 활용할 수 있음
이베이, 유튜브, 구글 플레이 스토어에서도 이 투 타워 모델을 활용함
nvidia merlin, tensorflow recommenders가 이 투타워모델을 패키징한 모델이며 이것들을 사용하면 투타워모델을 손쉽게 다룰 수 있음
스택 오버플로우 추천 시스템을 예제로 보여줌
- LangChaind LLM을 사용하면 손쉽게 아키텍처 구성 가능

Apache Iceberg on GCP, AWS

storage format에는 parquet, orc, arvo 등등이 있다
이런 storage foramt들은 스키마 미스매치가 발생하거나 스키마 에볼루션이 안된다 특히 write할 때 문제가 많이 발생한다. 그래서 이런 단점들을 보완하고자 table format이 대두되게 된다
빅데이터 플랫폼에서는 증분 업데이트나 머지, 업서트, 스키마 에볼루션 등이 문제가 된다
초기 테이블 포맷 테이블은 여러 파티션을 트렌잭셔널하게 업데이트도 안되고, 클라우드 스토리지에 적합하지 않은 설계(rename, list...) 등 hive 테이블에서 데이터 변경이 비효율적이다.
iceberg는 메타데이터가 중요 버전별로 메타데이터를 찍고 메타데이터만 보면 파일들이 어디 흩어져있는지 알 수 있다
- 증분데이터에 대해서도 유지보수가 쉬워진다
클라우드 환경에서는 AWS에서 후디를 풀 서포트한다(+EMR)
델타레이크는 aws 아테나에서는 제약이 많다
iceberg는 aws 아테나에서 제약이 있긴하지만 거의 다 가능하다
결론
- Hudi는 오래된 프로젝트지만 클라우드에서 쓰기에는 조금 애매한 느낌
- 델타레이크는 가장 핫하지만 AWS나 GCP에서 풀서포트를 받을 수 있을지 애매한 느낌..
- 아이스버그는 완전 오픈소스, 신생프로젝트, 클라우드 프로바이더들이 전폭적으로 지지한다
하지만 데이터브릭스에서 돈주고 이 세 프로젝트를 밴치마크했는데 벤치마크상 아이스버그가 델타레이크랑 속도가 세배나 차이날정도로 제일 느린 결과가..

세션보다는 네트워킹이 중점인 밋업

한국 데이터 엔지니어 모임 이후로 데이터 엔지니어 모임은 이번이 두번째인데 정말 재밌었다. 공감가는 얘기들도 많이 오가고 다른 회사는 어떻게 인프라를 구성하는지 어떤 오픈소스들을 사용하는지 귀동냥으로 많이 듣고 많이 배웠던 하루다.

아쉬웠던건 명함을 몇장 못들고가서 받은만큼 내 명함을 많이 뿌리지 못한 것...그게 좀 아쉽다. 다음 밋업때는 그런 실수없도록 넉넉하게 챙겨가도록 해야겠다.

2023 트리노 밋업 후기

은유 — Tue, 23 May 2023 01:26:01 +0900

한국 데이터 엔지니어 모임에서 트리노 밋업이 열린다는 소식을 전해듣고 트리노를 잘 활용하고 있는 한 유저로써 바로 신청했다. 트리노 밋업은 스파크플러스 선릉점에서 열렸으며 SKT와 스타버스트의 후원으로 진행하게 되었다.

입장해서 가장먼저 저녁을 대신할 샌드위치와 과일, 간단한 다과와 음료를 받아 자리에 앉았다. 아 트리노 트레이드마크인 토끼 마스코트가 그려진 티셔츠가 블랙과 화이트 중 택1로 받을 수 있었는데, 블랙은 너무 개발자스러워서 화이트로 받았다.

밋업이 끝날때쯤 과연 블랙만 품절이고 화이트는 조금 남았어서 블랙을 받고 끝날때쯤 남은 화이트를 가지고가 블랙과 화이트 둘다 챙길껄 하는 아쉬운 마음이 들었다.

사실 사이즈가 XL라고는 하지만 여성 기준인듯 나에게는 거의 95나 M사이즈에 가까울만큼이나 작았다. 그래서 아마 집에서 실내용으로만 입게될 것 같다.(~~하지만 토끼는 귀엽다~~)

세션은 총 세가지로 이루어져있으며 첫번째 세션에서는 trino의 상용버전 스타버스트의 코파운더인 matt가 zoom을 통해 트리노의 오늘과 내일에 대해서 이야기했다. 어딘지는 모르겠지만 그쪽 시간으로는 새벽5시라고...지구 반대편에 트리노를 위해 모인 사람들을 위해 새벽에 열심히 pt를 준비하고 발표해준 matt에게 감사한 마음이 들었다.

나머지는 SKT에서 트리노의 활용방안과 내부로직에 대한 세션이 이어졌다.

오늘 글에는 각 세션에 대해서 하나씩 정리한 내용을 공유하려고 한다.

트리노 오늘과 내일

트리노는 코디네이터에서 파싱하고 플래닝, 스케줄하는 식으로 작동된다
모든 커미터의 50퍼센트가 4년이내에 이루어질만큼 최근에 폭발적인 오픈소스 기여 활동이 일어나고 있다

과거 18개월동안
- 머지 쿼리는 ETL에서 유용하게 사용됐다.
- JSON functions 이 펑션을 사용해서 다른 저장소에 저장하거나 탐색함
- Table functions
Fault tolerant execution
dbt-trino 통합할 예정
메타베이스 드라이버 제공 예정
에어플로우 통합지원 예정

로드맵
- 다음 세대 columnar engine
  - trait-specific processing(인코딩, 아스키, null, 등..)
  - SIMD/GPU
- aggrigation과 조인을 통한 해쉬 테이블
- 스노우플레이크, 스타록스, 스패너, exasol 커넥터 제공예정
- CREATE/DROP CATALOG
질문! 코디네이터 HA는 지원하거나 지원할 예정인지?
- 아직 트리노 내부에서는 계획이 없다 대신에 핫스텐바이를 띄워서 패일오버하는 식으로 해결
- 쿠버네티스를 통해서 pod를 실패시 재실행하는 식으로 보완

ETL없이 데이터 레이크 구성하기

분석과들과 엔지니어들 간에 다툼을 극화시켜서 표현한 장면

일반적인 ETL 과정의 도식화된 과정에서 무조건 모아야 한다는 편견을 깨부수고 트리노로 다리를 놓자는 것이 핵심
ETL을 버리고 통합 데이터 플랫폼으로 진화 시키는 법
ETL 과정을 없애고 트리노로 모든 쿼리를 통합한다. 단, 같은 질의에 대한 캐시를 사용함(verade, file system, redis 등)으로써 DB의 부하를 최소화하는 것을 전재로 한다.
- 하이브는 디렉토리 베이스 구조이고 아이스버그는 파일 베이스 구조이다 파일 베이스로 가야지 앞서 얘기한 캐시를 사용함으로 트리노를 통한 다리 놓기가 가능
SQL Tracking System on AI
- 사용된 sql 문장을 통해 데이터 사용의도를 추적하는 시스템
Active Meta Platform
- 사용자의 노력없이 Data에 대한 Meta 정보를 알 수 있다
트리노에서 이벤트리스너를 통해서 사용자의 쿼리를 수집하고 재사용 쿼리에 대한 캐싱 처리 및 bert나 gpt 모델을 통한 학습으로 추후 대화형 질의를 통해 데이터를 검색하는 것까지 구상
살짝 진보적인 내용이긴 하지만 현재 ETL 구조에서에서 오는 피로함과 데이터를 디깅하는 입장에서의 마찰을 해결하려는 방식의 이상향에 대해서는 너무 공감하는 내용이다 개인적으로 가장 마음에 들었던 세션

Trino에서 데이터 저장소와 상호작용하는 방식을 알아보자

conway’s Law
- 유연성이 중요하다
무조건 모으지 않아도 된다는 관점에서 시작
- 데이터 메쉬의 등장
query federation?
- 여러개의 사일로된 데이터 소스에 대해서 쿼리를 날린다
즉결성에 있어서 페더레이트 쿼리가 중요하다
cdc는 현재 데이터가 보임→1년전껄 보고자한다면? 스쿱이 필요→기술이 적재적소에 필요함
비즈니스가 먼저고 기술이 후행한다
파싱→애널라이즈→플랜→스케쥴→익스큐트(워커)
optimization
- constant folding
- 반복적 최적화→트리구조를 반복적으로 가져가서 끝까지 최적화
스플릿→가장 작은 작업할당 단위이자 병렬성을 만족시키는 단위
bzip2만 스플릿터블함
orc, parquet…컬럼별로(나눠서) 압축을 함→그래서 압축을 해도 읽을 수 있음
스플릿 구조를 만든 이유→읽기 비용을 생각하면 페이지 캐시에 로드 되었으나 사용되지 못하는 영역을 사용하지 못하는 문제때문에 작게 나눈다
sk텔레콤에서는 아이스 버그를 사용한다
스토리지와 컴퓨테이션 분리가 추세
block replication vs erasure coding
- erasure coding이 반드시좋지는 않다→분산저장되어있으니까 로컬리티가 보장이 안됨
파퀘이에서는 로우그룹 orc에서는 stripe가 읽을 수 있는 최소그룹→스플릿 앞부분만 찾아서 인덱스를 추려내서 그 파일만 읽어냄
결론
- 모든 기술은 적합한 환경에서 사용해야 하며 내부 구현을 알면 더 잘 사용할 수 있다
트리노에 관해서는 태스크 위주로 작업을 해서 내부구조나 코드를 직접 까보고 원리에 대해서 이해하는 시간을 갖지는 못했는데 쿼리가 플래닝되는 과정들을 세세하게 과정 하나하나 뜯어가며 설명해준게 인상깊었다. 시간이 더 길었으면 좀더 천천히 설명을 들었을 걸하는 아쉬움이 남는 세션

모든 세션이 마치고

친구와 함께 세션이 끝마치고도 질문 공세를 퍼부어서 곤란하셨을 법한데 친절하게 모두 답변해준 이성화 연사자님께 감사의 말씀을 블로그 지면을 통해서라도 남기고 싶다.

사실 크게 별 기대안하고 단순히 트리노? 나도 쓰는건데! 한번 가볼까? 하는 가벼운 마음으로 신청한건데 생각보다 깊은 고찰과 수준높은 발표에 많은 것들을 배우고 견문을 넓히고 간다.

오히려 스타버스트측의 발표가 영어 발표이기도하고 새로울 것도 없는 내용이라서 좀더 아쉬울 만큼이나 나머지가 잘 준비된 세션들인 것 같다.

다음번에 밋업이 열리면 또 참석해야겠다.

kafka retention 용량 설정 값 이해하기

은유 — Mon, 1 May 2023 01:17:05 +0900

overview

retention.bytes옵션을 통해 retention 용량을 1GB로 설정했었는데 토픽의 용량이 7GB가 넘어가는 것들이 생겼다.
브로커당 용량이라고 이해해도 3GB넘지 않을 것이고 리플리케이션 팩터가 2라서라기엔 2GB를 훌쩍넘는다. 7GB라니...오버에도 한참 오버했다. 도대체 이 설정값들은 각각 무엇을 의미하는 것이고 어떤 매커니즘으로 메세지들이 지워지는지 파악해보자

Topic

retention 용량 설정에 대해서 알아보기 전에 토픽에 대해서 간단히 정리해보자

partitions

리더 파티션과 팔로워 파티션으로 구분(replication-factor가 1인 경우 리더 파티션만 존재)
리더 파티션은 프로듀서 또는 컨슈머와 직접 통신하는 파티션으로 읽기, 쓰기 연산을 담당
팔로워 파티션은 리더 파티션의 데이터를 복사하여 보관하는 역할, 장애 발생시 리더 파티션의 지위를 가지게 되는 예비용 파티션
파티션이 많아지면 그만큼 파일 핸들로도 늘어나게 되어서 파티션이 많다고 무조건 좋지는 않음
카프카에서는 브로커당 약 2천개 정도의 최대 파티션 수를 권장

replication-factor

기본값 replication factor=1 → 복제가 없는 경우 리더 파티션만 존재
broker 숫자만큼 설정 가능
파티션과 리플레케이션 팩터 모두 늘릴 수만 있고 줄일 수는 없어서 신중하게 선택해야함

ISR(In Sync Replica)

ISR이라는 논리적인 그룹에 리더와 팔로워가 묶여있으며 ISR 그룹에 속하지 못한 팔로워는 새로운 리더가 될 수 있는 자격이 없음
현재 리플리케이션되고 있는 리플리케이션 그룹을 뜻함

retention

retention은 기간과 용량을 설정해줄 수 있다.
or조건으로 기간이 만료되었거나 용량이 초과되면 설정한 기간만큼 메세지를 지우거나 용량만큼 메세지를 지운다.
토픽의 메세지들은 파티션으로 나뉘며, 각 파티션들은 세그먼트로 분류할 수 있다.
log.dirs의 디렉토리를 확인해보면 생성한 파티션을 확인할 수 있다

|── my-topic-0
   ├── 00000000000000000000.index
   ├── 00000000000000000000.log
   ├── 00000000000000000000.timeindex
   ├── 00000000000000001007.index
   ├── 00000000000000001007.log
   ├── 00000000000000001007.snapshot
   ├── 00000000000000001007.timeindex
   ├── leader-epoch-checkpoint

세그먼트는 다시 log, index, timeindex, snapshot, leader-epoch-checkpoint로 나뉘게된다.
- log file - 실제 record들이 기록되는 곳.
- index file - 파티션의 논리적인 인덱스와 파일의 물리적인 인덱스를 매핑해주는 파일
- snapshot file - 중복저장을 피하기 위해서 사용하는 sequence ID들에 대해서 프로듀서의 상태들이 담겨있다.
- leader-epoch-checkpoint - 컨트롤러에 의해 이전에 할당된 리더들의 숫자를 참고한다. 레플리카들은 leader epoch를 최근의 리더를 확인하는데 사용한다.

파라미터 명	기본 값	효과
log.segment.bytes	1 GiB	segment 단일 로그 파일의 용량 제한
log.index.size.max.bytes	10485760 (10MB)	오프셋 인덱스의 총 용량
log.retention.bytes	-1 (지우지 않음)	로그 파일의 총 용량
log.retention.ms/ log.retention.minutes/ log.retention.hours	null//null/168(hours)	log파일을 저장할 주기
log.retention.check.interval.ms	300000 (5분)	로그를 삭제할 대상을 확인하는 시간 주기
log.segment.delete.delay.ms	60000 (1분)	파일을 파일시스템으로 지우기 전에 기다리는 시간의 양

segment.bytes

단일 로그 파일의 용량

retention.bytes

로그 파일들의 총 용량
log.retention.check.interval.ms은 기본 값이 5분이다. 만약 설정한 log.retension값이 이 값보다 짧으면 원하는 시간주기대로 log를 삭제하지 못할 수 있다.
- 한마디로 log.retention.check.interval.ms값보다 log.retension값이 더 커야한다.
segment.bytes는 각 log파일들의 용량을, retention.bytes는 각 log파일들이 합쳐진 총 용량을 의미한다.
- 예를들어 segment.bytes는 10mb, retention.bytes는 20mb로 설정하면 10mb짜리 log파일이 2개 생성된다.
- segment.bytes보다 retention.bytes가 값이 더 커야지 적용된다.

다만 이 설정은 active중인 segment에 대해서는 해당되지 않는다. active중인 segment가 segment.bytes에 설정한 만큼을 달성하면 retention.bytes에 설정한 만큼 가장 오래전에 생성된 segment먼저 지워지게 된다.

Proof

partitions가 1, replication-factor가 1이고 segment.bytes가 5MB, retention.bytes가 10MB인 토픽 하나를 생성한다.

@kafka:/$ kafka-topics.sh --bootstrap-server localhost:9092 \
 --create --topic test_topic1 --partitions 1 --replication-factor 1 -add-config segement.bytes=5242880,retention.bytes=10485760

test_topic1-0$ du -h *
0	00000000000000000000.index
0	00000000000000000000.log
0	00000000000000000000.timeindex
4.0K	leader-epoch-checkpoint
4.0K	partition.metadata

0kb로 log파일이 제대로 생성된 것을 확인할 수 있다. 이제 00000000000000000000.log 파일은 액티브 세그먼트로써 실시간으로 메세지들이 5MB까지 저장될 것이다.
test 메세지를 적재하기 위해 kafka-python 클라이언트를 받아서 임의의 메세지를 생성한다.

!pip install kafka-python

from kafka import KafkaProducer
from json import dumps

producer = KafkaProducer(acks=0, compression_type='gzip',
                         bootstrap_servers=['localhost:9092'],
                         value_serializer=lambda x: dumps(x).encode('utf-8'))
                         
counter=0
while True:
    producer.send('test_topic1', value={'test_key': f"test_value {counter}"})
    counter+=1
    producer.flush()

(주의)while문으로 중지하기 전까지 계속해서 메세지를 생성하므로 데이터 확인이 끝나면 반드시 프로세스를 종료시켜 준다.

test_topic1-0$ du -h *
12K	00000000000000000000.index
5.0M	00000000000000000000.log
16K	00000000000000000000.timeindex
12K	00000000000000052539.index
5.0M	00000000000000052539.log
4.0K	00000000000000052539.snapshot
16K	00000000000000052539.timeindex
4.0K	00000000000000104918.index
1.4M	00000000000000104918.log
4.0K	00000000000000104918.snapshot
8.0K	00000000000000104918.timeindex
4.0K	leader-epoch-checkpoint
4.0K	partition.metadata

segment.bytes에서 설정한대로 단일 로그 파일의 용량이 5MB로 2개 총 10MB의 segment가 완성되었다. 그런데 지금은 10MB를 넘어서 하나의 로그파일이 더 생성되고 11.4M가 되었다.
앞서 언급한 것처럼 1.4MB짜리 로그파일은 액티브 segment이며 이 파일의 용량이 5MB으로 채워지게 되면 가장 처음에 생성되었던 00000000000000000000.log부터 차례대로 지워지게 된다.
확인을 위해서 계속해서 데이터를 넣어보자

test_topic1-0$ du -h *
12K	00000000000000000000.index
5.0M	00000000000000000000.log
16K	00000000000000000000.timeindex
12K	00000000000000052539.index
5.0M	00000000000000052539.log
4.0K	00000000000000052539.snapshot
16K	00000000000000052539.timeindex
12K	00000000000000104918.index
5.0M	00000000000000104918.log
4.0K	00000000000000104918.snapshot
16K	00000000000000104918.timeindex
4.0K	00000000000000157316.index
892K	00000000000000157316.log
4.0K	00000000000000157316.snapshot
4.0K	00000000000000157316.timeindex
4.0K	leader-epoch-checkpoint
4.0K	partition.metadata

active segment가 00000000000000104918.log에서 00000000000000157316.log으로 바뀌었다.

test_topic1-0$ du -h *
12K	00000000000000000000.index.deleted
5.0M	00000000000000000000.log.deleted
16K	00000000000000000000.timeindex.deleted
12K	00000000000000052539.index
5.0M	00000000000000052539.log
4.0K	00000000000000052539.snapshot
16K	00000000000000052539.timeindex
12K	00000000000000104918.index
5.0M	00000000000000104918.log
4.0K	00000000000000104918.snapshot
16K	00000000000000104918.timeindex
4.0K	00000000000000157316.index
892K	00000000000000157316.log
4.0K	00000000000000157316.snapshot
4.0K	00000000000000157316.timeindex
4.0K	leader-epoch-checkpoint
4.0K	partition.metadata

예상했던 것처럼 가장 처음에 생성된 00000000000000000000.log가 deleted상태로 바뀌게 되고 segment.delete.delay.ms의 기본값인 1분 뒤에 완전히 지워지게 된다.

test_topic1-0$ du -h *
12K	00000000000000052539.index
5.0M	00000000000000052539.log
4.0K	00000000000000052539.snapshot
16K	00000000000000052539.timeindex
12K	00000000000000104918.index
5.0M	00000000000000104918.log
4.0K	00000000000000104918.snapshot
16K	00000000000000104918.timeindex
4.0K	00000000000000157316.index
892K	00000000000000157316.log
4.0K	00000000000000157316.snapshot
4.0K	00000000000000157316.timeindex
4.0K	leader-epoch-checkpoint
4.0K	partition.metadata

Conclusions

액티브 세그먼트까지 포함해서 파티션당 순간적으로 최대 retention.bytes + segment.bytes만큼의 용량이 추가로 필요하다.
용량이 7GB까지 늘어있던 토픽은 파티션이 2, 레플리케이션 팩터가 2 였다.
0번파티션은 0번, 1번 브로커에 레플리케이티드 되어있고, 1번 파티션은 각각 0번과 2번에 레플리케이티드 되어있다.
segment.bytes는 1기가, retention.bytes도 1기가로 설정되어있으므로 액티브 세그먼트를 고려하면 각 브로커의 파티션당 세그먼트 파일들이 순간적으로 최대 2GB까지 늘어날 수 있다.
따라서 레플리케이션 되어있는 총 개수를 곱하면 해당 토픽은 순간적으로 최대 8GB까지 늘어날 수 있다. 따라서 7GB라는 용량은 충분히 정상적인 값이다.

reference

https://www.conduktor.io/blog/understanding-kafkas-internal-storage-and-log-retention/

Understanding Kafka's Internal Storage and Log Retention

Apache Kafka is a commit-log system. Understanding configuration parameters gives you a lot more control over how you handle your data.

www.conduktor.io

2023 NAVER deview trino, kafka 세션 리뷰

은유 — Wed, 29 Mar 2023 00:07:12 +0900

CQuery: 우당탕탕 Trino와 썸타기

Hive+Tez vs Trino

하이브 대비 SQL 조회 성능이 매우 빠름

하이브는 Yarn에서 리소스를 할당받아 HDFS클러스터에서 데이터를 가져와 쿼리를 처리하는 시간 즉 얀 오버헤드와 쿼리타임이 합쳐진 시간이 전부 처리 시간이 됨

JVM위에서 띄우기 때문에 얀 오버헤드가 없음
코디네이터에서 필요한 메타데이터를 얻고 최적화된 쿼리플랜을 생성함
스케줄러에는 워커들에게 작업을 할당하면서 데이터 위치정보를 함께 넘겨줌
워커들에서 커넥터로 구분에 여러 디비에서 데이터를 가져와서 읽고 쓸 수 있음
여러 스테이지서 나눠진 파이프단위로 워커들의 메모리에 데이터를 올려서 처리

Trino 기능

커널, 디스크/네트워크 버퍼 등으로 20% 사용
Tread stacks, GC, off heap 메모리 등으로 30% 사용
스타버스트 피셜 쿼리 실제 처리 가용 메모리는 서버의 56%
- ex) 100GB 서버 → 80GB JVM(-20%) → 56GB 쿼리 메모리(-30%) → 총 44 GB(-44%)손실
워커 안에서 처리되는 객체 페이지>블럭>슬라이스 단위로 잘게 나뉘어서 처리
- 슬라이스는 메모리를 접근하고 특정 데이터로부터 읽는 라이브러리
코디네이터 WEB UI는 DB가 아니라 코디네이터 메모리에 저장되서 날아감

access-rules.json 파일로 WEB UI에서 보여지는 쿼리에 대한 조회 접근을 제한하고 있음
Rerty policy: 쿼리 작업 실패 시 자동으로 재시도
- Fault-tolerant execution 옵션 설정 켜기
- 특정 작업에 대해서 재시도가 불필요한 경우 사용자가 임의로 끌수 있도록 허용
Stage 0: 코디네이터에서만 실행되는 태스크로 stage1 작업의 결과 최종 집계
스테이지 N(1): Distributed stage로 각 워커에서 작업을 수행하는 단계

ops

web ui 히스토리 개수만큼 GC가 되지 않기 때문에 개수를 너무 늘리면 OOM, 서버 무응답 등 장애 발생
JMX로 제공하는 지표를 프로메테우스와 연동해서 사용
이벤트리스너를 통한 쿼리별 실행 정보를 엘라스틱서치와 연동
- 실행한 쿼리 정보
- 사용한 리소스 정보
- 실패한 쿼리 exception 정보
Event Listener
- Query Creation: 사용자 쿼리가 입력되고 실행되기 전 발생하는 이벤트
- Query Completion: 사용자 쿼리가 종료된 이후 발생하는 이벤트
- Split Completion: 쿼리 실행 중 각각의 Stage마다 split 완료될 때마다 발생하는 이벤트

이벤트 리스너를 직접 구현해서 사용중
리소스 그룹: 그룹내에서 실행되는 쿼리에 대해 대기열 정책을 적용하거나 메모리 CPU 제한을 부여하는 기능

특정 사용자의 다수의 쿼리 어뷰징 문제(For문을 통해 기간만 바꿔서 대량의 쿼리 요청)
- 단기간 요청이 많을 경우 시스템 불안정
Guard: 어뷰징 쿼리로 인해 클러스터 리소스 전부 잠식하는 경우 발생
- 특정 worker 장비에서 장기간 CPU 로드 과부하로 인해 클러스터 데이터 처리 지연
- count(distinct) 함수는 고유값을 찾는 로직이라 무거움 문서에서도 approx_distinct()함수 사용 권장

조회 기간이 제한 범위 이내면 쿼리가 정상적으로 실행
그래도 UNION, JOIN 등 메모리 과다 사용시 실패 → SPil to Disk 기능 사용(OS의 페이지스왑핑과 흡사한 기능)→일시적으로 한도 이상 메모리 사용가능

To be

스케일아웃으로는 한계가 있어서 스케일업을 하려고함→dram보다는 느리지만 저렴한 cxl 기반 메모리 사용

저용량에서는 CXL 메모리가 오히려 성능 하락

확장된 CXL 저가 메모리는 spilled data가 발생하지 않음 Disk IO까지 사용하는 빈도를 줄여 빠른 쿼리 성능을 기대할 수 있음

Lyft처럼 앞단에 프록시 게이트웨이를 두어서 쿼리 특성에 따라서 클러스터 자동 전환
- 반드시 성공을 보장 받아야하는 쿼리는 독립된 클러스터에서 실행
Hive Table Format에서 Iceberg Format으로 변경
- PB단위를 넘어섰고 갈수록 증가하는 데이터에서는 Hive MetaStore의 RDBMS, Hadoop NameNode 병목이 가장 큰 문제

네이버 스케일로 카프카 컨슈머 사용하기

Kafka Consumer 동작 원리

Topic: 1개 이상의 Partition으로 분할, 1개 이상의 Replica로 복제된 log 자료 구조
Client
- Producer: 쓰고자 하는 Topic Partition의 맨 끝에 record를 추가
- Consumer: 읽어오고자 하는 Topic의 Partition에 저장된 record를 순차적으로 읽어옴
카프카란? 로그 자료 형태를 분산 스토리지 형태로 만든 것
- 로그는 레코드를 추가된 순서대로 저장하는 자료구조→순서보장이 가장 큰 특징
- 카프카에서 제공되는 로그는 분할되고 복제된 로그(파티션, 레플리카)
- 고가용성, 단일파티션 내에서만 순서보장, 읽기쓰기 리더 레플리카에서만 일어남
- 하나의 컨슈머는 하나의 파티션을 독점적으로 읽게 됨
- 컨슈머끼리는 서로 협력해야함
Consumer Group
- 같은 group.id 설정값을 가진 Consumer들은 하나의 Consumer Group을 이룬다
- 같은 Consumer Group에 속한 Consumer들이 Topic에 속한 Partition들을 나눠서 읽는다
- 컨슈머 리벨런스를 통해서 컨슈머나 파티션에 증감이 있을때 자동으로 멈췄다가 조정해서 시작함

컨슈머 추상화 객체→논리적인 컨슈머
컨슈머 그룹 기능이 제대로 동작하기 위해 필요한 두가지
- Partition Assignment기능
  - 중복도 누락도 없이 할당하는 할당 메커니즘
- Offset Commit 기능
  - 어디서부터 작업을 재개하면 되는지 저장하고 읽는 매커니즘

서버가 아니라 컨슈머 그룹중 하나의 컨슈머 리더가 되서 토픽의 파티션들을 컨슈머들에게 할당
- 컨슈머들끼리는 직접적인 통신을 하지 않고 브로커가 컨슈머 그룹 코디네이터 역할로 경유해서 간접적으로 통신
- 브로커를 재시작할 필요없이 유연하고 확장 가능한 파티션 할당을 지원하기 위해 이런 구조로 구성됨
max.poll.interval.ms: 컨슈머가 토픽을 가져올때(poll)의 최대 시간
session.timeout.ms: 컨슈머가 백그라운드 스레드에서 컨슈머 코디네이터에 보내는 하트비트 신호없이 동작하는 최대 시간
- heartbeat.interval.ms
partition.assignment.strategy: ConsumerPartitionAssignor class들의 목록이 들어감
- 파티션 할당 전략으로 선택
group.instance.id
- 정상적 재시작 이전에 할당되어 있던 파티션들을 다시 할당하므로 리벨런스가 발생하지 않음
- 단순 pod 재시작으로 파티션 리벨런스가 발생하는 사태를 방지
- 카프카 스트림이 내부적으로 이 설정을 사용함

요약

카프카 컨슈머에는 컨슈머 그룹이라는 개념이 있으며, 같은 컨슈머 그룹에 속한 컨슈머들은 토픽을 읽어올 때 여기 속한 파티션들을 자동으로 나눠가진다.
클라우드 환경에서 컨슈머 그룹 기능을 사용하는 것이 쉽지많은 않으며, 2.x 이후에 업데이트된 기능과 설정들을 적절히 활용함으로써 문제 발생을 막을 수 있다
Rack 관련 최적화 기능이 추가된 Partition Assignor는 가능하며, 멀지않은 미래에 보편적인 기능이 될 것이다.

한국 데이터 엔지니어 모임 연사로 참여한 후기

은유 — Sun, 26 Mar 2023 02:51:01 +0900

첫번째 밋업

개발관련 컨퍼런스에 참여한 것은 몇번 있었지만, 네트워킹을 위한 밋업 참여는 이번이 처음이다. 50~60명 규모로 모집되어 거의 2:1의 경쟁률로 거의 100명가까이 신청 했다고 한다.
한국 데이터 엔지니어 모임은 카카오톡 오픈챗방으로 벌써 1300명이 넘는 인원이 상주하며 데이터 엔지니어 직군과 관련된 정보와 질문들을 서로 공유하고 있다.
나도 그 톡방에 상주하며 여러 트렌드도 읽고 궁금한 점에 대해서는 질문도 하고, 때로 내가 아는 내용이 나오면 답변도 하면서 활동하고 있다.ㅡ활동명은 비밀이다. 채팅방에 팀장님도 계신다고 하여서 운신의 폭을 넓히기 위해서 조용하고 은밀하게 활동중이다.ㅡ그러던 중에 채팅방에서 제 2회 한국 데이터 엔지니어 모임 밋업을 진행한다는 공지를 보게 되었고 나는 이런 밋업같은 것이 처음이었기 때문에 이런 곳에 가면 어떨까, 나랑 같은 직군에 있는 사람들은 어떤 사람들일까? 하는 궁금한 마음이 들었다.
그래서 꼭 참여해야겠다 생각하고 언제 열리게될까 기다리던 도중 모임에서 발표할 연사자를 모집한다는 공지글을 확인했다.
때마침 디비지움에 대해서 작업하던 내용도 있어서 준비하고 발표하면서 커리어적으로 나에게 도움될 수 있을 것 같다는 생각에 신청했다.
그때는 몰랐다 정말로 될지는, 그간 대화방을 눈팅하면서 워낙 쟁쟁하고 실력이 출중한 사람들이 모여서 대화를 나누던 곳이라서 나도 정말 많이 도움받고 그냥 읽기만 하는 것만으로도 실력과 견문이 넓혀지는 듯한 기분이 들었다.
그런 대단한 사람들 사이에서 내가 신청한 발표가 모임 가장 첫번째 순서로 소개하게 되다니.
비록 신청할때는 가벼운 마음으로 하기는 했지만 준비는 결고 가볍지 않게 해야겠노라고 다짐했다.

디비지움을 이용한 CDC 실시간 테이블 파이프라인 구성기

내가 준비한 발표는 디비지움을 이용한 CDC 실시간 테이블 파이프라인 구성기였다.
사내에서 CDC 작업을 위해 진행했던 내용 중에 디비지움에 포커스를 맞춰서 어떻게 파이프라인을 구성했는지, 작업 진행 중에 주의하면 좋을 점이나 트러블슈팅 같은 것들을 공유하기로 간략하게 틀을 잡아놓고 ppt를 만들었고 다음과 같은 ppt가 탄생했다.
https://docs.google.com/presentation/d/1uVK7Qrp2JQ1mSBzMCC1Mw1QNkJ5wW7ItD4412hBVPwY/edit#slide=id.p
나중에 발표를 찍은 영상을 유튜브로 공유해준다고 하는데...채팅방에 영영 안올라왔으면 하는 바람이다.
발표는 내 소개와 더불어 CDC와 사내 파이프라인이 어떻게 구성되어있는지 간략하게 소개하고, 디비지움을 중점적으로 디비지움이 무엇인지 부터 시작해서 직접 테스트하면서 CDC 데이터를 확인하는 예제까지 함께 보면서 진행했다.
마무리로 그간 작업하면서 부딪혔던 트러블 슈팅과 Q&A를 끝으로 모든 발표를 마쳤다.
초반에는 진짜 덜덜 떨면서 했는데 중반부터는 자주 혼자서 연습했던 부분이라서 그나마 조금 자연스럽게 다른 사람들도 쳐다보면서 진행을 했었던 것 같다.
팀장님 말로는 한곳이 아니라 여러곳에서 발표했던걸 기반으로 점점 디벨롭 시켜가면서 같은 주제로 한다고 하는데, 나도 기회가 된다면 좀더 이번 발표때 아쉬웠던 부분을 다듬고 발전시켜 더 좋고 많은 사람들 앞에서 전달해줄 수 있으면 더 나를 발전시킬 수 있을 것이라는 생각이 들었다.

debezium으로 CDC 데이터 파이프라인 구축기

Debezium을 이용한 CDC 실시간 테이블 파이프라인 구성기 한국 데이터 엔지니어 모임 2기 발표자 윤도경

docs.google.com

네트워킹

모든 발표가 끝나고 나서 피자를 먹으면서 모임에 참여한 사람들과 번갈아가면서 대화를 나눌 시간이 생겼다. 발표 버프(?) 덕분인지 초반 한 10여분을 제외하고는 여러 많은 다양한 회사의 다양한 분들과 대화할 수 있었다.
너무 감사하게도 많은 분들이 말을 걸어주셔서 아싸 성격인 나는 말을 걸어주시는 분들에게 대답하는 것만으로도 벅찰 정도로 주어진 시간을 알차게 쓸 수 있었다.
대화를 나누면서 느꼈던 것들은 많은 사람들이 나와 비슷한 고민을 하고 있다는 점과 CDC를 도입을 앞두거나 관심이 있는 사람이 상당히 많다는 점이었다. 나는 발표를 준비하면서 과연 많은 사람들이 공감하거나 이해할 수 있을까에 대한 고민을 많이 했었는데 그 걱정을 조금 덜 수 있어서 다행이라고 느꼈다.
가장 기억에 남는 것은 현업자분들 이외에 스태프로 아직 취직을 준비하시는 분들이나 학생분들이 지원을 많이 하셨는데 그분들이 오셔서 데이터 엔지니어의 직군에 대한 고민과 취직에 대한 고민 등을 털어놓으셨는데, 최대한 내가 이해하고 있는 직군에 대한 이해와 취직에 도움이 될만한 정보들을 전달해주었다.
그것만으로도 부족하다는 생각이 들어서 내 명함을 건네주고 이력서 첨삭이나 다른 궁금한 점이 있다면 언제든지 연락 달라고 말했다.
사실 호의를 베풀기는 했어도 상대방이 오히려 부담스러워하거나 연락하기를 꺼려할 수도 있는데, 모임이 끝나고 그때 나에게 상담을 받았던 두 명 중에 한 명이 나에게 연락이 왔다.
기특하고 반가운 마음에 최대한 정성껏 보내온 이력서를 자세하게 읽고 내가 그간 겪었던 경험들을 되돌아보며 최대한 알기쉽게 현업에 대한 이야기와 알아야 할 것들에 대해서 전달했다.

어찌보면 나에게 첫 멘토링과도 같은 기회였는데, 이런 경험들을 통해서 내 자신이 얼마나 현 상황에 안주하고 있었는지를 깨닫고 리프레쉬하는 계기가 되었다. 열심히 노력하는 신입들을 보며 나 역시 부끄럽지 않은 사람이 되기 위해서 부단히 노력해야겠다.

아무튼 이번 한국 데이터 엔지니어 모임을 통해서 많은 것을 깨달았고 많은 사람들과 이야기 하면서 공감도 하고 위로도 되었다. 처음에는 이런 자리가 낯설고 어색했지만 다음에도 또 이런 기회가 있다면 더 자주 찾아가서 더 적극적으로 다른 사람들과 정보를 공유하는 사람이 되어야겠다.

debezium server 정리 및 트러블슈팅

은유 — Mon, 6 Feb 2023 00:27:10 +0900

개요

CDC(Change Data Capture)

CDC는 변경 데이터 켑처이라는 의미로 주로 데이터베이스와 같은 데이터 스토어의 데이터 변경을 포착하여 ETL, 감사(audit), 캐싱과 같은 다양한 후속 처리를 하는데 사용한다.

Debezium

이름은 DB와 주기율표에 많은 요소 이름에 사용되는 -ium 접미사의 조합
Debezium은 다양한 데이터베이스를 모니터링하며 모든 이벤트를 대상으로 변경 사항을 분을 거의 즉시 응답하는 분산 오픈 소스 플랫폼이다.
- debezium은 결함과 실패를 허용하도록 설계되었고 수행하는 유일한 방법은 분산 시스템을 사용하는 것이다. Debezium은 모니터링 프로세스 또는 커넥터를 여러 시스템에 분산시킬 수 있고 문제가 발생하면 커넥터를 다시 시작할 수 있다.
카카오커머스, 라인커머스, 에이블리, 트리바고 등 주로 커머셜 도메인에서 자주 사용됨
PostgreSQL, MongoDB, MySQL, Oracle, AWS RDS, Db2, SQL Server, Cassandra를 지원한다.
기본적으로 debezium은 카프카의 커넥터 기반 플러그인으로 제공되며 최근 Debezium Server라는 이름으로 독립된 형태로 Embedded Engine을 사용할 수 있으며 카프카 대신 AWS Kinesis, GCP Pub/Sub, Apache Pulsar or Redis 등 다양한 스트림을 대상으로 데이터 베이스 소스를 내보낼 수 있다. 아직 인큐베이팅 상태
- 카프카의 커넥터 형태가 아니라 자바 애플리케이션의 라이브러리로 바로 사용
Debezium이 중단되었다가 재시작되면 마지막에 저장된 binlog offset부터 다시 읽어 카프카 토픽에 저장한다.

Local 환경 셋팅

카프카가 아닌 키네시스를 사용하기 위해서 debezium server를 사용
테스트 환경 구축 및 테스트 목적
Docker를 통해 Mysql과 Redis를 띄우고 Mysql의 변경사항을 Redis에 적재하도록 함

설치

아래 저장소에서 버전 확인 후 설치
- 2023-02-05 기준 2.1.2 Final 버전이 가장 최근 버전
tar.gz 파일을 받고 압축을 해제

io/debezium/debezium-server-dist

Central Repository: io/debezium/debezium-server-dist

repo1.maven.org

기본적으로 conf하위에 application.properties 파일에 설정값을 지정하고 ./run.sh 스크립트를 통해서 Debezium 구동

application.properties

debezium.sink.type=redis
debezium.sink.redis.address=127.0.0.1:6379
debezium.source.connector.class=io.debezium.connector.mysql.MySqlConnector
debezium.source.offset.storage.file.filename=data/offsets.dat
debezium.source.offset.flush.interval.ms=0
debezium.source.database.hostname=127.0.0.1
debezium.source.database.port=3306
debezium.source.database.user=mysqluser
debezium.source.database.password=mysqlpw
debezium.source.database.dbname=inventory
debezium.source.database.server.name=test1
debezium.source.database.server.id=3461 #아이디값은 임의 값으로 지정
debezium.source.database.include.list=inventory
debezium.source.database.history.file.filename=data/history.dat
debezium.source.database.history=io.debezium.storage.file.history.FileDatabaseHistory
quarkus.log.console.json=false

Docker

# 샘플 데이터가 저장되어있는 Mysql 이미지 run
docker run -it --rm --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=debezium -e MYSQL_USER=mysqluser -e MYSQL_PASSWORD=mysqlpw quay.io/debezium/example-mysql:1.9

# Redis 이미지 run
docker run --name redis -d -p 6379:6379 redis

Mysql

mysql 권한부터 만들어야 한다.

docker exec로 이미지 접속 mysql -uroot -p 으로 mysql cli띄우기→비밀번호는 mysql docker 이미지를 실행할때 변수값으로 전달한 비밀번호 MYSQL_ROOT_PASSWORD
mysql> CREATE USER 'mysqluser'@'localhost' IDENTIFIED BY 'mysqlpw';
mysql> GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'mysqluser';
mysql> FLUSH PRIVILEGES;

REPLICATION CLIENT와 REPLICATION SLAVE는 CDC를 위한 권한
- REPLICATION CLIENT – This privilege is required for CDC tasks only. In other words, full-load-only tasks don’t require this privilege.
- REPLICATION SLAVE – This privilege is required for CDC tasks only. In other words, full-load-only tasks don’t require this privilege.
SHOW DATABASES와 RELOAD는 스냅샷을 위해 필요한 권한이다.
- RELOAD - Enables the connector the use of the FLUSH statement to clear or reload internal caches, flush tables, or acquire locks. This is used only when performing a snapshot.
- SHOW DATABASES - Enables the connector to see database names by issuing the SHOW DATABASE statement. This is used only when performing a snapshot.
RELOAD 같은 경우는 스냅샷시 Lock을 걸기 위해 필요한 권한이다. snapshot.locking.mode 옵션을 none으로 설정하면 RELOAD권한이 없어도 스냅샷 기능을 사용할 수 있다. 다만 이 옵션은 정합성을 위해서 스냅샷이 동작 중에 스키마가 변경될 일이 없을 경우에만 권장된다.

Redis

Redis의 key, value들을 Gui로 확인하기 위해서 맥 기준 앱스토어에서 Medis2라는 클라이언트를 설치한다

커텍트를 눌러서 docker로 띄운 redis에 연결한다

Dbeaver와 같은 클라이언트를 통해서 mysql에 연결 후 테스트를 위해 테이블에 정보를 임의로 수정

"payload":{
"before":{"id":109,"name":"spare tire","description":"32 inch spare tire","weight":22.2},
"after":{"id":109,"name":"spare tire","description":"28 inch spare tire","weight":22.2}

페이로드로 데이터가 32 inch spare tire에서 28 inch spare tire로 바뀐 것을 확인할 수 있다.

Kinesis

appication.properties

debezium.sink.type=kinesis
debezium.sink.kinesis.region=ap-northeast-1
debezium.source.connector.class=io.debezium.connector.mysql.MySqlConnector
debezium.source.offset.storage.file.filename=data/offsets.dat
debezium.source.offset.flush.interval.ms=0
debezium.source.database.hostname=rds-host.net
debezium.source.database.port=3306
debezium.source.database.user=username
debezium.source.database.password=password
debezium.source.database.dbname=dbname
debezium.source.database.server.name=debezium-v2
debezium.source.database.server.id=31
debezium.snapshot.new.tables=parallel
debezium.source.snapshot.mode=schema_only # 초기적재를 하지 않고 띄우기 위해서 schema_only
debezium.source.snapshot.locking.mode=none
debezium.source.include.schema.changes=false
debezium.source.table.include.list=item,user
debezium.source.database.history.file.filename=data/history.dat
debezium.source.database.history=io.debezium.storage.file.history.FileDatabaseHistory
quarkus.log.console.json=false

스냅샷 모드란 디비지움 커넥터가 처음 시작할 때 데이터의 빈로그 포지션과 테이블, 스키마를 읽고 기본값은 initial 이고 schema_only로 하면 스키마의 스냅샷만 가져온다 스냅샷 모드를 해야만 재시작했을 때 이미 저장해둔 빈로그 위치에서 다시 시작할 수 있다
현재 설정값으로는 하나의 스트림 당 하나의 테이블로만 매칭되어있다.
필요한 경우 하나의 스트림에 멀티 테이블 로그 ingest하도록 설정할 수 있다.(SMT 설정을 통해 가능)
설정값에 server.name값에 맞게 스트리밍명을 설정해야함
- ex)debezium-v2.테이블명
파이어호스는 네이밍 규칙은 따로 필요없이 스트림과 이어주면 된다.

TroubleShooting

slave 중복 문제

2022-08-29 12:38:02,327 ERROR [io.deb.pip.ErrorHandler] (mysql:3306) Producer failure: io.debezium.DebeziumException: A slave with the same server_uuid/server_id as this slave has connected to the master; the first event 'mysql-bin-changelog.122640' at 2669334, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.122640' at 2940252, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.122640' at 2940252. Error code: 1236; SQLSTATE: HY000.
	at io.debezium.connector.mysql.MySqlStreamingChangeEventSource.wrap(MySqlStreamingChangeEventSource.java:1189)

server_id가 중복이 되서 생기는 문제 설정 값에서 서버아이디를 임의의 다른 값으로 수정함으로써 해결

Kinesis 스트림 샤드 Rate 초과 문제

2022-08-31 18:03:41,757 INFO  [io.deb.ser.ConnectorLifecycle] (pool-7-thread-1) Connector completed: success = 'false', message = 'Stopping connector after error in the application's handler method: Rate exceeded for shard shardId-000000000002 in stream table_name under account 12345678. (Service: Kinesis, Status Code: 400, Request ID: f9276a90-a2ae-ce2dfd553c4b)', error = '{}': software.amazon.awssdk.services.kinesis.model.ProvisionedThroughputExceededException: Rate exceeded for shard shardId-000000000002 in stream table_name under account 12345678. (Service: Kinesis, Status Code: 400, Request ID: f9276a90-c875-c0a8-a2ae-ce2dfd553c4b)
	at software.amazon.awssdk.core.internal.http.CombinedResponseHandler.handleErrorResponse(CombinedResponseHandler.java:123)
	at software.amazon.awssdk.core.internal.http.CombinedResponseHandler.handleResponse(CombinedResponseHandler.java:79)
	at software.amazon.awssdk.core.internal.http.CombinedResponseHandler.handle(CombinedResponseHandler.java:59)
	at software.amazon.awssdk.core.internal.http.CombinedResponseHandler.handle(CombinedResponseHandler.java:40)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.HandleResponseStage.execute(HandleResponseStage.java:40)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.HandleResponseStage.execute(HandleResponseStage.java:30)
	at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallAttemptTimeoutTrackingStage.execute(ApiCallAttemptTimeoutTrackingStage.java:73)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallAttemptTimeoutTrackingStage.execute(ApiCallAttemptTimeoutTrackingStage.java:42)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.TimeoutExceptionHandlingStage.execute(TimeoutExceptionHandlingStage.java:77)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.TimeoutExceptionHandlingStage.execute(TimeoutExceptionHandlingStage.java:39)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage.execute(RetryableStage.java:64)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage.execute(RetryableStage.java:34)
	at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
	at software.amazon.awssdk.core.internal.http.StreamManagingStage.execute(StreamManagingStage.java:56)
	at software.amazon.awssdk.core.internal.http.StreamManagingStage.execute(StreamManagingStage.java:36)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallTimeoutTrackingStage.executeWithTimer(ApiCallTimeoutTrackingStage.java:80)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallTimeoutTrackingStage.execute(ApiCallTimeoutTrackingStage.java:60)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ApiCallTimeoutTrackingStage.execute(ApiCallTimeoutTrackingStage.java:42)
	at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
	at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ExecutionFailureExceptionReportingStage.execute(ExecutionFailureExceptionReportingStage.java:37)
	at software.amazon.awssdk.core.internal.http.pipeline.stages.ExecutionFailureExceptionReportingStage.execute(ExecutionFailureExceptionReportingStage.java:26)
	at software.amazon.awssdk.core.internal.http.AmazonSyncHttpClient$RequestExecutionBuilderImpl.execute(AmazonSyncHttpClient.java:189)
	at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.invoke(BaseSyncClientHandler.java:121)
	at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.doExecute(BaseSyncClientHandler.java:147)
	at software.amazon.awssdk.core.internal.handler.BaseSyncClientHandler.execute(BaseSyncClientHandler.java:101)
	at software.amazon.awssdk.core.client.handler.SdkSyncClientHandler.execute(SdkSyncClientHandler.java:45)
	at software.amazon.awssdk.awscore.client.handler.AwsSyncClientHandler.execute(AwsSyncClientHandler.java:55)
	at software.amazon.awssdk.services.kinesis.DefaultKinesisClient.putRecord(DefaultKinesisClient.java:1562)
	at io.debezium.server.kinesis.KinesisChangeConsumer.handleBatch(KinesisChangeConsumer.java:113)
	at io.debezium.embedded.ConvertingEngineBuilder.lambda$notifying$2(ConvertingEngineBuilder.java:83)
	at io.debezium.embedded.EmbeddedEngine.run(EmbeddedEngine.java:827)
	at io.debezium.embedded.ConvertingEngineBuilder$2.run(ConvertingEngineBuilder.java:192)
	at io.debezium.server.DebeziumServer.lambda$start$1(DebeziumServer.java:146)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

키네시스 스트림에 샤드를 늘려서 해결

binary log index Error

기존에 사용하던 server.name사용시 io.debezium.DebeziumException: Could not find first log file name in binary log index file Error code: 1236; SQLSTATE: HY000.에러 발생
다른 이름으로 새롭게 스트림 생성 후 연결시 정상적으로 새로운 변경 정보만 가져오는 것

max request size 문제

Caused by: io.debezium.DebeziumException: org.apache.kafka.common.errors.RecordTooLargeException: The message is 3815143 bytes when serialized which is larger than 1048576, which is the value of the max.request.size configuration.
	at io.debezium.server.kafka.KafkaChangeConsumer.lambda$handleBatch$0(KafkaChangeConsumer.java:86)
	at org.apache.kafka.clients.producer.KafkaProducer.doSend(KafkaProducer.java:1064)
	at org.apache.kafka.clients.producer.KafkaProducer.send(KafkaProducer.java:949)
	at io.debezium.server.kafka.KafkaChangeConsumer.handleBatch(KafkaChangeConsumer.java:83)
	... 7 more
Caused by: org.apache.kafka.common.errors.RecordTooLargeException: The message is 3815143 bytes when serialized which is larger than 1048576, which is the value of the max.request.size configuration

토픽 메세지가 기본 값을 초과해서 생긴 문제
debezium.sink.kafka.producer.override.max.request.size 옵션에 적절한 값을 추가
그런데도 설정값이 먹히지 않고 계속해서 같은 에러가 발생
디비지움 카프카 커넥터 버전과 달리 debezium-server의 경우에는 옵션값에 override라는 이름이 생략해야 된다고 함
따라서 debezium.sink.kafka.producer.max.request.size 옵션값으로 시도 후 정상 반영된 것 확인

2022년 결산 및 회고

은유 — Thu, 26 Jan 2023 01:30:15 +0900

2022년을 완주한 나에게

이직한 회사에서 살아남기

딱 이 맘때쯤 회고록 고졸 개발자가 1년만에 당토직야로 이직한 건에 대하여를 블로그에 게시했다. 뭔가 복잡하고 회고록같지 않은 네이밍이지만 이번에는 뭔가 대비되도록 심플하게 2022년 결산 및 회고라는 평범한 제목으로 회고록을 작성하려고 한다.

굳이 부제를 붙이자면 이직한 회사에서 살아남기 정도가 되겠지만 생각보다 글로 적으면 그렇게까지 스펙타클하거나 한 건 없을 것 같아서 단순명료하게 결산 및 회고 정도면 적확하다 싶다.

사실 적응은 이미 상반기에 끝나서 3개월차가 지난 이후로는 무난하게 큰 탈없이 흘러왔다고 볼 수 있다. 남은 나머지는 이제 적응한 베이스를 가지고 새롭게 채워나가고 루틴을 만들어가는 것에 있었는데, 새롭게 이직한 회사에서는 기술적인 베이스도 달랐지만 무엇보다 가장 달라진 방식은 주 5일 전부 근무 환경이 전부 재택이라는 점이다.

회사 처음 입사서 부터 재택이었기 때문에 처음에는 낯설고 적응하기 힘들었지만 이제는 당연한 것처럼 여겨지고 오히려 가끔 밖으로 출근하듯이 나가서 일할 때마다 내가 어떻게 이렇게 출퇴근을 매일같이 했을까 하는 생각이 들정도다.(~~재택없이는 살수없는 몸이 되어버렷..~~)

재택에 시간이 맞춰지면서 출퇴근하면서 생기는 잉여시간이 사라지고 그 시간들을 자기개발에 필요한 것들도 채우고 여러 시행착오를 거치며 루틴화하는 일들을 진행했다.

그레서 가장 큰 수확은 작년에 평일에 헬스장가는 루틴을 제대로 정착시켰다는 것. 그래서 별 일이 없다면 일주일내내 꾸준히 운동할 수 있는 고정화된 시간과 루틴을 확보할 수 있었다는 것이 작년에 가장 큰 수확이라고 할 수 있다.

식단을 하면서 꾸준히 프로틴을 섭취하고 제한하기로 한 것도 비록 1년을 채워서 하지는 못했지만 6개월 이상 지속하면서 루틴에 포함하게 된 것도 성공적이라고 평가할만 하다.

한문장으로 2022년을 표현하자면,

2021년의 한 해는 무언가를 빠르게 이루기 위해서 도망치듯 고군분투하고 발버둥친 해였다고 한다면 2022년의 한 해는 서둘러 도착한 곳에서 숨을 고르고, 서있는 곳을 잘 내딛을 수 있도록 평탄하게 만드는 작업을 하는 해였다고 할 수 있다.

개인 스프린트

작년 부터 매월을 하나의 스프린트를 잡고 매번 회고하며 잘한 점과 못한 점을 짚어가면서 목표를 수정하며 조금씩 이루어 나가고 있다.

단기 스프린트를 잡아서 뜬구름잡는 목표가 아닌 당장 눈앞에 펼쳐진 현실 가능성이 있는 목표들을 골라서 수행해 나가며 하나씩 퍼즐을 맞춰가는 것처럼 장기 목표에 다가가는 것이 목표이다.

물론 회고를 매월 진행했다고해서 당연히 드라마틱하게 삶의 변화가 생겼던 것은 아니다. 회고를 함에도 불구하고 계속해서 미루면서 이월되는 것들도 있었고, 그냥 반성에서 그치며 흐지부지 된 것도 있었다.

가장 대표적으로는 블로그 포스팅이 아무리 적어도 매월 2개씩은 남기자가 목표였는데 작년에는 거의 양손가락에 꼽을 정도로만 포스팅했다. 이렇게 되면 월에 한 개도 채 못올린게 된다.

그래서 올해부터는 이 사태(?)에 대책으로 개발 블로그와 일반 취미 블로그를 분리하고 이곳 개발블로그를 좀더 블로그를 라이트하게 운영해보려고 한다.

하나의 주제에 특화되어 운영하는 게 검색 알고리즘이나 광고를 붙이기에도 좀더 타겟팅이 잘되지 않을까 싶다. 그리고 각 플랫폼 마다 특장점이 있기 때문에 그것을 백분 활용하는 것이 좋을 것 같아서 다방면으로 고심해서 내린 결정이다. 아무쪼록 올해에는 더욱 블로그 활동을 왕성하게 하는 것이 목표이다.

개인 스프린트를 도입해서 잘한 것은 쿠버네티스와 플러터를 책으로 일독해서 공부를 마친 것이다. 비록 많이 이월되기는 했지만 스스로를 채찍질해서 끝까지 완주하도록 노력했다. 결과론적이기는 하지만 스프린트를 나누어서 박차를 가하지 않았다면 이보다 더 많은 아웃풋을 내놓지는 못했을 것 같다.

결산

한 해동안 나의 생산활동과 창작활동에 지대하게 영향을 미친 매체들이다. 영화, 드라마, 예능, 책 등 나열하고 하나씩 BEST와 WORST를 뽑고 살짝씩 코멘트를 곁들이면 돌아보는 의미가 있을 것 같아서 회고에 추가했다.

2022년의 최고의 영화

헤어질 결심

한편을 끝까지 다 마치고도 감정이 진정되지 않고 요동치며 여운을 남긴 영화다. 미장센과 대비가 잘 어울어진 작품이다.

2022년의 최악의 영화

매트릭스 리저렉션

나의 매트릭스에 대한 향수와 경의를 모두 저버리게 만드는 작품이었다. 되돌아보니 한 해의 시작을 매트릭스 리저렉션으로 시작했다니…뭔가 추억이 더럽혀지는 느낌이 들었다.

이제 더이상 새로운 것없이 기믹만 남은 채 계속 명맥을 유지하려는 듯한 느낌이 들었다.

2022년 최고의 TV Show

링컨 차를 타는 변호사 and 이상한 변호사 우영우

변호사물을 개인적으로 좋아하는 것은 차치하더라도 가장 깔끔하고 군더더기없는 기승전결을 보여주었다.

2022년 최악의 TV Show

재벌집 막내아들

최고의 SHOW를 뽑은 것과 정반대로 가장 더럽고 찝찝한 기승전결을 보여주었다. 오직 진회장 연기만 남았던 드라마.

책은 딱히 어떤 걸 베스트나 워스트로 꼽아야할지도 정하기 애매할 정도로 읽은 토대가 얼마 없다…그저 반성하자!

잘한 점

플러터와 쿠버네티스 관련 책도 읽고 정리도 마친 점
식단과 함께 웨이트 트레이닝을 꾸준히 루틴으로 삼고 실행한 것

아쉬운 점

책을 많이 읽지 못했던 것
블로그 포스팅을 많이 하지 못했던 것

새해 목표 및 다짐

스팅어 구매(차량 구매)
~~업무 성숙도 높히기!~~
1. ~~쿠버네티스 도서 한권 더 읽기~~
2. 스파크 완벽 가이드 책 읽기
3. TDD 방식으로 개발해보기
책 10권 읽고 리뷰하기(컴퓨터 도서 포함)
75kg까지 찌우기!(근성장으로!)

작년의 새해 목표와 다짐이다. 사실상 2번을 부분 달성한 것 이외에는 이뤄진 것이 하나도 없다. 차량구매는 뭐 그렇다치더라도 책 읽기는 반성하고 근성장은 조금씩 점진적으로 나아가고 있으니 좀더 세밀하고 현실적인 목표를 세워야할 것 같다.

새해를 맞아, 잘한 것은 계속 유지하고 아쉬운 점은 보완하고 채워나가면서 어제보다 더 나은 내일을 점진적으로 이루어 나가도록 해야겠다.

주말을 잘 활용할 것. 수동적인 자세가 아닌 적극적으로 모임에 참여하자!
매달 컴퓨터 서적 한 권과 책 한 권을 구입하자(다 읽든 안 읽든)
- 책 많이 읽기 최소 15권 이상
블로그 포스팅 최소 월에 2회 이상, 연 24회 이상 달성하기
차량 구매
근골격근 양을 키워서 72kg까지 찌우기
카프카 이해도 높히기
자격증 따기
- AWS 및 컨플루언트
영어 회화 배우기
상반기에 앱 만들어 런칭하기
테니스와 클라이밍 꾸준히 배우기

이번 회고때도 어김없이 하는 말이지만, 블로그를 지켜보며 많은 관심과 감시를 바라는 마음을 끝으로 회고를 마친다.

이제 개발블로그와 일상블로그는 분리되어 운영됩니다

은유 — Mon, 16 Jan 2023 00:46:20 +0900

새해를 맞은 개편사항입니다. 이전에 일상 취미의 영역까지 올라오던 티스토리 블로그가 이제는 개발블로그만 따로 떼어서 운영하게 됩니다.

~~부캐열풍에 힘입어~~

광고 타겟팅 문제도 있고 일상은 네이버에서 개발 및 IT 관련된 이야기는 티스토리에서 나누어서 하는게 플랫폼 특화해서 구분감을 가지고 제가 활동하기 편리하기 위함도 있습니다

이곳에는 인상깊게 느꼈던 IT관련된 뉴스에 코멘트를 달아 포스팅하거나 IT관련된 소식들, 제품과 책 리뷰, 개발관련된 Log들이 적재될 예정입니다.

스킨도 그냥 티스토리 기본스킨으로 돌아갔습니다. 유지보수하기가 벅차서 그냥 제공해주는 스킨을 사용하기로 했습니다..

방식을 바꾼만큼 새해에는 새로운 마음으로 더 많은 포스팅과 질높은 자료를 올리도록 약속하겠습니다.

감사합니다.

2022 Airflow Summit - Implementing Event Based Dags with Airflow

은유 — Sun, 28 Aug 2022 16:44:33 +0900

https://airflowsummit.org/sessions/2022/

에어플로우 2022 summit의 세션중에 Implementing Event Based Dags with Airflow 세션을 번역하고 정리한 내용입니다.

Airflow Summit 2022 sessions

Airflow summit is the premier conference for the worldwide community of developers and users of Apache Airflow.

airflowsummit.org

발표자는 데이터 엔지니어링 컨설턴트
- Astronomer의 리드 엔지니어

time-based scheduling은 새벽5시에 땡하고 출발하는 마라톤에 비유
Event-based triggering은 팀메이트가 나에게 왔을 때 레이스를 시작하는 이어달리기에 비유
그렇다면 airflow에서 그것이 가능한가?→YES!

왜 Event-Based Triggering을 사용해야할까?

애드훅 기반의 많은 어플리케이션에 도움이 된다.
다양한 경우의 머신러닝 오케스트레이션을 위한 에어플로우에 적용할 수 있다.

어떻게 내 DAGs를 Event-Based로 만들까?

TriggerDagRunOperator
- 많은 사람들이 이런걸 지원하는지도 모르는 경우가 많다
- 이벤트가 발생했을 때 같은 환경의 다른 DAG를 트리거함

장점
- 쉽게 구현가능함
- wait_for_completion param값으로 복잡한 dag 의존성을 위한 옵션을 줄수있다
단점
- DAG들이 반드시 같은 환경의 에어플로우내에 있어야 한다

Sensor

airflow 외부에 일어나는 무언가를 기다렸다가 감지해서 작동한다
장점
- 효과적으로 다른 오퍼레이터로 보낼 수 있다
- 많은 use-case로 쉽게 적용가능
단점
- 한번 센서로 이벤트를 받으면 다시 DAGs를 돌릴 수 없다
- 길게 기다리는 sensors는 높은 리소스 코스트를 발생한다
- 당신의 세세한 유즈케이스에 해당하는 sensor가 존재하지 않을 가능성이 있다

Deferrable Operators

airflow 2.2에서 지원

sensor를 기다리는 코스트가 비쌀 때 사용하는 가장 이상적인 sensors
compute 자원을 아끼고 싶을 때 sensor를 사용하는 것처럼 사용하면된다.
장점
- 기존 sensor에 비해서 크게 연산 비용이 절약된다 이는 확장성이나 비용에 도움이 된다
- 쉽게 변경할 수 있다
단점
- triggerer가 러닝중이어야 한다
- 진정한 애드훅을 위한 best option은 아니다

Airflow API

astronomer의 데이터분석팀은 파이썬을 모르는데 API를 만들어서 쿼리를 실행하는 분석 태스크를 summit해서 사용하고있다
장점
- 트리거가 언제 어디서나 최고의 방법으로 구현할 수 있다
- airflow2에서 완전히 Stable하게 Rest API를 지원한다(1.x에서는 experimental이었음)
단점
- 오직 DAG로만 트리거를 요청하기만 하지 콜백을 받지 않는다 그래서 DAG의 상태를 모른다
- 사용하기전에 API auth 설정이 필요하다.

미래에는..

https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-48+Data+Dependency+Management+and+Data+Driven+Scheduling

AIP-48 Data Dependency Management and Data Driven Scheduling - Airflow - Apache Software Foundation

페이지 Airflow Home Airflow Improvement Proposals Skip to end of banner Go to start of banner Skip to end of metadata 작성자 : Vikram Koka, 최근 변경 : Daniel Standish - 8월 06, 2022 Go to start of metadata Background and motivation Airflow has

cwiki.apache.org

AIP 48
- data driven scheduling
- 데이터셋 업데이트에 기반한 DAGs 트리거링
  - 데이터가 추가되거나 제거거나 바뀌면 dag가 이를 추적하다가 실행된다
- 아직은 super early stages 상태
AIP란 Airflow Improvement Proposals의 약자로 에어플로우의 메이저 변경사하을 미리 소개한다.

오픈소스 컨트리뷰션 아카데미 발대식 후기

은유 — Thu, 28 Jul 2022 00:20:05 +0900

지난 주말 9일 토요일 오픈소스 컨트리뷰션 아카데미의 발대식이 진행되었다.
발대식은 말그대로 앞으로의 스케줄과 멘토와 멘티들 서로 얼굴을 익히는 자리였다. 발대식과 별개로 멘토와 멘티들끼리 모여서 앞으로의 계획이나 어떻게 기여할지, 또는 작업할지에 대해서 논의하는 자리기도 했다. 디스코드를 통해서 가볍게 아이스브레이킹도 하면서 경직된 분위기를 살짝 업시키기도 했다.
아쉬운건 바로 다음 발대식이 예약되어 있어서 회의를 채 끝마치지 못한체 자리를 비워주어야 했다는 점이다.
그래도 생각보다 준비해준 다과나 식사, 굿즈 등이 퀄리티도 좋고 맛도 좋았다. 생각보다 돈이 많이 들었을 것 같다는 생각이 들정도다.

오픈소스 컨트리뷰션 아카데미의 공간도 선릉역에 있는데 언제든지 예약하고 프로젝트를 위해 사용할 수 있다는 것도 이 오픈소스 컨트리뷰션 기간동안의 혜택이라면 혜택이 될 것이다.

나는 오픈소스 컨트리뷰션 아카데미가 이번년도에도 한다고해서 거의 모집과 동시에 신청을 했는데, 프로젝트 중에서 Finance Data Reader 오픈소스 프로젝트에 신청했고 운이 좋아서 참여하게 되었다.
https://github.com/FinanceData/FinanceDataReader
작년에 신청했을 때는 떨어져서 아쉬웠는데 이번에는 붙게되어서 감사하는 마음을 가지고 열심히 해야겠다는 생각이 들었다.
오픈소스 컨트리뷰션 아카데미, 그리고 그곳에서 하필이면 왜 Finance Data Reader 프로젝트를 선택하게 되었는가 하면, 먼저 나의 버킷리스트부터 털어놓아야할 것 같다.
여러 버킷리스트들이 있지만 개발자로서 올해의 목표가 하나 있다면 오픈소스 프로젝트에 기여하는 것이 있는데, 이미 조금 알려진 오픈소스 프로젝트들이면 다 그런건 아니지만 대부분 메인테이너가 정해져있고 각 프로젝트마다 기여하는 방법과 팔로우업해야하는 지식들이 천차만별이여서 오픈소스를 사용하다가 발견한 핫픽스급의 버그가 아닌 기능개발같은 것들은 섣불리 접근해서 기여하기란 쉽지 않다.
반면에 오픈소스 컨트리뷰션의 프로젝트들은 메인테이너가 나 컨트리뷰터가 직접 멘토로써 참여하며 다함께 프로젝트를 진행하는 의미도 있지만 무엇보다 같은 개발자들끼리 정보공유도 하고 네트워킹도 하는 형식의 이벤트다.
나는 데이터 엔지니어라는 직군이 아무래도 다른 직군보다는 흔치 않다보니 데이터 직군에 대해서 좀더 세부적으로 설명하고 공유하는 시간을 FDR 멘티들과 나누었다. 내가 가진 경험을 공유하고 나눈다는 것이 이번이 처음이기는 하지만 나름 이것도 오픈소스 정신에 걸맞는 행동이지 않을까 싶은 생각에 뿌듯했다.
행사는 10월 14일까지 계속 이어진다. 멘티들끼리 컨트리뷰션을 진행하면서 중간 보고서도 작성하고 기여하면서 수료증도 받을 수 있다.
아무래도 '아카데미'라는 명칭에서 그렇듯이 하나의 교육과정처럼 진행되는 것 같다. 멘토마다, 프로젝트마다 참여한 멘티나 진행하는 방식이 상이하니 꼭 이 후기만이 오픈소스 컨트리뷰션 아카데미의 전부가 아니니 여러 후기들을 보고 복합적으로 판단하는 것이 좋을 것 같다.
개인적으로 우리팀은 적극적인 멘티들도 많고 멘토분도 자신이 멘티들보다 뛰어나거나 앞서있다는 생각이 아니라 차분히 정리하듯이 함께 프로젝트를 좀더 보조하고 관리한다는 느낌으로 멘티들과 함께해주고 계신다.
개인적으로 핑계일 수도 있지만 직장에 최근 프로젝트 진행하는 것이 있어서 초반에 프로젝트를 좀더 면밀히 살펴보지 못하고 정기회의에도 많이 참석하지 못하서 조금 아쉽다.
앞으로는 좀더 시간내서 적극적으로 찾아보고 딥 다이브해서 프로젝트에 대해서 뜯어보고 기여해볼 수 있도록 노력해야겠다.

(2022.06.01~06.05)서울 국제 도서전 후기

은유 — Mon, 4 Jul 2022 17:34:21 +0900

서울국제도서전은 전국도서전시회로 시작했던 1954년부터 지금까지 70년 가까이 출판사, 저자, 독자가 한자리에서 만나는 우리나라의 가장 큰 책 축제다.

그렇게 오래된 축제임에도 불구하고 내가 서울국제도서전을 알고 참여하게 된 것은 이번이 처음이다. 책에 관심이 있었던 것은 꽤 되었지만 책 박람회가 있다는 것을 알지 못했고 알려고 시도조차 안했다.

그러던 중 뉴닉 뉴스레터를 구독하다가 우연히 서울 국제 도서전이 개최한다는 것을 알았고 과연 책 박람회는 어떨까하는 호기심 반 책에 대한 흥미 반해서 도서전에 참여하게 되었다. 뉴닉또한 서울국제도서전의 부스를 개최하여 이벤트를 진행하고 있었다. 퀴즈를 풀면 소정의 사은품을 증정하던데, 그냥 지나가면서 참여도 안하고 뉴닉 구독자라고도 말안하고 아 여기구나...하면서 지나갔던 기억이 있다.

이런 이벤트가 있었다면 더 일찍이 참여하게 되었을텐데하는 아쉬움도 있었다. 특히 도서정가제 이전...

서울국제도서전은 코엑스에서 개최하게 되었는데, 여느 매체에서 다루듯이 독서율이 점점 낮아지고 관심도 줄어들고 있다는 소식이 무색할만큼이나 정말 많은 사람들이 모였다. 코엑스를 거의 가득 메울정도로 입장 대기줄도 놀이공원처럼 길게 늘어서있고 들어가서도 행사장을 정말 북적거릴 정도로 많았다.

부스 한곳에서는 김영하 작가의 신작을 맞이하여 사인회를 열고있었다. 줄이 금방 길게 서있고 마감도 빠르게 되어서 그냥 먼발치에서 손가락빨면서 사진찍고 구경만 했었다.

중간중간에 글귀 자판기(?)같은 게 있어서 시나 소설 등 자기가 원하는 것을 선택하면 랜덤하게 아주 짤막하게 읽을만한 것들을 즉석에서 출력해준다.

박람회 중에서 제일 흥미롭고 볼만했던 것은 이벤트관들이었다. 책이랑 전혀 연관이 없어보일 것 같았던 배달의 민족에서 하는 글쓰기 이벤트나 책의 기원과 미래에 대해서 연대기를 총 망라한 전시나 주제별로 책들을 묶어서 볼 수 있었던 전시까지 트렌드인 친환경을 주제로 다양한 상품들과 같이 보여주어서 더 흥미로웠던 것 같다.

출판사에서 진행하는 작가와의 미팅이나 팟캐스트처럼 방송도 진행하고 국내 유명한 성우들이 책을 읽어주는 라디오 부스도 인상적이었다.

다만 그 이외에 출판사에서 진행하는 부스들은 조금 아쉬웠다. 도서 정가제때문에 어차피 집에서 인터넷을 통해서 사도 싸게 살 수 있기 때문에 굳이 박람회까지 와서 무겁게 싸들고 집까지 갈 이유가 없었다. 그래서 나도 책 한권도 안샀다.

도서정가제 이전에는 출판사에서 재고라도 털어내려고 많이 할인도 하고 그랬다는데, 정말 그랬었으면 더 기쁜 마음으로 쇼핑백 한가득 들고와서 여기저기 들쑤시도 다녔을텐데 지금 이 시기에 박람회를 알게된게 아쉽다.

결론적으로 이런 이벤트 부스들의 주제가 내게 흥미롭게 다가오거나, 마음에 드는 연사가 강연하는 것이 아니라면 굳이 책 박람회까지 가야할 이유가 없을 것 같다.

물론 내가 우연히 지나치는 모르는 분야의 책들을 알게되는 건 좋았지만 요즘 시대에는 이런 오프라인 이벤트가 아니더라도 다양한 방식으로 읽을 책들을 고를 수 있는 방법은 넘쳐나기 때문에 그닥 큰 메리트라고는 할 수 없을 것 같다.

그래서 도서정가제가 사라지기 전까지는 다음 해부터하는 국제 도서전은 굳이 참여안할 것 같다.

컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 리뷰

은유 — Mon, 27 Jun 2022 00:12:41 +0900

얼핏 책의 제목을 읽어보면 쿠버네티스와 도커에 대한 설명으로 가득할 것 같지만, 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커는 비단 쿠버네티스와 도커에 대한 설명으로 그치지 않고 컨테이너 인프라의 전반적인 환경에 대해 방점을 찍혀있는 책이다.
젠킨스와 프로메테우스 그라파나 등 컨테이너 기반의 환경에서 모니터링과 CI/CD 등 배포까지를 책에서는 담고있다.
폭넓게 인프라 전반적인 환경들을 다룰 수 있다는 점에서는 이 책이 유용하다고 느낄 수 있으나 도커와 쿠버네티스의 핵심만 공부하고 싶은 사람들에게는 사실 그다지 쓸모없는 내용처럼 느껴질 수도 있다.

사실 젠킨스나 프로메테우스와 같은 경우에는 툴처럼 사용하는 경향이 더 커서 핵심적인 내용만 알고 실무에 적용하기를 원하는 니즈가 더 강하게 느껴졌기 때문이다.
베이그런트로 로컬내에 별도의 가상환경을 구축해 쿠버네티스가 돌아가는 원리를 실습을 통해서 확인할 수 있으며 클라우드나 온프레미스 환경의 실제 서버가 존재하지 않더라도 쉽게 로컬 테스트환경에서 쿠버네티스를 사용해볼 수 있도록 쉘스크립트들을 제공한다.
이 스크립트들은 github 저장소를 통해 공개되어 있으며 책에 실습에 필요한 내용들이 담겨있고 책에는 해당 스크립트들에 대한 주석들도 첨부되어 있어서 어떤 원리로 돌아가는지 파악할 수 있다.

다만 최근 클라우드의 기조에 쉽게 쿠버네티스를 클러스터로 구성해서 사용할 수 있기 때문에 굳이 온프레미스 환경에서 인프라를 구축하는 것이 아니라면 너무 과한 설명이기는 하지만 한번 흐름을 쫓아가면서 알아둔다고 해도 나쁘지는 않아 보인다.
다만 개인적으로는 쿠버네티스나 도커에 대해서만 자세히 알고싶었기 때문에 나머지 내용에 대해서는 크게 와닿지 않았다. 오히려 개인적으로는 부록에 담긴 내용들이 더 나에게 실무적으로 도움이 되겠다는 생각이 들었다.

폭넓게 다룬다는 것은 장점이지만 쿠버네티스와 도커에 대해서 심층적으로 알고싶었던 것을 바라고 접한 사람들에게는 실망이 클 수도 있겠다.

ELT 툴 Airbyte 개요 및 M1 mac local환경 세팅

은유 — Wed, 13 Apr 2022 15:13:20 +0900

Airbyte?

데이터 통합을 쉽고 확장가능성 있게 만들어주는 EL(T) Tool
CDC기능을 사용 준실시간성으로 데이터를 가져올 수 있다
비교적 설치가 간편하다
지원하는 데이터 connector들이 많다 DB이외에 페이스북, 인스타그램 등 다양한 SNS과도 연동 가능하며 140개 이상의 커넥터를 지원
T(Transform)부분의 지원이 빈약하다
아직 Hive나 Glue 저장을 지원하지는 않는다
쿠버네티스, 에어플로우, dbt 등과 통합하여 사용할 수 있다.
- ex) airflow + airbyte + dbt on kubernates

Architecture

Airbyte는 플랫폼과 커넥터 이렇게 두가지 컨셉으로 나뉜다.
- 플랫폼은 모든 수평적 서비스들에서 요구하는 설정과 데이터의 움직임을 운영하는(UI, configuration API, job scheduling, logging, alerting 등...)것들을 제공한다.
- 커넥터들은 데이터를 넣고 가져오는 독립적인 모듈이다.
- 커넥터들은 도커 이미지로 패키징 되어있다.

UI: Airbyte API와 상호작용을 통해 쉽게 사용할 수 있는 그래픽 인터페이스
WebApp Server: UI와 API사이에 커넥션을 핸들링
Config Store: 모든 커넥션 정보들을 저장한다(credentials, frequency 등)
Scheduler Store: 스케줄러에 대한상태와 작업정보를 저장
Config API: Airbyte의 메인 컨트롤. sources, destinations, connections, 설정 관리 등 API로 부터 불러와 설정한다.
Scheduler: 스케줄러는 API의 요청에 의해 작업을 수행하고 Temporal service로 병렬적으로 작업을 할당하여 보낸다. 작업의 성공/실패를 트래킹하는 것을 책임진다.
Temporal Service: 스케줄러를 위해서 task queue와 워크플로우들을 관리한다.
Worker: 워커들은 source 커넥터와 연결하여 데이터를 당겨와 destination에 적재한다.
Temporary Storage: 언제든지 디스크에 데이터를 채우고 싶을 때, Worker들이 사용할 수 있는 스토리지

Source

Extract 대상의 연결 목록들을 관리하는 곳

destination

Load 대상의 연결 목록들을 관리하는 곳

connection

등록한 Source와 Destination을 조합해 하나의 Connection으로 연결해서 관리할 수 있다.
sync하는 주기를 설정할 수 있다. (시, 분 단위)
원하는 컬렉션 or 테이블만 골라서 가져올 수 있다.
Overwrite할지 incremental하게 쌓을지 선택할 수 있다.
- 증분형식으로 가져오기 위해서는 primary key 지정이 필수

Quick start

git clone <https://github.com/airbytehq/airbyte.git>
cd airbyte
docker-compose up

webserver: http://localhost:8000
단, M1의 경우에는 일부 이미지가 지원되지 않는 경우가 있어서 arm64 이미지로 새롭게 build된 dev버전으로 실행해야 한다.

requirements for build

Java 17
Node 16
python 3.7 or higher
Docker and Docker-compose
Jq

위 요구사항을 build하기 전에 맞춰준다.

export DOCKER_BUILD_PLATFORM=linux/arm64
export DOCKER_BUILD_ARCH=arm64
export ALPINE_IMAGE=arm64v8/alpine:3.14
export POSTGRES_IMAGE=arm64v8/postgres:13-alpine
export JDK_VERSION=17

M1의 경우 빌드전 환경변수로 arm64로 세팅해주어야 한다. 터미널을 통해 위 변수들을 미리 설정해준다.

SUB_BUILD=PLATFORM ./gradlew build

환경변수들을 적용한 이후에 airbyte root 위치에서 위 명령어로 gradle을 통해서 build해준다.

VERSION=dev docker-compose up

위 명령어를 통해서 m1 실리콘 환경 로컬에서 airbyte를 실행할 수 있다.

데이터 엔지니어의 바이블 빅데이터를 지탱하는 기술

은유 — Fri, 11 Mar 2022 01:00:56 +0900

이 책을 접하게 된 계기

단톡방에서 추천 덕분이었다. 나는 한국 데이터 엔지니어 모임이라는 오픈 채팅방에 속해있는데 과장을 조금 보태서자면그냥 읽기만해도 실력이 쭉쭉 늘어나는 것같이 나에게 좋은 자양분이 되어주는 그런 단톡방이다.

그곳에서 다른 분이 데이터 엔지니어 공부 관련해서 추천하는 도서가 있느냐는 거의 고정적으로 올라오는 질문이 있다. 이 질문에 항상 꼽히는 답변으로 달리는 도서가 바로 이 빅데이터를 지탱하는 기술이라는 책.

책 자체는 2018년에 출간해서 그리 최신의 책은 아니라고 할 수 있다. 그럼에도 불구하고 지금까지 계속해서 회자되며 사람들이 추천하는 이유는 무엇일까.

데이터 엔지니어링의 A to Z를 담았다

가장 눈에 띄는 것은 목차에서 얼핏 느꼈다시피 데이터 분석에서 데이터 파이프라인, 분산 처리 및 수집까지 데이터 엔지니어링의 포괄적인 부분을 모두 넣은 구성이 돋보였다.

데이터 엔지니어링은 다른 직군에 비해서 정립된지 얼마 안되었기도 하고 기존에 백엔드 개발자들이 하던 것들을 더 전문화되고 분업화되어서 등장하게 되었다.

그렇기 때문에 걸쳐놓은 분야가 정말 많다. 백엔드에 필요한 지식, 데브옵스, 데이터 분석, 데이터 사이언티스트 등 다양한 직군에 걸쳐 다양하게 알고 있어야하는 것이 바로 데이터 엔지니어링이라는 직군이다.

자조적인 표현으로 데이터 잡부라는 말이 단톡방 사이에서 있을 정도로 회사마다 데이터 엔지니어가 하는 일은 천차만별이다. 그런 직업의 특수성 때문에 보통 데이터 엔지니어링을 공부한다면 하나의 프레임워크나 기술을 가지고 공부하게 되는데(spark, airflow 등)

이 책은 그 수 많은 범위를 폭넓게 망라하고, 특히 데이터라는 도메인에 대해서 그 발전된 역사를 함께 서술하고 있어서 전반적인 지식을 얻을 수 있다.

예를 들어 하둡이나 하이브의 등장 배경이나 MPP, 분산 처리의 등장과도 같은 데이터 기반 인프라들이 어떤 필요에 의해서 등장하고 발전하게 되었는지를 알 수 있는 것이 가장 큰 장점이다.

고졸 개발자가 1년만에 당토직야로 이직한 건에 대하여

은유 — Mon, 24 Jan 2022 23:25:43 +0900

제목은 작년에 본 애니메이션에서 착안해 약간의 어그로성을 담아보았다.

⛔주의! 제목에 어그로성이 짙지만 사실만을 다루는 회고성 기록물입니다.

⛔주의2! 제목과 달리 이직에 대해 주요하게 다루는 이직기가 아닌 앞서 말했듯이 회고록이므로 이직이나 이직한 회사에 대한 내용은 차후의 포스팅을 참고하시기 바랍니다.

⛔주의3! 스크롤의 압박이 있는 아주 긴 글입니다. 크게 심호흡을 하신 뒤에 스크롤을 내리시기 바랍니다.

2021년을 맞이하며

코로나로부터 2020년 살아남기 회고록을 이후로 벌써 1년이 지났다. 해당 글이 1월 3일에 기록된 것에 비해 약 20여일가량이 지난 지금 회고록이라는 이름이 무색해질만큼 벌써부터 작년의 기억이 까마득해버릴 정도다.

코로나로부터 2020년 살아남기

이글은 회고록의 목적성을 담고 있다. 올해에 겪은 일들과 과정 등을 풀어서 적고, 어떤 것들이 부족했는지, 앞으로는 어떤 것들이 필요한지를 점검하고자 한다. 회고록을 남기게 된 계기 사실

blog.metafor.kr

늦어진 것에는 여러가지 이유가 있긴하겠지만 앞으로 주요하게 적게될 내용인 이직이라는 큰 이슈가 발생한지 이제 막 한달이 넘었기 때문에 이리저리 적응하고 치이느라 생각보다 일정이 딜레이되게 되었다.

그럼에도 불구하고 1월이 지나가기 전까지는 회고를 해야겠지...!라는 마음속의 부채가 키보드를 잡게 만들었고 이번 회고록에서도 어김없이 여러 일련의 사건들과 좋은 점들, 나쁜 점들을 들춰내어서 자축하고 또 점검하며 반성하는 시간을 가져보려 한다.

내게 21년도는 정말 기억에 남는 한 해일 것 같다. 20년도 회고록에도 이직 아니, 다시 재취업하는 내용이 담겼는데 이번 회고에도 이직하는 내용이 담길 줄은 상상도 못했을만큼이나 다사다난했다.

재작년에 회사에 취직했을 때 무난히 몇년동안은 계속 다니리라 예상했지만 사실 스타트업에서 그런 예상은 사치에 가까웠고 급격하게 변동하는 회사 상황에 결국 이직을 결심하고 해가 바뀌어가는 즈음에 맞춰 이직에 성공하게 되었다.

2021년을 맞이하면서 나는 새로운 해 아래서 새로운 회사에서 새로운 환경에 적응해나가고 있다.

커리어에서 스타트업이란

뜬금없이 스타트업의 생존율을 올리는 이유는 그만큼 스타트업에서 자금 확보하는 일과 매출을 벌어들이는 것은 정말로 어려운 일이다라는 것을 말하고 싶었다. 특히 코로나로 인해서 상황이 더욱 힘들어진 지금 하루가 다르게 회사의 사정이 급변한다.

시중에 화폐가 늘어남에 따라 투자자금들이 대거 플랫폼과 IT쪽으로 몰리면서 개발자들의 수요가 급증하고 있음은 물론이지만 코로나의 장기화가 됨에 따라서 사회 전반적으로 매우 힘들다는 것은 사실이다.

강한자가 살아남는 것이 아니라 살아남는자가 강한 것이라는 말처럼 스타트업은 정말로 살아남는 것이 강한 회사인 셈이다.

지금까지 2년차 개발자의 커리어에 2번의 이직. 짧은 커리어 대비 이직이 잦은 이유를 굳이 항변하는 목적이라기 보다는 단순한 개인의 변심에 의해서 회사를 이직하는 것이 아닌 외부적이고 환경적인 요인이 정말 크다는 것을 말하고 싶다. 단순히 확률적으로 내가 불운하다고 여기는 것이 아니라 오히려 스타트업 초기부터 자리잡는 것이 더 어렵다는 것을 알게되니 뭔가 내 잘못은 아니라는 점이 안도가 되었다.

첫번째 회사는 코로나로 인해서 회사가 망하고 마지막 달 월급도 못받아서 노동청에 신고해서 겨우겨우 받았다.

두번째 회사는 지난 회고에서도 적었듯이 너무나 마음에 들었다. 급여적인 측면이나 복지, 사람들 등 하지만 첫번째 투자 이후 투자관련해서 사건들이 많았고 많은 사람들이 퇴사를 했고 상황이, 다들 희망에 차서 다같이 목표를 향해 달려나갔던 처음과는 많이 달라졌다.

그래도 아직 회사에서 내가 할 일이 있을 것이라는 생각에, 데이터 엔지니어를 더 충원해준다는 말에, 사수없이 입사 이후 퇴직할 때까지 혼자서 일을 하다가 결국 가정사적인 사유가 덩달아 터지게 되면서 조금 휴식이 필요해졌고, 대표님에게 지난해 11월달까지만 하고 그만두겠다고 말했다.

청년 내일채움공제도 포기하고, 정말 할 말도 많고 더 하소연도 하고 싶긴 하지만 이전 회사로 인해 알게 된 사람들, 그리고 비즈니스를 통해 알게된 여러 도메인 지식들 등 앞으로 좋은 기억으로만 그 회사를 추억하고 싶다.

#이직

2021년도 가장 큰 해쉬태그를 뽑자면 역시 이직이 되겠다. 표면적으로 보면 이직이긴 하지만 아무것도 행보가 정해지지 않은 상황에서 퇴사를 먼저 결정하고, 이전 회사에서 퇴사하기로 약속하고 마무리하는 대략 한달여 기간동안에 합격까지 일사천리로 통과되어서 퇴사하자마자 거의 바로 일을 하게된 경우라서 엄밀히 따지면 퇴사 확정 이후 재취직이지만 그 텀이 매우 짧았다고 할 수 있다. 물론 이거를 너무 길게 설명하긴 어렵기 때문에 그냥 이직이라고 해두자.

정말 나도 생각치도 못할만큼 빠르게 이직자리가 결정되었다. 사실 그만둔다고 말하면서 조금 휴식을 취하면서 내가 그간 일하면서 못채웠던 부족한 것도 채우고 바빠서 오징어 게임이 그렇게 핫하던데 그것도 보고(아직도 못보고있다), 가족과의 시간도 보낼 심산이었다.

다만 일하는 동안에는 한번도 이직 생각이나 면접을 본적이 없기도하고 데이터 엔지니어 직무로서 지원하는 것은 처음이기 때문에(퇴사한 직장도 백엔드로 지원했다가 들어와서 데이터 엔지니어로 변경된 경우다) 면접에 대한 감과 내 위치에 대해서 가늠하기 위해서 몇 군데 지원서를 넣었다.

지원한 대부분에 붙었었는데, 가장 그래도 이름있고 알려진 서비스들 가운데에서는 변호사와 매칭해주는 플랫폼과 흔히들 이야기하는 네카라쿠배 당토직야 중에서 당토직야. 그중에 한곳이었다.

결론부터 말하자면 그 두 회사가 비슷한 시기에 최종합격을 했었는데, 결국 당토직야 중에 한 곳에 가게되었다. 굳이 콕집어 밝히지 않는 이유는 세 가지가 있는데,

이 회고록은 이직에 대한 내용은 언급하되 그 회사에 대한 내용으로 변질되지 않기를 바라는 마음
또 하나는 아직 이직한지 이제 막 한달이 지나가는 시점에서 무엇을 말해야하는지도 알 수 없고 어디까지 말해야하는지도 몰라 아직은 조심스러운 입장이기 때문
안그래도 길어질 내용이기 때문에 최대한 이직에 대한 이야기를 덜어내고자 함

좀더 명확하게 어떤 것을 어떻게 말해야할지가 나왔을 때, 더 잘 정리해서 많은 사람들에게 이직할 때 어떤 과정을 거쳤는지를 따로 공유하고 싶다.

다시 돌아와 이야기를 계속하자면 지금의 회사에 데이터 엔지니어 직무로 입사하게 되었다. 백엔드에서 데이터 엔지니어로 직무를 변경한지 1년만에 이직을 하게된 셈이다. 비록 백엔드로서의 직무 경험이 있긴하지만 거의 6개월도 안됐었기도하고(지난 회고록 참조), 보통 2-3년차를 시장에서 많이 찾게 되는 것에 비하면 굉장히 운이 좋은 케이스라고 할 수 있다.

이 결과가 어느정도 눈에 보이는 성과로써 마주하게 된 것 같아서 나름 그간 해왔던 일들이 틀리지는 않았구나하는 안도감으로 되돌아온다.

이직을 결심하게 된 이유?

사실 앞서서 이야기한 것처럼 당장 회사를 급하게 구하려는 마음도 없었고 지금의 회사를 가장 최우선 순위로 고려한 부분 또한 아니었다.

다만 그간 짧지만 여러 번의 회사를 거치며 회사를 보는 조건이 살짝 달라졌다. 내가 아무리 욕심이 있고 목표가 확고해도 환경이 안정적이지가 않으면 그 흐름과 추세가 다소 꺾일 수 있다는 점이다. 아무리 내가 열심히하고 상황을 무시한다고 하더라도 주변에서 아무래도 회사에 대해서 부정적인 입장들이 많아지게 되면 나도 혹하게 되고 동요하게 되는 것은 사람의 심리상 어쩔 수가 없는 부분이다. 다른 것들을 신경쓰지않고 일만하고 싶다는 이 단순하지만 명확한 요구사항이 국내 스타트업에서는 정말로 힘들고 어려운 조건이라는 것을 이번 기회에 깨달았다.

그렇다보니 앞으로 회사를 고를 때의 조건이 조금 바뀌게 되었다.

인지도나 매출, 투자가 안정된 곳
같이 일하는 동료가 있어서 그 동료가 나보다 실력이 뛰어나거나 그렇지 않더라도 크로스체크를 해서 피드백을 할 수 있는 환경

그래야만 내가 오롯히 일에 집중하고 또한 팀원들을 통해서 성장하는 원동력으로 삼을 수 있을 것 같았다.

그런 점에서 내가 이번에 선택한 이 회사는 인지도면에서, 팀적인 측면에서 내 요구사항을 모두 채워줄 수 있었다.

무엇보다 대우가 좋았다. 물론 당연히 더 준비해서 내가 정말로 마음속에 품고 지망했던 회사에 들어가 더 좋은 대우를 받으면 가장 베스트였겠지만 지금까지 오퍼를 포기하고 그런 선택을 한다는 것은 너무 자만이자 오만이었고, 지금의 제안보다 더 좋은 대우를 해줄 것이라는 보장도 없는 모험이었다.

잘한 점

뭔가 결과만 늘어놓으면 자기 자랑처럼 변해버릴 것 같아서 그간 커리어를 위해서 준비했던 것들을 작년에 잘한 점에 넣어서 추가해보려고 한다.

일단 회사일을 기본적으로 완벽하게 수행하려고 노력했다. 일을 시작하기 앞서 주어진 일을 어떻게하면 Best Practiction으로 구성할 수 있을까를 고민하고 관련된 레퍼런스들을 다양한 방면에서 접하고 노출시켰다. 예를 들어 한국 데이터 엔지니어 오픈톡방에 들어가서 눈팅하며 필요한 지식을 주워듣고 내가 대답할 수 있는 질문에는 대답도 달고 반대로 궁금한 것들은 질문도 올리면서 다양한 데이터 엔지니어분들과 소통했다.

Druid관련 밋업이나 AWS 밋업 카카오 개발자 컨퍼런스 등도 꾸준히 참여해서 기술에 대한 트렌드도 팔로우업했다. 다행이 작년에는 전부 온라인 컨퍼런스라서 다시보기로 여러번 되돌려보거나 편한 시간에 시청할 수 있어서 좋았다.

소규모 스타트업에서 나의 강점을 키우는 일

앞서 너무 소규모 스타트업에 대해서 부정적으로만 이야기했던 것 같은데, 그렇다고해서 내가 했던 일이나 스타트업에 대해서 부정하는 것이 결코아니다. 다만 이런 것도 겪었으니 앞으로는 이런 환경에서 일하는 것을 희망한다는 관점에서 부연설명을 했었던 것이고 그간 내 실력이나 이직함에 있어서 이 회사에서 했던 일이 당연히 나에게 가장 큰 영향을 미치고 도움을 줬던 것은 부정할 수 없는 사실이다. 항상 상대적인 관점에서 지금의 위치에서 최선의 방향으로 나가는 방법을 모색하는 것이 성장에 가장 필요한 요소라는 생각이 든다.

일단 인적리소스가 충분하지 않은 상황이고 지원도 확실하지 않은 상황이기 때문에 나 혼자 많은 것들을 처리한다. 나쁘게 말하면 R&R이 명확하지 않다고 볼 수 있지만 반대로 생각하면 AtoZ까지 모두 내가 설계하고 고민하며 평소에 시도해보고 싶었던 것들을 빠르게 도입하거나 반영할 수 있다.

다른 회사에서 1년차 개발자는 여러 프로세스에 막혀서 전혀 해볼 수 없는 일들을 여기서는 자유롭게 시도해볼 수 있었다.

보통 면접에서의 질문들은 이력서에 적혀진 이전 커리어에서 맡았던 프로젝트나 업무 위주로 질문을 한다. 혼자서 여러 레퍼런스들을 보며 검증하고 직접 벤치마크들도 비교해보면서 선택한 아키텍처들이기 때문에 다양한 바리에이션의 질문들에도 비교적 능숙하게 대답할 수 있었고 상세하게 전후 과정들을 쭉 망라해서 설명할 수 있었다.

예를 들어 “이런 방식도 가능할텐데 왜 이런 방식으로 하게 되었나요?”

“이 프레임워크 혹은 라이브러리를 선택하게 된 이유가 있나요?” 등 면접에서 자주 듣는 패턴의 질문인데, 따로 질문에 대해서 준비하지 않아도 경험으로 이미 체득한 부분이 있어서 자연스럽게 술술 대답했었던 것 같다. 아마 이런 점때문에 면접에서 플러스 요인이 있었지 않았나 싶다.

물론 그렇게하기까지의 과정은 결코 쉽지 않았다. 거의 매일같이 평균적으로 8시까지 회사에 남아서 야근한 날이 야근안한 날보다 더 많았고 퇴근을 해서도 따로 전공서적을 보며 노션에 정리했다. 에러로그나 기술관련 된 내용들을 블로그에 정리해서 틈틈이 포스팅하는 것도 이러한 과정에 포함된다.

모든 사람이 나와같은 상황이 아니고 이 방법이 모두에게 같이 적용되는 것이 아니라 반드시 야근을 해야만 한다고 권하는 글을 아니지만 집에 돌아오면 확실히 의지력이 약해지기도 하고 일의 구분감을 두기 위해서 나는 웬만하면 회사에서 전부 끝마치려고 노력하는 편이다.

그리고 알고리즘 스터디를 따로 마음이 맞는 친구와 일주일에 1회 진행했는데, 사실 퇴사를 하고 휴식과 겸해서 제일 보충하고 싶었던 부분이 바로 이 알고리즘 파트였다. 그정도로 그간 일에 치여 알고리즘 문제를 거의 못풀어서 많이 약했던 부분이었는데 그 점을 스터디를 진행하면서 감각을 끌어올리는데 집중했다.

알고리즘을 공부하는 것에는 여러가지 이유가 있었기는 하지만 가장 큰 이유는 1차 코딩테스를 통과하기 위해서다. 기술면접에서는 자신있게 대답할 준비가 되어있었지만 거기까지 가지 못한다면 내가 가진걸 보여주지도 못하고 끝나게 된다. 물론 테스트를 봤던 기업들이 그렇게 어려운 난이도를 요구하는 것들이 아니었지만, 그마저도 준비를 안해서 떨어져서 아예 나에 대해서 말하고 어필할 수 있는 기회조차 박탈당해버린다면 너무 아쉬울 것 같았다. 내가 가진걸 보여주기 위해 반드시 넘어야하는 허들, 내게 알고리즘은 그래서 더 중요한 문제였다.

스터디 진행 방식은 일주일간 서로 알고리즘 문제를 한 문제씩 풀어보고 스터디 당일 날 서로 그 문제를 바꿔서 20분정도 시간 제약을 둔 후 풀어본 다음에 설명해주는 것이 스터디 진행 방식이었다.

처음에는 정말 피지컬로만 문제를 풀다가 점점 한계를 느끼고 알고리즘 개념도 덫붙혀서 서로에게 설명하고 하나씩 배워나가다보니 기본적인 문제에 대해서는 어느정도 자신감을 얻게 되었다. 물론 여전히 알고리즘 문제에 대해서는 부족함을 많이 느끼고 있고 아직도 여전히 채워나가야 하는 것들 중에 하나다.

정리하자면...

스타트업의 유연함을 100% 활용하여 기술들을 적용하고 고민해본 것
회사에 매일 8시까지 남아 야근하면서 업무와 업무에 필요한 지식을 스터디
에러로그나 기술관련 블로그 포스팅
퇴근 이후에도 한시간 정도 관련 도서를 읽으며 따로 공부를 진행
친구와 함께 매주 알고리즘 스터디를 진행

방문자 수 10만명 돌파!

작년에 목표로 했던 21년도 누적 방문자수 10만명 돌파해 어느덧 14만명을 향해 달려가고 있다. 올해는 20만을 목표로 계속해서 이 텐션을 유지해보려고 한다.

운동도 나름 쏘쏘

코로나 때문에 헬스장이 간헐적으로 닫아서 운동을 좀 해볼만하면 닫고 다시 몸이 돌아올만하면 닫고해서 지속적으로 운동하기가 힘들었었는데, 작년 하반기부터 위드 코로나를 하기도 하고 백신도 맞고해서 이제 다시 꾸준히 어느정도 헬스에 다시 다니기 시작했다.

저번 목표로 한 3대 250은 사실 혼자서 1rm을 측정하기가 상황이 여의치가 않아서 이번에는 좀더 수치적으로 확실하게 확인할 수 있는 목표로 재설정할 생각이다. 지금 68에서 70kg을 왔다갔다하는데 근성장을 해서 75kg으로 증량하는 것이 목표다.

아쉬운 점

역시나 매해 계획에 책을 읽겠다고 적어놨지만 21년도에는 컴퓨터 관련 서적 외에는 단 한권밖에 읽지 못했다. 전공서적을 포함하더라도 원래 목표했던 10권에는 턱없이 모자라는 수치이다. 아무리 일이 바쁘고 이리핑계 저리핑계를 대더라도 매해가 갈수록 점점 줄어들어서 올해에는 아예 0에 수렴하게 될지도 모른다는 생각이든다. 10권정도는 실현가능한 목표라고 생각했었는데...

그 이외에 목표로 했던 데이터 엔지니어 숙련도 올리기와 리액트 공부하기는 애매모호하게 표현했기 때문에 일부 참작의 여지는 있다. 숙련도나 공부한다는 것의 지표가 상대적이기 때문에 어떻게보면 숙련도를 올렸다고 볼 수 있고 리액트 공부도 책을 끝까지는 아니어도 중간이상 봤어서 진행했다고 볼 수 있기 때문이다.

뭐 일단 핑계긴 하지만 아무튼 올해 목표는 이걸 반면교사 삼아서 좀더 구체적이고 실현가능한 목표들을 통해 스프린트를 나누고 체계적으로 하나씩 이루어나갈 생각이다.

막연하게 1년에 10권!이 아니라 월 단위, 주 단위로 나누어서 어떤 책을 어떤 순서로 읽어나가야 할지를 플래닝하고 실시간으로 플랜들을 상황에 맞춰서 수정해나가면서 최종 목표에 까지 도달할 생각이다.

이번 년도부터는 업무뿐만이 아니라 개인 계획에도 애자일을 도입하고 한달 단위로 회고 시간을 가지며 플래닝을 수정하고 계획하는 시간을 갖도록 해야겠다.

22년도 목표 및 다짐

어김없이 새해의 새 가 떴다. 새 술은 새 부대에 담으라고 했다. 그간 회고를 해오면서 느꼈던 계획에 대한 현실적인 감각을 되찾았다. 꿈을 크게 갖는 것은 좋지만 너무 이게 장기화되면 무감각해지고 목표에 대해서 감흥이 사라진다. 그래서 올해부터는 지킬 수 있는 최소한의 것들을 세우고 그것의 세부항목들을 넣어서 짧게 퀘스트를 깨는 느낌으로 성취율을 가져가면서 오래 꾸준히 이루어낼 수 있도록 긴 플랜을 짜야겠다.

스팅어 구매(차량 구매)
업무 성숙도 높히기!
1. 쿠버네티스 도서 한권 더 읽기
2. 스파크 완벽 가이드 책 읽기
3. TDD 방식으로 개발해보기
책 10권 읽고 리뷰하기(컴퓨터 도서 포함)
75kg까지 찌우기!(근성장으로!)

올해에도 어김없이 남발한 약속을 지킬지 안지킬지, 관심을 가지고 블로그를 지켜보며 많은 관심과 감시를 바라는 마음이다. 정말 다사다난했던 2021년 한해였다. 과연 올해는 무탈히 그리고 행복하게 지낼 수 있을 지 벌써부터 걱정반 기대반이다.

분산 쿼리 엔진 prestoSQL의 바뀐 이름 Trino

은유 — Tue, 4 Jan 2022 00:31:47 +0900

귀엽다...

Trino? 처음듣는데?

페이스북 내부 직원 약 1,000명은 Presto를 매일 페타바이트가 넘는 데이터를 스캔하는 30,000건이 넘는 쿼리를 페이스북 데이터를 조회하는데 사용하고 있다.
presto는 페이스북이 최초 개발하여 오픈 소스로 공개한 대화식 데이터 쿼리 서비스. 이를 이용해 다양한 데이터베이스에 대한 일관된 ANSI SQL 질의가 가능하다.
빠른 속도를 보장하기 위해 엔진 레벨에서 분산 컴퓨팅 기법이 사용된다.
2020년 12월 27일 Presto 초기 멤버들이 페이스북을 나와 만든 PrestoSQL 프로젝트가 Trino로 리브랜딩 됨
- 350버전 이후로 prestoSQL에서 Trino로 완전히 이름이 바뀜
Amazon은 presto 0.172 기반으로 시작해 자체 개발한 Amazon Athena 서버리스 상품을 제공하고 있다. 기능적인 건 presto나 trino에 비해 부족하지만 인프라 구성에 신경쓰지 않고 매니지드하게 다룰 수 있는 장점이 있음

Trino v.s. PrestoDB

What's the Difference Between Trino and PrestoDB?

What’s the Difference Between Trino and PrestoDB?

Read on to find out more about Trino and PrestoDB, what makes them unique, their differences, and discover which solution is better.

pandio.com

위 글은 제목은 비교하는 글이지만 막상 내용은 Trino를 추천하는 단락이 더 많다.
prestoDB 용량 1.1G v.s. Trino 용량 607MB
Trino는 제한적이지만 Oracle Connector를 사용할 수 있음(2020년 말부터는 PrestoDB도 Oracle Connector 지원)
정리하자면 presto의 핵심 개발자들이 참여하는 Trino의 오픈소스 활동이 더 활발하고 다양한 DB에 대한 지원과 편의성이 빠르게 늘어나며 최적화 되어있어서 Trino를 더 권장

Config

https://trino.io/docs/current/installation/deployment.html

Deploying Trino — Trino 367 Documentation

Deploying Trino Requirements Linux operating system 64-bit required newer release preferred, especially when running on containers adequate ulimits for the user that runs the Trino process. These limits may depend on the specific Linux distribution you are

trino.io

coordinator와 worker

트리노는 2가지 타입의 서버가 있다 코디네이터와 워커
코디네이터는 쿼리를 플래닝하고 워커 노드들을 매니징한다.
테스트 목적으로는 싱글 인스턴스에서 코디네이터와 워커 두가지 역할을 동시해 하도록 할 수 있지만 그렇지 않은 경우에는 코디네이터 하나에 워커 하나 또는 그 이상을 함께 설치해야한다.
코디네이터는 워커와 클라이언트들과 REST API를 사용해서 통신한다.
워커들은 task들을 수행하고 데이타들을 프로세싱한다.
코디네이터들은 워커들로부터 받은 결과들을 최종적으로 클라이언트에 리턴해주는 것을 담당한다.

config.properties

기본적으로는 단일 노드로 돌아가지만 프로덕션 레벨에서는 코디네이터와 워커로 따로 분리해서 trino를 실행한다.
코디네이터 역할을 하는 노드는 아래 configure를 적용해서 실행하고 워커 역할을 하는 노드에서는 두번째 configure를 적용해서 실행하면 된다.

coordinator minimal configuration

coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=8080
query.max-memory=50GB
query.max-memory-per-node=1GB
query.max-total-memory-per-node=2GB
discovery.uri=http://example.net:8080

worker minimal configuration

coordinator=false
http-server.http.port=8080
query.max-memory=50GB
query.max-memory-per-node=1GB
query.max-total-memory-per-node=2GB
discovery.uri=http://example.net:8080

node.properties

각 노드들의 설정, 노드 아이피 명시, 환경명 명시(클러스터들끼리 동일한 환경의 이름을 가져야함)
production일 경우 환경명을 production으로 수정해서 사용

node.environment=development
node.data-dir=/data/trino

jvm.config

jvm 메모리 설정

-server
-Xmx16G
-XX:-UseBiasedLocking
-XX:+UseG1GC
-XX:G1HeapRegionSize=32M
-XX:+ExplicitGCInvokesConcurrent
-XX:+ExitOnOutOfMemoryError
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-XX:ReservedCodeCacheSize=512M
-XX:PerMethodRecompilationCutoff=10000
-XX:PerBytecodeRecompilationCutoff=10000
-Djdk.attach.allowAttachSelf=true
-Djdk.nio.maxCachedBufferSize=2000000

log.properties

log level 설정

io.trino=INFO

hive.properties

AWS glue 메타스토어 연결

connector.name=hive-hadoop2
hive.metastore=glue
hive.metastore.glue.aws-access-key=
hive.metastore.glue.aws-secret-key=
hive.s3.aws-access-key=
hive.s3.aws-secret-key=
hive.allow-drop-table=true

Dashboard

docker로 간단하게 단일 노드의 trino를 시작할 수 있다.
위 config를 적용하기 위해서는 로컬의 디렉토리에 config들을 작성 후에 마운트해서 -v 옵션으로 docker를 실행해주면 된다.
코디네이터와 워커를 분리해서 실행하고 싶다면 docker-compose를 이용해서 이어주도록 하자.

docker run -p 8080:8080 trinodb/trino

localhost:8080로 접속하면 대쉬보드를 확인할 수 있다.

Client

JDBC를 통해 클라이언트에서 원격 연결이 가능하다. 아래 사진은 DBeaver에서 trino를 연결하는 방법

새로운 커넥션을 추가할 때 trino로 검색하고 다음을 누른다.

docker를 통해 포트포워딩으로 로컬의 8080과 JDBC로 연결하고 완료를 누른다.

연결을 위한 드라이버 라이브러리를 설치한 후에 접속할 수 있다.

airflow의 새로운 경쟁자 오케스트레이션 플랫폼 dagster

은유 — Thu, 23 Dec 2021 23:42:52 +0900

orchestration platform을 강조하고 있다.

Open Source Data Stack Conference

아래 내용은 위 동영상의 내용을 번안하고 정리한 내용입니다.

위 사진의 기술들은 다양한 방식들로 서로 의존성이 존재한다. 예를들어 스노우플로우나 다른 데이터 웨어하우스에서 데이터가 만들어지기 전까지 dbt를 실행할 수 없다. 그리고 dbt가 그것의 모델을 업데이트하기 전까지 Grouparoo같은 리버스 ETL은 새로운 정보를 적재할 수 없다.

이런 의존성들간에 Ordering과 Excute를 조율하는 것이 오케스트레이션의 목적이다.

왜 dagster여야 하는가?

전통적인 오케스트레이션은 스케줄링과 실행을 통합하는 시스템과 가시적이고 알림을 운영할 수 있어야 한다. 여기에 더해져서 덱스터는

유용한 metadata를 생성하는 과정에서 데이터가 어디를 통과하는지 충분히 수치화해서 보여준다.
오케이트레이션 레이어에서 생산성을 늘리기 위해서 덱스터가 코드를 실행하기 위해 편리하게 만들어진 프로덕션 레벨의 데이터베이스를 건들지 않는 api로 테스트를 할 수 있다.
파이프라인을 디버그하고 작업하는 ui가 쉽고 재밌다.
중앙 집중형으로 시스템들을 기록할 수 있다.

dagster의 기본적인 개념

~~Dagster에서 Job들은 solid로 표현되며 workflow는 pieline으로 구현~~
- 최근 버전에서 solid가 op로 pipeline이 job으로 명칭이 변경되면서 하나의 낱개 task들은 op로 이어놓는 workflow들은 job으로 구현한다.
각각 op와 job은 데코레이터로 정의된다.
하나의 스크립트에 다수의 pipeline을 포함할 수 있으며 이를 통해 여러 workflow를 구현 가능하다→이런 스크립트 하나를 repository라 정의
각각의 op는 별도의 input과 output을 가질 수 있으며, solid간 변수 상속이 가능하다.

airflow와 비교 및 차별점

dagster는 오케스트레이션을 표방하고 airflow는 monitor workflow를 표방한다.
airflow는 추상화된 클래스 객체를 오버라이딩하거나 상속받아서 dag를 작성하는데 사용하지만 dagster는 데코레이터를 사용해서 함수를 기반으로 job을 작성한다.
airflow는 dag의 워크플로우를 구성할 때 >> 를 통해 방향성을 결정하지만 dagster는 정의해놓은 함수에 인자를 태움으로써 방향성을 결정한다.
airflow에서는 task간 변수 상속이 x-com을 통해서 가능하긴 하지만 메모리 등 어느정도 제약점이 존재하지만 dagster는 op간 변수 상속이 용이한 점
airflow에서는 비교적 힘들게 UTC기준으로 된 타임존을 변경했었는데 dagster에서는 timezone을 지원해서 쉽게 데코레이터의 파라미터로 타임존을 입력하면 쉽게 스케줄링을 걸수있다.

DEMO

dagster는 python 3.6이상의 환경에서 원활히 활용할 수 있으며 3.8, 3.7, 3.6에서 정상적으로 작동되는 것이 확인됨

pip install dagster dagit

python pip를 통해서 설치

Dagster: 싱글 노드, 싱글 프로세스와 멀티 프로세스 실행 엔진, 엔진들을 실행하기 위한 CLI 툴
Dagit: DAG browser를 포함한 개발, jobs 운영 UI. config editor, 라이브 실행 인터페이스

Single-Op Job

op는 job의 한 부분이다. 일반적으로 op들은 @op decorator와 함께 python function을 어노테이팅하는 걸로 정의할 수 있다.

아래 op는 CSV를 다운로드하고 CSV의 row들과 로그들의 row들을 딕셔너리 리스트로 불러서 읽는 작업을 한다.

import requests
import csv
from dagster import job, op, get_dagster_logger


@op
def hello_cereal():
    response = requests.get("https://docs.dagster.io/assets/cereal.csv")
    lines = response.text.split("\n")
    cereals = [row for row in csv.DictReader(lines)]
    get_dagster_logger().info(f"Found {len(cereals)} cereals")

    return cereal

@job
def hello_cereal_job():
    hello_cereal()

dagit -f 파일명.py

콘솔에서 위 명령어를 통해서 job을 비주얼라이즈할 수 있다.

dagster job execute -f 파일명.py

위 명령어로 이벤트를 스트림하게 처리하며 내부적인 로그를 확인할 수 있다.

Complex DAG

import csv

import requests
from dagster import get_dagster_logger, job, op


@op
def download_cereals():
    response = requests.get("https://docs.dagster.io/assets/cereal.csv")
    lines = response.text.split("\n")
    return [row for row in csv.DictReader(lines)]


@op
def find_highest_calorie_cereal(cereals):
    sorted_cereals = list(
        sorted(cereals, key=lambda cereal: cereal["calories"])
    )
    return sorted_cereals[-1]["name"]


@op
def find_highest_protein_cereal(cereals):
    sorted_cereals = list(
        sorted(cereals, key=lambda cereal: cereal["protein"])
    )
    return sorted_cereals[-1]["name"]


@op
def display_results(most_calories, most_protein):
    logger = get_dagster_logger()
    logger.info(f"Most caloric cereal: {most_calories}")
    logger.info(f"Most protein-rich cereal: {most_protein}")


@job
def diamond():
    cereals = download_cereals()
    display_results(
        most_calories=find_highest_calorie_cereal(cereals),
        most_protein=find_highest_protein_cereal(cereals),
    )

순차적이지 않은 다이아몬드형태의 복잡한 DAG구성의 예제
이 예제를 실행하면 donwload_cereals가 가장 먼저 실행되고 뒤이어서 find_highest_calorie_cereal과 find_highest_protein_cereal이 동시에 실행된고 display_result가 마지막으로 실행된다

dag+ster

dagster란 네이밍에서도 알 수 있듯이 dag와 dag를 실행시킨다는 접미사를 붙인다는 네이밍으로 합쳐져서 덱스터라는 이름이 등장한 것 같다.

프로덕션 레벨에서는 위와 같이 튜토리얼 처럼 cli로 실행하는게 아니라 yaml파일로 제공하는 데몬을 띄워서 웹서버와 스케줄러 등을 msa로 나누어서 실행하고 레포지토리들을 storage에서 불러와서 실행하게 된다.

단순히 컨퍼런스의 데모영상을 보고 직접 튜토리얼을 진행하면서 느낀점은 airflow에 비해서 UI가 깔끔하고 리얼타임으로 진행상황을 간트차트로 확인할 수 있다는 정도, 나머지는 좀 불편하긴 하지만 airflow에서도 다 구현이 가능한 부분이라서 굳이...?라는 생각이 든다.

함수를 기반으로 dag의 종속관계를 짜야한다는 것도 조금 한 몫하는 것 같다. 다만 dbt나 멜타노 같은 환경들을 같이 사용한다면 좀더 시너지있고 통합적으로 활용 가능성이 많다는 점은 앞으로 두고봐야할 것

[에러로그]parquet파일 변환 fastparquet v.s pyarrow

은유 — Fri, 19 Nov 2021 16:06:42 +0900

에러 내용

parquet로 변환한 파일을 read해서 확인했을 때 일부 컬럼의 로우 값이 제대로 인코딩되지 않은 문제가 있다.
다른 컬럼의 값들은 정상적으로 표출되었지만 특정 컬럼에서만 이상이 생기는 것을 확인했다.

to_parquet 메소드

pandas 라이브러리에서 to_parquet 메소드를 사용해서 데이터프레임을 parquet 포맷으로 변경할 때, 사용할 수 있는 엔진의 옵션은 두 가지가 있다.

pyarrow와 fastparquet이 바로 그것인데, pandas 내부적으로 이 두 라이브러리들을 가져와서 parquet파일로 변환하게 된다.

라이브러리를 선택하는 방법은 engine 파라미터에 해당하는 라이브러리명을 적어주면 된다.

df.to_parquet("test.parquet", engine="pyarrow")
# or
df.to_parquet("test.parquet", engine="fastparquet")

압축 속도는 벤치마크상으로 pyarrow가 압도적으로 높지만 기본적인 라이브러리 자체의 용량이 100배나 차이나기 때문에 트레이드오프를 잘 따져서 두 엔진 중에 상황에 맞게 선택하면 될 것 같다.

A comparison between fastparquet and pyarrow?

After some searching I failed to find a thorough comparison of fastparquet and pyarrow. I found this blog post (a basic comparison of speeds). and a github discussion that claims that files crea...

stackoverflow.com

문제원인

문제가 생겼던 특정 컬럼의 형식은 array였다.
fastparquet 공식 문서에 따르면 간단한 데이터들과 plain encoding만을 지원한다고 한다. 이는 복잡한 데이터들에는 array도 포함되어있다는 뜻이었다.

How to write a Dask dataframe containing a column of arrays to a parquet file

I have a Dask dataframe, one column of which contains a numpy array of floats: import dask.dataframe as dd import pandas as pd import numpy as np df = dd.from_pandas( pd.DataFrame( { ...

stackoverflow.com

결론

따라서 형이 다양한 데이터들과 인코딩 된 데이터셋을 사용한다고 한다면 pyarrow 엔진으로 parquet 파일을 생성하자

재택근무를 희망하는 히치하이커를 위한 안내서

은유 — Sun, 17 Oct 2021 20:18:50 +0900

달콤했던 재택근무를 떠나보내며

어느새 코로나 일별 확진자 수가 3천명을 넘겼다는 소식이 뉴스를 통해 들리고, 몇 주째 2천여명 밑으로 떨어질 기미가 보이지 않는다.

예전에 1,000명을 넘겨도 직장 동료들과 친구들끼리 서로 걱정하며 안부를 전하던 것이 무색할 만큼 후반부 드래곤볼의 전투력 인플레이션마냥 이제는 2000명 정도는 “크큭, 고작 그 정도 수치인가?”속으로 코웃음치며 무뎌져 간다. 물론 그렇다고 이러한 상황에 대비하지 않는 것은 아니다. 백신 1차 접종도 받고, 어지간하면 집 안에서 해결하고 약속도 거리 두기 단계에 맞춰서 많은 인원 수가 모이는 모임같은 경우는 지양했다. ~~집돌이인 성향도 한 몫하긴 했지만~~

호오 고작 그정도 수치인가요

지금까지 간헐적으로 회사에서 재택을 하기는 했지만 이런 외부 상황과 나의 개인적인 사유를 덫붙혀 회사의 배려로 비교적 긴 기간동안 재택을 하게 되었다. 나름 합치면 두 달여간이 얼추 되어가는 재택 기간 동안에 기존 회사에서 출퇴근 형식으로 하던 것과 원거리로 근무를 하는 것 어느정도 적응이 되려고 했는데 내게 허락된 재택의 시간이 끝나가고 있다. 그렇지만 그렇게 크게 아쉽지는 않다. 문맥상 재택근무의 앞에 달콤했다고 표현하기는 했지만 나는 이 둘을 우열을 나누는 것이 아니라 서로 대등하고 보완적인 관계로 보고 그간 양쪽다 겪으면서 느꼈던 득과 실, 명과 암에 대해서 명명백백히 가려보려고 한다.

재택 근무가 활성화 되는 시점과 계기는 당연히 누가 뭐라고 해도 코로나를 기점으로 관련 산업들이 폭풍적으로 성장한 것이리라. 줌과 디스코드, 구글 밋업, 게더타운 등 다양한 곳에서 이를 지원하는 서비스들이 대기업에 인수되거나 주식 시장에서 큰 성장세를 보이기 시작한지 꽤 오래되었다. 특히 IT기업들은 이미 한 번이라도 도입한적이 있거나 이미 지금도 부분 및 전체 재택으로 전환한 기업도 많다. 서비스나 반드시 대면으로 작업해야만 하는 직종에서는 피치 못하게 계속해서 출퇴근을 하고 있지만 그렇지 않은 직업군들은 재택 도입에 대해서 검토하는 수준을 벗어나 적극적으로 도입하고 테스트하고 있다.

내가 다니는 회사에서도 초반에는 그런 기업들 중에 하나였다. 그래서 코로나가 한창이었을 때(지금도 한창이기는 하지만)시범삼아 2주간 재택에 들어갔다. 하지만 그때는 그저 전체 공지로 언제부터 언제까지 재택하기로 했다고 일방적이고 갑작스러운 통보로 이루어진 재택이었기 때문에 사실상 주간 회의를 제외하고는 누군가 제어해주는 사람도 일정을 관리하는 사람도 없었다.

그렇기에 일정이 딜레이되는 일들이 생겼고 이에 대표님은 큰 실망하고 앞으로 재택근무를 하는 것에 보수적이 되었다. 갑작스러운 재택이 핑계가 되지는 않지만 다들 첫 재택에 적응도 필요했을 것이며 각자 Task에 대한 인지가 필요했을 것이다. 사실 재택에 있어서 가장 주의해야할 것은 집이라는 공간의 특성이다.

공부를 한다는 것도 그렇지만 일을 한다는 것은 더더욱 집중하기 어려운 환경이라는 점이다.

누구나 한번쯤 시험기간이 되었을 때 책상에 앉아서 공부 대신에 청소나 기타 등등 공부 빼고 전부 다 하는 진귀한 경험들을 한번씩 해봤을 것이다.

언제든 푹신한 침대에 누워서 늘어지게 기지개를 펼칠 수 있다는 것. 그 유혹은 선악과에 손을 댄 아담과 이브만큼이나 달콤할 수밖에 없다. 노사 관계를 떠나서 인간이기 때문에 겪는 실수들은 집 안 깊숙히 도사리고 있고 이는 회사라고 예외는 아니다. 다만 이것은 누구의 잘못도 아니라는 점을 인지하고 넘어가고 싶다.

정확한 디렉션과 체계없이 남들이 하기 때문에, 대세라서 편승하듯이 급하게 시작한 재택, 감시가 벗어나 자유를 누리는 재택. 굳이 따지자면 선후 관계가 어느 정도 존재는 하지만 프로라면 이것을 변명으로 삼아선 안될 것이다. 그렇다고 재택근무라는 녀석은 단순히 나쁘기만 한 걸까?

만약 재택을 본격적으로 시작하려는 회사가 있다면

잘못된 도구는 없다. 잘못된 방법만 있을 뿐이다. 만약 재택을 본격적으로 시작하려는 회사가 있다면 정확한 메뉴얼과 체계가 지켜지길 바란다. 그것은 회사보다 더 체계적이어야 하며 각자의 책임을 지도록 하는 규율책이어야 한다. 회사에 거주하면서 느끼는 것들은 여러가지가 있는데 그 중 하나는 바로 소속감이다. Company라는 회사를 뜻하는 영단어의 어원에는 com(함께)pany(빵) 함께 빵을 먹는다는 어근들이 조합되어 있다. 즉 함께 밥을 먹는 식구들이라는 개념이다. 이런 소속감들은 재택을 하면서 대게는 많이 무뎌지게 되기 마련이다.

회식도 구시대 유물이 되어가는 요즘같은 시대에 소속감이 중요하다는 이야기는 아니다. 다만 회사에 속한 일들을 하고 있다는 주제 의식은 확실하게 심어둘 필요가 있다. 이것은 프로젝트가 산으로 가지 않도록 지속적인 조율이 필요하다는 말과 동일하다. 재택 근무를 지향할 수록 PM의 역할이 아닐 때보다 더 중요하고 커진다. 지라나 컨플루언스 같은 협업툴을 통해서 함께 프로젝트를 공유하며 부분적인 일만, 개인적으로 끝내고 넘어가는 형식이 아니라 거대한 분모 중에서 어떤 분자를 담당하는 지 즉 그 작업의 위치와 중요도를 지속적으로 인지시키고 확인할 필요가 있다. 각자 맡겨진 Task 별로 일정을 확정하는 것 또한 중요하다. 당연히 모든 프로젝트에는 확실한 일정같은 것은 존재하지 않는다. 항상 예상치 못하는 변수들과 상황들이 존재한다. 하지만 그렇다고 그 기점을 그냥 단순히 작업이 끝나는 순간에 맞추기 시작한다면 기약없이 늘어지는 경험을 하게 될 것이다.

그 기간에 맞출 수 없다고 해도 다시 그 진도가 어디까지 나갔는지 재차 확인하고 조율하는 것 또한 중요하다는 것을 강조하고 싶다. 이를 고과에 반영하도록 하는 것도 고취시키는 방법일 수 있다. 단적으로 친구의 직장에는 재택을 도입하면서 메신저로 아주 잠시간의 부재더라도 꼭 보고 메세지를 남기는 것이 의무화 되어있다. (심지어 화장실에 가는 것 마저도) 하지만 그것의 사유가 동네에 담배에 사는 것이라 하더라도 그것을 용인하고 넘어간다. 감시의 용도라기 보다는 커뮤니케이션 미스를 피하기 위한 용도와 자신이 일을 하고 있다는 것을 인지하기 위한 장치라고 보여진다.

이제는 게더타운에서 모여라

게더타운을 도입해서 회사 분위기처럼 꾸미고 상시 화상 또는 음성을 통해서 교류하는 방식의 재택도 있다. 최근 떠오르는 메타버스의 활용법 중에 하나로 앞서 단락 서두에 표현한 company라는 소속감을 가상 메타버스 공간에서 구현한 것이다. 이 게더타운에서는 가까이 가면 화상이나 음성을 통해서 대화할 수도 있고 게임이나 발표 등 회사에서만 가능할 것 같은 다양한 상호작용이 가능하다. 재택의 단점이라고 꼽는 의사소통의 갭을, 완전히 대면과 같은 수준까지는 아니지만 많이 줄일 수 있는 솔루션이다.

정리하자면

협업툴을 통해서 프로젝트 진행 상황과 해야할 일들을 지속적으로 모니터링 한다.
일정을 정하고 수시로 일정에 대해서 확인하고 조율한다.
자유와 책임을 명확히 한다.
의사소통의 갭을 줄여야 한다.

재택은 역시 득보다는 실인가?

위와 같은 조건을 갖추고도 역시 이 재택이라는 것은 개인차가 생길 수 있다. 확실히 기존의 근무 방식과는 차이가 있다. 그렇다고 해서 섣불리 재택이 기존 출퇴근보다 효율이 떨어지는 업무 방식이라고 생각하지는 말아야한다. 정말 방식이 다를 것일 뿐 일을 하기 위한 접근 방식이라는 것은 동일하고 감히 효율 또한 동일하다고 아니, 오히려 재택 근무가 체질에 맞는 사람의 경우에는 출퇴근 방식보다 더욱 효율 좋은 업무 방식이라는 것을 말하지 않을 수 없다.

일단 두 방식의 차이점을 하나씩 따져보며 구분점을 짚어보자. 가장 큰 차이점이라고 한다면 당연히 공간이라고 볼 수 있다. 회사라는 물리적인 공간이 존재하는 출퇴근 방식과 집이나 카페 등 ‘일’을 하는 것에 정해진 규격의 공간의 제한이 없는 재택 근무는 얼핏 재택의 장점이 더 강해보인다. 일단 출퇴근하면서 소모되는 시간 및 비용 낭비를 막을 수 있고 그 시간에 더 업무에 집중할 수 있다. 대부분이 서울의 거점에 회사가 몰려있는 것을 생각해보면 땅값이 싸고 더 넓고 쾌적한 곳에서 일할 수 있는 수도 집중 현상을 막을 수 있는 해결책으로도 보인다. 하지만 물리적인 공간이 존재한다는 것은 생각보다 많은 의미를 차지한다. 개인적으로는 공간감을 분리하는 것을 좋아하는 편인데, 단적으로 task 단위로 일을 하면서 그 task가 끝날 때까지 야근을 했으면 했지 절대로 그 일거리를 집까지 가져오지 않고 최대한 회사에서 해결하려고 한다.

집은 쉬고 개인의 시간을 갖는 공간, 회사는 일하는 공간으로 구분한 것이다. 덕분에 주말에는 회사에 대한 걱정이나 생각 등은 일체 접어두고 개인정비에 온 신경을 쏟을 수 있었다. 하지만 이러한 재택은 그런 공간구분을 무뎌지게 한다. 일이 집이라는 공간으로 스며들어온다. 밥을 먹으면서도 나는 회사에 있는 중이고, 잠깐 외출을 하면서도 나는 일을 하는 중이다. 덕분에 퇴근을 찍어도 잠깐 누워있다가 일에 대해 생각나면 곧바로 노트북을 들어 하던 작업에 다시 들어간다. 주말이나 연휴 기간 동안에도 일하게 된 것은 단순히 내가 일을 좋아한다는 것과는 거리가 먼 문제다. 이렇듯 회사라는 공간은 심리적인 역할을 겸하고 있다. 출퇴근은 나에게 일종에 종교의식과도 같은 일이었다. 테니스 선수나 배구선수가 서브를 날리기 전에 항상 하던 루틴을 행동하며 마음을 가다듬는 것처럼 나는 출퇴근을 하며 무의식적으로 나는 일을 할 준비하는 의식을 하고 있는 셈이다.

하지만 그 의식이라는 행위자체가 너무나 소모적이고 낭비라는 것은 우리는 잘 알 것이다. 이와 유사하게도 실제 최근 제사나 종교행사들이 허례허식이라며 많이 축소하거나 사라지는 추세라는 것을 보면 마음 가짐의 싱크로를 맞춘다는 행위는 현대에서는 사실 무의미하거나 생략되고, 많이 재해석된다고 볼 수 있다.

순수하게 움직이는 시간과 일에 집중하기 위해 준비하는 시간, 거기에 들어가는 교통비나 기타 비용까지 생각한다면 재택을 한다는 것은 즉 출퇴근에 사용되는 시간과 돈을 다른 식으로 활용할 수 있다고 볼 수 있다.

실제로 재택을 하면서 나에 대한 자기개발을 할 수 있는 시간들이 늘어났고, 나에 투자할 수 있는 비용 또한 늘어났다.

이것은 업무의 효율성과는 논외의 이야기다. 업무는 출퇴근 방식과 동일한 시간을 쓰되 더 짬짬이 남는 시간을 자신에게 투자할 수 있다는 것. 그것이 내가 재택하면서 느꼈던 가장 큰 재택의 장점이자 활용도 였다.

그것이 기업에 반드시 유리하게만 작용하는 것은 아니지만 장기적으로 봤을 때 자신에게 투자하는 시간이 늘어날 수록 개인이 기업에 기여하는 가치가 비례하며 늘어날 것이라는 것이 나의 단편적인 관망이다.

만약 출퇴근과 재택의 효용성이 대등하거나 그에 준한다면 회사나 개인의 비용을 줄일 수 있고 성장의 가능성이 높은 재택이 가장 이상적인 미래의 업무 방향성이 아닐까 싶다.

물론 이의 전제조건은 앞에서 언급한 것과 같이 회사에서 관련된 인프라와 체계가 잡혀있어야한다는 점은 당연하다.

그 인프라에 있어서는 회의나 업무관리 같은 백오피스 등 다양한 매니징툴과 그것들을 관리하고 컨트롤할 수 있는 인력이 필요하다. 가장 대표적으로 회의를 위한 화상은 밋업이나 게더타운 같은 것들을 활용한다. 하지만 아무리 요즘 인터넷 속도와 기술이 비약적으로 발전했다고는 하지만 대면하는 것과 같은 드라마틱한 효과를 기대하기는 힘들다.

실제로 밋업을 통해 회의를 하면 대화의 흐름이 끊기거나 일방적인 방식으로 이루어질 가능성이 많다는 것을 체감했다. 이는 시간이 흐를 수록 그리고 기술이 발전할 수록 그 간극이 많이 좁혀들 것으로 예상하지만 단기간내에 극복할 수는 없다는 생각이 든다.

비교를 정리하자면

공간의 구분감을 가질 수 있는 출퇴근 방식이지만 출퇴근 하는 것에 사용되는 에너지와 비용, 시간 낭비가 크다.
(개인차가 있지만)업무의 효율성의 차이는 같거나 미미하다.
대면으로 이루어지는 것들을 재택이 완전하게 대체하기에는 아직 무리인 점들이 있다.

따라서 완전히 재택을 부정하고 지레 겁먹기 보다는 시행착오를 겪어보면서 이같은 재택의 장점과 출퇴근의 장점을 골라서 취하는 것 또한 회사의 방향성에 긍정적인 방식으로 부합하리라 생각한다.