JJUG CCC 2021 Fallの 「15:00 ~ 15:50 Debeziumで変更データキャプチャを学ぼう」の資料です
JJUG CCC 2021 Fallの 「15:00 ~ 15:50 Debeziumで変更データキャプチャを学ぼう」の資料です
どうしてこの記事を書いたのか Elasticsearch/Neo4j 活用していらっしゃいますでしょうか? どちらも著名なデータベース(DB)ですが,その特徴・用途は異なります. Elasticsearch は文字情報の検索に強く,Neo4j は関連性を早く調べたいという場合に利用されているイメージです. 所感ですが,Neo4j でもデータのプロパティを基準にクエリをかけたいこともありますし,Elasticsearch に入っているデータ同士を紐づけたいことも往々にしてあります. しかし,愚直にそうしてしまうとスループットが低くなったり,実装に継続的な作りこみが必要だったり,なかなか考え物です. そこで,データ構造を見直しつつ何とか良いとこ取りできないかなと検討するようになりました. Neo4j と Elasticsearch の連携を行うことで, Elasticsearchに投入したデー
こんにちは!POSグループのhktです。 こちらの記事は、「S3のコスト削減に失敗した話」の後編になります。 もしまだ前編をご覧になっていない方は、ぜひ読んでみてください。 さて、前編では、S3のコストを調査したところ、最も費用がかかっているのがPutObjectであることが判明しました。 今回は、S3のコストを削減するために、PutObjectの実行回数を減らすことはできないか検討しました。 PutObjectの実行回数を減らしたい POSグループが運用するAWSアカウントでは、ログデータをS3に保存するために、Kinesis Data StreamsをトリガーとするLambda関数が稼働しています。 具体的には、以下のような構成になっています。HandsPOSアプリからKinesis Data Streamsにログデータが送信され、Kinesis Data StreamsからLambd
Akka Streams が2.4以降からexperimentalを外して、正式版をリリースしました。丁度会社で3日のHackerDaysを機に、Akka Streams を勉強しはじめました。 この記事では、AkkaStreamの公式ドキュメントを抜粋し、翻訳しながら、AkkaStreamの基礎概念を説明します。 Akka Streams ってなに 背景 今のInternet上、我々は膨大なデータを消費している。その大量のデータを人々はビッグデータと呼んでいるw。 もう昔みたいにデータを全部ダウンロードして処理、処理完了してアップロード的な処理は時間掛かりすぎ、そもそも一台のサーバに保存しきれないデータは処理できないので、Streamみたいな流れとしての処理が必要になっている。 Akkaが使うActorモデルもその一例、データを分割し、メッセージとしてActorに送る、Actorは只々流
“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
これは何? こんにちは。 dely株式会社でデータエンジニアをしておりますharry(@gappy50)です。 この記事は、昨年書いた以下の記事の続きの記事になります。 SnowflakeではDynamic TablesのPuPrが開始されており、宣言的なデータパイプラインの全貌徐々に見え隠れしております。 また、これに追従する形でdbt1.6でもMaterialized View(SnowflakeではDynamic Table)をサポートしはじめました。 このDynamic Tablesのメリットとして一番わかりやすいのは、ニアリアルタイムなストリーミングパイプラインをクエリを書くだけで実現が可能になる面だと思います。 これまではモデルを作成したあとのワークロードの実行は dbt build を実行するタイミングとなってしまうため、リアルタイムなデータパイプラインの構築が難しい側面があ
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
はじめに 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
1.はじめに Snowflake を用いたデータ分析基盤の構築案件が増えており、筆者も参画しています。近年では扱うデータ量として、RAWデータ、および、ETL処理を行うデータに関しては、100TBオーダーからPBオーダーになってきています。担当案件でも、1年間でETL処理のパイプラインを通過するデータの総量は約1PBという目標で進めています。 これだけのデータ量であっても、データの鮮度に関して、数年前から見ると高いレベルが求められている印象を受けます。担当しているプロジェクトでも目標値ではありますが、遅れが5分以内のニアリアルタイムでの鮮度を目指すという話が聞こえ始めました。 一方、SnowflakeのETL処理向けの新機能として、Dynamic Tables という機能がパブリックプレビューとして利用可能になっています。詳細は後続の章に記載しますが、データ変換の結果になる変換後テーブルを
耐障害性と拡張性のあるストリーム処理基盤が欲しい、と思ってApache Flinkを調べている. 今はリアルタイム集計にNorikraを使っていて、これはとてもカジュアルに使えて良いのだけど、以下の様なケースだと難しい。 比較的止めたくない処理で、サーバ障害時にも自動的に回復して欲しい 1日とか長いtime windowの集計をしているので、途中でサーバが落ちて集計中の状態が失われると辛い トラフィックが増えてきて、複数サーバに負荷を分散したい 例えばストリームに含まれているIDに対応する値を外部のテーブルから取ってくるような、ちょっと複雑な処理をしたい Flinkとはどのようなソフトウェアか 一言で言うと、対障害性と拡張性を備えた、分散ストリーム処理基盤。バッチ処理もストリーム処理の仕組みでできるよね、ということでバッチ用、ストリーム用両方のAPIが提供されている。実行環境としては、Ha
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
このエントリはスターフェスティバル株式会社の スターフェスティバル Advent Calendar 2022 16日目記事でもあります。 みなさんは開発する時にどう考えていますか? 大した内容ではありませんが、今回は開発をする上で 「どう考えて設計して表現していくか」、という永遠の悩みの中で 自分が複雑な物事に立ち向かう時の頭の中を少し書き出してみようと思います。 各カンファレンスなどで話しているものを結合したものではあります。 一緒に仕事をしたりしている方々にはお馴染みの話です 前半くらいは前提の話や分析の思考、 後半はイベント駆動などにおけるメッセージについて という流れになってます。 ちなみに自身はスターフェスティバルではアプリケーション全般の開発には関わっていますが、 主にデータ基盤やデータドリブンなマインドを伝播させていくことや、 データを使った戦略を立てながらのプロダクト作りや
技術部データ基盤チームの@tosh2230です。 2023/04/11(火)に、ファインディ株式会社主催のLTとパネルで学ぶ データ基盤アーキテクチャトレンド 2023にてChange Data Capture(CDC)の事例を紹介しました。関係者の皆様に感謝を申し上げます。 この記事では、発表した内容と質疑応答への回答、その後の動向についてお伝えします。 発表内容 ニアリアルタイム分析の実現に向けた取り組みの概要と、本番稼働したばかりのCDCデータパイプラインの詳細についてご紹介しました。 CDCを行うツールとして、今回はDebezium Serverを選びました。Debezium Serverは日本国内では事例が少ないのですが、コンテナで軽量にCDCを実現できる良い手段だと思います。 質疑応答 発表後にいただいた質問への回答を記載します。当日うまく答えられた自信はありませんが、下記の内
Cloud Native Computing Foundation(CNCF)が公開しているYouTubeチャネルから、Kafkaに替わるストリーミングプロセッシングを行うオープンソースソフトウェアFluvioを解説する動画を紹介する。CNCFはクラウドネイティブなシステムを普及するためのマーケティング活動の一環としてクラウドネイティブなソフトウェアを解説する動画を公開しているが、これもそのひとつだ。Fluvioを開発しているのはInfinyOnという企業で、元NGINXのエンジニアが創業したベンチャーだ。Fluvio自体はオープンソースだが、CNCFのサンドボックスプロジェクトという訳でもない。CNCFにはTremorやStrimziというストリーミングのためのソフトウェアがすでにサンドボックスとして採用されているが、そういった枠には捕らわれずに紹介をするという発想だろう。 動画:Int
ストリーム処理とバッチ処理を統合して扱えるプログラミングモデル(あるいはデータ処理のフロントエンド)である Apache Beam が、特にGoogle Cloud DataflowやApache Flinkからの利用を背景にシェアを伸ばしています。 Apache Beamの特色として、複数のプログラミング言語のSDKを持つこと・複数のバックエンド処理系(Flinkなどを指す)を持つことが挙げられますが、これがどう実現されているのかをまとめます。 目次 前提知識: Beam入門 Exampleコードからざっくり理解 Beamのプログラミング体験 Beamのコードを見てみる Beamにおけるパイプライン実行 Beamのプログラミングモデルをちゃんと理解 前提知識: Beamでは複数種類のバックエンドが使える 前提知識: Beamプログラムは多言語で記述できる 多言語・他バックエンド対応の課題
業務で 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
この記事は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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く