#hcj-2014

July 08, 2014

Hadoop Conference Japan 2014に参加してきました

個人的な所感としては。

  • spark楽しそう(だけどまだ触るには勇気が)
  • Prestoも熱そう
  • MapR書くよりもSQL書く方がお手軽

以下はメモ書き。

keynote

hadoopを取り巻く環境について

  • 始めて普及した並列分散

    • データの読み込みのスループットを最大化
    • 全件データの処理を実現
    • シンプルなモデル(MapReduce)
    • YARN
    • MapReduceからそれ以外のアルゴリズムも
    • 複数の並列分散エンジンを併用できる環境
    • メモリーの大容量化、10Gbpsネットワークの普及

      • インメモリー処理の実現性の向上

The Future of Data

Doug Cutting

  • 未来について

    • ハードウェアの価格の低下、性能の向上
    • データの重要性の向上
    • オープンソースが勝ち残る

The Future of spark

Patric Wendlell

  • Sparkの目的

    • データサイエンティスト、エンジニア能力の拡張
    • 表現力のあるクリーンなAPIの提供
    • 多様な環境にわたって統合されたランタイム
  • API stability

    • 3か月サイクルでマイナーリリース
    • 必要におおじてメンテナンスリリース
  • Spark SQL
  • MLlib

    • Spark + R
  • DataBricks

Hadoopエコシステムの片鱗と見えてきた使いドコロ

  • TreasureData

    • なぜHadoop使うのか
    • Hadoopを使うのは最適な解か

      • 安いストレージとして使うだけならHadoopより良い物は沢山ある
    • データの収集ソフトウェア

      • 多種多様なデータ・ソース
      • fluentd,flumea,kafka,sqoop
    • ファイルフォーマット

      • Schema on Read
    • 管理・人的コスト低減の支援
    • 簡単にデータを扱うか

      • Tez, Spark
    • SQL on Hadoop

      • Impala, SlarkSQL, Presto Drill
      • Mahout, Spark MLlib
    • 今までの時代

      • データを入れるだけ入れたけど、レポート化できる人の限られている
      • 今までは何でも入れられるだけ
      • これからはだれでも取り出せるようにしないと意味がない
    • Hadoop -> MPP

      • Twitter: Hadoop -> Vertica
      • Pinterest: Hadoop -> redshift
    • 非構造化データの領域に踏み込む
    • 混沌の時代

セッション

マルチテナント化に向けたHadoopの最新セキュリティー事情

  • Hadoopのユースケースの移り変わり

    • バッチ処理を効率よく行うため
    • 部門単位での利用、クラスターの乱立
    • 近年
    • バッチ処理 + インタラクティブな処理
    • SQLによるアクセス
    • データは一部の人だけのものではない
    • クラスターの共有(マルチテナント)
    • マルチテナントのメリット
    • データの複製不要
    • 業務の取り巻き
    • 性能・効率の改善
    • 課題  - リソースの分離と管理
    • Role管理
  • マルチテナントとセキュリティーの関連性

    • 認証
    • kerberos

      • 相手が何者であるかを保証するプロトコル
      • 暗号化
    • 認可
    • HDFS ACL

      • ファイルシステムレベルでのaccess control
    • Apache Sentry

      • データベース、テーブルview、行列の粒度でアクセス制御
  • 認可モジュールSentryの紹介

    • Apache Sentryはモジュールとして開発されている

BigQuery and the world after MapReduce

  • BigData at Google

    • ログ分析するのにMapReduceを書いてる場合じゃない
    • BigQuery ( sql base )
    • indexなんてないんや
    • 全文検索、120億行、10秒ぐらい
    • storage料金
    • Quesy料金
  • Column Oriented Storage

    • もはやスタンダード
  • Colossus File System

    • GFSの次のもの
  • MPP

    • 1TBの内容を数秒で舐めるためには何台必要なのか
  • JOIN

    • small join
    • broadcast JOIN
    • ばらまいてコピー => JOIN
    • JOIN Each
    • shuffleしてjoinできる
  • BigQuery Streaming

    • fluentd
    • fluent-plugin-bigquery
  • BigQuery User-Defined-Function-with-JavaScript

    • クエリ内にJavaScript書く
  • Cloud Pub/Sub
  • FlumeJava

  • MillWheel

SQLによるバッチ処理とストリーム処理

  • @tagomoris

    • stream処理
    • norikra
    • Hadoop
    • Hive/ Presto
    • SQL is NOT the best;
    • But, SQL is better than NONE.
    • Batch processing
    • hive
    • Stream processing
    • storm
    • kafka
    • esper
    • norikra
    • fluentd
  • Lamda Architecture

    • Streaming
    • 速報値
    • Batch
    • 確定値
    • 両方に対応したい
  • Stream処理

    • レイテンシが低い
    • 同じ処理をバッチとしても実行できる必要がある

YARN

  • TD

    • PlazumaDB
    • S3上で動作
    • HDFS is not used
    • Hadoop Cluster
    • Customize hadoop
    • Customize hive
    • Customize Pig
    • PlazumaDB
    • Customize Impala
    • Customize Presto
    • 独自queue
    • 独自scheduler
    • YARN cluster
    • プロダクションにはまだ入れてないが 環境整えている
  • YARNとは

    • Job History Server注意
    • 起動してないと過去ログが追えなくなる
    • NOTE
    • Use the Hadoop 2.4.0 and later

      • Capacity Scheduler、there is a bug
      • deadlock
    • hadoop-conf-pseudo doees not work
    • 2.2.0 and 2.4.0

      • 結構違うので注意

Presto

  • what is Presto

    • Facebookで作られてoss化
    • HDFS上のデータを可視化したい
    • うまくいかない
    • hiveが遅すぎる
    • hiveをバッチ化 => 中間DBに入れる
    • 中間DBはスケールしない
    • HDFSに保存してないものは入れなきゃならない
  • Presto

    • 中間データベースの取り除く有効な手段
    • 他のデータストアを舐めることにも対応
    • Hiveとの使い分けが必要
    • 巨大なjoin
    • group by
    • Interactiveなクエリを発行できる
    • 複数のデータ・セットをまとめて表示できる
  • BI tools

    • 可視化に利用していく
    • ODBC/JDBC is very complicated!
  • Prestoの実行モデルについて

    • not MapReduce
    • 全部並行で動いてる
    • 一個死んだら全部死ぬ
    • メモリー溢れてしまうとクエリが死んでしまう
    • メモリーの使用量はクラスターで管理されて、クラスターが死ぬことはない(はず)
    • がクエリは死ぬ