データ ウェアハウスの進化: SQL Server からデータ レイクハウスへ
企業がデータを保存、整理、分析する方法は変革を遂げています ここ20年で急進的。クローズドなリレーショナルモノリスからエンタープライズデータセンターへ ペタバイト規模の構造化データと非構造化データを管理できる分散クラウド プラットフォームへの移行 リアルタイム。しかし、多くのイタリアの中小企業にとって、 データウェアハウス 曖昧な概念のままですが、 投資が延期され、プロジェクトが複雑すぎて取り組むことができません。
この記事がシリーズの始まりです データ ウェアハウス、AI、デジタル トランスフォーメーション と 大企業に限定されがちな概念をアクセスしやすくすることが目的です。 SQL Server と Oracle を使用した従来のデータ ウェアハウスの基礎から始めて、最終的に到達します。 をベースとした現代建築へ データレイクハウス、進化のあらゆる段階を探索する そして、それぞれの技術的飛躍が必要となった理由。
世界のデータ ウェアハウス市場は約 1,000 ドルの価値に達しています。 390億ドル 2025年に、次に年間複合成長率 (CAGR) が 10% を超える 十年。エンタープライズセグメント (EDW) はさらに急速に成長しており、CAGR は 22.8% です。 これはテクノロジーの流行ではありません。ビジネスのあり方の構造的変革です。 データに関係します。
この記事で学べること
- データモデリングに対する古典的なキンボールアプローチとインモンアプローチの違い
- 従来のデータ ウェアハウスでは十分ではなくなった理由と、それが到達した限界
- データ レイクが新しい問題を作成しながらいくつかの問題をどのように解決したか
- Data Lakehouse とは何か、そして Apache Iceberg が市場の 78.6% を占めている理由
- Snowflake、Databricks、BigQuery、DuckDB と実際のコストを実際に比較
- 大手企業が採用するメダリオン（ブロンズ/シルバー/ゴールド）アーキテクチャ
- 量、予算、チームのスキルに基づいて適切なプラットフォームを選択する方法
データ ウェアハウス、AI、デジタル トランスフォーメーション シリーズの概要
| # | アイテム | 集中 |
|---|---|---|
| 1 | 現在位置 - データ ウェアハウスの進化 | SQL Server からデータ レイクハウスへ |
| 2 | データメッシュとデータガバナンス | データを分散化する |
| 3 | クラウドにおける ETL と ELT | 最新のデータ パイプライン |
| 4 | ビジネスのための AI と機械学習 | ビジネス予測モデル |
| 5 | リアルタイム分析 | ストリーミングとリアルタイムの意思決定 |
| 6 | データの品質と可観測性 | データの健全性を監視する |
| 7 | PNRR とデジタルトランスフォーメーション | イタリアの中小企業にとってのチャンス |
| 8 | エンドツーエンドの実践例 | データ レイクハウスをゼロから構築する |
従来のデータ ウェアハウス: 基礎
データ ウェアハウスの概念は 1990 年代に生まれ、企業はデータベースの重要性を理解し始めました。 注文、請求書、顧客記録を管理するために設計されたトランザクション (OLTP) システムは適していません データ分析用。分析クエリ用に最適化された別のシステムが必要です。 データウェアハウス (DWH)、オンライン分析処理 (OLAP) データベース。
30 年間にわたって DWH 設計を支配してきた 2 つの考え方: ビル・インモン そしてそれの ラルフ・キンボール。違いを理解する これら 2 つのアプローチは今日でも多くのアーキテクチャに影響を与えているため、これら 2 つのアプローチの相互関係は基本的なものです。 ビジネスシステム。
印門アプローチ：トップダウン
データウェアハウジングの父とされるビル・インモン氏は、次のようなアプローチを提案しています。 トップダウン: まず、集中化され正規化されたデータ ウェアハウスが構築されます (第 3 正規形、3NF)。 次に i を導き出します 火曜日の日付 各部門に特化したもの。中央の DWH 組織全体にとって唯一の信頼できる情報源として機能します。
印門アプローチの特徴
- 主題指向: データはソース アプリケーションごとではなく、トピック (顧客、製品、売上) ごとに整理されます。
- 統合: さまざまなソースからのデータが統一された規則に基づいて調整されます
- 不揮発性: アップロード後はデータは変更されず、追加されるだけです
- 時間変動: 各レコードには、履歴分析のための時間ディメンションがあります。
- 正規化 (3NF): 冗長性は軽減されますが、クエリで複雑な結合が必要になります
キンボールのアプローチ: ボトムアップ
ラルフ・キンボールは 1 つのアプローチを提案します ボトムアップ 根本的に異なる: ニーズから始める ビジネス分析と構築 次元データマート すぐに使える、 これらは次に経由して統合されます 適合寸法 (寸法は共通)。心 キンボールモデルと スタースキーマ.
-- Esempio di Star Schema per le vendite (SQL)
-- Fact Table: misure quantitative (metriche)
CREATE TABLE fact_vendite (
vendita_id BIGINT PRIMARY KEY,
data_id INT REFERENCES dim_data(data_id),
cliente_id INT REFERENCES dim_cliente(cliente_id),
prodotto_id INT REFERENCES dim_prodotto(prodotto_id),
negozio_id INT REFERENCES dim_negozio(negozio_id),
quantità INT NOT NULL,
prezzo_unitario DECIMAL(10,2) NOT NULL,
sconto DECIMAL(5,2) DEFAULT 0,
importo_totale DECIMAL(12,2) NOT NULL
);
-- Dimension Table: attributi descrittivi
CREATE TABLE dim_cliente (
cliente_id INT PRIMARY KEY,
nome VARCHAR(100),
cognome VARCHAR(100),
citta VARCHAR(50),
regione VARCHAR(50),
segmento VARCHAR(30), -- es: 'Premium', 'Standard'
data_registrazione DATE
);
-- Dimension Table: gerarchia temporale
CREATE TABLE dim_data (
data_id INT PRIMARY KEY,
data_completa DATE,
giorno INT,
mese INT,
trimestre INT,
anno INT,
giorno_settimana VARCHAR(15),
festivo BOOLEAN
);スター スキーマは直感的です。 ファクトテーブル (ファクトテーブル) 中央には、 数値指標 (数量、量、数)、 寸法表 (テーブル 次元) フィルタリングとグループ化を可能にする説明的な属性が含まれています データ (誰が、何を、どこで、いつ)。スター構造は、クエリを削減することで分析クエリを最適化します。 必要な結合の数。
インモン vs キンボール: 簡単な比較
| 待ってます | 印門（トップダウン） | キンボール (下から上) |
|---|---|---|
| データモデル | 正規化 (3NF) | 次元 (スター スキーマ) |
| 出発点 | 一元化された DWH | 部門別データマート |
| 価値を実現するまでの時間 | 長期 (数カ月/年) | 迅速 (数週間/数か月) |
| 初期費用 | 高い | コンテンツ |
| クエリの複雑さ | 高 (結合が多い) | 低い (結合が少ない) |
| 典型的なユーザー | エンタープライズ、銀行 | 中小企業、小売業、マーケティング |
古典的な ETL プロセス
どのアプローチを選択する場合でも、データはソース システムから抽出され、変換される必要があります。 そしてDWHにアップロードします。として知られるこのプロセス ETL (抽出、変換、ロード)、 数十年にわたり、あらゆるデータ ウェアハウスの心臓部として機能してきました。のようなツール SQL Server 統合サービス (SSIS), オラクルデータインテグレーター, Informatica PowerCenter e テイルンド この空間を支配してきました。
-- Esempio semplificato di ETL in SQL Server (T-SQL)
-- STEP 1: Extract - Leggere dalla sorgente operazionale
SELECT
o.order_id,
o.customer_id,
o.order_date,
oi.product_id,
oi.quantity,
oi.unit_price
FROM source_db.dbo.orders o
JOIN source_db.dbo.order_items oi
ON o.order_id = oi.order_id
WHERE o.order_date >= DATEADD(DAY, -1, GETDATE());
-- STEP 2: Transform - Pulire, arricchire, conformare
INSERT INTO staging.dbo.stg_vendite
SELECT
o.order_id AS vendita_id,
d.data_id,
c.cliente_id,
p.prodotto_id,
s.negozio_id,
oi.quantity AS quantità,
oi.unit_price AS prezzo_unitario,
ISNULL(o.discount, 0) AS sconto,
oi.quantity * oi.unit_price * (1 - ISNULL(o.discount, 0))
AS importo_totale
FROM extracted_orders o
-- Lookup nelle dimensioni per ottenere le surrogate key
JOIN dim_data d ON d.data_completa = o.order_date
JOIN dim_cliente c ON c.source_id = o.customer_id
JOIN dim_prodotto p ON p.source_id = oi.product_id
JOIN dim_negozio s ON s.source_id = o.store_id;
-- STEP 3: Load - Caricare nella fact table
INSERT INTO dwh.dbo.fact_vendite
SELECT * FROM staging.dbo.stg_vendite;このプロセスは通常夜間にスケジュールされます (バッチ処理) が完全に適切でした 企業が最新のレポートを確認するには翌日まで待つことができる場合。しかし、 世界は変わりました。
従来のデータ ウェアハウスの限界
従来の DWH は 20 年以上にわたってビジネスに貢献してきましたが、その背景には テクノロジーもビジネスも劇的に変化しました。それが必要となった制限は次のとおりです 進化:
従来の DWH の 5 つの重大な制限
- スキーマの厳格性 (Schema-on-Write): すべてのデータは構造化されている必要があります ロードする前に確認してください。新しい列を追加するか、データ型を変更する 多くの場合、スキーマの変更、ETL の更新、テストなど、数週間の作業が必要になります。 回帰、調整されたリリースの。要件が毎週変化する時代において、 この硬直性がビジネスのブレーキとなります。
- 非構造化データは除外されます: リレーショナル DWH は行を含むテーブルを管理します そしてコラム。しかし現在、企業データの 80% 以上が非構造化されています (アプリケーション ログ、 電子メール、PDF ドキュメント、画像、ビデオ、IoT データ、ソーシャル フィード。このデータは単にそうではありません 従来の DWH に入ります。
- コストの増加: SQL Server Enterprise、Oracle Database、および Teradata は、データ量とコンピューティング能力に応じて拡張します。 10TBの企業の場合 データ量を考慮しないと、ライセンスだけで年間コストが 200,000 ユーロを超える場合があります。 ハードウェア、ストレージ、専門スタッフ。
- データ遅延 (リアルタイムではない): 夜間の ETL バッチ処理によりレイテンシが発生する 12～24時間。電子商取引、金融、物流などの業界では、この遅延は許容できません。 翌日に販売異常が発見されれば、数千ユーロの損失が発生する可能性があります。
- 垂直方向のスケーラビリティ: 従来の DWH は、CPU、RAM、および ディスクを既存のサーバーに接続します (スケールアップ)。このアプローチには物理的な上限とコストがかかります 指数関数的。最新のクラウド プラットフォームは水平方向に拡張 (スケールアウト) し、 線形コストでノードをクラスターに接続します。
これらの制限は突然現れたわけではなく、徐々に蓄積されていきました。 企業データの量、種類、速度は飛躍的に増加しました。答えは これらの問題の最初の原因は、 データレイク.
データレイク: 最初の革命
データ レイクは、従来の DWH の限界への対応として 2010 年頃に誕生しました。アイデアは シンプルかつ強力: データをロードする前にスキーマを定義する (書き込み時スキーマ) の代わりに、 生データを元の形式で保存し、その時点でのみスキーマを適用します。 読書の（読み取り時のスキーマ）。初期の技術基盤 アパッチ・ハドゥープ HDFS 分散ファイルシステムを使用します。
データレイクの特徴
- スキーマオンリード: データは変換せずにロードされ、読み取られたときにスキーマが適用されます。
- すべてのデータ型: 構造化 (CSV、Parquet)、半構造化 (JSON、XML)、非構造化 (画像、ログ、ビデオ)
- 経済的な保管: Amazon S3、Azure Data Lake Storage、Google Cloud Storage の料金は月額 1 GB あたり数セントです
- 無制限のスケーラビリティ: クラウド ストレージはハードウェア管理なしでエクサバイトまでスケールアップできます
- オープンフォーマット: Parquet、ORC、Avro はオープン スタンダードであり、ストレージに対するベンダー ロックインはありません
# Esempio: Scrivere dati in un Data Lake con PySpark
from pyspark.sql import SparkSession
spark = SparkSession.builder \
.appName("ETL-DataLake") \
.getOrCreate()
# Leggere dati grezzi da diverse sorgenti
vendite_csv = spark.read.csv("s3://data-lake/raw/vendite/*.csv",
header=True, inferSchema=True)
log_json = spark.read.json("s3://data-lake/raw/app-logs/*.json")
# Trasformare e arricchire
vendite_pulite = vendite_csv \
.filter("importo > 0") \
.withColumn("data_elaborazione", current_timestamp()) \
.dropDuplicates(["ordine_id"])
# Salvare in formato Parquet (colonnare, compresso)
vendite_pulite.write \
.mode("append") \
.partitionBy("anno", "mese") \
.parquet("s3://data-lake/processed/vendite/")データ沼問題
データ レイクは剛性とストレージ コストの問題を解決しましたが、 新たな潜伏性の問題: データ沼 （データ沼）。ガバナンスがなければ、 カタログ作成と品質管理により、データレイクはすぐに埋め立て地と化しました そこに何があるか、誰がそこに置いたか、そしてそれがまだ信頼できるかどうか誰も知らないデータ。
管理されていないデータレイクの問題
- ACID トランザクションなし: 同時書き込みによりデータが破損する可能性があります。 ETL ジョブが途中で失敗すると、部分的なデータが残ります。
- 強制スキームなし: 何百ものプロデューサーが標準なしでデータを書き込むと、読み取り時のスキーマの自由が混乱します。
- パフォーマンスが悪い: インデックス、統計、クエリの最適化がなければ、レイクからのデータの読み取りは、DWH からのデータ読み取りよりも桁違いに遅くなります。
- タイムトラベルなし: 誰かが Parquet ファイルを上書きすると、以前のデータは永久に失われます。
- 大量の重複: 異なるチームが同じデータを異なる形式にコピーするため、一貫性のないコピーが作成されます。
データ レイクに対する不満により、多くの企業が両方の DWH を並行して維持するようになりました。 (重要な構造化データ用) とデータ レイク (未加工データおよび非構造化データ用) 重複が発生し、コストと複雑さが 2 倍になります。最善のものを組み合わせたソリューションが必要でした 両方の世界。この解決策は、 データレイクハウス.
データ レイクハウス: 両方の長所
Il データレイクハウス 柔軟性と低コストを兼ね備えたアーキテクチャ データ レイクの信頼性、パフォーマンス、およびデータ ウェアハウスのガバナンスを保証します。の 重要なコンセプトとオープンテーブル形式: メタデータの重なり合うレイヤー データ レイク (通常はオブジェクト ストレージ上の Parquet) 内のファイルに送信して ACID トランザクションを提供します。 スキーマの強制、タイムトラベル、クエリの最適化。
3 つのオープン テーブル形式
| 形式 | 作成者 | 2025 年の採用 | 強みポイント |
|---|---|---|---|
| アパッチ・アイスバーグ | Netflix (2017) | 78.6% (独占) | ベンダー中立、隠蔽パーティショニング、広範なエコシステム |
| デルタ湖 | データブリック (2019) | 39.3%（重複） | ネイティブ Spark 統合、リキッド クラスタリング |
| アパッチ・ヒューディ | ウーバー (2016) | マイナー | UPSERT と CDC (変更データ キャプチャ) 用に最適化 |
3 つのフォーマット間の競争は 2024 年から 2025 年に実質的に終了しました。 アパッチ・アイスバーグ デファクトスタンダードの地位を確立しました。 決定的なシグナルは 2024 年 6 月に到着しました。 データブリックを取得しました 表形式、Icebergの作成者によって設立された会社。データブリックス、同じ会社 Delta Lake の作成者は、Iceberg との相互運用性が長い間待ち望まれていたことを認識していました 不可欠な。 Icebergのカタログサービス市場は5億7,800万に達した 2024 年には 21.7% の年間成長が見込まれます。
# Creare una tabella Iceberg con PySpark
from pyspark.sql import SparkSession
spark = SparkSession.builder \
.appName("Lakehouse-Iceberg") \
.config("spark.sql.catalog.lakehouse", "org.apache.iceberg.spark.SparkCatalog") \
.config("spark.sql.catalog.lakehouse.type", "rest") \
.config("spark.sql.catalog.lakehouse.uri", "http://iceberg-rest:8181") \
.config("spark.sql.catalog.lakehouse.warehouse", "s3://my-lakehouse/") \
.getOrCreate()
# Creare una tabella con schema tipizzato
spark.sql("""
CREATE TABLE lakehouse.vendite.ordini (
ordine_id BIGINT,
cliente_id INT,
prodotto_id INT,
quantità INT,
importo DECIMAL(12,2),
data_ordine TIMESTAMP,
regione STRING
)
USING iceberg
PARTITIONED BY (days(data_ordine), regione)
""")
# Inserire dati con transazioni ACID
df_nuovi_ordini.writeTo("lakehouse.vendite.ordini") \
.append()
# Time Travel: leggere i dati com'erano ieri
spark.read \
.option("as-of-timestamp", "2025-06-14T00:00:00") \
.table("lakehouse.vendite.ordini") \
.show()データ レイクと比較してデータ レイクハウスがもたらすもの
- ACID トランザクション: 原子的で、一貫性があり、孤立した、長く続く文章。部分的なデータや破損したデータはもうありません。
- 進化スキーム: 既存のデータを書き換えることなく、列を追加、名前変更、または削除します。
- タイムトラベル: 監査、デバッグ、ロールバックのためにデータの履歴バージョンにアクセスします。
- クエリの最適化: 列統計、ファイル プルーニング、データ スキップにより、読み取りデータが 90% 以上削減されます。
- アップサートとマージ: CDC および SCD (Slowly Changing Dimensions) の基本となる、効率的な更新/挿入/削除操作。
- オープンフォーマット: データはオブジェクト ストレージ上の Parquet に残ります。ベンダーロックインはありません。
プラットフォームの比較: どれを選択するか?
クラウド データ プラットフォーム市場は、Snowflake、Databricks、および Google BigQuery に、ローカル分析に革命を起こす部外者が加わりました: アヒルDB。各プラットフォームには価格モデル、アーキテクチャ、およびケースがあります。 さまざまな理想的な用途を実現します。それらを詳しく見てみましょう。
プラットフォームの詳細な比較
| 特性 | 雪の結晶 | データブリック | BigQuery | アヒルDB |
|---|---|---|---|---|
| モデル | SaaS (クレジット) | PaaS (DBU) | サーバーレス | 埋め込み型（無料） |
| ストレージ/TB/月 | ~23ドル (AWS) | クラウドの直接コスト | $20 (アクティブ) | $0 (現地) |
| コンピューティング | 2 ～ 4 ドル/クレジット | $0.07+/DBU | $5/TB スキャン | $0 (ローカル CPU) |
| 一般的な月額コスト (PMI) | 2,000ドル～10,000ドル | 1,500ドル～8,000ドル | 500ドル～5,000ドル | $0 |
| オープンテーブル形式 | 自然の氷山 | デルタ湖 + 氷山 | ビッグレイク + 氷山 | 氷山（読書） |
| 言語 | SQL、Python、Java | Python、Scala、SQL、R | SQL、Python | SQL |
| ストリーミング | スノーパイプ | 構造化ストリーミング | ネイティブストリーミング | No |
| 統合された ML/AI | コーテックスAI | MLflow、モザイク | 頂点AI | No |
| に最適 | SQLファーストのチーム | データ エンジニアリング + ML | Google エコシステム | ローカル分析、PoC |
DuckDB: 組み込み分析革命
データの世界で近年起こった最も重要なイノベーションには、次のようなものがあります。 アヒルDB、 開発者とデータの方法を根本的に変える組み込み分析データベース アナリストはデータを操作します。これを「分析用の SQLite」と考えてください。サーバーをインストールする必要はありません。 セットアップもライセンス費用もかかりません。単一のコマンドでインストールして機能します ローカルファイルに直接。
ベンチマークは明らかです。PostgreSQL で 2 時間以上かかる TPC-DS クエリは次のとおりです。 約で実行されます 400ミリ秒 DuckDB を使用します。分析ワークロードについては、DuckDB そのアーキテクチャにより、SQLite や PostgreSQL よりも 100 ～ 1000 倍高速になる可能性があります 円柱状の 実行あり ベクトル化された.
# Installare DuckDB
pip install duckdb
# Analizzare un file Parquet da 10GB senza importarlo
import duckdb
con = duckdb.connect()
# Query diretta su file Parquet (nessun import necessario)
result = con.sql("""
SELECT
regione,
EXTRACT(MONTH FROM data_ordine) AS mese,
COUNT(*) AS num_ordini,
SUM(importo) AS fatturato_totale,
AVG(importo) AS ordine_medio,
COUNT(DISTINCT cliente_id) AS clienti_unici
FROM 'vendite_2025.parquet'
GROUP BY regione, mese
ORDER BY fatturato_totale DESC
""")
result.show()
# Leggere direttamente da S3
con.sql("""
SELECT * FROM read_parquet('s3://my-bucket/data/*.parquet')
WHERE regione = 'Puglia'
LIMIT 1000
""")
# Esportare in diversi formati
con.sql("COPY (SELECT * FROM result) TO 'report.xlsx' (FORMAT GDAL)")
con.sql("COPY (SELECT * FROM result) TO 'report.csv' (HEADER)")DuckDB を使用する場合
- 探索的分析: インフラストラクチャなしで CSV、Parquet、JSON ファイルをクエリ
- プロトタイピング: Snowflake または Databricks で本番環境に移行する前に、クエリとロジックを検証します。
- 現地レポート: ラップトップ上で最大 100 GB のデータに関するダッシュボードとレポートを生成
- CI/CD パイプライン: 継続的統合パイプラインでのデータ品質テスト
- エッジコンピューティング: 組み込みデバイスまたは非ネットワーク環境での分析
DuckDB はペタバイト規模の運用ワークロードに対して Snowflake や Databricks を置き換えるものではありませんが、 アナリストが回答を必要とする、最も一般的な使用範囲に完全に対応しています 単一サーバー上のデータセットから迅速に取得できます。真っ先に動き出すイタリアの中小企業向け データ分析に向けたステップとして、DuckDB は理想的なエントリ ポイントを表します。 コストゼロ、 最小限の学習ですぐに結果が得られる.
建築メダリオン: ブロンズ、シルバー、ゴールド
選択したプラットフォームに関係なく、最新のデータ レイクハウスで最も広く採用されているアーキテクチャ そして メダリオン建築 (メダリオン アーキテクチャ)、データを次のように編成します。 品質と洗練の 3 つの段階的なレベル。各レベルにはサイクル内で特定の役割があります 生の取り込みからビジネスでの使用まで、データの寿命を守ります。
メダリオン アーキテクチャの 3 つのレベル
| レベル | 範囲 | データ品質 | 対象ユーザー |
|---|---|---|---|
| ブロンズ (未加工) | 生の取り込み、ソースの 1:1 コピー | 検証なし、受信したままのデータ | データエンジニア |
| シルバー (検証済み) | クリーニング、重複排除、構成 | 入力、重複排除、結合完了 | データエンジニア、アナリスト |
| ゴールド（ビジネス） | 集計、指標、ビジネスモデル | レポートとダッシュボードの準備ができました | ビジネスユーザー、アナリスト、ML エンジニア |
# Architettura Medallion con PySpark e Iceberg
# ============ BRONZE LAYER ============
# Ingestione grezza: copia fedele dalla sorgente
bronze_vendite = spark.read \
.format("csv") \
.option("header", "true") \
.load("s3://sources/erp/vendite_export_*.csv")
# Aggiungere metadati di ingestione
bronze_vendite = bronze_vendite \
.withColumn("_ingestion_ts", current_timestamp()) \
.withColumn("_source_file", input_file_name())
bronze_vendite.writeTo("lakehouse.bronze.vendite_raw").append()
# ============ SILVER LAYER ============
# Pulizia, tipizzazione, deduplicazione
silver_vendite = spark.table("lakehouse.bronze.vendite_raw") \
.filter("importo IS NOT NULL AND importo > 0") \
.withColumn("importo", col("importo").cast("decimal(12,2)")) \
.withColumn("data_ordine", to_timestamp("data_ordine", "dd/MM/yyyy")) \
.dropDuplicates(["ordine_id"]) \
.join(
spark.table("lakehouse.silver.dim_clienti"),
"cliente_id",
"left"
)
silver_vendite.writeTo("lakehouse.silver.vendite_clean") \
.overwritePartitions()
# ============ GOLD LAYER ============
# Aggregazioni pronte per il business
gold_fatturato = spark.sql("""
SELECT
c.regione,
c.segmento,
DATE_TRUNC('month', v.data_ordine) AS mese,
COUNT(*) AS num_ordini,
SUM(v.importo) AS fatturato,
AVG(v.importo) AS ordine_medio,
COUNT(DISTINCT v.cliente_id) AS clienti_attivi
FROM lakehouse.silver.vendite_clean v
JOIN lakehouse.silver.dim_clienti c ON v.cliente_id = c.cliente_id
GROUP BY c.regione, c.segmento, DATE_TRUNC('month', v.data_ordine)
""")
gold_fatturato.writeTo("lakehouse.gold.fatturato_mensile") \
.overwritePartitions()メダリオン アーキテクチャは単なる技術的なパターンではありません。 組織契約。 ブロンズ レイヤーはデータ エンジニアリング チームの責任であり、シルバー レイヤーはデータ エンジニアリング チーム間で共有されます。 エンジニアリングと分析のゴールド レイヤーはビジネスと共同設計されています。この分離は、 レイクハウス テーブル形式のトランザクション保証と組み合わせることで、責任が排除されます。 データ沼地問題を解決し、データを管理および統制された企業資産にします。
イタリアの状況: 機会と遅れ
イタリアはデジタル変革における逆説的なパノラマを提示しています。一方で、 移行計画 5.0 PNRR のおかげで、大量のリソースが利用可能になりました ビジネスのデジタル化には、2024～2025 年の 2 年間で 63 億ユーロ。一方では、 導入率は依然として劇的に低いままです。
イタリアの中小企業における AI の現状
- のみ8.2% イタリアの製造業中小企業の 1 つは少なくとも 1 つの AI テクノロジーを統合しているのに対し、米国企業の 40% 以上
- イタリアの AI 市場は 12 億ユーロ (年間 58% 増加) の価値がありますが、成長は大企業に集中しています
- トランジション 5.0 の資金は 2025 年 11 月 6 日に枯渇し、GSE プラットフォームは早期に閉鎖されました。
- 実績予算は当初計画より約38億円減の25億円に修正
- ソフトウェア 4.0 に対する税額控除が廃止され、中小企業にインセンティブ格差が生じている
このギャップはリスクであると同時にチャンスでもあります。中小企業が現在投資しているのは、 独自のデータ インフラストラクチャと、DuckDB やオープン ソース ツールなどのアクセス可能なソリューションも備え、 次のインセンティブ サイクルが始まると、競争上の優位性を得ることができます。 利用可能です。始めるのに何百万ユーロも必要ありません。明確な戦略と 正しいスキル。
選び方: 実践的な意思決定ガイド
適切なプラットフォームの選択は、データ量、 利用可能な予算とチームのスキル。実際の意思決定ツリーは次のとおりです。
意思決定ツリー: どのプラットフォームを選択するか
| シナリオ | データ量 | 年間予算 | 推奨プラットフォーム |
|---|---|---|---|
| スタートアップ / PoC | 100GB未満 | 1,000 ユーロ未満 | アヒルDB + 寄木細工のファイル |
| 中小企業 - 最初のステップ | 100GB～1TB | 1,000 - 10,000ユーロ | BigQuery (クエリごとに支払い) |
| PMI - SQL チーム | 1～10TB | 10,000 - 50,000 ユーロ | 雪の結晶 |
| PMI - データ/ML チーム | 1～10TB | 10,000 - 50,000 ユーロ | データブリック |
| 企業 | > 10TB | > 50,000ユーロ | データブリック o 雪の結晶 + 氷山 |
| Google エコシステム | どれでも | 変数 | BigQuery + 頂点 AI |
選択する前に自問すべき5つの質問
- 誰がデータを使用するのでしょうか? チームが SQL アナリストで構成されている場合は、Snowflake または BigQuery を選択するのが自然です。データ エンジニアとデータ サイエンティストがいる場合、Databricks はより高い柔軟性を提供します。
- リアルタイムは必要ですか? データを数時間ではなく数秒で利用できるようにする必要がある場合は、Databricks や BigQuery などのネイティブ ストリーミング プラットフォームが必要です。
- 非構造化データはどのくらい重要ですか? ログ、画像、ドキュメント?それらが重要な部分である場合、氷山の湖畔の家が最良の選択です。
- 社内クラウドプロバイダーとは何ですか? あなたの会社がすでに AWS を利用している場合、Snowflake と Databricks は自然な選択肢です。 GCP では、BigQuery には統合上の利点があります。
- 3年計画とは何ですか？ PoC 用に DuckDB から始めて、Snowflake または Databricks に移行することは、完全に優れた人気のある戦略です。
バッチとストリーミング: 2 つの取り込みモデル
最新のデータ アーキテクチャで理解すべき重要な点は、次の違いです。 処理 バッチ e ストリーミング。それは選択することではありません どちらか一方が適切であるかどうかを理解する必要があります。
バッチとストリーミング: いつどちらを使用するか
| 待ってます | バッチ | ストリーミング |
|---|---|---|
| レイテンシ | 時間（通常は夜行性） | 秒または分 |
| 複雑 | 低い | 高（状態管理、順序付け、失敗） |
| 料金 | コンテンツ (オンデマンドでコンピューティング) | 高 (コンピューティングは常にアクティブ) |
| ユースケース | 日次レポート、従来の ETL、ML トレーニング | 不正行為の検出、監視、リアルタイム ダッシュボード |
| 楽器 | スパーク、dbt、エアフロー | カフカ、フリンク、スパーク ストリーミング |
| 中小企業におすすめ | ここから始めます (ケースの 90%) | ビジネスで必要な場合のみ |
実践的なアドバイス: 中小企業の 90% はアーキテクチャから簡単に始めることができます バッチ、管理が簡単で安価で、大部分をカバーします。 分析ユースケースの大部分。ストリーミングは要件がある場合にのみ導入する必要があります それを正当化する明確かつ測定可能なビジネス上の理由 (例: リアルタイムの不正行為の検出、 IoT モニタリング、電子商取引におけるリアルタイムのパーソナライゼーション)。
結論と次のステップ
この記事では、データ ウェアハウジングの進化全体をモデルから説明しました。 データ レイク革命を経て、Inmon と Kimball による SQL Server と Oracle を使用したリレーショナル Hadoop とクラウド ストレージを使用し、今日では Apache Iceberg を使用した Data Lakehouse アーキテクチャに至るまで、 最先端の技術を表します。
覚えておくべき重要なポイント
- Il 従来の DWH 彼は死んでいません：彼は進化しています。スター スキーマと次元モデリングの概念は依然として基本です。
- Il データレイク ストレージ問題は解決しましたが、適切なガバナンスがなければデータ沼を生み出しました。
- Il データレイクハウス Apache Iceberg を使用すると、経済的なストレージ、ACID トランザクション、パフォーマンスの両方の長所が組み合わされます。
- アヒルDB 中小企業やアナリストにとって理想的なエントリーポイントです。コストゼロ、卓越したパフォーマンス、インフラストラクチャ不要です。
- L'メダリオン建築 (ブロンズ/シルバー/ゴールド) は、データの取り込みからビジネスまでのフローを明確かつ管理された方法で整理します。
- Il イタリア語の背景 AI 導入には大きな差があります (中小企業 8.2% 対米国 40% 以上) が、今投資している人にとってはチャンスでもあります。
シリーズの次の記事では、補完的かつ同様に重要なトピックについて取り上げます。 データメッシュとデータガバナンス。データ所有権を分散化する方法を見ていきます 品質と安全基準を維持し、完全に統合する組織的アプローチ 今日私たちが探索した湖の家の技術的なアーキテクチャを使用して。
推奨される実践的な演習
次の記事に進む前に、DuckDB をインストールしてクエリを実行してみてください。 実際のデータセットの分析。 ISTAT などのオープンソースから CSV データセットをダウンロードできます または Kaggle を使用して、1 行のコードでクエリを実行します。
# Installa DuckDB
pip install duckdb
# Una riga per analizzare qualsiasi CSV
python -c "import duckdb; duckdb.sql(\"SELECT * FROM 'dataset.csv' LIMIT 10\").show()"
# Oppure in una sessione interattiva
import duckdb
con = duckdb.connect()
# Statistiche descrittive immediate
con.sql("""
SUMMARIZE SELECT * FROM 'vendite.csv'
""").show()
# Analisi per regione
con.sql("""
SELECT
regione,
COUNT(*) AS record,
ROUND(AVG(importo), 2) AS media,
ROUND(MEDIAN(importo), 2) AS mediana
FROM 'vendite.csv'
GROUP BY regione
ORDER BY record DESC
""").show()シリーズの次の記事では、このアーキテクチャの各コンポーネントをさらに詳しく掘り下げていきます。 最新の ETL/ELT パイプラインからデータ品質まで、ビジネスに適用される AI から エンドツーエンドの実際的なケース。あなたが起業家、IT マネージャー、または将来を目指す人であれば エンジニアの皆さん、このシリーズでは、旅を始めるための実践的な知識を提供します。 あなたの会社のデジタルトランスフォーメーションを実現します。