- Yelp는 최근 소비자의 데이터에 대한 수요가 증가함에 따라 Redshift에 데이터를 더 효율적으로 로드하는 방법을 재검토함
- 이 글에서는 DBT가 Redshift Spectrum과 원활하게 사용되어 Data Lake에서 Redshift로 데이터를 읽어들여 런타임을 크게 줄이고, 데이터 품질 문제를 해결하며, 개발자 생산성을 향상시키는 방법을 살펴봄
시작점
- 배치 데이터를 Redshift에 로드하는 방법은 수년 동안 효과적이었지만 계속해서 개선점을 모색함
- 주로 Spark 작업을 사용하여 S3 데이터를 읽고 in-house Kafka 기반 데이터 파이프라인에 게시하여 Data Lake와 Redshift 모두에 데이터를 가져옴
- 그러나 몇 가지 문제점에 직면하기 시작함:
- 성능: 대용량 데이터 세트(일일 100만 개 이상의 행)가 지연되기 시작함. 대부분 upsert 시 기본 키가 중복되지 않도록 하기 위한 테이블 스캔 때문임
- 스키마 변경: 대부분의 테이블은 Avro 스키마로 구성되었음. 스키마 변경은 때때로 복잡했는데, 이는 새 Avro 스키마를 생성하고 등록하는 다단계 프로세스가 필요했기 때문임
- 백필: 데이터 수정에 대한 백필 지원이 미흡했는데, in-place로 행을 수정할 수 있는 쉬운 방법이 없었기 때문임. 전체 파티션에 대해 수정된 데이터를 쓰기 전에 데이터를 수동으로 삭제하는 경우가 많았음
- 데이터 품질: Data Lake와 Redshift에 병렬로 쓰는 것은 두 데이터 스토어 간의 데이터 유형 차이와 같은 데이터 차이의 위험이 있었음
DBT로 Redshift 로드 개선하기
- 데이터를 보다 효율적으로 이동시키는 방법을 고려할 때 Redshift에서 Data Lake 데이터를 쿼리할 수 있도록 특별히 구축된 도구인 AWS Redshift Spectrum을 활용하기로 선택함
- Data Lake 테이블은 일반적으로 가장 업데이트된 스키마를 가지고 있었기 때문에 Redshift 배치를 위한 데이터 소스로 S3 대신 Data Lake를 사용하기로 결정함. 이는 데이터 차이를 줄이는 데 도움이 될 뿐만 아니라 Data Lake를 단일 진실 소스로 취급하는 우리의 모범 사례와도 일치함
- 구현을 위해 Spectrum은 정의된 스키마가 필요한데, 이는 우리의 Data Lake 테이블을 위해 Glue에 이미 존재함. 추가로 필요한 유일한 설정은 Data Lake 테이블을 외부 테이블로 추가하여 간단한 SQL 쿼리로 Redshift에서 액세스할 수 있도록 하는 것뿐이었음
- 이미 다른 데이터 세트에 DBT를 채택하기 시작했지만, 파이프라인에서 Redshift Spectrum 쿼리를 캡처하는 데에도 완벽한 후보로 보임. DBT는 데이터 변환에 탁월하며 모듈화되고 버전 제어된 SQL 작성을 적용하는 데 도움이 됨
- Spark 작업이 S3에서 Redshift로 읽는 대신 DBT를 사용하여 Data Lake에서 Redshift로 데이터를 직접 복사함. DBT는 재현성, 유연성 및 데이터 계보와 같은 특징적인 이점을 제공할 뿐만 아니라 위에서 언급한 몇 가지 문제점을 해결하는 데도 도움이 됨
단순화된 스키마 변경
- 스키마 변경을 단순화하기 위해 DBT의 on_schema_change 구성 인수를 활용함. append_new_columns로 설정하여 들어오는 데이터에 열이 없는 경우 삭제되지 않도록 보장함
- 또한 DBT 계약을 두 번째 보호 계층으로 사용하여 작성 중인 데이터가 모델의 구성과 일치하는지 확인함
덜 수동적인 백필
- DBT를 통해 백필도 훨씬 쉬워졌음. pre_hook 구성 인수를 사용하여 모델 바로 직전에 실행할 쿼리를 지정할 수 있음
- 이를 통해 작성될 파티션에 대한 데이터를 보다 자동으로 삭제할 수 있음
- 이제 멱등성을 보장할 수 있게 되어 오래된 데이터가 제거되지 않는 것에 대해 걱정할 필요 없이 백필을 수행할 수 있게 됨
데이터 중복 제거
- 중복 행을 해결하기 위해 SQL에 중복 제거 계층을 추가하고 DBT 테스트로 유효성을 검사함
- DBT에는 기본 제공 unique 열 테스트가 있지만 전체 테이블 스캔이 필요하므로 큰 테이블에는 실행 가능하지 않음
- 대신 dbt_expectations 패키지의 expect_column_values_to_be_unique 함수를 사용함. 이를 통해 최근에 작성된 행만 스캔하는 행 조건을 지정할 수 있음
성능 향상
- 가장 눈에 띄는 성과는 특히 가장 큰 문제가 있는 Redshift 데이터 세트의 성능 향상이었음:
- 쓰기는 약 2시간이 걸렸지만 이제는 일반적으로 단 10분 만에 실행됨
- 이전에는 한 달에 최대 6시간의 지연이 있었지만 이제는 더 이상 지연이 없음. 이는 온콜 인시던트 대응 노력에 큰 부담을 줄여줌
- 스키마 업그레이드는 이전에 더 긴 다단계 프로세스였음. 이제는 몇 시간밖에 걸리지 않는 3단계 프로세스로 개선됨
더 나은 데이터 일관성
- 데이터 흐름의 분기를 제거함으로써 다른 데이터 저장소 간에 데이터가 달라지지 않을 것이라는 확신이 높아짐
- Redshift에 들어오는 모든 데이터는 먼저 Data Lake를 통과해야 하므로 Data Lake가 단일 진실의 원천으로 남을 수 있도록 더 잘 보장할 수 있음
결론
- 마이그레이션의 성공에 따라 약 12개의 다른 데이터 세트에 이러한 변경 사항을 적용했으며 전반적으로 유사한 이점을 관찰함
- AWS Redshift Spectrum 및 DBT와 같은 도구를 활용하여 인프라를 진화하는 데이터 요구 사항에 맞게 조정하여 사용자와 이해 관계자에게 더 큰 가치를 제공함