#garagekidztweetz

読者です 読者をやめる 読者になる 読者になる

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

Cloudera、Hadoop MRのecosystemの #Spark 移植を推進するってよ!: #cwt2015 に参加してきたメモ

スポンサーリンク

今日は Cloudera World Tokyo 2015 に参加してきました。

タイトルのとおり、Cloudera さんの大絶賛 Spark 推し*1ということが前面におされているイベントだったのかなぁというのが個人的に強く印象に残ったイベントでした。

以下、今回のわたしのレポートのコンテンツ。

個人的には、わたしが参加した中では、基調講演中の特別講演の江崎教授のお話と、 niconico の事例の話が聞き応えがありました。

では、以降に各セッションのメモを公開します。

10:00 - 12:20 基調講演

  • 1 億ドル OSS 企業
    • 1 社目、 Redhat, 2 社目 Cloudera
  • ビジネス価値を生む3つの領域が注目
    • 顧客 - 360 度情報をいかに取得して、いかに活用するか
    • サービス - Data Driven, いかに低コストにおさえるか
    • リスクマネジメント - セキュリティ、コンプライアンス
  • Cloudera の提案
    • Spark
      • MR に取ってかわる
    • Kudu
      • HDFS にかわる Storage layer
    • セキュリティレイア
      • セキュリティの一元管理を可能に
【特別講演】IoT時代に向けたHadoopへの期待と責任
  • Speaker: 東京大学大学院 情報理工学系研究科教授 江崎 浩氏
  • Hadoop に期待するのはオープン性
    • セキュリティ、コンプライアンス
  • 311 東日本大震災からの 5 つの教訓
    • すべての産業が IT/ICT に依存
    • データが企業活動の最重要資源
    • システムの地理的分散
    • 遠隔・移動オフィス環境による BCP
    • 日頃動いていないシステムは動かない
  • データセンター 第3の波
    • インターネット経済
      • EC, Search Engine
    • クラウド
    • ビッグデータ、 IoT、人工知能
      • データ処理
  • IoT
    • IP for Everything - 扱うデータ量は膨大
      • まだデータ量が小さいところでの IoT の代表例 - コマツ : 建機
  • How to use BigData / IoT?
    • Objective
      • Decision making by data - Data Driven
        • Fintech - 今、海外の銀行の人たちと話すと今はこのトピックでもちきり
          • カスタマーのアウトリーチがオンラインでドラスティックに変わる
          • いまどき銀行にまで足を運ぶのはバカじゃね?という話
          • 余談: 311 の災害の裏でグローバルでは金融取引が 2 倍起きていた。
    • Outputs
      • Substainability
      • Improvement
      • Innovation
  • BigData 解析
    利益率は下にいくほど向上。
    • 事業継続
    • 効率化・品質向上
    • 新機能・新サービス
  • ネットワークトポロジの変化
    • 階層化構造のさらなる進展
    • CSP の ISP 化
    • プライベートピアリングの増加
    • CDN
    • Off-the-Premise の進展
      • キャンパス内にあったものをキャンパスの外へ
  • 国外 ISP 等と交換されるトラフィック
    • 国外から国内に入ってくるトラフィックは上がり、出て行く量は減っている
      • 日本国内にデータが溜まっていっている
      • ローカルなコンテンツを海外に持ち出すバカはいないということ。
        • ローカルなものはローカルで活用しよう
  • Where we install computers, on-the-premise or off-the-premiss?
    北米ではすでに使い分けになってきている。なんでも AWS なんてことはない。
    • On the Premisss
      • By IT division in companies: In north America
        • DC for themselves and by themselves
    • Off-the-Premiss
      • By provider in elsewhere : Japan in 2010s
        • including cut of human cost
  • What have happened in Back end
    • Virtulization
    • Portable/ Mobility / Migration
    • Collocate-ability
  • 仮想化の効果 - スマート化
    • 時間と空間の制約がなくなってきた
      • ハードインフラからの開放
        • Portability
        • Collocate-ability
        • Platform Setup
      • プロセッサーをデータの近くにもっていって処理をするようになってきている
        • データの移動は難しい
        • たかだか数GBの仮想マシンイメージを100GBクラスのネットワークで転送するのは屁でもないが、PBクラスのストレージのデータを転送するのはしんどい、だったら仮想マシンをデータのほうに転送してから処理すればいいじゃない、という発想。
  • Innovations in DC architecture
    • Open & Transparent i.e. whiteXX
      • HW
        • chip, board, server, switch, etc...
      • SW
    • Data (Storage) Centric
      • Processor/CPU Centric -> Data/Storage centric
  • DC サービスの変化
    ロックインが起きないようにするにはオープン化
    • Housing
    • Hosting
    • Cloud Platform
      • IaaS
      • PaaS
      • SaaS
      • XaaS
  • 多様な DC
    複数の DC, Providers の連携。誰かに全部を預けて処理をするというのはコストに見合わない。
    • 共通点
      • サービスの継続性
      • エネルギー効率
      • 運用効率
    • 相違点
      • サービスの信頼度
      • マルチテナンシー
  • Conclusion
    • From Internet by Design
      • Open
      • Transparent
      • Alternative for improvement and innovation
    • Security and Privacy by Design
    • Data Centric Architecture
    • SW Defined/Centric System
