Työkuormataulukon ylläpito ja optimointi Microsoft Fabricissa

Microsoft Fabricin delta-taulukot palvelevat useita kulutusmoottoreita, joilla jokaisella on erilaiset suorituskykyominaisuudet ja optimointivaatimukset. Tämä opas tarjoaa kattavan viitekehyksen ymmärtää, miten yhden moottorin kirjoittamat taulukot kulutetaan muiden toimesta ja miten taulukoiden ylläpitostrategiat voidaan optimoida sen mukaisesti.

Kirjoituskuvioiden ja lukusuorituskyvyn välisen suhteen ymmärtäminen eri moottoreiden välillä on olennaista tehokkaiden dataalustojen rakentamiseksi. Tavoitteena on varmistaa, että datatuottajat luovat taulukkoasetelmia, jotka optimoivat lukusuorituskyvyn loppukäyttäjille, olivatpa he käyttäneet Sparkia, SQL-analytiikkapäätepistettä, Power BI Direct Lakea tai Warehousea.

Kirjoita ja lukea skenaariomatriisi

Seuraava taulukko tiivistää odotetut suorituskykyominaisuudet yleisille kirjoitus- ja lukuyhdistelmille sekä suositellut optimointistrategiat. Käytä tätä matriisia tunnistaaksesi skenaariosi ja ymmärtääksesi asiaankuuluvat ohjeet.

Kirjoitusmenetelmä	Lukumoottori	Odotetut aukot	Suositeltu strategia
Spark-erä	Spark	Ei aukkoja	Oletus-Spark-kirjoitusasetukset riittävät
Spark-erä	SQL-analytiikan päätepiste	Ei aukkoja	Ota automaattinen tiivistys käyttöön ja optimoi kirjoitus
Kipinävirtaus	Spark	Pienet tiedostot mahdolliset	Automaattinen tiivistys ja optimointi-kirjoitus aikataulutetulla OPTIMoituksella
Kipinävirtaus	SQL-analytiikan päätepiste	Pienet tiedostot ja tarkistuspisteet	Automaattinen tiivistyminen, optimoi-kirjoitus, jako medallion-kerrokset
Varasto	Spark	Ei aukkoja	Järjestelmäohjattu optimointi käsittelee asettelua
Varasto	SQL-analytiikan päätepiste	Ei aukkoja	Järjestelmäohjattu optimointi käsittelee asettelua

Optimaaliset tiedostoasettelut moottorin mukaan

Eri kulutusmoottoreilla on erilaiset optimaaliset tiedostoasettelut. Näiden tavoitteiden ymmärtäminen auttaa sinua konfiguroimaan kirjoitustoiminnot ja ylläpitotehtävät oikein.

Ohjeita SQL-analytiikan päätepisteelle ja Fabric Data Warehouselle

Optimaalisen suorituskyvyn saavuttamiseksi SQL-analytiikkapäätepisteellä ja Warehousella käytä seuraavia asetuksia:

Kohdetiedoston koko: Enintään 4 GB per tiedosto
Riviryhmän koko: Noin 2 miljoonaa riviä per riviryhmä
V-järjestys: Parantaa lukusuorituskykyä 10%

Varasto käyttää näitä kriteerejä löytääkseen tiivistysehdokkaita:

Taulukkotiedostojen ylikuormitus on yli 10%
Taulukon loogisesti poistetut rivit ovat yli 10%
Pöydän koko on suurempi kuin 1 024 riviä

Tiivistymisen aikana prosessi valitsee ehdokkaat seuraavien kriteerien perusteella:

Mikä tahansa tiedosto on alle 25% ihanteellista kokoa (rivimäärän mukaan)
Jokaisessa tiedostossa on yli 20% poistettua riviä

Spark

Spark on luotettava, kun lukee eri tiedostokokoja. Optimaalisen suorituskyvyn saavuttamiseksi:

Kohdetiedoston koko: 128 MB–1 GB riippuen taulukon koosta
Riviryhmän koko: 1 miljoona–2 miljoonaa riviä per riviryhmä
V-järjestys: Ei vaadittu Sparkin lukusuorituskyvylle (voi lisätä 15-33% kirjoitusylikuormaa)

Spark-lukemat hyötyvät adaptiivisesta kohdetiedoston koosta, joka mukautuu automaattisesti taulukon koon mukaan:

Alle 10 GB:n taulukot: 128 MB tavoite
Taulukot yli 10 TB: Enintään 1 GB tavoite

Power BI Direct Lake

Optimaalisen Direct Lake -suorituskyvyn saavuttamiseksi:

Tavoiteriviryhmän koko: 8 miljoonaa tai enemmän riviä per riviryhmä parhaan suorituskyvyn saavuttamiseksi
V-Order: Kriittinen 40-60% parannus kylmävälimuistikyselyissä
Tiedostomäärä: Minimoi tiedostomäärä transkoodauksen kuormituksen vähentämiseksi
Johdonmukaiset tiedostokoot: Tärkeitä ennustettavan kyselysuorituskyvyn kannalta

Suoran järven semanttiset mallit toimivat parhaiten, kun:

Sarakedata on V-järjestetty VertiPaq-yhteensopivaa pakkausta varten
Riviryhmät ovat riittävän suuria tehokkaaseen sanakirjan yhdistämiseen
Deleetiovektorit minimoidaan säännöllisellä tiivistämisellä

Lisätietoja löytyy kohdasta Understand Direct Lake -kyselyn suorituskyky.

Mirroring

Tiedostojen automaattinen kokoaminen taulukon tilavuuden perusteella:

Pöydän koko	Rivit per riviryhmä	Rivit per tiedosto
Pieni (jopa 10 GB)	2 miljoonaa	10 miljoonaa
Keskikokoinen (10 GB – 2,56 TB)	4 miljoonaa	60 miljoonaa
Suuri (yli 2,56 TB)	8 miljoonaa	80 miljoonaa

Kirjoituskuviot ja konfiguraatiot

Kipinäkirjoitusmallit

Spark-kirjoitukset käyttävät seuraavia oletusasetuksia:

Määritykset	Oletusarvo	Kuvaus
`spark.microsoft.delta.optimizeWrite.fileSize`	128 MB	Kohdetiedostokoko optimoiduille kirjoituksille
`spark.databricks.delta.optimizeWrite.enabled`	Vaihtelee profiilin mukaan	Mahdollistaa automaattisesti tiedostojen yhdistämisen
`spark.databricks.delta.autoCompact.enabled`	Disabled	Mahdollistaa jälkikirjoituksen tiivistämisen
`spark.sql.files.maxRecordsPerFile`	Ei rajoitettu	Maksimitietueet per tiedosto

Spark-kirjoitusten konfigurointi SQL-kulutukselle seuraavasti:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

Lisätietoja resurssiprofiileista ja niiden oletusarvoista löytyy kohdasta Resurssiprofiilien konfiguraatioiden määrittäminen.

Varastokirjoitusmallit

Warehouse optimoi automaattisesti datan asettelun kirjoitusten aikana:

V-järjestys on oletuksena käytössä lukuoptimointia varten.
Automaattinen tiivistyminen toimii taustaprosessina.
Tarkistuspisteiden hallinta hoidetaan automaattisesti.

Varasto tuottaa SQL:n käyttöön optimoituja tiedostoja ilman manuaalista puuttumista. Warehousen laatimat taulukot on luonnostaan optimoitu sekä SQL-analytiikan päätepisteille että Warehouse-lukemille.

Pöydän ylläpitotoimet

OPTIMO-komento

Komento OPTIMIZE yhdistää pienet tiedostot suuremmiksi tiedostoiksi:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Tärkeää

Komento OPTIMIZE on Spark SQL -komento. Sinun täytyy ajaa se Spark-ympäristöissä, kuten muistikirjoissa, Spark-tehtävämäärittelyissä tai Lakehouse Maintenance -käyttöliittymässä. SQL-analytiikan päätepiste ja Warehouse SQL -kyselyeditori eivät tue tätä komentoa.

Lisätietoja löytyy kohdasta Taulukon tiivistäminen.

Automaattinen tiivistys

Automaattinen tiivistäminen arvioi osion terveyden automaattisesti jokaisen kirjoitusoperaation jälkeen ja käynnistää synkronisen optimoinnin, kun tiedostojen pirstoutuminen havaitaan:

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

Käytä automaattista tiivistämistä syöttöputkiin, joissa kirjoitetaan usein pieniä kirjoituksia (suoratoisto tai mikroerä) manuaalisen ajoituksen välttämiseksi ja tiedostojen automaattisesti tiivistämiseksi.

Automaattinen tiivistys ja optimointikirjoitus tuottavat yleensä parhaat tulokset, kun niitä käytetään yhdessä. Optimoitu kirjoitus vähentää pienten tiedostojen määrää, ja automaattinen tiivistys hoitaa jäljellä olevan pirstoutumisen.

Lisätietoja löytyy kohdasta Automaattinen tiivistyminen.

