[/aside]
どうもayijkです。もう8月なんですねぇ。最近あんまりアプリ書いてないです……（もうリリース直前くらいまで実装は終わってるんですけど）。
さてさて普段はAndroid関係のイベントに出没することが多い私ですが，
今回は趣向を変えてデータ分析系の情報を仕入れようと思って以下の勉強会に参加してきました。
普段は勉強会中はメモを取るに留めて，帰宅後イチから記事を書き起こすことが多いのですが，
今週末はちょっと予定が詰まっているのもあり，勉強会中に記事を書ききる練習をしています。
# イベント終了後追記
やっぱり間に合いませんでしたｗ
イベント終了後，30分ほど執筆時間を取っています。
[/aside]
イベント概要
当該イベントのconnpassページはこちら。
# はじめに コネクティッドカーに代表されるようにIoTデバイスから大量のデータを取得し、リアルタイムにデータを分析し…
レバレジーズさんで開催されるイベントはいつも盛況ですね。特に記事にはしませんでしたが，先日参加してきたPython勉強会もここで開催でした。
登壇者は7名で2時間という結構豪華な会です。
講演詳細
ストリームデータ処理の動向
[aside type=”boader”] 6月に米サンノゼで開催された「DataWorks Summit 2017」で取材した内容を中心に、データストリーミングの最新トレンドについて紹介します。[/aside]
サンノゼで開催されたDataWorks Summitの報告発表です。
箇条書きで失礼すると，以下のような報告があがりました。
- 以前は”Hadoop”の名が入っていたカンファレンスだったが，最近は”Hadoop”の名前を出さずにデータ基盤としての色合いを出していこうとしている。
- 一番人気はTensorFlowのブース
- KafkaとNiFiについての話がメイン
膨大な数のデータソースから継続的に生成される連続データのことです。
時間の経過とともにデータの性質が変化するので，「いま」の状況を分析＆可視化するための技術として昨今注目が集まっています。
[/aside]
その他，印象深い言葉があったので紹介します。
[aside type=”boader”]
- 「Kafkaは空気」。使っていてあたりまえ。無いと死ぬ。
- Kafkaは我々にとって頭で考えて使うものではない。
- 新しいワインは新しい革袋に，古いワインは古い革袋に。
- 新しいイノベーションは新しい技術で。 [/aside]
- Spark Structured StreamingはSpark2.2でProduction Readyになった
- バッチとストリーミングデータを統合して扱える
- Kafkaとの親和性が高い
Kafka，ちょっと雰囲気だけでも知っておこうと思えるいい発表でした。
Modern stream processing by Spark Structured Streaming
[aside type=”boader”] 昨今、ストリーム処理は以前言われてきたバッチ処理と対比される状況を越え、統合データ処理として語られるようになってきています。OSSによるストリーム処理の流れを振り返り、最近の1つの具体例として統合されたデータ処理を簡易に実現可能なSpark Structured Streamingについて紹介します。[/aside]
冒頭はストリーミング処理システムの構成の変遷から。
その後は，同じくApacheプロジェクトのSparkのStructured Streamingについての説明がありました。
詳しくは上の発表資料を見ていただくとして，私的になるほどーと思った点を，これまた箇条書きで。
資料中に簡単なサンプルコードも挙げてくださってたので，イメージが掴みやすくて助かります。
例えばScalaで書くとこう。
val ss = SparkSession
.builder
.appName("app")
.getOrCreate()
import spark.implicits._
val lines = ss.readStream
.format("socket")
.option("host", "localhost")
.option("port", 9999)
.load()
Sparkは研究室時代にほどほどに使ったので抵抗感があんまりないのが幸いなところ。
Kafkaもそうですけど，こういうツールはどんどん新しいのが出てくるのでしっかりと追っていかないと置いてかれますね。IT系の楽しいところであり辛いところでもあります。
その点，こういう勉強会はコスパ（と言ってしまうと淡泊だけど）がよくて便利です。
Kafka Summit NYCに見るストリーミングデータETLの話（仮）
[aside type=”boader”] 5月に米ニューヨークで開催された「Kafka Summit NYC」をベースに、KafkaをコアにしたストリーミングデータのETLの動向などについて話します。[/aside] [aside type=”normal”]Kafkaとは
「そもそもKafkaとは」という説明があったので引用しておきます（私はこれだけだとナンノコッチャだったので，別途調べます……）。
Kafkaは以下の機能を提供するOSSのストリーミングプラットフォームだそうです。
- レコードストリームをpub/subできる
- レコードストリームをフォールトトレラントに永続化できる
- レコードストリームを発生したらすぐ処理できる
資料p16の一部，すこし口頭で説明のあったところを補足しますね。
- Messaging Done Right
- Hadoop Made Fast
- つまりHadooopの速い版
- ETL as a Platform
- Kafka全体をETLのプラットフォームとしている
あと，Kafka未入門の私にとってすごくわかりやすかったのが資料のp18, p19の図。
p18は色んなデータソースとシステムが複雑怪奇に絡み合ってThat’s Spaghetti!! って感じの惨状ですが，それをKafkaが解決するのがp19のイメージ。「取りあえずデータはKafkaに貯めて，そこから必要なものを引き出す」というスタンスのようですね。
あとは上に書いた「ETL as a Platform」とも通じる話ですが，p21もわかりやすいです。
[aside type=”normal”]
ETL as a Platform
- 全てのログはKafkaに，全てのログはKafkaから。
- Transformした結果は，そのままHadoopに入れるのではなくてKafkaに戻すこと。
大規模MQTTメッセージを支える技術
[aside type=”boader”] 物流系のIoTなシステムを設計/構築する中で、特にMQTTブローカーについて、考慮しなくちゃいけなかったことやハマったポイント、プロダクト/サービスの選定経緯についてお話します。[/aside]
実際に使ってるシステムをざざっと解説された感じ。
KInesis，MQTT，みたいな他のフレームワークの話がメインでしたが，Kafkaですらわからない私にはちょっと敷居が高かったですね……。
Apache NiFi, 流れるデータにもスキーマを
[aside type=”boader”] 処理性能にも大きく貢献する、Apache NiFi 1.2.0から追加された、スキーマやRecord Reader/Writerといった機能について掘り下げて紹介します。[/aside]
ApacheプロジェクトのNiFiというOSSツールのコミッターの方による発表です。
Kafkaと同じくNiFiも私にとっては初見ですが，NiFiは一言で言うと「データオーケストレーション・ツール」です。
具体的には，以下のような場面で活躍するのだとか。
- Kafkaにreachできないところからのフロー
- 多種多様なデータ形式のフォーマット変更の役割の吸収
また，NiFiの軽量版でminifiというのもあって，Raspberry Piでも動くらしいです。
OSSのコミット，してみたいな。
ちょっと探してみようと思ったり。
NiFi素人が苦労した物語
[aside type=”boader”] Webサービスが連携していく中で、独自インターフェースとのやり取りや、しがらみを吸収するのに採用した内容について事例紹介させていただきます。[/aside]
SoftBankの運用システムの中でNiFiを活用した事例の紹介です。
SoftBankは会社の合併・統合という経緯から，サービス毎に個別開発したシステムが多くて，そのメンテが大変という問題に直面しているらしいです。そのため，開発プラットフォームを統一化しようという流れがあるのだと。
特にNiFiを使うときに気をつけて欲しい3つのことを共有してくれました。詳しくは資料を。
- NiFiをどうやって使うか決めておくといい
- 具体的にNiFiがシステム中で受け持つ機能について（連携先のシステムとの分担について）
- 性能
- 使用する言語の選択（例えばJythonは性能落ちる）
- GCチューニング
ビッグデータエンジニア向けのIoT入門 〜デバイス、無線からクラウドまで〜
[aside type=”boader”] IoTならではのアプリケーションデザインのお話をします。例えば、セルラー通信でのデータ収集はネットワークの不安定性を考慮に入れて設計する必要がありますが、デバイス側のバッファが小さく、再送処理もままならないようなケースも多数あります。こういった「あるある」なユースケースに沿ったアプリケーションデザインを紹介していきます。[/aside]
最近，KDDIが200億で買収したと話題のSORACOM。
IoT＋ストリーミング処理って実際どうなの？ という話題で中の人が説明してくれました。確かに，IoTってイメージで語られることが多くて内実を見せてもらえることって意外と少ないですよね。
SORACOMの案件として説明があったのは以下の2つでした。
- 遠隔監視
- スマートメーターで使いすぎ通知
- 動態管理
- 物流トラックにおける動態管理
ほかに，IoTならではの特異性は？ という話題で後半の話。
通常のシステムと比べて大きな違いは，「デバイスやネットワークもアプリケーションの一部」という意識。例えば電池は何年持つの？ とか，ネットワークはどれくらい安定してるの？ とか，普段は気にしない足回りも気にする必要があるんですね。
もう少し具体的に言うと，
- モバイルネットワーク
- 切れる前提でアプリケーションを設計する必要がある。
- 速度低下，ボトルネックもある。
- 大量のデバイスを取り扱う場合，処理の時間的分散も組み込んでおく（devide idのmodとか）
- デバイス
- 用途/予算によって適当なものを使う。
- デバイスに角のインテリジェンスを求めない。
- やれること vs 消費電力/値段はトレードオフ（たとえばHTTPS+JSONは高級品）。
- 通信にかかる負荷をどうオフロードするか。
- OTA(Over The Air)をどうするか。
- データ
- プリミティブなデータをどう扱うか（基本的なデータは数値，連続的なデータが多い）。
- イベント検出をデバイスとサーバのどちらで行うか。
などが議題でした。
IoT＋ストリーミング処理を標榜するSORACOMならではの発表で興味深かったです。
まとめ
ストリーミングデータ処理，という言葉に引かれて偶然申し込んだ勉強会だったのですが，KafkaとNiFiという新しい知識を得ることができてよかったです。
Apacheのツールは1度俯瞰しておかないとエンジニアはもはや名乗れないのかもしれない，と結構焦ってしまったのはここだけの話。
配属先で学ばなきゃいけないことも多いんですが，それだけで満足するのではなくて，このあたりの周辺知識も積極的に集めていこうと心を新たにしたイベントになりました。