スポンサーサイト

一定期間更新がないため広告を表示しています

スポンサードリンク | - | | - | - | - | - |

Hadoop Conference Japan 2011 Fallに参加してきました。

Hadoop Conference Japan 2011 Fallに行ってきました。
まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとうございます。
Hadoopは昨年触っていたのですが、最近は縁がなくなってしまいました。
ただ、触っていたときに面白かったので参加してきました。
ということで、今回も自分用にメモを取ったので。(今回は英語のヒアリングがあって、メモがひどい事になってます。。。)
いつものことながら、おかしいところとかあれば、ツッコミなどフィードバックをもらえると嬉しいです。


場所:ベルサール汐留
日時:2011/09/26 10:00〜18:00+懇親会:18:30〜21:00

オープニングトーク:濱野、太田
 参加者:1100名超!(実際は800名弱?)
 Hadoopの経験:利用経験なしな方が580名
 カンファレンスの認知:Twitterよりも知人、その他が多かった。
 会場提供:リクルート様
 リクルート米谷様より一言。
  Question VOTE!!サイトを用意。
  http://mit.recruit.co.jpにて情報提供。
 ※残念ながら地下だったため、E-mobileにつながらず、あと、電源確保が難しかったのでMBAをスタンドアロンにしてメモをとっていたので、
  QAサイトにはアクセスしませんでした。もう少し活用したかったんですが、携帯でTwitterを追っかけるので精一杯。。。

◎The role of the Distribution in the Apache Hadoop Ecosystem:Todd Lipcon(Cloudera)
 1.Introduction
  Todd Lipcon:Clouderaエンジニア
  Hadoop とHBaseのコミッター
 2. Hadoop Overview
  HDFS+MapReduceの説明
  Hadoopの生まれてきた経緯 
   様々な形式のデータが大量に存在し、データのハンドリングが難しくなってきたため。
   Flexible, Scalable Solutionが必要に。
  Hadoop の2つのユースケース
   1.Advanced Analytics
    SNS(Web)、Content Optimization(Media)、Network Analytics(Telco)、
   2.Data Processing
    Clickstream SessionizationEngagement

 3.Cloudera Overview
  ClouderaCustomers
   ・Large National Bank
   ・Web-Based Media
    click-through dataや広告のログ
   ・Wireless Telecom
    大量のデータ
  目標:大量データからビジネスを引き出すこと。
  Cloudera Japan:トレーニング。NTTDと協業して開発支援も
 4.CDH Overview
  100% pure Apache Hadoop
  SCM Epress(Service & Configuration Manager)
   Free 
  なぜ、CDHを利用するの?
   Linuxを利用する場合にLinux.orgからはダウンロードしないように、Hadoopも同じように提供したい。
    RedHat系を目指しているみたい。
   様々なパッケージの依存関係が混乱を招く。
    CDHならテストが終わってるものが提供されてる。
  ※SolrはLWEがLucidWorksEnterpriseがこれを目指してるのか。
 5.Cloudera Enterprise
  Activity Monitor:Jobのパフォーマンスをリアルタイムに監視
  SCM:設定のvalidateや管理。
  Resource Manager:。。。
 6.まとめ
  CDH:簡単にHadopが使えるよ。
  SCM Express:簡単にHadoopの設定ができてフリーだよ
  Cloudera:Hadoopに関していろいろサポートしているよ。(Enterprise用ソフトやトレーニングなど)


◎About Hortonworks:Owen O'Malley(Hortonworks)
 1.About Hortonworks
  2011/2月に設立
  22人のYahooからのアーキテクトとコミッタにより設立
 2.Credentials
  Yahooのクラスタの経験者がいますよ。
  OSSに長けた人達によるチームです。
 3.What is Apache Hadoop
  Hadoopの説明(別の側面が幾つかあり。)
  Commodity Hardwareで動く
  簡単にプログラムできる
  典型的なアプリケーションのタグクラウド(あとでちゃんと見る)
  HadoopのほとんどのソースコードはYahooで作られてるよ。
  Clouderaとか目じゃないよ
 4.Hadoop @ Yahoo!
  各種サーバや規模など
  Science Hadoop Cluster <-> Production Hadoop Cluster <-> Serving Systems
   という構成で、いろいろやってます。
 5.Hadoop Market
  ビジネス:ビッグデータを扱って色々やろうね
  金融系:IT系のコストをOSSとHadoopで削減
  技術系:
 6.Hortonworks Strategy
  Hadoopを利用、管理しやすくするためのいろんなことをコミュニティに還元しますよ。
  性能などについても同様。
  トレーニングやテクニカルサポートやりますよ。
 QA:
  Q:42Kのノードの管理ツールはなに?
  A:手で管理してます。
  Q:社名の由来は?
  A:童話でHortonという名前の象の話がある。
  Q:CDHはおすすめ?それともほかのものがいい?
  A:※聞き取れず。。。
  Q:500万Query/月はアドホックQueryもあるの?
  A:幾つかのクラスタに分けて使ってる。アドホックは不明


