Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大規模Hive-Trino移行PJの事例紹介
Search
LY Corporation Tech
PRO
July 16, 2024
Technology
2
340
大規模Hive-Trino移行PJの事例紹介
「Trino Japan Community Meetup 2024」での発表資料です。
LY Corporation Tech
PRO
July 16, 2024
Tweet
Share
More Decks by LY Corporation Tech
See All by LY Corporation Tech
LeSSに潜む「隠れWF病」とその処方箋
lycorptech_jp
PRO
2
68
新卒2年目エンジニアがLINEギフトの保守性を高めるために取り組んだこと
lycorptech_jp
PRO
2
390
Trusted Types API と Vue.js
lycorptech_jp
PRO
1
260
LeSSをはじめよう〜LeSSをはじめるとき、LeSSをはじめてから、知りたかったこと詰め合わせ〜
lycorptech_jp
PRO
2
140
合併後のインフラ環境におけるアラートフローの問題点洗い出しと改善をした話
lycorptech_jp
PRO
1
98
はじめてのアクセシビリティ実践記
lycorptech_jp
PRO
2
85
Real World Ray
lycorptech_jp
PRO
1
42
アナリティクスエンジニアとその周辺の技術について
lycorptech_jp
PRO
1
82
풍성한 디자인 요청사항에 대응하기
lycorptech_jp
PRO
0
20
Other Decks in Technology
See All in Technology
Data Migration on Rails
ohbarye
6
3.4k
VPoE Meetup Vol.1 VPoEとして実践してきたことと反省点
coconala_engineer
3
240
EKS初心者が早めに知っておきたかったこと
cuorain
0
130
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
110
サーバーサイドのデータプレーンプログラミング 〜 NVIDIA Blue Field / DOCA 〜
ebiken
PRO
1
220
リファクタリングへの耐性が高いモデルベースの統合テストの紹介 / Model-Base Integration Test for Refactoring
yuitosato
5
1.2k
日経ビジュアルデータにおける スクロールテリングと地図/nikkei-tech-talk-26
nikkei_engineer_recruiting
0
150
Kubernetes Summit 2024 Keynote:104 在 GitOps 大規模實踐中的甜蜜與苦澀
yaosiang
0
250
Why and Why not of enabling swap in Kubernetes
hwchiu
0
440
開発健全性の可視化と開発者体験の改善 ~ Compassでエンジニアに活力と生産性を ~
atlassianjapan
0
170
サーバーレス SaaS における運用監視の負荷軽減のためのアプローチ
ririru0325
0
130
クラシルの現在とこれから
am1157154
1
320
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
65
11k
Designing for humans not robots
tammielis
249
25k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
9
660
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
KATA
mclloyd
29
13k
The Cost Of JavaScript in 2023
addyosmani
45
6k
Building an army of robots
kneath
302
42k
Raft: Consensus for Rubyists
vanstee
136
6.6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Transcript
© LY Corporation ⼤規模Hive-Trino移⾏PJの 事例紹介 LINEヤフー株式会社 伊藤 祐貴 (Yuki Ito)
© LY Corporation 2 • ҏ౻ ༞و (Yuki ito) •
ܦྺ • ~2019: ౦ژۀେֶ म࢜ଔۀ • HPCΛઐ߈ • 2019: Ϡϑʔ (ݱLINEϠϑʔ)৽ଔೖࣾ • TrinoνʔϜʹॴଐ • 2023~: ࣾTrinoͷProduct Managerʹ • झຯ: 3DCG ⾃⼰紹介
© LY Corporation • 現在LINEヤフーではHive脱却を推進中 • Trino / Sparkへの移⾏することに •
その移⾏PJについて紹介します! • 移⾏のモチベーション • 各種課題 / 対応の紹介、など 3 本発表について (Ref: https://hive.apache.org/) (Ref: https://trino.io/ ) (Ref: https://spark.apache.org/)
© LY Corporation Agenda 01: Hive脱却の背景 Hive脱却のモチベーション / 課題感 02:
Hive-Trino移⾏の進め⽅ 移⾏の実績作り / 各課題への対応検討 / ユーザへのアプローチ 03: 終わりに 4
© LY Corporation 01: Hive脱却の背景 5
© LY Corporation • 社内だと⻑年Hive使う⽂化だった • が、時が経つにつれて課題が増えてきた… 6 背景 脆弱性
Communityの 衰退 より⾼性能な PFの登場 PF側だけでなく client側の脆弱性も 将来的な改善が⾒込めない Trinoの⽅が⾼速 => コスト削減に繋がる Hive脱却 + Trinoへの移⾏を決意!!!
© LY Corporation • 社内でHiveのワークロードは⼤量に存在 7 脱却に向けた課題 Þ 「どう進めていくか」から⼤きな課題に… •
そもそも技術的に移⾏ができるのか • PF側の準備何をすればいいのか • ユーザ側の移⾏コスト⼤きい、etc… ユーザ数 数千アカウントが利⽤ クエリ数 dailyで数⼗万クエリ リソース使⽤量 サーバ数千台分
© LY Corporation 02: Hive-Trino移⾏の進め⽅ 8
© LY Corporation 1. 移⾏の下地作り • 社内でのTrino実績作り • 運⽤体制の改善 2.
各課題の対策検討 • とにかく課題を洗い出し + 対策を進めた • (いくつか実際にあった課題紹介します) 3. ユーザへの各種アプローチ • 実際にユーザに動いてもらうのも⼤きな課題だった 9 全体としての流れ
© LY Corporation • ユーザーが安⼼して移⾏できるような実績作り: • ⼀部のユースケースに絞って移⾏ • まずはTrinoが得意なSELECT系クエリをターゲットに Þ
これによって社内でも少しずつ「Trino良さそう」って雰囲気を作れた • ユーザ増加への対策: • ユーザが増えると運⽤負担も増える • その前にTrino運⽤体制の改善は進めた • Trino on K8S化、など • (詳細は別途スターさんの発表参照) 10 1. 移⾏の下地作り kubernetes Trino クラスタA Trino クラスタB
© LY Corporation • 社内ユースケースや社外資料を調査し、課題を洗い出し / 対策検討した • 特に参考になった社外資料: •
Hive公式ドキュメント • Hive独⾃構⽂の洗い出しに • Meta社のHive脱却の紹介: • 4IBSFE'PVOEBUJPOT.PEFSOJ[JOH.FUB`T%BUB-BLFIPVTF • 社内だとユーザへのアンケートも実施して課題を洗い出した • 移⾏にあたっての懸念点をヒアリング • 実際に移⾏したユーザへ「苦労した点」のヒアリング 11 2.各課題への対策検討
© LY Corporation 12 課題対応の事例 (1/3) 課題 対策 SQLの書き換えコストが⼤きい ルールベースの簡単なSQL変換ツールを提供
• 100%は無理だけど少しでも楽できるように • ⾃動変換できないものは書き換えTipsでフォロー Trinoはfault tolerance⾯が弱い 重いETLジョブだと問題になる Þ Trinoだけで頑張らずにSparkも移⾏先として採⽤ ⼤量のUDF移⾏のための開発コスト 数⼗件のHive UDFがあった • 中には「開発者がもういないけど、使っている⼈はたくさんい る」ケースも… • 移⾏のためにはTrino版の開発が必要 Þ 基本的には「UDF使いたい⼈に作成してもらう」作戦に • 開発つらそうな場合はSparkへ誘導
© 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
© LY Corporation 14 課題対応の事例 (3/3) 課題 対策 ユーザ増加によるTrino負荷増⼤ Hive感覚でTrino利⽤するユーザが増えた
• 今までHiveだと無茶なクエリも動いていた (数TBのJOINなど) • そのままTrinoで実⾏しようとしてTrinoのcpuやメモリ、HDFS、 HMSなどに⾼負荷が発⽣ Þ 様々な負荷対策が必要に • クエリ単位のcputime / HDFS read量制限 • アカウント単位のcputime制限、など 制限⼊れた結果、効率の悪いクエリが減った Þ リソース使⽤量が削減 Þ サーバコスト削減にまで繋がった
© LY Corporation 1. 全部事前に対策するのは現実的でない... • 社内のワークロードが多すぎて、事前にPF側で全て対応するのは不可能 • その代わりサポート体制はしっかり整えていった •
問い合わせ⽤のslack部屋を⽤意 • 知⾒は常に社内ドキュメントへ反映 2. 基本的にはTrinoへ移⾏ + 困ったらSparkへ! • 特に問題起きやすかったのはETL系のワークロード • Trinoではメモリ負荷⾼い / fault torelance⾯で要件満たせない、など • ただ、多くのクエリはTrinoへ移⾏できている 15 課題対応してきた感想
© LY Corporation • Hive脱却についてユーザ視点だと... Þ いかにモチベーション持ってもらうかも⼤きな課題の⼀つだった 16 3.ユーザへの各種アプローチ (1/2)
今Hive安定しているのに なんで移⾏必要なの? ユーザAさん 他にもやらないと いけないことある… ユーザBさん
© LY Corporation • ユーザにも移⾏モチベーション持ってもらえるようにコミュニケーションを⼯夫 • ユーザへのメリット提⽰は⼤事 • 誰に /
どんなアプローチするべきかも考えた • 移⾏コストについてはサポート体制もセットでフォロー • 説明会も何度も実施 • 「⼀緒に頑張りましょう!」って雰囲気を重視 • 最終的には全社的なPJとして推進 • リスク (=脆弱性) 対応やコスト削減を⽬的として推進中 17 3.ユーザへの各種アプローチ (2/2) (現場の⼈向け) Trinoの⽅がxx倍も 速いです! (管理者向け) コストがxx億円 安くなります! Trinoチーム
© LY Corporation 03: 終わりに 18
© LY Corporation • まだ移⾏終わっていないので、この進め⽅が正解だったかはわからない… • 現在ラストスパート中、頑張ります!!! • 何かしら⼤規模な移⾏PJの参考になれば •
個⼈的にはこういう知⾒がどこかにあって欲しかった • (Hive-Trino移⾏に限らず?) 19 終わりに
© LY Corporation Q&A 20