Ewolucja hurtowni danych: od SQL Server do Data Lakehouse
Sposób, w jaki firmy przechowują, organizują i analizują swoje dane, przeszedł transformację radykalny w ciągu ostatnich dwudziestu lat. Przeszliśmy od zamkniętych relacyjnych monolitów do korporacyjnego centrum danych do rozproszonych platform chmurowych zdolnych do zarządzania petabajtami danych ustrukturyzowanych i nieustrukturyzowanych czasie rzeczywistym. Jednak dla wielu włoskich MŚP hurtownia danych pozostaje mglistą koncepcją, odłożona inwestycja, projekt zbyt złożony, aby się nim zająć.
Artykuł ten inauguruje serię Hurtownia danych, sztuczna inteligencja i transformacja cyfrowa z w celu udostępnienia koncepcji, które zbyt często pozostają ograniczone do dużych przedsiębiorstw. Zaczniemy od podstaw, od tradycyjnej hurtowni danych z SQL Server i Oracle, aż dotrzemy do nowoczesnych architektur opartych na Jezioro danychbadając każdy etap ewolucji oraz powody, dla których każdy skok technologiczny był konieczny.
Globalny rynek hurtowni danych osiągnął wartość ok 39 miliardów dolarów w 2025 roku, a następnie złożona roczna stopa wzrostu (CAGR) powyżej 10%. dekada. Segment przedsiębiorstw (EDW) rośnie jeszcze szybciej, z CAGR na poziomie 22,8%. To nie jest chwilowa moda: to strukturalna transformacja sposobu prowadzenia biznesu dotyczy danych.
Czego dowiesz się w tym artykule
- Różnice pomiędzy klasycznym podejściem Kimballa i Inmona do modelowania danych
- dlaczego tradycyjna hurtownia danych już nie wystarcza i jakie limity osiągnęła
- Jak Data Lake rozwiązało niektóre problemy, jednocześnie tworząc nowe
- Czym jest Data Lakehouse i dlaczego Apache Iceberg dominuje z 78,6% rynku
- Praktyczne porównanie Snowflake, Databricks, BigQuery i DuckDB z rzeczywistymi kosztami
- Architektura Medalion (Brąz/Srebro/Złoto) używana przez wiodące firmy
- Jak wybrać odpowiednią platformę w oparciu o wielkość, budżet i umiejętności zespołu
Przegląd serii hurtowni danych, sztucznej inteligencji i transformacji cyfrowej
| # | Przedmiot | Centrum |
|---|---|---|
| 1 | Jesteś tutaj - Ewolucja hurtowni danych | Od SQL Server do Data Lakehouse |
| 2 | Siatka danych i zarządzanie danymi | Decentralizacja danych |
| 3 | ETL kontra ELT w chmurze | Nowoczesne potoki danych |
| 4 | Sztuczna inteligencja i uczenie maszynowe dla biznesu | Biznesowe modele predykcyjne |
| 5 | Analityka w czasie rzeczywistym | Transmisja strumieniowa i decyzje w czasie rzeczywistym |
| 6 | Jakość danych i obserwowalność | Monitoruj stan danych |
| 7 | PNRR i transformacja cyfrowa | Szanse dla włoskich MŚP |
| 8 | Praktyczny futerał od początku do końca | Budowanie jeziora danych od podstaw |
Tradycyjna hurtownia danych: podstawy
Koncepcja hurtowni danych narodziła się w latach 90. XX wieku, kiedy firmy zaczęły rozumieć bazy danych Systemy transakcyjne (OLTP) przeznaczone do zarządzania zamówieniami, fakturami i dokumentacją klientów nie są odpowiednie do analizy danych. Potrzebujesz osobnego systemu, zoptymalizowanego pod kątem zapytań analitycznych: hurtownia danych (DWH), baza danych do przetwarzania analitycznego online (OLAP).
Przez trzy dekady w projektowaniu DWH dominują dwie szkoły myślenia: Billa Inmona i to z Ralpha Kimballa. Zrozum różnice między tymi dwoma podejściami jest fundamentalna, ponieważ nadal wpływają one na architekturę wielu współczesnych systemy biznesowe.
Podejście Inmona: od góry do dołu
Bill Inmon, uważany za ojca hurtowni danych, proponuje podejście z góry na dół: najpierw budowana jest scentralizowana i znormalizowana hurtownia danych (w trzeciej postaci normalnej, 3NF), następnie wyprowadzamy i Wtorkowa data specyficzne dla każdego działu. Centralny DWH służy jako jedyne źródło prawdy dla całej organizacji.
Charakterystyka podejścia Inmon
- Tematyczne: Dane są uporządkowane tematycznie (klienci, produkty, sprzedaż), a nie według aplikacji źródłowej
- Zintegrowany: Dane pochodzące z różnych źródeł są uzgadniane z jednolitymi konwencjami
- Nielotny: Po przesłaniu dane nie są modyfikowane, a jedynie dodawane
- Wariant czasowy: Każdy zapis ma wymiar czasowy na potrzeby analizy historycznej
- Znormalizowany (3NF): Zmniejsza nadmiarowość, ale wymaga złożonych złączeń w zapytaniach
Podejście Kimballa: oddolne
Ralph Kimball oferuje jedno podejście od dołu do góry radykalnie odmienne: zaczynając od potrzeb analityka biznesowa i budowanie wymiarowe zbiory danych natychmiast nadające się do użytku, które są następnie integrowane poprzez zgodne wymiary (wspólne wymiary). Serce modelu Kimballa i Schemat gwiazdy.
-- 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
);Schemat Gwiazdy jest intuicyjny: tabela faktów (tabela faktów) pośrodku zawiera metryki numeryczne (ilości, kwoty, liczebności), natomiast tabela wymiarów (stoły wymiarowe) zawierają atrybuty opisowe umożliwiające filtrowanie i grupowanie dane (kto, co, gdzie, kiedy). Struktura gwiazdy optymalizuje zapytania analityczne poprzez redukcję wymaganą liczbę złączeń.
Inmon kontra Kimball: szybkie porównanie
| Czekam | Inmon (z góry na dół) | Kimball (od dołu do góry) |
|---|---|---|
| Model danych | Znormalizowany (3NF) | Wymiarowy (schemat gwiazdy) |
| Punkt wyjścia | Scentralizowany CWU | Departamentowe Marty Danych |
| Czas na wartość | Długie (miesiące/lata) | Szybki (tygodnie/miesiące) |
| Koszt początkowy | Wysoki | Treść |
| Złożoność zapytania | Wysoka (wiele połączeń) | Niski (kilka połączeń) |
| Typowy użytkownik | Przedsiębiorstwo, bankowość | MŚP, handel detaliczny, marketing |
Klasyczny proces ETL
Niezależnie od wybranego podejścia, dane muszą zostać wydobyte z systemów źródłowych i poddane transformacji i przesłane do DWH. Proces ten, tzw ETL (wyodrębnij, przekształć, załaduj), i od dziesięcioleci jest bijącym sercem każdej hurtowni danych. Narzędzia takie jak Usługi integracji SQL Server (SSIS), Integrator Danych Oracle, Informatyka Power Center e Taland zdominowały tę przestrzeń.
-- 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;Ten proces, zwykle planowany na noc (przetwarzanie wsadowe), był całkowicie odpowiedni kiedy firma mogła poczekać do następnego dnia, aby zobaczyć zaktualizowane raporty. Ale świat się zmienił.
Ograniczenia tradycyjnej hurtowni danych
Tradycyjny DWH dobrze służy firmom od ponad dwóch dekad, ale kontekst technologiczne i biznesowe i uległo radykalnej zmianie. Oto ograniczenia, które uczyniły to koniecznym ewolucja:
Pięć krytycznych ograniczeń tradycyjnego DWH
- Sztywność schematu (Schemat przy zapisie): Każde dane muszą mieć strukturę i dostosowane przed załadunkiem. Dodaj nową kolumnę lub zmień typ danych często wymaga tygodni pracy: modyfikacji schematu, aktualizacji ETL, testowania regresji, skoordynowane uwolnienie. W czasach, gdy wymagania zmieniają się co tydzień, ta sztywność jest hamulcem w biznesie.
- Wyłączone dane nieustrukturyzowane: Relacyjny DWH zarządza tabelami z wierszami i kolumny. Jednak obecnie ponad 80% danych korporacyjnych jest nieustrukturyzowanych: dzienniki aplikacji, e-maile, dokumenty PDF, obrazy, filmy, dane IoT, kanały społecznościowe. Te dane po prostu nie wchodzą do tradycyjnego DWH.
- Rosnące koszty: SQL Server Enterprise, baza danych Oracle i Teradata skaluje się wraz z ilością danych i mocą obliczeniową. Dla firmy z 10 TB danych, roczne koszty mogą przekroczyć 200 000 EUR za same licencje, nie licząc sprzęt, magazynowanie i wyspecjalizowany personel.
- Opóźnienie danych (bez czasu rzeczywistego): Nocne grupowanie ETL wprowadza opóźnienia 12-24 godziny. W branżach takich jak e-commerce, finanse i logistyka takie opóźnienie jest nie do przyjęcia: anomalia sprzedażowa wykryta następnego dnia może oznaczać utratę tysięcy euro.
- Skalowalność pionowa: Tradycyjne DWH skaluje się poprzez dodanie procesora, pamięci RAM i dysk do istniejącego serwera (skalowanie). To podejście ma fizyczny pułap i koszty wykładniczy. Nowoczesne platformy chmurowe skalują się w poziomie (skalowanie w poziomie), dodając węzłów do klastra z kosztami liniowymi.
Ograniczenia te nie pojawiły się nagle: narastały stopniowo w miarę jak ilość, różnorodność i prędkość danych korporacyjnych wzrosła wykładniczo. Odpowiedź Początkowym problemem tych problemów był Jezioro danych.
Jezioro danych: pierwsza rewolucja
Data Lake narodziło się około 2010 roku jako odpowiedź na ograniczenia tradycyjnego DWH. Pomysł jest taki proste i wydajne: zamiast definiowania schematu przed załadowaniem danych (schemat przy zapisie), przechowujesz surowe dane w oryginalnym formacie i stosujesz schemat tylko w tej chwili czytania (schemat w trakcie odczytu). Wstępne podstawy technologiczne tj Apache Hadoopa z rozproszonym systemem plików HDFS.
Charakterystyka jeziora danych
- Schemat w trakcie odczytu: Dane są ładowane bez transformacji, schemat obowiązuje przy ich czytaniu
- Wszystkie typy danych: Strukturalny (CSV, Parquet), półstrukturalny (JSON, XML), niestrukturalny (obrazy, logi, filmy)
- Ekonomiczne przechowywanie: Amazon S3, Azure Data Lake Storage, Google Cloud Storage kosztują kilka centów za GB miesięcznie
- Nieograniczona skalowalność: Pamięć masowa w chmurze można skalować do eksabajtów bez zarządzania sprzętem
- Otwarte formaty: Parkiet, ORC, Avro to otwarte standardy, brak zależności od dostawcy w zakresie przechowywania
# 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/")Problem bagna danych
Jezioro danych rozwiązało problem sztywności i kosztów przechowywania, ale stworzyło nowy i podstępny problem: Bagno Danych (bagno danych). Bez zarządzania, katalogowania i kontroli jakości, jeziora danych szybko zamieniły się w wysypiska śmieci danych tam, gdzie nikt nie wie, co tam jest, kto je tam umieścił i czy są nadal wiarygodne.
Problemy niekontrolowanego jeziora danych
- Brak transakcji ACID: Równoczesne zapisy mogą uszkodzić dane. Zadanie ETL, które zakończy się niepowodzeniem w połowie, pozostawia częściowe dane.
- Brak schematu egzekwowania: Swoboda odczytu schematów staje się chaosem, gdy setki producentów zapisują dane bez standardów.
- Słaba wydajność: Bez indeksów, statystyk i optymalizacji zapytań odczyt danych z jeziora jest o rząd wielkości wolniejszy niż z DWH.
- Żadnych podróży w czasie: Jeśli ktoś nadpisze plik Parquet, poprzednie dane zostaną utracone na zawsze.
- Ogromne powielanie: Różne zespoły kopiują te same dane do różnych formatów, tworząc niespójne kopie.
Frustracja związana z jeziorem danych skłoniła wiele firm do równoległego utrzymywania obu rozwiązań DWH (dla krytycznych danych strukturalnych) i Data Lake (dla danych surowych i nieustrukturyzowanych). powielanie, podwojenie kosztów i złożoności. Potrzebowaliśmy rozwiązania, które łączyłoby w sobie to, co najlepsze oba światy. To rozwiązanie jest Jezioro danych.
Data Lakehouse: to, co najlepsze z obu światów
Il Jezioro danych oraz architekturę, która łączy w sobie elastyczność i niskie koszty jeziora danych z gwarancjami niezawodności, wydajności i zarządzania hurtownią danych. The kluczowa koncepcja iOtwórz format tabeli: nakładająca się warstwa metadanych do plików w jeziorze danych (zazwyczaj Parquet on object Storage) w celu zapewnienia transakcji ACID, egzekwowanie schematów, podróże w czasie i optymalizacja zapytań.
Format trzech otwartych stołów
| Format | Stworzony przez | Adopcja 2025 | Punkt siły |
|---|---|---|---|
| Góra lodowa Apache | Netflixa (2017) | 78,6% (wyłącznie) | Neutralny dla dostawcy, ukryty podział, szeroki ekosystem |
| Jezioro Delty | Kostki danych (2019) | 39,3% (nakładanie się) | Integracja z natywną platformą Spark, płynne klastrowanie |
| Apache Hudi | Ubera (2016) | Drobny | Zoptymalizowany pod kątem upsert i CDC (przechwytywanie zmian danych) |
Rywalizacja między trzema formatami zasadniczo zakończyła się w latach 2024–2025, kiedy to Góra lodowa Apache który osiągnął pozycję de facto standardu. Decydujący sygnał nadszedł w czerwcu 2024 r., kiedy Zdobyto kostki danych Tabelaryczne, firma założona przez twórców Iceberg. Databricks, ta sama firma który stworzył Delta Lake, uznał, że interoperacyjność z Iceberg była już dawno oczekiwana istotne. Rynek usług katalogowych dla Iceberg osiągnął 578 milionów dolarów w 2024 r., przy oczekiwanym rocznym wzroście na poziomie 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()Co oferuje Data Lakehouse w porównaniu z Data Lake
- Transakcje ACID: Pisma atomowe, spójne, izolowane i długotrwałe. Nigdy więcej częściowych lub uszkodzonych danych.
- Schemat ewolucji: Dodawaj, zmieniaj nazwy lub usuwaj kolumny bez przepisywania istniejących danych.
- Podróż w czasie: Uzyskaj dostęp do dowolnej historycznej wersji danych w celu audytu, debugowania lub wycofania zmian.
- Optymalizacja zapytań: Statystyki kolumn, czyszczenie plików i pomijanie danych zmniejszają odczyt danych o ponad 90%.
- Wstaw i połącz: Wydajne operacje aktualizacji/wstawiania/usuwania, podstawowe dla CDC i SCD (powoli zmieniające się wymiary).
- Otwarte formaty: Dane pozostają w Parquet w magazynie obiektowym. Brak blokady dostawcy.
Porównanie platform: którą wybrać?
Rynek platform danych w chmurze jest zdominowany przez trzech gigantów: Snowflake, Databricks i Google BigQuery, do którego dołącza osoba z zewnątrz, która rewolucjonizuje analitykę lokalną: DuckDB. Każda platforma ma model cenowy, architekturę i obudowę różnych idealnych zastosowań. Zobaczmy je szczegółowo.
Szczegółowe porównanie platform
| Charakterystyczny | Płatki śniegu | Kostki danych | BigQuery | DuckDB |
|---|---|---|---|---|
| Model | SaaS (kredyty) | PaaS (DBU) | Bezserwerowy | Wbudowany (bezpłatny) |
| Miejsce na dane/TB/miesiąc | ~23 USD (AWS) | Bezpośredni koszt chmury | 20 USD (aktywny) | 0 USD (lokalnie) |
| Obliczać | 2-4 USD/kredyt | 0,07 USD +/DBU | Zeskanowano 5 USD/TB | 0 $ (lokalny procesor) |
| Typowy koszt miesięczny (PMI) | 2000-10 000 dolarów | 1500-8000 dolarów | 500-5000 dolarów | $0 |
| Otwórz format tabeli | Rodzima góra lodowa | Jezioro Delta + góry lodowe | Wielkie Jezioro + Góra Lodowa | Góra lodowa (czytanie) |
| Język | SQL, Python, Java | Python, Scala, SQL, R | SQL, Python | SQL-a |
| Transmisja strumieniowa | Śnieżka | Strukturalne przesyłanie strumieniowe | Natywne przesyłanie strumieniowe | No |
| Zintegrowane ML/AI | Kora AI | MLflow, mozaika | Wierzchołkowa sztuczna inteligencja | No |
| Idealny dla | Zespoły korzystające z SQL | Inżynieria danych + ML | Ekosystem Google’a | Analityka lokalna, PoC |
DuckDB: rewolucja w zakresie wbudowanej analityki
Do najważniejszych innowacji ostatnich lat w świecie danych zalicza się DuckDB, wbudowana analityczna baza danych, która zasadniczo zmienia sposób, w jaki programiści i dane analitycy pracują z danymi. Pomyśl o tym jak o „SQLite do celów analitycznych”: nie trzeba instalować serwerów, bez konfiguracji, bez kosztów licencji. Instaluje się za pomocą jednego polecenia i działa bezpośrednio na plikach lokalnych.
Testy porównawcze są jasne: zapytanie TPC-DS, które w PostgreSQL zajmuje ponad 2 godziny, jest wykonano w ok 400 milisekund z DuckDB. W przypadku obciążeń analitycznych DuckDB ze względu na swoją architekturę może być 100-1000 razy szybszy niż SQLite lub PostgreSQL kolumnowy z wykonaniem wektoryzowane.
# 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)")Kiedy używać DuckDB
- Analiza eksploracyjna: Zapytaj o pliki CSV, Parquet, JSON bez infrastruktury
- Prototypowanie: Sprawdź zapytania i logikę przed przeniesieniem ich do środowiska produkcyjnego w Snowflake lub Databricks
- Raporty lokalne: Generuj dashboardy i raporty dotyczące danych do 100 GB na laptopie
- Potok CI/CD: Testowanie jakości danych w potokach ciągłej integracji
- Przetwarzanie brzegowe: Analityka na urządzeniach wbudowanych lub w środowiskach niesieciowych
DuckDB nie zastępuje Snowflake ani Databricks w przypadku petabajtowych obciążeń produkcyjnych, ale obejmuje doskonale ten zakres zastosowań, najpowszechniejszy, w którym analityk potrzebuje odpowiedzi szybko ze zbiorów danych znajdujących się na jednym serwerze. Dla włoskich MŚP, które poruszają się jako pierwsze kroki w kierunku analizy danych, DuckDB stanowi idealny punkt wejścia: zerowy koszt, minimalna krzywa uczenia się, natychmiastowe rezultaty.
Medalion Architektury: Brązowy, Srebrny, Złoty
Niezależnie od wybranej platformy, jest to najczęściej stosowana architektura w nowoczesnych jeziorach danych i Architektura medalionowa (architektura medalionowa), która organizuje dane w trzy progresywne poziomy jakości i wyrafinowania. Każdy poziom ma określoną rolę w cyklu cykl życia danych – od ich surowego spożycia po wykorzystanie w firmie.
Trzy poziomy architektury medalionowej
| Poziom | Zakres | Jakość danych | Użytkownicy docelowi |
|---|---|---|---|
| Brąz (surowy) | Surowe spożycie, kopia źródeł 1:1 | Brak walidacji, dane w postaci otrzymanej | Inżynierowie danych |
| Srebro (zatwierdzone) | Czyszczenie, deduplikacja, konformacja | Wpisano, zdeduplikowano, dołączenie gotowe | Inżynierowie danych, analitycy |
| Złoto (biznes) | Agregacje, metryki, modele biznesowe | Gotowy do raportów i dashboardów | Użytkownicy biznesowi, analitycy, inżynierowie 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()Architektura Medalionu to nie tylko wzór techniczny: to: umowa organizacyjna. Za warstwę brązową odpowiada zespół inżynierii danych, a warstwa srebrna jest współdzielona inżynierii i analityki, warstwa Gold została zaprojektowana wspólnie z biznesem. To oddzielenie odpowiedzialność w połączeniu z gwarancjami transakcyjnymi w formacie tabeli Lakehouse eliminuje problem bagna danych i sprawia, że dane stają się zarządzanym i regulowanym aktywem korporacyjnym.
Kontekst włoski: możliwości i opóźnienia
Włochy przedstawiają paradoksalną panoramę transformacji cyfrowej. Z jednej strony Plan przejścia 5.0 PNRR udostępniło znaczne zasoby na cyfryzację przedsiębiorstw: 6,3 mld euro w okresie dwóch lat 2024–2025. z drugiej strony wskaźnik adopcji pozostaje dramatycznie niski.
Stan sztucznej inteligencji we włoskich MŚP
- Tylko8,2% włoskich MŚP produkcyjnych zintegrowało co najmniej jedną technologię sztucznej inteligencji w porównaniu z ponad 40% firm amerykańskich
- Włoski rynek sztucznej inteligencji jest wart 1,2 miliarda euro (+58% rocznie), ale wzrost koncentruje się w dużych firmach
- Fundusze Transition 5.0 wyczerpały się już 6 listopada 2025 r. wraz z wcześniejszym zamknięciem platformy GSE
- Rzeczywisty budżet został przemodelowany do 2,5 miliarda, około 3,8 miliarda mniej niż pierwotny plan
- Zniesiono ulgę podatkową na oprogramowanie 4.0, tworząc lukę motywacyjną dla MŚP
Ta luka stanowi zarówno ryzyko, jak i szansę. MŚP inwestujące obecnie w własną infrastrukturę danych, również z dostępnymi rozwiązaniami typu DuckDB i narzędziami open source, znajdą przewagę konkurencyjną, gdy nadejdą kolejne cykle motywacyjne dostępne. Na początek nie potrzebujesz milionów euro: potrzebujesz jasnej strategii i właściwe umiejętności.
Jak wybrać: praktyczny przewodnik dotyczący podejmowania decyzji
Wybór odpowiedniej platformy zależy od trzech głównych czynników: ilości danych, dostępny budżet i umiejętności zespołu. Oto praktyczne drzewo decyzyjne:
Drzewo decyzyjne: którą platformę wybrać
| Scenariusz | Ilość danych | Roczny budżet | Polecana platforma |
|---|---|---|---|
| Startupy / PoC | < 100 GB | < 1000 EUR | DuckDB + Pilnik do parkietu |
| MŚP – pierwsze kroki | 100 GB - 1 TB | 1 000 - 10 000 EUR | BigQuery (płatność za zapytanie) |
| PMI - zespół SQL | 1–10 TB | 10 000 - 50 000 EUR | Płatki śniegu |
| PMI - zespół danych/ML | 1–10 TB | 10 000 - 50 000 EUR | Kostki danych |
| Przedsiębiorstwo | > 10 TB | > 50 000 EUR | Kostki danych o Płatki śniegu + Góra lodowa |
| Ekosystem Google’a | Każdy | Zmienny | BigQuery + Sztuczna inteligencja wierzchołków |
5 pytań, które warto sobie zadać przed wyborem
- Kto będzie korzystał z danych? Jeśli zespół składa się z analityków SQL, naturalnym wyborem będzie Snowflake lub BigQuery. Jeśli istnieją inżynierowie danych i naukowcy zajmujący się danymi, Databricks oferuje większą elastyczność.
- Czy potrzebny jest czas rzeczywisty? Jeśli dane muszą być dostępne w ciągu kilku sekund (a nie godzin), potrzebujesz natywnych platform do przesyłania strumieniowego, takich jak Databricks lub BigQuery.
- Jak ważne są dane nieustrukturyzowane? Dzienniki, obrazy, dokumenty? Jeśli stanowią one znaczną część, najlepszym wyborem będzie domek nad jeziorem z górą lodową.
- Jaki jest dostawca usług w chmurze dla firmy? Jeśli Twoja firma korzysta już z AWS, naturalnymi opcjami są Snowflake i Databricks. W GCP BigQuery ma zalety integracji.
- Jaki jest plan 3-letni? Rozpoczęcie od DuckDB dla PoC i migracja do Snowflake lub Databricks to całkowicie dobra i popularna strategia.
Partia a przesyłanie strumieniowe: dwa modele przetwarzania
Kluczowym aspektem, który należy zrozumieć w nowoczesnej architekturze danych, jest różnica pomiędzy przetwarzanie seria e przesyłanie strumieniowe. Tu nie chodzi o wybór jednego lub drugiego, ale aby zrozumieć, kiedy każdy z nich jest odpowiedni.
Partia a przesyłanie strumieniowe: kiedy używać którego
| Czekam | Seria | Transmisja strumieniowa |
|---|---|---|
| Utajenie | Godziny (zwykle nocne) | Sekundy lub minuty |
| Złożoność | Niski | Wysoki (zarządzanie statusem, zamawianie, awaria) |
| Koszt | Treść (obliczenia na żądanie) | Wysoki (obliczenia zawsze aktywne) |
| Przypadki użycia | Codzienne raporty, klasyczne szkolenia ETL, ML | Wykrywanie oszustw, monitorowanie, dashboard w czasie rzeczywistym |
| Instrumenty | Iskra, dbt, przepływ powietrza | Kafka, Flink, Spark Streaming |
| Zalecane dla MŚP | Zacznij tutaj (90% przypadków) | Tylko jeśli wymaga tego biznes |
Praktyczna rada: 90% MŚP może z łatwością zacząć od architektury seria, który jest prostszy w zarządzaniu, tańszy i obejmuje zdecydowaną większość większość przypadków użycia analitycznego. Streaming należy wprowadzać tylko wtedy, gdy istnieje taka potrzeba jasne i mierzalne uzasadnienie biznesowe, które to uzasadnia (np. wykrywanie oszustw w czasie rzeczywistym, monitoring IoT, personalizacja w czasie rzeczywistym w e-commerce).
Wnioski i dalsze kroki
W tym artykule omówiliśmy całą ewolucję hurtowni danych: od modelu relacyjne Inmona i Kimballa z SQL Server i Oracle, przechodzące rewolucję Data Lake z Hadoop i pamięcią masową w chmurze, aż po architekturę Data Lakehouse z Apache Iceberg, która dzisiaj reprezentuje stan techniki.
Kluczowe punkty do zapamiętania
- Il Tradycyjny DWH On nie umarł: on ewoluował. Koncepcje schematu gwiazdy i modelowania wymiarowego pozostają fundamentalne.
- Il Jezioro danych rozwiązał problem przechowywania danych, ale stworzył Bagno Danych bez odpowiedniego zarządzania.
- Il Jezioro danych z Apache Iceberg łączy w sobie to, co najlepsze: ekonomiczne przechowywanie, transakcje ACID i wydajność.
- DuckDB oraz idealny punkt wejścia dla MŚP i analityków: zerowy koszt, wyjątkowa wydajność, brak infrastruktury.
- L'Architektura medalionowa (Brązowy/Srebrny/Złoty) organizuje przepływ danych od przyjęcia do biznesu w przejrzysty i regulowany sposób.
- Il Kontekst włoski stwarza znaczną lukę we wdrażaniu sztucznej inteligencji (8,2% MŚP w porównaniu z ponad 40% w USA), ale także możliwości dla tych, którzy inwestują obecnie.
Następny artykuł z tej serii poruszy uzupełniający i równie istotny temat: Siatka danych i zarządzanie danymi. Zobaczymy, jak zdecentralizować własność danych utrzymanie standardów jakości i bezpieczeństwa, podejście organizacyjne, które doskonale się integruje z architekturą techniczną domku nad jeziorem, który dzisiaj zwiedzaliśmy.
Zalecane ćwiczenie praktyczne
Zanim przejdziesz do następnego artykułu, spróbuj zainstalować DuckDB i uruchomić zapytanie analizy na rzeczywistym zbiorze danych. Możesz pobrać zbiór danych CSV z otwartych źródeł, takich jak ISTAT lub Kaggle i zapytaj go za pomocą jednej linii kodu:
# 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()W kolejnych artykułach z serii zagłębimy się w każdy element tej architektury, od nowoczesnych potoków ETL/ELT po jakość danych, od sztucznej inteligencji stosowanej w biznesie po praktyczny przypadek od końca do końca. Jeśli jesteś przedsiębiorcą, menadżerem IT lub aspirującą randką inżynier, ta seria zapewni Ci praktyczną wiedzę niezbędną do rozpoczęcia Twojej podróży cyfrowa transformacja Twojej firmy.