viime vuosina olen käynyt monia keskusteluja ystävien ja kollegoiden kanssa turhautuneena siitä, kuinka käsittämättömän monimutkainen tietoinfrastruktuurin ekosysteemi on. Vaikka ei aivan niin paha kuin front-end maailma, asiat muuttuvat tarpeeksi nopeasti luoda buzzword keitto.

aloittelijana on superhaastavaa päättää, mitkä työkalut sopivat juuri sinulle. Apache Foundation listaa 38 projektia ”Big Data” – osiossa, ja näillä työkaluilla on tonneittain päällekkäisyyksiä niissä ongelmissa, joihin ne väittävät puuttuvansa. Esimerkiksi Flink, Samza, Storm ja Spark Streaming ovat ”distributed stream processing engines”, Apex ja Beam ”unify stream and batch processing”.

tässä viestissä toivon tarjoavani apua vaihtoehtojen navigointiin, kun määrität datainfrastruktuurin rakentamisen. Nämä ovat suurin piirtein vaiheet, joita seuraisin tänään, perustuen kokemuksiini viime vuosikymmeneltä ja keskusteluihin kollegoiden kanssa, jotka työskentelevät tässä tilassa.

alussa projektin, olet luultavasti esitetään mitään muuta kuin tavoite ”saada oivalluksia datani” kädessä. Tämän vertaaminen tiettyihin teknologioihin on erittäin pelottavaa. Sinulla ei luultavasti ole suurta käsitystä siitä, mitä työkalut ovat suosittuja, mitä ” stream ”tai” erä ” tarkoittaa, tai onko edes tarvitse datainfrastruktuuria ollenkaan.

tässä viestissä toivon voivani antaa ohjeita, joiden avulla pääset nopeasti vauhtiin ja saat kerättyä tietoja. Uskon vahvasti asioiden pitämiseen yksinkertaisina mahdollisimman pitkään, monimutkaisuuden tuomiseen vain silloin, kun sitä tarvitaan skaalautuvuuteen. Tämä viesti seuraa, että kaari kolmessa vaiheessa. Monin tavoin, se retraces vaiheet rakennuksen tietoinfrastruktuurin että olen seurannut viime vuosina.

huomaa, että ei ole olemassa yhtä oikeaa tapaa suunnitella datainfrastruktuuria. Asiantuntijoiden käsittelyssä tämä, Olet ehkä mieluummin vaihtoehtoja ratkaisuja ehdotetaan tässä. Se on fantastinen, ja korostaa erilaisia uskomattomia työkaluja meillä on näinä päivinä. Olemme tulleet kauas siitä, kun Hadoop MapReduce oli kaikki mitä meillä oli.

juttu on näin: ”big data” ei taida vielä löytyä. Lähes 4 vuotta myöhemmin Chris Stucchion vuonna 2013 julkaistu artikkeli Don ’ t use Hadoop on yhä ajankohtainen. Jos sinulla on alle 5TB tietoja, aloita pieni. Tämä säästää toiminnallisia päänsärkyä ylläpitämällä järjestelmiä, joita et vielä tarvitse. But hey, if you love 3am fire drills from job failures, feel free to skip this section…

Otherwise, stay away of all the buzzword technologies at the start, and focus on two things: (1) making your data queryable in SQL, and (2) choosing a BI Tool. Nämä ovat” Hei, maailma ” selkäranka kaikille tulevaisuuden datainfrastruktuurin.

kaikki SQL

tämä on todella tärkeää, koska se avaa tiedot koko organisaatiolle. Harvoja poikkeuksia kaikkein peloton markkinointi ihmiset, et koskaan vakuuttaa ei-TEKNISET kollegat oppia Kibana, grep joitakin lokit, tai käyttää hämärä syntaksi Oman NoSQL datastore.

SQL-käyttöoikeuden tarjoaminen mahdollistaa sen, että koko yhtiöstä tulee itsepalveluanalyytikkoja, jolloin jo venynyt insinööritiimisi poistuu kriittiseltä polulta. Se myös muuttaa kaikki ilmainen QA joukkue tietosi. ”Hei, nämä numerot näyttävät jotenkin oudolta…” on korvaamaton löytää vikoja datasi ja jopa tuotteesi.

