반응형
반응형
안녕하세요. 주형권입니다. AI를 적극적으로 업무에 도입해서 하다 보니 생각보다(?) 빠르게 업무를 하는 거 같습니다. 그래서 결과물이 제가 생각한 것보다 빠르게 도출되면서 블로그 글을 쓸 거리도 많아지고 있는 거 같습니다. 이 블로그에서 나오는 내용은 2개의 AI의 도움을 받았습니다. 우선 첫 번째로 Databricks에서 제공되는 Genie Code입니다. Agent AI로 사용하고 있습니다. 두 번째로는 Gemini입니다. 챗봇 형태로 생성형 AI로 사용하고 있습니다. 두 개의 AI 모두 회사에서 사용하도록 허가된 제품이며, 공식적으로 현재 회사에서 제공하고 있습니다. 그래서 두 개의 AI만을 이용해서 현재 블로그에서 나오는 내용의 모든 작업을 진행하였습니다. 물론 기획 및 디테일한 부분을 제가 모..
📌 이 글의 핵심 요약 (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) 전략을 집중적으로 다룹니다. 안녕하세요. 주형권입니다.최근 방대한 로그들이 여기저기에서 들어오다 보니 로그가 정상적으로 들어오는지에 대해서 고민을 많이 하게 되었습니다. 그래서 데이터 엔지니어들의 영원한 숙제인 정..
📌 이 글의 핵심 요약 (Key Takeaways)멀티 리전 Databricks 환경에서 발생하는 고질적인 'Small File 문제'와 스토리지 낭비를 해결하기 위해, 메타데이터 기반으로 OPTIMIZE & VACUUM 작업을 완전히 자동화한 데이터 파이프라인 구축기입니다. 본 글에서는 수백 개의 분산된 델타 테이블 중 정리가 필요한 대상 테이블을 자동으로 판별하는 동적 메타데이터 관리 기법, 데이터 유실 없이 디스크 용량을 확보하는 안전한 VACUUM 자동화 아키텍처, 그리고 멀티 리전 간의 효율적인 배치 최적화 노하우를 실무 코드와 함께 다룹니다. 안녕하세요. 주형권입니다.최근 Databricks 환경을 운영하면서 피할 수 없는 숙명과도 같은 문제를 마주했습니다. 바로 데이터 엔지니어들의 영원한 ..
📌 이 글의 핵심 요약무슨 문제인가: Databricks 글로벌/멀티 테넌트 환경을 운영하면서 비인가자의 접근, 불필요한 퍼스널 토큰 남용, 보안 취약점 노출을 수동으로 일일이 감시하기 어려웠음.어떻게 해결했나: Databricks가 생성하는 시스템 감사 로그(Audit Log)를 자동으로 수집·적재하고, Python API와 Teams 알림을 연동하여 비인가 접근 및 보안 위협을 실시간으로 감지하는 데이터 거버넌스 자동화 시스템을 구축함.무슨 효과를 얻었나: 보안 감사(Audit) 업무를 100% 자동화하여 리소스를 제로화하고, 개인정보(PII) 유출 및 비인가 토큰 사용 등 데이터 플랫폼의 보안 위협을 실시간으로 철통 방어함.안녕하세요, 주형권입니다. 정말 오랜만에 블로그로 인사 드립니다.그동안 밀..
📌 이 글의 핵심 요약무슨 문제인가: 기존 팀 단위의 단편적인 모니터링 방식으로는 본부 전체 사용자가 무작위로 생성하는 수많은 Databricks 워크플로우의 성공/실패/지연 상태를 체계적으로 관리하고 대응하기 어려웠음.어떻게 해결했나: Databricks Job/Task API를 주기적으로 호출하는 자동 탐지 백엔드를 개발하고, 메타데이터 저장을 위한 RDS 구축 및 비공개 Teams 채널 연동을 아우르는 전사적 워크플로우 관측 가능성(Observability) 알림 아키텍처를 수립함.무슨 효과를 얻었나: 본부 내 누구나 워크플로우를 생성해도 별도 설정 없이 실시간 장애 알림이 자동 적용(바이브코딩 배려)되었으며, 단순 감지를 넘어 장애 원인을 신속히 진단할 수 있는 데이터 신뢰성(DRE) 기반을 마..
해당 내용은 제가 생각한 부분과 외국 블로그, 사이트에서 있는 내용을 정리 한 개념이므로 정답은 아닙니다. 📌 이 글의 핵심 요약무슨 직군인가: 데이터 신뢰성 엔지니어(Data Reliability Engineer, DRE)는 소프트웨어 분야의 SRE(사이트 신뢰성 엔지니어링) 철학을 데이터 도메인에 이식하여, 대규모 데이터 파이프라인의 품질, 정합성, 안정성을 보장하고 자동화하는 차세대 직군입니다.왜 필요한가: 데이터 플랫폼이 대형화되면서 사후 모니터링만으로는 정합성 오류와 성능 저하를 방지하기 어려우며, 데이터 신뢰도를 엔지니어링 기법으로 '설계 단계'부터 강제하고 관리해야 하기 때문입니다.앞으로의 방향성: 국내에는 아직 매우 생소하지만 해외 및 선도 IT 기업들을 중심으로 급부상 중이며, 전통적인..
안녕하세요. 오랜만에 Databricks 관련 글을 올립니다. 오랜만에 쓰는 글인데 심화적인 글은 아니고 간단한 API를 이용한 내용입니다. Databricks에서는 AWS나 GCP 같은 플랫폼에서와 같이 Key 형태의 Token을 제공합니다. Token을 이용해서 여러 가지 Databricks의 모니터링을 할 때 Token을 이용해서 코드에 삽입하여 사용합니다. 제가 만든 수많은 모니터링 시스템에서 필요한 것이 Databricks의 Token입니다. 모니터링을 하려면 AWS에서는 Access key 가 필요하고 GCP에서는 key file이 필요하듯이 여기서도 Token이라는 것이 존재 합니다. Authenticate with Databricks personal access tokens (legacy..
[공통] 데이터엔지니어링팀의 계획 - 단기 편 (0~2년) [공통] 데이터엔지니어링팀의 계획 - 단기편 (0~2년)어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고burning-dba.tistory.com 지난 단기편에 이어서 중기 편을 이어가려고 합니다. 만약 여러분이 단기 과정을 어느 정도 끝냈다면 이제부터는 중반에 접어들었을 것이라고 봅니다. 기존의 데이터가 없는 환경에서 이제 플랫폼을 이용하여 무엇을 할 수 있는 단계에 이르렀다고 생각됩니다. 이것은 엄청난 도약입니다. 데이터 없이 경험과 감으로 일하던 환경에서 이제는 사실 기반으로 데이터와 수치를 기반으로 업무를 ..
어느 조직이든 간에 계획은 중요한 요소 중에 하나입니다. 데이터엔지니터링을 맡는 팀 역시 계획이 중요하긴 마찬가지입니다. 어느 부서건 비전과 계획을 수립하고 그에 맞게 일을 가져가고 비전에 파생되는 계획을 단/중/장기적으로 실천하는 일이 필요합니다. 비전과 계획이 별거 아닌 것 같지만 이것이 없으면 팀원들은 팀 비전에 대해서 의구심을 느낄 수 있으며 불안감이나 또는 보람을 느끼지 못할 수 있습니다. 그렇기 때문에 비전과 계획은 굉장히 중요한것 같습니다. 이번 글에서는 비전 이야기보다는 실질적인 계획에 대해서 이야기해보고자 합니다. 목표라고 할 수도 있겠네요. 사실 비전은 팀마다 정하기 나름이고 회사의 기조에 따라서 많이 달라질 것 같기에 비전에 대해서 다루지 않고 데이터엔지니어링 팀의 계획에 대해서만 ..
안녕하세요. Databricks 관련해서 글을 쓰다 보니 굉장히 기본적인 모니터링 관련해서 글을 쓰지 않았네요. 제가 오늘 말씀드릴 내용은 아마도 모니터링에 가장 기본적인 Job에 대한 모니터링 방법에 관련된 내용입니다. Databricks를 운영하면서 수도 없이 많은 모니터링을 만들었지만 아마도 이 모니터링을 가장 처음 만들었던 거 같습니다. Databricks 운영에 관련해서 다른 글을 보시고 싶으시면 아래의 글을 참고해주세요.[Databricks] Databricks 운영 정리 - 1편 :: 데이터엔지니어 군고구마 [Databricks] Databricks 운영 정리 - 1편안녕하세요. 계속해서 회사에서 Databricks를 하다 보니 자연스럽게 Databricks에 관련된 글을 많이 쓰고 있습니..
📌 이 글의 핵심 요약무슨 도전이었나: Databricks 경험이 전무한 상태에서 이미 가동 중인 대규모 데이터 환경을 인수받아, 플랫폼의 현황을 파악하고 안정적인 운영 체계를 확보해야 하는 극한의 과제에 직면함.어떻게 해결했나:모아이(MOAI) 모니터링 시스템을 선제 구축하여 비용 및 실패 지표를 시각화하고,VACUUM 최적화를 통해 S3 스토리지의 불필요한 데이터 수백 TB를 청소했으며,파티션 재설계 및 쿼리 최적화로 성능을 극대화하는 동시에 업무 프로세스를 도식화하여 팀원들과 함께 시너지를 내는 구조를 확립함.무슨 가치를 얻었나: 인프라 비용 대폭 절감 및 쿼리 성능 향상이라는 하드웨어적 성과를 넘어, "누구나 데이터를 쉽게 사용할 수 있는 데이터 민주화(Democratization)"의 기반을 ..
안녕하세요. 주형권입니다.정말 오랜만에 글을 쓰는 거 같습니다. 요즘 내/외부적으로 바쁘게 살고 있어서 글을 쓸 시간이 없습니다... 그래서 한 달에 1개 업로드하기도 어렵습니다.🥺 들어가며 Databricks를 이용해서 데이터환경을 구축하고 이를 기반으로 수많은 유저들에게 오픈하여 사용하다보면 어쩔 수 없이 비용이 많이 나오게 됩니다. Databricks도 결국 사용하는 만큼 비용을 지불하기 때문에 그만큼 오래 수행이 된다면 비용을 많이 지불하게 됩니다. (AWS EC2 비용은 별도다.😥) 어쩔 수 없이 기간을 오래 잡아서 데이터를 집계하거나 어쩔 수 없이 큰 데이터를 조회하는 경우는 어쩔 수 없지만 비전공자나 데이터를 잘 사용해 본 적이 없는 사용자의 경우 파티션이나 리퀴드 클러스터링 등 사용을 ..
안녕하세요. 계속해서 회사에서 Databricks를 하다 보니 자연스럽게 Databricks에 관련된 글을 많이 쓰고 있습니다. 이외에도 다른 공부(spark 등)도 하고 있지만 본업이 우선이기에 Databricks 쪽으로 제일 많이 집중하고 있습니다. 제가 어느덧 Databricks를 접한 지 10개월이 넘어가는 시점에서 회사에 와서 처음 시작해 보는 Databricks 플랫폼 환경에서 무엇을 하였는지에 대해서 회고 겸 정리 겸 글을 작성하였습니다. 이 글은 타 회사와 환경과 비용적 측면에서 다를 수 있으므로 참고 차원에서 보시길 권해 드립니다. 제가 작성한 글이 무조건 정답은 아니며, 회사의 상황에 맞게 적용이 필요합니다. 그렇기에 꼭 본인의 회사에 적용을 하실때 환경과 상황에 맞게 각자의 판단에 ..
안녕하세요. 테이블 옵션에 관해서 처음 글을 쓰는 거 같네요. Databricks에는 여러 가지 자동으로 최적화해주는 옵션이 있지만 해당 옵션을 추가하여 Small 파일을 방지하고 성능을 향상할 수 있을 것 같습니다. 실제로 파일의 개수가 1/2 가량 줄어드는 것을 보았고, KB의 파일들이 모여서 MB로 변경되는 것을 눈으로 직접 확인하였습니다. 제가 알고 있기로 Databricks에는(아니면 delta 옵션 일수도?) 다음과 같이 파일에 관련하여 옵션을 제공 합니다. 제가 아는 건 2개 정도였는데요. 이미 테이블에 옵션을 적용해 놨습니다. delta.autoOptimize.autoCompact delta.autoOptimize.optimizeWrite 데이터 파일 크기를 제어하도록 Delta Lak..