Above & Beyond

日々のアウトプット記録

フィンテックエンジニア養成勉強会#3(共催:東京証券取引所)

11/21(木) は「フィンテックエンジニア養成勉強会#3(共催:東京証券取引所)」に参加してきました。

fintech-engineer.connpass.com

f:id:kabukawa:20191124160555p:plain:w500

会場は 東京証券取引所 さんのイベントホール。まさか勉強会で東証に入館する日が来ようとは。。。。

f:id:kabukawa:20191124161258j:plain:w600

会場となったホールは奥行きがあって広いのですが、後ろの方の人はちょっとスクリーンが見えづらかったかもしれません。 (自分は前の方に陣取ることができたのですが、そういう声もありました)

そして東証といえばテレビでよく見るシリンダー(電光掲示板で株価などがダーッと流れているガラス張りの円筒形の場所)ですね。 休憩時間に少しだけ見ることができました。(取引は終わっているので当然暗闇の中なわけですが)

f:id:kabukawa:20191124161448j:plain:w600


目次


フィンテックエンジニア養成勉強会 とは

金融エンジニア養成コミュニティ の開催する勉強会です。コミュニティの概要から引用すると

金融エンジニア養成コミュニティは「より良い未来の社会を切り拓くためにVUCA時代を乗り越えれる金融関係者(エンジニア、マネージャー、経営者)を養成すること」を目的としております。 第1弾の取り組みとして2019年10月5日に「フィンテックエンジニア養成読本」を発売しました。この本のコンセプトをベースに継続的に勉強会を開催する予定です。

僕はSESの世界で主に金融システム(Not 勘定系)に携わってきたので金融分野には結構興味がありますが、なかなかカジュアルな感じで参加できる勉強会って無いんですよね。 金融系というとスーツの人たち向けのシンポジウムか株で一山当てよう!みたいな人が集まっていそう、というイメージもあるとは思いますが。。。 エンジニアじゃない人でも参加できると思うので、割とライトなところから入れる稀有な勉強会だと思います。


タイムテーブル

時間 内容
19:00~19:10 オープニング
発表者:阿部 一也@三菱UFJトラスト投資工学研究所 さん
19:10~19:20 東京証券取引所のサービス説明」
発表者:保坂 豪@東京証券取引所 さん
19:20~20:05 パネルディスカッション1「金融ビッグデータの活用の今と未来」
パネラー1:保坂 豪@東京証券取引所 さん
パネラー2:北山 朝也@Alpaca Japan さん
パネラー3:辻中 仁士@ナウキャスト さん
モデレーター:多治見 和彦@みずほフィナンシャル さん
20:05~20:15 休憩
20:15~21:00 パネルディスカッション2「金融クラウドの進化」
パネラー1:大西 純@三菱UFJ銀行 さん
パネラー2:廣瀬 一海(デプロイ王子)@日本マイクロソフト さん
パネラー3:中出 匠哉@マネーフォワード さん
モデレーター:南 達也@みずほフィナンシャル さん
21:00~21:05 クロージング
高屋 卓也@技術評論社 さん
21:05~21:20 名刺交換タイム
21:20~21:30 撤収

内容

今回のテーマは「アノ鐘ヲ鳴ラスノハアナタ」。会場が東証だけに、鐘に掛けている、と(笑)

f:id:kabukawa:20191124165805j:plain:w500

実は1回目から参加(今回は3回目)しているのですが、残念ながらスライドの共有は今のところ無いようです。 トゥギャられてもいない(もったいない)ようなので、取り敢えずハッシュタグで検索のリンクを貼っておきます。

twitter.com

もっとも、パネルディスカッションが多いので、スライドよりはツイート読んだほうが雰囲気や内容がわかると思います。 なので今回のエントリは自分のツイートを中心にまとめたいと思います。

オープニング

コミュニティの目的もちゃんと説明があります。

f:id:kabukawa:20191124165740j:plain:w500

雰囲気はカジュアルですが、内容と目的は極めて真面目です。


東京証券取引所のサービス説明」

発表者:保坂 豪@東京証券取引所 さん


東京証券取引所のサービスについて。

東証では板情報などを提供する FLEX Histrical データサービスというのが有るのですが、これ確かデータが巨大な上に固定長のテキストで下処理が結構大変なんですよね。 それを東証でも分かってはいて、扱いやすくするための取り組みもしているとのこと。それがこちら。なんとOSSで公開されています。

