ایا موږ د ډیټا لیک ته اړتیا لرو؟ د معلوماتو ګودام سره څه وکړي؟

دا مقاله په منځني ډول زما د مقالې ژباړه ده - د ډیټا لیک سره پیل کول، کوم چې خورا مشهور و ، شاید د دې سادگي له امله. له همدې امله ، ما پریکړه وکړه چې دا په روسی ژبه ولیکئ او یو څه اضافه کړم ترڅو یو عادي کس ته دا روښانه کړم چې د ډیټا متخصص نه دی د ډیټا ګودام (DW) څه شی دی ، او د ډیټا لیک څه شی دی (ډاټا لیک) ، او دوی څنګه. سره یوځای شئ

ولې ما غوښتل د ډیټا لیک په اړه ولیکم؟ زه د 10 کلونو لپاره د معلوماتو او تحلیلونو سره کار کوم، او اوس زه یقینا په کیمبرج کې د ایمیزون الیکسا AI کې د لوی ډیټا سره کار کوم، کوم چې په بوسټن کې دی، که څه هم زه د وینکوور ټاپو په ویکټوریا کې ژوند کوم او ډیری وختونه د بوسټن، سیټل څخه لیدنه کوم. ، او په وینکوور کې، او ځینې وختونه حتی په مسکو کې، زه په کنفرانسونو کې خبرې کوم. زه هم وخت په وخت لیکم، مګر زه په انګلیسي ژبه لیکم، او ما مخکې هم لیکلي دي ځینې ​​کتابونه، زه د شمالي امریکا څخه د تحلیلي رجحاناتو شریکولو ته هم اړتیا لرم ، او زه ځینې وختونه لیکم تلیگرامونه.

ما تل د معلوماتو ګودامونو سره کار کړی، او له 2015 راهیسې ما د ایمیزون ویب خدماتو سره نږدې کار پیل کړ، او عموما د بادل تحلیلونو (AWS، Azure، GCP) ته بدل شوم. ما د 2007 راهیسې د تحلیلي حلونو تکامل لیدلی او حتی د ډیټا ګودام پلورونکي Teradata لپاره یې کار کړی او په سبربینک کې یې پلي کړی ، او دا هغه وخت دی چې د هډوپ سره لوی ډیټا راڅرګند شو. ټولو ویل چې د ذخیرې دورې تېرې شوې او اوس هر څه په هډوپ کې دي، بیا یې د ډیټا لیک په اړه خبرې پیل کړې، چې اوس د ډیټا ګدام پای ته رسېدلی دی. مګر خوشبختانه (شاید له بده مرغه د ځینو لپاره چې د هډوپ تنظیم کولو لپاره یې ډیرې پیسې ګټلې)، د معلوماتو ګودام له منځه لاړ نه شو.

پدې مقاله کې به موږ وګورو چې د ډیټا لیک څه شی دی. دا مقاله د هغو خلکو لپاره ده چې د معلوماتو ګودامونو سره لږ یا هیڅ تجربه نلري.

په انځور کې د بلډ جهيل دی، دا زما د خوښې جهيلونو څخه دی، که څه هم زه هلته یوازې یو ځل وم، ما دا زما د پاتې ژوند لپاره یاد کړ. مګر موږ به د بل ډول جهيل په اړه وغږیږو - د معلوماتو جهيل. شاید ستاسو څخه ډیری لا دمخه د دې اصطلاح په اړه له یو ځل څخه ډیر اوریدلي وي، مګر یو بل تعریف به هیچا ته زیان ونه رسوي.

تر ټولو لومړی، دلته د ډیټا لیک خورا مشهور تعریفونه دي:

"د هر ډول خام ډیټا فایل ذخیره کول چې په سازمان کې د هرچا لخوا د تحلیل لپاره شتون لري" - مارټین فولر.

"که تاسو فکر کوئ چې ډیټا مارټ د اوبو بوتل دی - د مناسب مصرف لپاره پاک شوی ، بسته شوی او بسته شوی ، نو د ډیټا جهيل په طبیعي شکل کې د اوبو لوی زیرمه ده. کاروونکي، زه کولی شم د ځان لپاره اوبه راټول کړم، ژور ډوب کړم، وپلټم "- جیمز ډیکسن.

اوس موږ په ډاډه توګه پوهیږو چې د ډیټا لیک د تحلیلونو په اړه دی ، دا موږ ته اجازه راکوي چې لوی مقدار ډیټا په خپل اصلي بڼه ذخیره کړو او موږ ډیټا ته اړین او اسانه لاسرسی لرو.

