Successfully reported this slideshow.
Your SlideShare is downloading. ×

データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 22 Ad

データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用

Download to read offline

Hadoop Spark Conference 2019
データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用

Hadoop Spark Conference 2019
データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用 (20)

Advertisement

Recently uploaded (20)

データサイズ2ペタ ソネット・メディア・ネットワークスでのImpala活用とHadoop運用

  1. 1. データサイズ2ペタ ソネット・メディア・ネットワークス でのImpala活用とHadoop運用 Hadoop / Spark Conference Japan 2019 So-net Media Networks 菅沼 嘉一
  2. 2. 菅沼 嘉一 Yoshikazu Suganuma So-net Media Networks 分析基盤T Cloudera Hadoopの障害対応したり、python/Goでツール作成したり Go言語好き!
  3. 3. 目次 ● Hadoopの用途 ● Hadoopの環境 ● ビッグデータ管理大変だよね!
  4. 4. Hadoopの用途
  5. 5. Logicadとは... So-net Media Networksが提供する 広告配信プラットフォーム
  6. 6. ● 広告配信ログを保管 ● データサイズ:約2PB ● 総レコード数:約1.1兆 ● 1日あたり約8TB増加 ● 主にデータ分析用途
  7. 7. Hadoopの環境
  8. 8. サーバースペック(データノード) スペック: Dell PowerEdge R720xd/R730xd/R740xd/R740xd2(予定) メモリ:約370GB/サーバー HDD:約90~160TB/サーバー (10TB x 18, 10TB x 12, 8TB x 12) PowerEdge R740xd
  9. 9. Hadoop構成 CDH 5.15 データノード:20 台 = 約2PB その他ノード:8台 (合計28台/1クラスター) (Zookeeper, Journal NodeにはIntel Optane SSDストレージ搭載) メタデータはAWS RDSに保管 Active-Standby の2クラスター構成
  10. 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 クラスター
  11. 11. Active Hadoop クラスター Standby Hadoop クラスター S3 ログの インポート処理 ログ収集 サーバー PQ生成
  12. 12. 主なImpalaの使い方 Hiveから1時間毎にParquet生成 Impala + Parquet はレスポンス最速 クエリ数:約13万クエリ/月 PQサイズ:約750TB
  13. 13. ビッグデータ管理 大変だよね.....!?
  14. 14. すぐに容量枯渇する...!? 8TB/day 増加するので容量を注視 保存期間をまめに調整 データ容量が90%近くになると Hive, Impalaのレスポンスが悪くなる傾向 早めにデータノードを追加
  15. 15. DBのパーティション数は約18万 データをパーティショニングすることで性能は上がるが パーティション数がボトルネックになることがある 過去にImpalaが動かなくなったこともある (CDH5.7で約20万あった時) 推奨値は3~4万だとか....無理ゲーじゃない?
  16. 16. 月に一回Hadoopの容量チェック 月に一回、詳細にデータサイズ、パーティション数....などの 全体チェックを行いレポートにまとめる
  17. 17. Elasticsearch+kibanaで監視 データ容量の推移をグラフ化 HDFSの各種データサイズをhdfsコマンドで取得し Elasticsearchに貯める Impalaクエリの傾向調査 Cloudera Manager APIからImpalaクエリを取得して Elasticsearchに貯める
  18. 18. バージョンアップは覚悟しておけ....!? (マジで) CDHのバージョンアップはどこかでミスがあると インストールできなくなる(「戻る」は押さない) そのためActive-Standbyの2クラスターを構築 (片方づつバージョンアップ)
  19. 19. Active-Standbyの2クラスター構成 同じHW構成を2つ構築して片方づつ運用 メリット: バージョンアップ作業、機能検証がはかどる デメリット: コストがかかる 移行コストが高い
  20. 20. Active-Standbyの2クラスター構成 バージョンアップ後のデータ移行について クラスター間コピー:hadoop distcpコマンド 同時データインポート distcp 同時インポート
  21. 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. 22. Thanks !

Editor's Notes

  • 本日の目次ですがスライドにありますように
    ・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のバージョンアップを目指して目下構築準備をすすめているところです。
  • 以上です ありがとうございました

×