github.com



パネルディスカッション1 「金融ビッグデータの活用の今と未来」

パネラー1:保坂 豪@東京証券取引所 さん
パネラー2:北山 朝也@Alpaca Japan さん
パネラー3:辻中 仁士@ナウキャスト さん
モデレーター:多治見 和彦@みずほフィナンシャル さん


ナウキャスト社

アルパカ社

  • Alpaca
  • 板情報などを駆使してMarketStore、AlpacaForecast、AlpacaRadar等のサービスを展開。前のセッションのところで紹介したAlpacaDBはアルパカ社と東証OSS化。

パネルディスカッションの開始前にパネラーにアンケートを取った結果

JPX Alpaca Now Cast
外部データ ほぼ内部データ 金融市場の
さまざまなデータ
データ購入も
外部データを
プロダクト化・提供
クラウド 公開:パブリッククラウド
非公開:セキュアな
スダンドアローン
ほぼパブリッククラウド
専用線も利用
AWS公表の
ベストプラクティスに準拠
ほぼパブリッククラウド
セキュリティ担当者配置
アクセスコントロール
Pマークレベル
データ分析
体制
10名超データ分析担当者
案件ごとにチームを組成
ビジネスサイド:10%
データエンジニア:30%
(システム・フルスタック寄り)
データサイエンティスト:60%
デザイナー・フロントエンジニアは外注
ピジネスサイド:10%
データエンジニア:45%
(データクレンジング,データハンドリング等)
データサイエンティスト:45%
デザイナー・フロントエンジニアは外注

様々なデータが投資に意味を持つようになってきた。様々なデータが使えるようになってきた。

セキュリティ関連の話は、たぶん会場にいる多くのひとが頷いている気がする。


モデレータの方の進行がうまくて、とても良いパネルディスカッションでした。 盛り上がりすぎて時間があと1時間位ほしい、と思ったのは自分だけではないでしょう。 データに対する考え方はそれぞれあるけれど、その違いがまた面白いなぁと思いました。


パネルディスカッション2 「(仮)金融クラウドの進化」

パネラー1:大西 純@三菱UFJ銀行 さん
パネラー2:廣瀬 一海(デプロイ王子)@日本マイクロソフト さん
パネラー3:中出 匠哉@マネーフォワード さん
モデレーター:南 達也@みずほフィナンシャル さん


クラウド導入の苦労

「触ってみて使い方を考える。車買うときに試乗するのと同じ。」という広瀬さんの話がなんか心に残りました。


まとめ

これまで3回参加してみてどの内容も面白いなぁと思っているのですが、限られた時間の中でパネルディスカッション2本はちょっと多いな、という気がします。 盛り沢山なのは良いのですが、面白いテーマがたくさんある分消化不良気味に終わってしまうのも事実。 たぶん参加者の多くがそう思っている気がするので、回数を増やす代わりに思い切ってコンテンツを減らしてみるのも有りかと思います。 もちろん、そうするとスタッフの負担が増えてしまって運営しきれないという問題がでるので、うまくコミュニティが成長してスタッフも増えて、という循環が必要になると思いますが。 色々書きましたが、その分期待も大きいということで、これからも注目して(できれば参加もして)いきたいと思います。

なお、フィンテックエンジニア養成読本はこちらです。ちょっとだけAmazonにレビューも書いたので、よろしくおねがいします!

フィンテックエンジニア養成読本 (Software Design plusシリーズ)

フィンテックエンジニア養成読本 (Software Design plusシリーズ)

最後になりましたが、今回も講演者、スタッフ、参加者、そして会場を提供してくれた東証の皆様、ありがとうございました!

f:id:kabukawa:20191124180400j:plain:h300

ちなみにこの牛の人形、東証だけに「とうし」という名前でした(笑)

PWA Night vol.10 ~PWA × 技術~

11/20(水) は「PWA Night vol.10 ~PWA × 技術~」に参加してきました。

pwanight.connpass.com

f:id:kabukawa:20191124112212p:plain:w500

会場は オイシックス・ラ・大地株式会社 さんのイベントスペース。

f:id:kabukawa:20191124124323j:plain:w600

