Financial Timesのデータプラットフォーム構築記

130年の歴史を持つ新聞社のデジタルトランスフォーメーションの話

G1. 2008〜2014 : 閲覧した記事に基づくニュース推薦に集中。SQL Serverベース

G2. 2014〜2016 : ETLの導入。大規模データ分析と新たな問い、データ量の増大

→ SQL Serverがボトルネック。Redshift + ETL Framework に移行

→ 1日に何度もSQLを実行するようスケジューリングを自動化

→ SQL + Python で複雑なデータモデルをサポート

G3. 2016〜2018 : ビッグデータ@FT の始まり

→ データレイテンシの最小化を目標に。Data Ingestion が1日1回(24h)。これを減らせばより速くトレンドに対応可能

→ 読者のインタラクションをすべて送信できる独自トラッキングライブラリを開発

→ すべてのイベントを AWS SNS → SQS → Kinesis → Parquet → Redshift

→ Raw Event を処理するNodeJSサーバーを作り、内外部データを組み合わせてイベントを enrich した後 Kinesis に載せる

→ Kinesis Firehose を利用してイベントをCSVにしてS3に保存

→ イベント重複が発生する状況があり、これを処理する別のRedshiftクラスターを作ると、そのせいでレイテンシが遅くなる

G4. 2019 : ビジネス価値の追加に重点を置いてプラットフォームをリビルド

→ データプラットフォームをPaaSに変えたかった

→ Kubernetes導入。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 を改善し、ストリーム処理をドラッグ&ドロップで可能にする予定

[kbumsik]

おお、こういうブログ記事は好きです。各アーキテクチャ世代ごとの悩みが込められていますね。メディア企業でもこの規模のデータプラットフォームを設計するのですね。

[kbumsik]

ところで、SQS -> Nodejs ループ -> Kinesis みたいな形でつないでいるんですね。単純に Kinesis 1つで済ませられないのか気になります。まだ AWS にあまり詳しくないので 泣

[cbbatte]

良い記事の要約をありがとうございます！

[xguru]

ここで出てくる用語の説明をご覧になりたい場合は、

• 最新データインフラのための新しいアーキテクチャ https://ja.news.hada.io/topic?id=3055

上記の記事と、GeekNews YouTubeの「最新データインフラを理解する」動画を参考にしてください。

• https://youtube.com/playlist?list=PLL-_zEJctPoJ92HmbGxFv1Pv_ugsggGD2

そして、同じくデジタルトランスフォーメーションに成功したニューヨーク・タイムズの事例もあわせて参考にしてください。

失敗しないニューヨーク・タイムズ - NYTはいかにしてデジタル化に成功したのか

• https://youtu.be/K2qiAFTzDLU

• （失敗しない）ニューヨーク・タイムズ https://ja.news.hada.io/topic?id=3172