【基調講演1】データエコシステムへの挑戦
  • Speaker: Cloudera, Inc. チーフアーキテクト Doug Cutting 氏
  • データが主役の時代がやってきた。
    • Abandance of HW.
      • Affordablity.
      • Performance Improvements.
        • Computers are adapted in many industries (Agriculture, healthcare etc...). Those push this improvements.
    • SW
      • Creating SW with lower costs.
  • データのためのプラットフォーム Apache Hadoop ecosystem.
    • Importance to be OSS.
      • it possible everyone to adapt it.
        • That's why Hadoop he developped.
        • And that's why it is OSS, so spread used by all over the world.
  • 成功には課題がつきもの
    • Example of SmartPhone.
      • Have much functionality but for each need not to become the best.
        • Everyone using SP for camera because everyone everytime bring it.
    • 1st challenge: Maturity
      • ecosystem is growing very very quickly.
        • It is difficult for each existing tools to catch up with those changes.
    • 2nd challenge: Talent
      • Everyone have to familier with new technologies (but this is also difficult).
      • Tools are also need to adapt new changes.
      • There are already many people well known their business.
        • They are need to learn new tools.
    • 3rd challenge: Complexity of the systems.
      • We have more type of data. Structured data, unstructured data. We need to collaborate those data come together.
        • Sometimes need Common Data Formats.
      • Variety of tools also make data complicated.
        • Machine learning tools
        • Search engine
        • ETL tools
    • 4th challenge: Security
      • Cloudera did much efforts for this.
        • At the beginning of Hadoop, there is no limits, anyone can read anyone can write.
      • Encription.
    • 5th challenge: Reliability
      • Audit Functionality.
    • 6th challenge: Changes.
      • Technologies changes.
        • new HW, etc...
      • Changes of ecosystem of itself.
  • 私たちはデータに恒久的な安定をもたらすことができる。
【基調講演2】ビックデータのセキュリティとガバナンス要件
  • Speaker: Cloudera, Inc. プロダクトマーケティング シニアディレクター Clarke Patterson 氏
  • Every industires have risks to be security attacked.
    • Every organizations need to think about security. To protect each of his company.
  • 組織を守るには新しい呪法戦略が不可欠
  • Cloudera の情報セキュリティのためのエンタープライズデータハブ
    • 1 つのプラットフォームで
      • セキュレイティを多くの情報に
      • あらゆる環境を調査
      • 未知の脅威を検知
  • セキュリティを多くの情報に Cloudera の違いは
    • 手頃なストレージ
    • 最小限のデータ移動
    • エンタープライズ向けセキュレイティ
      • Intel: security optimized for Intel chips.
      • 暗号化とキー管理、バックアップ、 DR 、ユーザ認証 etc...
    • あらゆるデータ
      • 構造・非構造
    • さまざまなアクセスフレームワーク
      • Discover
        • Impala
        • Solr
      • Model
        • SAS
        • R
        • Spark
        • Mahout
    • リアルタイムモニタリング
    • シングルデータソース
      • 処理対象となるデータセットは直ちに分析ができるように1つのシステムに配置
    • 処理速度
      • Impala
    • 大規模に高度な分析
  • Cloudera のコンプライアンスレディなセキュリティ機能
    • Cloudera Manager
      • クラスタ本体に対するアクセス防御
    • Apache Sentry
      • ユーザアクセス管理
    • Cloudera Navigator
      • データの出処とどのように利用されているかをレポート
    • Navigator Encrypt & Key Trustee | Partners
