#garagekidztweetz

読者です 読者をやめる 読者になる 読者になる

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

Cloudera World Tokyo 2014 の LT セッションで聞いてきたメモ #cwt2014

cloudera cdh conference lifelog cwt2014 hadoop

f:id:garage-kid:20141106221042p:plain

Cloudera World Tokyo 2014 | Cloudera Japanに参加してきたレポート、最後のエントリは LT セッションで聞いてきたメモです。

本編以上に濃ゆい内容がそろっていたので Hadoopユーザー会 でリストアップされていた LT すべて聞きたいでしたが、それだとちょっと本末転倒な感じだったので、以下の 4 セッションだけ話をきいてきました。

  • LT :
    • 12:55 - 13:10 インメモリ/分散並列処理対応のビジネスインテリジェンス(BI)ソリューションでHadoopデータを活用する 畝見 真氏(SAS Institute Japan)
    • 13:10 - 13:25 Hadoop 2.6の最新機能 鯵坂 明氏(NTTデータ)
    • 13:30 - 13:45 Fluentd: Unified Logging Layer Masahiro Nakagawa 氏(Treasure Data)
    • 13:45 - 14:00 Ansibleで構成管理を始める人のモチベーションを高めたい! 土橋 昌氏(NTTデータ)

以降からがメモです。

LT :

12:55 - 13:10 インメモリ/分散並列処理対応のビジネスインテリジェンス(BI)ソリューションでHadoopデータを活用する 畝見 真氏(SAS Institute Japan)

  • SAS Visual Analytics の紹介
    • Hub
      • Data Query 作成
      • 管理
        • データロード、アンロード
        • エクスプローラー
          • アドホックな探索
        • Designer
          • Dashboard
            • mobile でみれる
        • Mobile BI
    • In-memory Analytics (SAS LASR Analytics Server)
      • In-memory 並列分散処理できるから高速
      • HDFS から memory load が並列分散実行可能
    • Demo
      • Prediction
      • What-if 分析
      • 異なるデータ項目間の相関関係を導き出すこともできる

13:10 - 13:25 Hadoop 2.6の最新機能 鯵坂 明氏(NTTデータ)

  • @ajis_ka
    • Hadoop
      • Document
      • bug fix
      • 運用件数
      • パッチのマージ件数 100 件以上
  • Hadoop 2.6
    • 2.2.0 以来、一番大きなリリース
      • 848 件の issue が解決された
    • JDK6 での動作をサポートするのはこれで最後
      • 2.7 以降はしない
    • 2014 Nov にリリースされると思われる
  • 最新機能一覧
    • roadmap からみれるので wiki.apache.org/hadoop/Roadmap
    • ピックアップする
  • HDFS から 2 つ
    • Transparent Encryption
      • 背景
        • HDFS には暗号化の機能がなかった
        • もともと hadoop に対するセキュリティはクラスタへのアクセスを隔離することで担保されていた
        • 金融、公共、ヘルスケアではそれでは要求をみたされなくなってきた
        • Intel 開発
      • ファイルを暗号化して HDFS を構成するディスクに書き込む
        • AES-CTR 方式を採用
        • 暗号化、復号化は Key Management Server (HADOOP-10433) で管理
          • OSS Conf でその話はしてきた
    • Achival Storage
      • 背景
        • HDFS にいれるデータにしてもよく処理されるものとそうでないものがある
        • 頻繁に処理されるデータは SSD に処理されないおのは低スペックなアーカイブ領域に配置したい
        • よりレプリカ配置を細かく管理する仕組みを実装
          • HDFS を構成する各ディスクに対して Storage Type 指定
          • 管理者が各ディレクトリに Storage Policy を指定
            • hdfs dfsadimin -setStoragePolicy ...
          • Storage Type
            • RAM_DISK が追加
              • 各 DN で tempfs を設定して RAM_DISK に指定
            • ARCHIVE
  • YARN から 2 つ
    • Resource Manager(RM) Restart Phase 2
      • RM は YARN における SPOF
      • Hadoop 2.4 で HA 化された機能には制限
        • RM が FO すると Application Master がすべて再起動
        • 動作中の container はすべて kill
      • そうならなくなった
    • NodeManager Restart
      • NM は YARN の SPOF ではない
      • メンテナンスやアップグレードを考えた時に別の NM で処理を再実行させるのではなく再起動後に処理を途中から実行したい
      • 処理状況をローカルに保存するように
        • RM Restart Phase 2 とおn組み合わせで Rolloing Upgrade が可能になる予定
  • 今後の開発予定
    • 今後も次々と機能が追加されていく予定
      • YARN-666
      • YARN-796
      • YARN-1492
      • HDFS-7285
      • etc, etc...
  • 今回、わたしが聞いた LT の中では一番タメになったセッション。
  • たいへん勉強になりました。

