Bu məqalə mənim orta məqaləmin tərcüməsidir - , yəqin ki, sadəliyinə görə olduqca populyar oldu. Buna görə də, mən bunu rus dilində yazmaq qərarına gəldim və məlumat mütəxəssisi olmayan adi bir insana məlumat anbarının (DW) nə olduğunu və məlumat gölünün (Data Lake) nə olduğunu və onların necə olduğunu başa düşmək üçün bir az əlavə etmək qərarına gəldim. birlikdə olun.
Data gölü haqqında niyə yazmaq istədim? Mən 10 ildən artıqdır ki, məlumat və analitika ilə işləyirəm və indi mən mütləq Bostonda olan Kembricdəki Amazon Alexa AI-də böyük data ilə işləyirəm, baxmayaraq ki, mən Vankuver adasında Viktoriyada yaşayıram və tez-tez Boston, Seattle oluram. , və Vankuverdə, bəzən hətta Moskvada konfranslarda çıxış edirəm. Mən də vaxtaşırı yazıram, amma əsasən ingilis dilində yazıram və artıq yazmışam , Şimali Amerikadan analitik tendensiyaları paylaşmağa da ehtiyacım var və bəzən yazıram .
Mən həmişə məlumat anbarları ilə işləmişəm və 2015-ci ildən Amazon Web Services ilə yaxından işləməyə başladım və ümumiyyətlə bulud analitikasına (AWS, Azure, GCP) keçdim. Mən 2007-ci ildən bəri analitik həllərin təkamülünü müşahidə etmişəm və hətta məlumat anbarı satıcısı Teradata üçün işləmişəm və onu Sberbank-da tətbiq etmişəm və o zaman Hadoop ilə Big Data peyda oldu. Hər kəs saxlama dövrünün keçdiyini və indi hər şeyin Hadoop-da olduğunu söyləməyə başladı və daha sonra Data Lake haqqında danışmağa başladılar, indi məlumat anbarının sonu mütləq gəldi. Ancaq xoşbəxtlikdən (bəlkə təəssüf ki, Hadoop-u qurmaqla çox pul qazanan bəziləri üçün) məlumat anbarı getmədi.
Bu yazıda data gölünün nə olduğuna baxacağıq. Bu məqalə məlumat anbarları ilə az və ya heç təcrübəsi olmayan insanlar üçün nəzərdə tutulub.
Şəkildə Bled gölüdür, bu mənim ən çox sevdiyim göllərdən biridir, cəmi bir dəfə orda olsam da, ömrümün sonuna qədər xatırladım. Amma biz başqa bir göl növündən - data gölündən danışacağıq. Yəqin ki, bir çoxunuz bu termin haqqında bir dəfədən çox eşitmisiniz, amma daha bir tərif heç kimə zərər verməyəcək.
Əvvəla, Data Gölü üçün ən məşhur təriflər bunlardır:
"Təşkilatdakı hər kəs tərəfindən təhlil edilə bilən bütün növ xam məlumatların saxlanması" - Martin Fowler.
“Əgər siz data martın rahat istehlak üçün təmizlənmiş, qablaşdırılmış və qablaşdırılmış bir şüşə su olduğunu düşünürsünüzsə, o zaman data gölü təbii formada nəhəng su anbarıdır. İstifadəçilər, mən özüm üçün su toplaya, dərinə dala, kəşf edə bilərəm” - James Dixon.
İndi biz dəqiq bilirik ki, data gölü analitika ilə bağlıdır, o, bizə böyük həcmdə verilənləri orijinal formada saxlamağa imkan verir və məlumatlara lazımi və rahat çıxışımız var.
Mən çox vaxt hər şeyi sadələşdirməyi xoşlayıram, əgər mürəkkəb termini sadə sözlərlə izah edə bilsəm, o zaman onun necə işlədiyini və nə üçün lazım olduğunu özüm başa düşürəm. Bir gün iPhone foto qalereyasında gəzirdim və ağlıma gəldi ki, bu, əsl məlumat gölüdür, hətta konfranslar üçün slayd da hazırladım:
Hər şey çox sadədir. Telefonda şəkil çəkirik, şəkil telefonda saxlanılır və iCloud-da (bulud fayl yaddaşı) saxlanıla bilər. Telefon həmçinin foto metadata toplayır: göstərilənlər, coğrafi etiket, vaxt. Nəticədə biz öz şəklimizi tapmaq üçün iPhone-un istifadəçi dostu interfeysindən istifadə edə bilirik və hətta göstəriciləri də görürük, məsələn, yanğın sözü olan fotoşəkilləri axtaranda 3 ədəd yanğın təsviri olan fotoşəkillər tapıram. Mənim üçün bu, çox tez və aydın şəkildə işləyən Biznes Kəşfiyyatı vasitəsi kimidir.
Və əlbəttə ki, təhlükəsizlik (avtorizasiya və autentifikasiya) haqqında unutmamalıyıq, əks halda məlumatlarımız asanlıqla ictimai sahəyə düşə bilər. Tərtibatçıların səhlənkarlığı və sadə qaydalara əməl etməməsi səbəbindən məlumatları ictimaiyyətə açıq olan böyük korporasiyalar və startaplar haqqında çoxlu xəbərlər var.
Hətta belə sadə bir şəkil bizə məlumat gölünün nə olduğunu, onun ənənəvi məlumat anbarından fərqlərini və onun əsas elementlərini təsəvvür etməyə kömək edir:
- Data Yüklənir (Yəni qəbul) məlumat gölünün əsas komponentidir. Məlumatlar verilənlər anbarına iki yolla daxil ola bilər - toplu (fasilələrlə yükləmə) və axın (məlumat axını).
- Fayl saxlama (Storage) Data Lake-in əsas komponentidir. Bizə yaddaşın asanlıqla genişləndirilə bilən, son dərəcə etibarlı və aşağı qiymətli olması lazım idi. Məsələn, AWS-də bu S3-dür.
- Kataloq və Axtarış (Kataloq və Axtarış) - Məlumat bataqlığından qaçmaq üçün (bu, biz bütün məlumatları bir yığına tökdükdən sonra onunla işləmək mümkün deyil), məlumatları təsnif etmək üçün metadata qatını yaratmalıyıq. istifadəçilər təhlil üçün lazım olan məlumatları asanlıqla tapa bilsinlər. Bundan əlavə, ElasticSearch kimi əlavə axtarış həllərindən istifadə edə bilərsiniz. Axtarış istifadəçiyə rahat interfeys vasitəsilə tələb olunan məlumatları tapmağa kömək edir.
- Emal (Proses) - bu addım məlumatların işlənməsi və dəyişdirilməsi üçün cavabdehdir. Biz məlumatları çevirə, strukturunu dəyişdirə, təmizləyə və daha çox şey edə bilərik.
- təhlükəsizlik (Təhlükəsizlik) - Həllin təhlükəsizlik dizaynına vaxt sərf etmək vacibdir. Məsələn, saxlama, emal və yükləmə zamanı məlumatların şifrələnməsi. Doğrulama və avtorizasiya üsullarından istifadə etmək vacibdir. Nəhayət, audit alətinə ehtiyac var.
Praktik nöqteyi-nəzərdən məlumat gölünü üç atributla xarakterizə edə bilərik:
- Hər şeyi toplayın və saxlayın — verilənlər gölü bütün məlumatları, həm hər hansı bir müddət üçün işlənməmiş, həm də işlənmiş/təmizlənmiş məlumatları ehtiva edir.
- Dərin Skan — data gölü istifadəçilərə məlumatları araşdırmaq və təhlil etmək imkanı verir.
- Çevik giriş — Məlumat gölü müxtəlif məlumatlar və müxtəlif ssenarilər üçün çevik giriş təmin edir.
İndi məlumat anbarı ilə məlumat gölü arasındakı fərq haqqında danışa bilərik. Adətən insanlar soruşur:
- Məlumat anbarı haqqında nə demək olar?
- Məlumat anbarını verilənlər gölü ilə əvəz edirik, yoxsa onu genişləndiririk?
- Məlumat gölü olmadan hələ də etmək mümkündürmü?
Bir sözlə, dəqiq cavab yoxdur. Hamısı konkret vəziyyətdən, komandanın bacarıqlarından və büdcədən asılıdır. Məsələn, məlumat anbarını Oracle-dan AWS-ə köçürmək və Amazon-un törəmə şirkəti - Woot tərəfindən məlumat gölünün yaradılması. .
Digər tərəfdən, satıcı Snowflake deyir ki, artıq məlumat gölü haqqında düşünməyə ehtiyac yoxdur, çünki onların məlumat platforması (2020-ci ilə qədər məlumat anbarı idi) həm məlumat gölünü, həm də məlumat anbarını birləşdirməyə imkan verir. Mən Snowflake ilə çox işləməmişəm və bu, həqiqətən də bunu edə bilən unikal məhsuldur. Məsələnin qiyməti başqa məsələdir.
Yekun olaraq, mənim şəxsi fikrim budur ki, hesabatımız üçün əsas məlumat mənbəyi kimi hələ də məlumat anbarına ehtiyacımız var və nə uyğun gəlmirsə, biz data gölündə saxlayırıq. Analitikanın bütün rolu qərarlar qəbul etmək üçün biznesin asan çıxışını təmin etməkdir. Kim nə deyə bilər, biznes istifadəçiləri məlumat gölündən daha səmərəli şəkildə məlumat anbarı ilə işləyirlər, məsələn Amazonda - Redshift (analitik məlumat anbarı) və Redshift Spectrum/Athena (S3-də verilənlər gölü üçün SQL interfeysi) mövcuddur. Hive/Presto). Eyni şey digər müasir analitik məlumat anbarlarına da aiddir.
Tipik bir məlumat anbarı arxitekturasına baxaq:
Bu klassik bir həlldir. Mənbə sistemlərimiz var, ETL/ELT-dən istifadə edərək biz məlumatları analitik məlumat anbarına köçürür və onu Biznes Kəşfiyyatı həllinə qoşuruq (mənim sevimlim Tableau, sizinki necə?).
Bu həllin aşağıdakı mənfi cəhətləri var:
- ETL/ELT əməliyyatları vaxt və resurslar tələb edir.
- Bir qayda olaraq, analitik məlumat anbarında məlumatların saxlanması üçün yaddaş ucuz deyil (məsələn, Redshift, BigQuery, Teradata), çünki biz bütün klasteri almalıyıq.
- Biznes istifadəçilərinin təmizlənmiş və tez-tez toplanmış məlumatlara çıxışı var və xam məlumatlara çıxışı yoxdur.
Əlbəttə ki, hər şey sizin vəziyyətinizdən asılıdır. Əgər məlumat anbarınızla bağlı probleminiz yoxdursa, o zaman məlumat gölünə ümumiyyətlə ehtiyacınız yoxdur. Ancaq yer, güc və ya qiymət çatışmazlığı ilə bağlı problemlər yarandıqda, əsas rol oynadıqda, məlumat gölünün seçimini nəzərdən keçirə bilərsiniz. Bu səbəbdən data gölü çox populyardır. Data gölü arxitekturasına bir nümunə:
Data lake yanaşmasından istifadə edərək, biz xam məlumatları data gölümüzə yükləyirik (toplu və ya axın), sonra lazım olduqda məlumatları emal edirik. Məlumat gölü biznes istifadəçilərinə öz məlumat transformasiyalarını (ETL/ELT) yaratmağa və ya Business Intelligence həllərində məlumatları təhlil etməyə imkan verir (lazımi sürücü varsa).
İstənilən analitik həllin məqsədi biznes istifadəçilərinə xidmət göstərməkdir. Ona görə də biz həmişə biznes tələblərinə uyğun işləməliyik. (Amazonda bu prinsiplərdən biridir - geriyə doğru işləmək).
Həm məlumat anbarı, həm də məlumat gölü ilə işləyərək hər iki həlli müqayisə edə bilərik:
Çıxarılan əsas nəticə ondan ibarətdir ki, verilənlər anbarı verilənlər gölü ilə rəqabət aparmır, əksinə onu tamamlayır. Ancaq işiniz üçün nəyin doğru olduğuna qərar vermək sizin ixtiyarınızdadır. Bunu özünüz sınamaq və düzgün nəticələr çıxarmaq həmişə maraqlıdır.
Data lake yanaşmasından istifadə etməyə başladığım hallardan birini də sizə danışmaq istərdim. Hər şey olduqca mənasızdır, mən ELT alətindən (bizdə Matillion ETL var idi) və Amazon Redshift-dən istifadə etməyə çalışdım, həllim işlədi, lakin tələblərə uyğun gəlmədi.
Mən veb qeydləri götürməli, onları çevirməli və 2 hal üçün məlumat təmin etmək üçün toplamalı idim:
- Marketinq qrupu SEO üçün bot fəaliyyətini təhlil etmək istədi
- İT veb saytın performans göstəricilərinə baxmaq istədi
Çox sadə, çox sadə loglar. Budur bir nümunə:
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" "-" "-"Bir faylın çəkisi 1-4 meqabayt idi.
Ancaq bir çətinlik var idi. Dünyada 7 domenimiz var idi və bir gündə 7000 min fayl yaradıldı. Bu, daha çox həcm deyil, cəmi 50 giqabaytdır. Ancaq Redshift klasterimizin ölçüsü də kiçik idi (4 qovşaq). Bir faylın ənənəvi şəkildə yüklənməsi təxminən bir dəqiqə çəkdi. Yəni problem üz-üzə həll olunmayıb. Mən data gölü yanaşmasından istifadə etmək qərarına gələndə belə oldu. Həll belə görünürdü:
Bu olduqca sadədir (qeyd etmək istəyirəm ki, buludda işləməyin üstünlüyü sadəlikdir). Mən istifadə etdim:
- Hesablama Gücü üçün AWS Elastic Map Reduce (Hadoop).
- AWS S3 verilənləri şifrələmək və girişi məhdudlaşdırmaq imkanı ilə fayl yaddaşı kimi
- Məntiq və məlumatların çevrilməsi üçün InMemory hesablama gücü və PySpark kimi Spark
- Spark nəticəsində parket
- AWS Glue Crawler yeni məlumatlar və bölmələr haqqında metadata toplayıcısı kimi
- Redshift Spectrum, mövcud Redshift istifadəçiləri üçün məlumat gölünə SQL interfeysi kimi
Ən kiçik EMR+Spark klasteri bütün fayl yığınını 30 dəqiqə ərzində emal etdi. AWS üçün başqa hallar var, xüsusən də çoxlu məlumatın olduğu Alexa ilə əlaqəli bir çoxu.
Bu yaxınlarda bir məlumat gölünün çatışmazlıqlarından birinin GDPR olduğunu öyrəndim. Problem ondadır ki, müştəri onu silməyi xahiş etdikdə və verilənlər fayllardan birindədir, biz verilənlər bazasındakı kimi Data Manipulation Language və DELETE əməliyyatından istifadə edə bilmirik.
Ümid edirəm ki, bu məqalə məlumat anbarı ilə məlumat gölü arasındakı fərqi aydınlaşdırdı. Əgər maraqlanırsınızsa, daha çox məqalələrimi və ya oxuduğum peşəkarların məqalələrini tərcümə edə bilərəm. Həm də işlədiyim həllər və onların arxitekturası haqqında danışın.
Mənbə: www.habr.com