Python duomenų sandėliavimas: išsamus OLAP sistemų projektavimo vadovas

Šiandieniniame duomenimis grindžiamame pasaulyje gebėjimas greitai analizuoti didelius informacijos kiekius yra ne tik konkurencinis pranašumas, bet ir būtinybė. Įmonės visame pasaulyje remiasi patikima analitika, kad suprastų rinkos tendencijas, optimizuotų veiklą ir priimtų strateginius sprendimus. Šio analitinio potencialo pagrindą sudaro dvi esminės koncepcijos: duomenų sandėliai (DWH) ir internetinio analitinio apdorojimo (OLAP) sistemos.

Tradiciniškai šių sistemų kūrimui reikėjo specializuotos, dažnai nuosavybės teise saugomos ir brangios programinės įrangos. Tačiau atsiradus atvirojo kodo technologijoms, duomenų inžinerija tapo prieinamesnė. Šiam pokyčiui vadovauja Python – universali ir galinga programavimo kalba su gausia ekosistema, dėl kurios ji yra išskirtinis pasirinkimas kuriant galinius duomenų sprendimus. Šis vadovas išsamiai aprašo duomenų sandėliavimo ir OLAP sistemų projektavimą bei įgyvendinimą naudojant Python ekosistemą, skirtą pasaulinei duomenų inžinierių, architektų ir kūrėjų auditorijai.

1 dalis: Verslo analitikos kertiniai akmenys – DWH ir OLAP

Prieš pradedant gilintis į Python kodą, labai svarbu suprasti architektūros principus. Dažna klaida yra bandyti atlikti analizę tiesiogiai su operacinėmis duomenų bazėmis, o tai gali lemti prastą našumą ir netikslias įžvalgas. Tai yra problema, kurią buvo siekiama išspręsti kuriant duomenų sandėlius ir OLAP.

Kas yra duomenų sandėlis (DWH)?

Duomenų sandėlis yra centralizuota saugykla, kurioje saugomi integruoti duomenys iš vieno ar daugiau skirtingų šaltinių. Jo pagrindinis tikslas yra palaikyti verslo analitikos (BI) veiklas, ypač analizę ir ataskaitų teikimą. Galvokite apie tai kaip apie vienintelį organizacijos istorių duomenų šaltinį.

Jis smarkiai skiriasi nuo internetinio transakcijų apdorojimo (OLTP) duomenų bazės, kuri palaiko kasdienes programas (pvz., e-komercijos atsiskaitymo sistemą arba banko transakcijų registrą). Štai trumpas palyginimas:

• Darbo krūvis: OLTP sistemos apdoroja daug mažų, greitų transakcijų (skaitymo, įterpimo, atnaujinimo). DWH yra optimizuoti mažesniam skaičiui sudėtingų, ilgai trunkančių užklausų, kurios nuskaito milijonus įrašų (daugiau skaitymo operacijų).
• Duomenų struktūra: OLTP duomenų bazės yra labai normalizuotos, siekiant užtikrinti duomenų vientisumą ir išvengti dubliavimosi. DWH dažnai yra denormalizuoti, kad supaprastintų ir pagreitintų analitines užklausas.
• Tikslas: OLTP skirtas verslo valdymui. DWH skirtas verslo analizei.

Gerai suprojektuotas DWH pasižymi keturiomis pagrindinėmis savybėmis, dažnai priskiriamomis pradininkui Billui Inmonui:

• Orientuoti į objektą: Duomenys organizuojami pagal pagrindinius verslo objektus, tokius kaip 'Klientas', 'Produktas' ar 'Pardavimai', o ne pagal programos procesus.
• Integruoti: Duomenys renkami iš įvairių šaltinių ir integruojami į nuoseklų formatą. Pavyzdžiui, 'JAV', 'Jungtinės Valstijos' ir 'J. V.' gali būti standartizuoti į vieną įrašą 'Jungtinės Valstijos'.
• Kintami laike: Sandėlyje esantys duomenys atspindi informaciją per ilgą laikotarpį (pvz., 5–10 metų), leidžiančią atlikti istorinę analizę ir nustatyti tendencijas.
• Nekintantys: Kai duomenys įkeliami į sandėlį, jie retai kada atnaujinami ar ištrinami. Jie tampa nuolatiniu istorių įvykių įrašu.