結構広いのですが、ここが一杯になるくらいの申し込みがあったということで、なんかPWAの熱を感じますね。


目次


PWA Night とは

初回と2回めに参加していて、参加報告を書いていますので、そちらも参照してください。

kabukawa.hatenablog.jp

kabukawa.hatenablog.jp

今年の2月からスタートして今回で10回目。毎月開かれているっていうのがすごいです。 人気の勉強会で、油断すると補欠になったりするので、参加したい方はグループメンバーになっておくことをおすすめします。

pwanight.connpass.com

僕も暫く参加できていなくて、今回の参加が久しぶりでした。


内容

既にトゥギャられていますので、内容や雰囲気はこちらで。

togetter.com

250ツイート以上と、すごい盛り上がりでした。


とある個人開発PWAのSEO奮戦記

大岡由佳(おおおか・ゆか)@oukayuka さん

speakerdeck.com

Mangarel というサイトのインデックスをGoogleにいかに拾ってもらえるようにするか、とPWA化について。

mangarel.com

問題点

  1. ページそのものがインデックスされない
  2. タイトルや詳細が個別に表示されない
  3. コンテンツがレンダリングされない

サイトマップを送ってみたが、他のページからのリンクがなければインデックスから除外されていしまう。 カテゴリを増やすなどして地道に内部リンクを増やしてみたところ、少しずつ登録されるページが増えてきた。

github.com

コンテンツがレンダリングされない問題

  • 遅いか遅くないか、それが問題。
  • 全体の表示時間が4~5秒位が生命線と思われる。
  • これを4秒未満に抑えるというのを当面の目標に。

www.npmjs.com

無限スクロールはGoogleがあまり認識してくれない問題 * →ガイドラインがある。 * URLにpage=2とか付ければインデックスをしてくれるようになるらしい。これはなかなか大変そう。

webmasters.googleblog.com


PWAとサイトのインデックス化、何もしないでも大丈夫だと思っていたけど、色々対応をしないとうまく行かないんだなと思いました。 Mangarel、早速インストールしてみたけど、サクサク動いていい感じです。


PWA×クラウドゲーミング

おりばー(@oliver_diary)さん@Black Inc.

speakerdeck.com

クラウドゲーミングプラットフォームのOOPartsと、そのクライアントアプリのPWA化という内容。

oo.parts

クラウドレンダリングなどの重い処理をして、クライアントには映像を配信するような仕組み。Googleのstadiaと似ているのかな。

stadia.dev

ゲームだとアプリとしてのサイズはどうなんだろうと思ったけど、アプリで演算するわけではないからそんなに重くはないのかもしれない。 ゲームに起動=サーバー側のインスタンスが起動するまでの時間+αということなのか。面白い仕組みだな。

なんの問題も起きずに(いや、当たり前なのかもしれないけど)サクサク動いていて、言われないとクラウドで動いているとは気づかないかも。ブラウザのアドレスバーとかもないから、没入感を得るには確かにPWA化は自然な感じもする。


もうちょっとモッサリした感じの動きを想像していたんだけど、想像以上にサクサク動いていいてびっくり。 裏側の開発は大変そうだけど、これはもしかしたらいい線いけるかも、と感じました。 サブスクリプションということなので、どれだけコンテンツが集められるかにも期待したいですね。

jp.techcrunch.com


コードサイズの大きなプログラムのロード時間:WebAssemblyの場合

@chikoskiさん

WebAssembly については MDNのこちらの記事で。

developer.mozilla.org

WebAssemblyに変換してやると、Vimもブラウザ上で動くらしい。以下がそのデモページ。すごい。

rhysd.github.io

PWA化することで、Javascriptより高速で安定した処理を行うことができるようになる。

いくつかの例:

サイバーエージェント社の「こえのブログ」。WAVをMP3に変換するなどの処理をWebAssemblyで処理しているとのこと。

developers.cyberagent.co.jp

InstagramのPWA版

WebAssemblyを採用することで、PWA版でもフィルタの適用ができるようになったらしい。

このあたりの話はこのスライドにも少し出てきますね。

www.slideshare.net

WebAssemblyは高速に実行できるけど、それをダウンロードして実行モジュールをビルドしたりする時間が結構大きいので、キャッシュ戦略が重要。

