반응형
반응형
📌 이 글의 핵심 요약 (Key Takeaways)단순히 "작업이 실패했습니다"라고 통보하는 1차원적 모니터링을 넘어, 장애 발생 시 "어떤 후속 작업과 데이터 마트 테이블에 영향이 가는가?"를 예측하는 관측 가능성(Observability) 시스템 구축 실무 사례입니다. 본 글에서는 Databricks 파이프라인의 코드를 스캔하여 데이터 리니지(Lineage) 메타데이터를 자동화하는 방법, 다단계(A➡️B➡️C) 영향도 추적 로직, 그리고 알림 피로도(Alert Fatigue)를 방지하기 위해 MS Teams 채널을 세분화하여 공지하는 DRE(Data Reliability Engineering) 조직 문화 정착 노하우를 집중적으로 다룹니다. 안녕하세요. 주형권입니다. 어느덧 Data Reliabili..
📌 이 글의 핵심 요약 (Key Takeaways)매일 수억 건이 발생하는 대규모 데이터 파이프라인에서 단순 건수 체크를 넘어선 '다차원 로그 정합성 모니터링 시스템(Airflow + Databricks + MySQL + Teams)'을 구축한 실무 사례입니다. 본 글에서는 특정 로그 타입 및 국가별 유실을 감지하는 세분화된 집계 로직, 알림 피로도(False Positive)를 줄이기 위한 임계치 설정 노하우, 그리고 대용량 집계 시 발생하는 비용 최적화(Cost Optimization) 전략을 집중적으로 다룹니다. 안녕하세요. 주형권입니다.최근 방대한 로그들이 여기저기에서 들어오다 보니 로그가 정상적으로 들어오는지에 대해서 고민을 많이 하게 되었습니다. 그래서 데이터 엔지니어들의 영원한 숙제인 정..
📌 이 글의 핵심 요약무슨 문제인가: 기존 팀 단위의 단편적인 모니터링 방식으로는 본부 전체 사용자가 무작위로 생성하는 수많은 Databricks 워크플로우의 성공/실패/지연 상태를 체계적으로 관리하고 대응하기 어려웠음.어떻게 해결했나: Databricks Job/Task API를 주기적으로 호출하는 자동 탐지 백엔드를 개발하고, 메타데이터 저장을 위한 RDS 구축 및 비공개 Teams 채널 연동을 아우르는 전사적 워크플로우 관측 가능성(Observability) 알림 아키텍처를 수립함.무슨 효과를 얻었나: 본부 내 누구나 워크플로우를 생성해도 별도 설정 없이 실시간 장애 알림이 자동 적용(바이브코딩 배려)되었으며, 단순 감지를 넘어 장애 원인을 신속히 진단할 수 있는 데이터 신뢰성(DRE) 기반을 마..
[공통] 데이터엔지니어링팀의 계획 - 단기 편 (0~2년) [공통] 데이터엔지니어링팀의 계획 - 단기편 (0~2년)어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고burning-dba.tistory.com 지난 단기편에 이어서 중기 편을 이어가려고 합니다. 만약 여러분이 단기 과정을 어느 정도 끝냈다면 이제부터는 중반에 접어들었을 것이라고 봅니다. 기존의 데이터가 없는 환경에서 이제 플랫폼을 이용하여 무엇을 할 수 있는 단계에 이르렀다고 생각됩니다. 이것은 엄청난 도약입니다. 데이터 없이 경험과 감으로 일하던 환경에서 이제는 사실 기반으로 데이터와 수치를 기반으로 업무를 ..
어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고 비전에 파생되는 계획을 단/중/장기적으로 실천하는 일이 필요합니다. 비전과 계획이 별거 아닌 것 같지만 이것이 없으면 팀원들은 팀 비전에 대해서 의구심을 느낄 수 있으며 불안감이나 또는 보람을 느끼지 못할 수 있습니다. 그렇기 때문에 비전과 계획은 굉장히 중요한것 같습니다. 이번 글에서는 비전 이야기보다는 실질적인 계획에 대해서 이야기해보고자 합니다. 목표라고 할 수도 있겠네요. 사실 비전은 팀마다 정하기 나름이고 회사의 기조에 따라서 많이 달라질 것 같기에 비전에 대해서 다루지 않고 데이터엔지니어링 팀의 계획에 대해서만 ..
📌 이 글의 핵심 요약무슨 도전이었나: Databricks 경험이 전무한 상태에서 이미 가동 중인 대규모 데이터 환경을 인수받아, 플랫폼의 현황을 파악하고 안정적인 운영 체계를 확보해야 하는 극한의 과제에 직면함.어떻게 해결했나:모아이(MOAI) 모니터링 시스템을 선제 구축하여 비용 및 실패 지표를 시각화하고,VACUUM 최적화를 통해 S3 스토리지의 불필요한 데이터 수백 TB를 청소했으며,파티션 재설계 및 쿼리 최적화로 성능을 극대화하는 동시에 업무 프로세스를 도식화하여 팀원들과 함께 시너지를 내는 구조를 확립함.무슨 가치를 얻었나: 인프라 비용 대폭 절감 및 쿼리 성능 향상이라는 하드웨어적 성과를 넘어, "누구나 데이터를 쉽게 사용할 수 있는 데이터 민주화(Democratization)"의 기반을 ..
안녕하세요. 계속해서 회사에서 Databricks를 하다 보니 자연스럽게 Databricks에 관련된 글을 많이 쓰고 있습니다. 이외에도 다른 공부(spark 등)도 하고 있지만 본업이 우선이기에 Databricks 쪽으로 제일 많이 집중하고 있습니다. 제가 어느덧 Databricks를 접한 지 10개월이 넘어가는 시점에서 회사에 와서 처음 시작해 보는 Databricks 플랫폼 환경에서 무엇을 하였는지에 대해서 회고 겸 정리 겸 글을 작성하였습니다. 이 글은 타 회사와 환경과 비용적 측면에서 다를 수 있으므로 참고 차원에서 보시길 권해 드립니다. 제가 작성한 글이 무조건 정답은 아니며, 회사의 상황에 맞게 적용이 필요합니다. 그렇기에 꼭 본인의 회사에 적용을 하실때 환경과 상황에 맞게 각자의 판단에 ..
안녕하세요. 주형권입니다.제1부 - warming-up에 이어서 두 번째 이야기입니다. 두 번째 이야기는 데이터 환경을 구성하기 위해서 하는 준비 과정을 작성하였습니다. "생각보다 그냥 하면 되는 거 아니야?"라고 생각할 수 있지만 준비할 게 정말 많습니다. 저 같은 경우 사람들을 설득시키는 과정이 굉장히 힘들었고 인식을 바꾸는 과정이 가장 어려웠던 거 같습니다. 물론 사람의 입장의 차이가 모두 있고 팀의 사정이 저마다 다르기에 우리의 일을 모두 좋게 바라볼순 없습니다. 또한 여러 가지 이해관계가 엮여 있으므로 당연히 풀어야 하는 문제입니다. 무조건 우리 쪽의 입장만 들어주고 데이터를 만들어준다면 정말 편하겠지만 상대방의 입장과 상대방의 팀의 입장이 있고 변경하기 어려운 점이 분명히 존재하므로 여러 가..
안녕하세요. 주형권입니다. 지난번에 링크드인에서 이야기드렸듯이 과반의 득표를 얻어서 관련하여 글을 작성하였습니다. 이 글은 이제 막 시작하는 데이터엔지니어 또는 데이터엔지니어를 꿈꾸는 학생 또는 다른 직문의 사람에게 조금이나마 도움이 되고자 하여 작성하였으며, 저의 개인적인 견해와 생각이 많이 반영되어 있으므로 "꼭 이렇게 하세요." 라는 의도는 없으니 글을 읽을 때 참고 차원에서 읽어 주시기 바랍니다. 시작하며 시작하기에 앞서 이글을 왜 작성하였는지 설명을 드리려고 합니다. 제가 처음에 일을 시작할 때는 사수와 부사수라는 개념이 일반적이었습니다. 흔히 말하는 시니어와 주니어(신입)를 한 세트로 묶어서 사수가 부사수를 교육시켜주는 역할을 하였습니다. 요즘은 많은 회사가 사수와 부사수보다는 멘토(mento..
안녕하세요. 데이터엔지니어 주형권입니다. 오랜만에 꽤나 길고 범용적인 주제에 관해서 글을 쓰려고 합니다. 많은 회사에서 데이터를 활용하여 많은 업무를 하고 데이터를 이용해서 많은 의사결정을 하고 있습니다. 그러면서 데이터의 양도 방대하고 종류도 꽤나 다양해졌습니다. 제가 처음에 일할 때는 RDB(Relational Database)에서 발생하는 데이터만 주로 다루었습니다. 하지만 최근에는 너무도 많고 너무도 다양한 데이터를 이용해서 의사결정과 업무를 진행합니다. 하지만 데이터가 아무리 다양하고 많아져도 RDB에서 발생하는 트랜잭션 데이터는 절대적으로 필요합니다. 그렇기에 RDB에서 데이터를 가져오는 것은 절대로 필요하다고 볼 수 있습니다. 회원 데이터 또는 빌링 데이터등은 무결성이 무조건이기 때문에 RD..
BigQuery에서 가끔씩 Error: 80324028이 발생하면서 실행이 실패하는 경우가 있습니다. 이러한 현상을 구글링 해봤으나 별다른 성과가 없었으며, Slack overflow에서만 몇몇 답글이 달렸지만 해결방법은 없고 대부분이 "아마도 그럴 것이다?"라는 추측이었습니다. 무슨 작업을 했을 때 발생 하였는가? 그래서 몇 가지 의심 가는 정황을 포착해서 여러 가지 테스트를 해보았는데, 현재는 발생하지 않고 있습니다. 제가 하려던 작업은 ETL 작업이었고 Python Operator를 이용해서 작업을 부르고 그 안쪽에 BigQuery의 Query를 수행하는 작업이 몇 개 있었습니다. 대략 이러한 작업이었습니다. 이러한 여러 번의 Query를 수행하는 작업이 순차적으로 수행됩니다. drop_query ..
안녕하세요. 주형권입니다. 데이터웨어하우스 관련 글을 오랜만에 쓰는 것 같습니다. 글을 읽기 전에 이 글의 내용은 제가 알고 있고 공부한 내용을 바탕으로 설명하였습니다. 이 내용을 꼭 맹신하지 않고 혹시라도 다른 내용이 있다면, 서로 비교하여 읽기를 추천드립니다. 데이터웨어하우스 (이하 DW) 관련한 여러 가지 글이 있는데 그중에 DW의 설계 기법인 Star Schema와 Snowflake Schema에 대해서 설명해 보려고 합니다. DW를 하다 보면 가히 필수로 알아야 하는 개념이며 추가적으로 Galaxy Schema라는 설계 기법도 존재합니다. 최근에는 BigQuery와 같은 컬럼 형식으로 저장하면서 이러한 기법을 굳이 사용하지 않아도 최적의 저장 효율을 제공합니다. DW 기법이 필요한 이유는? DW..
글을 읽기 전에 이 내용은 저의 경험을 토대로 작성하였습니다. 현재 사용하시는 도구 및 방법과 다르다고 하여 무엇이 맞고 틀리고를 이야기하고자 하는 글이 아닌 경험을 공유하고자 작성된 글이므로 참고 차원에서 봐주시길 바랍니다. 데이터를 보기 위해서는 많은 과정이 필요합니다. SQL을 이용해서 데이터를 추출하고 이를 엑셀로 다운로드하거나 리포트를 만들어서 보는 과정이 아닌 전체적인 과정을 설명하고자 합니다. 이 글의 내용은 제가 아는 범위에서 작성하였으나 회사마다 모두 다르고 사람마다 모두 다른 방식으로 할 수 있기 때문에 어느 정도 감안해서 글을 읽어 주시길 바랍니다. 보통 데이터는 크게 3가지의 데이터가 있습니다. 정형 데이터 : 관계형 데이터베이스 (MySQL , SQL Server , Oracle)..