タグ付けされた質問 「stream-processing」

3
forループの代わりに「機能的操作」を使用する必要があるのはなぜですか?
for (Canvas canvas : list) { } NetBeansは、「機能的操作」を使用することを提案しています。 list.stream().forEach((canvas) -> { }); しかし、なぜこれが好ましいのでしょうか?どちらかといえば、読みやすく、理解しにくいです。を呼び出してからstream()、forEach()パラメーター付きのラムダ式を使用していますcanvas。for最初のスニペットのループよりも優れていることはわかりません。 明らかに、私は美学だけについて話している。おそらく、ここには技術的な利点がありますが、私には欠けています。それは何ですか?代わりに2番目の方法を使用する必要があるのはなぜですか?

3
peek()を使用してストリーム要素を変更するのはアンチパターンですか?
モノのストリームがあり、それらを途中で「強化」したい場合peek()、これを行うために使用できます。たとえば: streamOfThings.peek(this::thingMutator).forEach(this::someConsumer); コードのこの時点でthingMutatorモノを変更することは正しい動作であると仮定します。たとえば、メソッドは「lastProcessed」フィールドを現在の時間に設定できます。 ただし、peek()ほとんどのコンテキストでは、「見て、触れないでください」という意味です。 ストリーム要素の突然変異にアンチパターンを使用peek()していますか? 編集: より一般的な代替アプローチは、消費者を変換することです。 private void thingMutator(Thing thing) { thing.setLastProcessed(System.currentTimeMillis()); } パラメータを返す関数に: private Thing thingMutator(Thing thing) { thing.setLastProcessed(currentTimeMillis()); return thing; } map()代わりに使用します: stream.map(this::thingMutator)... しかし、それは機能的なコード(return)を導入しpeek()、同じオブジェクトを返すことを知っているので、それがより明確であるとは確信していませんがmap()、同じクラスのオブジェクトであることは一目でさえわかりません。 さらに、peek()あなたは突然変異するラムダを持つことができmap()ますが、列車の残骸を構築する必要があります。比較する: stream.peek(t -> t.setLastProcessed(currentTimeMillis())).forEach(...) stream.map(t -> {t.setLastProcessed(currentTimeMillis()); return t;}).forEach(...) 私は思うpeek()ので、何の「神秘的」副作用はありません、バージョンが明確で、かつラムダは明らかに変異されます。同様に、メソッド参照が使用され、メソッドの名前が明らかに突然変異を暗示している場合、それも明確で明白です。 個人的には、peek()突然変異に使うことをためらわない-非常に便利だと思う。

4
実際にバイトストリームとは何ですか?
誰が実際にバイトストリームに含まれているのか説明できますか?バイト(16進データ)またはバイナリデータまたは英字のみが含まれていますか?「生データ」という用語についても混乱しています。「4バイトのデータを逆にする」ように頼まれた場合、データは16進コードまたはバイナリコードであると想定する必要がありますか?

