Yahoo!ショッピング：データ基盤における次世代クエリエンジン（Spark/Trino）移行の取り組みについて

はじめに

本ブログシリーズでは、Yahoo!ショッピングのデータ分析基盤を最適化するために取り組んだ大規模プロジェクト――Apache HiveからTrinoとApache Sparkへの移行――について、詳しく解説しています。前回の記事（第1部）では、この移行がなぜ必要となったのか、そして具体的にどのような技術的背景があったのかを中心に取り上げました。

今回はその続編として、実際に移行を推進したチームメンバーたちの“リアルな声”や“現場で起きたドラマ”を深く掘り下げていきます。彼らがどのような困難に直面し、どのようにそれを克服してきたのか――そこには、同様の移行を考えている皆さまにとって参考になる、多くのヒントと学びが詰まっています。私たちが体験した試行錯誤のプロセスと、その先に芽生えた気づきを共有しながら、お読みいただく方々の一助になれば幸いです。

第1部の振り返り: Hiveの課題とTrino/Sparkの可能性

前回の記事（第1部（英語のみ））では、主に以下のようなトピックについて詳しく取り上げました。

なぜTrinoやSparkを選択肢に挙げたのか
- Trinoのインメモリ処理による高速クエリ応答性が、多くのインタラクティブ分析に適している点。
- Sparkは大規模分散処理に強く、大量のデータ削除や入れ替えが発生するシナリオにも対応可能。
Hiveの高コスト・長時間クエリ問題
- 100TBを超えるメモリを消費し、数時間実行し続ける巨大クエリの存在。
- 1回の実行で高額のコストが発生するケースもみられ、データ量の増加とともにこれらのクエリがますます膨れ上がる懸念。
具体的な処理の課題事例
- ユーザーのデータ削除要請により、パーティションあたり600GBを超える圧縮Columnarテーブルからデータを削除する必要が生じた場合、Hiveのみでは技術・コストの両面で大きな負担が生じる。
- これをTrinoやSparkで解決することで、作業負荷を軽減できる可能性がある。
リアルタイム分析やインタラクティブ分析への期待
- 企業がより迅速にデータドリブンな意思決定を行うには、Hiveだけに依存するアーキテクチャでは不十分。
- 運用効率と分析速度を同時に底上げできるTrinoやSparkへの移行は、不可欠なステップとなった。

こうした背景を踏まえ、私たちは既存のHiveベースの基盤を段階的にTrinoやSparkへとシフトする運びとなりました。移行の過程では、「単なるツールの入れ替え」にとどまらず、大規模データに対するアプローチそのものに変化をもたらすことが期待されます。

移行プロジェクトの背景とゴール

Yahoo!ショッピングでは、マーケットプレイスにおける日々の取引データ、ユーザ行動ログ、商品属性情報など、膨大で多様なデータを扱っています。これらの情報を集約・分析しながら、顧客体験の向上や売上増につなげるためには、データ基盤自身の耐久性・拡張性・パフォーマンスすべてが高水準で求められていました。
（※LINEヤフー株式会社ではお客様のプライバシーの保護に細心の注意を払っています。詳しくはLINEヤフープライバシーセンターをご覧ください。）

こうした要件を踏まえて、私たちが目指したゴールは以下の4点です:

バッチジョブやクエリの実行時間短縮
コスト削減（システムコストはもちろん、エンジニアの対応時間など総合的リソースの最適化含む）
データの整合性・完全性の確保
マイグレーションによる混乱を最小限に抑えながら、新たなインフラを定着させる

具体的には、約100のAirflow DAGと300ほどのSQLクエリをHiveからTrino・Sparkへ段階的に移行し、まずビジネスインパクトが比較的小さいクエリから着手するアプローチを取りました。こうすることで、大きなリスクを伴う作業を一度に進めるのではなく、サービスへの影響を抑えながら安全かつ着実に移行を進めることができたのです。

テックリーダーが語る次世代クエリエンジン移行の取り組み

ここでは、Yahoo!ショッピングデータの移行プロジェクトのシニアマネージャーである新井に、HiveからTrinoとSparkへの移行について全般的なお話を伺いました。

HiveからTrinoとSparkへの移行を決定した主な理由は何か

