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

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 とおｎ組み合わせで 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 同様これだけは聞いておきたいと思っていたセッション。
- 参加することにして間違いはなかった。