jos ensisijainen datastore on relaatiotietokanta, kuten PostgreSQL tai MySQL, tämä on todella yksinkertaista. Voit vain perustaa lukujäljennöksen, pääsyn säännöksiin, ja olet valmis.

NoSQL-tietokannassa, kuten ElasticSearch, MongoDB tai DynamoDB, sinun täytyy tehdä enemmän työtä muuntaaksesi tietosi ja laittaaksesi ne SQL-tietokantaan. Jos olet uusi datamaailmassa, kutsumme tätä ETL: n putkeksi. Vältä rakentaa tätä itse, jos mahdollista, koska johdotus off-the-hylly ratkaisu on paljon halvempaa pienillä tietomäärillä. Riippuen olemassa olevasta infrastruktuurista, voi olla pilvi ETL tarjoaja kuten segmentti, että voit hyödyntää.

jos huomaat, että sinun on rakennettava omat dataputkesi, pidä ne aluksi hyvin yksinkertaisina. Kirjoita skripti ajoittain dump päivitykset tietokannasta ja kirjoittaa ne jonnekin queryable SQL.

3. osapuolen lähteiden etlingin tietojen tarina on samankaltainen kuin NoSQL-tietokannoissa. Käytä ETL-as-a-service-tarjoajaa tai kirjoita yksinkertainen skripti ja talleta tietosi SQL-queryable-tietokantaan.

laita kone pyörittämään ETL-skriptiäsi päivittäisenä kronikkana, niin pääset kisoihin.

BI-työkalu

hyvä BI-työkalu on tärkeä osa tietojesi ymmärtämistä. Hienoja työkaluja harkita ovat Chartio, Mode Analytics, ja Periscope Data — jokin näistä pitäisi toimia hyvin saada analytiikka vauhtiin. Useimmissa tapauksissa voit osoittaa nämä työkalut suoraan SQL-tietokantaan nopealla kokoonpanolla ja sukeltaa suoraan dashboardien luomiseen.

vetämällä tämä kaikki yhteen, tässä on tietoinfrastruktuurin ”Hello, World”:

Vaihe 1:” Hei, maailma ”pieni dataputki

Vaihe 2: kutsutaan sitä” mediumiksi ” tieto

tässä vaiheessa on enemmän kuin muutama teratavu kellumassa, eikä cron+script ETL ihan pysy perässä. Ehkä olet proliferated datastores ja on heterogeeninen sekoitus SQL ja NoSQL backends. Sinulla saattaa myös olla nyt kourallinen kolmansia osapuolia, joilta keräät tietoja. Lopuksi, saatat alkaa olla useita vaiheita ETL putkistot joitakin riippuvuuksia vaiheiden välillä.

työnkulun hallinta & automaatio

ensimmäinen vaihe tässä vaiheessa olisi ilmavirran käyttöönotto ETL-putkistojen hallintaa varten. Ilmavirran avulla voit ajoittaa työt säännöllisin väliajoin ja ilmaista sekä ajallisia että loogisia riippuvuuksia työtehtävien välillä. Se on myös hyvä paikka oman infrastruktuurin lisätä työn uudelleen, seuranta & hälyttää tehtävien epäonnistumisia. Se on käynnissä vitsi, että jokainen käynnistyksen yläpuolella tietyn koon kirjoittaa oman työnkulun hallinta / työn ajoitus. Muun muassa Spotify kirjoitti Luigia ja Pinterest flipperiä. Niillä on kuitenkin vähemmän vauhtia yhteisössä, ja niistä puuttuu joitakin ilmavirran ominaisuuksia.

ETL-putkistojen rakentaminen

liiketoiminnan kasvaessa ETL-putkistojen vaatimukset muuttuvat merkittävästi. Sinun täytyy alkaa rakentaa enemmän skaalautuva infrastruktuuri, koska yksi skripti ei leikkaa sitä enää. Tavoitteesi ovat myös todennäköisesti laajentaa yksinkertaisesti mahdollistaa SQL access kattaa tukemalla muita loppupään työpaikkoja, jotka käsittelevät samoja tietoja.