「コストと実行時間の改善が主な理由です。特に実行時間に関しては、出店者様向けのレポート提供に利用している部分もあり、データの提供時間に深く関わってきます。要望に応じて集計軸を増やすと、どうしても集計処理がどんどん重くなりますが、それをなるべく早く提供することで、出店者様が施策を考えるための時間を増やすことにつながります。」

Yahoo!ショッピング特有の課題や移行中に印象に残ったエピソードについて教えてください。それらの課題やチャレンジはどのように解決されましたか？

「アクセスログなどのデータ量が圧倒的に多かったため、大規模データの取り扱い中にメモリエラー（out of memory）が発生するケースがありました。特に、大きなクエリを移行した際にはメモリ不足が続発し、戸惑いもしましたが、メンバーが定期的・非定期的に集まり、問題について討論しながら中間テーブル化やパーティションなどを再検討しました。イシューを一つひとつ確実に乗り越えていく中で、エンジニアが積極的に試行錯誤できる文化が突破口になるのだと実感しました。」

現場の声: インタビューを通じて見えた躍進と苦闘

ここからは、移行プロジェクトを推進したメンバーたちへのインタビューから得られた、リアルな声をご紹介します。単なる技術論だけでなく、プロジェクト全体を成功に導いたアイデアや、現場での苦闘を乗り越える中で得られたヒントを取り上げたいと思います。彼らの体験談を通じて、データ移行の“リアル”を少しでも感じ取っていただければ幸いです。

なぜHiveから移行するのか？

移行を決断するうえで最も大きかった要因は、やはり“パフォーマンス向上”への期待でした。和田（プロジェクトメンバー）は、クエリ実行時間の劇的な短縮効果を次のように語っています。

「Hiveで数時間かかっていたSQLが、Trinoに移行すると驚くほど短い時間で完了するんです。バッチジョブ全体の終了が大きく前倒しできるだけでなく、開発中の検証や障害対応時の調査クエリも、あっという間に終わるようになりました。本当に助かっています。」

実際に「数時間が数十分になる」という改善は、エンジニアの働き方そのものを一変させるほどのインパクトがあります。これにより、夜通しクエリ実行を待つ必要がなくなり、限られた時間を新機能の開発やサービス改善など、より生産的な活動に割り当てられるようになりました。

ワークフローへの影響は？

次に、移行後のワークフロー全体でどのような変化が起きたのかを見てみましょう。高橋（プロジェクトメンバー）は、テストや検証プロセスそのものが大きく効率化されたと話します。

「Trinoのおかげでクエリ実行時間が短くなり、一度に処理できるテストや検証の数が格段に増えました。同じ時間内に何倍ものケースを試せるので、クエリを書くスキルやテーブル構造への理解が自然と深まるんです。『ここを少し変えてみよう』とか『別のアプローチを試してみよう』といった実験を気軽に繰り返すうちに、結果として組織全体のデータ活用度合いが高まっていると感じます。」

このように、作業スピードだけではなく「試行錯誤のしやすさ」が増したことで、ワークフロー全体の質が格段に向上しました。個人レベルでのスキルアップと組織全体でのイノベーションが、同期して進んでいるのです。

データ整合性と冪等性への挑戦

もちろん、すべての移行がスムーズに進んだわけではありません。特に、冪等性のないクエリは大きなハードルでした。渡邊（プロジェクトテックリード）は、ウィンドウ関数が引き起こす問題についてこう語ります。

以下に、内容を整理しながら読みやすさを高めた形で文章をまとめます。オリジナルの技術情報を保持しつつ、表現を少し柔らかく調整しています。

検証の過程では、特に冪等性をもたないクエリへの対応に苦労しました。通常、以下のような差分チェックを行い、本番環境（Hive）と開発環境（Trino/Spark）の出力結果が完全に一致すれば「移行成功」とみなします。実際には結果が一致しないケースがしばしば発生しました。特に、ウィンドウ関数の ROW_NUMBER() を使ったクエリが原因となることが多かったです。以下に例を示します。

まず、注文実績テーブルを以下のように定義します。
CREATE TABLE db.orders (
    order_id VARCHAR,
    timestamp BIGINT
);
このテーブルを注文時刻順に並べる場合、次のようなクエリがよく使用されます。
SELECT
    order_id,
    ROW_NUMBER() OVER (ORDER BY order_timestamp) AS num
