آیا به دریاچه داده نیاز داریم؟ با انبار داده چه کنیم؟

این مقاله ترجمه ای از مقاله من در رسانه است - شروع کار با Data Lake، که احتمالاً به دلیل سادگی آن کاملاً محبوب بود. بنابراین، تصمیم گرفتم آن را به زبان روسی بنویسم و ​​کمی اضافه کنم تا برای یک فرد عادی که متخصص داده نیست، بفهمم انبار داده (DW) چیست و دریاچه داده چیست (دریاچه داده) و چگونه آنها با هم کنار بیایند .

چرا می خواستم در مورد دریاچه داده بنویسم؟ من بیش از 10 سال است که با داده ها و تجزیه و تحلیل ها کار می کنم، و اکنون قطعاً با داده های بزرگ در آمازون الکسا AI در کمبریج، که در بوستون است، کار می کنم، اگرچه من در ویکتوریا در جزیره ونکوور زندگی می کنم و اغلب از بوستون، سیاتل بازدید می کنم. و در ونکوور، و حتی گاهی در مسکو، در کنفرانس ها سخنرانی می کنم. من هم گهگاهی می نویسم، اما عمدتاً به زبان انگلیسی می نویسم و ​​قبلاً هم نوشته ام برخی از کتاب های، من همچنین نیاز به اشتراک گذاری روندهای تجزیه و تحلیل از آمریکای شمالی دارم و گاهی اوقات در آن می نویسم تلگرام.

من همیشه با انبارهای داده کار کرده ام و از سال 2015 شروع به همکاری نزدیک با خدمات وب آمازون کردم و به طور کلی به تجزیه و تحلیل ابری (AWS، Azure، GCP) روی آوردم. من تکامل راه حل های تجزیه و تحلیل را از سال 2007 مشاهده کردم و حتی برای فروشنده انبار داده Teradata کار کردم و آن را در Sberbank پیاده سازی کردم، و آن زمان بود که Big Data with Hadoop ظاهر شد. همه شروع کردند به گفتن این که دوران ذخیره سازی گذشته و حالا همه چیز روی هادوپ است و بعد شروع کردند به صحبت در مورد دریاچه داده، که حالا قطعاً پایان انبار داده رسیده است. اما خوشبختانه (شاید متأسفانه برای برخی که با راه اندازی Hadoop پول زیادی به دست آوردند)، انبار داده از بین نرفت.

در این مقاله به این خواهیم پرداخت که دریاچه داده چیست. این مقاله برای افرادی در نظر گرفته شده است که تجربه کمی با انبارهای داده دارند یا اصلاً تجربه ندارند.

در تصویر دریاچه بلد است، این یکی از دریاچه های مورد علاقه من است، اگرچه من فقط یک بار آنجا بودم، تا آخر عمر آن را به یاد آوردم. اما ما در مورد نوع دیگری از دریاچه صحبت خواهیم کرد - دریاچه داده. شاید بسیاری از شما قبلاً بیش از یک بار در مورد این اصطلاح شنیده باشید، اما یک تعریف بیشتر به کسی آسیب نمی رساند.

اول از همه، در اینجا محبوب ترین تعاریف دریاچه داده آمده است:

"ذخیره فایلی از انواع داده های خام که برای تجزیه و تحلیل توسط هر فردی در سازمان در دسترس است" - مارتین فاولر.

"اگر فکر می کنید که دیتا مارت یک بطری آب است - تصفیه شده، بسته بندی و بسته بندی شده برای مصرف راحت، پس دریاچه داده یک مخزن عظیم آب در شکل طبیعی آن است. کاربران، من می توانم برای خودم آب جمع آوری کنم، در اعماق شیرجه بزنم، کاوش کنم.» - جیمز دیکسون.

اکنون با اطمینان می دانیم که دریاچه داده در مورد تجزیه و تحلیل است، به ما امکان می دهد حجم زیادی از داده ها را به شکل اصلی خود ذخیره کنیم و دسترسی لازم و راحت به داده ها را داریم.

من اغلب دوست دارم چیزها را ساده کنم، اگر بتوانم یک اصطلاح پیچیده را با کلمات ساده توضیح دهم، پس خودم می فهمم که چگونه کار می کند و برای چه چیزی لازم است. یک روز داشتم در گالری عکس آیفون نگاه می‌کردم، و متوجه شدم، اینجا یک دریاچه داده واقعی است، حتی یک اسلاید برای کنفرانس‌ها درست کردم:

همه چیز بسیار ساده است. ما با گوشی عکس می گیریم، عکس روی گوشی ذخیره می شود و می توان آن را در iCloud (ذخیره سازی فایل های ابری) ذخیره کرد. این تلفن همچنین ابرداده عکس را جمع آوری می کند: آنچه نشان داده شده است، برچسب جغرافیایی، زمان. در نتیجه می توانیم از رابط کاربر پسند آیفون برای یافتن عکس خود استفاده کنیم و حتی نشانگرهایی را هم می بینیم، مثلاً وقتی عکس هایی با کلمه آتش را جستجو می کنم، 3 عکس با تصویر آتش سوزی پیدا می کنم. برای من، این دقیقاً مانند یک ابزار هوش تجاری است که بسیار سریع و دقیق کار می کند.

