Más contenido relacionado La actualidad más candente (20) Similar a データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用 (20) データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用9. Hadoop構成
CDH 5.15
データノード:20 台 = 約2PB
その他ノード:8台 (合計28台/1クラスター)
(Zookeeper, Journal NodeにはIntel Optane SSDストレージ搭載)
メタデータはAWS RDSに保管
Active-Standby の2クラスター構成
10. Data Node Data Node
Data Node Data Node
Data Node
Data Node
………………
…….
………………
…….
x 20
Name
Node
Zookeeper JournalNode
Hive
Metastore
Impala
Catalog ………………
…….
x 8
Hadoop クラスター
Notas del editor 本日の目次ですがスライドにありますように
・Hadoopの用途
・Hadoopの環境
・ビッグデータを管理をしていく上での大変だったところ
を紹介したいと思います。 ソネット・メディア・ネットワークスではDSP型の広告配信プラットフォームであるLogicadというサービスを提供しています。
膨大な配信ログをもとに最適な入札額を推定し、精度の高いターゲティングを提供しています。 Hadoopの用途としては、主にLogicadの広告配信ログを保管しています。
全体総量としてのデータサイズは約2ペタバイトを保管していて、レコード数としては約1.1兆レコードになります。
一日あたりに増加するログの量としては、約8TB近く増えていっています。
ログの使用用途ついてですが、主にデータ分析の用途に使っています。 次にHadoopの環境を紹介します Hadoopはオンプレ環境で運用しています。
データノードのサーバースペックですが、Dell製のPowerEdge R720xdからR740xdを使っています。
メモリは1台あたり約370ギガバイトのメモリを用意し、ディスク容量は1台あたり90テラバイトから160テラバイトを搭載しています。 Hadoop構成についてですが、HadoopのディストリビューションはCloudera Hadoopを使っておりバージョンは5.15です。
データノードは20台、データノード以外のノードは8台あり、合計で1クラスターあたり28台で構成しています。
一部ZookeeperとJournal NodeにはIntel Optane SSDメモリを搭載しています。
またバージョンアップを考慮して、同じサーバー構成を2つ用意してActive-Standby の2クラスター構成で運用しています。
それについては後程スライドで紹介したいと思います。 システム構成図ですが、説明は飛ばします。 主なImpalaの使い方についてです。
主にやっていることは、ログを1時間ごとにHiveで読みとってParquet形式に変換しています。
カラム指向のParquetファイルをImpalaで検索する組み合わせは、体感的にとても早いと感じていて基本的にImpalaを使っています。
クエリ数:約13万クエリ/月でPQサイズ:約750TBです 次にビッグデータを管理していく上での大変なところを紹介します。 一日当たり8TB増加するのですぐに容量が枯渇していきます。
そのために容量を常にチェックしており、まめに古いデータを削除して保存期間を調整しています。
またデータ容量が90%近くになるとHive, Impalaのレスポンスが悪くなる傾向わかっているので、データ増加を予測して早めのデータノードを追加していきます。 データ容量も問題になることもありますが、パーティション数が多すぎることで問題が起こることもありました。
一つ前の世代のクラスターでは5.7を使っていてパーティションが20万あった時があり、Impalaが動かなくなったことがありました。
今のバージョン5.15では多めの18万パーティションあっても動くようです。
Clouderaの推奨値では5万以下のパーティション数に抑えるようにと聞いたことがありますが、非常に難しいんじゃないかと思っています。
データサイズの傾向やパーティション数を把握するために、月に一回Hadoopの全体チェックをしています。
全体チェックをすることで、データベースのテーブル数や個々のデータサイズの増加傾向を把握したり、パーティション数を把握できます。
そうすることでパーティションの切り方を再検討してリスクを減らすことができるのでとても大事なレポートになっています。 他にもElasticsearchとkibanaを使って監視もしています。
具体的に言うとバッチ処理によって、定期的にデータベースの各種データサイズとCloudera ManagerのAPIからクエリログをElasticsearchに貯めこんでいます。
時系列でデータの増加傾向を把握したり、クエリ調査に使ったりしています。 Cloudera Hadoopのバージョンアップについてですが、これはほんとに苦労するポイントです。
どこの発表でもバージョンアップは大変と聞きますがほんとうに大変です。
インストール画面でどこかミスをするとインストールが先にすすまなくなり苦労するので
Active-Stanbyの2クラスターを構築し、片方づつバージョンアップしています。 Active-Standbyの2クラスター構成は主にバージョンアップ作業をスムースにするためにこの構成にしています。
ローリングアップデートも対応しているんですが、あまり信用していません。
ですが、反面デメリットとして倍の費用がかかるのでコストはとてもかかります。
またバッチ処理などを移し替えるために移行コストが高いという難点もあります。
そういうデメリットはありますがバージョンアップ作業が安心して行えるメリットが大きいのでこのような構成にしています。 バージョンアップ後のデータ移行についてです。
hadoopのdistcpでデータを移行します。それと同時にログデータを両方のクラスターに更新することで、2つのクラスターを同期させます。 最後にCDHバージョンですが、これまで第一世代のCDH5.1から始まり5.7、現在5.15と来ています。
今年の春から6.1のバージョンアップを目指して目下構築準備をすすめているところです。 以上です ありがとうございました