Kas yra OLAP (interneto analitinis apdorojimas)?

Jei DWH yra istorių duomenų biblioteka, OLAP yra galinga paieškos sistema ir analizės įrankis, leidžiantis juos tyrinėti. OLAP yra programinės įrangos technologijų kategorija, leidžianti vartotojams greitai analizuoti informaciją, kuri buvo apibendrinta į daugiamates nuostatas, žinomas kaip OLAP kubai.

OLAP kubas yra koncepcinė OLAP šerdis. Tai nebūtinai fizinė duomenų struktūra, bet būdas modeliuoti ir vizualizuoti duomenis. Kubas susideda iš:

• Rodikliai: Tai kiekybiniai, skaitmeniniai duomenų taškai, kuriuos norite analizuoti, pvz., 'Pajamos', 'Parduotas kiekis' arba 'Pelnas'.
• Dimensijos: Tai kategoriniai atributai, apibūdinantys rodiklius ir suteikiantys kontekstą. Dažnos dimensijos apima 'Laikas' (Metai, Ketvirtis, Mėnuo), 'Geografija' (Šalis, Regionas, Miestas) ir 'Produktas' (Kategorija, Prekės ženklas, SKU).

Įsivaizduokite pardavimų duomenų kubą. Galėtumėte peržiūrėti bendras pajamas (rodiklį) pagal skirtingas dimensijas. Naudojant OLAP, galite atlikti galingas operacijas su šiuo kubu neįtikėtinu greičiu:

• Išpjova (Slice): Sumažinamas kubo dimensijų skaičius, pasirenkant vieną dimensijos reikšmę. Pavyzdys: Pardavimų duomenų peržiūra tik už '2023 m. IV ketvirtį'.
• Ištrauka (Dice): Pasirenkamas subkubas, nurodant reikšmių diapazoną kelioms dimensijoms. Pavyzdys: Pardavimų peržiūra 'Elektronikai' ir 'Aprangai' (Produkto dimensija) 'Europoje' ir 'Azijoje' (Geografijos dimensija).
• Nusileidimas / Pakilimas (Drill-Down / Drill-Up): Naršymas per detalumo lygius dimensijoje. Nusileidimas (drill-down) judama nuo aukštesnio lygio apibendrinimų prie žemesnio lygio detalių (pvz., nuo 'Metų' iki 'Ketvirčio' iki 'Mėnesio'). Pakilimas (drill-up arba rolling up) yra atvirkščias procesas.
• Sukamasis rodinys (Pivot): Kubų ašių sukimas, siekiant gauti naują duomenų vaizdą. Pavyzdys: 'Produkto' ir 'Geografijos' ašių sukeitimas, siekiant pamatyti, kurie regionai perka kokius produktus, o ne kokie produktai parduodami kokiuose regionuose.

OLAP sistemų tipai

Yra trys pagrindiniai OLAP sistemų architektūriniai modeliai:

1. MOLAP (Daugiamatis OLAP): Tai yra "klasikinis" kubo modelis. Duomenys išgaunami iš DWH ir iš anksto agreguojami į nuosavybės teise saugomą, daugiamatę duomenų bazę. Privalumai: Ypatingai greitas užklausų vykdymas, nes visi atsakymai yra iš anksto apskaičiuoti. Trūkumai: Gali sukelti "duomenų sprogimą", nes iš anksto agreguotų langelių skaičius gali tapti milžiniškas, ir jis gali būti mažiau lankstus, jei reikia užduoti klausimą, kuris nebuvo numatytas.
2. ROLAP (Reliacinis OLAP): Šis modelis saugo duomenis reliacinėje duomenų bazėje (paprastai pačiame DWH) ir naudoja sudėtingą metaduomenų sluoksnį, kad OLAP užklausos būtų išverstos į standartinę SQL. Privalumai: Labai keičiamo dydžio, nes naudojama šiuolaikinių reliacinių duomenų bazių galia, ir gali užklausti detalesnius, realaus laiko duomenis. Trūkumai: Užklausų vykdymas gali būti lėtesnis nei MOLAP, nes agregacijos atliekamos realiuoju laiku.
3. HOLAP (Hibridinis OLAP): Šis metodas bando sujungti geriausius abiejų pasaulių bruožus. Jis saugo aukšto lygio agreguotus duomenis MOLAP tipo kube, kad būtų užtikrintas greitis, ir saugo detalius duomenis ROLAP reliacinėje duomenų bazėje, kad būtų galima atlikti gilią analizę.

Šiuolaikinėms duomenų platformoms, sukurtoms naudojant Python, ribos susiliejo. Atsiradus neįtikėtinai greitoms stulpelinėms duomenų bazėms, the ROLAP modelis tapo dominuojančiu ir labai efektyviu, dažnai užtikrinančiu našumą, kuris prilygsta tradicinėms MOLAP sistemoms, bet be pastarųjų nelankstumo.

2 dalis: Python ekosistema duomenų sandėliavimui

Kodėl verta pasirinkti Python užduočiai, kurią tradiciškai dominavo įmonių BI platformos? Atsakymas slypi jo lankstume, galingoje ekosistemoje ir gebėjime suvienyti visą duomenų gyvavimo ciklą.

Kodėl Python?

• Vieninga kalba: Python galite naudoti duomenų išgavimui (ETL), transformavimui, įkėlimui, orkestravimui, analizei, mašininiam mokymuisi ir API kūrimui. Tai sumažina sudėtingumą ir poreikį perjunginėti kontekstą tarp skirtingų kalbų ir įrankių.
• Didžiulė bibliotekų ekosistema: Python turi brandžias, patikrintas bibliotekas kiekvienam proceso etapui, nuo duomenų manipuliavimo (Pandas, Dask) iki sąveikos su duomenų bazėmis (SQLAlchemy) ir darbo eigos valdymo (Airflow, Prefect).
• Nepamirštantis tiekėjo: Python yra atvirojo kodo ir jungiasi prie visko. Nesvarbu, ar jūsų duomenys yra PostgreSQL duomenų bazėje, Snowflake sandėlyje, S3 duomenų ežere ar Google lentelėje, yra Python biblioteka, leidžianti juos pasiekti.
• Mastelio keitimas: Python sprendimai gali būti masteliami nuo paprasto scenarijaus, veikiančio nešiojamajame kompiuteryje, iki paskirstytos sistemos, apdorojančios petabaitus duomenų debesies klasteryje, naudojant tokius įrankius kaip Dask ar Spark (per PySpark).

Pagrindinės Python bibliotekos duomenų sandėlio platformai

Tipiškas Python pagrįstas duomenų sandėliavimo sprendimas yra ne vienas produktas, o kruopščiai atrinktas galingų bibliotekų rinkinys. Štai esminiai:

ETL/ELT (Išgauti, Transformuoti, Įkelti)

• Pandas: Pagrindinis standartas duomenų manipuliavimui atmintyje Python kalba. Puikiai tinka mažiems ir vidutiniams duomenų rinkiniams (iki kelių gigabaitų). Jo „DataFrame“ objektas yra intuityvus ir galingas duomenų valymui, transformavimui ir analizei.
• Dask: Lygiagretaus skaičiavimo biblioteka, kuri mastelio keičia jūsų Python analitiką. Dask suteikia lygiagretų „DataFrame“ objektą, kuris imituoja Pandas API, bet gali veikti su duomenų rinkiniais, kurie yra didesni nei atmintis, suskaidydamas juos į dalis ir apdorodamas juos lygiagrečiai per kelis branduolius ar mašinas.
• SQLAlchemy: Pagrindinis SQL įrankių rinkinys ir objekto-reliacinis žemėlapis (ORM) Python kalbai. Jis suteikia nuoseklų, aukšto lygio API prisijungimui prie praktiškai bet kurios SQL duomenų bazės, nuo SQLite iki įmonės lygio sandėlių, tokių kaip BigQuery ar Redshift.
• Darbo eigos orkestratoriai (Airflow, Prefect, Dagster): Duomenų sandėlis nėra sukurtas vienu scenarijumi. Tai priklausomų užduočių seka (išgauti iš A, transformuoti B, įkelti į C, patikrinti D). Orkestratoriai leidžia apibrėžti šias darbo eigas kaip kryptinius aciklinius grafus (DAG), planuojant, stebint ir pakartotinai vykdant jas patikimai.

