남는건 기록뿐

Databricks에서 쿼리가 느리면 Warehouse나 Cluster부터 키우기 쉽다. Compute를 늘리는 것이 필요한 상황도 있지만, 불필요한 데이터를 읽고 옮기는 구조가 그대로라면 더 많은 자원으로 같은 일을 반복하게 된다. 쿼리를 최적화할 때 먼저 던질 질문은 다음과 같다. 이 결과를 만들기 위해 정말 모든 파일과 컬럼을 읽어야 하는가? Join 전에 줄일 수 있는 데이터를 그대로 전달하고 있지 않은가? Join으로 행이 불어난 뒤 DISTINCT로 문제를 숨기고 있지 않은가? 같은 데이터를 여러 번 Scan하거나 같은 JSON을 반복해서 파싱하고 있지 않은가? 빨라진..

IoT 데이터 파이프라인은 단순히 센서 데이터를 빠르게 저장하는 시스템이 아니다. 현장의 디바이스는 연결이 불안정할 수 있고, 데이터는 짧은 시간에 몰리며, 같은 이벤트가 다시 전송되거나 순서가 뒤바뀔 수 있다. 펌웨어가 업데이트되면 메시지 구조도 달라진다. 이 데이터를 분석 플랫폼이 직접 받도록 만들면 디바이스 접속 문제와 데이터 처리 문제가 한 시스템 안에서 얽힌다. 그래서 실시간 IoT 아키텍처에는 역할 분리가 필요하다. AWS IoT Core는 디바이스를 안전하게 연결하고 메시지를 받는다. Amazon Kinesis Data Streams는 수신한 이벤트를 일정 기간 보관하고 소비자에게 전..

Airflow에서 Sensor는 외부 조건이 충족될 때까지 기다렸다가 다음 Task를 실행한다. 예를 들어 다음과 같은 조건을 확인한다. Source File이 도착했는가 상위 시스템의 Batch가 완료됐는가 특정 Partition이 생성됐는가 여러 Source가 모두 준비됐는가 업무 마감 시각 전에 데이터가 도착했는가 Databricks에도 SQL 결과를 평가하는 Alert와 Lakeflow Jobs의 조건 분기 기능이 있다. 그렇다면 Databricks Alert를 Airflow Sensor처럼 사용해 Pipeline을 Trigger할 수 있을까? 결론부터 말하면 가능하지만, 완전히 같은 방..

Databricks에서 Alert를 만드는 일 자체는 어렵지 않다. SQL을 작성하고, 조건과 임계값을 정하고, Slack이나 이메일을 연결하면 된다. 하지만 운영 환경에서는 Alert의 개수보다 다음 질문이 더 중요하다. 이 Alert는 실제 장애를 조기에 발견하는가? 같은 장애를 5분마다 반복해서 알리지 않는가? 알림을 받은 사람이 원인과 영향 범위를 바로 판단할 수 있는가? 담당자가 퇴사하거나 권한이 변경돼도 계속 동작하는가? Alert Query가 실패하거나 실행 자체가 누락된 사실도 감지할 수 있는가? Alert를 실행하는 SQL Warehouse 비용이 감시 대상보다 커지지는 ..

Databricks에서 클러스터를 만들 때 가장 흔한 질문은 다음과 같다. Worker는 몇 대가 필요한가? M, C, R, I 계열 중 무엇을 선택해야 하는가? 작은 Worker를 많이 쓰는 것과 큰 Worker를 적게 쓰는 것 중 어느 쪽이 좋은가? Autoscaling 범위는 어떻게 정해야 하는가? Photon과 Spot을 켜면 항상 비용이 줄어드는가? Driver와 Worker를 같은 Instance로 구성해도 되는가? 이 질문에 하나의 정답은 없다. 같은 데이터 크기라도 Join, Aggregation, Python UDF, Streaming State, 파일 수와 Partit..

Databricks 비용을 처음 확인할 때는 보통 Workspace별 DBU나 SKU별 사용량부터 본다. 하지만 실제 운영에서는 곧 다음 질문을 만나게 된다. 이 비용은 어느 본부와 팀이 사용했는가? 특정 Project의 ETL·BI·ML 비용은 얼마인가? Production과 Development 비용을 분리할 수 있는가? Shared Compute 비용은 누구에게 배부해야 하는가? Tag가 없는 비용은 전체의 몇 퍼센트인가? Budget Alert가 울렸을 때 어떤 Resource를 줄여야 하는가? 이 질문에 답하려면 비용이 발생한 뒤 사람이 Resource 이름을 해석하는 방식으로는 부족하..