Downloaded 10 times
Uploaded byYoshikazu Suganuma
データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用
Hadoop Spark Conference 2019 データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用
データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用
- 1. データサイズ２ペタ ソネット・メディア・ネットワークス でのImpala活用とHadoop運用 Hadoop / SparkConference Japan 2019 So-net Media Networks 菅沼 嘉一
- 2. 菅沼 嘉一 Yoshikazu Suganuma So-netMedia Networks 分析基盤T Cloudera Hadoopの障害対応したり、python/Goでツール作成したり Go言語好き！
- 3. 目次 ● Hadoopの用途 ● Hadoopの環境 ●ビッグデータ管理大変だよね！
- 4.
- 5.
- 6. ● 広告配信ログを保管 ● データサイズ：約2PB ●総レコード数：約1.1兆 ● 1日あたり約8TB増加 ● 主にデータ分析用途
- 7.
- 8. サーバースペック(データノード) スペック： Dell PowerEdge R720xd/R730xd/R740xd/R740xd2(予定) メモリ：約370GB/サーバー HDD：約90～160TB/サーバー (10TBx 18, 10TB x 12, 8TB x 12) PowerEdge R740xd
- 9. Hadoop構成 CDH 5.15 データノード：20 台＝ 約2PB その他ノード：8台 (合計28台/1クラスター) (Zookeeper, Journal NodeにはIntel Optane SSDストレージ搭載) メタデータはAWS RDSに保管 Active-Standby の2クラスター構成
- 10. Data Node DataNode Data Node Data Node Data Node Data Node ……………… ……. ……………… ……. x 20 Name Node Zookeeper JournalNode Hive Metastore Impala Catalog ……………… ……. x 8 Hadoop クラスター
- 11.
- 12. 主なImpalaの使い方 Hiveから1時間毎にParquet生成 Impala + Parquetはレスポンス最速 クエリ数：約13万クエリ/月 PQサイズ：約750TB
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21. CDHバージョン遍歴 今年はCDH6.1にバージョンアップ予定 年代 クラスターA クラスターB 2015～CDH5.1 (hadoop-2.3.0) 2016～ CDH5.7 (hadoop-2.6.0) 2018～ CDH5.15(現在) (hadoop-2.6.0) 2019～ CDH6.1(構築中) (hadoop-3.0.0)
- 22.
Editor's Notes
- #4 本日の目次ですがスライドにありますように ・Hadoopの用途 ・Hadoopの環境 ・ビッグデータを管理をしていく上での大変だったところ を紹介したいと思います。
- #6 ソネット・メディア・ネットワークスではDSP型の広告配信プラットフォームであるLogicadというサービスを提供しています。 膨大な配信ログをもとに最適な入札額を推定し、精度の高いターゲティングを提供しています。
- #7 Hadoopの用途としては、主にLogicadの広告配信ログを保管しています。 全体総量としてのデータサイズは約２ペタバイトを保管していて、レコード数としては約1.1兆レコードになります。 一日あたりに増加するログの量としては、約８TB近く増えていっています。 ログの使用用途ついてですが、主にデータ分析の用途に使っています。
- #8 次にHadoopの環境を紹介します
- #9 Hadoopはオンプレ環境で運用しています。 データノードのサーバースペックですが、Dell製のPowerEdge R720xdからR740xdを使っています。 メモリは1台あたり約370ギガバイトのメモリを用意し、ディスク容量は1台あたり90テラバイトから160テラバイトを搭載しています。
- #10 Hadoop構成についてですが、HadoopのディストリビューションはCloudera Hadoopを使っておりバージョンは5.15です。 データノードは２０台、データノード以外のノードは8台あり、合計で1クラスターあたり28台で構成しています。 一部ZookeeperとJournal NodeにはIntel Optane SSDメモリを搭載しています。 またバージョンアップを考慮して、同じサーバー構成を2つ用意してActive-Standby の2クラスター構成で運用しています。 それについては後程スライドで紹介したいと思います。
- #11 システム構成図ですが、説明は飛ばします。
- #13 主なImpalaの使い方についてです。 主にやっていることは、ログを１時間ごとにHiveで読みとってParquet形式に変換しています。 カラム指向のParquetファイルをImpalaで検索する組み合わせは、体感的にとても早いと感じていて基本的にImpalaを使っています。 クエリ数：約13万クエリ/月でPQサイズ：約750TBです
- #14 次にビッグデータを管理していく上での大変なところを紹介します。
- #15 一日当たり８TB増加するのですぐに容量が枯渇していきます。 そのために容量を常にチェックしており、まめに古いデータを削除して保存期間を調整しています。 またデータ容量が90%近くになるとHive, Impalaのレスポンスが悪くなる傾向わかっているので、データ増加を予測して早めのデータノードを追加していきます。
- #16 データ容量も問題になることもありますが、パーティション数が多すぎることで問題が起こることもありました。 一つ前の世代のクラスターでは5.7を使っていてパーティションが20万あった時があり、Impalaが動かなくなったことがありました。 今のバージョン5.15では多めの18万パーティションあっても動くようです。 Clouderaの推奨値では5万以下のパーティション数に抑えるようにと聞いたことがありますが、非常に難しいんじゃないかと思っています。
- #17 データサイズの傾向やパーティション数を把握するために、月に一回Hadoopの全体チェックをしています。 全体チェックをすることで、データベースのテーブル数や個々のデータサイズの増加傾向を把握したり、パーティション数を把握できます。 そうすることでパーティションの切り方を再検討してリスクを減らすことができるのでとても大事なレポートになっています。
- #18 他にもElasticsearchとkibanaを使って監視もしています。 具体的に言うとバッチ処理によって、定期的にデータベースの各種データサイズとCloudera ManagerのAPIからクエリログをElasticsearchに貯めこんでいます。 時系列でデータの増加傾向を把握したり、クエリ調査に使ったりしています。
- #19 Cloudera Hadoopのバージョンアップについてですが、これはほんとに苦労するポイントです。 どこの発表でもバージョンアップは大変と聞きますがほんとうに大変です。 インストール画面でどこかミスをするとインストールが先にすすまなくなり苦労するので Active-Stanbyの2クラスターを構築し、片方づつバージョンアップしています。
- #20 Active-Standbyの2クラスター構成は主にバージョンアップ作業をスムースにするためにこの構成にしています。 ローリングアップデートも対応しているんですが、あまり信用していません。 ですが、反面デメリットとして倍の費用がかかるのでコストはとてもかかります。 またバッチ処理などを移し替えるために移行コストが高いという難点もあります。 そういうデメリットはありますがバージョンアップ作業が安心して行えるメリットが大きいのでこのような構成にしています。
- #21 バージョンアップ後のデータ移行についてです。 hadoopのdistcpでデータを移行します。それと同時にログデータを両方のクラスターに更新することで、2つのクラスターを同期させます。
- #22 最後にCDHバージョンですが、これまで第一世代のCDH5.1から始まり5.7、現在5.15と来ています。 今年の春から6.1のバージョンアップを目指して目下構築準備をすすめているところです。
- #23 以上です ありがとうございました