はじめに
こんにちは！ 東京工業大学（東京科学大学理工学系）理学院物理学系 修士1年の松本侑真です。2024年8月26日から6週間、私はアナリティクスエンジニアリング1（AE1）チームのインターンシップに参加しました。本記事では、ETLパイプライン再設計の取り組みを紹介します。
背景
AE1チームのミッション
AE1チームのミッションの一つは、「データモデリングを活用したETLパイプラインの再設計による分析コスト削減への貢献」です。今回のインターンシップでは、その取り組みの一環としてLINE公式アカウント事業に関係するETLパイプラインの再設計を行いました。ETLはデータ分析の基盤であり、データの抽出・変換・格納までの重要な各工程を指します。ETLパイプラインを適切に設計することにより、データ活用において次のようなメリットが得られます。
- 可用性・耐障害性の高いデータ分析基盤を提供できる
- メンテナンス性の高い設計を実現することで、要件変更に対して柔軟に対応できる
- 利用価値の高いデータへのアクセスを容易にできる
これらのメリットは、対応に時間がかかっていたロジックの修正を迅速に行うことや、障害発生時の手動による復旧対応を減らすことなどにつながります。
LINE公式アカウントとは
LINE公式アカウント（Official Account: OA）は、LINE上で企業や店舗がアカウントをつくり、友だち追加してくれたユーザーに直接情報を届けることができるサービスです。現在、37万を超える企業や店舗がアカウントを作成してビジネスに活用しています。日本の人口の約70％、9,700万人という多くのユーザー数を誇るLINE上にアカウントを作成することで、販促や集客に関するさまざまな施策を実施できます。（LINEヤフー for Businessの説明より）
OAではメッセージ運用の自動化やクーポン配布、予約機能といったさまざまな機能が提供されています。これらの機能を組み合わせることで、アカウントオーナーはLINE上で効果的にマーケティングを行うことができます。飲食、EC、美容、教育をはじめとする幅広い業界でOAが活用されています。
OA事業におけるデータ活用
OA事業では、プロダクト改善のためにデータに基づいた企画立案や意思決定を行っています。そのなかで、OAには数多くの機能が備わっており、それらの機能ごとにデータが生成されていることが、事業部内でのデータ活用のハードルをあげていました。そこで、それらの機能の利用状況をアカウント単位で集計し、一覧できるひとつのフラットスキーマのデータマートが作成されました。既に各機能について集計されたデータマートであることから、事業部の方々はテーブルを参照するための基本的な SQL を書くことだけで、必要とする集計結果を得たり、それを用いて可視化できます。
インターンシップの目的
上述したデータマートは事業部に広く普及しており利用頻度も高いものでした。その一方 で、データマートを管理運用するという保守性の観点と、データマートの情報を事業活動に用いるデータ利活用の観点に分けられる課題を抱えていました。本インターンシップでは、その課題を解決することを目的とします。解決にあたり、データマートを再設計することになったため、以降では既存のデータマートを「旧データマート」、再設計後のデータマートを「新データマート」と呼ぶことにします。
旧データマートが抱えている課題
旧データマートは大きく分けて3つの課題を抱えています。そのうち2つの課題は保守性の観点からみた課題として分けることができます。
保守性の観点からみた1つ目の課題は、参照している複数のソーステーブルのうち、1つでも更新に支障をきたした場合、データマート全体の更新が停止してしまうことです。一つひとつのソーステーブルの更新が失敗することはそれほど頻繁に起きるわけではありませんが、参照しているテーブル数が20を超えているため、いずれかの更新が失敗する確率はかなり高くなります。実際に頻繁にデータマートの更新ができない状況になっていました。また、ソーステーブル復旧後のデータマートの再生成コストも増大していました。
加えて、2つ目の課題は、集計項目の追加や削除への対応にかかるコストが 大きいことです。将来的なOAの機能変更などに伴い、取得したい項目の追加や変更が生じる可能性があります。旧データマートでは、密結合なETLパイプラインであることが原因で、項目の追加や削除の際の検証コストが大きくなっていました。
最後に、3つ目の課題はデータ利活用の観点からみた課題です。これは、データの集計定義が現在の事業活動で求められている要件にそぐわないものとなっているという課題があります。旧データマートが作成された当時から時間が経ち、ソーステーブルの仕様変更や事業の変化に伴った変更に対応が追いついておらず、時代遅れの集計定義が残っています。また、定義が複雑化し、クエリを確認しなければ正確な定義を把握できなくなってしまった項目も存在します。しかし、現在の事業活動の理解をしないまま、既存の集計定義を独断で変更すると混乱を招きます。OA事業でのデータマートの利用状況を確認しつつ、データ活用に支障がないように再設計する必要がありました。
旧データマートが抱える課題を解決するためのアプローチ方法を表にまとめました。次章では、それぞれのアプローチの詳細を解説します。
| 観点 | 課題 | アプローチ |
|---|---|---|
| 保守性 | ソーステーブルが一部でも欠落してしまうとデータマート全体の更新が止まってしまう | 中間テーブルの設計 |
| 保守性 | 集計項目の追加や削除への対応コストが大きい | 中間テーブルの設計 |
| データ利活用 | 集計定義が現在の利用環境に即していない | 集計定義のアップデート |
課題解決のアプローチ
中間テーブルの設計
すべてのソーステーブルをまとめて処理しようとするので、ソーステーブルが一部でも欠落してしまうと、データマート全体の更新が止まってしまうという状況が発生しています。そこで今回は一度、中間テーブルを作成し、集計処理をソーステーブルごとに分割することにします。事業部へ提供するテーブルはその中間テーブルをさらに処理して作成される構成にしました。
中間テーブルの設計案について、2つの案が検討しました。1つ目は、複数あるソーステーブルから、機能ごとにいくつかの集計項目をまとめた中間テーブルを複数用意するという、OAの機能ごとにデータの保存を物理的に分離する案です。この場合、異なる機能であるクーポンとメッセージに関する集計値は、それぞれ異なる中間テーブルとして保存されます。2つ目は、OAの機能ごとにパーティションを用意し、ひとつの中間テーブルに格納することで、データを論理的に分離する案です。
それぞれの設計案のメリット、デメリットを総合的に判断した結果、パーティションを用いた設計案を採用することにしました。この設計案を採用することによって、旧データマートが抱えていた課題のいくつかが解決されます。
非同期処理による耐障害性の向上
旧データマートの更新のためには、すべてのソーステーブルが正しく更新されるのを待たなければならない問題がありました。この問題の解決策の一つは、いくつかのソーステーブルごとに分離された非同期的な処理システムにすることです。例えば、更新が完了したソーステーブルから順番にデータを格納する中間テーブルを作成することで、更新が完了しているデータのみを用いてデータマートの更新が可能となります。このような非同期的な処理システムにすることで、必要な集計項目があったときに、対応する機能の処理さえ終わっていれば、ほかの機能の処理が終わっていなかったり、障害によって中断されていたとしても、欲しい情報にアクセスできます。
疎結合な設計によるメンテナンス性の向上
中間テーブルを作成することで、疎結合なパイプライン設計が可能になります。これにより、ETLパイプラインのメンテナンス性の向上が期待できます。例えば、データマートで集計する項目の定義に変更が生じた場合、今までの設計ではETLパイプライン全体をメンテナンスする必要がありました。中間テーブルを作成することで変更すべき箇所が明確になり、メンテナンス性の向上につながります 。
集計定義のアップデート
テーブル利活用の観点からの課題解決をはかるには、要件の刷新をして集計定義をアップデートする必要があります。適切な集計項目を定義するために、実際にデータを利用する事業部の方たちとヒアリングと議論を重ねました。定義変更における合意を得るプロセスのなかでは、次の2つのことを意識して準備に取り組みました。
1つ目は、データマートが各事業ドメインにおいて、どのような用途で利用されているかを事前に理解しておくことです。具体的には、旧データマートが作成された経緯や現在の利用状況などの徹底した事前調査を行いました。より効果的にデータを活用して事業活動を推進するためには、既存の使われ方とそこにあるニーズを正しくすくい上げることが必要です。そうすることではじめて適切な集計定義を策定できます。
2つ目は、収集可能なデータから、シンプルで実態に即した定義の集計項目を用意することです。項目の利用観点からだけでなく、保守性の観点からも優れたロジックが採用できるように、集計定義の候補を複数用意した状態で議論に臨みました。
このような準備が功を奏し、事業部の方との議論は支障なく進みました。こちら側から積極的にメンテナンス性の高いロジックを提案することもでき、スムーズなテーブル開発につながりました。
技術的な検討事項
データマートの作成形式としてテーブルとビューの2種類がありますが、そのどちらを採用するかについて検討しました。今回検討するうえで特に考慮したそれぞれの特徴を以下の表にま とめました。
| 特徴 | テーブル | ビュー |
|---|---|---|
| 定義 | データベース内のデータを格納する基本構造である | テーブルに基づいた仮想的なテーブルであり、物理的にデータを持たない |
| データの格納 | 実際のデータが格納される | 実際のデータは格納されず、クエリの結果として動的に生成される |
| パフォーマンス | データが直接格納されているため、高速なアクセスが可能である | クエリ実行時にデータを取得するため、実行時間がテーブルに劣る場合がある |
| カラムの追加方法 | ALTER TABLE文を使用して、スキーマの最後の列に追加することは簡単に可能である | CREATE VIEW文を変更することで、任意の位置に新しい列を簡単に追加可能である |
| カラムの削除方法 | ALTER TABLE文を使用すれば可能だが、一部制約がある | CREATE VIEW文を変更することで、任意の位置の列を簡単に削除できる |
新データマートでは、旧データマートと同じ作成形式（テーブル）を採用しました。特に採用の決め手となったのは、パフォーマンスの違いでした。取り扱うOA事業のデータは膨大となるため、実行時間が相応にかかることになります。このデータマートを複数の事業のメンバーが複数回参照するということを考えると、実行のたび取得に時間をかけてしまうビュー形式では、全体的な工数が物理テーブルを作成し格納しておくコストを上回ってしまうことになります。もし今回扱うデータ規模よりもずっと少量のデータを対象としたフラットスキーマのデータマート作成においては 、十分なパフォーマンスが期待される可能性も高く、ビューが選択肢に残るケースもあるでしょう。
再設計したETLパイプラインの検証
今回設計したETLパイプラインの導入により、旧データマートが抱えていた課題を解決できるかを検証しました。本番環境での実運用のまえに、ETLパイプラインのプロトタイプを作成し、動作確認を行いました。特に確認しておきたいこととしては、保守性の観点からみた1つ目の課題に対応できているかということです。このことは、一部のソーステーブルの更新が失敗していたとしても、それに引きずられることなく新データマートが生成されるかどうかで確認できます。また今回の仕様は、更新が失敗してしまったソーステーブルに関する集計値は、欠損として新データマートに格納されるよう設計しました。
| アカウント ID | アカウント 名 | 作成日時 | クーポン 配布数 | クーポン 利用数 | ショップ カード 配布数 | 有料 メッセージ 送信数 | … |
|---|---|---|---|---|---|---|---|
| ***** | ***** | 2020/04/01 | null | null | 8,000 | 10,000 | … |
| ***** | ***** | 2023/03/31 | null | null | 1,600 | 1,000 | … |
クーポン関連のソーステーブルが更新失敗した際に作成されるデータマートのイメージ（アカウント名、ID等は*****とマスクしています）
旧データマートにおいて他にあげられていた課題もすべて解決できました。改修後のパイプラインでの検証結果は以下の表にまとめています。
| 観点 | 旧データマートの課題 | 新データマートでの検証結果 |
|---|---|---|
| ETLパイプラインの運用・保守 | ソーステーブルが一部でも欠落してしまうとデータマート全体の更新が止まってしまう | 欠落しているソーステーブルに関連しない事業ドメインのデータは正常に更新できた。その際に、更新が失敗したデータはnullとなって生成される。 |
| ETLパイプラインの運用・保守 | 集計項目の追加や削除への対応コストが大きい | 疎結合なETLパイプラインの実現により、集計項目の変更対応は中間テーブルの導入によって、分離されたクエリ文の一部を変更することによって対応可能となった。これにより、変更時の検証コストの削減にもつながる。 |
| データマートの利用 | 集計定義が現在の利用環境に即していない | 事業部との議論を通じた集計定義のアップデートにより、利用環境に即したものに変更した。さらに、今後の定義変更にも容易に対応できる設計になっている。 |
今回のインターンシップでは再設計したETLパイプラインを用いることで、旧データマートが抱えていた複数の課題を解決できました。
今後は、これまでよりも実態に即したデータマートの提供と、ETLパイプラインの保守・運用コストの削減を実現でき、OA事業でのデータ活用の促進が期待できます。また、このような事例をつくっていくことで、同様の課題を抱えている他サービスでのパイプライン再設計を円滑に進めていくことにつながります。今回のタスクを通じて、AE1チームのミッションの一つである 「データモデリングを活用したETL パイプラインの再設計による分析コスト削減への貢献」を推進することに寄与できました。
インターンシップを通じて得られたこと
広く使われているテーブルのデータパイプラインの改修作業は挑戦的なテーマでしたが、AE1チームの小坪さんや今井さん、分析チームの佐野さんをはじめとするさまざまな方の手厚いサポートのおかげで、当初の目的であったETLパイプラインのプロトタイプ作成まで行うことができました。今回のインターンシップを通して、データエンジニアリングに関する一般的な手法や、アナリティクスエンジニアリングの役割についてはもちろんのこと、LINEヤフーの大規模な事業を支えているデータ分析業務についての深い理解も得られました。
部署の壁を超えて20名以上の方との1on1はとても貴重な経験でした。1on1を快く受けてくださった方々に感謝しています。さらに、社内の食堂でのおいしいランチは毎日の楽しみでした。さまざまなイベントにも参加でき、インターンシップでは業務以外の経験もできました。業務を幅広く支えてくださったAE1チームと分析チームの皆様、出社時にお世話になった福田さん、栗本さん、仲村さん、本当にありがとうございました。
