Financial Times의 데이터플랫폼 구축기
(medium.com)130년된 신문사의 디지털 트랜스포메이션 이야기
G1. 2008~2014 : 읽은 기사에 기반한 뉴스추천에 집중. SQL Server 기반
G2. 2014~2016 : ETL의 도입. 데규모 데이터 분석과 새로운 질문들, 데이타 양 증대
ㅤ→ SQL Server가 병목. Redshift + ETL Framework 로 전환
ㅤ→ 일간 몇번씩 SQL실행하도록 스케줄링 자동화
ㅤ→ SQL + Python 으로 복잡한 데이터 모델 지원
G3. 2016~2018 : 빅데이터@FT 의 시작
ㅤ→ 데이터 레이턴시 최소화를 목표. Data Ingestion 이 하루에 한번(24h). 이걸 줄여야 더 빠르게 트렌드에 대응가능
ㅤ→ 독자의 인터랙션을 모두 전송가능한 자체 트래킹 라이브러리 개발
ㅤ→ 모든 이벤트를 AWS SNS → SQS → Kinesis → Parquet → Redshift
ㅤ→ Raw Event를 처리할 NodeJS서버를 만들어 내외부 데이터를 조합해서 이벤트를 enrich 한후 Kinesis에 올림
ㅤ→ Kinesis Firehose 를 이용해서 이벤트를 CSV로 만들어 S3에 저장
ㅤ→ 이벤트 중복이 일어나는 상황이 있어서, 이를 처리하는 별도의 Redshift 클러스터를 만드니, 이거 때문에 레이턴시가 느려짐
G4. 2019 : 비즈니스 가치 추가에 중점을 두고 플랫폼을 리빌드
ㅤ→ 데이터 플랫폼을 PaaS로 바꾸고 싶었음
ㅤ→ 쿠버네티스 도입. ECS 에서 EKS로
ㅤ→ Airflow 도입
ㅤ→ AWS SNS → SQS → Kinesis → Parquet → Airflow → Redshift
G5. 2020 : 이제 실시간 데이터의 시대
ㅤ→ G4는 좋았지만 아직도 실시간은 불가능
ㅤ→ SNS,SQS,Kinesis 의 복잡한 세팅에서 Kafka로 전환 ( Amazon MSK )
ㅤ→ 스트림프로세싱 플랫폼은 Apache Spark
ㅤ→ kafka → spark → parquet(delta lake, redshift) ↔ airflow
ㅤ→ 데이터 검증을 위해서 Apache Avro 도입 : Data Contract
ㅤ→ Redshift, S3, Kafka 등을 쿼리하기 위해서 Presto 사용
앞으로의 계획
ㅤ→ 현재 Airflow, Spark, Kafka 3가지 컴포넌트에서 데이터가 들어오는데, 이걸 CDC(Change Data Capture) 기반으로 변경 예정
ㅤ→ 모든 사람들이 실시간 데이터에 접속할수 있도록 변경. Data UI 를 향상시켜서 스트림처리를 드래그 & 드랍으로 가능할수 있도록
그나저나 SQS -> Nodejs 루프 -> Kinesis 이런 식으로 연결했네요. 그냥 Kinesis 하나로 퉁칠 수 없는지 궁금하네요. 아직 AWS 잘 아는 편이 아니라서 ㅠ
여기서 나온 단어들의 설명을 보시려면,
- 최신 데이터 인프라를 위한 새로운 아키텍처 https://news.hada.io/topic?id=3055
위 글과 긱뉴스 유튜브의 "최신 데이터 인프라 이해하기" 영상을 참고하세요
- https://youtube.com/playlist?list=PLL-_zEJctPoJ92HmbGxFv1Pv_ugsggGD2
그리고, 비슷하게 디지털 트랜스포메이션에 성공한 뉴욕타임즈 이야기도 같이 참고하세요
실패하지 않는 뉴욕타임즈 - NYT는 어떻게 디지털화에 성공했나
- https://youtu.be/K2qiAFTzDLU
- (실패하지 않는) 뉴욕타임스 https://news.hada.io/topic?id=3172