◎How Hadoop needs to evolve and integrate into the enterprise:Ted Dunning(MapR)
 ・Quick History
 ・英語わからない身には辛い。。。
 Zookeeperの人らしい。
 Narrow Foundations
  HDFSとNASの間には大きな壁があり、大きなデータを移動するのはコストが掛かる。
 Broad Foundation
  HDFSの代わりにNAS、RDBMSの下に位置するMapRを用意
  ど、どんな仕組み?->テクニカルセッションで。
 QA:
  Q:MapRはOSSにしないのか?
  A:MapRで開発したものはApacheに還元はしますが、OSSにはしないよ。フリー版は提供するかも


ここで昼食。午前中からいた人にはランチボックスが提供されました。
午後からはコミュニティトラックとテクニカルトラックの2トラックがありましたが、LTが聞きたかった(それよりも英語が辛かった?)のでコミュニティトラックのど真ん中、最前列に入り浸りました。
★コミュニティトラック
◎Elastic MapReduce Amazonが提供するHadoop:大谷晋平(Amazon)
 ・Amazonとは
  Eコマース
  流通
  AWS
  の3つのサービス
 ・AWS
  Low-level、High-level、Cross Service、Tools to access services、アプリケーション
  色々あるなー
 ・Bigデータが大変な理由
  ケタ違いのデータ量、異なる形式データ、即時性
  現状システムはスケールしない
  ビジネスとして成立する?
   成立するならすぐスケールだめならすぐ縮小
 ・Hadoopとは?
  これまでのお話。
  スケーラブル、低価格なハード
  誰でも入手可能で、実績多数。
 ・Amazon EMR
  AWS上でスケーラブルなインフラ上に構築が可能
  オンプレミスからMapReduceアプリを移行可能なため、分析、解析に集中可能
  S3からデータIN/OUTするので、データ欠損がない。
  Hadoopそのままではチューニングやクラスタサイズ見積もりも難しい
   =>クラスタサイズを動的に拡張伸縮可能。パフォーマンス最適化もできるよ。
  0.18、0.20が利用可能。
  EMRはHDFSとジョブ(タスク)トラッカーを別構成にしている。
  EC2上にMaster、Core、タスクノードを展開
  S3にデータを格納
  SimpleDB(KVS)を利用
 ・EMR注目機能
  ジョブフローの高速化
   ジョブの再起動無しにコスト/パフォーマンス比を変更可能。
   タスクノードを動的に増やせる
  柔軟なデータウェアハウスクラスタ
   タスクノードをバッチ実行時にのみ増やせる。
  ※増減できるのはタスクノード
   Coreノードは増加のみ
  EMR+Spotインスタンスの活用
   コスト削減効果が非常に高い
   AWSの余剰リソースをリーズナブルに提供(Amazon的にもウハハだ)
 ・その他の機能
  東海岸だけだけど、スパコンレベルのインスタンスも利用可能
  AWS上での最適化設計など
  ※ちょっと時間足りなくなってきたw
 ・EMRの事例
  1.Razorfish
   ROAS(広告費用対効果)を500%改善(すげー)
  2.So-net
 ・EMR都市伝説
  物理vs仮想
   そりゃ、物理が速いよ
  EMRの柔軟性・拡張性がセールスポイント
   ビッグデータは成功/失敗が読めないのもあるので、
   インフラに投資する部分を少なくできるよ。
  オンプレミスが安い?
   いやいや、HWの購入から設定など時間かかる。
 ・Beyond Hadoop
  HadoopのIn/Out含めてスケーラブル、フレキシビリティが重要
  運用管理の仕組みも重要
  まだまだやってくよ。
 QA
  Q:EMRは複数サービスから構築してるけど、一部がダウンするとどーなる?(例:SimpleDBが落ちてるとか)
  A:ジョブはReRunしてもらうか、SimpleDBの状態をみてリカバリをしてもらう。
  Q:上記にともない、SLAの計算は?
  A:SLAはEMRについては定義できてない。S3などはリージョン跨いで
  Q:S3のセキュリティが心配だが、どう考えてるか?
  A:いままで脆弱性を晒してデータをロストしてない。
    ユーザコントロールなどもできる。基本的には問題ない
  Q:EMRでS3を使う=Hadoopのローカリティの利点が失われるのでは?
  A:オーバヘッドはあるが、実際のデータはS3で守られているので、HDFSが飛んでも大丈夫。
  Q:S3からのコピーオーバヘッドはどーなるか?
  A:Single5で少しずつor分割して全部送るも可能
  Q:EMRはマルチテナントだけど他のユーザのネットワークの影響を受けないの?
  A:マルチテナントだと起こる可能性がある。
    M1(?)だと内部ネットワークは専有可能らしい。