زه ډیری وختونه د شیانو ساده کول خوښوم، که زه کولی شم یوه پیچلې اصطلاح په ساده کلمو کې تشریح کړم، نو زه د ځان لپاره پوهیږم چې دا څنګه کار کوي او څه ته اړتیا لري. یوه ورځ ، زه د آی فون عکس ګالري کې شاوخوا ګرځیدم ، او دا زما په ذهن کې راڅرګند شو ، دا د ډیټا ریښتیني جهيل دی ، ما حتی د کنفرانسونو لپاره سلایډ جوړ کړ:

هرڅه خورا ساده دي. موږ په تلیفون کې عکس اخلو، عکس په تلیفون کې خوندي شوی او په آی کلود کې خوندي کیدی شي (د کلاوډ فایل ذخیره). تلیفون د عکس میټاډاټا هم راټولوي: هغه څه چې ښودل شوي، جیو ټګ، وخت. د پایلې په توګه ، موږ کولی شو د خپل عکس موندلو لپاره د آی فون کارونکي دوستانه انٹرفیس وکاروو او موږ حتی شاخصونه هم ګورو ، د مثال په توګه ، کله چې زه د اور وژنې کلمې سره عکسونه لټوم ، زه د اور عکس سره 3 عکسونه ومومم. زما لپاره، دا د سوداګرۍ استخباراتي وسیلې په څیر دی چې خورا ګړندی او روښانه کار کوي.

او البته، موږ باید د امنیت (اجازت او تصدیق) په اړه هیر نکړو، که نه نو زموږ ډاټا کولی شي په اسانۍ سره په عامه ډومین کې پای ته ورسیږي. د لوی شرکتونو او پیل کولو په اړه ډیر خبرونه شتون لري چې معلومات یې د پراختیا کونکو غفلت او د ساده مقرراتو په تعقیب کې پاتې راتلل له امله په عامه توګه شتون لري.

حتی دا ډول ساده انځور موږ سره مرسته کوي چې تصور وکړو چې د ډیټا لیک څه شی دی، د دودیز ډیټا ګودام څخه توپیرونه او د هغې اصلي عناصر:

1. د معلوماتو بارول (Ingestion) د ډیټا لیک کلیدي برخه ده. ډاټا کولی شي د معلوماتو ګودام ته په دوه لارو ننوځي - بیچ (په وقفه کې بار کول) او جریان (د معلوماتو جریان).
2. د فایل ذخیره کول (ذخیره) د ډیټا لیک اصلي برخه ده. موږ ذخیره کولو ته اړتیا لرو ترڅو په اسانۍ سره د توزیع وړ ، خورا معتبر او ټیټ لګښت وي. د مثال په توګه، په AWS کې دا S3 دی.
3. کتلاګ او لټون (کتالوګ او لټون) - د دې لپاره چې موږ د ډیټا سویمپ څخه مخنیوی وکړو (دا هغه وخت دی چې موږ ټول ډیټا په یوه ټوټه کې ډوب کړو، او بیا د هغې سره کار کول ناشوني وي)، موږ اړتیا لرو چې د ډاټا طبقه بندي کولو لپاره د میټاډاټا پرت جوړ کړو. نو کاروونکي کولی شي په اسانۍ سره هغه معلومات ومومي، کوم چې دوی د تحلیل لپاره اړتیا لري. سربیره پردې، تاسو کولی شئ د اضافي لټون حلونه لکه ElasticSearch وکاروئ. لټون د کارونکي سره مرسته کوي چې د کاروونکي دوستانه انٹرفیس له لارې اړین معلومات ومومي.
4. پروسس کول (پروسس) - دا مرحله د معلوماتو پروسس او بدلولو مسولیت لري. موږ کولی شو ډاټا بدل کړو، جوړښت یې بدل کړو، پاک یې کړو، او نور ډیر څه.
5. امنیت (امنیت) - دا مهمه ده چې د حل د امنیت ډیزاین باندې وخت مصرف کړئ. د مثال په توګه، د ذخیره کولو، پروسس کولو او بارولو په وخت کې د معلوماتو کوډ کول. دا مهمه ده چې د تصدیق او تایید میتودونه وکاروئ. په پای کې، د پلټنې وسیله ته اړتیا ده.

د عملي لید څخه، موږ کولی شو د معلوماتو جھیل په دریو ځانګړتیاو سره مشخص کړو:

1. هر څه راټول او ذخیره کړئ - د ډیټا لیک ټول معلومات لري، دواړه د هرې مودې لپاره خام غیر پروسس شوي ډاټا او پروسس شوي / پاک شوي ډاټا.
2. ژور سکین - د ډیټا لیک کاروونکو ته اجازه ورکوي چې ډیټا کشف او تحلیل کړي.
3. انعطاف وړ لاسرسی - د ډیټا لیک مختلف ډیټا او مختلف سناریوګانو لپاره انعطاف وړ لاسرسی چمتو کوي.

اوس موږ کولی شو د ډیټا ګودام او ډیټا جهيل تر مینځ د توپیر په اړه وغږیږو. معمولا خلک پوښتنه کوي:

• د معلوماتو ګودام په اړه څه؟
• ایا موږ د ډیټا ګودام د ډیټا لیک سره ځای په ځای کوو یا موږ یې پراخوو؟
• ایا دا لاهم امکان لري چې د ډیټا لیک پرته ترسره شي؟

په لنډه توګه، هیڅ روښانه ځواب شتون نلري. دا ټول په ځانګړي حالت، د ټیم مهارتونو او بودیجې پورې اړه لري. د مثال په توګه، AWS ته اوریکل ته د ډیټا ګودام لیږدول او د ایمیزون فرعي شرکت لخوا د ډیټا لیک رامینځته کول - Woot - زموږ د ډیټا لیک کیسه: څنګه Woot.com په AWS کې بې سرور ډیټا لیک جوړ کړ.

له بلې خوا ، پلورونکی سنوفلیک وايي چې تاسو نور اړتیا نلرئ د ډیټا لیک په اړه فکر وکړئ ، ځکه چې د دوی ډیټا پلیټ فارم (تر 2020 پورې دا د ډیټا ګودام و) تاسو ته اجازه درکوي د ډیټا لیک او ډیټا ګودام دواړه یوځای کړئ. ما د سنو فلیک سره ډیر کار نه دی کړی، او دا واقعیا یو ځانګړی محصول دی چې دا کولی شي. د قیمت قیمت بله موضوع ده.

په پایله کې ، زما شخصي نظر دا دی چې موږ لاهم زموږ د راپور ورکولو لپاره د ډیټا اصلي سرچینې په توګه د ډیټا ګودام ته اړتیا لرو ، او هر هغه څه چې مناسب نه وي موږ د ډیټا جهیل کې ذخیره کوو. د تحلیلونو ټول رول د پریکړې کولو لپاره سوداګرۍ ته اسانه لاسرسي چمتو کول دي. هر هغه څه چې ویل کیدی شي، د سوداګرۍ کاروونکي د ډیټا لیک په پرتله د ډیټا ګودام سره ډیر اغیزمن کار کوي، د بیلګې په توګه په ایمیزون کې - دلته ریډشیفټ (د تحلیلي ډیټا ګودام) شتون لري او د ریډ شفټ سپیکٹرم / اتینا (د S3 په اساس د ډیټا لیک لپاره د SQL انٹرفیس شتون لري. Hive/Presto). ورته د نورو عصري تحلیلي معلوماتو ګودامونو باندې تطبیق کیږي.

راځئ چې د ډیټا ګودام یو عادي جوړښت ته وګورو:

دا یو کلاسیک حل دی. موږ د سرچینې سیسټمونه لرو، د ETL/ELT په کارولو سره موږ ډاټا د تحلیلي معلوماتو ګودام کې کاپي کوو او دا د سوداګرۍ استخباراتو حل سره وصل کوو (زما د خوښې میز دی، ستاسو په اړه څه دی؟).

دا حل لاندې زیانونه لري:

• د ETL/ELT عملیات وخت او سرچینو ته اړتیا لري.
• د یوې قاعدې په توګه، د تحلیلي معلوماتو ګودام کې د معلوماتو ذخیره کولو لپاره حافظه ارزانه نه ده (د بیلګې په توګه، Redshift، BigQuery، Teradata)، ځکه چې موږ اړتیا لرو یو بشپړ کلستر واخلو.
• د سوداګرۍ کارونکي پاک او ډیری وختونه راټول شوي ډیټا ته لاسرسی لري او خام ډیټا ته لاسرسی نلري.

