안녕하세요. 주형권입니다. 지난번에 썼던 데이터 엔지니어를 준비하거나 이제 막 시작 하는 분들에게 글이 인기가 꽤 많아서 2탄을 준비 하였습니다. 데이터 엔지니어를 준비하거나 이제 막 시작 하는 분들에게안녕하세요.데이터 엔지니어 주형권입니다. 오늘은 보편적인(?) 이야기를 하려고 합니다. 데이터 엔지니어를 준비하시거나 데이터 엔지니어를 이제 막 시작하신 분들에게 드리는 이야기입니다burning-dba.tistory.com 링크드인의 조회수가 10,000을 넘어서 11,000을 달리고 있어서 꽤 인기가 많이 있습니다. 기술적인 이야기보다는 확실히 범용적인 이야기가 인기가 많은 거 같습니다. 그리고 많은 분들이 공감을 해주셨고 많은 메시지와 문의가 있었습니다. 그래서 그 인기(?)에 힘입어 2탄을 준비하였습..

안녕하세요. 데이터엔지니어 주형권입니다.어느덧 Databricks를 맡고 운영한 지 5개월 정도가 흘렀습니다. 초반에 데이터 아키텍처와 정책을 잡고 서서히 물리적인 데이터를 운영 함에 있어서 꼭 알아야 하는 개념이 무엇일까 하다가 2가지 내용이 있어서 공부 겸 찾아보고 개념을 정리하였습니다.  위의 2개의 작업은 Databricks를 운영 하면서 필수적인 내용이므로 꼭 해줘야 하는 작업으로 보입니다. 정확히는 Optimize에 z-Ordering이 포함(?)인 것으로 옵션입니다. 하지만 할 때 같이 해주는 게 성능에 큰 영향을 미치는 것으로 보입니다. 개념과 함께 실제로 실행했을 때 알아야 하는 내용에 대해서도 공유하고자 합니다. Databricks의 테이블과 데이터 파일 처리 원리Databricks에 ..

안녕하세요. 주형권입니다.2부에서 3부로 넘어오는 시간이 조금 길었습니다. 개인적인 일이 매우 많아서 글 쓸 시간이 없다 보니 3부를 시작하는데 시간이 오래 걸렸습니다. 3부는 본격적으로 데이터를 데이터 환경을 구성하는 실제 개발 과정에 대한 경험과 방법에 대해서 다루려고 합니다. 물론 자세한 코드나 기법에 대해서는 부족 할 수 있으나 어느 정도 고민 하는 부분을 해결해주는 수준에서는 큰 도움이 될 것 같습니다. 그리고 3부에 들어가기 앞서 2부의 내용을 한번 더 숙지하고 비교하면서 읽어 보시면 아주 큰 도움이 될 것 같습니다.  [공통] 나혼자 데이터환경 구성 - 제 2부안녕하세요. 주형권입니다. 제1부 - warming-up에 이어서 두 번째 이야기입니다. 두 번째 이야기는 데이터 환경을 구성하기 ..

안녕하세요. 주형권입니다.제1부 - warming-up에 이어서 두 번째 이야기입니다. 두 번째 이야기는 데이터 환경을 구성하기 위해서 하는 준비 과정을 작성하였습니다. "생각보다 그냥 하면 되는 거 아니야?"라고 생각할 수 있지만 준비할 게 정말 많습니다. 저 같은 경우 사람들을 설득시키는 과정이 굉장히 힘들었고 인식을 바꾸는 과정이 가장 어려웠던 거 같습니다.  물론 사람의 입장의 차이가 모두 있고 팀의 사정이 저마다 다르기에 우리의 일을 모두 좋게 바라볼순 없습니다. 또한 여러 가지 이해관계가 엮여 있으므로 당연히 풀어야 하는 문제입니다. 무조건 우리 쪽의 입장만 들어주고 데이터를 만들어준다면 정말 편하겠지만 상대방의 입장과 상대방의 팀의 입장이 있고 변경하기 어려운 점이 분명히 존재하므로 여러 가..

안녕하세요. 주형권입니다. 최근에 범용적인 글을 많이 쓰고 있고 경험을 공유하는 글을 많이 작성하고 있는데요. 이런 글을 많이 쓰다 보니 기존에 했었던 노하우(?)를 공유해 달라는 요청이 몇 개 있어서 제가 전에 다녔던 G사에서 구성하였던 데이터 환경을 어떻게 구성하였는지 정리해 볼까 합니다. 이미 퇴사한 회사라서 회사명을 언급하진 않겠으나 G사면 어디인지 다들 아실 거라 생각합니다.  회사에서 팀장이였는데 데이터엔지니어링팀에 저 혼자였고 1인 팀장이었습니다... 그래서 혼자서 구축하였으니 제가 했던 게 전부라고 할 수 있겠네요. 아마도 이 글은 스타트업에 혼자서 데이터 환경을 어떻게 구성해야 할지 고민인 분들에게 많은 도움이 될 것으로 보입니다. 또한 이 글은 기존의 여러 가지 글을 짜깁기 하여 쓴 글..

안녕하세요. 주형권입니다. 지난번에 링크드인에서 이야기드렸듯이 과반의 득표를 얻어서 관련하여 글을 작성하였습니다. 이 글은 이제 막 시작하는 데이터엔지니어 또는 데이터엔지니어를 꿈꾸는 학생 또는 다른 직문의 사람에게 조금이나마 도움이 되고자 하여 작성하였으며, 저의 개인적인 견해와 생각이 많이 반영되어 있으므로 "꼭 이렇게 하세요." 라는 의도는 없으니 글을 읽을 때 참고 차원에서 읽어 주시기 바랍니다. 시작하며 시작하기에 앞서 이글을 왜 작성하였는지 설명을 드리려고 합니다. 제가 처음에 일을 시작할 때는 사수와 부사수라는 개념이 일반적이었습니다. 흔히 말하는 시니어와 주니어(신입)를 한 세트로 묶어서 사수가 부사수를 교육시켜주는 역할을 하였습니다. 요즘은 많은 회사가 사수와 부사수보다는 멘토(mento..

들어가며 안녕하세요. 주형권입니다. 오늘은 저연차 주니어 분들에게 도움이 될 것 같은(?) 글을 작성하려고 합니다. 제가 주니어 시절에 많은 시니어 분들께서 강조하셨고 가르쳐 주셨던 내용을 여러분께 정리하여 공유 드리고자 합니다. 저의 링크드인을 보면 아시겠지만 저는 이직을 꽤 여러번 하였습니다. 물론 자의가 아닌 타의(회사가 망...)로 회사를 옮긴적도 여러 번 있지만 이직을 여러 번 경험 한 저에게는 한 가지 습관이 있습니다. 누구나 자신만의 업무 스타일이 있고, 연차가 오래될수록 그 업무 스타일은 습관으로 굳어지는 것 같습니다. 여러가지 업무 스타일이 있지만 유독 이 부분은 제가 강점이라고 생각합니다. 누군가에게는 별것 아니라고 들을 수 있지만 제가 여러 회사를 옮기면서 느꼈지만 별게 맞습니다. 왜..

안녕하세요. 주형권입니다. AWS의 boto3를 이용하여 데이터 레이크 운영을 위한 개발을 하던 와중에 제목과 같은 에러를 발견하고 해결 방법에 대해서 정리 하였습니다. 우선 국내 블로그 및 외국 블로그에도 정확하게 나온 곳이 없어서 도움이 될 것 같아서 빠르게 글을 작성 하였습니다. 무엇을 하려고 하였는가? 저희는 AWS 환경에서 데이터레이크를 구축하고 있는 만큼 boto3를 정말 많이 씁니다. 그렇게 하다보니 boto3의 여러가지 기능에 대해서 많이 사용하고 있는데요. 그중에 CloudTrail에 관련하여 boto3를 통해서 데이터를 가져오려고 하였습니다. trail = boto3.client('cloudtrail') boto3에서 CloudTrail을 가져오는 방법이 여러가지가 있는데, 이중에 lo..

안녕하세요. 주형권입니다. 현재 회사에서 AWS 기반의 환경에서 Athena Iceberg(이하 Iceberg)를 이용하여 Data Lake를 구축하고 있습니다. Iceberg 테이블에 데이터를 마이그레이션 하거나 ELT를 할때 다음과 같은 오류가 발생 하여서 간략하게 글을 써봅니다. 무슨 오류가 발생 하였는가? TOO_MANY_OPEN_PARTITIONS : Exceeded limit of 100 open writers for partitions/buckets 다음과 같이 파티션이 100개 이상 쓸 수 없다고 나오는데요. 이는 INSERT 및 UPDATE , MERGE등에서 모두 발생 하였습니다. 어떻게 해결 하였는가? 이 부분은 해결 방법이 없습니다... 공식 홈페이지에 내용이 나오긴 하는데, 단순히..

안녕하세요. 주형권입니다. 2023년 6월 30일 기준으로 어느덧 GS리테일에 입사한 지 2달을 넘었습니다. 현재 잘 적응하고 있으며 입사 이후에 정말 많은 것들을 만들고 있습니다. 이번 글은 그 첫 번째 프로젝트에 대해서입니다. 저는 어느 회사를 가던지 무조건 처음에 하는 작업이 있습니다. 바로 모니터링 시스템을 만드는 작업입니다. 데이터엔지니어를 5년 정도 하면서 많은 실무자들이 개발 베이스로 일을 하다 보니 운영에 대해서 경험이 없는 경우가 많고 어떠한 것을 만들어야 할지 어떻게 만들어야 할지 모르는 경우가 매우 많았습니다. 운영이 생각보다 신경 쓸게 많고, 많은 지식을 요하는 경우가 있어서 쉬운 부분이 아닙니다. 그래서 이러한 노하우(?)를 공유하고 어떻게 도입하였는지 공유하여 많은 분들께서 도움..

안녕하세요. 데이터엔지니어 주형권입니다. 오랜만에 꽤나 길고 범용적인 주제에 관해서 글을 쓰려고 합니다. 많은 회사에서 데이터를 활용하여 많은 업무를 하고 데이터를 이용해서 많은 의사결정을 하고 있습니다. 그러면서 데이터의 양도 방대하고 종류도 꽤나 다양해졌습니다. 제가 처음에 일할 때는 RDB(Relational Database)에서 발생하는 데이터만 주로 다루었습니다. 하지만 최근에는 너무도 많고 너무도 다양한 데이터를 이용해서 의사결정과 업무를 진행합니다. 하지만 데이터가 아무리 다양하고 많아져도 RDB에서 발생하는 트랜잭션 데이터는 절대적으로 필요합니다. 그렇기에 RDB에서 데이터를 가져오는 것은 절대로 필요하다고 볼 수 있습니다. 회원 데이터 또는 빌링 데이터등은 무결성이 무조건이기 때문에 RD..

안녕하세요. 주형권입니다. 데이터웨어하우스 관련 글을 오랜만에 쓰는 것 같습니다. 글을 읽기 전에 이 글의 내용은 제가 알고 있고 공부한 내용을 바탕으로 설명하였습니다. 이 내용을 꼭 맹신하지 않고 혹시라도 다른 내용이 있다면, 서로 비교하여 읽기를 추천드립니다. 데이터웨어하우스 (이하 DW) 관련한 여러 가지 글이 있는데 그중에 DW의 설계 기법인 Star Schema와 Snowflake Schema에 대해서 설명해 보려고 합니다. DW를 하다 보면 가히 필수로 알아야 하는 개념이며 추가적으로 Galaxy Schema라는 설계 기법도 존재합니다. 최근에는 BigQuery와 같은 컬럼 형식으로 저장하면서 이러한 기법을 굳이 사용하지 않아도 최적의 저장 효율을 제공합니다. DW 기법이 필요한 이유는? DW..

글을 읽기 전에 이 내용은 저의 경험을 토대로 작성하였습니다. 현재 사용하시는 도구 및 방법과 다르다고 하여 무엇이 맞고 틀리고를 이야기하고자 하는 글이 아닌 경험을 공유하고자 작성된 글이므로 참고 차원에서 봐주시길 바랍니다. 데이터를 보기 위해서는 많은 과정이 필요합니다. SQL을 이용해서 데이터를 추출하고 이를 엑셀로 다운로드하거나 리포트를 만들어서 보는 과정이 아닌 전체적인 과정을 설명하고자 합니다. 이 글의 내용은 제가 아는 범위에서 작성하였으나 회사마다 모두 다르고 사람마다 모두 다른 방식으로 할 수 있기 때문에 어느 정도 감안해서 글을 읽어 주시길 바랍니다. 보통 데이터는 크게 3가지의 데이터가 있습니다. 정형 데이터 : 관계형 데이터베이스 (MySQL , SQL Server , Oracle)..

💁‍♂️ 들어가며 데이터를 적재하면서 가장 중요한 것은 무엇일까요? 여러가지 이유가 있겠지만 무엇보다 그 데이터가 정상적으로 잘 적재되었는지 여부 입니다. 많은 사람들이 적재를 어떻게 하면 "빠르고 효율적으로 적재 할 수 있나?" 에 초점을 많이 둡니다. 하지만 이 데이터가 정상적으로 A 👉🏻 B 들어왔는지는 많이 고민하지 않는 것 같습니다. 이 글에서는 실제로 구현한 코드를 보여주진 않습니다. (회사에서는 제가 구현을 했지만..) 컨셉을 주로 설명하며, 각자가 맞게 회사 시스템에 녹일 수 있으면 좋겠습니다. 🤷‍♂️ 어떻게 체크 할것인가? 데이터를 가공하여 계산 된 데이터를 적재하는 경우는 그 데이터가 정확하게 나온 지 여부를 확인하지만 원천 데이터에서 데이터를 가져올 경우 데이터를 맞게 가져왔는지 확..

기존에 링크드인에 공유한 포토폴리오 형식으로 제작 된 데이터 파이프라인 제작 관련 자료 입니다. 관련하여, 다운로드를 받으시려면 가장 아래에 첨부 파일을 확인해 주세요. 데이터 파이프라인 PDF

오랜만에 글을 쓰는거 같습니다. 한동안 서버 세팅을 하면서 바쁜 시간을 보내고 재택 근무를 하면서 이런저런 적응을 하다보니 글을 안쓰게 되었습니다. 그러다 이번에 새롭게 Airflow2.0을 실제로 세팅 하면서 이런 저런것을 정리해야겠다 싶어서 글을 씁니다. 들어가며... 이 글을 읽고 참고 하시면 도움이 될 분들은 이런 분들 입니다. 스케줄 처리를 해야하는데, Airflow를 선택 하였다. 하지만 나는 딥하게 알지는 못한다. 대규모 처리가 필요한게 아닌 적당한 처리를 할 예정이다. 일단 실무에 급하게 반영해야 하는데 봐도 잘 모르겠다. 튜토리얼이 아닌 진짜 실무에서 쓸수 있는 Airflow 시스템을 구축 하려고 한다. 반면 읽어도 큰 도움이 안 될 분들은 이런 분들 입니다. 대규모 작업이 필요하며, 빠..

요즘 많은 분들이 SQL을 통해서 데이터를 조회하고 추출합니다. 예전에는 DBA 분들이 주로 SQL을 통해서 데이터를 조회하고 추출하였습니다. 하지만 이제는 데이터 분석가, 사업, 기획, 개발 많은 분야에서 다양한 분들이 SQL을 통해서 데이터를 조회 및 추출을 합니다. 이렇게 많은 분들이 사용하다 보니 비전문가가 많아서 성능을 고려하지 못하고 SQL을 쓰는 사례가 많아졌습니다. 이는 자칫 실서버 또는 분석용 서버에 무리를 주는 경우가 있어서 이러한 부분을 조금이라도 줄이기 위해서 글을 작성합니다. 이 글의 경우 mysql , google big query에서 테스트하였습니다. (2020 기준으로 회사에서 2개를 사용) 첫 번째, WHERE절의 좌변을 가공하지 마세요. 이게 무슨 말일까요? SQL의 기본..