◎LT
 ・Hadoop and Subsystems in livedoor @tagomoris
  ピーク時に15Gbps。
  10ノード(36コア)
  CDH3b2を利用
  データマイニングではなく、ログからレポーティングをするのに利用している。
  hadoop streaming + Hiveで実施
  580G/dayが96サーバから来る
  ScribeにてHadoop Streaming(Perl)でper hourでHiveにload
  scribelineをWebサーバに入れててログ配送してくれる。


 ・Lightweight @stanaka(はてなCTO:田中慎司さん)
  EMR以前
   自前20台クラスタ
   ジョブがあふれてきた
   ナマMapReduceを利用
   PerlでMapper/Reducerを記述(Hadoop Streaming)
  EMR導入
   リソース増やせて便利!
   必要な台数に伸縮可能
   問題点:
    S3にアップしないとダメ
     =>ログデータをS3に展開するlog2s3.plを作成。毎時実行。
    起動、ジョブキック、結果改修どーする?
     =>Net::Amazon::EMR::Wrapperを作成した。
      クラスタ起動、ジョブキック、クラスタ停止などできる
     作ってみて思ったこと
      よかったところ:
       Perlでかける。Cronで実行可能。HiveQL便利。
      悪かったところ。
       途中で失敗してクラスタ起動しっぱなしとかがある。S3にデータを展開が大変。複雑な計算がきつい。
    慣れてないエンジニアにも触れるようにしたい
     =>Perlで書けるようにした?。


 ・HBaseでグラフ構造を扱う(開発中):アメーバ鈴木
  自己紹介@brfrnl69
  アメーバのソーシャルグラフ
   基本はMySQL
   マスタ分散が難しい、シャーディング管理が面倒
    =>HBaseでやってみるか。
  目的 
   グラフデータに対して高速に更新追加したい。
   隣接ノードが取れればいい(これを高速化したい)
   オンライン処理したい
   運用コストの削減したい。
  Not目的
   マルチホップはどうでもいい。
  アーキテクチャ
   JavaでGatewayつくってみる。
 ・Large-Scale Graph Processing:井上さん(@doryokujin)さん
  Map/Reduceではグラフ計算だめ?
   Vertex基本だとShuffleに問題ががが。
  BSPの紹介
   Bulk Synchronous Processing
  Google Pregel 
  SSSP:MapReduce Model
   すごい計算時間が掛かりそう。MRの組み合わせが何回回ることやら。
   枝が少ないとこっちのほうがいいのか?
  SSSP:PregelModel
   シンプルなアルゴリズム
  Pregel使えるのあるの?
   Hama
   GoldenOrb
   Giraph
    YERN?YARN?


◎リクルート式Hadoopの使い方:石川(リクルート)
 @ground_beetle
 ・導入の課題点
  バッチ処理時間対策のため。
   =>実は入れたかっただけw
 ・導入の障壁
  現行システムへの影響+開発工数
   =>これへの対処がこのあとの話
 ・課題の克服と活用シーン
  Azkaban知らなかった。ジョブスケジューリングツール
  Hadoop単体ではなく、エコシステム(関連ツール)が魅力
 ・活用シーン:Hive
  SQLゆーがざ多く、HiveQLがSQLライクのため導入が簡単に!
  既存機能のリプレイス系案件に活躍(低工数+簡単に高速化)
  とりあえず、Hive実装
   =>性能アップのためにMapReduceで書きなおし
  Hotpepperなどのアトリビューション分析に利用
 ・活用シーン:Sqoop+Hive
  RDBとHadoop連携のツール:Sqoop
  現行システムの横にHadoopを配置でき、RDBMSの利点も利用しつつHiveも利用できるようになる。
   (※気を付けないといけないけどねぇ。)
  ゼクシィで活用しようとしてるところ。
 ・活用シーン:Mahout
  マイニング用ツール
  カーセンサーのレコメンド(同時に閲覧される車種)
  アソシエーション分析+クラスタリング
 ・活用シーン:BIツールの導入
  何度か導入しようとして失敗してます。。。
  BIツールの前処理(クレンジングなど)にHadoopを活用
 ・インフラリソースは?
  全部で118台。
  最小のクラスタ構成はサーバ6台で構成してる
 ・Hadoopで複数処理を回す方法
  ここまで紹介したものを入れてますよ。Hive、Sqoop、Solr。。。
 ・Azkaban
  TomcatにWar配置で利用可能。
  LinedInのチームにより作成
 ※若干マシントラブルで中断
 ・今後のHadoop導入
  ログ基盤
  分析エンジン・レコメンドエンジンとして
  バッチ処理短縮=トライアンドエラーが簡単にできるようになる。=色々な気づきが出てくる。
  アジャイル的な解析が可能に。
 ・開発サイクルの短縮ができるエコシステムでビジネスが回りだす。
 ・今後の展開
  MapRが気になってる。
   マルチテナント対応ができてうはうはできそう。
   EMCと共同して検証中

 QA:
  Q:性能監視ツールの選別の理由は?
  A:Zabbix、Cactiです。今から利用しようと思っている段階。
  Q:CDH、GreenPlum、Apacheをそれぞれ利用してるけど、使い分けのシーンは?比較は?
  A:CDH3u0です。GreenPlumは使ってないです。理由は言うとクビが飛ぶ可能性ががが。
  Q:高度なデータ分析ができる技術者はどこからヘッドハントしてるの?
  A:MITに別途分析チームが存在し、高度な分析をしてくれる。
  Q:NameNodeの冗長化はどーやってんの?
  A:象本と一緒DRBD+HeartBeat
  Q:EMRの導入を検討してる?
  A:今後、サーバ数が多くなると導入の検討をしていくと思う。
    現時点は、運用ノウハウも入手するために社内で使ってる。
    EMRになるかRCloud(リクルート社内クラウド)になるかは不明。
  Q:HBaseを利用してる?
  A:してないです。スペック的にサーバが買ってもらえないと厳しいです。