Optimoi kirjoitus

Optimoitu kirjoitus vähentää pienten tiedostojen ylikuormitusta suorittamalla esikirjoitustiivistystä, joka tuottaa vähemmän ja suurempia tiedostoja:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

Optimointikirjoitus on hyödyllinen:

Osioidut taulukot
Pöydät, joissa on usein pieniä lisäosia
Operaatiot, jotka koskettavat monia tiedostoja (MERGE, UPDATE, DELETE)

Esikirjoituksen tiivistäminen (optimoi kirjoitus) on yleensä edullisempaa kuin jälkikirjoitustiivistys (optimoi). Lisätietoja löytyy kohdasta Optimoi kirjoitus.

VACUUM komento

Komento VACUUM poistaa vanhat tiedostot, joihin Delta-taululoki ei enää viittaa:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

Oletuspidätysaika on seitsemän päivää. Lyhyempien säilytysaikojen asettaminen vaikuttaa Deltan aikamatkustuskykyihin ja voi aiheuttaa ongelmia samanaikaisille lukijoille tai kirjoittajille.

Lisätietoja löytyy kohdasta Lakehousen pöydän huolto.

V-järjestyksen optimointi

V-Order on kirjoitusaikainen optimointi, joka soveltaa VertiPaq-yhteensopivaa lajittelua, koodausta ja pakkausta Parquet-tiedostoihin:

Power BI Direct Lake: 40-60% parannus kylmävälimuistikyselyissä
SQL-analytiikan päätepiste ja varasto: Noin 10% lukusuorituskyvyn parannus
Spark: Ei luontaista lukuhyötyä; 15-33% hitaampia kirjoituksia

Milloin V-järjestys tulee ottaa käyttöön

V-Order tarjoaa eniten hyötyä:

Kultakerrostaulut, jotka palvelevat Power BI Direct Lakea
Taulukot, joita usein haetaan SQL-analytiikan päätepisteen kautta
Lukupainotteiset työkuormat, joissa kirjoitussuorituskyky on vähemmän kriittinen

Milloin V-järjestystä kannattaa välttää

Harkitse V-järjestyksen poistamista käytöstä seuraavissa tilanteissa:

Pronssikerrostaulukot, jotka keskittyvät nielemisnopeuteen
Spark-to-Spark-putket, joissa SQL ja Power BI eivät kuluta dataa
Kirjoituspainotteiset työkuormat, joissa datan viive on kriittistä

Määritä V-järjestys

V-Order on oletuksena pois päältä uusissa Fabric-työtiloissa. Ottaminen käyttöön:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

V-järjestyksen valikoivaksi soveltamiseksi Direct Lake -kulutuksen perusteella harkitse V-järjestyksen aktivoinnin automatisointia tauluille, joita käytetään Direct Lake -semanttisissa malleissa. Taulut, joita Direct Lake ei kuluta, voivat jäädä ilman V-Orderia paremman kirjoitussuorituskyvyn saavuttamiseksi.

Lisätietoja on kohdassa Delta Lake -taulukon optimointi ja V-järjestys.

Nestemäinen klusterointi ja Z-järjestys

Nesteklusterointi

Nestemäinen klusterointi on suositeltu lähestymistapa datan organisointiin. Toisin kuin perinteinen osiointi, nesteen klusterointi:

Sopeutuu muuttuviin kyselykuvioihin
Vaatii OPTIMIZE klusteroinnin käyttöä
Tarjoaa paremman tiedoston ohittamisen suodatetuille kyselyille

Ota Liquid Clustering käyttöön taulukon luomisessa:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z-järjestys

Z-järjestys kokoaa siihen liittyvää dataa samoihin tiedostoihin, joten saat paremman kyselysuorituskyvyn suodatinpredikaateilla.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Käytä Z-Orderia, kun:

Taulusi on osioitu, koska Liquid Clustering ei toimi osioitujen taulujen kanssa.
Kyselysi suodattuvat usein kahden tai useamman sarakkeen yhdessä.
Predikaattisi ovat tarpeeksi valikoivia hyötyäkseen tiedostojen ohittamisesta.

Medallion-arkkitehtuurisuositukset

Medallion-arkkitehtuuri (pronssi-, hopea-, kultakerrokset) tarjoaa kehyksen taulukon ylläpitostrategioiden optimointiin kunkin kerroksen tarkoituksen mukaan.

Pronssikerros (laskeutumisalue)

Pronssitaulukot keskittyvät kirjoitussuorituskykyyn ja matalan viiveen vastaanottoon:

Optimointiprioriteetti: Vastaanottonopeus lukusuorituskyvyn sijaan
Osiointi: Hyväksyttävää, mutta uusissa toteutuksissa ei suositella
Pienet tiedostot: Hyväksyttävää, koska painopiste on vastaanottonopeudessa
V-järjestys: Ei suositella (lisää kirjoituskuormaa)
Automaattinen tiivistyminen: Mahdollistaa pienten tiedostojen vähentämisen, mutta ne voidaan uhrata syöttönopeuden vuoksi
Poistovektorit: Otetaan käyttöön taulukoille, joissa on yhdistämiskuvioita

Pronssitaulukoita ei tule tarjota suoraan SQL-analytiikan päätepisteille tai Power BI Direct Lake -käyttäjille.

Hopeakerros (kuratoitu alue)

Hopeiset taulukot tasapainottavat kirjoitus- ja lukusuorituskyvyn:

Optimointiprioriteetti: Tasapaino vastaanoton ja kyselyn suorituskyvyn välillä
Tiedostokoot: Kohtalainen (128–256 MB) tukemaan sekä kirjoitus- että lukutoimintoja
V-järjestys: Valinnainen; aktivoida, jos SQL-analytiikan päätepiste tai Power BI:n kulutus on merkittävää
Liquid Clustering eli Z-Order: Suositellaan kyselysuorituskyvyn parantamiseen
Automaattinen tiivistys ja optimointi-kirjoitus: Ota käyttöön alavirran vaatimusten mukaan
Poistovektorit: Ota käyttöön tauluille, joissa päivitetään usein
Aikataulutettu OPTIMIZE: Suorita aggressiivisesti tiedostoasettelun ylläpitämiseksi

Kultakerros (tarjoilualue)

Kultaiset taulukot priorisoivat lukusuorituskyvyn loppukäyttäjän kulutuksessa:

Optimointiprioriteetti: Lue suorituskykyä analytiikkaa varten
Tiedostokoot: Suuret (400 MB–1 GB) optimaalisen SQL- ja Power BI:n suorituskyvyn takaamiseksi
V-Order: Vaaditaan Power BI Direct Lakelle; Hyödyllinen SQL-analytiikan päätepisteelle
Nestemäinen klusterointi: Välttämätön optimaaliseen tiedostojen ohittamiseen
Optimize-write: Vaaditaan yhtenäisille tiedostokooille
Aikataulutettu OPTIMIZE: Aja aggressiivisesti optimaalisen asettelun ylläpitämiseksi

Optimoi kultapöydät eri tavalla ensisijaisen kulutusmoottorin mukaan:

Kulutusmoottori	V-järjestys	Kohdetiedoston koko	Riviryhmän koko
SQL-analytiikan päätepiste	Kyllä	400 MB	2 miljoonaa riviä
Power BI Direct Lake	Kyllä	400 MB:stä 1 GB:iin	8+ miljoonaa riviä
Spark	Valinnainen	128 MB – 1 GB	1–2 miljoonaa riviä

Useita taulukkokopioita

On hyväksyttävää ylläpitää useita kopioita taulukoista, jotka on optimoitu eri kulutustottumille:

Hopeapöytä, joka on optimoitu Spark-käsittelyyn
Kultainen taulukko, joka on optimoitu SQL-analytiikkapäätepisteelle ja Power BI Direct Lakelle
Dataputket, jotka muuntavat ja sijoittavat oikean rakenteen jokaiselle kerrokselle

Tallennustila on edullisempaa verrattuna laskentaan. Taulukoiden optimointi kulutustottumusten mukaan tarjoaa paremman käyttökokemuksen kuin yrittää palvella kaikkia kuluttajia yhdestä taulukosta.

Tunnista taulukon terveys

Ennen taulukoiden optimointia arvioi nykyinen taulukkojen kunto ymmärtääksesi optimointitarpeita.

Tutki Parquet-tiedostoja suoraan

Voit selata OneLaken taulukkokansiota ja tarkastella yksittäisten Parquet-tiedostojen kokoja. Terveissä taulukoissa tiedostokoot jakautuvat tasaisesti. Etsi:

Yhtenäiset tiedostokoot: Tiedostojen tulisi olla suunnilleen saman kokoisia (enintään 2x toisistaan).
Ei erittäin pieniä tiedostoja: alle 25 MB tiedostot viittaavat pirstoutumiseen.
Ei erittäin suuria tiedostoja: Yli 2 GB tiedostot voivat vähentää rinnakkaisuutta.