Duomenų saugojimui ir apdorojimui

• Debesies DWH jungtys: Bibliotekos, tokios kaip snowflake-connector-python, google-cloud-bigquery ir psycopg2 (skirtos Redshift ir PostgreSQL), leidžia sklandžiai sąveikauti su pagrindiniais debesies duomenų sandėliais.
• PyArrow: Itin svarbi biblioteka darbui su stulpeliniais duomenų formatais. Ji suteikia standartizuotą atminties formatą ir leidžia greitai perduoti duomenis tarp sistemų. Tai variklis, užtikrinantis efektyvią sąveiką su tokiais formatais kaip Parquet.
• Šiuolaikinės duomenų ežerų bibliotekos: Pažangiems nustatymams, bibliotekos, tokios kaip deltalake, py-iceberg, o „Spark“ vartotojams – „PySpark“ natūralus palaikymas šiems formatams, leidžia Python kurti patikimus, transakcinius duomenų ežerus, kurie tarnauja kaip sandėlio pagrindas.

3 dalis: OLAP sistemos projektavimas su Python

Dabar pereikime nuo teorijos prie praktikos. Štai žingsnis po žingsnio vadovas, kaip suprojektuoti jūsų analitinę sistemą.

1 žingsnis: Duomenų modeliavimas analitikai

Bet kurios geros OLAP sistemos pagrindas yra jos duomenų modelis. Tikslas yra struktūrizuoti duomenis greitam, intuityviam užklausų vykdymui. Dažniausiai ir efektyviausi modeliai yra žvaigždės schema ir jos variantas – snaigės schema.

Žvaigždės schema prieš Snaigės schemą

Žvaigždės schema yra plačiausiai naudojama duomenų sandėlių struktūra. Ją sudaro:

• Centrinė Faktų lentelė: joje yra rodikliai (skaičiai, kuriuos norite analizuoti) ir išoriniai raktai į dimensijų lenteles.
• Kelių Dimensijų lentelės: kiekviena dimensijos lentelė sujungiama su faktų lentele vienu raktu ir joje yra aprašomieji atributai. Šios lentelės yra labai denormalizuotos, siekiant supaprastinti ir pagreitinti.

Pavyzdys: A `FactSales` lentelė su stulpeliais, tokiais kaip `DateKey`, `ProductKey`, `StoreKey`, `QuantitySold`, ir `TotalRevenue`. Ją suptų `DimDate`, `DimProduct`, ir `DimStore` lentelės.

Snaigės schema yra žvaigždės schemos išplėtimas, kai dimensijų lentelės normalizuojamos į kelias susijusias lenteles. Pavyzdžiui, `DimProduct` lentelė gali būti suskaidyta į `DimProduct`, `DimBrand`, ir `DimCategory` lenteles.

Rekomendacija: Pradėkite nuo Žvaigždės schemos. Užklausos yra paprastesnės (mažiau sujungimų), o šiuolaikinės stulpelinės duomenų bazės yra tokios efektyvios apdorojant plačias, denormalizuotas lenteles, kad snaigės schemų saugojimo pranašumai dažnai yra nereikšmingi, palyginti su papildomų sujungimų našumo sąnaudomis.

2 žingsnis: ETL/ELT dujotiekio kūrimas Python kalba

ETL procesas yra pagrindas, maitinantis jūsų duomenų sandėlį. Jis apima duomenų išgavimą iš šaltinių sistemų, jų transformavimą į švarų ir nuoseklų formatą ir įkėlimą į jūsų analitinį modelį.

Iliustruokime tai paprastu Python scenarijumi, naudojant Pandas. Įsivaizduokime, kad turime šaltinio CSV failą su neapdorotais užsakymais.

# Supaprastintas ETL pavyzdys naudojant Python ir Pandas

import pandas as pd

# --- IŠGAVIMAS ---
print("Išgaunami neapdoroti užsakymų duomenys...")
source_df = pd.read_csv('raw_orders.csv')

# --- TRANSFORMACIJA ---
print("Transformuojami duomenys...")

# 1. Išvalyti duomenis
source_df['order_date'] = pd.to_datetime(source_df['order_date'])
source_df['product_price'] = pd.to_numeric(source_df['product_price'], errors='coerce')
source_df.dropna(inplace=True)

# 2. Praturtinti duomenis - Sukurti atskirą Datos Dimensiją
dim_date = pd.DataFrame({
    'DateKey': source_df['order_date'].dt.strftime('%Y%m%d').astype(int),
    'Date': source_df['order_date'].dt.date,
    'Year': source_df['order_date'].dt.year,
    'Quarter': source_df['order_date'].dt.quarter,
    'Month': source_df['order_date'].dt.month,
    'DayOfWeek': source_df['order_date'].dt.day_name()
}).drop_duplicates().reset_index(drop=True)

# 3. Sukurti Produkto Dimensiją
dim_product = source_df[['product_id', 'product_name', 'category']].copy()
dim_product.rename(columns={'product_id': 'ProductKey'}, inplace=True)
dim_product.drop_duplicates(inplace=True).reset_index(drop=True)

# 4. Sukurti Faktų lentelę
fact_sales = source_df.merge(dim_date, left_on=source_df['order_date'].dt.date, right_on='Date')\
                      .merge(dim_product, left_on='product_id', right_on='ProductKey')

fact_sales = fact_sales[['DateKey', 'ProductKey', 'order_id', 'quantity', 'product_price']]
fact_sales['TotalRevenue'] = fact_sales['quantity'] * fact_sales['product_price']
fact_sales.rename(columns={'order_id': 'OrderCount'}, inplace=True)

# Agreguoti iki norimo detalumo lygio
fact_sales = fact_sales.groupby(['DateKey', 'ProductKey']).agg(
    TotalRevenue=('TotalRevenue', 'sum'),
    TotalQuantity=('quantity', 'sum')
).reset_index()

# --- ĮKĖLIMAS ---
print("Įkeliami duomenys į tikslinę saugyklą...")
# Šiam pavyzdžiui, išsaugosime į Parquet failus, labai efektyvų stulpelinį formatą
dim_date.to_parquet('warehouse/dim_date.parquet')
dim_product.to_parquet('warehouse/dim_product.parquet')
fact_sales.to_parquet('warehouse/fact_sales.parquet')

print("ETL procesas baigtas!")

Šis paprastas scenarijus demonstruoja pagrindinę logiką. Realiame scenarijuje šią logiką apvyniotumėte funkcijomis ir valdytumėte jos vykdymą orkestratoriumi, tokiu kaip Airflow.

3 žingsnis: OLAP variklio pasirinkimas ir įgyvendinimas

Kai jūsų duomenys yra sumodeliuoti ir įkelti, jums reikia variklio, kuris atliktų OLAP operacijas. Python pasaulyje turite keletą galingų pasirinkimų, daugiausia vadovaujantis ROLAP metodu.

A metodas: Lengvasis galiūnas – DuckDB

DuckDB yra procese veikianti analitinė duomenų bazė, kuri yra neįtikėtinai greita ir lengvai naudojama su Python. Ji gali tiesiogiai užklausti Pandas DataFrames ar Parquet failus naudojant SQL. Tai puikus pasirinkimas mažo ir vidutinio masto OLAP sistemoms, prototipams ir vietinei plėtrai.

Ji veikia kaip didelio našumo ROLAP variklis. Jūs rašote standartinį SQL, o DuckDB jį vykdo su ypatingu greičiu jūsų duomenų failuose.

import duckdb

# Prisijungti prie atminties duomenų bazės arba failo
con = duckdb.connect(database=':memory:', read_only=False)

# Tiesiogiai užklausti Parquet failus, kuriuos sukūrėme anksčiau
# DuckDB automatiškai supranta schemą
result = con.execute("""
SELECT
    p.category,
    d.Year,
    SUM(f.TotalRevenue) AS AnnualRevenue
FROM 'warehouse/fact_sales.parquet' AS f
JOIN 'warehouse/dim_product.parquet' AS p ON f.ProductKey = p.ProductKey
JOIN 'warehouse/dim_date.parquet' AS d ON f.DateKey = d.DateKey
WHERE p.category = 'Electronics'
GROUP BY p.category, d.Year
ORDER BY d.Year;
""").fetchdf() # fetchdf() grąžina Pandas DataFrame

print(result)

B metodas: Debesų masto titanai – Snowflake, BigQuery, Redshift

Didelio masto įmonių sistemoms debesies duomenų sandėlis yra standartinis pasirinkimas. Python sklandžiai integruojasi su šiomis platformomis. Jūsų ETL procesas įkeltų duomenis į debesies DWH, o jūsų Python programa (pvz., BI prietaisų skydelis ar Jupyter užrašų knygelė) juos užklaustų.

Logika išlieka tokia pati kaip su DuckDB, tačiau ryšys ir mastelis skiriasi.

import snowflake.connector

# Pavyzdys, kaip prisijungti prie Snowflake ir vykdyti užklausą
conn = snowflake.connector.connect(
    user='your_user',
    password='your_password',
    account='your_account_identifier'
)

cursor = conn.cursor()

try:
    cursor.execute("USE WAREHOUSE MY_WH;")
    cursor.execute("USE DATABASE MY_DB;")
    cursor.execute("""
        SELECT category, YEAR(date), SUM(total_revenue)
        FROM fact_sales 
        JOIN dim_product ON ...
        JOIN dim_date ON ...
        GROUP BY 1, 2;
    """)
    # Gauti rezultatus, jei reikia
    for row in cursor:
        print(row)
finally:
    cursor.close()
    conn.close()

C metodas: Realaus laiko specialistai – Apache Druid arba ClickHouse

Naudojimo atvejams, reikalaujantiems subsekundinės užklausos delsos dideliems, srautiniams duomenų rinkiniams (pvz., realaus laiko vartotojų analizei), specializuotos duomenų bazės, tokios kaip Druid ar ClickHouse, yra puikūs pasirinkimai. Tai stulpelinės duomenų bazės, skirtos OLAP darbo krūviams. Python naudojamas duomenims į jas transliuoti ir užklausti per atitinkamas kliento bibliotekas ar HTTP API.

4 dalis: Praktinis pavyzdys – Mini OLAP sistemos kūrimas

Apjunkime šias koncepcijas į mini projektą: interaktyvų pardavimų prietaisų skydelį. Tai demonstruoja pilną, nors ir supaprastintą, Python pagrįstą OLAP sistemą.

Mūsų techninis paketas:

• ETL: Python ir Pandas
• Duomenų saugykla: Parquet failai
• OLAP variklis: DuckDB
• Prietaisų skydelis: Streamlit (atvirojo kodo Python biblioteka gražioms, interaktyvioms žiniatinklio programoms duomenų mokslui kurti)

Pirmiausia paleiskite ETL scenarijų iš 3 dalies, kad sugeneruotumėte Parquet failus `warehouse/` kataloge.

Toliau sukurkite prietaisų skydelio programos failą, `app.py`:

# app.py - Paprastas interaktyvus pardavimų OLAP prietaisų skydelis

import streamlit as st
import duckdb
import pandas as pd
import plotly.express as px

# --- Puslapio konfigūracija ---
st.set_page_config(layout=\"wide\", page_title=\"Global Sales Dashboard\")
st.title(\"Interaktyvus pardavimų OLAP prietaisų skydelis\")

# --- Prisijungimas prie DuckDB ---
# Tai tiesiogiai užklausi mūsų Parquet failus
con = duckdb.connect(database=':memory:', read_only=True)

# --- Įkelti dimensijos duomenis filtrams ---
@st.cache_data
def load_dimensions():
    products = con.execute(\"SELECT DISTINCT category FROM 'warehouse/dim_product.parquet'\").fetchdf()
    years = con.execute(\"SELECT DISTINCT Year FROM 'warehouse/dim_date.parquet' ORDER BY Year\").fetchdf()
    return products['category'].tolist(), years['Year'].tolist()

categories, years = load_dimensions()

# --- Šoninė juosta filtrams (išpjova ir ištrauka!) ---
st.sidebar.header(\"OLAP Filtrai\")

selected_categories = st.sidebar.multiselect(
    'Pasirinkite produktų kategorijas',
    options=categories,
    default=categories
)

selected_year = st.sidebar.selectbox(
    'Pasirinkite metus',
    options=years,
    index=len(years)-1 # Numatytasis - naujausi metai
)

# --- Dinaminis OLAP užklausos sudarymas ---
if not selected_categories:
    st.warning(\"Prašome pasirinkti bent vieną kategoriją.\")
    st.stop()

query = f"""
SELECT
    d.Month,
    d.MonthName, -- Darant prielaidą, kad DimDate egzistuoja MonthName
    p.category,
    SUM(f.TotalRevenue) AS Revenue
FROM 'warehouse/fact_sales.parquet' AS f
JOIN 'warehouse/dim_product.parquet' AS p ON f.ProductKey = p.ProductKey
JOIN 'warehouse/dim_date.parquet' AS d ON f.DateKey = d.DateKey
WHERE d.Year = {selected_year}
  AND p.category IN ({str(selected_categories)[1:-1]})
GROUP BY d.Month, d.MonthName, p.category
ORDER BY d.Month;
"""

# --- Vykdyti užklausą ir rodyti rezultatus ---
@st.cache_data
def run_query(_query):
    return con.execute(_query).fetchdf()

results_df = run_query(query)

if results_df.empty:
    st.info(f\"Duomenų nerasta pasirinktiems filtrams metais {selected_year}.\")
else:
    # --- Pagrindiniai prietaisų skydelio vaizdai ---
    col1, col2 = st.columns(2)

    with col1:
        st.subheader(f\"Mėnesio pajamos už {selected_year}\")
        fig = px.line(
            results_df,
            x='MonthName',
            y='Revenue',
            color='category',
            title='Mėnesio pajamos pagal kategoriją'
        )
        st.plotly_chart(fig, use_container_width=True)

    with col2:
        st.subheader(\"Pajamos pagal kategoriją\")
        category_summary = results_df.groupby('category')['Revenue'].sum().reset_index()
        fig_pie = px.pie(
            category_summary,
            names='category',
            values='Revenue',
            title='Visų pajamų dalis pagal kategoriją'
        )
        st.plotly_chart(fig_pie, use_container_width=True)

    st.subheader(\"Detalesni duomenys\")
    st.dataframe(results_df)

Norėdami tai paleisti, išsaugokite kodą kaip `app.py` ir vykdymo lange paleiskite `streamlit run app.py`. Tai atvers žiniatinklio naršyklę su jūsų interaktyviu prietaisų skydeliu. Šoninės juostos filtrai leidžia vartotojams atlikti OLAP „išpjovimo“ ir „ištraukimo“ operacijas, o prietaisų skydelis atnaujinamas realiuoju laiku, pakartotinai užklausiant DuckDB.

5 dalis: Pažangios temos ir geriausios praktikos

Pereinant nuo mini projekto prie gamybinės sistemos, apsvarstykite šias pažangias temas.

Mastelio keitimas ir našumas

• Naudokite Dask dideliems ETL: Jei jūsų šaltinio duomenys viršija jūsų mašinos RAM, pakeiskite Pandas į Dask savo ETL scenarijuose. API yra labai panaši, bet Dask apdoros už atminties ribų ir lygiagretųjį apdorojimą.
• Stulpelinė saugykla yra raktas: Visada saugokite savo duomenų sandėlio duomenis stulpeliniu formatu, tokiu kaip Apache Parquet arba ORC. Tai žymiai pagreitina analitines užklausas, kurioms paprastai reikia skaityti tik kelis stulpelius iš plačios lentelės.
• Skirstymas (Partitioning): Kai duomenys saugomi duomenų ežere (pvz., S3 ar vietinėje failų sistemoje), suskirstykite duomenis į aplankus pagal dažnai filtruojamą dimensiją, pvz., datą. Pavyzdžiui: warehouse/fact_sales/year=2023/month=12/. Tai leidžia užklausų varikliams praleisti nereikšmingų duomenų skaitymą, procesą, žinomą kaip „skirstymo apipjaustymas“.

Semantinis sluoksnis

Kai jūsų sistema auga, pastebėsite, kad verslo logika (pvz., „Aktyvaus vartotojo“ ar „Bendrosios maržos“ apibrėžimas) kartojasi keliose užklausose ir prietaisų skydeliuose. Semantinis sluoksnis tai išsprendžia, pateikdamas centralizuotą, nuoseklų jūsų verslo metrikų ir dimensijų apibrėžimą. Tokie įrankiai kaip dbt (Data Build Tool) tam yra išskirtiniai. Nors pats dbt nėra Python įrankis, jis puikiai integruojasi į Python valdomą darbo eigą. Jūs naudojate dbt, kad modeliuotumėte savo žvaigždės schemą ir apibrėžtumėte metrikas, o tada Python gali būti naudojamas dbt vykdymams orkestruoti ir atlikti pažangią analizę su gautomis švariomis lentelėmis.

Duomenų valdymas ir kokybė

Sandėlis yra toks geras, kokie jame esantys duomenys. Integruokite duomenų kokybės patikrinimus tiesiai į savo Python ETL dujotiekius. Bibliotekos, tokios kaip Great Expectations, leidžia jums apibrėžti „lūkesčius“ apie jūsų duomenis (pvz., customer_id niekada negali būti null, revenue turi būti nuo 0 iki 1 000 000). Jūsų ETL užduotis gali sugesti arba įspėti, jei gaunami duomenys pažeidžia šias sutartis, taip užkertant kelią netinkamiems duomenims sugadinti jūsų sandėlį.

Išvada: Kodo pirmenybės metodo galia

Python iš esmės pakeitė duomenų sandėliavimo ir verslo analitikos aplinką. Jis suteikia lankstų, galingą ir nuo tiekėjų nepriklausomą įrankių rinkinį, skirtą kurti sudėtingas analitines sistemas nuo nulio. Sujungus geriausias bibliotekas, tokias kaip Pandas, Dask, SQLAlchemy ir DuckDB, galite sukurti visapusišką OLAP sistemą, kuri yra tiek keičiamo dydžio, tiek lengvai prižiūrima.

Kelionė prasideda nuo tvirto duomenų modeliavimo principų, tokių kaip žvaigždės schema, supratimo. Nuo to galite kurti patikimus ETL dujotiekius, kad suformuotumėte savo duomenis, pasirinkti tinkamą užklausų variklį pagal savo mastelį ir netgi kurti interaktyvias analitines programas. Šis kodo pirmenybės metodas, dažnai esminis „Modern Data Stack“ principas, suteikia analitikos galią tiesiogiai kūrėjų ir duomenų komandų rankoms, leidžiant jiems kurti sistemas, kurios puikiai pritaikytos jų organizacijos poreikiams.