3
コレクションを通常返す場所にストリームを返すのは正気ですか?
レガシーコードに関連付けられていないAPIを開発しているとき、結果を収集することで純粋にStreamsパイプラインで終了するメソッドを作成していることがよくあります。このように: ImmutableSet<T> deriveSomethingMeaningfulFromPrivateState() { return myPrivateThingies.stream() .map(this::ownerOfThing) .map(Owner::socialStatus) .filter(SocialStatus::isHeAFineMatey) .collect(MyCustomCollectors.toImmutableSet()); } さて、このクラスのほとんどのクライアントは通常、要素を検索してそれを反復処理するためにコレクション(この場合はImmutableSet)を必要としますが、一部のクライアントはその上にいくつかの操作をパイプできるようにストリームを持つことで利益を得ることができますコレクションから新しいストリームを取得する必要のないストリーム。したがって、ストリームを返すと、コレクションを持っている場合のオプションのスーパーセットがクライアントに提供されます(結局、常にcollect()ストリーム自体を使用できます: Stream<T> deriveSomethingMeaningfulFromPrivateState() { return myPrivateThingies.stream() .map(this::ownerOfthing) .map(Owner::socialStatus) .filter(SocialStatus::isHeAFineMatey); // No collect } このアプローチは、潜在的な欠陥が見当たらないため、試してみたいと思います。しかし、どのライブラリでもこのアプローチを見たことはありません(おそらく、Java 8の登場後にリリースされたライブラリが多くなかったためです)。既存のライブラリクラスは、通常、プライベート状態から何かを派生するときにコレクションを返します。 Java 8より前の自分がコレクションを返す場所にストリームを返すことにした場合に発生する可能性のある悪いことがありますか?または、私はここで私的状態から派生したすべてのものでアンチパターンの何かをしていますか?

2
従来のメッセージブローカーとストリーミングデータ
カフカのサイトによると: 「Kakfaは、リアルタイムデータパイプラインとストリーミングアプリの構築に使用されます。」 インターネットを広く検索して、「ストリームデータ」とは何かについて、一般に受け入れられている次の定義を見つけました。 ストリームデータは、ネットワークを介してソースから宛先に連続して流れるデータです。そして ストリームデータは本質的にアトミックではありません。つまり、データのフローストリームのどの部分も意味があり、処理可能であることを意味します。そして ストリームデータはいつでも開始/停止できます。そして 消費者は自由にデータのストリームをアタッチおよびデタッチし、必要な部分だけを処理できます さて、上で言ったことが間違っている、不完全である、または完全に間違っている場合、私を修正することから始めてください!多かれ少なかれ軌道に乗っていると仮定すると... 「ストリーミングデータ」が何であるかを理解したので、KafkaとKinesisがストリーミングデータを使用するアプリケーションの処理/仲介ミドルウェアとして自身に請求するときの意味を理解しました。しかし、それは私の興味をそそりました。KafkaやKinesisのような「ストリームミドルウェア」を、従来のメッセージブローカーのような非ストリーミングデータに使用できるかどうか。そしてその逆:RabbitMQ、ActiveMQ、Apolloなどの従来のMQをデータのストリーミングに使用できますか、または使用すべきですか? アプリケーションが処理が必要なJSONメッセージのバックエンドの一定の集中砲火を送信する例を見てみましょう。処理はかなり複雑です(検証、データの変換、フィルタリング、集計など)。 ケース#1:メッセージは映画の各フレームです。これは、フレームデータといくつかのサポートメタデータを含むビデオフレームごとに1つのJSONメッセージです ケース#2:メッセージは時系列データであり、おそらく時間の関数としての誰かのハートビートです。したがって、t = 1でのハートビートを表すメッセージ#1が送信され、t = 2でのメッセージ#2にはハートビートが含まれます。 ケース#3:データは完全にばらばらであり、時間によって、または「データストリーム」の一部として無関係です。おそらく、数百人のユーザーがボタンをクリックしてアクションを実行するアプリケーションをナビゲートすると発生する監査/セキュリティイベント Kafka / Kinesisの課金方法と「ストリーミングデータ」とは何であるかを理解すると、これらはケース#1(連続したビデオデータ)と#2(連続した時系列データ)の明らかな候補のようです。ただし、RabbitMQのような従来のメッセージブローカーがこれらの入力の両方を効率的に処理できなかった理由はわかりません。 また、ケース#3では、発生したイベントのみが提供されるため、そのイベントに対する反応を処理する必要があります。私にとってこれは、RabbitMQのような従来のブローカーが必要であることを意味します。しかし、KafkaまたはKinesisでイベントデータの処理を処理できない理由もありません。 だから基本的に、私は言うルーブリックを確立しようとしています:私はY特性を持つXデータを持っています。Kafka / Kinesisのようなストリームプロセッサを使用して処理する必要があります。または、逆に、私が判断するのに役立つもの:Z特性を持つWデータがあります。従来のメッセージブローカーを使用して処理する必要があります。 だから私は尋ねる:データ(またはそれ以外)がストリームプロセッサとメッセージブローカーの間の決定を導くのに役立つのは、どちらもストリーミングデータを処理でき、両方が(非ストリーミング)メッセージデータを処理できるからですか?


1
一方向ストリーミングオーディオデバイスにはどのような種類のバッファを実装する必要がありますか?
オーディオデータがデバイスにストリーミングされるプロジェクトに取り組んでいます。オーディオデータはオーパス経由でエンコードされ、一度に20 msのペイロードでストリーミングされます。パケット損失を完全に回避するために、ストリーミングはTCP経由で行われます。ストリーミングの目的は、オーディオの損失やジッターを発生させずに、ライブオーディオストリーミングにできる限り近づけることです。 現在、遅いインターネット接続で何が起こるか、オーディオが少しジッターすることがあります。私は現在バッファを使用していませんが、目標はできるだけ「ライブストリーミング」に近づけることができると同時にジッターを排除することです。 私はジッターバッファーを調べましたが、ジッターバッファーも両端で遅延を処理して、両端が可能な限り同期するようになっているようです。静的なバッファサイズを作成した場合、必要がなければ、ライブストリーミングの側面からそれを取り除くことになると思います。 だから、これはいくつかの質問を私に残します、それらはすべて何らかの形で関連しています。 バッファー長を検出するための適切な方法またはアルゴリズムは何ですか? 受信側のデコーダーにデータを送り始めるための最良の方法は何ですか?バッファが一定のミリ秒に達すると、20ミリ秒のペイロードでデータの供給を開始しますか? バッファーがいっぱいになった場合、再生を遅らせますか? バッファはバイトまたは時間の長さになりますか? 本当にありがとう!
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.