Upgrade to Pro — share decks privately, control downloads, hide ads and more …

大規模Hive-Trino移行PJの事例紹介

 大規模Hive-Trino移行PJの事例紹介

「Trino Japan Community Meetup 2024」での発表資料です。

LY Corporation Tech

July 16, 2024
Tweet

More Decks by LY Corporation Tech

Other Decks in Technology

Transcript

  1. © LY Corporation 2 • ҏ౻ ༞و (Yuki ito) •

    ܦྺ • ~2019: ౦ژ޻ۀେֶ म࢜ଔۀ • HPCΛઐ߈ • 2019: Ϡϑʔ (ݱLINEϠϑʔ)΁৽ଔೖࣾ • TrinoνʔϜʹॴଐ • 2023~: ࣾ಺TrinoͷProduct Managerʹ • झຯ: 3DCG ⾃⼰紹介
  2. © LY Corporation • 現在LINEヤフーではHive脱却を推進中 • Trino / Sparkへの移⾏することに •

    その移⾏PJについて紹介します! • 移⾏のモチベーション • 各種課題 / 対応の紹介、など 3 本発表について (Ref: https://hive.apache.org/) (Ref: https://trino.io/ ) (Ref: https://spark.apache.org/)
  3. © LY Corporation Agenda 01: Hive脱却の背景 Hive脱却のモチベーション / 課題感 02:

    Hive-Trino移⾏の進め⽅ 移⾏の実績作り / 各課題への対応検討 / ユーザへのアプローチ 03: 終わりに 4
  4. © LY Corporation • 社内だと⻑年Hive使う⽂化だった • が、時が経つにつれて課題が増えてきた… 6 背景 脆弱性

    Communityの 衰退 より⾼性能な PFの登場 PF側だけでなく client側の脆弱性も 将来的な改善が⾒込めない Trinoの⽅が⾼速 => コスト削減に繋がる Hive脱却 + Trinoへの移⾏を決意!!!
  5. © LY Corporation • 社内でHiveのワークロードは⼤量に存在 7 脱却に向けた課題 Þ 「どう進めていくか」から⼤きな課題に… •

    そもそも技術的に移⾏ができるのか • PF側の準備何をすればいいのか • ユーザ側の移⾏コスト⼤きい、etc… ユーザ数 数千アカウントが利⽤ クエリ数 dailyで数⼗万クエリ リソース使⽤量 サーバ数千台分
  6. © LY Corporation 1. 移⾏の下地作り • 社内でのTrino実績作り • 運⽤体制の改善 2.

    各課題の対策検討 • とにかく課題を洗い出し + 対策を進めた • (いくつか実際にあった課題紹介します) 3. ユーザへの各種アプローチ • 実際にユーザに動いてもらうのも⼤きな課題だった 9 全体としての流れ
  7. © LY Corporation • ユーザーが安⼼して移⾏できるような実績作り: • ⼀部のユースケースに絞って移⾏ • まずはTrinoが得意なSELECT系クエリをターゲットに Þ

    これによって社内でも少しずつ「Trino良さそう」って雰囲気を作れた • ユーザ増加への対策: • ユーザが増えると運⽤負担も増える • その前にTrino運⽤体制の改善は進めた • Trino on K8S化、など • (詳細は別途スターさんの発表参照) 10 1. 移⾏の下地作り kubernetes Trino クラスタA Trino クラスタB
  8. © LY Corporation • 社内ユースケースや社外資料を調査し、課題を洗い出し / 対策検討した • 特に参考になった社外資料: •

    Hive公式ドキュメント • Hive独⾃構⽂の洗い出しに • Meta社のHive脱却の紹介: • 4IBSFE'PVOEBUJPOT.PEFSOJ[JOH.FUB`T%BUB-BLFIPVTF • 社内だとユーザへのアンケートも実施して課題を洗い出した • 移⾏にあたっての懸念点をヒアリング • 実際に移⾏したユーザへ「苦労した点」のヒアリング 11 2.各課題への対策検討
  9. © LY Corporation 12 課題対応の事例 (1/3) 課題 対策 SQLの書き換えコストが⼤きい ルールベースの簡単なSQL変換ツールを提供

    • 100%は無理だけど少しでも楽できるように • ⾃動変換できないものは書き換えTipsでフォロー Trinoはfault tolerance⾯が弱い 重いETLジョブだと問題になる Þ Trinoだけで頑張らずにSparkも移⾏先として採⽤ ⼤量のUDF移⾏のための開発コスト 数⼗件のHive UDFがあった • 中には「開発者がもういないけど、使っている⼈はたくさんい る」ケースも… • 移⾏のためにはTrino版の開発が必要 Þ 基本的には「UDF使いたい⼈に作成してもらう」作戦に • 開発つらそうな場合はSparkへ誘導
  10. © LY Corporation 13 課題対応の事例 (2/3) 課題 対策 ⼤量のCREATE TEMPORARY

    TABLEの移⾏によるHMS負荷 1⽇数万件実⾏しているユーザいた • Trinoだとクエリ書き換え or 通常Table変更 • 通常Table頻繁に作られるとHMS負荷⾼い Þ がっつりワークロード⾒直し相談した • (いくつかの通常テーブルを毎⽇使い回してもらう形に) 1万カラムテーブルによる coordinator負荷 Trinoだとplanningだけでもcoordinatorへのメモリ負荷⾼い Þ Spark⾏ってもらった 参考: 下記のPRで負荷⾃体は緩和された • https://github.com/trinodb/trino/pull/15601 • https://github.com/trinodb/trino/pull/15721
  11. © LY Corporation 14 課題対応の事例 (3/3) 課題 対策 ユーザ増加によるTrino負荷増⼤ Hive感覚でTrino利⽤するユーザが増えた

    • 今までHiveだと無茶なクエリも動いていた (数TBのJOINなど) • そのままTrinoで実⾏しようとしてTrinoのcpuやメモリ、HDFS、 HMSなどに⾼負荷が発⽣ Þ 様々な負荷対策が必要に • クエリ単位のcputime / HDFS read量制限 • アカウント単位のcputime制限、など 制限⼊れた結果、効率の悪いクエリが減った Þ リソース使⽤量が削減 Þ サーバコスト削減にまで繋がった
  12. © LY Corporation 1. 全部事前に対策するのは現実的でない... • 社内のワークロードが多すぎて、事前にPF側で全て対応するのは不可能 • その代わりサポート体制はしっかり整えていった •

    問い合わせ⽤のslack部屋を⽤意 • 知⾒は常に社内ドキュメントへ反映 2. 基本的にはTrinoへ移⾏ + 困ったらSparkへ! • 特に問題起きやすかったのはETL系のワークロード • Trinoではメモリ負荷⾼い / fault torelance⾯で要件満たせない、など • ただ、多くのクエリはTrinoへ移⾏できている 15 課題対応してきた感想
  13. © LY Corporation • Hive脱却についてユーザ視点だと... Þ いかにモチベーション持ってもらうかも⼤きな課題の⼀つだった 16 3.ユーザへの各種アプローチ (1/2)

    今Hive安定しているのに なんで移⾏必要なの? ユーザAさん 他にもやらないと いけないことある… ユーザBさん
  14. © LY Corporation • ユーザにも移⾏モチベーション持ってもらえるようにコミュニケーションを⼯夫 • ユーザへのメリット提⽰は⼤事 • 誰に /

    どんなアプローチするべきかも考えた • 移⾏コストについてはサポート体制もセットでフォロー • 説明会も何度も実施 • 「⼀緒に頑張りましょう!」って雰囲気を重視 • 最終的には全社的なPJとして推進 • リスク (=脆弱性) 対応やコスト削減を⽬的として推進中 17 3.ユーザへの各種アプローチ (2/2) (現場の⼈向け) Trinoの⽅がxx倍も 速いです! (管理者向け) コストがxx億円 安くなります! Trinoチーム