Java Streams API を使って例外処理をきっちり行なうコードを書くことは難しい - Qiita
Streams API をこれまでまともに使ったことがなかった。 まともに使おうとしたら例外処理の扱いが非常に難しいことを実感したので、一例を挙げてその難しさを解説する。 やりたい処理 複数のテキストファイルのそれぞれを1行ずつ読みこみ、空白文字で各行を単語に分割し、単語に対して何か処理を行なう、というよくある処理を実装してみよう。処理の手順を手続き的に書くと以下のようになる。 あるディレクトリの直下に存在する複数のテキストファイル（拡張子 .txt）を1つずつ読む 各テキストファイルを1行ずつ読む 各行（文字列）を、空白文字を区切り文字として複数の文字列（単語と呼ぶことにする）に分割する 各単語に対して何か処理をする。以下、処理の名前を analyze とする クラスの雛形 以下の TextFileProcessor を拡張したクラスを実装する。 各単語に関する処理 analyze は実
The Beam Model [model evolution and details, ~45 min]
The Beam Model [model evolution and details, ~45 min]
![The Beam Model [model evolution and details, ~45 min]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e1eb7b5818c593d0cb9cb3a81c34957f2b8fa527/height=288;version=1;width=512/https%3A%2F%2Flh7-us.googleusercontent.com%2Fdocs%2FAHkbwyJzK9M75qNoUty8DjEZDwMbgyR9stjbwQyeDAjhBPemZg0xe9aRnwBPAHYV2R75KaCjhxIjWYE83-Qm3fmD_qOnzJVZ34JLSbT1tHNT9HksKK-kQpo-%3Dw1200-h630-p)
Googleが考えるストリームデータ処理とは？ - Qiita
この記事は？ この記事は、ドワンゴ Advent Calendar 2016の14日目の記事です。 この記事で書いている内容は？ Googleが出しているストリームデータ処理の資料を要約したものです。 つまり、「Googleが考えるストリームデータ処理とは？」ということになるかと。 趣味でストリームデータ処理について調べていたのでまとめてみます。 出来るだけよく出てくる固有の言葉を最初から使用せずに書いているつもりですが、 何かわかりにくい場所あればコメントいただけると。 「ストリーム処理」とだけ書くとストリーミング配信等とも微妙に混同しやすいため、 区別のために「ストリームデータ処理」と書いています。 基となっている情報は下記の５つです。 MillWheel: Fault-Tolerant Stream Processing at Internet Scale The Dataflow
Streaming 102: The world beyond batch
The what, where, when, and how of unbounded data processing. Introduction Welcome back! If you missed my previous post, The world beyond batch: Streaming 101, I strongly recommend you take the time to read that one first. It lays the necessary foundation for the topics I’ll be covering in this post, and I’ll be assuming you’re already familiar with the terminology and notions introduced there. Cav
ストリームでのウィンドウ集計：タンブリング(Tumbling)、ホッピング(Hopping)、スライディング(Sliding)ウィンドウ - 烏滑稽
リアルタイムストリーム処理の話でよく出てくる以下のウィンドウ集計について、パッとわかる日本語の説明がなかったから認識を書いてみた。 各項目最初の2, 3行でつまりなんなのかを説明しようとしているが、それ以降はちょっと細かい話なので混乱したくない場合は見ない方がいいかも。 時間軸での集計前提。 タンブリングウィンドウ集計 (Tumbling Window) ホッピングウィンドウ集計 (Hopping Window) スライディングウィンドウ集計 (Sliding Window) タンブリングウィンドウ集計 一言でいうと「一定時間ごとの集計」。 例えば10秒毎の流れてくるツイートを知りたいといったときにはタンブリングウィンドウ集計を選択することになる。 このウィンドウ関数を起動してから10秒たったらその10秒間のツイート数が、さらにその10秒後にはその10秒間のツイート数が取得できる感じ。 ポ
Streaming 101: The world beyond batch
Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful. Learn more As someone who’s worked on massive-scale streaming systems at Google for the last five+ years (MillWheel, Cloud Dataflow), I’m delighted by this streaming zeitgeist, to say the least. I’m also interested in making sure that folks understand everything that
Kafka Summit NYCに見るストリーミングデータETLの話 #streamdatajp
ストリームデータ処理技術勉強会 発表資料 https://futureofdata.connpass.com/event/60300/
Reactive Streamsとは？ - たけぞう瀕死ブログ
Reactive Streamsというのはノンブロッキングなback pressure可能な非同期ストリーム処理の標準的な仕様を提供しようというもので、実装としてはAkka Streams、RxJava、Reactor Composable、Ratpackなどがあります。 Reactive StreamsについてはAkkaのコミッタであるKonrad Malawskiさんの以下のスライドがとてもわかりやすいです。 2014 akka-streams-tokyo-japanese from Konrad Malawski ストリーム処理（というか非同期メッセージング全般に言えることですが）では受信側の処理能力を超えるデータを送信し続けるといずれキャパシティを超えてオーバーフローが発生してしまうため、送信側に比べて受信側の処理能力が低い場合は送信側が手加減してデータを送信する必要があります。な
ストリーム処理とは何か？＋2016年の出来事 - Qiita
この記事で書いている内容は？ ストリーム処理とはそもそも何かからはじまり、必要になる検討ポイントなどの情報を振り返り用にまとめたものです。 あとは、今年個人的にこの分野に影響が大きかったと思ったイベントをまとめています。 他の方へ説明する際のベースとするためにまとめているため、 既にこの分野を知っている方にとっては冗長な内容も多いかもしれませんが、 その場合は適宜読み飛ばしていただけると。 あと、私の他記事からも内容引っ張ってきているのでかぶりはあると思います。 特にGoogleが考えるストリームデータ処理とは？とは目的もかぶっているので相応に被りがあるかと・・・ 出来るだけよく出てくる固有の言葉を最初から使用せずに書いているつもりですが、 何かわかりにくい場所あればコメントいただけるとありがたいです。 「ストリーム処理」とだけ書くと微妙にストリーミング配信等とも混同しやすいですが、 デー
PowerTrack API
<g> <g> <defs> <rect id="SVGID_1_" x="-468" y="-1360" width="1440" height="3027" /> </defs> <clippath id="SVGID_2_"> <use xlink:href="#SVGID_1_" style="overflow:visible;" /> </clippath> </g> </g> <rect x="-468" y="-1360" class="st0" width="1440" height="3027" style="fill:rgb(0,0,0,0);stroke-width:3;stroke:rgb(0,0,0)" /> <path d="M13.4,12l5.8-5.8c0.4-0.4,0.4-1,0-1.4c-0.4-0.4-1-0.4-1.4,0L12,10.6L6.2
Consuming streaming data
<g> <g> <defs> <rect id="SVGID_1_" x="-468" y="-1360" width="1440" height="3027" /> </defs> <clippath id="SVGID_2_"> <use xlink:href="#SVGID_1_" style="overflow:visible;" /> </clippath> </g> </g> <rect x="-468" y="-1360" class="st0" width="1440" height="3027" style="fill:rgb(0,0,0,0);stroke-width:3;stroke:rgb(0,0,0)" /> <path d="M13.4,12l5.8-5.8c0.4-0.4,0.4-1,0-1.4c-0.4-0.4-1-0.4-1.4,0L12,10.6L6.2
Documentation Home
<g> <g> <defs> <rect id="SVGID_1_" x="-468" y="-1360" width="1440" height="3027" /> </defs> <clippath id="SVGID_2_"> <use xlink:href="#SVGID_1_" style="overflow:visible;" /> </clippath> </g> </g> <rect x="-468" y="-1360" class="st0" width="1440" height="3027" style="fill:rgb(0,0,0,0);stroke-width:3;stroke:rgb(0,0,0)" /> <path d="M13.4,12l5.8-5.8c0.4-0.4,0.4-1,0-1.4c-0.4-0.4-1-0.4-1.4,0L12,10.6L6.2
アクターの諸刃の剣：非同期のメッセージパッシングと状態隔離対障害モデル、そしてそれを克服するAkka Streamの可能性 - TanUkkiiのブログ
ScalaのアクターライブラリであるAkkaでは今までHTTPがIOパッケージでサポートされてきませんでした。HTTPのサポートはAkka Streamの開発とともになされたのです。なぜアクターモデルとHTTPをすぐ統合せずにStreamの登場を待つことになったのか？この疑問に答えることはアクターの問題を考えるよい題材です。 Sprayの革新とその限界 SprayはAkkaのアクターモデルとHTTPを統合して成功したフレームワークです。SprayはJVMベースのフレームワークの中で最高のパフォーマンスを誇りました。SprayはServletがもつがスレッドの高速性と、NodeJSがもつイベントループによる大量のリクエストを効率的に捌くことの特性の両立を、アクターによって可能にしたのです。 ところがSprayはアクターモデルならではの問題とも戦うことになります。Reactive Manife
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43864.pdf
The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing
MillWheel: Fault-Tolerant Stream Processing at Internet Scale
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/41378.pdf
Distributed Stream Processing Frameworks for Fast & Big Data
Event time processing in Apache Spark and Apache Flink
ETL Is Dead, Long Live Streams
