メダリオンアーキテクチャの構築

第2章. 基礎固め

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

家を建てるには、まず基礎を固める必要がある。同じ考え方がMedallionアーキテクチャにも当てはまる。この章は、Medallionアーキテクチャを議論する中で繰り返し登場する主要なコンポーネントとパターンを紹介し、準備の橋渡しをする。また、Medallionアーキテクチャとその階層化アーキテクチャを深く掘り下げる第3章へのセットも行う。

この章では、いくつかの核となる分野を取り上げる：

余分な着陸帯

生データがMedallionアーキテクチャに着地する前にインジェストされる予備領域

生データ

さまざまなソースから収集された未加工のデータで、さらなる変換と分析の基礎となる。

バッチ処理

データを収集し、処理した後、スケジュールされた間隔でバッチ出力するデータ処理メソッド。

リアルタイム・データ処理

バッチ処理とは対照的に、これはデータが利用可能になるとすぐに処理することで、即座の分析と意思決定を可能にする。

ETLおよびオーケストレーションツール

データの抽出、変換、ロードに不可欠であり、データエコシステム内のワークフローのオーケストレーションと自動化に重要な役割を果たす。

これらのコンポーネントをMedallionアーキテクチャに含めるかどうかはさまざまである。主要なアーキテクチャの枠組みの中に直接それらを描く実践者もいれば、ダイアグラムの外や周辺に配置し、サポート的な役割を強調することを好む実践者もいる。

また、デルタ・テーブルの管理（）についても検討する。これらのテーブルを効果的に管理する方法を理解することは、異なる Medallion レイヤーのデータプロセスの整合性と効率を維持するために極めて重要である。

この章が終わる頃には、Medallionのアーキテクチャとその演算子をより深く理解するための準備として、これらの重要な要素について基礎的な理解を深めているはずである。

前提条件

アーキテクチャの設計と実装に入る前に、データが必要だ。そのため、新しいアーキテクチャの設計と実装を開始する最初のステップは、常にターゲットとなるソースシステムを特定し、そこからデータを収集する最善の方法を見つけ出すことから始まる。この文脈では、データがMedallionアーキテクチャに統合される前に、より良い整理と変換を促進することができる、データ取り込みのための中間ランディングゾーンを使用する必要があるかどうかが大きな課題となる。続いて、データ取り込みのメソッドを決定する必要がある。バッチ処理にすべきか、リアルタイム処理にすべきか。この決定は、データ統合、オーケストレーション、テーブル管理のために選択するツールやテクニックに影響を与える。

以下の章では、前述した順序で、これらの決定事項を探っていく。この議論は、第3章で詳しく取り上げるブロンズ、シルバー、ゴールドのレイヤーを理解するための強固な土台となる。まず、ランディングゾーンを追加する必要性について議論しよう。

特別着陸帯

ランディングゾーン "は、生データがMedallionアーキテクチャに着地する前にインジェストされる予備領域（）として使われることが多い。データソースの特性など、さまざまな要因がこの選択に影響する。

例えば、外部サービスやSaaSベンダと取引する場合、ブロンズレイヤーにデータを移行する前に、データを初期ストアするためのセキュアなランディングゾーンが必要になるかもしれない。同様に、厳格なデータ取り込み要件を持つ特定のアプリケーションチームには、専用のランディングゾーンが必要になるかもしれない。このようなチームは抽出プロセスを管理し、予期せぬエラーやデータの不整合がないようにする。また、この ...