FROM db.orders;
しかし、このクエリは非冪等性を持つため、実行するたびに ROW_NUMBER() の値が変動する可能性があります。これにより、移行後の検証時に結果が一致しない問題が発生することがありました。

もし order_timestamp がまったく同じ複数の order_id に割り当てられていると、クエリが実行されるたびに同じレコードに対して ROW_NUMBER() の値が1になったり2になったりする可能性があります。こうした非冪等的なクエリは、HiveでもTrinoでも実行結果に微妙な差分が生じるため、移行後の検証時に「差分が出た＝バグかもしれない」と疑われてしまうのです。

しかし実際には、Hive時代から同様に結果が変動していた場合もあり、単なる「クエリの書き換えミス」とは限りません。そのため、原因の切り分けに時間がかかり、トラブルシューティングが複雑化していました。

このような問題に対しては、大まかに以下のアプローチを取りました。

検証時に出た差分レコードをサンプリングし、そのレコードが非冪等性に起因するものかどうかを確かめる。
差分の件数がテーブル全体の件数と比べて十分小さいかどうかを確認する。
クエリに冪等性を簡単に導入できる場合は、なるべくそこを修正する。

このように、移行の過程でロジック上のあいまいさやデータ品質のグレーゾーンが浮き彫りになるのは、ある意味で「移行の醍醐味」とも言えます。今まで表面化していなかった問題を洗い出し、クエリやデータ定義を根本的に見直す機会となったのです。

プロジェクトを前進させたチーム・マネジメントの要

プロジェクトマネージャーの水谷は、Airflow DAGの管理とリアルタイムな意思決定の重要性について次のように語ります。

「AirflowのDAGが100もあり、それらが相互に連携して動作する場合、いくつかのパイプラインを個別に管理するよりも、エラーの発生確率が高くなります。そのため、エラーや警告の頻度も増加する傾向にあります。これを放置すると、すぐにSLA違反やデータパイプラインの滞留につながるため、問題が発生するたびに『これはTrinoで修正可能か？』『Sparkに切り替えるべきか？』と即断する必要があり、最初は正直かなり混乱していました。しかし、このリアルタイムの判断を全員で共有する仕組みを整えたことで、ノウハウが段階的に蓄積されていきました。」

たとえば、「Trinoで処理不可ならSparkに移す」「Sparkでも対応できないならテーブル分割や再設計を検討する」という段階的な基準をあらかじめ文書化し、各チームが同じ指針に基づいて行動できるようにしたことが大きな成功要因だったそうです。こうして属人化を防ぎつつ、素早い意思決定を可能にした仕組みが、移行プロジェクト全体の前進に寄与しました。

移行がもたらした意外な恩恵: 型管理とデータ品質

Trinoはデータ型が厳密であるため、思わぬメリットが得られた面もありました。高橋は次のように語ります。

「Hive時代は“文字列”に何でも放り込んで処理できちゃう気楽さがあった反面、知らないうちに型変換ミスやNULLの扱いが曖昧になっていることも多かったんです。Trinoは型エラーになりやすいので最初こそ面倒に感じましたが、『このカラムは本当にINTでいいの？』『空文字をNULLにするならCOALESCEを使うべきか？』といった議論が自然に生まれて、結果的にはデータ品質が明らかに底上げされました。」

移行作業にはコストと手間がかかる一方で、システムやデータを総点検し、より良い状態へアップデートする絶好の機会でもあります。単に「面倒な作業」として捉えるか、「改善の種を拾うチャンス」と考えるかが、最終的な成果を大きく左右すると言えるでしょう。

インタビュー要約

Yahoo!ショッピング特有の課題と対応策

Yahoo!ショッピングのような大規模サービスには、独特の課題があります。例えば、以下のような点が挙げられます：

取引情報や在庫データなど、多次元かつ粒度の異なるデータが頻繁に更新される。
キャンペーンやセール期間など、短期的にアクセスが集中しやすく、データの偏りが大きい。これにより、テーブルのパーティショニングが複雑化しがち。
売上やユーザ行動ログをほぼリアルタイムで分析し、即時にビジネス判断へ反映させる必要がある。
ユーザーのデータ削除要請が発生すると、圧縮された状態でパーティション当たり600GBを超える巨大なColumnarテーブルからデータを削除しなければならない。これは技術面・コスト面で大きな挑戦を伴う。