◎The history and the future of Hadoop use case at Rakuten:Tarje Marthinussen(楽天)
 ・Introduction(self、rakuten)
  NextGeneration Search Group
  Norwayから来ましたよ。
 ・RakutenのBigDataとは
 ・Hadoop at rakuten 
  Recommendation(2009)
  ProductRanking、GenreRanking、Log解析、(2010)
  Enhance Search。。。(2011)
 ・PigやHiveのようなものが簡単に利用できるようになってきた
 ・新しい検索プラットフォームを構築中
  index 10k docs/sec
  search 400qps
 ・What's Next Generation Search
  20%はインデックスとQuery評価の
  50%がデータの前処理(データとQuery)
  30%がアナライズ
 ・Collecting Data?
  ログの取得はバッチ処理だった。これをStreamingに(Flume)
 ・Flume
  Zookeeperを利用してFlumeを管理してる???
 ・気になる部分があったので、改善のコーディングしてるよ。
  ・セキュリティ
   マスタで管理できるように
  ・Pools
   Agentが送信先がコケてると他のPoolにスイッチ可能に。
  ・MasterlessACKs
 QA
  Q:パッチ作成は何人でやってるの?
  A:50人が働いていてOSSコミッターが何人いるかはわからんです。
  Q:ログはテキストだけど、パース処理はどこで?(古橋さん)
  A:Flumeは各ノードでうまい構成になっていて
    Decorator
   性能問題は?
   HiveはJSONデータをうまく活用できてるよ。
  Q:Masterlessとそうじゃないバージョンの性能比は?
  A:ノード数が増えると
  Q:HBaseじゃなくてCassandraなの?
  A:(※英語きつい。。。聞き取れず)


◎マーケティング向け大規模ログ解析事例紹介:原謙治(NTTコミュニケーション)
 ・自己紹介
 ・BizCITYというクラウドサービスを展開中
  まずは、宣伝。
  Bizストレージ、Bizマーケティングとして大規模データ、分散処理を実施してる。
 ・Hadoop in Bizマーケティング
  CGMデータを解析して口コミ情報抽出
  アクセスログから行動情報抽出
 ・Hadoop in BuzzFinder
  CGM DBからHDFSにインポートして解析開始。DBはPostgreSQL
  処理フローは資料参照。
  リッチインデクシング技術(NTT研究所が開発した日本語解析技術)
  ※検索インデックスってどんなものなんだろう?
  ポジネガ分析気になる。
 ・Fast Map-Reduce for PaaS Services
  アクセス解析やマーケティング解析を行う上でShuffleコストが大きくなるため大量マシンが必要
   =>マシン数を減らすことが目的?
  Map Multi-Reduce、PJoinはNTT研究所が開発した技術!?(子象本にないっけ??)
   =>Multi-Reduce。同一ノード上のMap出力をReduceすることで、shuffleフェーズに渡るデータを削減している。
    =>PJoin 
 QA
  Q:Map multi-reduce、PJoinはどう実現してるのか?公開するのか?
  A:Hadoopの0.19に改造をしてる。
    公開できるかどうかはわかりません。NTT研究所が研究しているものを試しに実装してみてるから。
    なのでパッチにはなりませんかね(研究所に聞いてみないとわからないっす)
  Q:性能が向上したパターンはあったが、悪化する場合などはあるのか?
  A:不明
  Q:Map-side Joinとの違いは?
  A:。。。
※この辺で少し集中力が途切れてしまいました、すみません。(次に集中したかったので。。。)