lopulta yksinkertaiset putkistot eivät skaalaa

näihin muuttuviin vaatimuksiin vastaamiseksi, sinun kannattaa muuntaa ETL-skriptit toimimaan hajautettuna työnä klusterissa. Mahdollisten ratkaisujen määrä tässä on aivan ylivoimainen. Suosittelen aloittamaan Apache Sparkista. Spark on valtava, erittäin aktiivinen yhteisö, skaalaa hyvin, ja on melko helppo saada vauhtiin nopeasti. AWS: ssä voit ajaa Sparkia käyttämällä EMR; for GCP: tä Cloud Dataprocin avulla. Jos syöt dataa relaatiotietokannasta, Apache Sqoop on aika lailla standardi.

tässä vaiheessa ETL-infrastruktuurisi alkaa näyttää liukuhihnatyövaiheilta, jotka toteuttavat kolme ETL-verbiä: poimia tietoja lähteistä, muuttaa nämä tiedot Vakioituihin formaatteihin pysyvässä tallennustilassa ja ladata ne SQL-queryable datastore-muotoon.

tietovarasto

tässä vaiheessa kaikkien tietojen saaminen SQL: ään pysyy prioriteettina, mutta nyt kannattaa alkaa rakentaa ”oikeaa” tietovarastoa.

juuri aloittaville suosittelisin BigQueryn käyttöä. BigQuery on helppo perustaa (voit vain ladata kirjaa JSON), tukee sisäkkäisiä/monimutkaisia tietotyyppejä, ja on täysin hallittu/palvelimeton, joten sinulla ei ole enemmän infrastruktuuria ylläpidettäväksi. Kuten monet suositukset täällä, vaihtoehtoja BigQuery ovat saatavilla: on AWS, Redshift, ja on-prem, Presto. Minulla on vahva mieluummin BigQuery yli Redshift koska sen serverless suunnittelu, yksinkertaisuus konfigurointi oikea turvallisuus / tilintarkastus, ja tukea monimutkaisia tyyppejä. Prestoa kannattaa harkita, jos on-premille on kova vaatimus.

kun harkitset tietovaraston perustamista, kätevä malli on ottaa käyttöön 2-vaiheinen malli, jossa käsittelemätön tieto puretaan suoraan taulukkojoukkoon, ja toinen työ sen jälkeen, kun tämä data käsitellään ”puhtaammiksi” taulukoiksi.

käsittele näitä puhtaampia taulukoita mahdollisuutena luoda kuratoitu näkymä liiketoimintaasi. Sinun tulisi luoda ja kuratoida jokaiselle yrityksesi keskeiselle kokonaisuudelle taulukko, jossa on kaikki kyseisen kokonaisuuden analysointiin usein käyttämäsi mittarit/KPI: t ja mitat. Esimerkiksi ”käyttäjät” – taulukko saattaa sisältää mittareita, kuten kirjautumisaikaa, ostojen lukumäärää ja ulottuvuuksia, kuten maantieteellistä sijaintia tai hankintakanavaa.

kaiken tämän jälkeen infrastruktuurisi pitäisi näyttää jokseenkin tältä:

Vaihe 2: ”medium” dataputki

🚀 Vaihe 3: Isoksi meneminen

oikeilla perustuksilla kasvun jatkumisen ei tarvitse olla kivuliasta. Voit usein tehdä tehdä yksinkertaisesti heittämällä laitteisto ongelma käsittelyn lisääntynyt tietomääriä.

haastavimpia ongelmia tällä kaudella ovat usein raa ’ an mittakaavan lisäksi laajenevat vaatimukset. Esimerkiksi, ehkä sinun täytyy tukea A / B testaus, kouluttaa koneoppimisen malleja, tai putki muuntaa dataa ElasticSearch cluster.