Epätasainen tiedostokokojakauma viittaa usein puuttuviin tiivistyksiin tai epäjohdonmukaisiin kirjoituskuvioihin eri työtehtävissä.

OPTIMIZE DRY RUN in Spark SQL

Käytä vaihtoehtoa DRY RUN esikatsoaksesi, mitkä tiedostot ovat optimoitavissa ilman tiivistämistä:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

Komento palauttaa listan tiedostoista, jotka kirjoitettaisiin uudelleen optimoinnin aikana. Käytä tätä:

Arvioi optimoinnin laajuus ennen kuin käynnistät sen.
Ymmärrä tiedostojen pirstoutuminen ilman taulun muuttamista.
Arvioi optimointiaika sen mukaan, kuinka monta tiedostoa vaikutetaan.

Tiedostokoon jakauma

Käytä seuraavaa lähestymistapaa tiedostokokojen ja jakautumisen analysointiin:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Jakauma voi olla vinoutunut, sillä tiedostot, jotka ovat lähellä taulukon alkua tai tietystä osiosta, eivät välttämättä ole optimoituja.

Voit arvioida jakaumaa ajamalla kyselyn, joka ryhmittyy taulukon osiointi- tai klusterointiavainten mukaan.

Määritä optimointitarpeet

Vertaa todellisia tiedostokokoja kulutusmoottorin perusteella tavoitekokoihin:

Moottori	Kohdetiedoston koko	Jos tiedostot ovat pienempiä	Jos tiedostot ovat suurempia
SQL-analytiikan päätepiste	400 MB	`OPTIMIZE`in suorittaminen	Tiedostot ovat hyväksyttäviä
Power BI Direct Lake	400 MB:stä 1 GB:iin	`OPTIMIZE VORDER`in suorittaminen	Tiedostot ovat hyväksyttäviä
Spark	128 MB – 1 GB	Ota automaattinen tiivistys käyttöön	Tiedostot ovat hyväksyttäviä

Taulukkohistoria ja transaktioloki

Käy läpi taulukkohistoria ymmärtääksesi kirjoituskuviot ja ylläpidon tiheyden:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Konfiguraation parhaat käytännöt

Käytä taulun ominaisuuksia istuntoasetusten sijaan

Taulukon ominaisuudet säilyvät sessioiden aikana ja varmistavat johdonmukaisen käyttäytymisen kaikissa töissä ja kirjoittajissa:

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Istuntotason asetukset koskevat vain nykyistä Spark-istuntoa ja voivat aiheuttaa epäjohdonmukaisia kirjoituksia, jos eri sessiot käyttävät eri asetuksia.

Ota käyttöön adaptiivinen kohdetiedostokoko

Adaptive target file -koko säätää automaattisesti tiedostokokoisia kohteita taulukon koon mukaan:

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Toiminnon ominaisuuksia:

Alkaa pienemmillä tiedostoilla (128 MB) pienille taulukoille
Skaalaa jopa 1 GB:iin yli 10 TB taulukoissa
Arvioi automaattisesti uudelleen operaatioiden aikana OPTIMIZE

Ota käyttöön tiedostotason tiivistyskohteet

Estä aiemmin tiivistettyjen tiedostojen uudelleenkirjoittaminen, kun kohdekoot muuttuvat:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Suositusten yhteenveto

Kerros	Automaattinen tiivistyminen	Optimize-write	V-järjestys	Nesteklusterointi	Aikataulutettu OPTIMIZE
Pronssi	Ota käyttöön (valinnainen)	Ota käyttöön	Ei	Ei	Valinnainen
Hopea	Ota käyttöön	Ota käyttöön	Valinnainen	Kyllä	Aggressiivinen
Kulta	Ota käyttöön	Ota käyttöön	Kyllä	Kyllä	Aggressiivinen

Erityistilanteissa käytä seuraavia suosituksia:

Spark-to-Spark: Keskity tiedostokoon optimointiin; V-tilaus valinnainen.
Spark-to-SQL: Mahdollista optimointi-kirjoitus ja automaattinen tiivistäminen; kohdistetaan 400 MB tiedostoihin, joissa on 2 miljoonaa riviryhmää.
Suoratoiston vastaanotto: Automaattinen tiivistys otetaan käyttöön; Aikatauluta lisätöitä OPTIMIZE SQL-käyttäjille.
Power BI Direct Lake: ota käyttöön V-Order; Kohdista 8+ miljoonaa riviryhmää; juokse OPTIMIZE VORDER.

Palaute

Onko tästä sivusta apua?

Last updated on 2026-02-13