11月17日、Data Engineering Conference 2015に行ってきた。
その内容をメモメモ
なお、
・一部分かっていない
・その前に眼科にいき、目薬を打ったため＆会場は後ろの席だったため
スクリーンの文字は全く見えない
・途中からさんか
ので、テキトーにメモッっている。なので、一部間違っているところや
抜けてしまって意味通じないところもあると思うが、ご容赦願いたい。
※表題の件は、最後のパネルディスカッションの中で
（実際には、ノーチラステクノロジーズの神林氏が説明）
■AI（人工知能）の全体像－その歴史と現状、今後の展望
（途中から）
・統計確率型AI
事前確率：適当に決める
やってみる：ベイズの法則
事後確率→事前確率として戻る
・ロボットに応用→カルマンフィルタ→自動運転
センサーの値
ベイズ
結果→もどす
・現実世界：正規分布でない→同じキケン、限界
・脳科学：認識
→ディープラーニング、ディープニューラルネット
ブレイクスルー
GPU
ニューラル リワイヤリング：脳の回路をつなぎ変えても作用→脳に汎用性が在る
スパースコーディング
画像が音声にも使える
ロボット：非常に難しい→外界認識に
軍事転用の可能性
■きちんと知りたいApache Spark～機械学習とさまざまな機能群
発表資料はスライドシェア
聴講者層：機械学習初学者
ゴール；ＡＰＩが実践を意識している
Apache Sparkは３つに対応
バッチ処理
リアルタイム
インタラクティブ
Ｓｃａｌａ
Ｊａｖａ
Ｐｙｔｈｏｎ
Ｒ
機械学習ライブラリ
Sparkサポート
HDFS
AWS S3
Hive
JSON
HBASE接続ライブラリも
Ｓｐａｒｋ．ＭＬＬｉｂ
機械学習を簡単に
アルゴリズム
よく知られている
論文がある
スケールする
コンシステンシーを持たせる
クラシフィケーション
回帰分析
クラスタリング
レコメンド
データ読み込み
モデル
予測
ベンチマーク
Ａｍａｚｏｎ １０秒かからないでモデル構築
データフレームＡＰＩ
・ラッパーＡＰＩ
よくつかわれる機能をＤＳＬで
じかにＳＱＬ記述もできる
・関数多数、ユーザー定義も
・つかったほうがはやい
パイプラインＡＰＩ
・ＭＬパイプライン→ＤａｒaFrameを通してアクセス
・データ形式 フューチャーエクストラクションにかける
・パイプライン定義、データを放り込む
・流れ
訓練用データ、：モデル構築 テスト用データ適用
パラメーターチューニング
オーバーフィッティング→クロスバリデーション
パイプラインに対しモデル保存、再利用
Advaiced analysis with spark
■Sparkがもたらすビジネス革新ーデータドリブン・ソリューションの迅速な展開ー
Ｓｐａｒｋ ＩＢＭ昔から注目
システム３６０ 十分な速度ではない ランドマーク
一つのＯＳ
周辺的なソリューション
開発者集結
Ｌｉｎｕｘ
新しいＯＳ
サーバー、ＰＣ，でアプリ構築→コンピューターサイエンス
１３００万コード
インターネット
Ｓｐａｒｋ
次世代データアナリティクスＯＳ
→５０万業務コード
１．速度
２．表現力
→Ｌｉｎｕｘと比較
どのようなシステムでも対応できる
→コグニティブアプリケーション
高速な反復
横断的
ポイントをまとめた
プログラムバックグラウンド必要ない
数百万で提供
Ｓｐａｒｋ Ａｓ Ａ Ｓｅｒｖｉｃｅとして
Ｓｙｓｔｅｍ ＭＬ：マシンラーニングエンジン WATSON
オープンソーステクノロジ
コミニティとコントリビューション
インキュベーターとして
宣言的
Ｓｐａｒｋ ａｓ ａ ｓｅｒｖｉｃｅ
→Blue Mixで：他のサービスとも合わせて
天候の予測：Ｓｐａrkつかってから成功
家具店；クライアントのエンゲージメント
IoT：からだ、自転車、風力・・・・
投資：Ｈａｄｏｏｐにも
→とってかわるのか？：Ｎｏ
相当の投資
ＢｉｇＩｎｓｉｇｈｔ
ＭａｐＲｅｄｕｃｅ
多くのプロジェクト進行中
ＢｉｇＳＱＬ
従来の知識で良い
ＢＩＧ Ｒ
Ｈａｄｏｏｐの中核
オープンデータプラットフォーム
ＩＢＭ Ｂｉｇ Ｉｎｓｉｇｈｔ クラウド
サーバーのプロビジョン
おきゃくさまのリスト
主要なケーパビリティ：ストリーム
６０％以上のユーザー
ストリーミングコンピューティング
マイクロストリーミング
完全なストリーミング
新しいサービス
地理空間アナリティクス
ストリーミング
まとめ
表を作った
大量ＶＳ高速
小規模でスピード遅ければＭｙＳQL,DB2でも
堅牢なアナリティクスプラットフォーム
■SystemMLによる機械学習について
機械学習
ＳｙｓｔｅｍＭＬ
おぷティマイザ
ＳｙｓｔｅｍＭＬ
概要を話す
２０１０年から
どういうニーズがあるか
例：車の買い替え：アルゴリズム
→データポイント不十分
アルゴリズムのカスタム化だいじ
データセットも変わってくる
さまざまなアナリティクス要件
・上層部のセマンティック
・アルゴリズムの柔軟性
・データに依存しない、
・スケーラブル（独立性）
データサイエンティスト
Ｒ
Ｐｙｔｈｏｎで作成
→ＢｉｇＤａｔａもんだい
問題
・データサイエンティスト
反復的にプログラム書く
・データの最適化技術
Ｒ，Ｐｙｔｈｏｎ
→ターゲットプラットフォームかんがえなくていい
Ｓｐａｒｋ：ＲＤＤ
スタンディングエクスキューたー
ＳｙｓｔｅｍＭＬ
・回帰の例
マトリクスマルティぷレーション
・ロジスティック回帰
・直線的回帰
・データポイントの事例
５００のフィーチャー→フィーチャーをふやす
マルティプレっくすの演算子使えない→べつの演算子
→オプティマイザに処理させる
ほっぷ→データ特性：インストラクション
ろっぷ
データサイズによる違い
パターンマッチング：コモンパターン
ロイテッドスクエアードロス
ヒューズドオペレータ
Ｓ－ｐｒｏｐ－Ｐ
まとめ
・宣言的
■Beyond Shuffling-tips ＆ tricks for scaling Apache Spark
いろんなレベルで永続化できる
→キャッシングだけでは十分ではない：メモリに入りきらない
シェアードクラスタ
他の人が使っている場合、キャッシュ使えない（再演算）
チェックポイント機能
きーえすきゅー
キーの分散均等にならない問題
→処理の中断
→再パーティション必要になってくる
→Ｇｒｏｕｐ Ｂｙ ｋｅｙが悪
ＳＱＬ環境では問題ない
リリースバイキー
アグリケートバイキー→最適化できる
ソーティングの問題
Ｓｐａｒｋのアキュムレーター
予想性は高くないけど、それゆえにいいことがある
SparkSQL
ＳＱＬのためだけではない。
構造化、半構造化によい
→λファンクションより
エラーフリーなコード：書かれないコード
Sparkに機械学習
コードジェネレーション：まだまだ
spark10387
Tree reduce,Tree アグリゲーション
プログラミングガイド見てね！
spark.tc
■パネルディスカッション
アプリ・サービス開発者が学ぶべきデータアーキテクチャはこれだ！
データ活用がテーマ
・ロータスNotes：ドキュメント指向型データベース
→ＫＶＳに毛が生えたもの
Ｐ２Ｐがたグループウェア
ありるねっとわーくす→ワークスアプリケーションに買収される
ワークスアプリケーション：パッケージベンダー ＥＲＰ
HUE(ひゅー）がおもしろい
→０．１秒というパフォーマンス
HUE：カンパニーフォーラムで
・プログラム言語
ＪＶＭ
Ｓｐａｒｋ
→チューニング
・分散業務系しかやっていない
→Hadoop,Spark
さくらインターネット Hadoop→Spark
バッチ系：メインフレームより早い→１０倍出る
オンラインの分散処理：グリッド→メニ―コア
Hadoopやってる人は、Sparkすぐやったほうがいい
Hadoopはすべての面でおそい
１ペタバイトのＧｒｏｕｐ ＢｙだけHadoopかつ
→ほかはspark圧勝！
HadoopもSparkも触っていない人
→Spark見送ったほうがいい
絶対動かない
もうすこしすれば、使い勝手良い
→Hadoopは動く
→Sparkは過渡期
2020年：メニ―コア化、バスのスピード
→アーキテクチャが変わる
今のＳｐａｒｋが５年もつか？
ＪＶＭ→Stop The worldはどうしょうもない！
HUEのデータ活用
ＷｏｒｋｓはSparkつかってます。
既存の製品：Ｏｒａｃｌｅ→ある程度のデータ量おそい
ＲＤＢ使えなくなった
発想限られる→基礎技術から変えた
エンタープライズにコンシューマー技術
ＧｏｏｇｌｅがＥＲＰを作ったら？
はやい
機械学習
Ｃａｓｓａｎｄｒａ
Elastic search（えらすてぃっくさーち）
Kafka(かふか)
Ｓｐａｒｋ
なぜＣａｓｓａｎｄｒａ？
分散ＫＶＳはたくさんあるが・・
ＤｙｎａｍｏＤＢ，ＢｉｇＴａｂｌｅ：ベンダーロックイン
ＭｏｎｇｏＤＢ：スケーラビリティの悪いうわさ
Riak（りあっく）：単純、あーらん
ＨＢａｓｅ：たまたまＣａｓｓａｎｄｒａのほうが運用実績があった
→性能のはなしではない。どっちでもよかった。
読み書き早い。レイテンシーが下がらない
→書き込みは複雑なことやると遅くなるが、
複雑なことをやっていないので早い
ＨａｄｏｏｐでパフォーマンスでないのでＳｐａrk
一貫性、トランザクション→ほとんどは必要でないが、一部ある。
→過剰にみんなトランザクションしてる
しなきゃいけないのにやってない→たいへんなことになるね！
ＴＰＣ－Ｃ
どういうふうに開発していけば
→アプリで頑張ればよい
ＯＣＣ Ｗｒｉｔｅ－Ｗｒｉｔｅ
Ｗｒｉｔｅ－SKew(すきゅー)は絞って
機械学習：ＲＤＢでやると、ＲＤＢがボトルネックになる
Spark SQLで何段も重ねたＳＱＬを動かすのはまだまだ
ロック周りのチューニング
チューニングにびくともしないのがある（余地がない）
ＧＣをきっちりやるのは、前提（止まるから）
ＪＶＭは手を入れる。パフォーマンスをどう上げるか
Ｓｐａｒｋはチューニングしないといけない
Ｈａｄｏｏｐはチューニングするところ限られている
これからさき
・Ｓｐａｒｋ
→ＳＴＣ（すぱーくてくのろじーせんたー）
ＪavaＴＣ，LinuxTCのつぎ
・Sparkの欠陥
pull型、
書き込みタイミング
→５～８ノードに最適化したものが出てきたら終わる
→そこはSparkは見ていない
そこにでてくる：ＲＤＢの延長
車輪の再発明をしていない
→ＲＤＢを勉強する
途中でてくるOCC（optimistic concurrency control：楽観的並行制御、楽観的排他制御、楽観的ロック）の話は、また別に書く。
その内容をメモメモ
なお、
・一部分かっていない
・その前に眼科にいき、目薬を打ったため＆会場は後ろの席だったため
スクリーンの文字は全く見えない
・途中からさんか
ので、テキトーにメモッっている。なので、一部間違っているところや
抜けてしまって意味通じないところもあると思うが、ご容赦願いたい。
※表題の件は、最後のパネルディスカッションの中で
（実際には、ノーチラステクノロジーズの神林氏が説明）
■AI（人工知能）の全体像－その歴史と現状、今後の展望
（途中から）
・統計確率型AI
事前確率：適当に決める
やってみる：ベイズの法則
事後確率→事前確率として戻る
・ロボットに応用→カルマンフィルタ→自動運転
センサーの値
ベイズ
結果→もどす
・現実世界：正規分布でない→同じキケン、限界
・脳科学：認識
→ディープラーニング、ディープニューラルネット
ブレイクスルー
GPU
ニューラル リワイヤリング：脳の回路をつなぎ変えても作用→脳に汎用性が在る
スパースコーディング
画像が音声にも使える
ロボット：非常に難しい→外界認識に
軍事転用の可能性
■きちんと知りたいApache Spark～機械学習とさまざまな機能群
発表資料はスライドシェア
聴講者層：機械学習初学者
ゴール；ＡＰＩが実践を意識している
Apache Sparkは３つに対応
バッチ処理
リアルタイム
インタラクティブ
Ｓｃａｌａ
Ｊａｖａ
Ｐｙｔｈｏｎ
Ｒ
機械学習ライブラリ
Sparkサポート
HDFS
AWS S3
Hive
JSON
HBASE接続ライブラリも
Ｓｐａｒｋ．ＭＬＬｉｂ
機械学習を簡単に
アルゴリズム
よく知られている
論文がある
スケールする
コンシステンシーを持たせる
クラシフィケーション
回帰分析
クラスタリング
レコメンド
データ読み込み
モデル
予測
ベンチマーク
Ａｍａｚｏｎ １０秒かからないでモデル構築
データフレームＡＰＩ
・ラッパーＡＰＩ
よくつかわれる機能をＤＳＬで
じかにＳＱＬ記述もできる
・関数多数、ユーザー定義も
・つかったほうがはやい
パイプラインＡＰＩ
・ＭＬパイプライン→ＤａｒaFrameを通してアクセス
・データ形式 フューチャーエクストラクションにかける
・パイプライン定義、データを放り込む
・流れ
訓練用データ、：モデル構築 テスト用データ適用
パラメーターチューニング
オーバーフィッティング→クロスバリデーション
パイプラインに対しモデル保存、再利用
Advaiced analysis with spark
■Sparkがもたらすビジネス革新ーデータドリブン・ソリューションの迅速な展開ー
Ｓｐａｒｋ ＩＢＭ昔から注目
システム３６０ 十分な速度ではない ランドマーク
一つのＯＳ
周辺的なソリューション
開発者集結
Ｌｉｎｕｘ
新しいＯＳ
サーバー、ＰＣ，でアプリ構築→コンピューターサイエンス
１３００万コード
インターネット
Ｓｐａｒｋ
次世代データアナリティクスＯＳ
→５０万業務コード
１．速度
２．表現力
→Ｌｉｎｕｘと比較
どのようなシステムでも対応できる
→コグニティブアプリケーション
高速な反復
横断的
ポイントをまとめた
プログラムバックグラウンド必要ない
数百万で提供
Ｓｐａｒｋ Ａｓ Ａ Ｓｅｒｖｉｃｅとして
Ｓｙｓｔｅｍ ＭＬ：マシンラーニングエンジン WATSON
オープンソーステクノロジ
コミニティとコントリビューション
インキュベーターとして
宣言的
Ｓｐａｒｋ ａｓ ａ ｓｅｒｖｉｃｅ
→Blue Mixで：他のサービスとも合わせて
天候の予測：Ｓｐａrkつかってから成功
家具店；クライアントのエンゲージメント
IoT：からだ、自転車、風力・・・・
投資：Ｈａｄｏｏｐにも
→とってかわるのか？：Ｎｏ
相当の投資
ＢｉｇＩｎｓｉｇｈｔ
ＭａｐＲｅｄｕｃｅ
多くのプロジェクト進行中
ＢｉｇＳＱＬ
従来の知識で良い
ＢＩＧ Ｒ
Ｈａｄｏｏｐの中核
オープンデータプラットフォーム
ＩＢＭ Ｂｉｇ Ｉｎｓｉｇｈｔ クラウド
サーバーのプロビジョン
おきゃくさまのリスト
主要なケーパビリティ：ストリーム
６０％以上のユーザー
ストリーミングコンピューティング
マイクロストリーミング
完全なストリーミング
新しいサービス
地理空間アナリティクス
ストリーミング
まとめ
表を作った
大量ＶＳ高速
小規模でスピード遅ければＭｙＳQL,DB2でも
堅牢なアナリティクスプラットフォーム
■SystemMLによる機械学習について
機械学習
ＳｙｓｔｅｍＭＬ
おぷティマイザ
ＳｙｓｔｅｍＭＬ
概要を話す
２０１０年から
どういうニーズがあるか
例：車の買い替え：アルゴリズム
→データポイント不十分
アルゴリズムのカスタム化だいじ
データセットも変わってくる
さまざまなアナリティクス要件
・上層部のセマンティック
・アルゴリズムの柔軟性
・データに依存しない、
・スケーラブル（独立性）
データサイエンティスト
Ｒ
Ｐｙｔｈｏｎで作成
→ＢｉｇＤａｔａもんだい
問題
・データサイエンティスト
反復的にプログラム書く
・データの最適化技術
Ｒ，Ｐｙｔｈｏｎ
→ターゲットプラットフォームかんがえなくていい
Ｓｐａｒｋ：ＲＤＤ
スタンディングエクスキューたー
ＳｙｓｔｅｍＭＬ
・回帰の例
マトリクスマルティぷレーション
・ロジスティック回帰
・直線的回帰
・データポイントの事例
５００のフィーチャー→フィーチャーをふやす
マルティプレっくすの演算子使えない→べつの演算子
→オプティマイザに処理させる
ほっぷ→データ特性：インストラクション
ろっぷ
データサイズによる違い
パターンマッチング：コモンパターン
ロイテッドスクエアードロス
ヒューズドオペレータ
Ｓ－ｐｒｏｐ－Ｐ
まとめ
・宣言的
■Beyond Shuffling-tips ＆ tricks for scaling Apache Spark
いろんなレベルで永続化できる
→キャッシングだけでは十分ではない：メモリに入りきらない
シェアードクラスタ
他の人が使っている場合、キャッシュ使えない（再演算）
チェックポイント機能
きーえすきゅー
キーの分散均等にならない問題
→処理の中断
→再パーティション必要になってくる
→Ｇｒｏｕｐ Ｂｙ ｋｅｙが悪
ＳＱＬ環境では問題ない
リリースバイキー
アグリケートバイキー→最適化できる
ソーティングの問題
Ｓｐａｒｋのアキュムレーター
予想性は高くないけど、それゆえにいいことがある
SparkSQL
ＳＱＬのためだけではない。
構造化、半構造化によい
→λファンクションより
エラーフリーなコード：書かれないコード
Sparkに機械学習
コードジェネレーション：まだまだ
spark10387
Tree reduce,Tree アグリゲーション
プログラミングガイド見てね！
spark.tc
■パネルディスカッション
アプリ・サービス開発者が学ぶべきデータアーキテクチャはこれだ！
データ活用がテーマ
・ロータスNotes：ドキュメント指向型データベース
→ＫＶＳに毛が生えたもの
Ｐ２Ｐがたグループウェア
ありるねっとわーくす→ワークスアプリケーションに買収される
ワークスアプリケーション：パッケージベンダー ＥＲＰ
HUE(ひゅー）がおもしろい
→０．１秒というパフォーマンス
HUE：カンパニーフォーラムで
・プログラム言語
ＪＶＭ
Ｓｐａｒｋ
→チューニング
・分散業務系しかやっていない
→Hadoop,Spark
さくらインターネット Hadoop→Spark
バッチ系：メインフレームより早い→１０倍出る
オンラインの分散処理：グリッド→メニ―コア
Hadoopやってる人は、Sparkすぐやったほうがいい
Hadoopはすべての面でおそい
１ペタバイトのＧｒｏｕｐ ＢｙだけHadoopかつ
→ほかはspark圧勝！
HadoopもSparkも触っていない人
→Spark見送ったほうがいい
絶対動かない
もうすこしすれば、使い勝手良い
→Hadoopは動く
→Sparkは過渡期
2020年：メニ―コア化、バスのスピード
→アーキテクチャが変わる
今のＳｐａｒｋが５年もつか？
ＪＶＭ→Stop The worldはどうしょうもない！
HUEのデータ活用
ＷｏｒｋｓはSparkつかってます。
既存の製品：Ｏｒａｃｌｅ→ある程度のデータ量おそい
ＲＤＢ使えなくなった
発想限られる→基礎技術から変えた
エンタープライズにコンシューマー技術
ＧｏｏｇｌｅがＥＲＰを作ったら？
はやい
機械学習
Ｃａｓｓａｎｄｒａ
Elastic search（えらすてぃっくさーち）
Kafka(かふか)
Ｓｐａｒｋ
なぜＣａｓｓａｎｄｒａ？
分散ＫＶＳはたくさんあるが・・
ＤｙｎａｍｏＤＢ，ＢｉｇＴａｂｌｅ：ベンダーロックイン
ＭｏｎｇｏＤＢ：スケーラビリティの悪いうわさ
Riak（りあっく）：単純、あーらん
ＨＢａｓｅ：たまたまＣａｓｓａｎｄｒａのほうが運用実績があった
→性能のはなしではない。どっちでもよかった。
読み書き早い。レイテンシーが下がらない
→書き込みは複雑なことやると遅くなるが、
複雑なことをやっていないので早い
ＨａｄｏｏｐでパフォーマンスでないのでＳｐａrk
一貫性、トランザクション→ほとんどは必要でないが、一部ある。
→過剰にみんなトランザクションしてる
しなきゃいけないのにやってない→たいへんなことになるね！
ＴＰＣ－Ｃ
どういうふうに開発していけば
→アプリで頑張ればよい
ＯＣＣ Ｗｒｉｔｅ－Ｗｒｉｔｅ
Ｗｒｉｔｅ－SKew(すきゅー)は絞って
機械学習：ＲＤＢでやると、ＲＤＢがボトルネックになる
Spark SQLで何段も重ねたＳＱＬを動かすのはまだまだ
ロック周りのチューニング
チューニングにびくともしないのがある（余地がない）
ＧＣをきっちりやるのは、前提（止まるから）
ＪＶＭは手を入れる。パフォーマンスをどう上げるか
Ｓｐａｒｋはチューニングしないといけない
Ｈａｄｏｏｐはチューニングするところ限られている
これからさき
・Ｓｐａｒｋ
→ＳＴＣ（すぱーくてくのろじーせんたー）
ＪavaＴＣ，LinuxTCのつぎ
・Sparkの欠陥
pull型、
書き込みタイミング
→５～８ノードに最適化したものが出てきたら終わる
→そこはSparkは見ていない
そこにでてくる：ＲＤＢの延長
車輪の再発明をしていない
→ＲＤＢを勉強する
途中でてくるOCC（optimistic concurrency control：楽観的並行制御、楽観的排他制御、楽観的ロック）の話は、また別に書く。
アクセス
トータル
ランキング