【基調講演3】パーベイシブ分析を目指して
  • Speaker: Cloudera, Inc. 最高技術責任者 Dr.Amr Awadallah 氏
  • データ革命がまさに起きようとしている
    • 産業革命
    • データ革命
  • あらゆる産業でデータ革命は起こっている - Web 企業でだけではない
    • テレコム
    • 金融
    • 公共機関
    • 小売
    • ヘルスケア
    • 農業
  • あらゆる事業分野でデータ革命は起こっている
    • マーケティング
    • 営業
    • etc..
  • なぜ?
    • インスツルメンテーション
      • 計装できるものは計測できる
    • パーソナリゼーション
      • ワタシを最優先時代
    • アドバンスドアナリシス
      • 革新的な企業は実験的で予測的な分析を活用し、迅速な対応を図っている
  • ビッグデータの要件
    • スケール (Scale)
      • 技術的にも経済的にも大規模な拡張が必要
    • 異なるデータタイプ( Multi-In )
      • 構造化データ
      • 半構造データ
      • 非構造データ
    • 同じパイプラインで異なるデータ・タイプを処理( Multi-Out )
  • Hadoop: スケーラブルでフレキシブルなストレージと処理機能
  • アジリティを提供するスマートフォンのようなビッグデータ
    • あるべき姿はデータにアプリケーションを提供
  • なぜレガシーなデータアーキテクチャでは不十分なのか
    • 限定的なデータ
      • パフォーマンスの見地でも。
    • 限定的なインサイト
      • 分析にかかるコストが高い。
        • Schema-on-write
    • 複雑なアーキテクチャ
  • ビッグデータの取り組み、道のりは厳しい。しかし Cloudera ならサポートできる
    • ビッグデータプラットフォーム革命
      • 2006 からの歴史
      • 20 以上の異なるプロジェクト
      • Cloudera Enterprise
        • データプラットフォーム
          • 無制限のデータを一箇所に
        • 業務スピードの向上
        • 容易な管理
        • 侵害のないセキュアな環境
      • 走る前に歩きなさい
        • 安価なストレージ
        • ETL/Batch の高速化
        • EDW の最適化
        • アジャイルなデータソース調査
        • SQL を超越する
        • パーペイシブ分析
  • では何をしなければならないか
    • 正しいチームを組む
      • IT
        • 運用、データセキュリティ、 DBA, ETL
      • Data Team
        • BI、分析、データサイエンス
      • ビジネスユーザ
    • 1 つにまとめる
      • アジャイルな処理ステージ
      • データ処理
      • ユーザアクセス
  • まとめ
    • テクノロジーの変化であると同時に文化の変化
    • はじめはゆっくりと、歩いて、それから走りましょう
    • 時間がかかりますが、今すぐ始めましょう。
    • 専門家から学びましょう。

13:50 - 14:20 Spark徹底入門

  • Speaker: Cloudera株式会社 テクニカルディレクター 川崎達夫氏
  • Spark どこに興味?
    • 速い
    • リアルタイム処理
    • Run programs up to 100x faster than Hadoop MR in memory or 10x faster on disk. spark.apache.org
      • 人と新幹線くらい違う?!
  • 汎用的なクラスタ計算システム
    • Spark と MR は位置的には同じ立ち位置
  • MR も Spark も分散処理
    • MR: 分散処理
      • バラバラにやって集約する、が基本。
        • Map: 分散されたデータをそれぞれのサーバで処理をする
        • Reduce: 分散処理した結果を集約する
  • Hadoop MR vs Spark
    • Spark は何が 100 倍速いのか?
      • Speed:
        • MR の処理
          • Hadoop の MR は単純な処理のみ
            • 複雑な処理をしたい場合、パイプラインを横に重ねないといけない。
              • 処理結果に対して、処理を重ねないといけない。
              • また、 Hadoop の場合は耐障害性のために処理の結果を一旦 Disk に書く。
                • Disk の読み書きの分がオーバーヘッドになる。
              • 処理都度 Java の起動。
          • Spark の場合はもうすこし柔軟。複雑な処理も可能。
            • Spark の場合は複雑な処理がひとつのパイプラインの中で済む。
            • 処理途中で Disk に書かない。
              • Disk に書かないわけではない。
        • 再帰的な処理でも Hadoop の場合は効率が悪い
        • メモリの効果
          • CPU と memory の間のデータ転送速度はどんどん高速になってきている。
        • 高速な処理
          • インメモリキャッシュ
            • データ用のパーティションにはディスクのかわりにメモリから読み込む
          • グラフ演算 (DAG)
            • スケジューリングの最適化
            • Fault Tolerance
        • ロジスティック回帰のパフォーマンス
          • 再帰的な処理なので、 2 回目、3回目と回数を重ねていくとメモリにキャッシュされている分、 Spark のほうが圧倒的に速くなっていく。
          • ただし、繰り返し処理が行われないものでは、Hadoop より Spark が圧倒的に速いということはなくなる。
      • 生産性が高い :
        • 同一の API で複数の言語をネイティブサポート
          • Scala
          • Java
          • Python
        • 対話的な環境が利用できる
          • REPL で対話的に記述できる
            • REPL: READ-eval-print Loop
            • code を書くときに、試して上手くいったら実際に記述するといったことができる
        • code 量
          • MR より 2-5x すくないコード量 e.g. wordcount のコード量
        • RDD
          • 耐障害性分散データセット
          • リネージ
        • ブラウザ上で書いた code を Spark で実行
          • Hue Notebook
          • Jupyter/IPython Notebook
        • SparkSQL
        • MLlib
        • SparkR
    • Streaming
      • Hadoop MR にはない。 Spark にはある。
      • バッチ処理と Streaming
        • Hadoop MR はバッチ処理
          • 大量のデータを効率的に処理できる
        • Spark Streaming
          • Spark の Core API を用いて「連続」して処理を実行できる
          • マイクロバッチアーキテクチャ
            • 短い間隔の計算バッチから構成
            • ICU でも利用されている
          • Spark Streaming のアーキテクチャ
            • データソース
            • 取り込みレイア
            • Spark Stream 処理
  • Spark は Hadoop を置き換えるのか?
    • Hadoop MR は不要か?
      • (現時点では) No
    • Hadoop の ecosystem で MR のみ対応のもの
      • Hive, Pig
      • etc...
    • この辺の問題が解決されていくと、 Spark による MR の置き換えは進む
  • まとめ
    • Speed
    • Easy
    • Streaming
  • どうやって勉強すんの?