البته، دا ټول ستاسو په قضیه پورې اړه لري. که تاسو د خپل ډیټا ګودام سره ستونزه نلرئ ، نو تاسو په هیڅ ډول د ډیټا لیک ته اړتیا نلرئ. مګر کله چې د ځای ، بریښنا یا نرخ نشتوالي سره ستونزې رامینځته کیږي کلیدي رول لوبوي ، نو تاسو کولی شئ د ډیټا لیک اختیار په پام کې ونیسئ. له همدې امله د ډیټا لیک خورا مشهور دی. دلته د ډیټا لیک معمارۍ یوه بیلګه ده:

د ډیټا لیک چلند په کارولو سره ، موږ خام ډیټا زموږ د ډیټا لیک (بیچ یا سټینګ) کې بار کوو ، بیا موږ د اړتیا سره سم ډیټا پروسس کوو. د ډیټا لیک سوداګرۍ کاروونکو ته اجازه ورکوي چې خپل ډیټا بدلونونه (ETL/ELT) رامینځته کړي یا د سوداګرۍ استخباراتو حلونو کې ډیټا تحلیل کړي (که چیرې اړین ډرایور شتون ولري).

د هر تحلیلي حل هدف د سوداګرۍ کاروونکو ته خدمت کول دي. له همدې امله، موږ باید تل د سوداګرۍ اړتیاوو سره سم کار وکړو. (په ایمیزون کې دا یو له اصولو څخه دی - شاته کار کول).

د ډیټا ګودام او ډیټا لیک دواړو سره کار کول ، موږ کولی شو دواړه حلونه پرتله کړو:

اصلي پایله چې کیدی شي دا دی چې د ډیټا ګودام د ډیټا لیک سره سیالي نه کوي ، بلکه دا بشپړوي. مګر دا تاسو پورې اړه لري چې پریکړه وکړئ چې ستاسو د قضیې لپاره څه سم دي. دا تل په زړه پوري ده چې دا پخپله هڅه وکړئ او سمې پایلې راوباسئ.

زه به تاسو ته یو له هغه قضیو څخه هم ووایم کله چې ما د ډیټا لیک چلند کارول پیل کړل. هرڅه خورا کوچني دي ، ما هڅه وکړه چې د ELT وسیله وکاروم (موږ میټیلین ETL درلود) او ایمیزون ریډ شفټ ، زما حل کار وکړ ، مګر اړتیاوې یې پوره نه کړې.

زه اړتیا لرم چې ویب لاګونه واخلم، دوی یې بدل کړم او د 2 قضیو لپاره ډاټا چمتو کولو لپاره یې راټول کړم:

1. د بازار موندنې ټیم غوښتل چې د SEO لپاره د بوټو فعالیت تحلیل کړي
2. IT غوښتل د ویب پاڼې فعالیت میټریکونه وګوري

ډیر ساده، ډیر ساده لوګو. دلته یو مثال دی:

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 لچکدار نقشه کمول (هډوپ).
• AWS S3 د فایل ذخیره کولو په توګه د ډیټا کوډ کولو او لاسرسي محدودولو وړتیا سره
• د InMemory کمپیوټري ځواک په توګه سپارک او PySpark د منطق او ډیټا بدلون لپاره
• پارکیټ د سپارک په پایله کې
• AWS ګلو کرالر د نوي ډیټا او برخو په اړه د میټاډاټا راټولونکي په توګه
• د Redshift سپیکٹرم د موجوده Redshift کاروونکو لپاره ډیټا لیک ته د SQL انٹرفیس په توګه

ترټولو کوچنی EMR + سپارک کلستر په 30 دقیقو کې د فایلونو ټول سټیک پروسس کړ. د AWS لپاره نورې قضیې شتون لري، په ځانګړې توګه ډیری د الیکسا پورې اړوند، چیرته چې ډیری ډاټا شتون لري.

پدې وروستیو کې ما زده کړل چې د ډیټا لیک یو له زیانونو څخه GDPR دی. ستونزه هغه وخت ده چې پیرودونکي د حذف کولو غوښتنه کوي او ډاټا په یوه فایل کې وي، موږ نشو کولی د ډیټا مینیپولیشن ژبه وکاروو او د ډیټابیس په څیر عملیات حذف کړو.

زه امید لرم چې دا مقاله د ډیټا ګودام او ډیټا لیک ترمینځ توپیر روښانه کړی. که تاسو علاقه لرئ، زه کولی شم زما ډیرې مقالې یا د مسلکي کسانو مقالې وژباړم چې ما لوستل. او د هغه حلونو په اړه هم ووایاست چې زه ورسره کار کوم او د دوی جوړښت.

سرچینه: www.habr.com