Hei Habr! Esitän huomionne artikkelin käännöksen kirjoittajat Burak Yavuz, Brenner Heintz ja Denny Lee, joka valmisteltiin kurssin alkamista ennakoiden OTUS:lta.
Tietoa, kuten kokemuksemme, kertyy ja kehittyy jatkuvasti. Pysyäkseen vauhdissa henkisten maailmamalliemme täytyy mukautua uusiin tietoihin, joista osa sisältää uusia ulottuvuuksia – uusia tapoja tarkkailla asioita, joista meillä ei ollut aavistustakaan aiemmin. Nämä mentaaliset mallit eivät eroa paljoakaan taulukkokaavioista, jotka määräävät, miten luokittelemme ja käsittelemme uutta tietoa.
Tämä vie meidät skeeman hallintaan. Kun liiketoiminnan haasteet ja vaatimukset muuttuvat ajan myötä, muuttuu myös tietojesi rakenne. Delta Laken avulla on helppo ottaa käyttöön uusia mittauksia tietojen muuttuessa. Käyttäjillä on pääsy yksinkertaiseen semantiikkaan hallitakseen taulukkoskeemojaan. Näitä työkaluja ovat Schema Enforcement, joka suojaa käyttäjiä tahattomasti saastuttamasta taulukoitaan virheillä tai tarpeettomilla tiedoilla, ja Schema Evolution, joka mahdollistaa uusien arvokkaiden tietojen sarakkeiden lisäämisen automaattisesti oikeisiin paikkoihin. Tässä artikkelissa sukeltamme syvemmälle näiden työkalujen käyttöön.
Taulukkokaavioiden ymmärtäminen
Jokainen Apache Sparkin DataFrame sisältää skeeman, joka määrittää tietojen muodon, kuten tietotyypit, sarakkeet ja metatiedot. Delta Laken avulla taulukkoskeema tallennetaan JSON-muodossa tapahtumalokiin.
Mitä on järjestelmän täytäntöönpano?
Schema Enforcement, joka tunnetaan myös nimellä Schema Validation, on Delta Laken suojausmekanismi, joka varmistaa tietojen laadun hylkäämällä tietueet, jotka eivät vastaa taulukon skeemaa. Kuten suositun vain varausravintolan vastaanoton emäntä, hän tarkistaa, onko jokainen taulukkoon syötetty tietosarake vastaavassa odotettavissa olevien sarakkeiden luettelossa (eli onko jokaiselle niistä "varaus"). ). ja hylkää kaikki tietueet, joiden sarakkeet eivät ole luettelossa.
Kuinka skeeman täytäntöönpano toimii?
Delta Lake käyttää skeema-kirjoitustarkistusta, mikä tarkoittaa, että kaikkien uusien taulukkoon kirjoitettujen kirjoitusten yhteensopivuus kohdetaulukon skeeman kanssa tarkistetaan kirjoitushetkellä. Jos skeema on epäjohdonmukainen, Delta Lake keskeyttää tapahtuman kokonaan (tietoja ei kirjoiteta) ja ilmoittaa käyttäjälle poikkeuksesta epäjohdonmukaisuudesta.
Delta Lake käyttää seuraavia sääntöjä määrittääkseen, onko tietue yhteensopiva taulukon kanssa. Kirjoitettava datakehys:
- ei voi sisältää lisäsarakkeita, jotka eivät ole kohdetaulukon skeemassa. Toisaalta kaikki on kunnossa, jos saapuvat tiedot eivät sisällä ehdottomasti kaikkia taulukon sarakkeita - näille sarakkeille annetaan yksinkertaisesti nolla-arvoja.
- ei voi olla saraketietotyyppejä, jotka poikkeavat kohdetaulukon sarakkeiden tietotyypeistä. Jos kohdetaulukon sarake sisältää StringType-dataa, mutta vastaava sarake DataFramessa sisältää IntegerType-dataa, skeeman valvonta aiheuttaa poikkeuksen ja estää kirjoitustoiminnon suorittamisen.
- ei voi sisältää sarakkeiden nimiä, jotka eroavat vain kirjainkoosta. Tämä tarkoittaa, että et voi määrittää samassa taulukossa sarakkeita nimeltä Foo ja foo. Vaikka Sparkia voidaan käyttää isot ja pienet kirjaimet erottelevassa (oletus) -tilassa, Delta Lake säästää kirjainkokoa, mutta ei välitä skeeman tallennustilassa. Parketti on isot ja pienet kirjaimet huomioiva pylvästietojen tallentamisessa ja palauttamisessa. Päätimme lisätä tämän rajoituksen mahdollisten virheiden, tietojen vioittumisen tai tietojen katoamisen välttämiseksi (mitä koimme henkilökohtaisesti Databricksissä).
Tämän havainnollistamiseksi katsotaanpa, mitä tapahtuu alla olevassa koodissa, kun yritämme lisätä joitain äskettäin luotuja sarakkeita Delta Lake -taulukkoon, jota ei ole vielä määritetty hyväksymään niitä.
# Сгенерируем DataFrame ссуд, который мы добавим в нашу таблицу Delta Lake
loans = sql("""
SELECT addr_state, CAST(rand(10)*count as bigint) AS count,
CAST(rand(10) * 10000 * count AS double) AS amount
FROM loan_by_state_delta
""")
# Вывести исходную схему DataFrame
original_loans.printSchema()
root
|-- addr_state: string (nullable = true)
|-- count: integer (nullable = true)
# Вывести новую схему DataFrame
loans.printSchema()
root
|-- addr_state: string (nullable = true)
|-- count: integer (nullable = true)
|-- amount: double (nullable = true) # new column
# Попытка добавить новый DataFrame (с новым столбцом) в существующую таблицу
loans.write.format("delta")
.mode("append")
.save(DELTALAKE_PATH)
Returns:
A schema mismatch detected when writing to the Delta table.
To enable schema migration, please set:
'.option("mergeSchema", "true")'
Table schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
Data schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
-- amount: double (nullable = true)
If Table ACLs are enabled, these options will be ignored. Please use the ALTER TABLE command for changing the schema.Sen sijaan, että Delta Lake lisäisi automaattisesti uusia sarakkeita, se asettaa skeeman ja lopettaa kirjoittamisen. Auttaakseen määrittämään, mikä sarake (tai sarakejoukko) aiheuttaa ristiriidan, Spark tulostaa molemmat skeemat pinojäljestä vertailua varten.
Mitä hyötyä skeeman täytäntöönpanosta on?
Koska skeeman valvonta on melko tiukka tarkistus, se on erinomainen työkalu puhtaan, täysin muunnetun tietojoukon portinvartijana, joka on valmis tuotantoon tai kulutukseen. Käytetään tyypillisesti taulukoihin, jotka syöttävät suoraan tietoja:
- Koneoppimisalgoritmit
- BI-kojelaudat
- Tietojen analysointi- ja visualisointityökalut
- Mikä tahansa tuotantojärjestelmä, joka vaatii erittäin jäsenneltyä, vahvasti tyypitettyä semanttisia skeemoja.
Valmistellakseen tietojaan tätä viimeistä estettä varten monet käyttäjät käyttävät yksinkertaista "multi-hop" -arkkitehtuuria, joka lisää asteittain rakennetta taulukoihinsa. Saat lisätietoja tästä artikkelista
Tietenkin skeeman valvontaa voidaan käyttää missä tahansa liukuhihnassa, mutta muista, että suoratoisto taulukkoon voi tässä tapauksessa olla turhauttavaa, koska olet esimerkiksi unohtanut, että olet lisännyt toisen sarakkeen saapuviin tietoihin.
Tietojen laimentumisen estäminen
Tähän mennessä saatat ihmetellä, mistä meteli johtuu? Loppujen lopuksi joskus odottamaton "schema mismatch" -virhe voi kompastaa sinut työnkulkuun, varsinkin jos olet uusi Delta Lake -käyttäjä. Miksen vain anna skeeman muuttua tarpeen mukaan, jotta voin kirjoittaa DataFrame-kehykseni mistä tahansa?
Kuten vanha sanonta kuuluu, "ehkäisy on kilon arvoinen hoitoon". Jossain vaiheessa, jos et huolehdi skeemasi täytäntöönpanosta, tietotyyppien yhteensopivuusongelmat nostavat rumia päätään – näennäisesti homogeeniset raakatietolähteet voivat sisältää reunatapauksia, vioittuneita sarakkeita, väärin muotoiltuja kartoituksia tai muita pelottavia asioita, joista haaveilla. painajaisia. Paras tapa on pysäyttää nämä viholliset portilla - skeeman täytäntöönpanon avulla - ja käsitellä niitä valossa, eikä myöhemmin, kun he alkavat väijyä tuotantokoodisi pimeissä syvyyksissä.
Kaavan pakottaminen antaa sinulle varmuuden siitä, että taulukkosi skeema ei muutu, ellet hyväksy muutosta. Tämä estää tietojen laimenemisen, jota voi tapahtua, kun uusia sarakkeita lisätään niin usein, että aiemmin arvokkaat, pakatut taulukot menettävät merkityksensä ja hyödyllisyytensä tietotulvan vuoksi. Kannustamalla sinua olemaan tarkoituksellinen, asettamaan korkeat vaatimukset ja odottamaan korkeaa laatua skeeman valvonta tekee juuri sen, mitä se on suunniteltu – auttaa sinua pysymään tunnollisena ja laskentataulukosi puhtaina.
Jos tarkemmin harkitessasi päätät, että todella kaivata lisää uusi sarake - ei hätää, alla on yksirivinen korjaus. Ratkaisu on piirin kehitys!
Mikä on skeeman evoluutio?
Schema evolution on ominaisuus, jonka avulla käyttäjät voivat helposti muuttaa nykyistä taulukkokaaviota ajan myötä muuttuvien tietojen mukaan. Sitä käytetään useimmiten suoritettaessa lisäys- tai uudelleenkirjoitustoimintoa mukauttamaan skeema automaattisesti yhden tai useamman uuden sarakkeen sisällyttämiseksi.
Miten skeeman evoluutio toimii?
Edellisessä osiossa olevan esimerkin mukaisesti kehittäjät voivat helposti lisätä skeeman evoluution avulla uusia sarakkeita, jotka aiemmin hylättiin skeeman epäjohdonmukaisuuden vuoksi. Piirin kehitys aktivoidaan lisäämällä .option('mergeSchema', 'true') Spark-tiimillesi .write или .writeStream.
# Добавьте параметр mergeSchema
loans.write.format("delta")
.option("mergeSchema", "true")
.mode("append")
.save(DELTALAKE_SILVER_PATH)Voit tarkastella kaaviota suorittamalla seuraavan Spark SQL -kyselyn
# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%sql
SELECT addr_state, sum(`amount`) AS amount
FROM loan_by_state_delta
GROUP BY addr_state
ORDER BY sum(`amount`)
DESC LIMIT 10
Vaihtoehtoisesti voit asettaa tämän vaihtoehdon koko Spark-istunnolle lisäämällä spark.databricks.delta.schema.autoMerge = True Spark-kokoonpanoon. Käytä tätä kuitenkin varoen, sillä skeeman valvonta ei enää ilmoita tahattomista skeeman epäjohdonmukaisuuksista.
Sisällyttämällä parametrin pyyntöön mergeSchema, kaikki sarakkeet, jotka ovat DataFramessa mutta eivät kohdetaulukossa, lisätään automaattisesti skeeman loppuun osana kirjoitustapahtumaa. Sisäkkäisiä kenttiä voidaan myös lisätä ja ne lisätään myös vastaavien rakennesarakkeiden loppuun.
Päivämäärä-insinöörit ja datatutkijat voivat käyttää tätä vaihtoehtoa lisätäkseen uusia sarakkeita (ehkä äskettäin seuratun mittarin tai tämän kuun myynnin tehokkuussarakkeen) olemassa oleviin koneoppimisen tuotantotaulukoihinsa rikkomatta olemassa olevia malleja vanhoihin sarakkeisiin perustuen.
Seuraavat skeeman muutokset ovat sallittuja osana skeeman kehitystä taulukon lisäyksen tai uudelleenkirjoituksen aikana:
- Uusien sarakkeiden lisääminen (tämä on yleisin skenaario)
- Tietotyyppien muuttaminen NullType -> mistä tahansa muusta tyypistä tai edistäminen ByteType -> ShortType -> IntegerType -tyypistä
Muut muutokset, joita ei sallita skeemakehityksessä, edellyttävät, että skeema ja tiedot kirjoitetaan uudelleen lisäämällä .option("overwriteSchema", "true"). Esimerkiksi siinä tapauksessa, että sarake "Foo" oli alun perin kokonaisluku ja uusi skeema oli merkkijonotietotyyppi, kaikki Parquet(data)-tiedostot on kirjoitettava uudelleen. Tällaisia muutoksia ovat mm.
- sarakkeen poistaminen
- olemassa olevan sarakkeen tietotyypin muuttaminen (paikallisesti)
- sarakkeiden uudelleennimeäminen, jotka eroavat vain kirjainkoosta (esim. "Foo" ja "foo")
Lopuksi Spark 3.0:n seuraavassa julkaisussa eksplisiittistä DDL:ää tuetaan täysin (ALTER TABLE:n avulla), jolloin käyttäjät voivat suorittaa seuraavat taulukkokaaviot:
- sarakkeiden lisääminen
- muuttaa sarakkeen kommentteja
- taulukon ominaisuuksien asettaminen, jotka ohjaavat taulukon toimintaa, kuten tapahtumalokin tallennusajan määrittäminen.
Mitä hyötyä piirin evoluutiosta on?
Schema evolutionia voidaan käyttää milloin tahansa aikoo muuta taulukkosi kaaviota (toisin kuin silloin, kun lisäsit vahingossa DataFrame-kehykseen sarakkeita, joita ei pitäisi olla siellä). Tämä on helpoin tapa siirtää skeemasi, koska se lisää automaattisesti oikeat sarakkeiden nimet ja tietotyypit ilman, että niitä tarvitsee erikseen ilmoittaa.
Johtopäätös
Kaaman valvonta hylkää kaikki uudet sarakkeet tai muut kaaviomuutokset, jotka eivät ole yhteensopivia taulukosi kanssa. Asettamalla ja ylläpitämällä nämä korkeat standardit analyytikot ja insinöörit voivat luottaa siihen, että heidän tietonsa ovat mahdollisimman eheitä, ja ne välittävät ne selkeästi ja selkeästi, mikä antaa heille mahdollisuuden tehdä parempia liiketoimintapäätöksiä.
Toisaalta skeeman kehitys täydentää täytäntöönpanoa yksinkertaistamalla oletettu automaattiset skeeman muutokset. Loppujen lopuksi sarakkeen lisäämisen ei pitäisi olla vaikeaa.
Kaavan pakotettu soveltaminen on yang, jossa järjestelmän kehitys on yin. Yhdessä käytettynä nämä ominaisuudet tekevät kohinan vaimennuksen ja signaalin virityksen helpommaksi kuin koskaan.
Haluamme myös kiittää Mukul Murthya ja Pranav Anandia heidän panoksestaan tähän artikkeliin.
Muita tämän sarjan artikkeleita:
Aiheeseen liittyvät artikkelit
Lähde: will.com