キャッシュを大事にするためにやるべきこと

  • 不必要な変更をしない
  • URLを変えない
  • サイズを小さくしすぎない(小さいとキャッシュされないため)
  • コンテンツが変わっていなければHTTPステータスは200ではなく304を返す

コンパイルを速くするにはMIME typeとして application/wasm をつける。 キャシュの話はこのあたりも参考にすると良いかもしれません。

developers.google.com


WASMの話、興味はあってもなかなか話を聞く機会がなかったので、とても参考になった。

CDNでもこんな動きがあって、クライアントだけではなくネットワークのエッジでも使われるんだー、と注目をしていたところでした。

www.publickey1.jp


LT1:JAMStackの話

のまどまんさん

[資料は公開されたら追記します]

JAM Stack jamstack.org

どんなものかを意訳をされた方がいらっしゃるので、そちらも併せてどうぞ。


JAM Stack 知らなかったので、あとでもう少し調べてみよう。


LT2:Monacaで3Dモデルを動かす話

VMT-Yamashitaさん

www.slideshare.net

playcanvasというものを使うとグリグリできるものが作れるらしい。

playcanvas.com


Monaca、実はあまりわかっていないので、こちらも少し勉強してみたい。


懇親会

体調を考えて懇親会は参加せずに帰りました。


まとめ

PWA、半年前に参加していたときに聞いた話よりもずっと浸透していて、しかも割と普通に使えるものになってきているのを実感しました。

あと、年明けにこんなイベントも有るようなので、PWAに興味がある人は参加すると良いと思います。なんと驚いたことに参加費は1000円!!!

conf2020.pwanight.jp

というわけで、今回も楽しく色々勉強になる回でした。

講演者、スタッフ、参加者の皆様、ありがとうございました!

Spark Meetup Tokyo #2 (Spark+AI Summit EU 2019)

11/19(火) は「Spark Meetup Tokyo #2 (Spark+AI Summit EU 2019)」に参加してきました。

spark-meetup-tokyo.connpass.com

f:id:kabukawa:20191120004343p:plain

会場は NTT Software Innovation Center さん。

f:id:kabukawa:20191124123516j:plain:w600


目次


Spark Meetup Tokyo とは

グループの概要から引用します。

オープンソースの分散並列処理フレームワーク Spark に関するmeetupです

分散並列処理フレームワーク Spark というのはこちらです。

spark.apache.org

近年注目されているOSSの超高速の統合分析エンジンです。


内容

開催概要から引用します。

Spark+AI Summit (SAIS) Europe 2019で発表があったSparkの最新開発状況,ユーザからのユースケース報告,関連OSSであるKoalas/MLflow/Delta Lakeなどに関する最新情報をお伝えします.

  • Spark+AI Summit Europe - イベント内容: databricks.com
  • Koalas - Spark用のPandas DataFrame APIs: pypi.org
  • MLflow - 機械学習によるデータ分析のライフサイクル管理ツール: pypi.org
  • Delta Lake - データレイクを実現するためのSpark用のストレージレイヤ: delta.io

イベントと会場に関する説明

Takeshi Yamamuro(Twitter:maropu)@NTT1 さん


SPARK+AI Summit Europe 2019 セッションハイライト

萩原 悠二/Yuji Hagiwara1 さん and 酒井 遼平/Ryohei Sakai@NTT Data さん

[資料は公開されたら追記します]

Spark+AI Summit EU 2019について

とはいえ

  • 昼食会場は席が足りない
  • 日本からの参加者は少ない
  • ヨーロッパ周辺からの参加者が多い

キーノート

  • ML Flowについての最新機能など
  • ML Flowについて
  • OSSのMLプラットフォーム
  • ラッキング、プロジェクト、モデルの3つで構成
  • ここ6ヶ月での機能のアップデート

Auto Logging

  • 機械学習ライブラリで学習を行う際に便利な機能
  • TensorFlowたKerasで一般的に必要になるであろうパラメータ、メトリクスを自動でトラッキングする。

ML Flow Model Registory

  • モデル管理の課題
  • 大人数でモデルを管理するとき
  • どのモデルを使えばいいか
  • どうやってモデルが作られたのか
  • どうやってレビューするか など

  • モデルに対して名前やコメント、タグを付けてバージョン管理できるレジストリ

  • 各モデルのステージ(開発用、ステージング、本番用など)の状態遷移、その履歴も管理する
  • デモでは実際の画面を見せてどんな事ができるかを確認できた
  • モデルの読み込み時にモデルの名前とステージを指定して読み込みができるようになる

