Бидэнд дата нуур хэрэгтэй юу? Мэдээллийн агуулахтай юу хийх вэ?

Энэ нийтлэл нь миний нийтлэлийн орчуулга юм. Дата нуурыг эхлүүлж байна, энэ нь нэлээд алдартай болсон нь энгийн байдлаасаа болж магадгүй юм. Тиймээс би үүнийг орос хэл дээр бичээд бага зэрэг нэмье гэж өгөгдлийн мэргэжилтэн биш энгийн хүнд өгөгдлийн агуулах (DW) гэж юу болох, дата нуур (Data Lake) гэж юу болох, тэд хэрхэн ажилладагийг ойлгуулахаар шийдлээ. хамт байх.

Яагаад би дата нуурын тухай бичихийг хүссэн юм бэ? Би 10 гаруй жилийн турш өгөгдөл, аналитик дээр ажиллаж байгаа бөгөөд одоо Бостон дахь Кембриж дэх Amazon Alexa AI-д том өгөгдөл дээр ажиллаж байгаа нь лавтай, гэхдээ би Ванкувер арал дээрх Виктория хотод амьдардаг бөгөөд Бостон, Сиэтл хотод байнга очдог. , Ванкуверт, заримдаа бүр Москвад ч би хурал дээр үг хэлдэг. Би ч бас хааяа бичдэг ч англиар голчлон бичдэг, биччихсэн байгаа зарим ном, Би Хойд Америкийн аналитик чиг хандлагыг хуваалцах хэрэгцээтэй байдаг бөгөөд би заримдаа бичдэг цахилгаан.

Би үргэлж өгөгдлийн агуулахтай ажиллаж байсан бөгөөд 2015 оноос хойш би Amazon Web Services-тэй нягт хамтран ажиллаж эхэлсэн бөгөөд ерөнхийдөө үүлэн аналитик (AWS, Azure, GCP) руу шилжсэн. Би 2007 оноос хойш аналитик шийдлүүдийн хувьслыг ажиглаж, тэр ч байтугай мэдээллийн агуулахын худалдагч Teradata-д ажиллаж, үүнийг Сбербанканд хэрэгжүүлсэн бөгөөд тэр үед Hadoop бүхий Big Data гарч ирэв. Хадгаламжийн эрин үе өнгөрч, одоо бүх зүйл Hadoop дээр байгаа гэж бүгд ярьж эхэлсэн бөгөөд дараа нь Дата нуурын талаар дахин ярьж эхлэв, одоо мэдээллийн агуулахын төгсгөл гарцаагүй ирлээ гэж. Гэвч аз болоход (магадгүй харамсалтай нь Hadoop-ийг суулгаж их мөнгө олсон зарим хүмүүсийн хувьд) мэдээллийн агуулах арилсангүй.

Энэ нийтлэлд бид дата нуур гэж юу болохыг авч үзэх болно. Энэ нийтлэл нь мэдээллийн агуулахын талаар бага эсвэл огт туршлагагүй хүмүүст зориулагдсан болно.

Зураг дээр Блед нуур, энэ бол миний хамгийн дуртай нууруудын нэг, гэхдээ би тэнд ганцхан удаа байсан ч би үүнийг амьдралынхаа туршид санаж байсан. Гэхдээ бид өөр төрлийн нуурын тухай ярих болно - дата нуур. Магадгүй та нарын олонхи нь энэ нэр томъёоны талаар нэгээс олон удаа сонссон байх, гэхдээ өөр нэг тодорхойлолт нь хэнд ч хор хөнөөл учруулахгүй.

Юуны өмнө, Дата нуурын хамгийн алдартай тодорхойлолтууд энд байна.

"Байгууллагын хэн ч дүн шинжилгээ хийх боломжтой бүх төрлийн түүхий мэдээллийн файлын хадгалалт" - Мартин Фаулер.

“Хэрэв та дата мартыг цэвэршүүлсэн, савлаж, хэрэглэхэд тохиромжтой савласан ус гэж бодож байгаа бол дата нуур нь байгалийн хэлбэрээрээ асар том усны нөөц юм. Хэрэглэгчид ээ, би өөртөө ус цуглуулж, гүнд шумбаж, судлах боломжтой" - Жеймс Диксон.

Өгөгдлийн нуур нь аналитик гэдгийг бид баттай мэдэж байгаа бөгөөд энэ нь бидэнд их хэмжээний өгөгдлийг анхны хэлбэрээр нь хадгалах боломжийг олгодог бөгөөд бидэнд шаардлагатай бөгөөд тохиромжтой мэдээлэлд хандах боломжтой болсон.

Би аливаа зүйлийг хялбарчлах дуртай, хэрэв би нарийн төвөгтэй нэр томъёог энгийн үгээр тайлбарлаж чадвал энэ нь хэрхэн ажилладаг, юунд хэрэгтэйг өөрөө ойлгодог. Нэгэн өдөр би iPhone-ийн зургийн цомогт эргэлдэж байтал энэ бол жинхэнэ мэдээллийн нуур, би чуулганд зориулсан слайд хүртэл хийсэн гэж санагдав.

Бүх зүйл маш энгийн. Бид утсан дээр зураг авдаг, зураг нь утсан дээр хадгалагдаж, iCloud (үүл файл хадгалах) дээр хадгалах боломжтой. Мөн утас нь зургийн мета өгөгдлийг цуглуулдаг: юу харагдаж байна, гео шошго, цаг. Үүний үр дүнд бид iPhone-ийн хэрэглэгчдэд ээлтэй интерфэйсийг ашиглан зургаа олох боломжтой бөгөөд бид индикаторуудыг хардаг, жишээлбэл, би гал гэсэн үгтэй зургийг хайхад би галын зурагтай 3 зураг олдог. Миний хувьд энэ нь маш хурдан бөгөөд ойлгомжтой ажилладаг Бизнесийн тагнуулын хэрэгсэлтэй адил юм.

Мэдээжийн хэрэг, бид аюулгүй байдлын (зөвшөөрөл ба баталгаажуулалтын) талаар мартаж болохгүй, эс тэгвээс бидний өгөгдөл олон нийтийн эзэмшилд амархан орох болно. Хөгжүүлэгчдийн хайхрамжгүй байдал, энгийн дүрмийг дагаж мөрдөөгүйн улмаас өгөгдөл нь олон нийтэд нээлттэй болсон томоохон корпорациуд, гарааны компаниудын тухай мэдээ маш их байдаг.

Ийм энгийн зураг ч гэсэн дата нуур гэж юу болох, түүний уламжлалт мэдээллийн агуулахаас ялгаа, үндсэн элементүүдийг төсөөлөхөд тусалдаг.

1. Өгөгдлийг ачаалж байна (Залгих) нь мэдээллийн нуурын гол бүрэлдэхүүн хэсэг юм. Өгөгдөл нь өгөгдлийн агуулахад хоёр аргаар орж болно - багц (завалтаар ачаалах) ба урсгал (өгөгдлийн урсгал).
2. Файл хадгалах (Хадгалах) нь Дата нуурын гол бүрэлдэхүүн хэсэг юм. Бидэнд хадгалах санг хялбархан өргөтгөх боломжтой, маш найдвартай, хямд өртөгтэй байх хэрэгтэй байсан. Жишээлбэл, AWS дээр энэ нь S3 юм.
3. Каталог ба хайлт (Каталог ба хайлт) - Бид өгөгдлийн намгаас зайлсхийхийн тулд (энэ нь бид бүх өгөгдлийг нэг овоолон хаях бөгөөд дараа нь түүнтэй ажиллах боломжгүй болно) өгөгдлийг ангилахын тулд мета өгөгдлийн давхарга үүсгэх хэрэгтэй. Ингэснээр хэрэглэгчид дүн шинжилгээ хийхэд шаардлагатай өгөгдлийг хялбархан олох боломжтой болно. Нэмж дурдахад та ElasticSearch гэх мэт нэмэлт хайлтын шийдлүүдийг ашиглаж болно. Хайлт нь хэрэглэгчдэд ээлтэй интерфэйсээр дамжуулан шаардлагатай өгөгдлийг олоход тусалдаг.
4. Боловсруулалт (Процесс) - энэ алхам нь өгөгдлийг боловсруулах, хувиргах үүрэгтэй. Бид өгөгдлийг хувиргах, бүтцийг нь өөрчлөх, цэвэрлэх гэх мэт олон зүйлийг хийх боломжтой.
5. Аюулгүй байдал (Аюулгүй байдал) - Шийдлийн хамгаалалтын загварт цаг зарцуулах нь чухал. Жишээлбэл, хадгалах, боловсруулах, ачаалах үед өгөгдлийг шифрлэх. Баталгаажуулалт, зөвшөөрлийн аргыг ашиглах нь чухал юм. Эцэст нь аудитын хэрэгсэл хэрэгтэй.

Практик талаас нь бид дата нуурыг гурван шинж чанараар тодорхойлж болно.

1. Юуг ч цуглуулж, хадгал — өгөгдлийн нуур нь ямар ч хугацааны турш боловсруулагдаагүй, боловсруулсан/цэвэрлэсэн өгөгдөл зэрэг бүх өгөгдлийг агуулдаг.
2. Гүн сканнердах — өгөгдлийн нуур нь хэрэглэгчдэд өгөгдөл судлах, дүн шинжилгээ хийх боломжийг олгодог.
3. Уян хатан хандалт — Өгөгдлийн нуур нь өөр өөр өгөгдөл, өөр хувилбаруудад уян хатан хандах боломжийг олгодог.

Одоо бид мэдээллийн агуулах ба дата нуурын ялгааны талаар ярьж болно. Хүмүүс ихэвчлэн асуудаг:

• Мэдээллийн агуулахын талаар юу хэлэх вэ?
• Бид мэдээллийн агуулахыг дата нуураар сольж байна уу эсвэл өргөжүүлж байна уу?
• Дата нуургүйгээр хийх боломжтой хэвээр байна уу?

Товчхондоо тодорхой хариулт алга. Энэ бүхэн тодорхой нөхцөл байдал, багийн ур чадвар, төсвөөс хамаарна. Жишээлбэл, өгөгдлийн агуулахыг Oracle руу AWS руу шилжүүлж, Amazon-ын охин компани Woot-ийн дата нуурыг бий болгох. Манай дата нуурын түүх: Woot.com AWS дээр сервергүй дата нуурыг хэрхэн барьсан.

Нөгөөтэйгүүр, худалдагч Цасан ширхгийн хэлснээр та дата нуурын талаар бодох шаардлагагүй болсон, учир нь тэдний дата платформ (2020 он хүртэл энэ нь мэдээллийн агуулах байсан) нь дата нуур болон мэдээллийн агуулахыг хослуулах боломжийг олгодог. Би Snowflake-тэй нэг их ажиллаж байгаагүй бөгөөд энэ нь үнэхээр үүнийг хийж чадах өвөрмөц бүтээгдэхүүн юм. Асуудлын үнэ нь өөр асуудал юм.

Дүгнэж хэлэхэд, миний хувийн бодлоор бидэнд тайлагнах мэдээллийн гол эх сурвалж болох мэдээллийн агуулах шаардлагатай хэвээр байгаа бөгөөд тохирохгүй зүйлийг бид дата нууранд хадгалдаг. Аналитикийн бүх үүрэг бол бизнест шийдвэр гаргахад хялбар хандах боломжийг олгох явдал юм. Бизнесийн хэрэглэгчид өгөгдлийн нуураас илүү өгөгдлийн агуулахтай илүү үр дүнтэй ажилладаг, жишээ нь Amazon-д Redshift (аналитик мэдээллийн агуулах) байдаг ба Redshift Spectrum/Athena (S3-д суурилсан мэдээллийн нуурын SQL интерфейс) байдаг. Hive/Presto). Бусад орчин үеийн аналитик мэдээллийн агуулахуудад мөн адил хамаарна.

Өгөгдлийн агуулахын ердийн архитектурыг харцгаая:

Энэ бол сонгодог шийдэл юм. Бид эх сурвалжийн системтэй, ETL/ELT ашиглан өгөгдлийг аналитик өгөгдлийн агуулах руу хуулж, Business Intelligence шийдэлд холбодог (миний дуртай Tableau бол таных яах вэ?).

Энэхүү шийдэл нь дараахь сул талуудтай.

• ETL/ELT үйл ажиллагаа нь цаг хугацаа, нөөц шаарддаг.
• Дүрмээр бол аналитик мэдээллийн агуулахад өгөгдөл хадгалах санах ой нь хямд биш юм (жишээлбэл, Redshift, BigQuery, Teradata), учир нь бид бүхэл бүтэн кластер худалдаж авах шаардлагатай болдог.
• Бизнесийн хэрэглэгчид цэвэрлэж, ихэвчлэн нэгтгэсэн өгөгдөлд хандах боломжтой бөгөөд түүхий өгөгдөлд хандах эрхгүй байдаг.

Мэдээжийн хэрэг, энэ бүхэн таны хэргээс хамаарна. Хэрэв танд өгөгдлийн агуулахтай холбоотой асуудал байхгүй бол танд дата нуур огт хэрэггүй болно. Гэхдээ орон зай, эрчим хүч, үнэ дутагдалтай холбоотой асуудал гол үүрэг гүйцэтгэдэг бол та дата нуурын сонголтыг авч үзэх боломжтой. Ийм учраас дата нуур маш их алдартай. Дата нуурын архитектурын жишээ энд байна:

Өгөгдлийн нуурын хандлагыг ашигласнаар бид өгөгдлийн нууранд (багц эсвэл урсгал) түүхий өгөгдлийг ачаалж, шаардлагатай бол өгөгдлийг боловсруулдаг. Өгөгдлийн нуур нь бизнесийн хэрэглэгчдэд өөрсдийн өгөгдлийн хувиргалтыг (ETL/ELT) үүсгэх эсвэл Business Intelligence шийдэл дэх өгөгдөлд дүн шинжилгээ хийх боломжийг олгодог (хэрэв шаардлагатай драйвер байгаа бол).

Аливаа аналитик шийдлийн зорилго нь бизнесийн хэрэглэгчдэд үйлчлэх явдал юм. Тиймээс бид үргэлж бизнесийн шаардлагын дагуу ажиллах ёстой. (Амазон дээр энэ бол ухарч ажиллах зарчмуудын нэг юм).

Өгөгдлийн агуулах болон дата нуурын аль алинтай нь хамтран ажиллахдаа бид хоёр шийдлийг харьцуулж болно.

Хамгийн гол дүгнэлт бол мэдээллийн агуулах нь мэдээллийн нууртай өрсөлдөхгүй, харин түүнийг нөхөж өгдөг. Гэхдээ таны асуудалд юу тохирохыг та өөрөө шийдэх болно. Үүнийг өөрөө туршиж үзээд зөв дүгнэлт гаргах нь үргэлж сонирхолтой байдаг.

Би дата нуурын хандлагыг ашиглаж эхэлсэн тохиолдлуудын нэгийг бас хэлмээр байна. Бүх зүйл маш энгийн, би ELT хэрэгсэл (бид Matillion ETL байсан) болон Amazon Redshift ашиглахыг оролдсон, миний шийдэл ажилласан боловч шаардлагад нийцээгүй.

Би вэб бүртгэлийг авч, тэдгээрийг хувиргаж, нэгтгэн 2 тохиолдолд өгөгдөл өгөх шаардлагатай болсон:

1. Маркетингийн баг SEO-д зориулсан ботын үйл ажиллагаанд дүн шинжилгээ хийхийг хүссэн
2. МТ нь вэбсайтын гүйцэтгэлийн хэмжүүрийг харахыг хүссэн

Маш энгийн, маш энгийн бүртгэлүүд. Энд нэг жишээ байна:

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

Нэг файл 1-4 мегабайт жинтэй байв.

Гэхдээ нэг бэрхшээл байсан. Бид дэлхий даяар 7 домэйнтэй байсан бөгөөд нэг өдрийн дотор 7000 мянган файл үүсгэсэн. Энэ нь илүү их хэмжээ биш, ердөө 50 гигабайт юм. Гэхдээ манай Redshift кластерын хэмжээ бага байсан (4 зангилаа). Нэг файлыг уламжлалт аргаар ачаалахад нэг минут орчим зарцуулсан. Асуудлыг шууд шийдээгүй гэсэн үг. Би дата нуурын хандлагыг ашиглахаар шийдсэн үед ийм байсан. Шийдэл нь иймэрхүү харагдаж байв.

Энэ нь маш энгийн (үүл дээр ажиллахын давуу тал нь энгийн байдал гэдгийг тэмдэглэхийг хүсч байна). Би хэрэглэсэн:

• Тооцооллын хүчин чадалд зориулсан AWS Elastic Map Reduce (Hadoop).
• AWS S3 нь өгөгдлийг шифрлэх, хандалтыг хязгаарлах чадвартай файлын хадгалалт юм
• Spark нь InMemory тооцоолох хүчин чадал болон логик болон өгөгдлийг хувиргахад зориулсан PySpark
• Spark-ийн үр дүнд паркет
• AWS Glue Crawler нь шинэ өгөгдөл болон хуваалтуудын талаархи мета өгөгдөл цуглуулагч юм
• Redshift Spectrum нь одоо байгаа Redshift хэрэглэгчдэд зориулсан мэдээллийн нуурын SQL интерфейс юм

Хамгийн жижиг EMR+Spark кластер нь 30 минутын дотор файлын стекийг бүхэлд нь боловсруулсан. AWS-ийн бусад тохиолдлууд байдаг, ялангуяа Alexa-тай холбоотой олон тооны өгөгдөл байдаг.

Саяхан би дата нуурын нэг сул тал бол GDPR гэдгийг олж мэдсэн. Асуудал нь үйлчлүүлэгч үүнийг устгахыг хүсэх үед өгөгдөл нь аль нэг файлд байгаа тул бид мэдээллийн санд байгаа шиг Data Manipulation Language болон DELETE үйлдлийг ашиглаж чадахгүй байна.

Энэ нийтлэл нь өгөгдлийн агуулах ба дата нуурын ялгааг тодруулсан гэж найдаж байна. Хэрэв та сонирхож байсан бол би өөрийнхөө нийтлэл эсвэл уншсан мэргэжлийн хүмүүсийн нийтлэлийг орчуулах боломжтой. Мөн миний хамтран ажилладаг шийдлүүд болон тэдгээрийн архитектурын талаар ярина уу.

Эх сурвалж: www.habr.com