14:35 - 15:15 niconicoにおける継続的なデータ活用のためのHadoop運用事例

  • Speaker: 株式会社ドワンゴ ニコニコ事業統括本部 プラットフォーム事業本部 共通基盤開発部 数値基盤セクション セクションマネージャ 志村 誠氏
  • niconico 事業は dwango 傘下
    • MAU 800-900 万人
    • ひとりの滞在時間が長い
    • 1-20 代が大半
  • データ活用の方針
    • 必要な人が誰でも分析できるようにすることが目標
      • エンジニアに限らず
      • 分析部署だけでは社内の全部署のニーズを満たすことは不可能
      • 業務で必要な人が学習して自分でできるように
    • サービスを横断した分析の必要性
      • niconico では数多くのファミリーサービス
      • 何もしなければそれらが縦割りになってしまう
      • それを横串でできるように
  • 201511 時点のシステム構成
    • ポイント
      • Web フロント経由でのアクセス
      • システム間は API
      • CI 環境
      • 仮想化によるアプリケーションサーバの冗長性
      • 統一されたフォーマットでログの自動取得
      • ...
  • Phase1 導入期 2011-13
    • 課題
      • 統一データ基盤の必要性
    • システム
      • CDH3u0
        • SPOF
      • ディスクの枯渇
      • 運用
        • マニュアル運用
      • Pig
        • サービスごとにビジネスロジックが入り込んでいてアドホックな前処理が多数発生
        • 仕様変更が数多く発生するため、 Hive テーブルを定義するのが難しかった
      • 内製 Web フロント
        • 各サービスごとの企画担当者が直接ふれることを想定。当時の Hue は使えなかった。
        • 業務要件に最適化しすぎた。
    • データ活用
      • パワーユーザの育成
        • 各サービスごとに分析担当エンジニアと分析部署が相互に利用
  • Phase2 発展期
    • 課題
      • ディスク枯渇
      • インフラ構成見直しにともなう DC 移設
        • DC 間のデータ転送が必要なため帯域を絞りたい
        • distocp は当時帯域をしぼれなかった
      • 内製アプリケーションの運用負荷
        • Hue が充実してきたので移行したかった(この時点ではしてない)
      • クラスタ管理
        • 手運用から Cloudera Manager へ行きたかった(この時点ではしてない)
    • システム
      • CDH4.3
      • ノード構築作業の自動化
    • データ活用
      • Hadoop 開発の部署と分析の部署がひとつに
      • 内製の可視化基盤
        • Python 製のバッチ機構
        • Pig + MySQL + Phiny に構成
      • 分析環境の整備
        • Pig 開発効率の向上
          • UDF をまとめた jar ファイル
          • 名前と型をつけて書くログをロードする pig マクロ群
          • 標準コード規約
      • ユーザの規模 200 人以上
        • 新しい施策をうつさいの現状確認
        • 打った施策の成果確認
        • サービスごとの定常バッチ
        • システムのパフォーマンス測定
  • Phase3 大規模な構成変更 2015-
    • 課題
      • 運用コスト増大の解消
        • 内製アプリケーションからの脱却
      • システム構成の見直し
        • ラックやサーバ配置、ネットワーク等の最適化
        • YRAN 化
        • クラスタの再構成
          • 別クラスタを Cloudera Manager で構築
            • あたらしいものをたてて distocp
          • 新旧に同じデータをロードして並行運用
        • データコピー時での問題
          • CDH4 から HDFS ファイルの check sum が変更されていた
            • CRC32 から CRC32C になっていた
      • Cloudera サポートの導入
    • システム
      • CDH5.4.1
        • NN2 台の HA
        • Cloudera Manager
      • 内製アプリケーションの整理
        • OSS 置き換え
        • Hue や Tableau
      • 冗長性の担保
        • lxc でコンテナ化
        • fluentd クラスタによるログの取り込み
      • バッチジョブの省力化
        • バッチジョブは
          • ややこしい処理が多い
          • 処理自体の追加や変更も多い
          • ジョブ間の依存関係も多く存在する
      • ストリーミング基盤の構築
        • fluentd クラスタの構築
        • リアルタイム集計基盤
          • lxc コンテナの上に fluentd/Norikra/InfluxDB/Grafana を 1set として構築
          • 各サービスごとに必要なコンテナをたてて分析できるように
    • データ活用
      • 分析→可視化プロセスの強化
        • 可視化までの手間を削減
          • Hive 経由で Tableau による可視化
        • 全体のレベル上げ
          • Excel で行われていたことを Tableau へ自動化
      • 準エンジニア手当
        • 非エンジニア向け
        • 準エンジニア試験を受けて合格すると手当がもらえる
          • 前回の試験では Pig も範囲に。
  • まとめ
    • 今後の方向性
      • Pig 特有のつらみ
        • Pig つらい
          • バージョンがあがると、既存のプログラムがまったく動かなくなるということがザラ。
          • 0.11 -> 0.12 で生じた主な変更の例
            • メタ変数の展開形式が変更
            • グローバル変数の導入
            • replicated join の動作不具合
            • EXEC, RUN コマンドの変数引き渡し
        • Spark/Impala への移行
      • ストリーミングの強化
      • スケジューラの強化
        • 複数のバッチ間の依存関係
        • 各ユーザが勝手に Pig/Hive/Tableau 連携を定義してスケジュール実行できるように
      • 長期運用から得た知見
        • 初期設計は非常に大事
          • 各コンポーネントは疎にしておく
            • コンポーネント単位で後から差し替えられるように
            • 中途半端に密な内政アプリケーションをつくると後からの OSS 差し替えが非常にツラい。
          • データフォーマットは統一しておく
            • 一旦社内でひろく使われ始めたログフォーマットを後から変更するのはとてもコストが高い
            • ちゃんと初期時点で設計しておく
            • 業務プロセスに合わせて中間データをつくりそこでフォーマット変更の差異を吸収する
        • 運用コストをさげる
          • システム内で SPOF はなくす
          • 自動化、並列化
          • 内製コンポーネントはできるだけ使わない
            • まずは既存の MW を探す
            • つくるなら OSS の部分と疎になるように切り分ける
        • 分析体制の作り方
          • パワーユーザを育てる
            • 味方をつくる重要性
            • まずはスモールに。分析で問題解決ができる部署と協力関係を築いてそこで成果を出す
            • 全社展開していくのはある程度スモールな成果がでてから
          • サービスレベルは慎重に決める
            • 低すぎるとそもそも使ってもらえない
            • 高すぎると長期的な運用に差し支えがでる
            • 最初は若干低めに現実的な SLA で。後から徐々に上げていくべし。