10/30 に ML Flowがリリースされた。ML Flow mkdel Registoryも含まれている

事例 * フランスのメガバンクの事例 * ビジネス * データサイエンティスト * データエンジニア

取り組んできたこと

  • データローカリー(HDFSに保存して、是認がそこを見る)
  • アプリケーションの信頼性
  • 様々なPythonパッケージ
  • モデル管理
  • ラッキングサーバーの信頼性(冗長化)
  • モデルサービング(モデルの使い方)

具体的には

キーノート

  • Spark周りのエコシステムの状況
  • Sparkエコシステムに関する最近の取り組み

Spark3.0の改善ポイント

  • Adaptive Query Execution
  • Spark SQLのパフォーマンス改善ポイント
  • 実行中にデータを見てからクエリプランを変更

Dyanamic Partition pruning

  • ディメンションテーブルに対するフィルタ条件をもとにして巨大なファクトテーブルをフィルタ

2019/11/6に Sparl 3.0のPreviewがリリースされている

Delta Lake

  • ACID transaction on SparkScalable metadata handring
  • Streaming and batch unification
  • Schema enforcement
  • etc...

これまでのアーキテクチャで辛いポイント

  • データ分析をリアルタイムでしたい
  • もう少し精緻な形で分析したい
  • こういう条件が2つが並行で存在する場合に2つのアーキテクチャを作る必要がある

DeltaLakeを使うことで改善できる

  • 2018年4月にOSS

Koalasとは

  • Pandasと同じコードでSparkで動かす
  • モチベーション
    • データサイエンティストは自身のラップトップ上でコーディング
    • 実際の分析のときに書き換えることにあるのは辛い
    • PandasからSparkへの書き換えが1%くらいで済むようになる

なぜクラウドでオートスケーリングが重要か?

Sparkクラスタにおけるノードの役割

  • コンピュート
  • 一時データの保管

UpscaleはかんたんだがDownscaleは難しい

  • ノードの除外にあたって
  • 実行中のコンテナが存在しない
  • 一時データが存在しない

ことの確認が必要になる。

課題

解決策

一時データ

  • Suffuleファイルは各Executorのローカルストレージ上に存在
  • Suffule Cleanup
  • TTLベースでファイルを削除
  • コンピュートストレージの分離
  • nfsマウントした場所に置くことで回避

Koalasの開発状況 (Updates)

Takuya Ueshin(Twitter:ueshin)@Databricks さん

www.slideshare.net


Koalas

github.com

  • Pure Python Library
  • Databricsの開発したOSS
  • Pandas APIを使ってSparkを動かす

なぜ作ったか

  • データサイエンティストはPandasを使って教育を受けることが多い
  • Pandasは小さなデータのときは良いけど、実務では大きなデータが必要なので困る

Spark(UC Barklay→Databrics)

Pandas DataframeとSpark DataFrameは意外に違う

  • カラムの追加、リネーム、値のカウントなど。。。
  • 学習コストが、、、
  • Sparkで書くほうが少し冗長
    • →Koalasを開発

Koalasの開発

  • PandasのAPIを優先して開発

とはいえ違いはある

鍵となる違い

  • Pandasはその場で計算、Sparkの場合はそうならない
  • データの処理後の順番はSparkは分散システムなので保証されない

2週間に1回のリリース

  • 日次のダウンロード10kを超える

キーノートのビデオが公開されている

現在の開発状況

  • かなりアクティブに開発中
  • PAndasAPIの60%、DataframeGroupBy/SeriesGroupBy 60%実装済
  • Plot関数80%
  • parquetの読み込みなど
  • MuktiIndexColumn 90%

700コミットを超えている

  • 日次ダウンロードも15k以上に増加
  • 1%のコードを変えただけで10倍高速化した

今後の動き

pip/condaでインストール可能

  • ドキュメントに詳しく書いてある
  • github.com/databrics/Koalas
  • Libe Jupyterで動かして確認できる
  • 提案やリクエスト、イシューも募集中

Quick Overview of Upcoming Spark 3.0 + α(SAIS Europe 2019で個人的に興味のあった発表紹介)

