苍颈肠辞苍颈肠辞における継続的なデータ活用のための贬补诲辞辞辫运用事例
?Download as PPTX, PDF?
2 likes?1,584 views
Cloudera World Tokyo 2015の発表資料 https://clouderaworld.tokyo/session/
苍颈肠辞苍颈肠辞における継続的なデータ活用のための贬补诲辞辞辫运用事例
- 2. 自己紹介 > 志村誠 – 株式会社ドワンゴ プラットフォーム事業本部 共通基盤開発部 – 2011年に入社以来ずっと，Hadoop基盤の開発，運用， データ分析を担当
- 3. 会社绍介
- 4. 会社概要 > 2014/10にKADOKAWAとdwangoが経営統合 > 2015/10にカドカワに商号変更 > 苍颈肠辞苍颈肠辞事业は诲飞补苍驳辞伞下
- 6. agenda
- 7. agenda > データ活用の方针 > 第1フェーズ – 课题 – システム – データ活用 > 第2フェーズ > 第3フェーズ > まとめ
- 8. データ活用の方针
- 9. 必要な人が誰でも分析できるように > エンジニアに限らず，データを集計する必要 がある社員は誰でも自分自身が触れるよう にする > 分析部署だけで，社内の全部署のニーズを すべて満たすことは不可能 > 業務で必要な人が，学習して自ら集計でき るように育てていく
- 10. サービスを横断した分析の必要性 > niconicoは，動画と生放送を中心として，数 多くのファミリーサービスが存在している > なにもしなければ，各部署で縦割りの分析 をするしかない > そこでメインのHadoopクラスタにデータを集 約して，横串での分析をできる体制が必要
- 12. ポイント > Webフロント経由でのアクセス > システム間連携はAPIを提供 > CI環境の整備 > 仮想化によるアプリケーションサーバの冗 長性確保 > 統一されたフォーマットでログの自動取得 > 内製システムによるバッチ実行制御 > Hive経由での可視化基盤との連携
- 14. フェーズ 1 (2011-2013) フェーズ 2 (2013-2015) フェーズ 3 (2015-) 今後 システム構 成 ? 導入期 ? 負債を生成 ? 発展期 ? 取扱ログ 100種類以 上 ? 部分的な負 債解消 ? 大規模な構 成変更 ? 負債の解消 ? 運用の自動 化 ? スケールの 担保 ? 新規のミド ルウェアを 検証 & 投 入 ? ストリーム データへの 対応 データ活用 ? 導入期 ? パワーユー ザの育成 ? 普及期 ? 利用ユーザ 200人以上 ? 可視化基盤 の導入 ? 組織全体で 同じ数字を みる体制作 り ? 様々な用途 に応じた データ活用 フェーズ毎のサマリ
- 15. 第1フェーズ 2011-2013
- 16. 课题
- 17. 統一データ基盤の必要性 > ファミリーサービスが多数あり，それらを同 一のプラットフォーム上に載せて分析できる ようにしたい > 大半のデータについて，各サービス内で閉 じていた > サービス横断的にユーザの動向を把握でき る必要がある
- 18. システム构成
- 20. クラスタ > CDH3u0 – NN1台 + コールドスタンバイ – 単一障害点だらけ > ディスクの枯渇 – 想定より遥かに蓄積速度が早い – レプリケーション2での運用 > 運用 – 人の手による暖かみある運用
- 21. Pig > サービスごとにビジネスロジックが入り込ん でおり，アドホックな前処理が多数発生 > 仕様変更が数多く発生するため，Hiveテー ブルを定義するのが，（当時は）難しかった > 上記を整備するための知見と工数の蓄積が なかった
- 22. 内製Webフロント > はじめから，各サービスの企画担当者が直 接触れることを想定していた > 当時のHueは非常に機能が少なく，機能要 件を満たさなかった > 業務要件に合わせて作り込んだため，Hue への乗り換えに際して大きな障害となる
- 27. データ活用
- 28. パワーユーザーの育成 > 各サービスの分析担当エンジニアと，分析 部署が主に使用 > 各種環境の整備 – Pigの導入資料を用意 – 開発環境をVMで提供 – 各サービス向けに勉強会を開催
- 29. 第2フェーズ 2013-2015
- 30. 课题
- 31. クラスタ乗換の必要性 > ディスクの枯渇 – 2年間で扱うログが100種類以上に増加 – サーバスペック自体を見直す方向に > インフラ構成の見直しに伴うDC移設 – DC間のデータ転送が必要なため，帯域を絞りたい – Hadoop1.0系のdistcpだと，利用帯域を設定できない – 自作バッチを開発して，帯域を絞りながらデータ転送 を行うことに
- 32. 初期構成の負債 > 内製アプリケーションの運用負荷 – Hueの充実 – 継続的にメンテナンスコストがかかる > クラスタ管理 – ClouderaManagerに載せるためには，既存アプリの大 幅な作り替えが必要 – 時間と開発コストの面で見送りに…
- 33. システム构成
- 35. システム构成 > CDH3u6 → CDH4.3 – NN2台のマスタースレーブ構成 – 単一障害点もある程度解消 > ノード構築作業の自動化 – Chefレシピを作成 > 内製アプリケーションのリファクタリング – コンポーネントの集約 – Jenkinsを用いたCI環境の構築
- 36. データ活用
- 37. 部署の統合 > Hadoop開発の部署と，分析の部署が一つ にまとまる – 開発と連動した分析体制の整備 – 結果の可視化までをシステム化 > 内製の可視化基盤 – Python製のバッチ機構 – Pig + MySQL + Shiny の構成 – 基本的なKPIは全社員がインタラクティブに確認可能
- 40. 分析環境の整備 > Pig開発効率の向上 – ドメイン知識を詰めたUDFをまとめたjarファイル – 名前と型をつけて各ログをロードするpigマクロ群 – 標準コード規約 – 4桁行規模のPigスクリプトも多数 > 知見の蓄積と共有 – 各サービスで行った分析結果をconfluenceで共有 – 分析担当者が集まって情報共有をおこなうミーティン グを定期的に開催
- 41. ユーザーの規模 > アカウントを持っているユーザが200人以上 > 主な分析用途 – 新しい施策を打つ際の，現状の確認 – 打った施策の成果確認 – サービスごとの，さまざまな定常バッチ – システムのパフォーマンス測定 > 業務プロセスの変更が痛みを伴う規模に…
- 42. 第3フェーズ 2015-
- 43. 课题
- 44. 大規模な構成変更の必要性 > 運用コスト増大を解消 – 内製アプリケーションからの脱却 – クラスタの一元管理と監視?運用の省力化 – 新しいミドルウェアの導入コスト低減 > システム构成の見直し – ラックやサーバ配置，ネットワーク等の最適化 – YARN化に伴う各種構成の変更 > 上記を踏まえてClouderaサポート導入
- 45. 構成変更手順 1. 別クラスタをClouderaManagerで構築 2. distcpで現行クラスタのデータを新クラス タにコピー 3. 既存クラスタと新クラスタの両方に日々の ログデータを流し込む 4. YARNと既存アプリケーションの検証
- 46. データコピー時の問題 > CDH4から，HDFSファイルのcheck sumが変更さ れた – CDH3まではCRC32で，CDH4以降はCRC32C > 両方のcheck sumを含んだディレクトリをdistcp するとエラーで落ちる – distcpの際にcheck sumを指定する必要があるため > 結局エラーが出た箇所に関して，データを整形 した時期を確認して個別にdistcp
- 47. システム构成
- 49. システム构成 > CDH5.4.1 – NN2台のHA構成 – ClouderaManagerで構成管理 > 内製アプリケーションの整理 – 各アプリケーションを疎にしてOSS等に置き換え – HueやTableau > 冗長性の担保 – 各アプリケーションはlxcでコンテナ化 – fluentdクラスタによるログの取り込み – まだいくつか，冗長化しきれていないコンポーネントもある
- 50. バッチジョブの省力化 > バッチジョブは – ややこしい処理が多い – 処理自体の追加や変更も多い – ジョブ間の依存関係も多く存在する > 内製バッチフレームワークの開発 – コンポーネントの組み合わせでフローを表現 – その組み合わせをjsonで記述するだけ
- 51. ストリーミング基盤の構築 > fluentdクラスタの構築 – 大半のログは，統一フォーマットでfluentdに送って集 約する形に – 従来のログは順次fluentdに移行していく > リアルタイム集計基盤の構築 – lxcコンテナ上に，fluentd/Norikra/InfluxDB/Grafanaを 1セットとして構築 – 各サービスごとに，必要に応じてコンテナを立てて，集 計が行えるように
- 52. データ活用
- 53. 分析→可視化プロセスの強化 > 可視化までの手間を削減 – MapReduce/Pig – Hive経由でTableauによる可視化 > 全体のレベル向上への取り組み – パワーユーザーの育成 – Excelで行われていたことをTableauへ自動化 – 分析内容や使い方の共有会
- 54. 準エンジニア手当 > 会社全体として，ソフトウェアエンジニアリン グの知識を向上させるための取り組み > 非エンジニア向け > 準エンジニア試験を受けて合格すると，手 当がもらえる > 前回実施分では試験範囲にPigも
- 55. まとめ
- 56. 今后の方向性
- 57. 過度のPig依存からの脱却 > Pig特有のつらみ – バージョンが0.1変わっただけで仕様が大きく変わるた め，過去に開発したPigスクリプトが最新版で動作しな いことがザラ – テストフレームワークが充実しておらず，一定規模以 上の定常バッチには向いていない > Spark/Impalaへの移行 – バッチ処理はSparkで記述 – 短めのクエリはImpalaで実行
- 58. Pig 0.11 → 0.12で生じた主な変更 > メタ変数の展開形式が変更 – %DECLARE `${hoge}` がPigのメタ変数と認識されるように – %DECLARE `${hoge}` とエスケープ処理が必要に > グローバル変数の導入 – %DECLARE 変数がマクロ内部でも認識されるように – マクロ内変数を一律で M_XXXX と変更 > replicated joinの動作不具合 – MRにおけるmap side joinで，処理が高速なため多用していた – すべてskewed joinに変更し，使用をやめた > EXEC, RUNコマンドの変数引き渡し – 呼びもとのpigスクリプトで定義された%DECLARE変数が，呼び先のpigスクリ プトの同名変数を上書して実行 – EXEC, RUNの使用をやめた
- 59. ストリーミングの強化 > 流量が多すぎると，1台のNorikraでは対応 できない – NorikraエンジンのEsperは，dual 2GHzの85%使用時で， 70Mbit/s程度のストリームデータ処理が限度 – Norikraを多段に重ねれば，データ量の増加にもある 程度対応できるが，それだと今度は運用が辛い > ストリーミング処理も分散処理できるように しないといけない – Kafka + Spark Streamingの構成による検証を進める
- 60. スケジューラの強化 > 複数のバッチ間の依存関係を制御できるよ うに – 中間データA, Bがおわってから，集計処理X, Y, Zを走 らせたい，といったケース > 各ユーザが勝手に，Pig/Hive/Tableau連携 を定義してスケジュール実行できるように – セルフサービスBIをサポートしていく仕組みづくり
- 62. 長期運用から 得た知見
- 63. 初期設計は非常に大事 > 各コンポーネントを疎にしておく – コンポーネント単位で後から差し替えられるように – 中途半端に密な内製アプリケーションを作ると，後か らのOSS差し替えが非常につらい > データフォーマットの統一 – いったん社内で広く使われ始めたログのフォーマット を後から変更するのは，とてもコストが高い – ちゃんと初期の時点で設計しておく – 業務プロセスに合わせて中間データをつくり，そこで フォーマット変更の差異を吸収
- 64. 運用コストを下げる > システム内で単一障害点をなくす – 各アプリケーションサーバやDBサーバなど，Hadoopク ラスタ以外の全てにおいて同様 > 自動化，並列化， – 監視，デプロイ > 内製コンポーネントはできるだけ作らない – まずは既存のミドルウェアを探す – 作るなら，OSSの部分と疎になるように切り分ける
- 65. 分析体制の作り方 > パワーユーザを育てる – 何もしないで勝手に社内の人たちが分析してくれるほど， 世の中は甘くない – まずはスモールに，分析で問題解決ができる部署と協力 関係を築いて，そこで成果を出す – 全社展開していくのは，ある程度スモールな成果が出て から > サービスレベルは慎重に決める – 低すぎると，そもそも使ってもらえない – 高すぎると，長期的な運用に差し支えがでる – 最初は若干低めに現実的なSLAを定め，後から徐々に上 げていく
- 66. 以上