Hadoopモデリング座談会#2

雑記

概要

イベント名 Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第二回)
URL http://atnd.org/events/5987
日時 2010/07/26 18:00 - 20:00
場所 スター研修センター　御茶ノ水 Sun（サン）1F
twitterハッシュタグ #hadoopModeling
  • スーツ若干多め
  • 年齢やや高め
  • 女性ほぼ皆無

#1 @shot6 大谷晋平

現状と特徴
  • Hadoop の現状
    • 上位レイヤの開発がホット
    • 日本語も充実
  • Nosql の現状
    • 加熱し過ぎ
    • Twitter のニュースはいい冷却剤
  • RDBMS の現状
    • 成熟
    • Mysql の開発者はMariadb & Drizzle へ
    • プレイヤーも新規参入者も減少
  • Hadoop の特徴
    • big data
  • Nosql の特徴
設計パターン
  • CQRS パターン(マイクロソフト)
    • Command query responsibility segregation
    • æ›´æ–°ç³»(アクション)と参照系(クエリ)をわける
      • 更新系は内部状態を変える、参照系は変えない
      • 更新系は現状を返さない、参照系は返す
  • 一貫性保証をAP任せにすると破綻する。非合理的
    • APは一貫性維持を指示するだけ
      • Cassandra の Consistency Level とか
新しいアーキテクチャ
  • 従来の AP-DB では JOIN しまくってデータを呼び出す
  • 新しい方法では RDBMS,Hadoop,NoSQLをうまく連携させる
    • AP は Hadoop に直接データを入力
    • Hadoop は denormalize して NoSQL にデータを出力
    • AP は NoSQL 上のデータを読みに行く
    • この考えは HDFS アーキテクチャと同じ発想
    • アクション側で、一貫性を維持したければ RDBMS を同期させて使う
      • 力技は全て Hadoop
    • クエリは NoSQL 非同期
  • メリット
    • 一貫性の調節可能
    • AP開発の容易性
      • DBの種類を隠蔽
    • 管理容易性
      • 一貫性:RDBMS
      • スケーラビリティ:NoSQL
      • データがどう永続化されるかは開発者は意識しない
課題
  • Hadoop に対するデータの入出力をどうするか
    • 入力:SQLじゃ話にならない
      • ×sqoop
    • 出力:Thrift じゃダメ
    • 直接 MySQL などから吸い上げる仕組みと、直接 NoSQL に書き出す仕組みが必要
  • 現在は NoSQL クライアントがサーバの物理位置を知らなければいけない
  • データ構造のポータビリティ
  • 異なるDB間でのフェールオーバ
    • ヒントハンドオフ
まとめ
  • Hadoop は RDBMS と NoSQL のハブ
  • NoSQL には大量に書き込み、1キーで view を取得できるようにする
  • クライアントは REST + JSON で呼び出し
    • このときにできれば位置透過性の維持をしたい
  • アプリケーションには分散システムを意識させる
  • アプリケーションにはミドルウェアを意識させない

#2 佐藤一郎先生(NII) @ichiro_satoh

mapreduce 今昔
  • mapreduce は90年前後の並列 Lisp における並列処理手法と類似
    • タスク数>サーバ数→スケジューリング問題
    • 現在はタスク数<サーバ数なので、昔より簡単
  • Google は使っていないものしか公開しない(mapreduce論文についての話で)
Hadoop 感想
  • Google MapReduce はウェブインデクシング主体、つまりバックエンド処理
  • Hadoop はフロントエンド用途に使おうとする動きが多い(さっきの話とか)
  • Hadoop 使いたいために AP 作るのはやめた方がいい
  • 高機能化には性能低下のリスクがつきまとうので Hadoop の機能追加は慎重に
  • Hadoop 向け DSL 作ろうとしているが、Hadoop のためとか Mapreduce のためとかはやめた方がいい
    • 必要とは思うが AP ごとに応じて設計されるべき
    • 非機能要件のための DSL が重要
      • 分散システムの隠蔽
      • バッチ自動化
  • Boom(UCBのDSL)
    • 論理型言語
    • プロトコル記述
    • 投機的実行制御
データセンタから見た Hadoop
  • 消費電力変動大
  • Hadoop 専用システムは電力効率悪い
    • バッチ処理だから実行タイミングは決まっている
    • 複数の mapreduce を組み合わせるか、他の AP と共存すべき
  • Google は電力負荷の平準化してる
  • Hadoop は要因多すぎたり Java だったりするせいで電力モデルが作れない
  • Datacenter as a Computer の話
    • こんな文書を出すということは、つまり Google はデータセンターに興味がないということ
    • 中田さんがいて近日発売の翻訳書の宣伝してた
    • (私の感想記事もどうぞ http://d.hatena.ne.jp/shiumachi/20091229/1262054679)
  • データセンタのOSが必要
    • Mesos(UCB)
      • データセンタのOSライクな枠組み
トレンド
  • インタラクティブなデータ解析
    • オンライン処理
    • Hive とか Pig とか
  • リアルタイム処理化
    • 高速処理
    • 時間制約
      • バッチ処理では結構重要
  • ストリーム処理
    • 連続的な入出力処理
Future
  • 特定のシステム構成を前提に最適化は不可能
  • クラウド環境
    • プロバイダになるかユーザを選ぶか
    • ユーザになるとプロバイダにデータを読み取られ続ける
  • 従量課金がクラウドの基本
    • うまい処理とは料金が少ない処理のこと
    • 利用料金が見積もれる言語があればいい
  • データビジネス

#3 @ashigeru あらかわしげる

多段 mapreduce
    • シーケンス図ではなく DAG
    • スケジューリング
      • Hadoop はネイティブサポートしない
      • Oozie とか使えばいけるかも
    • クリティカルパス分析が必要になる？
変更耐性
  • 旧来:段階的詳細かを元にしたシーケンス
  • DAG:Predecessors と Successors 両方に影響
  • 対処法案(どれも不完全)
    • フロー全体で共通のモデル
    • 動的型付け
    • タプル＋型推論
    • 追加カラムを別フローに切り出す
    • 常に全データが流れてくる仮定をおく
再利用性
原子化
  • 多重スケジューラで可能？
併合化
  • 同一バッチを併合できるか？

#4 座談会

MS 萩原さんも参加。

  • 佐藤さん
    • データセンタOS の話は今年に入ってから
      • これからの話
    • 基本は従来のOSと同じ
      • リソース管理
      • スケジューリング
      • シェアリング
      • つまりいかに速く見せるかが重要
      • データセンタOSではそれに加えて消費電力を考える必要がある
    • 計算パラダイム
      • 非同期はお手上げ。力技で頑張ってほしい
  • 大谷さん
    • クラウドOSは開発者にとってしきいの高い領域になりつつある
  • 萩原さん
    • 並列性と逐次性の両方が重要
    • 人間の頭と同じ
      • 目で何かを見るとき、同時並行的に見ながら見たいものだけフィルタリングする
      • 人はブレストしてからまとめて体系化する
      • つまり発散して収束する
      • まさに mapreduce
    • 今の mapreduce はインスタンスベース
      • どういうデータに対しどう処理するか
      • これはユースケースモデル
      • ドメインモデルもあってもいい
  • あらかわさん
    • モデル検査が取り入れられるタイミングが来る
    • 実際に動くプログラムにするのはコンパイラではなく人
吉岡さん(id:hyoshiok)からの質問: 今 Google では何がホットなのか？
  • 佐藤先生が回答
  • 先月 Google の VP に会ったときに聞いた話
    • データセンタ間連携に興味がある模様
    • メタ情報を抽出する検索


以上

関連記事