데이터 웨어하우스의 진화: SQL Server에서 Data Lakehouse로
기업이 데이터를 저장, 구성, 분석하는 방식이 변화했습니다. 지난 20년 동안 급진적이었습니다. 폐쇄형 관계형 단일체에서 엔터프라이즈 데이터 센터로 전환했습니다. 페타바이트 규모의 정형 및 비정형 데이터를 관리할 수 있는 분산형 클라우드 플랫폼으로 실시간. 그러나 많은 이탈리아 중소기업의 경우 데이터 웨어하우스 여전히 모호한 개념으로 남아있다. 연기된 투자, 다루기에는 너무 복잡한 프로젝트입니다.
이 기사는 시리즈를 시작합니다 데이터 웨어하우스, AI 및 디지털 혁신 와 대기업에만 국한되어 있는 개념을 접근 가능하게 만드는 것이 목표입니다. 우리는 SQL Server와 Oracle이 포함된 전통적인 데이터 웨어하우스의 기초부터 시작하여 도달할 것입니다. 기반으로 한 현대적인 건축에 데이터 레이크하우스, 진화의 모든 단계를 탐구 그리고 각각의 기술적 도약이 필요했던 이유.
글로벌 데이터 웨어하우징 시장은 대략 다음과 같은 가치에 도달했습니다. 390억 달러 2025년에, 연평균 성장률(CAGR)이 10%를 넘을 것으로 예상됩니다. 10년. 엔터프라이즈 부문(EDW)은 CAGR 22.8%로 더욱 빠르게 성장하고 있습니다. 이는 기술적인 유행이 아니라 비즈니스 방식의 구조적 변화입니다. 데이터와 관련이 있습니다.
이 기사에서 배울 내용
- 데이터 모델링에 대한 기존 Kimball 접근 방식과 Inmon 접근 방식의 차이점
- 기존 데이터 웨어하우스가 더 이상 충분하지 않은 이유와 한계에 도달한 이유
- Data Lake가 새로운 문제를 생성하는 동안 몇 가지 문제를 해결한 방법
- Data Lakehouse란 무엇이며 Apache Iceberg가 시장의 78.6%를 차지하는 이유
- Snowflake, Databricks, BigQuery 및 DuckDB의 실제 비용과 실제 비교
- 주요 기업에서 사용하는 메달리온(브론즈/실버/골드) 아키텍처
- 규모, 예산, 팀 기술을 기준으로 올바른 플랫폼을 선택하는 방법
데이터 웨어하우스, AI 및 디지털 혁신 시리즈 개요
| # | Articolo | 집중하다 |
|---|---|---|
| 1 | 현재 위치 - 데이터 웨어하우스의 진화 | SQL Server에서 데이터 레이크하우스로 |
| 2 | 데이터 메시 및 데이터 거버넌스 | 데이터를 분산화 |
| 3 | 클라우드의 ETL과 ELT | 최신 데이터 파이프라인 |
| 4 | 비즈니스를 위한 AI 및 머신러닝 | 비즈니스 예측 모델 |
| 5 | 실시간 분석 | 스트리밍 및 실시간 결정 |
| 6 | 데이터 품질 및 관찰 가능성 | 데이터 상태 모니터링 |
| 7 | PNRR과 디지털 혁신 | 이탈리아 중소기업을 위한 기회 |
| 8 | 엔드투엔드 실제 사례 | 데이터 레이크하우스를 처음부터 구축하기 |
전통적인 데이터 웨어하우스: 기초
데이터 웨어하우스의 개념은 기업들이 데이터베이스의 중요성을 이해하기 시작한 1990년대에 탄생했습니다. 주문, 송장, 고객 기록을 관리하도록 설계된 거래(OLTP) 시스템은 적합하지 않습니다. 데이터 분석을 위해. 분석 쿼리에 최적화된 별도의 시스템이 필요합니다. 데이터 웨어하우스 (DWH), 온라인 분석 처리(OLAP) 데이터베이스입니다.
두 가지 사고 방식이 30년 동안 DWH 디자인을 지배해 왔습니다. 빌 인몬 그리고 그것은 랄프 킴볼. 차이점을 이해하세요 이 두 접근 방식 사이의 접근 방식은 기본적입니다. 왜냐하면 두 접근 방식은 오늘날에도 여전히 많은 아키텍처에 영향을 미치기 때문입니다. 비즈니스 시스템.
Inmon 접근 방식: 하향식
데이터 웨어하우징의 아버지로 불리는 Bill Inmon이 제안하는 접근 방식 위에서 아래로: 먼저 중앙 집중화되고 정규화된 데이터 웨어하우스가 구축됩니다(세 번째 정규 형식, 3NF). 그럼 우리는 i를 파생 화요일 날짜 각 부서마다 다릅니다. 중앙 DWH 전체 조직에 대한 단일 정보 소스 역할을 합니다.
인몬 접근법의 특징
- 주제 중심: 데이터는 소스 애플리케이션이 아닌 주제(고객, 제품, 판매)별로 구성됩니다.
- 통합: 다양한 소스의 데이터가 통일된 규칙에 따라 조정됩니다.
- 비휘발성: 업로드된 데이터는 수정되지 않고 추가만 됩니다.
- 시변: 각 레코드에는 기록 분석을 위한 시간 차원이 있습니다.
- 정규화(3NF): 중복성을 줄이지만 쿼리에 복잡한 조인이 필요합니다.
Kimball 접근 방식: 상향식
Ralph Kimball은 한 가지 접근 방식을 제안합니다. 상향식 근본적으로 다르다: 필요에서 시작하기 비즈니스 분석 및 구축 차원 데이터 마트 즉시 사용 가능, 그런 다음 다음을 통해 통합됩니다. 일치하는 치수 (공유 차원). 심장 Kimball 모델의 스타 스키마.
-- 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), 오라클 데이터 통합자, 인포매티카 파워센터 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 엔터프라이즈, Oracle 데이터베이스 및 Teradata는 데이터 볼륨과 컴퓨팅 성능에 따라 확장됩니다. 10TB를 보유한 기업의 경우 데이터의 경우 연간 비용은 라이센스에만 포함되지 않고 EUR 200,000를 초과할 수 있습니다. 하드웨어, 스토리지 및 전문 인력.
- 데이터 대기 시간(실시간 아님): 야간 ETL 일괄 처리로 인해 대기 시간 발생 12~24시간. 전자상거래, 금융, 물류 등의 산업에서는 이러한 지연 시간이 허용되지 않습니다. 다음날 발견된 판매 이상 현상은 수천 유로의 손실을 의미할 수 있습니다.
- 수직 확장성: 기존 DWH는 CPU, RAM 및 디스크를 기존 서버에 추가(수직 확장)합니다. 이 접근 방식에는 물리적 한계와 비용이 있습니다. 지수. 최신 클라우드 플랫폼은 수평적으로 확장(수평 확장)되어 선형 비용으로 노드를 클러스터에 추가합니다.
이러한 한계는 갑자기 나타난 것이 아니라 점차적으로 축적되었습니다. 기업 데이터의 양, 다양성, 속도가 기하급수적으로 증가했습니다. 대답 이러한 문제의 초기에는 데이터 레이크.
데이터 레이크: 첫 번째 혁명
Data Lake는 기존 DWH의 한계에 대한 대응으로 2010년경에 탄생했습니다. 아이디어는 간단하고 강력함: 데이터를 로드하기 전에 스키마를 정의하는 대신(쓰기 시 스키마) 원시 데이터를 원래 형식으로 저장하고 그 순간에만 스키마를 적용합니다. 독서의 (읽기 시 스키마). 초기 기술 기반 e 아파치 하둡 HDFS 분산 파일 시스템을 사용합니다.
데이터 레이크의 특징
- 읽기 시 스키마: 데이터는 변환 없이 로드되며, 읽을 때 스키마가 적용됩니다.
- 모든 데이터 유형: 구조적(CSV, Parquet), 반구조적(JSON, XML), 비구조적(이미지, 로그, 비디오)
- 경제적인 스토리지: Amazon S3, Azure Data Lake Storage, Google Cloud Storage 비용은 매월 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를 동시에 유지하게 되었습니다. (중요한 구조화된 데이터용) 및 Data Lake(원시 및 구조화되지 않은 데이터용) 중복, 비용, 복잡성이 두 배로 늘어났습니다. 우리는 최고의 장점을 결합한 솔루션이 필요했습니다. 두 세계 모두. 이 솔루션은 데이터 레이크하우스.
데이터 레이크하우스: 두 세계의 최고
Il 데이터 레이크하우스 유연성과 저비용을 결합한 아키텍처 데이터 웨어하우스의 신뢰성, 성능 및 거버넌스를 보장하는 데이터 레이크입니다. 는 핵심 개념과공개 테이블 형식: 메타데이터의 중첩 레이어 ACID 트랜잭션을 제공하기 위해 데이터 레이크(일반적으로 객체 스토리지의 Parquet)에 있는 파일에 스키마 시행, 시간 여행 및 쿼리 최적화.
세 가지 개방형 테이블 형식
| 체재 | 작성자: | 채택 2025 | 강점 |
|---|---|---|---|
| 아파치 빙산 | 넷플릭스 (2017) | 78.6% (독점) | 공급업체 중립적, 숨겨진 파티셔닝, 광범위한 생태계 |
| 델타 레이크 | 데이터브릭스(2019) | 39.3% (중복) | 기본 Spark 통합, Liquid Clustering |
| 아파치 후디 | 우버(2016) | 미성년자 | upsert 및 CDC(변경 데이터 캡처)에 최적화됨 |
세 가지 형식 간의 경쟁은 본질적으로 2024~2025년에 끝났습니다. 아파치 빙산 이는 사실상 표준의 위치를 달성했습니다. 결정적인 신호는 2024년 6월에 도착했습니다. Databricks 인수 표 형식, 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()Data Lakehouse가 Data Lake와 비교하여 제공하는 이점
- ACID 거래: 원자적이고 일관되며 고립되고 오래 지속되는 글입니다. 더 이상 부분적이거나 손상된 데이터가 없습니다.
- 진화 계획: 기존 데이터를 다시 쓰지 않고도 열을 추가하거나 이름을 바꾸거나 제거할 수 있습니다.
- 시간 여행: 감사, 디버깅 또는 롤백을 위해 모든 기록 버전의 데이터에 액세스하세요.
- 쿼리 최적화: 열 통계, 파일 정리, 데이터 건너뛰기는 읽기 데이터를 90% 이상 줄입니다.
- Upsert 및 병합: 효율적인 업데이트/삽입/삭제 작업은 CDC 및 SCD(Slowly Changing Dimensions)의 기본입니다.
- 개방형 형식: 데이터는 객체 스토리지의 Parquet에 남아 있습니다. 벤더 종속이 없습니다.
플랫폼 비교: 어느 것을 선택할 것인가?
클라우드 데이터 플랫폼 시장은 Snowflake, Databricks 및 3개의 거대 기업이 장악하고 있습니다. 지역 분석에 혁명을 일으키고 있는 외부인이 합류한 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, 파이썬, 자바 | 파이썬, 스칼라, SQL, R | SQL, 파이썬 | 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에서 프로덕션으로 전환하기 전에 쿼리 및 논리를 검증합니다.
- 지역 보고서: 노트북에서 최대 100GB의 데이터에 대한 대시보드 및 보고서 생성
- CI/CD 파이프라인: 지속적 통합 파이프라인의 데이터 품질 테스트
- 엣지 컴퓨팅: 임베디드 장치 또는 네트워크로 연결되지 않은 환경에 대한 분석
DuckDB는 페타바이트 규모의 프로덕션 워크로드를 위해 Snowflake 또는 Databricks를 대체하지는 않지만 분석가가 답변을 필요로 하는 가장 일반적인 사용 범위를 완벽하게 표현합니다. 단일 서버에 있는 데이터 세트에서 빠르게 먼저 이동하는 이탈리아 SME의 경우 데이터 분석을 향한 단계에서 DuckDB는 이상적인 진입점을 나타냅니다. 비용 제로, 최소한의 학습 곡선, 즉각적인 결과.
건축 메달: 브론즈, 실버, 골드
어떤 플랫폼을 선택하든 최신 데이터 레이크하우스에서 가장 널리 채택되는 아키텍처입니다. 그리고 메달리온 아키텍처 (메달리온 아키텍처)는 데이터를 다음과 같이 구성합니다. 품질과 세련미의 세 가지 점진적인 수준. 각 수준에는 주기에서 특정 역할이 있습니다. 원시 수집부터 비즈니스 사용까지의 데이터 수명입니다.
메달리온 아키텍처의 세 가지 수준
| 수준 | 범위 | 데이터 품질 | 대상 사용자 |
|---|---|---|---|
| 브론즈(원시) | 원시 수집, 소스 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% 의 이탈리아 제조 중소기업이 하나 이상의 AI 기술을 통합한 반면, 미국 기업은 40% 이상입니다.
- 이탈리아 AI 시장 규모는 12억 유로(연간 +58%)이지만, 성장은 대기업에 집중되어 있다
- 전환 5.0 자금은 GSE 플랫폼의 조기 폐쇄와 함께 이르면 2025년 11월 6일에 소진되었습니다.
- 실제 예산은 당초 계획보다 약 38억 적은 25억으로 재편성됐다.
- 소프트웨어 4.0에 대한 세금 공제가 폐지되어 중소기업에 대한 인센티브 격차가 발생합니다.
이러한 격차는 위험이자 기회를 의미합니다. 현재 투자하고 있는 중소기업 DuckDB 및 오픈 소스 도구와 같은 접근 가능한 솔루션을 갖춘 자체 데이터 인프라 다음 인센티브 주기가 되면 경쟁 우위를 확보하게 될 것입니다. 가능합니다. 시작하는 데 수백만 유로가 필요하지 않습니다. 명확한 전략과 맞는 스킬.
선택 방법: 실용적인 결정 가이드
올바른 플랫폼을 선택하는 것은 세 가지 주요 요소, 즉 데이터 양, 사용 가능한 예산과 팀의 기술. 실용적인 의사결정 트리는 다음과 같습니다.
의사결정 트리: 선택할 플랫폼
| 대본 | 데이터 볼륨 | 세계 | 권장 플랫폼 |
|---|---|---|---|
| 스타트업/PoC | < 100GB | < 1,000유로 | 덕DB + 쪽모이 세공 파일 |
| SME - 첫 번째 단계 | 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로 마이그레이션하는 것은 완벽하게 훌륭하고 인기 있는 전략입니다.
배치와 스트리밍: 두 가지 수집 모델
현대 데이터 아키텍처에서 이해해야 할 주요 측면은 처리 일괄 e 스트리밍. 선택하는 것이 아니다 둘 중 하나이지만 각각이 적절한 시기를 이해하는 것입니다.
배치 vs 스트리밍: 언제 어느 것을 사용해야 할까요?
| 나는 기다린다 | 일괄 | 스트리밍 |
|---|---|---|
| 숨어 있음 | 시간(일반적으로 밤) | 초 또는 분 |
| 복잡성 | 낮은 | 높음(상태관리,주문,실패) |
| 비용 | 콘텐츠(주문형 컴퓨팅) | 높음(계산은 항상 활성 상태) |
| 사용 사례 | 일일 보고서, 클래식 ETL, ML 교육 | 사기탐지, 모니터링, 실시간 대시보드 |
| 악기 | 스파크, DBT, 에어플로우 | Kafka, Flink, 스파크 스트리밍 |
| 중소기업에 권장 | 여기에서 시작하세요(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을 사용하여 한 줄의 코드로 쿼리합니다.
# 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 관리자 또는 연애 지망생이라면 엔지니어 여러분, 이 시리즈는 여러분의 여정을 시작하는 데 필요한 실용적인 지식을 제공할 것입니다. 기업의 디지털 혁신.