tässä vaiheessa kannattaa harkita joitakin asioita:

  • lähes reaaliaikainen: Et luultavasti tarvitse hajautettua jonoa tai lähes reaaliaikaista infrastruktuuria ennen kuin paljon myöhemmin kuin luulet. Siinä on paljon lisättyä monimutkaisuutta käsitellä kaikkia mahdollisia vikatiloja, mikä ei ole sen arvoista varhaisessa vaiheessa. Kun ROI calculus on järkevää, kokeile Kafka tai Cloud Pub / Sub.
  • skaalautuvuus: yhden monoliittisen Kipinärykelmän kanssa törmää lähes varmasti ongelmiin resurssikisan kanssa. Kun niin käy, täysin kimmoisat työpaikkakiusatut Kipinärykelmät ovat tutustumisen arvoisia.
  • Turvallisuus & Tilintarkastus: Jossain vaiheessa haluat ehkä valvoa tarkempaa pääsyä tietovaraston tietoihin. Jos käytät Bigquerya, voit tarjota dataset-käyttöoikeuden Google-ryhmille ja hallita sitä ohjelmallisesti Deployment Managerin avulla. BigQuery tarjoaa myös tarkastuslokit käyttäjien kyselyjen ymmärtämiseksi. Muita työkaluja, kuten Apache Knox ja Apache Sentry ovat saatavilla on-prem-tietoturvaratkaisuihin.
  • A/B-testaus: talon sisäiseen A/B-testaukseen ja kokeiluja tukevaan testaukseen ei valitettavasti ole montaa off-the-hylly-ratkaisua. Rakentaminen putki kipinä työpaikkoja, jotka kansoittavat taulukoita Oman tietovaraston on luultavasti paras vaihtoehto.
  • Koneoppiminen: ominaisuuksien louhintaa varten Sparkiin voi rakentaa lisää dataputkia. Itse malleille kannattaa taas aloittaa pienestä. Prosessoidut ominaisuutesi ovat todennäköisesti tarpeeksi pieniä mahtumaan yhteen koneeseen, joten voit kouluttaa malleja scikit-learnin tai TensorFlow ’ n avulla. Kun yksi kone ei enää riitä, voit käyttää Spark MLlib tai hajautettu TensorFlow.

tulevaisuus

on jännittävää nähdä, kuinka paljon tietoinfrastruktuurin ekosysteemi on parantunut viimeisen vuosikymmenen aikana. Olemme tulleet pitkän matkan lapsenvahtina Hadoop klustereita ja voimistelu pakottaa meidän tietojenkäsittelyn logiikka karttoja ja vähentää hankala Java. Siihen aikaan datainfrastruktuurin rakentaminen tuntui siltä kuin yrittäisi rakentaa pilvenpiirtäjän leluvasaran avulla.

nykyään meillä on hämmästyttävän paljon erilaisia työkaluja. Spark on selvästi hallinnut jack-of-all-trades korvaa Hadoop MapReduce; samaa alkaa tapahtua TensorFlow ’ n kanssa koneoppimisalustana. Harvoja poikkeuksia lukuun ottamatta, sinun ei tarvitse rakentaa infrastruktuuria tai työkaluja tyhjästä talon sisällä näinä päivinä, eikä sinun luultavasti tarvitse hallita fyysisiä palvelimia. Pilvenpiirtäjä on jo olemassa, sinun tarvitsee vain valita maalivärit.

the serverless future-it ’ ll totally be like this

Looking ahead, I expect data infrastructure and tools to continue moving towards Complete serverless platforms-DataBricks just announced such an offering for Spark. Palvelimeton infrastruktuuri mahdollistaa huolien tyylikkään erottelun: pilvipalvelujen tarjoajat voivat olla huolissaan laitteistosta, devopsista ja työkaluista, jolloin insinöörit voivat keskittyä ongelmiin, jotka ovat ainutlaatuisia (ja linjassa) heidän liiketoiminnassaan. Tulevaisuus on sellainen, jossa ei ole laitteistovikoja, Eläintenhoitajan sekoiluja tai ongelmia LANKARESURSSIEN kanssa, ja se on todella siistiä.

Edit: linkkien lisääminen joihinkin aiempiin viesteihin, jotka kirjoitin Peukaloisen tietoinfrastruktuurista:

Vastaa

Sähköpostiosoitettasi ei julkaista.

lg