Takeshi Yamamuro(Twitter:maropu)@NTT さん

www.slideshare.net

ML Flowの公式アカウントにイベント告知のリツイートをしてもらった

Spark3.0の時期リリース 20120のQ1と言われている

  • 互換性が壊れる変更が多く入っている
  • previewは事前の確認用の先行的な公開という位置づけ
  • 正式リリースではないので、パッケージでの配信などはない

開発中なので、メジャーアップデートの全機能はわからない。

これまでのクエリ実行

  • Sparkのクエリは入力データの統計を用いて「実行前」に決定
  • 実行計画は途中では変わらない(不変)

物理プランを複数のクエリステージに分割して各ステージの実際の出力プランの出力データの統計情報を用いて次のステージの実行計画を決める

Dyanmic Partition pruning

  • 隣接するFilter処理の述語(Where)を動的なパーティショニングに活かす
  • 属性テーブルの結果を天パンすることで最大100倍高速化

Sparkの実行計画が読みにくい

  • 見やすく修正された

DataFrame Cogrouping

  • Pandas UDFでグループ化してMAP処理が可能に

Join Hints

  • 3.0からはすべてのJoinに対するHintが可能に

PostgreSQL Sialect Support

  • PostgreSQLとの挙動のち外野未サポート機能を把握するためにリグレッションテストの一部を移植
  • 共通性の高い課題に関してはSparkの動作に反映。PostgreSQLの独自の振る舞いについてはオプション設定をすることで反映
  • ただし、開発中なのでどこまで取り込まれるかは未定

Spark@Facebook

  • FacebookはSparkのヘビーユーザーで知見を共有している
  • 推論とIndexingに使っている
  • Sparkと外部プロセスの間のI/O処理の効率化
  • 開発環境ではデバッグ効率重視のテキスト形式、プロダクションでバイナリに変更
  • Apache Arrow

Scriptb Transformation

  • テーブルに対してシェルなどのコマンドをApply出来る。

Delta アーキテクチャ

Paulo Gutierrez(Twitter:tokyodataguy)@Databricks さん

www.slideshare.net

Delta Lamdaアーキテクチャ(Apache Storm)よりは先、Kafca(Kappaアーキテクチャ)の次なのでDelta

kafka
Kinesis    Spark    Table    Spark  AI、Reporting
DataLake

リアルタイム分析 Spark Streaming

AI/AI、Reporting Spark batch

何が問題か?

  • コンスタントな読み込み ライターとリーダーの分離が必要
  • 最適化されたファイルのサイズとソースが必要
  • バージョンによるロールバック(タイムトラベル)
  • 履歴データのリプレイ
  • 後で来たデータもストリーミングでUpseartできる

バッチとストリーミングを統合して継続的にデータを処理する

  • バッチとストリーミングの統合
  • インクリメンタルなロード

Intermidiate Hops

  • 出来るとことから処理を開始する

ストレージレイアウトの最適化

  • パーティショニング カーディナリティの低いデータはこっちで
  • Z-Ordering
  • parquetを採用しているので出来る

再処理時

  • Infinite retention

データクオリティ

  • ブロンズ 生データ
  • シルバー ある程度クレンジング
  • ゴールド アグリゲーション。タグ/ラベル付

Project Hydrogenの最新情報

Kazuaki Ishizaki(Twitter:kiszk)@IBM Research - Tokyo さん

www.slideshare.net

AparkとAIフレームワークを統合するHydrogenプロジェクトについて

ある意味、3度めの正直

  • TensorFlow on Spark(Yahoo)
  • SqqpLearning Pipekines(Databrics)

Spark上で分散AIフレームワークを実現する

ユースケース1

  • 分散学習

分散学習では並列処理の形態がこれまでと異なる * MapReduce * 部分再実行 * 分散学習 * 全タスクを再実行

Barrier Execution Mode

  • すべてのタスクを同時に実行する
  • 故障が起きたら部分だけキャンセル

故障が発生した場合の再実行も自動的に行われる

  • 故障のためのコードを書かなくても良いSparkの良さはそのまま

Barrier Execution Mode 利用例

  • Databrice 5.0上でのHorovoidとの統合
  • Horovoid
  • 分散トレーニングを可能にするフィレー無ワークに依存しないランタイム

