_1010150_1010152

メトロ東西線 竹橋駅 1b出口からNIIのビルに歩いて。ちょっと迷った。花見シーズンなのか歩いている人がおおい。

googleクラウドが実現する大規模並列クエリサービス / Google 佐藤一憲

  • 挙手:
    • google GAP (PaaS): 数人挙手
    • amazon EC2 (IaaS): 1/3くらい
    • PaaSは学習が必要なのでマーケットシェアをとれていない。
  • (アクシデント) WiFiが切れてGoogleプレゼンテーションが一時的にできなくなった。事前にPDFにしておけばいいらしいが。
  • 社内:「グーグルスピードで仕事しろ」
  • adword: TB規模のデータが日々生成されている。
    • 急な問い合わせでmapreduceのコードを書いてデプロイするのでは遅すぎる。
  • DWH:
    • 高価な製品を買う必要がある
    • アドホックな問い合わせに対応できない(インデックスをはってないとだめ) → インメモリDBやSSDにするしかない
  • MapReduce:
    • スケールアウトできるしDWHほど高価ではない。
    • レスポンスがよくない。ターンアラウンドタイムが長い→バグに気づくのが遅れる。
  • Dremel(ドレメル)
    • 2006年から運用
    • 大規模並列クエル
    • 数百億件のフルスキャンが数十秒で終わる
    • 公開版がBigQuery。データ構造は簡略化されている。社内版とのパフォーマンスの差はない。
  • デモ: Wikipediaでいちばん更新されているページは?
    • 9GB(参照したカラムだけ)のデータをスキャンして8秒で
  • デモ: タイトルに数字が含まれるものは?
  • 4秒くらい
    • 被構造化データの検索(正規表現)
  • デモ: ERP 4.5億件売上データ
  • インポートが必要なので完全にリアルタイムではないが何時間もかかるわけではない。
  • カラム指向ストレージ
    • 技術は古い。
    • 行指向に比べ圧縮率があがる。
  • 数万台規模で並列処理
    • googleデータセンターの規模の経済だけ
    • サーバマシンは特定用途に固定されてないので自由につかえる
    • datacenter as a service
  • 階層構造
    • クエリの分配・結果の集計
    • RPCが高速になっている
  • LinuxにQoSを担保するスケジューラが入ってる???
  • Dremel: レスポンスが遅いマシンがどうしても出てくるがスレッショルド切って100%じゃない集計もとれる。
  • MapReduceでもディスクを大量につかえればDremelと同じパフォーマンスが得られるかもしれなが、運用できる?
    • googleではソフトウェアエンジニアで24時間はりつける人をやとっている。
  • bigquery:
    • 大規模のoutputには向かない。そういう設計になってない。結果を1RPCで返すところで制限になる。
    • データの更新ができない。
  • mapreduce:
    • 複雑な処理ができる。
  • Q: RDBは残る? (GAEでmysqlがつかえるが)
  • A: どうしてもBigTableがつかいにという声があるのでmysql(cloudsql)をつかえるようにした。
    • ロングスパン: 「スパナー」BigTableの次世代版。NoSQLとRDBの中間。eventually consistency。snapshot read。
  • 並列アップロードのツールはコンサルで提供している。

[2013-03-22 14:33]

トップエスイープロジェクト2012年度活動のご報告 / NII 田辺良則

[2013-03-22 14:42]

  • 育成実績240名 (毎年20〜40人)
  • 産学連携
  • 「達成された方もされなかった方もおられますが」(笑)
  • モデリング能力
  • UCLとの海外連携
  • 博士課程にも進める(電通大、北陸先端)
  • 遠隔受講もある

[2013-03-22 15:01]

トップエスイーによるロンドン大学とのグローバルPBL 参加報告 / キヤノン 小林秀典

[2013-03-22 15:01]

  • 組み込み屋
  • PBL: project based learning
  • UCL: 学生は万国共通で夜型! 夜になると大学から追い出されてしまうので、夜はチャットで。
  • selenium

[2013-03-22 15:21]

フィーチャ分析と充足可能性判定を用いたシステムテストに向けたシステム構成導出 / 日立 新原

[2013-03-22 15:22]

  • テスト項目からシステム構成を導出する必要がある。
  • テスト毎にシステム構成を置き換えるのは非現実的
  • 属人性をなくしたい
  • テスト項目を網羅したい
  • フィーチャ分析
    • 機器カテゴリごとにフィーチャツリーをつくる
    • 機器の組み合わせも考慮
  • サブシステム候補作成
    • フィーチャから候補の組み合わせを生成して充足判定でけずってゆく
  • システム構成導出
    • みたすものがなければハミング距離ではずれにあるものを除いてリトライ
    • 機能だけならSATソルバでよいが、将来的に台数をあつかえるようにSMTソルバを採用
  • Q: フィーチャ分析が属人的では?
  • A: ソフトウェアプロダクトラインの研究がなされているのでそちらに期待。構成導出にワンクッションおくところに意味がある。

[2013-03-22 15:41]

組み込みソフトウェアへのKobrA法の適用 / キヤノン 仲

[2013-03-22 15:42]

  • コンポーネント化で品質をたかめたいが、コンポーネントを括りだすのがむつしい。
  • KobrA:コブラ
    • コンテキスト実現
    • コンポーネント仕様
    • コンポーネント実現
  • 並行性・非同期通信で工夫が必要だった。
  • Q: 非同期・並行性導入で状態遷移はかわってこないか?
  • A: 上流の状態遷移は変更ないという認識。

[2013-03-22 16:02]

このあとポスターセッションがあったが、かるくひとまわりして帰ってきた。

竹橋駅から平川門のあいだで写真を撮って帰社。

P1010175_1010232