現代のデータシステムのアーキテクチャは根本的な変化を遂げています。 Ask a developer how they build data systems today, and the answer increasingly looks like this: Postgres for the application, a lakehouse for the analytics and data science. Postgresは、長い間トランザクションワークロードに好まれており、一般的な目的のオペレーティングデータベースに進化しました。信頼性があり、柔軟性があり、深く拡張可能で、顧客トランザクションやCRUDアプリケーションからリアルタイムダッシュボードやAIをサポートする製品機能に至るまですべてをサポートしています。 )、地理空間データ(PostGIS)、ベクトルおよびフルテキスト検索(pgvectorおよびpgvectorscale)など。 タイムスケール 同時に、オープン レイクハウス テクノロジーの出現は、組織がどのようにデータを規模で管理し分析するかを再定義しました。分散ストレージ、Icebergのようなオープン テーブル フォーマット、構造化データ カタログ、およびコンポーシブル クエリ エンジンは、ペタバイト規模のデータを正確に分析し、制御することを可能にしました。 驚くべきことは、これらのテクノロジーが個別に成功しているだけではなく、これらのテクノロジーがどのように頻繁に共に展開されているかです。組織はますます、操作的なワークロード(データベースによって動作する)と非操作的なワークロード(レイクハウスによって動作する)の両方をサポートする必要があり、しばしば同じソース(人、機械、デジタルシステム、またはエージェント)からのデータを使用しています。 実際、我々は、ポストグレスと湖屋を別々の世界としてではなく、操作的および分析的ニーズの全スペクトルを満たすように設計された単一のモジュールシステムの別々の層として扱う新しい、より一貫したアーキテクチャが現れると考えている。 OLTP vs OLAP ディコトミー データベースについて考える古い方法は単純だった: 取引のためのOLTP、分析のためのOLAP. あなたはPostgresを使用してアプリケーションを駆動し、夜間のETLの仕事を内部レポートやダッシュボードのためのデータストアに送りました。 現代のアプリケーションは、データ重量、顧客向け、デザインによってリアルタイムです. They blur the lines between transactional and analytical. 
 
 
 
 金融アプリケーションは、顧客ポートフォリオへのミリ秒アクセスが必要な取引エンジンを実行し、同時にリアルタイムのリスクレポートと内部ダッシュボードを供給する可能性があります。 SaaS アプリケーションはクリックを保存するだけでなく、使用率を計算し、警告を起動し、パーソナライズされたモデルを提供します。 産業用モニタリングシステムは、1時間あたり何千万ものセンサー読み込みを摂取し、異常検出と警告論理を駆使し、長期的な分析とAIモデルトレーニングのための長年の遠隔をアーカイブすることができます。 これらの使用例は例外ではありません - 彼らはすぐに規範となっています。 We increasingly see a more useful split: operational databases that power products, and lakehouses that power organizations. しかし、これらのタイプのシステムの所有権が分裂しているにもかかわらず、製品を供給するオペレーティングシステムを担当する製品エンジニアリングチームと、組織サービスとして湖のシステムを管理するデータチームは、まだお互いに話し合う必要がある。 オペレーティングメダリオンアーキテクチャ One pattern we see gaining traction is what we call an データエンジニアリングの世界で普及したメダリオンモデルにインスピレーションを得たこのパターンには、内部分析だけでなく、リアルタイムでユーザー向けのシステムをパワーアップするための銅、銀、金の層も含まれています。 オペレーティングメダリオンアーキテクチャ こちらはこれがどう見えるか: 
 
 
 
 Bronze Layer: Raw data lives in Parquet or Iceberg files on AWS S3 or similar low-cost bottomless storage systems. This data is typically immutable, append-only, and queryable by anything: query engines such as AWS Athena, DuckDB, Trino, ClickHouse, or Polars, or even directly from an operational database such as Postgres. このデータは、通常、不変であり、添付のみであり、AWS Athena、DuckDB、Trino、ClickHouse、またはPolarなどのクエリエンジンで検索可能である。 オペレーション シルバー レイヤー: クリーン、フィルタリング、検証、およびデドプリケーションされたデータは、ユーザー向け製品のリアルタイムの分析、ダッシュボード、またはアプリケーションの論理をパワーアップするために Postgres に書き込まれます。 Operational Gold Layer: Pre-aggregated data over silver data (like Postgres's materialized views or TimescaleDB's continuous aggregates) serves low-latency, high-competitive product experiences. これらは通常、銀と金の層間の一致性を確保するためにデータベース内で維持されます。 重要なことは、各層はクエリ可能であり、このデータの移動は二方向的です。 S3 から原始データまたは変換されたデータを直接 Postgres に引っ張ることができます(緊密に統合された逆の ETL に同調)。あなたは Iceberg から Iceberg テーブルに集計をロールすることができます(Postgres からの Iceberg ファイルに対する一回りまたは立場のクエリによって)。あなたはデータベースからレイクハウスに完全なスケジュールまたは単一のテーブルを継続的に同期することができます。 S3 のレイクハウスのストレージ レイクハウスのデータをデータベースに読み込むことができるように、データベースの銀と金はこれらのレイクハウスのストレージ フォーマットに書き込むことができます。 新鮮なデータを必要とするアプリケーションで観察した共通のパターンは、カフカやKinesisのような上流ストリーミングシステムから書くことです。 データベースのスケジュールとデータ検証の制約に依存するS3(順に、未修正のブロンズデータ)とPostgres(データベースのスケジュールとデータ検証の制約)の両方に、データベース内の銀テーブルとその後のゴールドアグレートが再びS3にエクスポートされ、データチームは顧客に提供された「地上の真実データ」にアクセスできるようになります。 並行 現在、各システムは懸念事項の分離を維持しています。オペレーティングデータベースは、ユーザーと不友好的なクエリの両方でロックされ、データはオープンな湖ハウスの一部として、どこにでも必要とされる場合でも提供されます。 なぜ今? 変化を駆り立てる技術力 いくつかの開発が、運用データベースや湖泊ハウスからシロード化から統合化への移行を推進している。 まず、Icebergは、スケジュールの進化、ACIDトランザクション、効率的な圧縮をサポートする安定した柔軟なテーブル形式に成熟しました。それは、複数のコンピューティングエンジンが同じデータセットから読んで書き込むことを可能にし、カタログ層がメタデータを追跡し、バッグ全体を統治するようにします。 第二に、Postgresはプラットフォームとして進化し続けています。コラムラストレージ、タイムシリーズデータ、ベクトルおよびハイブリッド検索の拡張機能 - 私たちが何年もTimescaleで構築してきたもの - Postgresは現在、リアルタイムの分析とエージェントワークフローを直接組み込む多くの製品を提供しています。そして、Postgres内から直接S3およびIcebergデータをクエリするためのサポートが発生し、S3ホストデータを直接組み込むことがますます可能になっています。 これは、事前に計算されたデータのためのデータキャッシュ レイヤーだけでなく、クエリタイムでさらなる統合、豊富化、または JOIN のための完全な SQL データベースです。 now acts as the serving layer for products incorporating both transactional and analytical data 第三に、開発者はコンポーネシビリティを期待します。一部の組織は遺産のモノリチックデータプラットフォームに閉じ込められているかもしれませんが、ほとんどの開発者やデータサイエンティストは、自分のスタックを構成し、アプリケーションのニーズを反映する方法で既知のツールを統合する柔軟性を望んでいます。 Put differently: the market is moving toward modular, open, developer-friendly architectures. What Comes Next 私たちは、データインフラの未来は、より深くオペレーティングと分析の層を統合するシステムによって形作られると信じています - Postgresと湖屋を同じコインの2つの側面として扱うシステムです。 これは、注意深いインターフェイス - 増加同期、共有カタログ、統一されたクエリ表面 - と、異質性を擁護するのではなく、それと戦う建築哲学から来るでしょう。 PostgresとIcebergの強みに基づいて、既存のレイクハウスシステムと密接に統合され、操作的および分析的忠実さを持つフルスタックデータシステムを構築することを劇的に容易にします。 これは、ETLを使用して古いシステムから新しいシステムにデータを移行するのではなく、操作的および非運用的な使用ケースに同様に役立つ一貫した近代的なデータアーキテクチャを構築することです。 トーナメントしろ

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

このオーディオは、ストーリーの元の言語で制作されています。

PostgresとLakehouseは1つのシステムになる - Here's What Comes Next

About Author

コメント

ラベル

この記事は

Related Stories

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps