Þurfum við gagnavatn? Hvað á að gera við gagnageymsluna?

Þessi grein er þýðing á grein minni á miðli - Að byrja með Data Lake, sem reyndist nokkuð vinsælt, líklega vegna einfaldleikans. Þess vegna ákvað ég að skrifa það á rússnesku og bæta aðeins við til að gera venjulegum einstaklingi sem er ekki gagnasérfræðingur ljóst hvað gagnavöruhús (DW) er og hvað gagnavatn er (Data Lake) og hvernig þeir ná saman.

Hvers vegna vildi ég skrifa um gagnavatnið? Ég hef unnið með gögn og greiningar í yfir 10 ár, og núna er ég örugglega að vinna með stór gögn hjá Amazon Alexa AI í Cambridge, sem er í Boston, þó ég búi í Victoria á Vancouver Island og heimsæki oft Boston, Seattle , og Í Vancouver, og stundum jafnvel í Moskvu, tala ég á ráðstefnum. Ég skrifa líka af og til en ég skrifa aðallega á ensku og hef þegar skrifað nokkrar bækur, Ég þarf líka að deila greiningarstraumum frá Norður-Ameríku og ég skrifa stundum inn símskeyti.

Ég hef alltaf unnið með gagnavöruhús og síðan 2015 byrjaði ég að vinna náið með Amazon Web Services og fór almennt yfir í skýjagreiningu (AWS, Azure, GCP). Ég hef fylgst með þróun greiningarlausna síðan 2007 og jafnvel unnið fyrir gagnavöruhúsasöluaðilann Teradata og innleitt það hjá Sberbank, og það var þegar Big Data með Hadoop birtist. Allir fóru að segja að tími geymslunnar væri liðinn og nú væri allt á Hadoop, og svo fóru þeir að tala um Data Lake, aftur, að nú væri endirinn á gagnageymslunni örugglega kominn. En sem betur fer (kannski því miður fyrir suma sem græddu mikla peninga á að setja upp Hadoop), hvarf gagnageymsluhúsið ekki.

Í þessari grein munum við skoða hvað gagnavatn er. Þessi grein er ætluð fólki sem hefur litla sem enga reynslu af vöruhúsum gagna.

Þurfum við gagnavatn? Hvað á að gera við gagnageymsluna?

Á myndinni er Lake Bled, þetta er eitt af mínum uppáhalds vötnum, þó ég hafi verið þar aðeins einu sinni, mundi eftir því alla ævi. En við munum tala um aðra tegund af stöðuvatni - gagnavatni. Kannski hafa mörg ykkar þegar heyrt um þetta hugtak oftar en einu sinni, en ein skilgreining í viðbót mun ekki skaða neinn.

Í fyrsta lagi eru hér vinsælustu skilgreiningarnar á Data Lake:

„skjalageymsla fyrir allar gerðir af hráum gögnum sem eru tiltæk til greiningar fyrir alla innan stofnunarinnar“ - Martin Fowler.

„Ef þú heldur að gagnamarkaður sé flaska af vatni - hreinsuð, pakkað og pakkað til þægilegrar neyslu, þá er gagnavatn risastórt vatnsgeymir í náttúrulegu formi. Notendur, ég get safnað vatni fyrir sjálfan mig, kafað djúpt, kannað“ - James Dixon.

Nú vitum við fyrir víst að gagnavatn snýst um greiningar, það gerir okkur kleift að geyma mikið magn af gögnum í upprunalegri mynd og við höfum nauðsynlegan og þægilegan aðgang að gögnunum.

Mér finnst oft gaman að einfalda hlutina, ef ég get útskýrt flókið hugtak með einföldum orðum, þá skil ég sjálfur hvernig það virkar og til hvers það þarf. Einn daginn var ég að pæla í iPhone myndagalleríinu og það rann upp fyrir mér, þetta er alvöru gagnavatn, ég gerði meira að segja glæru fyrir ráðstefnur:

Þurfum við gagnavatn? Hvað á að gera við gagnageymsluna?

Allt er mjög einfalt. Við tökum mynd í símanum, myndin er vistuð í símanum og hægt er að vista hana í iCloud (skýjaskráageymslu). Síminn safnar einnig myndlýsigögnum: hvað er sýnt, landfræðilegt merki, tími. Fyrir vikið getum við notað notendavænt viðmót iPhone til að finna myndina okkar og sjáum jafnvel vísbendingar, til dæmis þegar ég leita að myndum með orðinu eldur finn ég 3 myndir með mynd af eldi. Fyrir mér er þetta bara eins og Business Intelligence tól sem virkar mjög hratt og skýrt.

Og auðvitað megum við ekki gleyma öryggi (heimild og auðkenning), annars geta gögnin okkar auðveldlega endað í almenningseign. Það eru margar fréttir um stór fyrirtæki og sprotafyrirtæki þar sem gögnin urðu aðgengileg almenningi vegna vanrækslu þróunaraðila og vanrækslu á að fylgja einföldum reglum.

Jafnvel svo einföld mynd hjálpar okkur að ímynda okkur hvað gagnavatn er, muninn á því frá hefðbundnu gagnageymsluhúsi og helstu þætti þess:

  1. Hleður gögnum (Inntaka) er lykilþáttur gagnavatnsins. Gögn geta farið inn í gagnageymsluna á tvo vegu - lotu (hleðsla með millibili) og streymi (gagnaflæði).
  2. Skráargeymsla (Geymsla) er aðalhluti gagnavatnsins. Við þurftum að geymslan væri auðstæranleg, afar áreiðanleg og ódýr. Til dæmis, í AWS er ​​það S3.
  3. Vörulisti og leit (Vörulisti og leit) - til þess að við getum forðast gagnamýrina (þetta er þegar við hentum öllum gögnum í einn bunka og þá er ómögulegt að vinna með þau), þurfum við að búa til lýsigagnalag til að flokka gögnin þannig að notendur geti auðveldlega fundið gögnin sem þeir þurfa til greiningar. Að auki geturðu notað fleiri leitarlausnir eins og ElasticSearch. Leit hjálpar notandanum að finna nauðsynleg gögn í gegnum notendavænt viðmót.
  4. Vinnslu (Process) - þetta skref er ábyrgt fyrir vinnslu og umbreytingu gagna. Við getum umbreytt gögnum, breytt uppbyggingu þeirra, hreinsað þau og margt fleira.
  5. öryggi (Öryggi) - Það er mikilvægt að eyða tíma í öryggishönnun lausnarinnar. Til dæmis dulkóðun gagna við geymslu, vinnslu og hleðslu. Mikilvægt er að nota auðkenningar- og heimildaraðferðir. Að lokum þarf endurskoðunartæki.

Frá hagnýtu sjónarhorni getum við einkennt gagnavatn með þremur eiginleikum:

  1. Safnaðu og geymdu hvað sem er — Gagnavatnið inniheldur öll gögn, bæði óunnin óunnin gögn fyrir hvaða tíma sem er og unnin/hreinsuð gögn.
  2. Djúp skönnun - Gagnavatn gerir notendum kleift að kanna og greina gögn.
  3. Sveigjanlegur aðgangur — Gagnavatnið veitir sveigjanlegan aðgang fyrir mismunandi gögn og mismunandi aðstæður.

Nú getum við talað um muninn á gagnavöruhúsi og gagnavatni. Venjulega spyr fólk:

  • Hvað með gagnageymsluna?
  • Erum við að skipta út gagnageymslunni fyrir gagnavatn eða erum við að stækka það?
  • Er enn hægt að vera án gagnavatns?

Í stuttu máli, það er ekkert skýrt svar. Það veltur allt á sérstökum aðstæðum, færni liðsins og fjárhagsáætlun. Til dæmis að flytja gagnavöruhús til Oracle yfir í AWS og búa til gagnavatn af Amazon dótturfyrirtæki - Woot - Gagnavatnssaga okkar: Hvernig Woot.com byggði netþjónalaust gagnavatn á AWS.

Á hinn bóginn segir söluaðilinn Snowflake að þú þurfir ekki lengur að hugsa um gagnavatn þar sem gagnapallur þeirra (til 2020 var það gagnavöruhús) gerir þér kleift að sameina bæði gagnavatn og gagnavöruhús. Ég hef ekki unnið mikið með Snowflake, og það er sannarlega einstök vara sem getur gert þetta. Annað mál er verðið á útgáfunni.

Að lokum er persónuleg skoðun mín sú að við þurfum enn gagnageymslu sem aðaluppsprettu gagna fyrir skýrslugerðina okkar, og það sem passar ekki geymum við í gagnavatni. Allt hlutverk greiningar er að veita greiðan aðgang fyrir fyrirtæki til að taka ákvarðanir. Hvað sem menn kunna að segja, þá vinna viðskiptanotendur skilvirkari með gagnavöruhús en gagnavatni, til dæmis í Amazon - það er Redshift (greiningargagnavöruhús) og það er Redshift Spectrum/Athena (SQL tengi fyrir gagnavatn í S3 byggt á Hive/Presto). Sama á við um önnur nútíma greiningargagnageymslur.

Við skulum skoða dæmigerðan gagnavöruhúsaarkitektúr:

Þurfum við gagnavatn? Hvað á að gera við gagnageymsluna?

Þetta er klassísk lausn. Við erum með frumkerfi, með því að nota ETL/ELT afritum við gögn inn í greiningargagnageymslu og tengjum þau við viðskiptagreindarlausn (uppáhaldið mitt er Tableau, hvað með þitt?).

Þessi lausn hefur eftirfarandi ókosti:

  • ETL/ELT starfsemi krefst tíma og fjármagns.
  • Að jafnaði er minni til að geyma gögn í greiningargagnageymslu ekki ódýrt (til dæmis Redshift, BigQuery, Teradata), þar sem við þurfum að kaupa heilan klasa.
  • Viðskiptanotendur hafa aðgang að hreinsuðum og oft samanteknum gögnum og hafa ekki aðgang að hráum gögnum.

Það fer auðvitað allt eftir þínu tilviki. Ef þú átt ekki í vandræðum með gagnageymsluna þína, þá þarftu alls ekki gagnavatn. En þegar vandamál koma upp með plássleysi, orku eða verð gegnir lykilhlutverki, þá geturðu íhugað möguleikann á gagnavatni. Þess vegna er gagnavatnið mjög vinsælt. Hér er dæmi um gagnavatnsarkitektúr:
Þurfum við gagnavatn? Hvað á að gera við gagnageymsluna?
Með því að nota gagnavatnsaðferðina hleðum við hrágögnum í gagnavatnið okkar (lotu eða streymi), síðan vinnum við úr gögnunum eftir þörfum. Gagnavatnið gerir viðskiptanotendum kleift að búa til eigin gagnabreytingar (ETL/ELT) eða greina gögn í viðskiptagreindarlausnum (ef nauðsynlegur drifbúnaður er til staðar).

Markmið hvers kyns greiningarlausna er að þjóna viðskiptanotendum. Þess vegna verðum við alltaf að vinna samkvæmt viðskiptakröfum. (Hjá Amazon er þetta ein af meginreglunum - að vinna afturábak).

Með því að vinna bæði með gagnageymslu og gagnavatni getum við borið saman báðar lausnirnar:

Þurfum við gagnavatn? Hvað á að gera við gagnageymsluna?

Meginniðurstaðan sem hægt er að draga er sú að gagnavöruhúsið keppir ekki við gagnavatnið heldur bætir það við. En það er undir þér komið að ákveða hvað er rétt fyrir þínu tilviki. Það er alltaf áhugavert að prófa það sjálfur og draga réttar ályktanir.

Mig langar líka að segja þér eitt af tilfellunum þegar ég byrjaði að nota gagnavatnsaðferðina. Allt er frekar léttvægt, ég reyndi að nota ELT tól (við vorum með Matillion ETL) og Amazon Redshift, lausnin mín virkaði, en uppfyllti ekki kröfurnar.

Ég þurfti að taka vefskrár, umbreyta þeim og safna þeim saman til að veita gögn fyrir 2 tilvik:

  1. Markaðsteymið vildi greina virkni vélmenna fyrir SEO
  2. ÞAÐ vildi skoða árangursmælingar á vefsíðum

Mjög einföld, mjög einföld logs. Hér er dæmi:

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" "-" "-"

Ein skrá vó 1-4 megabæti.

En það var einn vandi. Við vorum með 7 lén um allan heim og 7000 þúsund skrár voru búnar til á einum degi. Þetta er ekki mikið meira magn, aðeins 50 gígabæt. En stærð rauðviksþyrpingarinnar okkar var líka lítil (4 hnútar). Það tók um eina mínútu að hlaða einni skrá á hefðbundinn hátt. Það er að segja að vandamálið var ekki leyst beint. Og þetta var raunin þegar ég ákvað að nota gagnavatnsaðferðina. Lausnin leit einhvern veginn svona út:

Þurfum við gagnavatn? Hvað á að gera við gagnageymsluna?

Það er frekar einfalt (ég vil taka fram að kosturinn við að vinna í skýinu er einfaldleiki). Ég notaði:

  • AWS Elastic Map Reduce (Hadoop) fyrir Compute Power
  • AWS S3 sem skráageymsla með getu til að dulkóða gögn og takmarka aðgang
  • Spark sem InMemory tölvukraftur og PySpark fyrir rökfræði og gagnaumbreytingu
  • Parket sem afleiðing af Spark
  • AWS Glue Crawler sem lýsigagnasafnari um ný gögn og skipting
  • Redshift Spectrum sem SQL tengi við gagnavatnið fyrir núverandi Redshift notendur

Minnsti EMR+Spark þyrpingin vann allan bunkann af skrám á 30 mínútum. Það eru önnur tilvik fyrir AWS, sérstaklega mörg tengd Alexa, þar sem er mikið af gögnum.

Nýlega lærði ég að einn af ókostum gagnavatns er GDPR. Vandamálið er þegar viðskiptavinurinn biður um að eyða því og gögnin eru í einni af skránum, getum við ekki notað Data Manipulation Language og DELETE aðgerð eins og í gagnagrunni.

Ég vona að þessi grein hafi skýrt muninn á gagnavöruhúsi og gagnavatni. Ef þú hefur áhuga get ég þýtt fleiri greinar mínar eða greinar sérfræðinga sem ég las. Og segja líka frá þeim lausnum sem ég vinn með og arkitektúr þeirra.

Heimild: www.habr.com

Bæta við athugasemd