Inflearn コミュニティ Q&A
投稿した質問数
람다 아키텍처에서 speed layer 관련 질문드립니다
作成
·
28
0
안녕하세요~
람다 아키텍처에서 speed layer 부분에 궁금한 점이 생겨 질문드립니다!
Q1. speed layer는 어딘가에 저장이 된 후에 serving layer에서 보여지는건지 궁금합니다
저장이 된 결과가 보여지는 거라면 serving layer에서 전 날의 결과도 같이 보여지게 되는걸까요?
아니면 별도의 설정 같은 걸로 전 날 데이터는 삭제가 되는걸까요?
Q2. speed layer에서 보여진 데이터가 다음 날에는 batch layer에 들어갈텐데 데이터 중복은 어떻게 처리할 수 있나요?
감사합니다!
回答 1
0
안녕하세요!
질문에 순서대로 답변 드릴께요.
Speed Layer도 데이터를 처리하기 위해 저장소를 가지고 있습니다. 어딘가 저장이 되긴 합니다. 그래야 서비스 Fail 후 재시작 했을 때 재처리 같은 작업이 가능합니다. 그런데 설명드린 람다 아키텍처는 개념 아키텍처라고 이해하셔야 합니다.
스피드 레이어가 최종 처리한 데이터를 어디에 저장할 것인가는 람다 아키텍처가 알려주지는 않습니다. 누가 알려주는지는 사실 논리 아키텍처를 작성하는 단계에서 아키텍트가 결정하면 됩니다.
서빙 레이어는 배치 레이어가 만든 데이터 + 스피드 레이어가 만든 데이터를 같이 볼 수 있어야 하므로 보통 S3 Object Storage 또는 사용하고 있는 DBMS에 맞는 저장소에 저장하게 됩니다.
예를 들면 서빙 레이어로 Trino 를 쓴다면 스피드 레이어가 처리한 데이터는 Trino에 저장하면 되겠죠? 또는 S3 Object Storage에 저장해도 됩니다.
그럼 질문하신 것처럼 해당 저장소에 스피드 레이어가 처리한 데이터들이 실시간으로 쌓일 겁니다. S3 Object Storage에 쌓인다면 밤바미님 말씀처럼 일주일 정도 지난 것들은 삭제하도록 설정을 걸어놓기도 합니다.그럼 서빙 레이어가 존재하는 영역에는 스피드 레이어가 쌓아온 일주일치 데이터가 배치 데이터와 함께 공존하게 될 텐데, 중복은 어떻게 제거하냐가 핵심이지요?
사실 이것도 상세 도구를 선택하게 되면 도구마다 어떻게 해결할 것인지, 아키텍처를 어떻게 잡을 지는 천차만별이라 정답이라 할 수 있는 건 없습니다.
최근에는 Parquet 같은 포맷보다, Iceberg 또는 Deltalake 라는 오픈 테이블 포맷을 많이 씁니다. 이런 포맷들은 OLAP성 처리에도 강하면서 OLTP성 처리에도 강한 특성을 보이는데 동일한 Iceberg 테이블에 배치처리 + 스피드 레이어 처리를 반영하게 되면 별도 View 분리없이 하나의 소스만 가지고 쿼리를 할 수도 있습니다.
또는 kafka 의 sink connector 라는 기능을 이용해서 처리된 데이터를 하나의 테이블로 merge 침으로써 배치 레이어가 처리한 테이블과 같은 테이블을 사용할 수도 있습니다.
아니면 스피드 레이어는 A라는 테이블에 데이터를 쌓습니다.
배치 레이어는 B라는 테이블에 데이터를 쌓습니다.
B라는 테이블에는 전일자 24시까지의 데이터가 모두 존재한다고 한다면
SELECT * FROM A WHERE TIMESTAMP >= CURRENT_DATE
UNION ALL
SELECT * FROM B WHERE TIMESTAMP < CURRENT_DATE
이런식으로 결합한 뷰를 정의해서 써도 됩니다.
하지만 이렇게 뷰를 분리하는 것보다는 하나의 테이블에 통합 관리하는 방법이 더 좋지 않을까 합니다.
결론은 람다 아키텍처는 개념적인 아키텍처라 너무 거기에 매몰되어서 생각하지 않으시는게 좋습니다. 실제 현업에서는 해결할 수 있는 방법이 다양해서요.
시원한 답변은 되지 않으셨겠지만 우선 강의 뒤에 있는 실습을 해보시면서 감을 잡으시는게 좋을거에요. 또 질문 있으면 언제든 남겨주세요 ^^