◎ミクシィにおけるHadoopの利用:伊藤敬彦(mixi)
 LSH-Based Recommendation engine powered by hadoop
 ・実はmixiの話はすくないよ。
 ・利用している環境。5or6台/クラスタ
 ・Hadoopの活用
  ログデータをHDFSに保存
  DBコンテンツをHDFSに入れることで、DBに負荷をかけずに解析する。
 ・マイニングも検証中
  検索クエリログをベースにデータマイニング
 では、本題。
 ・LSHを利用した推薦
 ・推薦とは?
  mixiにはいろいろ推薦(レコメンド)を付加できるサービスがある。
 ・推薦するには?
  類似インスタンス集合を抽出する。
  インスタンスは文書だったりユーザだったり
 ・類似インスタンスとは?
  同じ特徴を持つ集合
  例:同一商品購入したユーザとか同一単語を持つ文書とか
 ・抽出するには?
  全ユーザごとに全ユーザとの類似性をチェックすると時間がかかりすぎる!
  =>LSHを利用しよう!
 ・LSHについて
  特徴:
  ・速い!
  ・精度はそれほどではない
  事例:
  ・Google Newsのレコメンド(USロケール)
 ・LSHの処理ステップ
  2つだけ。
  1.インスタンスベクトルを計算(似ているデータは同じ値が返りやすい関数)
  2.同一値が帰ってきたデータが類似インスタンス
 ・インスタンスベクトル例(あとでスライド見ようね)
 ・Likelikeがいち実装。Hadoopでうごくよ
 ・実験について
  トップページに表示されていない記事を知ってもらうために推薦してみるぞ!
 ・実験1
  性能を測ってみた
 ・実験2
  精度を調べてみた。
  精度はほんとにひどいな。。。
  =>同一カテゴリの遷移を元に計算したらそれなりになってきた。
 ・今後
  データソースを増やしたい。
  他のアルゴリズムも実装したい
 ・CM
  以下も作ってますよ。
  Oluolu
  Anuenue

 QA
  Q:Mahoutは使わないんですか?
  A:Likelikeを作った頃にMahoutになかったので作った。
    性能比較したいと思ってる。
  Q:ログサーバのデータ転送はどーやってる?
  A:伊藤さんのところにはどういう仕組みかは上がって来てない。

  Q:ベクトルの次元数はどのくらいまで耐えられる?
  A:高次元のデータに対して耐えられるように作られてる。
    次元数が低くて良い制度が欲しければ他のアルゴリズムがいいかも。
  Q:ユーザのベクトルを作るテクニックは?
  A:画像などであれば大変だけど、ユーザであれば、単語とかキーワードとかで

  Q:ニュース以外のデータは?
  A:まだまだ実験中。まだやってない。

  Q:推薦される記事数のばらつきはどういった理由が考えられる?
  A:後ほど考察してQAサイトに入れます。

  Q:LSHをMapReduceに載せたということだけど、関数の計算をさせてる?
  A:Iterationはしてない。
   Map側でLSH関数計算してる。Reduceにて類似インスタンスを導出してる。

  Q:今後の予定の空間木とは?R-Treeだと高次元できついのでは?
  A:低次元にて利用できるように用意したい。
   
  Q:HamaとかGiraphで高速化させてみるのはどう?
  A:イテレーションがいらないからあまり利用用途がないかなぁ。
◎懇親会
 AWSを採用しない企業がいくつかあったのでそのあたりを質問してみた。
 AWSは通常運用に利用すると結構なコストがかかる場合があるので、ノウハウがある企業や
 データ量が多い場合は、オンプレミスの場合を選択しているらしい。
 やはりスポットで利用する方がお得感があるみたいだった。
 Twitter上だけの知り合いだった方々と面識が持てたのが一番の収穫でした。


感想+調べること
感想
 会場規模とかQAサイトとかオープニングムービーとかすごかったです。しかも無料。さすがリクルートさん。
 ランチボックスとか出てきたし。装飾もとても無料のカンファレンスと思えない出来でした。
 午前中はHadoopをもとにした各社の戦略とCMという感じが色濃かったです。少しずつ各社の立ち位置が違いそれはそれで面白かったです。

 AWSの説明を聞いてやはりAWSを扱える技術は必要だと再認識。
 お金かけないで触ってみれるレベルでまずは触ってみるかなぁ。
 洗脳されてるのかもしれないけど、自社or自前でHadoop運用するのは厳しそうです。(懇親会ですこし認識が変わった)

 カフェコーナーでは、リクルートのMITの冊子が配られていたり、映像や案内に使われていたHadoopマスコットのシールが配られていたりと小技も聞いてました。
 あと、オライリーの販売コーナーも用意されていて、思わず子象本を買ってしまう罠にはまったりもしましたが。。。

 mixiの伊藤さんの話は最後で疲れていたのですが、ストーリーが上手くできていて、実験や事例もあったのでわかりやすかったです。
 Hadoopはエコシステムと呼ばれるHadoopを活用するツール群(Hiveの話が多かった?)、Hadoopの今後、Hadoopを活用したログ解析の話など、
 話題が豊富でそれぞれの話が面白くて困ってしいまうくらいです。
 いくつかのセッションで出てきたのですが、アクセスログなどをHDFS上に集めるための仕組みがまだ乱立(定番がまだない)している感じを受けました。
 Flume、Scribe、MapR。。。などなど

 あとは、テクニカルセッションのビデオがアップされたらまた目を通さないと。。。
 残念ながらHadoopから少し縁遠くなっていますが、これからもネタや参考になりそうな話には事欠かなそうなのでかじりついていこうと思います。
 ※一番やらないといけないのは英語の勉強かもしれないです。。。

