Tämä artikkeli on käännös artikkelistani medialla - , joka osoittautui melko suosituksi luultavasti yksinkertaisuutensa vuoksi. Siksi päätin kirjoittaa sen venäjäksi ja lisätä hieman tehdäkseni tavalliselle henkilölle, joka ei ole tietoasiantuntija, selväksi, mikä on tietovarasto (DW) ja mikä on datajärvi (Data Lake) ja miten he tekevät. tulla toimeen yhdessä.
Miksi halusin kirjoittaa datajärvestä? Olen työskennellyt datan ja analytiikan parissa yli 10 vuotta, ja nyt työskentelen ehdottomasti big datan parissa Amazon Alexa AI:ssä Cambridgessa, joka on Bostonissa, vaikka asun Victoriassa Vancouver Islandilla ja vierailen usein Bostonissa, Seattlessa. , ja Vancouverissa ja joskus jopa Moskovassa puhun konferensseissa. Kirjoitan myös silloin tällöin, mutta kirjoitan pääasiassa englanniksi, ja olen jo kirjoittanut , minulla on myös tarve jakaa analytiikkatrendejä Pohjois-Amerikasta, ja kirjoitan toisinaan .
Olen aina työskennellyt tietovarastojen parissa, ja vuodesta 2015 lähtien aloin tehdä tiivistä yhteistyötä Amazon Web Services -palvelun kanssa ja vaihdoin yleensä pilvianalyysiin (AWS, Azure, GCP). Olen seurannut analytiikkaratkaisujen kehitystä vuodesta 2007 lähtien ja jopa työskennellyt tietovarastotoimittaja Teradatan palveluksessa ja ottanut sen käyttöön Sberbankissa, ja silloin Big Data Hadoopilla ilmestyi. Kaikki alkoivat sanoa, että tallennusaika oli ohi ja nyt kaikki oli Hadoopissa, ja sitten he alkoivat taas puhua Data Lakesta, että nyt tietovaraston loppu oli ehdottomasti tullut. Mutta onneksi (ehkä valitettavasti joillekin, jotka tekivät paljon rahaa Hadoopin perustamisella) tietovarasto ei hävinnyt.
Tässä artikkelissa tarkastellaan mitä datajärvi on. Tämä artikkeli on tarkoitettu ihmisille, joilla on vähän tai ei ollenkaan kokemusta tietovarastoista.
Kuvassa Bledjärvi, tämä on yksi suosikkijärvistäni, vaikka olin siellä vain kerran, muistin sen loppuelämäni. Mutta puhumme toisen tyyppisestä järvestä - datajärvestä. Ehkä monet teistä ovat jo kuulleet tästä termistä useammin kuin kerran, mutta vielä yksi määritelmä ei vahingoita ketään.
Ensinnäkin tässä ovat suosituimmat Data Laken määritelmät:
"Kaikentyyppisen raakadatan tiedostovarasto, joka on kaikkien organisaation jäsenten analysoitavissa" - Martin Fowler.
”Jos luulet, että datamarket on vesipullo – puhdistettua, pakattu ja pakattu kätevää kulutusta varten, niin datajärvi on valtava vesisäiliö luonnollisessa muodossaan. Käyttäjät, voin kerätä vettä itselleni, sukeltaa syvälle, tutkia.” - James Dixon.
Nyt tiedämme varmasti, että datajärvi on analytiikkaa, sen avulla voimme tallentaa suuria määriä dataa alkuperäisessä muodossaan ja meillä on tarvittava ja kätevä pääsy dataan.
Tykkään usein yksinkertaistaa asioita, jos voin selittää monimutkaisen termin yksinkertaisilla sanoilla, niin ymmärrän itse, miten se toimii ja mihin sitä tarvitaan. Eräänä päivänä tuijotin iPhonen kuvagalleriassa, ja minulle valkeni, tämä on todellinen datajärvi, tein jopa dian konferensseja varten:
Kaikki on hyvin yksinkertaista. Otamme valokuvan puhelimella, kuva tallennetaan puhelimeen ja voidaan tallentaa iCloudiin (pilvitiedostojen tallennus). Puhelin kerää myös kuvien metatietoja: mitä näytetään, geotunniste, aika. Tämän seurauksena voimme käyttää iPhonen käyttäjäystävällistä käyttöliittymää valokuvamme löytämiseen ja näemme jopa ilmaisimia, esimerkiksi kun haen kuvia sanalla tuli, löydän 3 valokuvaa, joissa on kuva tulipalosta. Minulle tämä on kuin Business Intelligence -työkalu, joka toimii erittäin nopeasti ja selkeästi.
Ja tietenkään emme saa unohtaa turvallisuutta (valtuutus ja todennus), muuten tietomme voivat helposti päätyä julkisiin tietoihin. Paljon uutisia on suurista yrityksistä ja startupeista, joiden tiedot tulivat julkisesti saataville kehittäjien huolimattomuuden ja yksinkertaisten sääntöjen noudattamatta jättämisen vuoksi.
Jo tällainen yksinkertainen kuva auttaa meitä kuvittelemaan, mikä datajärvi on, sen erot perinteiseen tietovarastoon ja sen pääelementtejä:
- Ladataan tietoja (Neliöinti) on datajärven avainkomponentti. Tietoa voidaan syöttää tietovarastoon kahdella tavalla - eränä (lataus väliajoin) ja suoratoistona (tietovirta).
- Tiedostojen tallennus (Tallennus) on Data Laken pääkomponentti. Tarvitsimme tallennustilan olevan helposti skaalautuva, erittäin luotettava ja edullinen. Esimerkiksi AWS:ssä se on S3.
- Katalogi ja haku (Katalogi ja haku) - jotta voimme välttää Data Swampin (tämä on kun upotamme kaikki tiedot yhteen pinoon, ja sen kanssa on mahdotonta työskennellä), meidän on luotava metatietokerros tietojen luokittelemiseksi jotta käyttäjät löytävät helposti analysointiin tarvitsemansa tiedot. Lisäksi voit käyttää muita hakuratkaisuja, kuten ElasticSearch. Haku auttaa käyttäjää löytämään tarvittavat tiedot käyttäjäystävällisen käyttöliittymän kautta.
- Käsittely (Prosessi) - tämä vaihe on vastuussa tietojen käsittelystä ja muuntamisesta. Voimme muuttaa tietoja, muuttaa sen rakennetta, puhdistaa ja paljon muuta.
- Безопасность (Turvallisuus) - On tärkeää käyttää aikaa ratkaisun turvallisuussuunnitteluun. Esimerkiksi tietojen salaus tallennuksen, käsittelyn ja latauksen aikana. On tärkeää käyttää todennus- ja valtuutusmenetelmiä. Lopuksi tarvitaan tarkastustyökalu.
Käytännön näkökulmasta voimme luonnehtia datajärveä kolmella attribuutilla:
- Kerää ja säilytä mitä tahansa — Data Lake sisältää kaikki tiedot, sekä käsittelemättömät raakatiedot miltä tahansa ajanjaksolta että käsitellyt/puhdistetut tiedot.
- Deep Scan — Datajärven avulla käyttäjät voivat tutkia ja analysoida tietoja.
- Joustava pääsy — Data Lake tarjoaa joustavan pääsyn erilaisille tiedoille ja erilaisille skenaarioille.
Nyt voimme puhua datavaraston ja datajärven erosta. Yleensä ihmiset kysyvät:
- Entä tietovarasto?
- Korvataanko tietovarasto datajärvellä vai laajennetaanko sitä?
- Pystyykö vielä pärjäämään ilman datajärveä?
Lyhyesti sanottuna selvää vastausta ei ole. Kaikki riippuu tilanteesta, joukkueen taidoista ja budjetista. Esimerkiksi tietovaraston siirtäminen Oracleen AWS:ään ja datajärven luominen Amazonin tytäryhtiön - Woot - toimesta. .
Toisaalta myyjä Snowflake sanoo, että sinun ei enää tarvitse ajatella datajärveä, koska heidän tietoalustaan (vuoteen 2020 asti se oli tietovarasto) voit yhdistää sekä datajärven että tietovaraston. En ole työskennellyt paljon Snowflaken kanssa, ja se on todella ainutlaatuinen tuote, joka voi tehdä tämän. Lehden hinta on toinen asia.
Lopuksi, henkilökohtainen mielipiteeni on, että tarvitsemme edelleen tietovaraston raportointimme pääasialliseksi tietolähteeksi, ja kaiken, mikä ei sovi, tallennamme datajärveen. Analytiikan koko rooli on tarjota yrityksille helppo pääsy päätöksentekoon. Mitä tahansa voi sanoa, yrityskäyttäjät työskentelevät tehokkaammin tietovaraston kuin datajärven kanssa, esimerkiksi Amazonissa - siellä on Redshift (analyyttinen tietovarasto) ja Redshift Spectrum/Athena (SQL-liitäntä datajärvelle S3:ssa, joka perustuu Hive/Presto). Sama pätee muihin nykyaikaisiin analyyttisiin tietovarastoihin.
Katsotaanpa tyypillistä tietovarastoarkkitehtuuria:
Tämä on klassinen ratkaisu. Meillä on lähdejärjestelmiä, ETL/ELT:n avulla kopioimme tiedot analyyttiseen tietovarastoon ja yhdistämme sen Business Intelligence -ratkaisuun (suosikkini on Tableau, entä sinun?).
Tällä ratkaisulla on seuraavat haitat:
- ETL/ELT-toiminta vaatii aikaa ja resursseja.
- Muisti tietojen tallentamiseen analyyttiseen tietovarastoon ei yleensä ole halpaa (esimerkiksi Redshift, BigQuery, Teradata), koska meidän on ostettava koko klusteri.
- Yrityskäyttäjillä on pääsy puhdistettuun ja usein aggregoituun dataan, eikä heillä ole pääsyä raakatietoihin.
Tietysti kaikki riippuu tapauksestasi. Jos sinulla ei ole ongelmia tietovaraston kanssa, et tarvitse datajärveä ollenkaan. Mutta kun ongelmia ilmenee tilan puutteesta, tehosta tai hinnasta, joka on avainasemassa, voit harkita datajärven vaihtoehtoa. Tästä syystä datajärvi on erittäin suosittu. Tässä on esimerkki datajärven arkkitehtuurista:
Data Lake -lähestymistapaa käyttämällä lataamme raakadataa datajärveemme (erä tai suoratoisto), jonka jälkeen käsittelemme tiedot tarpeen mukaan. Datajärven avulla yrityskäyttäjät voivat luoda omia tietomuunnoksia (ETL/ELT) tai analysoida tietoja Business Intelligence -ratkaisuissa (jos tarvittava ajuri on saatavilla).
Minkä tahansa analytiikkaratkaisun tavoitteena on palvella yrityskäyttäjiä. Siksi meidän on aina toimittava liiketoiminnan vaatimusten mukaisesti. (Amazonilla tämä on yksi periaatteista - työskentely taaksepäin).
Kun työskentelemme sekä tietovaraston että datajärven kanssa, voimme verrata molempia ratkaisuja:
Tärkein johtopäätös on, että tietovarasto ei kilpaile datajärven kanssa, vaan täydentää sitä. Mutta sinun on päätettävä, mikä on oikea tapaus. On aina mielenkiintoista kokeilla sitä itse ja tehdä oikeat johtopäätökset.
Haluaisin myös kertoa yhden tapauksesta, jolloin aloin käyttämään datajärvi -lähestymistapaa. Kaikki on melko triviaalia, yritin käyttää ELT-työkalua (meillä oli Matillion ETL) ja Amazon Redshiftiä, ratkaisuni toimi, mutta ei vastannut vaatimuksia.
Minun täytyi ottaa verkkolokit, muuttaa ne ja yhdistää ne saadakseni tietoja kahdesta tapauksesta:
- Markkinointitiimi halusi analysoida robottien toimintaa hakukoneoptimoinnissa
- IT halusi tarkastella verkkosivustojen tehokkuusmittareita
Hyvin yksinkertaiset, hyvin yksinkertaiset lokit. Tässä on esimerkki:
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"Yksi tiedosto painoi 1-4 megatavua.
Mutta siinä oli yksi vaikeus. Meillä oli 7 verkkotunnusta ympäri maailmaa, ja yhdessä päivässä luotiin 7000 50 tuhatta tiedostoa. Tämä ei ole paljon suurempi määrä, vain 4 gigatavua. Mutta myös Redshift-klusterimme koko oli pieni (XNUMX solmua). Yhden tiedoston lataaminen perinteisellä tavalla kesti noin minuutin. Eli ongelma ei ratkennut suoraan. Ja tämä oli tilanne, kun päätin käyttää data Lake -lähestymistapaa. Ratkaisu näytti tältä:
Se on melko yksinkertainen (haluan huomata, että pilvessä työskentelyn etuna on yksinkertaisuus). Käytin:
- AWS Elastic Map Reduce (Hadoop) laskentatehoa varten
- AWS S3 tiedostovarastona, jossa on mahdollisuus salata tiedot ja rajoittaa pääsyä
- Spark InMemory-laskentatehona ja PySpark logiikkaan ja tiedon muuntamiseen
- Parketti Sparkin seurauksena
- AWS Glue Crawler metatietojen kerääjänä uusista tiedoista ja osioista
- Redshift Spectrum SQL-liittymänä datajärveen olemassa oleville Redshift-käyttäjille
Pienin EMR+Spark-klusteri käsitteli koko tiedostopinon 30 minuutissa. AWS:lle on muitakin tapauksia, erityisesti monia Alexaan liittyviä tapauksia, joissa on paljon dataa.
Äskettäin opin, että yksi datajärven haitoista on GDPR. Ongelmana on, että kun asiakas pyytää poistamaan sen ja tiedot ovat jossakin tiedostossa, emme voi käyttää Data Manipulation Language- ja DELETE-toimintoa kuten tietokannassa.
Toivon, että tämä artikkeli on selventänyt eroa tietovaraston ja datajärven välillä. Jos kiinnostuit, voin kääntää lisää lukemiani artikkeleita tai ammattilaisten artikkeleita. Ja kerron myös ratkaisuista, joiden kanssa työskentelen, ja niiden arkkitehtuurista.
Lähde: will.com