タグ

streamingに関するsh19910711のブックマーク (139)

  • Debeziumで変更データキャプチャを学ぼう #jjug_ccc

    JJUG CCC 2021 Fallの 「15:00 ~ 15:50 Debeziumで変更データキャプチャを学ぼう」の資料です

    Debeziumで変更データキャプチャを学ぼう #jjug_ccc
    sh19910711
    sh19910711 2024/05/14
    "Debezium: RedHatがサポート + データベースの行レベルの変更をキャプチャする分散サービスのセット / Kafkaが嫌ならEmbedded Engineという手もある + お好みのメッセージブローカーに送信することも出来る" 2021
  • ElasticsearchとNeo4jをKafkaで連携する - Qiita

    どうしてこの記事を書いたのか Elasticsearch/Neo4j 活用していらっしゃいますでしょうか? どちらも著名なデータベース(DB)ですが,その特徴・用途は異なります. Elasticsearch は文字情報の検索に強く,Neo4j は関連性を早く調べたいという場合に利用されているイメージです. 所感ですが,Neo4j でもデータのプロパティを基準にクエリをかけたいこともありますし,Elasticsearch に入っているデータ同士を紐づけたいことも往々にしてあります. しかし,愚直にそうしてしまうとスループットが低くなったり,実装に継続的な作りこみが必要だったり,なかなか考え物です. そこで,データ構造を見直しつつ何とか良いとこ取りできないかなと検討するようになりました. Neo4j と Elasticsearch の連携を行うことで, Elasticsearchに投入したデー

    ElasticsearchとNeo4jをKafkaで連携する - Qiita
    sh19910711
    sh19910711 2024/05/09
    "Neo4j でもデータのプロパティを基準にクエリをかけたい + Elasticsearch に入っているデータ同士を紐づけたい / Neo4j Connector は Sink と Source のどちらもサポート" 2022
  • S3のコスト削減に成功した話 〜カギはバッチウィンドウ〜|ハンズラボ株式会社

    こんにちは!POSグループのhktです。 こちらの記事は、「S3のコスト削減に失敗した話」の後編になります。 もしまだ前編をご覧になっていない方は、ぜひ読んでみてください。 さて、前編では、S3のコストを調査したところ、最も費用がかかっているのがPutObjectであることが判明しました。 今回は、S3のコストを削減するために、PutObjectの実行回数を減らすことはできないか検討しました。 PutObjectの実行回数を減らしたい POSグループが運用するAWSアカウントでは、ログデータをS3に保存するために、Kinesis Data StreamsをトリガーとするLambda関数が稼働しています。 具体的には、以下のような構成になっています。HandsPOSアプリからKinesis Data Streamsにログデータが送信され、Kinesis Data StreamsからLambd

    S3のコスト削減に成功した話 〜カギはバッチウィンドウ〜|ハンズラボ株式会社
    sh19910711
    sh19910711 2024/05/04
    "S3のコストを調査したところ、最も費用がかかっているのがPutObjectで / ログデータをS3に保存するために、Kinesis Data StreamsをトリガーとするLambda関数が稼働 / バッチウィンドウ: 最大300秒間レコードをバッファリング" 2023
  • Akka Streams についての基礎概念 - Qiita

    Akka Streams が2.4以降からexperimentalを外して、正式版をリリースしました。丁度会社で3日のHackerDaysを機に、Akka Streams を勉強しはじめました。 この記事では、AkkaStreamの公式ドキュメントを抜粋し、翻訳しながら、AkkaStreamの基礎概念を説明します。 Akka Streams ってなに 背景 今のInternet上、我々は膨大なデータを消費している。その大量のデータを人々はビッグデータと呼んでいるw。 もう昔みたいにデータを全部ダウンロードして処理、処理完了してアップロード的な処理は時間掛かりすぎ、そもそも一台のサーバに保存しきれないデータは処理できないので、Streamみたいな流れとしての処理が必要になっている。 Akkaが使うActorモデルもその一例、データを分割し、メッセージとしてActorに送る、Actorは只々流

    Akka Streams についての基礎概念 - Qiita
    sh19910711
    sh19910711 2024/05/02
    "Akka Streams: バージョン2.4以降、APIを一新 + experimentalでなくなった / SourceとFlowを繋げば、新しいSourceになる、FlowとSinkを繋げば、新しいSinkになる、すべて繋げば、 RunnableFlow になる" 2016
  • Apache Beam Python SDK でパイプラインのテストコードを書く - public note

    sh19910711
    sh19910711 2024/05/01
    "Apache Beam: SDK には testing パッケージが用意 + パイプラインに対するテストコードを書けます / Beam パイプラインは、一般のコードと比較すると読んだだけでは挙動をイメージしにくい印象" 2023
  • Spark 2.0 on EMR で Structured Streaming をやってみた

    “Distributed computing (Apache Hadoop, Spark, …) Advent Calendar 2016” の 12/19 担当ということで、Spark 2.0 on EMR で Spark Streaming と Structured Streaming をやってみた結果を書きます。 この記事でやること この記事では Spark 2.0 で、現在アルファ版の Structured Streaming をやってみます。 Structured Streaming とは、Spark SQL エンジンで実現されたストリーム処理の仕組みです。 従来型の Spark Streaming は RDD を DStream とよばれる Spark Streaming 特有のモデルを導入して扱うのに対して、Structured Streaming では Spark SQL

    Spark 2.0 on EMR で Structured Streaming をやってみた
    sh19910711
    sh19910711 2024/04/29
    "Structured Streaming: Spark SQL エンジンで実現されたストリーム処理の仕組み + バッチジョブと同じ書き方で Streaming 処理を実現 / 従来型の Spark Streaming は RDD を DStream とよばれる Spark Streaming 特有のモデル" 2016
  • dbtからSnowflake Dynamic Tablesを作成してリアルタイムデータパイプラインを構築してみる

    これは何? こんにちは。 dely株式会社でデータエンジニアをしておりますharry(@gappy50)です。 この記事は、昨年書いた以下の記事の続きの記事になります。 SnowflakeではDynamic TablesのPuPrが開始されており、宣言的なデータパイプラインの全貌徐々に見え隠れしております。 また、これに追従する形でdbt1.6でもMaterialized View(SnowflakeではDynamic Table)をサポートしはじめました。 このDynamic Tablesのメリットとして一番わかりやすいのは、ニアリアルタイムなストリーミングパイプラインをクエリを書くだけで実現が可能になる面だと思います。 これまではモデルを作成したあとのワークロードの実行は dbt build を実行するタイミングとなってしまうため、リアルタイムなデータパイプラインの構築が難しい側面があ

    dbtからSnowflake Dynamic Tablesを作成してリアルタイムデータパイプラインを構築してみる
    sh19910711
    sh19910711 2024/04/23
    "宣言的なデータパイプラインの全貌徐々に見え隠れ + これに追従する形でdbt1.6でもMaterialized View(SnowflakeではDynamic Table)をサポート / ニアリアルタイムなストリーミングパイプラインをクエリを書くだけで実現" 2023
  • リアルタイムなイベントにFlafkaを使ってKafkaとデータのやり取りを行う - Qiita

    Apache FlumeやApache Kafkaはリアルタイムなイベント処理のバックエンドとして広く利用されています。これら2つのシステムは似ている部分もありますが、ユースケースによりどちらか一方、あるいは量を組み合わせて使う場合もあります。 FlumeとKafkaの違いは次のブログも参考になります。 https://www.linkedin.com/pulse/flume-kafka-real-time-event-processing-lan-jiang Apache Kafka Apache Kafkaはpub-sub、出版-購読型のシステムで、多数のシステムとの連携に広く利用されています。 [画像はhttps://kafka.apache.org/より引用] しかし、Kafkaを使う場合、一般的にプロデューサやコンシューマのためのコードを記述する必要があります。 Producer

    リアルタイムなイベントにFlafkaを使ってKafkaとデータのやり取りを行う - Qiita
    sh19910711
    sh19910711 2024/04/22
    "Apache Flume: リアルタイムなイベント処理のバックエンドとして広く利用 / Flafka: コードを記述することなくKafkaと連携 + KafkaをFlumeのソース(入力)やシンク(出力)、またはチャンネル(バッファ)として利用" 2016
  • 【Iceberg 1.5新機能】viewの紹介 - 共通メタデータ形式とバージョン管理が実現する新たな可能性 - 流沙河鎮

    はじめに Iceberg view概要 一般的なクエリエンジンにおけるviewの役割 Iceberg viewを使ってみる Iceberg viewのコンセプト メタデータ形式の共有 viewのバージョン管理 Iceberg viewの構成要素と仕組み View Metadata versionsフィールド representationsフィールド 「create_changelog_view」プロシージャによるIcebergのCDC create_changelog_view create_changelog_viewの使い方 引数 アウトプット create_changelog_viewの実行例 Tips Carry-over Rows Pre/Post Update Images ユースケースのアイデア おわりに Appendix: Viewサポートに関連するPR はじめに 2024

    【Iceberg 1.5新機能】viewの紹介 - 共通メタデータ形式とバージョン管理が実現する新たな可能性 - 流沙河鎮
    sh19910711
    sh19910711 2024/04/05
    "Iceberg 1.5: viewの仕様を定めるIceberg View Specが定義され、いくつかのCatalog実装がviewの操作をサポート / create_changelog_view: viewを活かしたSparkのStored Prodecure + 行レベルの変更をキャプチャできるため、CDCを実装する上で役に立つ"
  • Snowflake Dynamic Tables による大規模ニアリアルタイム処理に向けた基礎検証 | TECH | NRI Digital

    1.はじめに Snowflake を用いたデータ分析基盤の構築案件が増えており、筆者も参画しています。近年では扱うデータ量として、RAWデータ、および、ETL処理を行うデータに関しては、100TBオーダーからPBオーダーになってきています。担当案件でも、1年間でETL処理のパイプラインを通過するデータの総量は約1PBという目標で進めています。 これだけのデータ量であっても、データの鮮度に関して、数年前から見ると高いレベルが求められている印象を受けます。担当しているプロジェクトでも目標値ではありますが、遅れが5分以内のニアリアルタイムでの鮮度を目指すという話が聞こえ始めました。 一方、SnowflakeのETL処理向けの新機能として、Dynamic Tables という機能がパブリックプレビューとして利用可能になっています。詳細は後続の章に記載しますが、データ変換の結果になる変換後テーブルを

    Snowflake Dynamic Tables による大規模ニアリアルタイム処理に向けた基礎検証 | TECH | NRI Digital
    sh19910711
    sh19910711 2024/04/04
    "Snowflake Dynamic Tables: ソースデータに更新がかかったときに、その変更を変換後テーブルにSnowflake側で自動で反映してくれる / サイズXSの場合、1.2GB/分あたりが、更新遅延5分以内を満たせるかどうかのボーダー" 2023
  • Apache Flinkを試している - Tech Notes

    耐障害性と拡張性のあるストリーム処理基盤が欲しい、と思ってApache Flinkを調べている. 今はリアルタイム集計にNorikraを使っていて、これはとてもカジュアルに使えて良いのだけど、以下の様なケースだと難しい。 比較的止めたくない処理で、サーバ障害時にも自動的に回復して欲しい 1日とか長いtime windowの集計をしているので、途中でサーバが落ちて集計中の状態が失われると辛い トラフィックが増えてきて、複数サーバに負荷を分散したい 例えばストリームに含まれているIDに対応する値を外部のテーブルから取ってくるような、ちょっと複雑な処理をしたい Flinkとはどのようなソフトウェアか 一言で言うと、対障害性と拡張性を備えた、分散ストリーム処理基盤。バッチ処理もストリーム処理の仕組みでできるよね、ということでバッチ用、ストリーム用両方のAPIが提供されている。実行環境としては、Ha

    sh19910711
    sh19910711 2024/04/02
    "Stormでは各処理オペレータはstatelessになっていて、落ちると状態が失われる / Spark Streamingは正確にはストリーミングではなくてマイクロバッチなので、そのバッチの間隔にストリーム処理のwindowが左右される" 2016
  • Kafka Connect:Iceberg Sink Connectorを使ってみる

    sh19910711
    sh19910711 2024/03/10
    "Iceberg Sink Connector: KafkaのTopicをConsumeしてIcebergテーブルに取り込む + もともとTabularの製品だったが現在Apache Icebergに合流中 / テーブルの自動作成とスキーマの進化 / フィールド名とIcebergテーブルのカラムのマッピング"
  • Dataworks Summit 2017 SanJose StreamProcessing - Hadoop Source Code Reading #23 #hadoopreading

    sh19910711
    sh19910711 2024/03/09
    "Hadoop Summit → DataWorks Summitに名称を変更 / Apache Beam: バッチ処理とストリーム処理を任意のエンジンで実行できる + 2017/05/17 First stable release / Apache Storm: 2011年にTwitter社が公開 + Storm2.0からJavaコードに置き換え" 2017
  • Lambda Streaming responseで、S3に置いた大きなJSONデータを編集しながらレスポンスしたらどれくらい速いのか調べてみた | DevelopersIO

    timestamp はエポックミリ秒、value は気温を模したランダムな数値です。 deviceId には"001"の固定値を仮り置きしています。 実験の内容 3 種類の lambda 関数をそれぞれメモリサイズ 128MB, 256MB, 512MB で実行し、レスポンス完了までにかかる時間を調べました。 すべての関数とも、取得したデータを 1 ヶ月分だけに filter して返します。 1. s3 のデータを返す(stream) import { Writable, Readable } from "node:stream"; import { Handler } from "aws-lambda"; import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3"; import { chain } from "stre

    Lambda Streaming responseで、S3に置いた大きなJSONデータを編集しながらレスポンスしたらどれくらい速いのか調べてみた | DevelopersIO
    sh19910711
    sh19910711 2023/08/12
    "Lambda が stream レスポンスを返せるようになりました / 6MB よりも巨大なレスポンスを返すことができます / 巨大な json を stream のまま編集 / stream のまま扱うことで展開する memory のサイズを抑えることができます"
  • 現状と向き合ってシステムを考える時の頭の中をちょっとだけ - ytake blog

    このエントリはスターフェスティバル株式会社の スターフェスティバル Advent Calendar 2022 16日目記事でもあります。 みなさんは開発する時にどう考えていますか? 大した内容ではありませんが、今回は開発をする上で 「どう考えて設計して表現していくか」、という永遠の悩みの中で 自分が複雑な物事に立ち向かう時の頭の中を少し書き出してみようと思います。 各カンファレンスなどで話しているものを結合したものではあります。 一緒に仕事をしたりしている方々にはお馴染みの話です 前半くらいは前提の話や分析の思考、 後半はイベント駆動などにおけるメッセージについて という流れになってます。 ちなみに自身はスターフェスティバルではアプリケーション全般の開発には関わっていますが、 主にデータ基盤やデータドリブンなマインドを伝播させていくことや、 データを使った戦略を立てながらのプロダクト作りや

    現状と向き合ってシステムを考える時の頭の中をちょっとだけ - ytake blog
    sh19910711
    sh19910711 2023/07/29
    "メッセージの定義は時の流れとともに変更されていきます / Debeziumでoutboxパターンをサポートしてくれる機能があります / Protocol BuffersのOptional なども理解しておきましょう"
  • Debezium ServerによるChange Data Captureの事例紹介 - Pepabo Tech Portal

    技術部データ基盤チームの@tosh2230です。 2023/04/11(火)に、ファインディ株式会社主催のLTとパネルで学ぶ データ基盤アーキテクチャトレンド 2023にてChange Data Capture(CDC)の事例を紹介しました。関係者の皆様に感謝を申し上げます。 この記事では、発表した内容と質疑応答への回答、その後の動向についてお伝えします。 発表内容 ニアリアルタイム分析の実現に向けた取り組みの概要と、番稼働したばかりのCDCデータパイプラインの詳細についてご紹介しました。 CDCを行うツールとして、今回はDebezium Serverを選びました。Debezium Serverは日国内では事例が少ないのですが、コンテナで軽量にCDCを実現できる良い手段だと思います。 質疑応答 発表後にいただいた質問への回答を記載します。当日うまく答えられた自信はありませんが、下記の内

    Debezium ServerによるChange Data Captureの事例紹介 - Pepabo Tech Portal
    sh19910711
    sh19910711 2023/04/24
    "CDCを行うツールとして、今回はDebezium Serverを選びました / 日本国内では事例が少ないのですが、コンテナで軽量にCDCを実現できる良い手段 / Debezium Serverを第一候補として進めて、不測の事態が起きた場合にはAirbyteに"
  • RustとWASMで開発されKubernetesで実装されたデータストリームシステムFluvioを紹介

    Cloud Native Computing Foundation(CNCF)が公開しているYouTubeチャネルから、Kafkaに替わるストリーミングプロセッシングを行うオープンソースソフトウェアFluvioを解説する動画を紹介する。CNCFはクラウドネイティブなシステムを普及するためのマーケティング活動の一環としてクラウドネイティブなソフトウェアを解説する動画を公開しているが、これもそのひとつだ。Fluvioを開発しているのはInfinyOnという企業で、元NGINXエンジニアが創業したベンチャーだ。Fluvio自体はオープンソースだが、CNCFのサンドボックスプロジェクトという訳でもない。CNCFにはTremorやStrimziというストリーミングのためのソフトウェアがすでにサンドボックスとして採用されているが、そういった枠には捕らわれずに紹介をするという発想だろう。 動画:Int

    RustとWASMで開発されKubernetesで実装されたデータストリームシステムFluvioを紹介
    sh19910711
    sh19910711 2022/12/28
    "Fluvioを開発しているのはInfinyOnという企業で、元NGINXのエンジニアが創業したベンチャー / CNCFにはTremorやStrimziというストリーミングのためのソフトウェアがすでにサンドボックスとして採用されている"
  • Apache Beamが多言語・多バックエンド処理系を実現する仕組み

    ストリーム処理とバッチ処理を統合して扱えるプログラミングモデル(あるいはデータ処理のフロントエンド)である Apache Beam が、特にGoogle Cloud DataflowやApache Flinkからの利用を背景にシェアを伸ばしています。 Apache Beamの特色として、複数のプログラミング言語のSDKを持つこと・複数のバックエンド処理系(Flinkなどを指す)を持つことが挙げられますが、これがどう実現されているのかをまとめます。 目次 前提知識: Beam入門 Exampleコードからざっくり理解 Beamのプログラミング体験 Beamのコードを見てみる Beamにおけるパイプライン実行 Beamのプログラミングモデルをちゃんと理解 前提知識: Beamでは複数種類のバックエンドが使える 前提知識: Beamプログラムは多言語で記述できる 多言語・他バックエンド対応の課題

    sh19910711
    sh19910711 2022/12/27
    "2019年頃からBeamでは “Portability Framework” の導入が進められている / 例えば「JVMで動作するFlinkやDataflowなどのEngineを使いつつPythonで定義したパイプラインを実行」することが可能に"
  • Glue Schema Registry の導入を断念した話

    業務で AWS Glue Schema Registry を使おうとしたけど、やっぱりやめたというお話。 Glue Schema Registry#What’s Schema Registry?#AWS Glue Schema Registry は2020年に発表された AWS の機能だ。 Control the evolution of data streams using the AWS Glue Schema Registry一方、私が最初に schema registry 的なものを見たのは Confluent の例。 Schema Registry の概要 - ConfluentAWS の Glue Schema Registry はこれより後のリリースであり、同等のものの AWS マネージド版といったところだろうか。 schema registry で何ができるかは Confl

    Glue Schema Registry の導入を断念した話
    sh19910711
    sh19910711 2022/12/22
    "データ基盤上のストリーム処理における schema 管理はバッチ処理のそれとは異なる難しさ / application 側とデータ基盤側の中間で schema を定義・管理できるのが素晴らしい、そんなふうに考えていた時期が私にもありました"
  • Apache Kafka互換のRedpandaに触れる

    この記事はDistributed computing (Apache Spark, Hadoop, Kafka, ...) Advent Calendar 2022および気にはなってるけど触ってないビッグデータ系のツール・サービスを触る Advent Calendar 2022の15日目です。 こんにちは。Redpanda Dataでサポートエンジニアをしている @dice_redpanda です。 Redpandaは2019年創業のRedpanda Dataが開発・提供する分散ストリーミングエンジンです。 C++で開発されたRaftベースの分散ストレージの上にApache Kafka(以下Kafka)互換のAPIを提供するレイヤが組み込まれ、Kafkaの置き換えとして簡単・安全・速いを売りにしています。APIに互換性があるため、基的には全ての既存のKafkaアプリケーションはRedpa

    Apache Kafka互換のRedpandaに触れる
    sh19910711
    sh19910711 2022/12/18
    "2019年創業のRedpanda Dataが開発・提供する分散ストリーミングエンジン / C++で開発されたRaftベースの分散ストレージの上にApache Kafka互換のAPIを提供 / 既存のKafkaアプリケーションはRedpandaでも動作 + 一部未実装のAPIもあり"