調べること
一応Solrの人なので、Solrに関連しそうな話に興味がいってしまいます。
  • NTT研究所のリッチインデクシング技術
  • やっぱりAWS触ってみる。EMRまでとは言わないが。(herokuもちょっと興味あるが。)
  • Mesos、GreenPlum、Scribe、Storm、Flume、Giraphこれらの概要

関連サイト  公式QAサイト。後日録画していたセッションがアップされるそうです

 Hadoop Conferene Japan Fall 2011 - 急がば回れ、選ぶなら近道
 Hadoopカンファレンスが開催、本格普及を見据えた支援サービスや先進事例が充実 - ニュース:ITpro
 Hadoop Conference Japan 2011 fallで使用された資料 #hcj11f | インフラエンジニアのつぶやき(スライドをまとめてくれてます。)
johtani | hadoop | 17:51 | comments(0) | trackbacks(0) | - | - |

Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回)に参加しました。

Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回)」に参加しました。300名入るイベントルームでしたが、後ろの方まで人が埋まっていました。
ということで、主に自分用ですが、メモを取ったので。
※二次会行きたかった。。。


1.「鉄道システムへの誘い」
 @ayasehiro(本名無理w)
 Hadoopの話はありません。

 ○鉄道系基幹システムの開発
  実態:
   耐用年数:10年以上
   開発期間:数年〜5年程度
   開発規模:〜10Mステップ、10k人月〜

  ほとんどテスト、しかも異常系が主体。
  夜間に実際に鉄道を走らせて試験したり。

  開発サイクルが長い
   人材育成が難しい、ノウハウがたまらない。

  開発自体はほとんど時間がなく、設計・製造・試験など新規技術の採用が難しい。
  開発4年前の調査・検証自体が2年程度。
  Hadoopも調査中。
  
 ○鉄道システム3大システム
  マルス(予約オンラインシステム)(1960〜)
  コムトラック(運行管理システム)(1972〜)
  ヤックス(ヤード自動化システム)(1968〜1984)

 ○鉄道輸送システムとは
  用語:
   運行を計画する=>輸送計画
   列車を運行する=>運行管理

  需要想定+営業施策+その他(お召し列車など)=列車ダイヤ作成
   基本計画(長期)+短期計画(数日〜四半期程度)=列車ダイヤ(重ねあわせてできあがり)

  ダイヤの計画(発車時刻など)と車両運用(車両自体の走る組み合わせ(仮の車両))の作成
  +乗務員運用(乗務員の運用計画)

  運行管理:
   なにも起きなければすることなし。(車両故障、天候、人身事故などによる整合性を取る作業)
   =事前に計画した輸送計画をすべて見直し
   遅延の検知は?
    昔:人による伝令
    今:システムによる検知(レールに電流流して検知)

   運転整理(実際に遅れた):
    部分運休、折り返し駅の変更などにより対応
    元の計画になるべく近づく形で修正していく。

   新幹線、山手線、京浜東北線などは速度信号という信号が表示される。
   線路上に信号はないらしい。

 ○鉄道システムを取り巻く情勢
  少子高齢化・人口減少のため凋落産業となっている。
  社会インフラの責務=動くのが当たり前
  2007年問題(ベテランの引退)=スジ屋さんは最近いないらしい。
  高度な判断支援をするシステムが必要
   連続稼動=分散技術を適用できない?
   関係各所との情報共有
   計画立案のための情報支援=最適化技術を適用できない?
  
 ○分散処理技術の適用
  個人的な感想
   可用性(連続稼動)のための仕組み
   バッチ処理

 ○分散技術の適用
  ・連続稼動
   active-active構成がメイン
    主系の出力だけを行う。問題が出れば副系の出力。
   3系統の出力を比較器にて出力もある
    magiシステム
 
   問題点:
    ハードが高い(H社)
    ソフトウェアの作り込みが複雑=テストが前パターンできない
   解決案:
    汎用的なハードが使いたい。
    作り込みも減らしたい
  ・バッチ処理:
   Asakusa使えないかなーw

 ○最適化技術の採用
  コンピュータ技術の発展
  2007年問題
   職人に言わせれば最適化はいらない、俺の言うことを聞けw

  ・車両運用のモデリング
   車両数大=>組み合わせ大
   制約条件が多い
   車両運用の場合、走行累積キロの条件もある
   ->有向グラフにモデル化される。(ただし、グラフ化するまでが大変)
  ・乗務員運用のモデリング
   車両と違い、乗務員は1回で2人とか運べる(運転士+移動する人とか)

  ・車両割当のモデリング
   やはり、グラフ化が可能

  ・乗務員交番のモデリング。。。など

  結構一般的なモデルに落とし込める。ただし、落し込みが大変。
  机上研究だったものが、コンピュータの発展により実証研究になりつつある。
  
 ○まとめ
  鉄道システムはまだまだ未到の領域が残っている。
  開発サイクルが長いため、保守的な開発になる(35年前の設計思想からあまり変わってなかったりする)
  しかし業務要件やシステム利用者の意識は変化している
  
  興味を持たれた方は、ぜひ、我社に!(社名は2次会でw)

 ○Q&A
  Q:鉄道システムのカルチャーってイケイケ?保守的?(@okachimachiorgさん)
  A:最新技術も知らないとだめじゃないかという人が出てきている。
    コア部分(安全第一なところ)+周辺領域(ある程度融通が効きそうな部分)と考えることができるんじゃないかって人も出てきている。
    JR九○=先進的
    JR四○、北○道=お金ない
    JR○海=超保守(企業的に超保守)
    JR東、西=うーむ?
    東京メト○(運行計画)、阪○=先進的
    京○急行=基本人間で進路制御w
   基本的には新しいものには興味をもつ人たちでは。
  Q:Su○caとかで分散処理は利用出来るんでは?
  A:匿名なので外側から見ていると分散処理はいろいろ使えるんでは?
    ログデータからいろいろできるんじゃないの?活かすべきでないの?
    使いどころはいっぱいある。
  Q:鉄道システムでどうしようもなくなったことはあるか?
  A:保守体制が一番気になる。
    OSSとかならまだ調べられる。ミドルウェアなどの保守契約が必要。
    保守体制が確立されてればある程度の保守費用は飲み込む。
    どうしようもないことはないが、今すごく困ってることは
    Excelで帳票を出したいとかいわれること。(ちょっと前に作ったシステムでExcel2003。バージョンあげると速度が遅くなったりするw)
    ilog社のものを使ってたが、IBMに買収されて保守費用があがってこまってるw
    保守が10年と長いため、サポートなどの折衝が必要。
  Q:最適化の適用範囲は?
  A:走行順序(どこで追い抜くか)の算出に活用。ほぼ完成でユーザ教育中。
    1列車の波及がかなり影響が出る。ダイヤだけ見ると列車だけだが、乗務員も関係しており、大変。
    ある時点から終電までを最適化の対象としたりして割り切っている。
    また、不足分について算出が出来れば、そこで打ち切ったりもする。