15:40 - 16:20 MapReduceを置き換えるSpark 〜HadoopとSparkの統合〜

  • Speaker: Cloudera, Inc. Chief Architect & Co-Creator of Hadoop Doug Cutting 氏
  • Apache Spark の歴史
    • MR は多くの分野の課題に有効だが (Hive, Pig, Mahout, Crunch, Solr, etc..)
      • 限定的な表現力/プログラミングの難しさ
      • 設計に起因するパフォーマンスの限界
    • しかし望むらくは * 改善できる方法がある
      • 特定用途システム
        • Giraph/Graphlab, Impala
      • 汎用化した MR 機能
        • Harma, Dryad
    • Apache Spark の登場
      • MR よりも柔軟な汎用処理フレームワーク
        • 主な特性
          • 分散メモリ
          • データ並列処理のための全方位グラフ表現 (Full Directed Graph expressions)
          • 開発者のエクスペリエンス向上
        • 残された課題
          • リニアな拡張性
          • フォールトトレランス
          • データローカリティベースの処理
    • 容易な導入
      • Scala, Java, Python
        • コードを最小限に抑えるため、クロージャー、イテレーションなど一般的な言語構造を利用
        • Easier to read, write.
      • Interactive Shell
        • On a fly.
    • 柔軟で拡張性の高い API
    • 高速なバッチおよびストリーミング処理
  • Spark の優位点
    • RDD
      • 分散したフォールトトレラントなキャッシュデータをストアするメモリキャッシュレイア
        • Spark のエコシステムと Hadoop
        • Spark Streaming
        • MLlib
        • SparkSQL
        • GraphX
        • Data-frames
        • SparkR
      • Cloudera における Spark
        • Spark をサポートした最初の Hadoop ベンダー
        • Cloudera プラットフォームに完全統合
        • トレーニングを提供している最初のベンダー
        • エンジニアリソースを他社比 5 倍投入
          • コミッター数
            • IBM, MapR はゼロ
          • パッチ提供数
      • Cloudera のカスタマー
        • 150 以上のカスタマー
        • 800 クラスター
        • 活用事例
          • Core Spark
            • 金融
            • HealthCare
            • ERP
            • データサービス
          • Spark Streaming
            • 金融
            • HealthCare
            • 小売
            • 広告
  • MR を置き換える Spark
    • Cloudera が ecosystem の Spark 移植のコミュニティ開発を推進
      • Stage1
        • Crunch
        • Search
      • Stage2
        • Hive
        • HBase
      • Stage3
        • Pig
        • Sqoop
    • Spark と Hadoop の統合 (One Platform Initiative の投資分野)
      • 管理
      • セキュリティ
      • 拡張性 (Scalability)
        • 1 万ノード以上のクラスタを可能に
      • ストリーミング
  • One Platform Initiative
  • Hadoop データ処理の将来
    • 汎用データ処理: Spark
    • 分析データベース: Impala
    • 全文検索: Solr
    • オンディスク処理: MR
  • 実業務のために構築された Cloudera
    • Hadoop が提供
      • 無制限のデータを一箇所から
      • 統合マルチフレームワークデータアクセス
    • Cloudera が提供
      • 優れたパフォーマンス
      • エンタープライズ向けセキュリティ機能
      • データ管理機能
      • シンプルな運用管理機能
  • Spark をはじめるにあたって
    • 川崎さんの資料と同じ