و البته، ما نباید امنیت (مجوز و احراز هویت) را فراموش کنیم، در غیر این صورت داده های ما می توانند به راحتی در مالکیت عمومی قرار گیرند. اخبار زیادی درباره شرکت‌های بزرگ و استارت‌آپ‌هایی وجود دارد که داده‌های آنها به دلیل سهل انگاری توسعه‌دهندگان و رعایت نکردن قوانین ساده در دسترس عموم قرار گرفت.

حتی چنین تصویر ساده ای به ما کمک می کند تصور کنیم که دریاچه داده چیست، تفاوت آن با یک انبار داده سنتی و عناصر اصلی آن:

1. در حال بارگیری داده ها (بلع) جزء کلیدی دریاچه داده است. داده ها می توانند از دو طریق وارد انبار داده شوند - دسته ای (بارگیری در فواصل زمانی) و جریانی (جریان داده).
2. ذخیره سازی فایل (ذخیره) جزء اصلی دریاچه داده است. ما به فضای ذخیره سازی نیاز داشتیم که به راحتی مقیاس پذیر، بسیار قابل اعتماد و کم هزینه باشد. به عنوان مثال، در AWS S3 است.
3. کاتالوگ و جستجو (کاتالوگ و جستجو) - برای اینکه بتوانیم از Data Swamp اجتناب کنیم (این زمانی است که همه داده ها را در یک شمع تخلیه می کنیم و بعد کار با آن غیرممکن است) باید یک لایه ابرداده برای طبقه بندی داده ها ایجاد کنیم. به طوری که کاربران بتوانند به راحتی داده هایی را که برای تجزیه و تحلیل نیاز دارند پیدا کنند. علاوه بر این، می توانید از راه حل های جستجوی اضافی مانند ElasticSearch استفاده کنید. جستجو به کاربر کمک می کند تا داده های مورد نیاز را از طریق یک رابط کاربر پسند پیدا کند.
4. پردازش (فرآیند) - این مرحله وظیفه پردازش و تبدیل داده ها را بر عهده دارد. ما می‌توانیم داده‌ها را تغییر دهیم، ساختار آن را تغییر دهیم، آن‌ها را تمیز کنیم و خیلی چیزهای دیگر.
5. امنیت (امنیت) - صرف زمان برای طراحی امنیتی راه حل مهم است. به عنوان مثال، رمزگذاری داده ها در حین ذخیره سازی، پردازش و بارگذاری. مهم است که از روش های احراز هویت و مجوز استفاده کنید. در نهایت، یک ابزار حسابرسی مورد نیاز است.

از نقطه نظر عملی، ما می توانیم دریاچه داده را با سه ویژگی مشخص کنیم:

1. هر چیزی را جمع آوری و ذخیره کنید - دریاچه داده شامل تمام داده ها، هم داده های خام پردازش نشده برای هر دوره زمانی و هم داده های پردازش شده/پاک شده است.
2. بررسی عمیق - دریاچه داده به کاربران امکان می دهد داده ها را کاوش و تجزیه و تحلیل کنند.
3. دسترسی انعطاف پذیر - دریاچه داده دسترسی انعطاف پذیری را برای داده های مختلف و سناریوهای مختلف فراهم می کند.

اکنون می توانیم در مورد تفاوت بین انبار داده و دریاچه داده صحبت کنیم. معمولا مردم می پرسند:

• در مورد انبار داده چطور؟
• آیا انبار داده را با دریاچه داده جایگزین می کنیم یا در حال گسترش آن هستیم؟
• آیا هنوز هم می توان بدون دریاچه داده انجام داد؟

به طور خلاصه، هیچ پاسخ روشنی وجود ندارد. همه چیز به موقعیت خاص، مهارت های تیم و بودجه بستگی دارد. به عنوان مثال، انتقال یک انبار داده به Oracle به AWS و ایجاد یک دریاچه داده توسط یک شرکت تابعه آمازون - Woot - داستان دریاچه داده ما: چگونه Woot.com یک دریاچه داده بدون سرور در AWS ساخت.

از سوی دیگر، فروشنده Snowflake می گوید که دیگر نیازی نیست به دریاچه داده فکر کنید، زیرا پلت فرم داده آنها (تا سال 2020 یک انبار داده بود) به شما امکان می دهد هر دو دریاچه داده و انبار داده را ترکیب کنید. من زیاد با Snowflake کار نکرده‌ام، و واقعاً یک محصول منحصربه‌فرد است که می‌تواند این کار را انجام دهد. قیمت موضوع بحث دیگری است.

در پایان، نظر شخصی من این است که ما هنوز به یک انبار داده به عنوان منبع اصلی داده برای گزارش خود نیاز داریم، و هر چیزی که مناسب نیست در یک دریاچه داده ذخیره می کنیم. تمام نقش تجزیه و تحلیل فراهم کردن دسترسی آسان برای تصمیم گیری برای کسب و کار است. هرچه می توان گفت، کاربران تجاری با یک انبار داده کارآمدتر از یک دریاچه داده کار می کنند، برای مثال در آمازون - Redshift (انبار داده های تحلیلی) و Redshift Spectrum/Athena (رابط SQL برای دریاچه داده در S3 بر اساس کندو/پرستو). همین امر در مورد دیگر انبارهای داده تحلیلی مدرن نیز صدق می کند.