2.「九州電力におけるHadoopの取り組みについて」
 株式会社キューデンインフォコム e−ビジネス部 @hisashi_yano
 概要:2年間関係したOSSをメインにしたシステムの話。

 ○九州電力の概要
  現在風当たりが強い業界。
  東電の1/10くらい
  部門ごとに大手ベンダーが関わってる。

 ○Hadoop採用の経緯
  部門ごとに個別最適なシステムを導入していてベンダーロックインされてる。

    ・ホストのリプレース
  ・両現用センター構成への対応
  ・スマートグリッドへの対応

  問題点
  ・コスト削減
  ・技術革新への中の人の対応(内部でも問題を理解できるように)
  ・商用パッケージのカスタマイズの限界
  ・脱ベンダーロックイン(実は楽なんだけど。。。)


 ○過去2年間の研究内容
  ・H21年度の結果
   テーマ:クラウドの要素技術の研究
    KVM、Eucalyptus、wakame、hadoop   
   
   性能比較:VMWareとKVM->ベンチマーク比較
     結論:性能的にあまり問題なし。
   MapReduceの耐障害性など
     ダミーデータにより台数増加による影響を検証
     結論:台数大->性能向上
        ストリーミングは性能劣化する
        スループットはリニアに向上
     信頼性は?
      実行中にノードを抜いたりして検証。
     結論:問題なし。
   クラウド環境におけるシステム管理手法
    複数ハードで1アプリという構成になる。
    監視対象が膨大になる。
    障害発生時の切り離しや監視対象も膨大。
    データセンター自体を監視する仕組みが必要では?というところで終了。

  ・H22年度の結果
   分散に特化した研究
   前年度の課題
    サーバの仮想化・管理に関する課題
    分散処理に関する課題
    分散処理環境の運用監視に関する課題
   目的:
    Hadoopを本番への適用(実際にはダミーデータ+本番の仕組み)
   
   柔軟なサーバ統合基盤(サーバを起動->バッチを起動->回す仕組み)=MonkeyMagic
    libvirtを使ってる
    
   50台の仮想サーバの起動が10数分で完了。

  運用監視基盤(monkey magic)
   仮想、実サーバ混在の監視
   監視状況(サーバの状況)から判断して制御する仕組みを構築
   DSLにてルール(判断+制御)を指定
   ・ジョブの監視
   ・ジョブの実行管理
   ・構成管理の省力化
    volanteと連携が可能=AmazonWebServiceとも連携可能
   ・サーバリソース+アプリケーションの一括監視が可能
  分散バッチ処理の概要
   RDBからKV形式にして抽出し、MRで回してRDBに戻すという研究
   対象:
    配電部門(電柱の設備情報の目視検査)のデータの月間バッチ処理
   現状:
    19時間程度かかってる。
   テスト環境:
    実サーバ2台(仮想10台)
    MySQL、Javaで実装
   処理内容
    電柱104万本
    巨大バッチを分割して実装
   結果
    MySQL1台では15日以上かかる処理(現行システムで19時間)
    処理が32分で終了!他でも効果でるよね。
   バッチ短縮の理由は?
    1.データアクセスが分散された
    2.処理の並列化(多重化出来る部分がうまくできた)
   
  分散処理を書くのに2名死亡。。。

  適用基準の策定、開発ガイドライン、フレームワーク整備などが必要。

 ・H23年度は?
  Asakusaの適用など。

 ・さらに今後は?
  スマートグリッドへの適用
   ->メーターの交換が必要だが、10年くらいかかる
   ->スパンが長い(10年)ので商用製品だときつい?
   データ量も半端ない。
   テネシー州とClouderaでOpenPDCってのやってるらしい。
  
  電力と気温の関係は密接な関係あり。
   エアコンが割合を占めてるから。
   過去実績と予想気温データから分析するのにHadoop使える!
   
 ・2年間やってきて思うこと
  将来目指すべき理想像を掲げるのが重要
  新技術導入は段階を踏むことが必要
  コミュニケーション大切!

 ○Q&A
  Q:仮想化環境のオーバヘッドは?(I/O)
  A:台数を増やしたときにどうなるか?というのを検証したかった。
   アプリ配布も考えていたので、物理サーバに縛られたくなかった。
  Q:仮想化に関して気をつけたM/RのPGで気をつけたことありますか?
  A:まったくないです。
  Q:日本でスマートグリッドははやるの?
  A:電力会社的にはやりたくない。費用対効果があまりない。
  Q:今後のスケジュールは?
  A:文書管理システムの組織名変更などの処理時間が540時間とかでてくるらしい。
   これをHadoopで対応してみようかと思ってる。
  Q:Asakusaをどう評価していくのか?
  A:開発効率性があがるか?は検証する予定。1/3くらい楽になるんじゃないかなぁ?byのぐちさん
   バッチの種類などにもよると思うが、標準化も指標にする予定。
   結果はまたこの場で報告する予定。
  Q:Asakusa+MonkeyMagicの連携はどんなこと考えてる?
  A:MonkeyMagicを運用基盤として行く予定。合意が取れればだけど。
  ※MonkeyMagicもOSSにするよー