こうした要件への対策としては、Sparkを補完的に活用してメモリ不足を回避し、必要に応じてテーブルを分割（パーティション化やバケット化など）する方針をとりました。また、「Trinoはデータの厳密な制御」「Sparkは大規模分散処理」という棲み分けを明確にすることで、処理フローをシンプルに整理できた例も多かったようです。結果的に、複雑な要件が絡んだ場合でも、両ツールの得意分野をうまく組み合わせることで、安定した運用とスケーラビリティを確保することができました。

成功要因とベストプラクティスまとめ

これまでの議論を踏まえ、今回の移行で得られた主な知見やベストプラクティスを整理すると、以下のポイントに集約されます。

パフォーマンス指標とコストの早期モニタリング

実際に計測すると、単一のHiveクエリが数時間かかり、一度に高額のコストを発生させているケースが散見されました。こうした“危機感”をチーム内で共有することは、移行の優先度を明確にし、迅速な着手につながります。
- コストや実行時間を“見える化”することで、優先度の高いクエリから移行をスタートしやすくなりました。
Trinoを基本に、Sparkへ段階的に切り替え

まずTrinoで高速なSQL処理がどこまで可能か試し、メモリや機能制限にぶつかったらSparkに移すというフローを明文化。そのうえで誰もが同じ基準に従い、判断できる仕組みを作りました。
- 「どちらを使うか」を明確にするだけで、チーム間の齟齬や混乱が大きく減少しました。
データ整合性の検証に時間を割く覚悟

非冪等クエリやウィンドウ関数、NULL・型変換などの扱いには特に注意が必要でした。
- 差分チェックやサンプリングを組み合わせることで、実際のレコード差分を丁寧に精査し、バグ起因か非冪等性起因かを切り分ける工夫が求められました。
知見共有とコミュニケーションの徹底

トラブルが起きた際、個々のエンジニアが単独で解決して終わりにせず、チームやDAGオーナー間でノウハウを積極的に共有する文化が重要でした。
- エラーや成功事例はドキュメントやWikiなどにまとめ、頻出パターンを明確にしておくことで、同様の問題が再度発生した際の対応速度を高められます。
データ定義スキーマを再確認するチャンスと捉える

移行先がHiveより厳密な型指定を必要とする場合、従来のあいまいな定義やワークアラウンドを洗い出す絶好の機会となります。
- 新しいツールを導入したことで、日常的に見過ごされていた問題が可視化され、データ品質の向上に直結しました。

以上のポイントを踏まえることで、複雑で大規模な移行プロジェクトにおいても、パフォーマンス向上だけでなく、チーム全体の成長とデータ品質の向上を同時に実現できる可能性が高まります。

まとめと今後の展望

HiveからTrino・Sparkへの移行は、決して平坦な道のりではありませんでした。非冪等クエリや大規模ジョブのメモリ不足、各種メタデータとの同期といった数々の技術的ハードルを乗り越える必要があったのです。しかし、その過程で「不要なコストを浪費していたクエリ」や「型管理のあいまいさ」といった“負の遺産”を一つひとつ解消することができました。

結果として、

従来よりも高速かつスムーズなバッチ処理、
データ品質をより厳密にコントロールできる仕組み、
エンジニアが積極的に試行錯誤できる文化

といった、大きな成果を得られたのです。最大の収穫は、単なるツールの置き換えにとどまらず、“データ基盤に対する考え方と作業文化そのものがレベルアップした” 点にあるのかもしれません。

今後は、よりリアルタイムに近い分析ニーズに対応するため、TrinoとSparkの使い分けをさらに最適化していく予定です。たとえば、パーティションやバケット分割の戦略を洗練させたり、Apache Icebergのような新技術を試験的に導入しながら、スキーマ進化やテーブル管理を強化していく可能性も十分に考えられます。

本シリーズでは、私たちの移行を通じて見えた「技術革新と組織変革のリアル」を共有してきました。少しでも皆さまの参考になれば幸いです。ご意見・ご質問などありましたら、ぜひコメントやお問い合わせでお寄せください。今後も引き続き、移行の過程で得た知見やノウハウをアップデートし、お届けしていきたいと思います。

参考リンク

あなたのプロジェクトでもHiveからTrinoやSparkへの移行を考えている場合、この記事で紹介したエピソードやベストプラクティスが一助となることを願っています。どうぞお楽しみに！