個人的所感

のちほど、イベントの内容を思い出しながら、つらつらと書いてみる予定。

各セッション発表資料

セッション資料が公開されていたらこちらにリンクを貼らせてもらう予定。裏番組等で参加できなかったセッションの資料も公開されていたら、自分が読むために貼らせていただく予定。

Spark徹底入門

niconicoにおける継続的なデータ活用のためのHadoop運用事例

基礎から学ぶ超並列SQLエンジンImpala

MapReduceを置き換えるSpark 〜HadoopとSparkの統合〜

サポートの現場からお送りするCloudera Managerを使用した運用とトラブルシューティングガイド

みんなSpark!Spark!と騒いでるけど、ボクが本当のトコロをこっそりお教えします 2015

新製品Kudu及びRecordServiceの概要

Hadoopビッグデータ基盤の歴史を振り返る

LT イベントの発表資料

裏番組的に実施されていた Hadoop コミュニティによる LT イベントの資料、興味はあったんですが、表番組に参加したため自分は参加できなかったので、公開されていたら随時、リンクを貼らせていただく予定。

  • CDH 4->5へのUPDATE苦労話: 山田 雄 / リクルートライフスタイル
  • HDFS新機能総まとめ in 2015: 鯵坂 明 / NTTデータ, Hadoopコミッタ
  • HDFS Erasure Codingの実装と工夫: 佐々木 海 / TreasureData K.K.
  • Amebaのログ転送管理システムMineとその活用について: 斎藤 貴文 / サイバーエージェント
  • もっともっとHadoopを使ってみよう! Hadoop活用の裾野を広げるオラクルの取り組みご紹介!: 立山 重幸 / 日本オラク
  • Big Data and Geo Analytics: 髙瀬 啓司 / ESRIジャパン
  • 初心者向けSparkの入門: 土橋 昌 / NTTデータ
  • Spark Streamingで作る、つぶやきビッグデータのクローン: 野田 純一 / 秋葉原IT戦略研究所
  • hivemall-on-sparkの紹介とApache SparkにおけるHiveUDF系IFの対応状況: 山室 健
  • Spark Summit Europeに行ってきたのでポイントをご紹介: 土橋 昌 / NTTデータ
  • Running Kudu - how does it work on MapReduce framework?: Tsuyoshi Ozawa / Apache Software Foundation
  • Introducing Apache Yetus: 関 堅吾 / NTTデータ
  • HTrace 4の紹介: 岩崎 正剛 / NTTデータ, HTraceコミッタ
  • Relationship between JDK and Hadoop: Tsuyoshi Ozawa / Apache Software Foundation
  • MetricsSinkを書いてみた: 岩崎 正剛 / NTTデータ
  • 機械学習アルゴリズムがよくわからなくても大丈夫 ~Sparkを用いたビッグデータ機械学習の自動化~: 上田 晴康 / 富士通研究所
  • Hadoopのメンテナンスバージョンをリリースしてみた: 鯵坂 明 / NTTデータ, Hadoopコミッタ
  • 社内で使っていた Taildir を Apache Flume にコントリビュートするまで: 飯島 賢志 / サイバーエージェント

その他リンク

随時更新していくということで、初回はこんなところで。

あわせて読まれたい

*1:強いコミットメントを感じました