まとめ
Hadoopから少しずつ離れつつありますが、やはり興味があるので、非常に楽しく話を聞けました。
また、今回はインフラ分野のシステムということで、システムに要求されるレベルや
運用周りにも気を配っている話が聞けたのが収穫でした。保守期間が長いため、テストが長い=
運用もしっかりと考慮を入れた設計、実装が必要になるというのは最もだと思います。
ただ、少しずつ修正が入るアジャイルなども同様かと。

MonkeyMagicが出来上がってきた背景の話を聞いて、さらに興味が湧いてきたところです。
今後もかかわりが少ないかもしれないですが、ウォッチしていきたいと思いました。

ただ、興味あるモノが多すぎるので、優先度をつけつつこなして行かないと。。。
少しずつでも身につけていきたいと思う今日このごろです。

続きを読む >>
johtani | hadoop | 23:10 | comments(0) | trackbacks(0) | - | - |
1/1PAGES | |

09
--
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
--
>>
<<
--
PR
RECOMMEND
[改訂新版] Apache Solr入門 ~オープンソース全文検索エンジン (Software Design plus)
[改訂新版] Apache Solr入門 ~オープンソース全文検索エンジン (Software Design plus) (JUGEMレビュー »)
大谷 純,阿部 慎一朗,大須賀 稔,北野 太郎,鈴木 教嗣,平賀 一昭
Solr 4系に対応した改訂版を出しました!興味ある方はぜひ。
RECOMMEND
Apache Solr入門 ―オープンソース全文検索エンジン
Apache Solr入門 ―オープンソース全文検索エンジン (JUGEMレビュー »)
関口 宏司,三部 靖夫,武田 光平,中野 猛,大谷 純
RECOMMEND
RECENT COMMENT
  • ポモドーロ回してます。(ポモドーロテクニック入門読みました)
    おーたに (05/07)
  • Lucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。
    おーたに (04/26)
  • メインMBAをMountain Lionにアップデート(いろいろ確認中)
    おーたに (09/04)
  • メインMBAをMountain Lionにアップデート(いろいろ確認中)
    m_nori (09/03)
  • メインMBAをMountain Lionにアップデート(いろいろ確認中)
    おーたに (09/03)
  • メインMBAをMountain Lionにアップデート(いろいろ確認中)
    ho4kawa (09/03)
  • メインMBAをMountain Lionにアップデート(いろいろ確認中)
    おーたに (09/03)
  • メインMBAをMountain Lionにアップデート(いろいろ確認中)
    まろか (09/03)
  • Lucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応(1章)
    おーたに (08/07)
  • Lucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応(1章)
    moco (08/07)
RECENT TRACKBACK
MOBILE
qrcode
OTHERS