sql 튜닝, airflow 마이그레이션, 기타 등등을 진행하던 와중에 문제가 생겼습니다.

저는 사내 재고 분류를 위한 데이터 마트 구성을 담당하고 있습니다. 시기별로 이 상품이 어떤 재고인지(양성 / 악성 / …) 분류되는 기준을 걸러내는데, 이 때 많이 사용하는 연산자가 Like입니다.

앞선 포스팅에서 언급했듯, 현업에서 managed airflow의 2가지 문제점에서 한계를 느꼈습니다.

현업에서 온프레미스 Airflow를 거쳐 현재는 AWS Managed Airflow인 MWAA에서 Airflow를 운영하고 있습니다. 다소 가격이 비싸지만 데이터 엔지니어링에 많은 여력을 쏟을 수 없는 경우에는 좋은 대안이 될 수 있습니다.

저는 업무에서 AWS를 사용해 Spark Job을 돌리고 있습니다. 마지막에 파티션을 병합해야 결과 파일이 하나로 모이기 때문에, 파티션 1개로 병합하는 작업을 거칩니다. 이 때 사용할 수 있는 메서드가 파티션 갯수를 조절하는 repartition, coalesce 입니다.

1장에서는 sorted_queue가 어디서부터 생겨나는가?를 보았습니다.

Executor Deep Dive 2번째 파트 CeleryExecutor입니다. 사실 LocalExecutor는 production 환경에서 사용을 권장하지 않습니다. 그러나 CeleryExecutor부터는 production 환경 사용도 권장하고 있습니다.

이전 포스팅 [Airflow] Executor Deep Dive 1-2. LocalExecutor.LimitedParallelism에서, LimitedParallelism 클래스가 시작되면 worker가 parallelism 옵션에서 지정한 숫자(self.executor.parallelism)만큼 생성되는 것을 보았습니다.

생각보다 UnlimitedParallelism이 길어졌습니다. 지난번 포스팅에서 LocalWorker 클래스가 초기화되면 LocalWorkerBase 클래스의 execute_work가 실행된다는 것까지 살펴봤습니다.

카프카 구성요소