بیایید به یک معماری انبار داده معمولی نگاه کنیم:

این یک راه حل کلاسیک است. ما سیستم‌های منبع داریم، با استفاده از ETL/ELT داده‌ها را در یک انبار داده تحلیلی کپی می‌کنیم و آن را به یک راه‌حل هوش تجاری متصل می‌کنیم (مورد علاقه من Tableau است، مال شما چطور؟).

این راه حل دارای معایب زیر است:

• عملیات ETL/ELT به زمان و منابع نیاز دارد.
• به عنوان یک قاعده، حافظه برای ذخیره داده ها در یک انبار داده های تحلیلی ارزان نیست (به عنوان مثال، Redshift، BigQuery، Teradata)، زیرا ما نیاز به خرید یک خوشه کامل داریم.
• کاربران تجاری به داده های تمیز شده و اغلب تجمیع شده دسترسی دارند و به داده های خام دسترسی ندارند.

البته همه چیز به مورد شما بستگی دارد. اگر با انبار داده خود مشکلی ندارید، اصلاً به دریاچه داده نیاز ندارید. اما هنگامی که مشکلات کمبود فضا، قدرت یا قیمت نقش کلیدی ایفا می کند، می توانید گزینه یک دریاچه داده را در نظر بگیرید. به همین دلیل است که دریاچه داده بسیار محبوب است. در اینجا نمونه ای از معماری دریاچه داده است:

با استفاده از رویکرد دریاچه داده، داده های خام را در دریاچه داده خود بارگذاری می کنیم (دسته ای یا جریانی)، سپس داده ها را در صورت نیاز پردازش می کنیم. دریاچه داده به کاربران تجاری اجازه می دهد تا تبدیل داده های خود را ایجاد کنند (ETL/ELT) یا داده ها را در راه حل های هوش تجاری تجزیه و تحلیل کنند (در صورت وجود محرک لازم).

هدف هر راه حل تحلیلی، خدمت رسانی به کاربران تجاری است. بنابراین، ما باید همیشه بر اساس نیازهای تجاری کار کنیم. (در آمازون این یکی از اصول است - کار معکوس).

با کار با انبار داده و دریاچه داده، می توانیم هر دو راه حل را با هم مقایسه کنیم:

نتیجه اصلی که می توان گرفت این است که انبار داده با دریاچه داده رقابت نمی کند، بلکه مکمل آن است. اما این شما هستید که تصمیم می گیرید چه چیزی برای پرونده شما مناسب است. همیشه جالب است که خودتان آن را امتحان کنید و نتیجه‌گیری درستی بگیرید.

همچنین می خواهم یکی از مواردی را که استفاده از رویکرد دریاچه داده را شروع کردم به شما بگویم. همه چیز کاملاً بی اهمیت است، من سعی کردم از یک ابزار ELT (ما Matillion ETL داشتیم) و Amazon Redshift استفاده کنم، راه حل من کار کرد، اما با الزامات مطابقت نداشت.

من باید لاگ های وب را می گرفتم، آنها را تبدیل می کردم و آنها را برای ارائه داده برای 2 مورد جمع آوری می کردم:

1. تیم بازاریابی می خواست فعالیت ربات ها را برای سئو تجزیه و تحلیل کند
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 Elastic Map Reduce (Hadoop) برای توان محاسباتی
• AWS S3 به عنوان ذخیره سازی فایل با قابلیت رمزگذاری داده ها و محدود کردن دسترسی
• Spark به عنوان قدرت محاسباتی InMemory و PySpark برای منطق و تبدیل داده ها
• پارکت در نتیجه اسپارک
• AWS Glue Crawler به عنوان یک گردآورنده ابرداده در مورد داده ها و پارتیشن های جدید
• Redshift Spectrum به عنوان یک رابط SQL به دریاچه داده برای کاربران موجود Redshift

کوچکترین خوشه EMR+Spark کل پشته فایل ها را در 30 دقیقه پردازش کرد. موارد دیگری برای AWS وجود دارد، به خصوص بسیاری از موارد مربوط به الکسا، که در آن داده های زیادی وجود دارد.

اخیراً متوجه شدم یکی از معایب دریاچه داده GDPR است. مشکل این است که وقتی مشتری درخواست حذف آن را می‌کند و داده‌ها در یکی از فایل‌ها قرار دارند، نمی‌توانیم از زبان دستکاری داده‌ها و عملیات DELETE مانند یک پایگاه داده استفاده کنیم.

امیدوارم این مقاله تفاوت بین انبار داده و دریاچه داده را روشن کرده باشد. اگر علاقه داشتید، می‌توانم بیشتر مقالاتم یا مقالات حرفه‌ای را که خوانده‌ام ترجمه کنم. و همچنین در مورد راه حل هایی که با آنها کار می کنم و معماری آنها بگویید.

منبع: www.habr.com