アクセラレータ(GPU/TPU)、どうやって使ってますか?

  • YarnやK8sはExecuter単位でアクセラレータを割り当てる
  • でもSparkのTaskのことまでは知らない

Accelarator-aware Scheduling

GPUの自動検出、Executor/Taskに割り当てるGPUの数

  • Taskが実行されているGPUを取り出してTensorFlowにk情報を与える

Spark3.0 previewでのサポート状況

  • クラスタマネージャ サポート済み
  • k8s yaanなど
  • Mesos 未サポート

ユースケース2

  • ストリームデータの推論

推論ではAIフレームワークとの高速データ交換が重要

  • 性能に大きく影響する

Pandas UDFを使うと遅かったPySparkがSpark 2.3からは3倍から100倍高速化

  • 実装はApache Arrowを使っている
  • 推論でよく見る「ラベルとスコアのペア」を高速にSpark側に渡すことが出来る
  • Pandas UDF自体の高速化

Pandas UDFの1バッチを実行している間に次に使われるバッチを前乗ってApark側からPython側に転送しておく

  • PandasUDF内で一度呼んだモレルを再実行する

Spark極めて性能向上の話

Chris Kong(Twitter:val_mukong)@Rakuten さん

[資料は公開されたら追記します]

Rakuten AnalyticsTracker Platform

  • 12万QPS
  • 3.8B レコード
  • 1.9PBデータ

データ収集

Front
JS Tracker Logstash Spark Streaming/Kafka   
SDK
DMP

Spark Streaming の最適化

  • Kafkaからの読み込み/書き出し

何が問題か?

  • セールなどのときに処理が重くなる。
  • アップストリームにあるので、ここの遅延はまずい
  • Shfflingの時間がかかりすぎるのが問題
    • →Executerを増やす
    • 改善した

しかし、まだ問題が

  • マイクロバッチの処理
  • スケジューリングの遅延
    • →最適なmaxRatePerPartiotionを見つける
    • 遅延を早く改善することを目的としている

どうやって最適値を見つければいいか?

  • 秒間処理速度を概算して大体のmaxRatePerPatitionを逆算

レポートエンジンの改善

MapReduce on Yarn

  • 処理時間がかかりすぎ、Preemptされる
    • →Spark SQL を使うことにして劇的改善

しかし、バグが有って複雑なクエリを処理できないことが分かった

  • →Spark SQLをやめてDataSetを使う

チューニング

チューニング

  • Dynamic Resorce Allocation

結果

  • 処理時間が半分くらいになった
  • ただし会社からグラフの詳細度が。。。笑

これからやりたいこと

  • ストリーミング
  • バッチ
  • それぞれでやりたいポイントあり

LT1: Koalasのココが良いよね

Harutaka Kawamura(Twitter:harupy)@ARISE さん

docs.google.com

Koalasとは

  • 4月にDatabricsが公開

Koalasの特徴

  • PandasのAPIを真似る

Pandasを真似ることで得られる利点

  • PySparkの作法を学習「しなくて良い
  • 切り替えコストがk低い
  • PandasにあるがPySparkにはない機能&関数

Koalasを使えばPySparkよりかんたんにデータを処理できる


LT2: Higher-Order Functions をちょっと深掘りしてみた

Kamuela Lau(Twitter: kamu_lau)@Rondhuit さん

[資料は公開されたら追記します]

高階関数とは

  • 引数として関数を受け取る
  • 戻りとして関数を返す

高階関数の例

  • Transform
  • filetr
  • aggrigate
  • exists
  • sip_with

Map


懇親会

体調を考えて、懇親会は最初だけ参加して帰りました。


Apache Arrow

Apache Arrowというメモリ内データ用の言語間開発プラットフォームも、このプロジェクトから派生したOSSの一つです。 こちらも関連技術として、興味深いとおもいます。近々イベントも予定されていますのでリンクを貼っておきます。

arrow.apache.org

speee.connpass.com


まとめ

正直なところ、あまりSparkについて追いきれていなかったので、情報量の多さに着いていくのがやっとでした。 でも、メモを取りながら「こんなことまでできるようになってきているのか」とか得るものが多くて、参加できてよかったなと思います。 次回までにはもう少し勉強して、理解した形で参加したいなと思いました。

講演者、スタッフ、参加者の皆さん、ありがとうございました!