Koibumi

Minero Aoki (@aamine)

No biography provided.

Activity

『事例講演「なぜクックパッドはRedshiftをデータ基盤に選び続けるのか」』 のフィードバックへ回答しました。 2021/04/06 15:29:42
Minero Aoki's icon
つらい点はいくつもありましたが、大半はRedshiftの機能強化によってすでに解決されてしまいました。

- 細かい更新を高頻度で行うと書き込みが詰まる → Spectrumで解決
- ログを毎日vacuum sort onlyするのが面倒すぎる → Spectrumで解決(パーティションがあるため)
- varcharの文字列長をしくじって伸ばしたいときテーブルの書き直しが必要 → Spectrum(Parquet)とalter table alter columnで解決
- ログに配列を含めたい、配列を行に展開したい → super型とPartiQLで解決しそう
- MySQLからのテーブル取り込みのセットアップが煩雑でセルフサービス化しにくい → FederatedQueryで解決
- MySQLからのインポート遅延を短縮したい → FederatedQueryで解決
- BIからの重いクエリーがすべてのリソースを食ってしまう → Concurrency Scalingで軽減
- クエリーの優先度がないために重要バッチが個人のクエリーに潰される → AutoWLMで軽減

現在残っている最も大きい不満はワークロード管理です。AutoWLMで多少よくなりましたが、もっと細かく「この処理にはリソース何%まで使ってよい」みたいな制限ができたら最高ですね。

チューニングというのはsortkeyとdistkeyの話かと思いますが、クックパッドで最も重くて苦しんでいる処理はログに対するアドホッククエリーで、その手のクエリーにはdistkeyがほとんど効果がないので、蓄積バッチに変えるなどの別の方法で解決しています。

たべみるのようなフロントDBとして使う部分については多少チューニングはしましたが、大量にあるわけではないですし、やることはだいたい決まっているのでさほど悩みませんでした。

分散並列DBのパフォーマンスチューニングは分散キーに始まって分散キーに終わると言っても過言ではなく、そこのチューニングができるなら十分ではないかと個人的には思います。マテリアライズドビューはもう1つの有力な選択肢ではありますが、あれは副作用も強いので、使いどころは限られますね。
『事例講演「なぜクックパッドはRedshiftをデータ基盤に選び続けるのか」』 のフィードバックへ回答しました。 2021/04/06 15:11:41
Minero Aoki's icon
これは簡単で、データ量に対してスケールしないからです。完全に並列処理可能ならマルチプロセスやマルチスレッドで処理することでスケールするかもしれませんが、ジョインや再分散が必要な計算を自前で書くのはコスパが悪すぎます。

ビッグデータの処理ではまずデータを移動させない(= DBの外に出さない、ネットワーク転送させない)のが大原則で、Redshiftが必要なデータ量に対してわざわざアプリケーションで処理するのは悪手と思います。
『事例講演「なぜクックパッドはRedshiftをデータ基盤に選び続けるのか」』 のフィードバックへ回答しました。 2021/04/06 15:07:45
Minero Aoki's icon
新しいサービスをAWSで作るならRedshiftを使うと思います。ただ、最初のうちはMySQLの分析用レプリカを使ってRubyのバッチを書くていどで事足りることが多い気はしますね。
『事例講演「なぜクックパッドはRedshiftをデータ基盤に選び続けるのか」』 のフィードバックへ回答しました。 2021/04/06 15:05:16
Minero Aoki's icon
3年reserved instanceを使っています。その影響でRA3への切り替えが今年になったという面はあります。とはいえRedshiftはreserved instanceの値引き率が異常に大きいので、使わない選択肢はほぼないと思っています。
『事例講演「なぜクックパッドはRedshiftをデータ基盤に選び続けるのか」』 のフィードバックへ回答しました。 2021/04/06 15:03:17
Minero Aoki's icon
(アーキテクチャの?)拡張性については、QAタイムにお答えしたように、例外を作らずにRedshiftに寄せていくことがポイントと思います。

(取り込む各種データの?)整合性については、あるていど諦めている面はあります。基本的には集計して使うので、集計結果の大勢に影響するような大きな誤差でなければ許容するというスタンスです。

一方、もし売上の処理のように誤差が許容できない処理がある場合は、例えば元データを履歴で持って行の更新が起こらないようなデータ形式にするなどの工夫をすると思います。行の更新が起こらなければ「いつ取り込むか」ではなくて「どこまで取り込んだか」という問題になるので、話がシンプルになります。

Participating events

Koibumi

    • Language
    • 🇺🇸 English
      • › 日本語
      • › English
    © 2020 ElevenBack LLC.