13:30 - 13:45 Fluentd: Unified Logging Layer Masahiro Nakagawa 氏(Treasure Data)

  • データの収集している Fluentd のユースケース的なもの、最近のエコシステム
  • @repeadedly
  • Data 解析
    • いくつかの段階
    • Collect, Store, Process, Visualize
      • Collect に関しては defact がない状態だった
      • general で robust, pluggable なものがほしかった
      • で TREASUREDATA は fluentd をつくった
  • で Fluentd
    • written in Ruby
    • Customization is essential
      • ユーザが好きにカスタマイズできるように
    • like syslogd, but uses JSON for log messages
  • Divide and Conquer and Retry
    • 細かい単位で、失敗したらリトライする
  • Core
    • Divide and Conquer etc
  • Plugins
    • read/receive data
    • write/send data
  • Pluggable Architecture
    • Input と Output 部分は Pluggable
    • Input -> Engine -> Output
  • Fluentd を間にはさむことでデータ転送を Simple に
    • TREASUREDATA(TD) につなぐときには TREASUREDATA の純正プラグインがある
  • で Ecosystem
    • Treasure Agent
      • including Ruby, core lib and 3rd party plugins
      • stable ver 2.1.1
    • fluentd-forwarder
      • Win との相性が fluentd はあまりよくなかった
      • Go で書いた
      • 2014-11-05 リリースした
      • similar to ik, fluent-agent-hydra
    • fluentd-ui
      • Fluentd managed via WebUI
      • 次の Agent に同梱
  • Users
    • Web services, Ad tech, Game, Media, etc
    • Products
      • Kubernetes, Cloudn, Harvester, Bloombrg Clusterd Private Cloud, etc...
  • Simple forwarding
    • 一番シンプルな実装
    • リアルタイムに近い形でデータを集める (コピーして投げる)
  • Separate Log system
    • e.g. one to TD, one to elasticsearch
  • CEP for stream processing
    • Norikra
    • mackerel
    • TD
    • そんなに Spark をいれてまで CEP をする必要性は感じない
      • Google の人も Fluentd と Norikra を薦めてる
  • Roadmap
    • v0.10 (current)
    • 0.12 (Nov, 2014)
    • 0.14 (TBD)
    • v1
      • あくまで安定版ですよ、という version 1.0

13:45 - 14:00 Ansibleで構成管理を始める人のモチベーションを高めたい! 土橋 昌氏(NTTデータ)

  • プライベートでも業務でもたくさんのサーバ環境をつくってつくって(なおして)きた
  • 構成管理のモチベーションのおきどころってどこだろう?
    • 猥雑
    • 手に余る
    • オレオレスクリプト
    • いろんなツールがあっていろんな使い方ができるけどどしたらいいの?
  • そういうときは「なんのために?」を抑えておくと大きく踏み外さない
  • 構成管理ツールに何使うといいんだっけ?
    • 個人的にはなんでもいいとおもっている
      • Chef, Puppet, Ansible
    • メンバのスキルセット、プロジェクトの状況を鑑みる
    • Ansible でできること使い勝手のバランスが程よい
  • 結論
    • なんのために?
      • トレーサビリティの確保(なにがおきてる?
      • 共通の言葉づくり
      • ノウハウの蓄積と発展
        • そのつどつどになるのをできるだけ防ぐ
  • トレーサビリティ
    • 誰が何をどうしたらどうなった、の把握
    • 方法
      • git, SVN でのプレイブックの管理
    • 問題解決の例
      • 問題発生>現状把握>経緯の理解>仮説対策立案>テスト環境で確認>対策実施
  • 共通の言葉づくり
    • メンバの迅速な情報共有
    • 曖昧さの回避
    • 方法の例
      • 構成管理や運用作業をプレイブック化
      • Ansible 自体が上から順に実行される、ドキュメントに近い読みやすさ
      • pull request で議論、とか
      • プレイブック自体が手順書、となることもできる、かもしれない
  • ノウハウの蓄積と発展
    • 行き当たりばったりの回避
    • 煩雑なノウハウを継続的に改善し続ける
    • 方法の例
      • ロールを使って汎用化
      • プレイブックの共有化
  • 雑感
    • Hadoop 2.6 同様これだけは聞いておきたいと思っていたセッション。
    • 参加することにして間違いはなかった。

はい、 LT セッションのメモは以上。
そして Cloudera World Tokyo 2014 でわたしがとってきたメモの共有は以上です。

それにしても特にこの LT セッション、 Cloudera 関係ないんじゃ、むしろ競合なんじゃなんていうセッションもあったりしてましたが、それを許しちゃうのは Cloudera の懐の深さっていう話なんですかね、いや、すごい会社です。

では今回はこんなところで。

あわせて読まれたい