今日は 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
- セキュリティレイア
- セキュリティの一元管理を可能に
- Spark
【特別講演】IoT時代に向けたHadoopへの期待と責任
- Speaker: 東京大学大学院 情報理工学系研究科教授 江崎 浩氏
- Hadoop に期待するのはオープン性
- セキュリティ、コンプライアンス
- 311 東日本大震災からの 5 つの教訓
- すべての産業が IT/ICT に依存
- データが企業活動の最重要資源
- システムの地理的分散
- 遠隔・移動オフィス環境による BCP
- 日頃動いていないシステムは動かない
- データセンター 第3の波
- インターネット経済
- EC, Search Engine
- クラウド
- ビッグデータ、 IoT、人工知能
- データ処理
- インターネット経済
- IoT
- IP for Everything - 扱うデータ量は膨大
- まだデータ量が小さいところでの IoT の代表例 - コマツ : 建機
- IP for Everything - 扱うデータ量は膨大
- How to use BigData / IoT?
- Objective
- Decision making by data - Data Driven
- Fintech - 今、海外の銀行の人たちと話すと今はこのトピックでもちきり
- カスタマーのアウトリーチがオンラインでドラスティックに変わる
- いまどき銀行にまで足を運ぶのはバカじゃね？という話
- 余談： 311 の災害の裏でグローバルでは金融取引が 2 倍起きていた。
- Fintech - 今、海外の銀行の人たちと話すと今はこのトピックでもちきり
- Decision making by data - Data Driven
- Outputs
- Substainability
- Improvement
- Innovation
- Objective
- 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
- By IT division in companies: In north America
- Off-the-Premiss
- By provider in elsewhere : Japan in 2010s
- including cut of human cost
- By provider in elsewhere : Japan in 2010s
- On the Premisss
- 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
- HW
- Data (Storage) Centric
- Processor/CPU Centric -> Data/Storage centric
- Open & Transparent i.e. whiteXX
- 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
- From Internet by Design
【基調講演１】データエコシステムへの挑戦
- 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.
- Abandance of HW.
- データのためのプラットフォーム 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.
- it possible everyone to adapt it.
- Importance to be OSS.
- 成功には課題がつきもの
- 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.
- Have much functionality but for each need not to become the best.
- 1st challenge: Maturity
- ecosystem is growing very very quickly.
- It is difficult for each existing tools to catch up with those changes.
- ecosystem is growing very very quickly.
- 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
- We have more type of data. Structured data, unstructured data. We need to collaborate those data come together.
- 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.
- Cloudera did much efforts for this.
- 5th challenge: Reliability
- Audit Functionality.
- 6th challenge: Changes.
- Technologies changes.
- new HW, etc...
- Changes of ecosystem of itself.
- Technologies changes.
- Example of SmartPhone.
- 私たちはデータに恒久的な安定をもたらすことができる。
【基調講演２】ビックデータのセキュリティとガバナンス要件
- 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 つのプラットフォームで
- セキュレイティを多くの情報に
- あらゆる環境を調査
- 未知の脅威を検知
- 1 つのプラットフォームで
- セキュリティを多くの情報に Cloudera の違いは
- 手頃なストレージ
- 最小限のデータ移動
- エンタープライズ向けセキュレイティ
- Intel: security optimized for Intel chips.
- 暗号化とキー管理、バックアップ、 DR 、ユーザ認証 etc...
- あらゆるデータ
- 構造・非構造
- さまざまなアクセスフレームワーク
- Discover
- Impala
- Solr
- Model
- SAS
- R
- Spark
- Mahout
- Discover
- リアルタイムモニタリング
- シングルデータソース
- 処理対象となるデータセットは直ちに分析ができるように1つのシステムに配置
- 処理速度
- Impala
- 大規模に高度な分析
- Cloudera のコンプライアンスレディなセキュリティ機能
- Cloudera Manager
- クラスタ本体に対するアクセス防御
- Apache Sentry
- ユーザアクセス管理
- Cloudera Navigator
- データの出処とどのように利用されているかをレポート
- Navigator Encrypt & Key Trustee | Partners
- Cloudera Manager
【基調講演３】パーベイシブ分析を目指して
- Speaker: Cloudera, Inc. 最高技術責任者 Dr.Amr Awadallah 氏
- データ革命がまさに起きようとしている
- 産業革命
- データ革命
- あらゆる産業でデータ革命は起こっている - Web 企業でだけではない
- テレコム
- 金融
- 公共機関
- 小売
- ヘルスケア
- 農業
- あらゆる事業分野でデータ革命は起こっている
- マーケティング
- 営業
- etc..
- なぜ？
- インスツルメンテーション
- 計装できるものは計測できる
- パーソナリゼーション
- ワタシを最優先時代
- アドバンスドアナリシス
- 革新的な企業は実験的で予測的な分析を活用し、迅速な対応を図っている
- インスツルメンテーション
- ビッグデータの要件
- スケール (Scale)
- 技術的にも経済的にも大規模な拡張が必要
- 異なるデータタイプ（ Multi-In ）
- 構造化データ
- 半構造データ
- 非構造データ
- 同じパイプラインで異なるデータ・タイプを処理（ Multi-Out ）
- スケール (Scale)
- Hadoop: スケーラブルでフレキシブルなストレージと処理機能
- アジリティを提供するスマートフォンのようなビッグデータ
- あるべき姿はデータにアプリケーションを提供
- なぜレガシーなデータアーキテクチャでは不十分なのか
- 限定的なデータ
- パフォーマンスの見地でも。
- 限定的なインサイト
- 分析にかかるコストが高い。
- Schema-on-write
- 分析にかかるコストが高い。
- 複雑なアーキテクチャ
- 限定的なデータ
- ビッグデータの取り組み、道のりは厳しい。しかし Cloudera ならサポートできる
- ビッグデータプラットフォーム革命
- 2006 からの歴史
- 20 以上の異なるプロジェクト
- Cloudera Enterprise
- データプラットフォーム
- 無制限のデータを一箇所に
- 業務スピードの向上
- 容易な管理
- 侵害のないセキュアな環境
- データプラットフォーム
- 走る前に歩きなさい
- 安価なストレージ
- ETL/Batch の高速化
- EDW の最適化
- アジャイルなデータソース調査
- SQL を超越する
- パーペイシブ分析
- ビッグデータプラットフォーム革命
- では何をしなければならないか
- 正しいチームを組む
- IT
- 運用、データセキュリティ、 DBA, ETL
- Data Team
- BI、分析、データサイエンス
- ビジネスユーザ
- IT
- 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: 分散処理した結果を集約する
- バラバラにやって集約する、が基本。
- MR: 分散処理
- Hadoop MR vs Spark
- Spark は何が 100 倍速いのか？
- Speed:
- MR の処理
- Hadoop の MR は単純な処理のみ
- 複雑な処理をしたい場合、パイプラインを横に重ねないといけない。
- 処理結果に対して、処理を重ねないといけない。
- また、 Hadoop の場合は耐障害性のために処理の結果を一旦 Disk に書く。
- Disk の読み書きの分がオーバーヘッドになる。
- 処理都度 Java の起動。
- 複雑な処理をしたい場合、パイプラインを横に重ねないといけない。
- Spark の場合はもうすこし柔軟。複雑な処理も可能。
- Spark の場合は複雑な処理がひとつのパイプラインの中で済む。
- 処理途中で Disk に書かない。
- Disk に書かないわけではない。
- Hadoop の MR は単純な処理のみ
- 再帰的な処理でも Hadoop の場合は効率が悪い
- メモリの効果
- CPU と memory の間のデータ転送速度はどんどん高速になってきている。
- 高速な処理
- インメモリキャッシュ
- データ用のパーティションにはディスクのかわりにメモリから読み込む
- グラフ演算 (DAG)
- スケジューリングの最適化
- Fault Tolerance
- インメモリキャッシュ
- ロジスティック回帰のパフォーマンス
- 再帰的な処理なので、 2 回目、3回目と回数を重ねていくとメモリにキャッシュされている分、 Spark のほうが圧倒的に速くなっていく。
- ただし、繰り返し処理が行われないものでは、Hadoop より Spark が圧倒的に速いということはなくなる。
- MR の処理
- 生産性が高い :
- 同一の API で複数の言語をネイティブサポート
- Scala
- Java
- Python
- 対話的な環境が利用できる
- REPL で対話的に記述できる
- REPL: READ-eval-print Loop
- code を書くときに、試して上手くいったら実際に記述するといったことができる
- REPL で対話的に記述できる
- code 量
- MR より 2-5x すくないコード量 e.g. wordcount のコード量
- RDD
- 耐障害性分散データセット
- リネージ
- ブラウザ上で書いた code を Spark で実行
- Hue Notebook
- Jupyter/IPython Notebook
- SparkSQL
- MLlib
- SparkR
- 同一の API で複数の言語をネイティブサポート
- Speed:
- Streaming
- Hadoop MR にはない。 Spark にはある。
- バッチ処理と Streaming
- Hadoop MR はバッチ処理
- 大量のデータを効率的に処理できる
- Spark Streaming
- Spark の Core API を用いて「連続」して処理を実行できる
- マイクロバッチアーキテクチャ
- 短い間隔の計算バッチから構成
- ICU でも利用されている
- Spark Streaming のアーキテクチャ
- データソース
- 取り込みレイア
- Spark Stream 処理
- Hadoop MR はバッチ処理
- Spark は何が 100 倍速いのか？
- Spark は Hadoop を置き換えるのか？
- Hadoop MR は不要か？
- （現時点では） No
- Hadoop の ecosystem で MR のみ対応のもの
- Hive, Pig
- etc...
- この辺の問題が解決されていくと、 Spark による MR の置き換えは進む
- Hadoop MR は不要か？
- まとめ
- Speed
- Easy
- Streaming
- どうやって勉強すんの？
- 書籍あるよ
- Cloudera Developer Blog
- Cloudera Training
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 は使えなかった。
- 業務要件に最適化しすぎた。
- CDH3u0
- データ活用
- パワーユーザの育成
- 各サービスごとに分析担当エンジニアと分析部署が相互に利用
- パワーユーザの育成
- 課題
- Phase2 発展期
- 課題
- ディスク枯渇
- インフラ構成見直しにともなう DC 移設
- DC 間のデータ転送が必要なため帯域を絞りたい
- distocp は当時帯域をしぼれなかった
- 内製アプリケーションの運用負荷
- Hue が充実してきたので移行したかった（この時点ではしてない）
- クラスタ管理
- 手運用から Cloudera Manager へ行きたかった（この時点ではしてない）
- システム
- CDH4.3
- ノード構築作業の自動化
- データ活用
- Hadoop 開発の部署と分析の部署がひとつに
- 内製の可視化基盤
- Python 製のバッチ機構
- Pig + MySQL + Phiny に構成
- 分析環境の整備
- Pig 開発効率の向上
- UDF をまとめた jar ファイル
- 名前と型をつけて書くログをロードする pig マクロ群
- 標準コード規約
- Pig 開発効率の向上
- ユーザの規模 200 人以上
- 新しい施策をうつさいの現状確認
- 打った施策の成果確認
- サービスごとの定常バッチ
- システムのパフォーマンス測定
- 課題
- Phase3 大規模な構成変更 2015-
- 課題
- 運用コスト増大の解消
- 内製アプリケーションからの脱却
- システム構成の見直し
- ラックやサーバ配置、ネットワーク等の最適化
- YRAN 化
- クラスタの再構成
- 別クラスタを Cloudera Manager で構築
- あたらしいものをたてて distocp
- 新旧に同じデータをロードして並行運用
- 別クラスタを Cloudera Manager で構築
- データコピー時での問題
- CDH4 から HDFS ファイルの check sum が変更されていた
- CRC32 から CRC32C になっていた
- CDH4 から HDFS ファイルの check sum が変更されていた
- Cloudera サポートの導入
- 運用コスト増大の解消
- システム
- CDH5.4.1
- NN2 台の HA
- Cloudera Manager
- 内製アプリケーションの整理
- OSS 置き換え
- Hue や Tableau
- 冗長性の担保
- lxc でコンテナ化
- fluentd クラスタによるログの取り込み
- バッチジョブの省力化
- バッチジョブは
- ややこしい処理が多い
- 処理自体の追加や変更も多い
- ジョブ間の依存関係も多く存在する
- バッチジョブは
- ストリーミング基盤の構築
- fluentd クラスタの構築
- リアルタイム集計基盤
- lxc コンテナの上に fluentd/Norikra/InfluxDB/Grafana を 1set として構築
- 各サービスごとに必要なコンテナをたてて分析できるように
- CDH5.4.1
- データ活用
- 分析→可視化プロセスの強化
- 可視化までの手間を削減
- Hive 経由で Tableau による可視化
- 全体のレベル上げ
- Excel で行われていたことを Tableau へ自動化
- 可視化までの手間を削減
- 準エンジニア手当
- 非エンジニア向け
- 準エンジニア試験を受けて合格すると手当がもらえる
- 前回の試験では Pig も範囲に。
- 分析→可視化プロセスの強化
- 課題
- まとめ
- 今後の方向性
- Pig 特有のつらみ
- Pig つらい
- バージョンがあがると、既存のプログラムがまったく動かなくなるということがザラ。
- 0.11 -> 0.12 で生じた主な変更の例
- メタ変数の展開形式が変更
- グローバル変数の導入
- replicated join の動作不具合
- EXEC, RUN コマンドの変数引き渡し
- Spark/Impala への移行
- Pig つらい
- ストリーミングの強化
- スケジューラの強化
- 複数のバッチ間の依存関係
- 各ユーザが勝手に Pig/Hive/Tableau 連携を定義してスケジュール実行できるように
- 長期運用から得た知見
- 初期設計は非常に大事
- 各コンポーネントは疎にしておく
- コンポーネント単位で後から差し替えられるように
- 中途半端に密な内政アプリケーションをつくると後からの OSS 差し替えが非常にツラい。
- データフォーマットは統一しておく
- 一旦社内でひろく使われ始めたログフォーマットを後から変更するのはとてもコストが高い
- ちゃんと初期時点で設計しておく
- 業務プロセスに合わせて中間データをつくりそこでフォーマット変更の差異を吸収する
- 各コンポーネントは疎にしておく
- 運用コストをさげる
- システム内で SPOF はなくす
- 自動化、並列化
- 内製コンポーネントはできるだけ使わない
- まずは既存の MW を探す
- つくるなら OSS の部分と疎になるように切り分ける
- 分析体制の作り方
- パワーユーザを育てる
- 味方をつくる重要性
- まずはスモールに。分析で問題解決ができる部署と協力関係を築いてそこで成果を出す
- 全社展開していくのはある程度スモールな成果がでてから
- サービスレベルは慎重に決める
- 低すぎるとそもそも使ってもらえない
- 高すぎると長期的な運用に差し支えがでる
- 最初は若干低めに現実的な SLA で。後から徐々に上げていくべし。
- パワーユーザを育てる
- 初期設計は非常に大事
- Pig 特有のつらみ
- 今後の方向性
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)
- 開発者のエクスペリエンス向上
- 残された課題
- リニアな拡張性
- フォールトトレランス
- データローカリティベースの処理
- 主な特性
- MR よりも柔軟な汎用処理フレームワーク
- 容易な導入
- Scala, Java, Python
- コードを最小限に抑えるため、クロージャー、イテレーションなど一般的な言語構造を利用
- Easier to read, write.
- Interactive Shell
- On a fly.
- Scala, Java, Python
- 柔軟で拡張性の高い API
- 高速なバッチおよびストリーミング処理
- MR は多くの分野の課題に有効だが (Hive, Pig, Mahout, Crunch, Solr, etc..)
- 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
- 小売
- 広告
- Core Spark
- 分散したフォールトトレラントなキャッシュデータをストアするメモリキャッシュレイア
- RDD
- MR を置き換える Spark
- Cloudera が ecosystem の Spark 移植のコミュニティ開発を推進
- Stage1
- Crunch
- Search
- Stage2
- Hive
- HBase
- Stage3
- Pig
- Sqoop
- Stage1
- Spark と Hadoop の統合 (One Platform Initiative の投資分野)
- 管理
- セキュリティ
- 拡張性 (Scalability)
- 1 万ノード以上のクラスタを可能に
- ストリーミング
- Cloudera が ecosystem の Spark 移植のコミュニティ開発を推進
- One Platform Initiative
- Hadoop データ処理の将来
- 汎用データ処理： Spark
- 分析データベース： Impala
- 全文検索： Solr
- オンディスク処理： MR
- 実業務のために構築された Cloudera
- Hadoop が提供
- 無制限のデータを一箇所から
- 統合マルチフレームワークデータアクセス
- Cloudera が提供
- 優れたパフォーマンス
- エンタープライズ向けセキュリティ機能
- データ管理機能
- シンプルな運用管理機能
- Hadoop が提供
- Spark をはじめるにあたって
- 川崎さんの資料と同じ
個人的所感
のちほど、イベントの内容を思い出しながら、つらつらと書いてみる予定。
各セッション発表資料
セッション資料が公開されていたらこちらにリンクを貼らせてもらう予定。裏番組等で参加できなかったセッションの資料も公開されていたら、自分が読むために貼らせていただく予定。
Spark徹底入門
niconicoにおける継続的なデータ活用のためのHadoop運用事例
基礎から学ぶ超並列SQLエンジンImpala
MapReduceを置き換えるSpark 〜HadoopとSparkの統合〜
サポートの現場からお送りするCloudera Managerを使用した運用とトラブルシューティングガイド
みんなSpark！Spark！と騒いでるけど、ボクが本当のトコロをこっそりお教えします 2015
新製品Kudu及びRecordServiceの概要
Hadoopビッグデータ基盤の歴史を振り返る
LT イベントの発表資料
裏番組的に実施されていた Hadoop コミュニティによる LT イベントの資料、興味はあったんですが、表番組に参加したため自分は参加できなかったので、公開されていたら随時、リンクを貼らせていただく予定。
- CDH ４->５への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 にコントリビュートするまで: 飯島 賢志 / サイバーエージェント
その他リンク
随時更新していくということで、初回はこんなところで。
あわせて読まれたい
- デジタルマーケティングから IoT まで話題てんこ盛りな #devsumi 2015 Autumn に行ってきた
- #OpenStack5Bday 「 OpenStack Summit の歩き方」のレポート
- #ChugokuDB MyNA/JPUG 合同DB勉強会 in 東京 に行ってきた #メモ #レポート #MySQL #PostgreSQL
- #ichigayageek 愛の貧乏大作戦！ケチケチビッグデータ節約術に参加してきました #メモ #レポート
- #dbts2015 #E16 #分散トランザクション の現在 - 分散トランザクションを中心として。あと #Spark の話を少しのメモ
*1:強いコミットメントを感じました
