Имаме ли нужда от езеро с данни? Какво да правим със склада за данни?

Тази статия е превод на моята статия за среда - Първи стъпки с Data Lake, който се оказа доста популярен, вероятно поради своята простота. Затова реших да го напиша на руски и да добавя малко, за да стане ясно на обикновен човек, който не е специалист по данни, какво е хранилище на данни (DW) и какво е езеро с данни (Data Lake) и как те разбирайте се заедно.

Защо исках да пиша за езерото с данни? Работя с данни и анализи повече от 10 години и сега определено работя с големи данни в Amazon Alexa AI в Кеймбридж, който е в Бостън, въпреки че живея във Виктория на остров Ванкувър и често посещавам Бостън, Сиатъл , и във Ванкувър, а понякога дори в Москва, говоря на конференции. Аз също пиша от време на време, но пиша основно на английски и вече съм писала няколко книги, също имам нужда да споделям тенденции в анализите от Северна Америка и понякога пиша телеграми.

Винаги съм работил със складове за данни и от 2015 г. започнах да работя в тясно сътрудничество с Amazon Web Services и като цяло преминах към облачен анализ (AWS, Azure, GCP). Наблюдавах еволюцията на решенията за анализ от 2007 г. насам и дори работих за доставчика на хранилище за данни Teradata и го внедрих в Sberbank, и тогава се появиха Big Data с Hadoop. Всички започнаха да казват, че ерата на съхранението е отминала и сега всичко е на Hadoop, а след това отново започнаха да говорят за Data Lake, че сега определено е настъпил краят на хранилището за данни. Но за щастие (може би за съжаление за някои, които направиха много пари, настройвайки Hadoop), хранилището на данни не изчезна.

В тази статия ще разгледаме какво е езеро с данни. Тази статия е предназначена за хора, които имат малък или никакъв опит със складове за данни.

На снимката е езерото Блед, това е едно от любимите ми езера, въпреки че бях там само веднъж, запомних го за цял живот. Но ние ще говорим за друг тип езеро - езеро с данни. Може би много от вас вече са чували за този термин повече от веднъж, но още едно определение няма да навреди на никого.

На първо място, ето най-популярните дефиниции на Data Lake:

„файлово хранилище на всички видове необработени данни, което е достъпно за анализ от всеки в организацията“ – Мартин Фаулър.

„Ако смятате, че базата за данни е бутилка вода – пречистена, опакована и опакована за удобна консумация, тогава езерото за данни е огромен резервоар с вода в естествената й форма. Потребители, мога да събирам вода за себе си, да се гмуркам дълбоко, да изследвам” – Джеймс Диксън.

Сега знаем със сигурност, че езерото от данни е свързано с анализи, то ни позволява да съхраняваме големи количества данни в оригиналната им форма и имаме необходимия и удобен достъп до данните.

Често обичам да опростявам нещата, ако мога да обясня сложен термин с прости думи, тогава разбирам за себе си как работи и за какво е необходим. Един ден се рових в фотогалерията на iPhone и ми просветна, че това е истинско езеро с данни, дори направих слайд за конференции:

Всичко е много просто. Правим снимка на телефона, снимката се запазва на телефона и може да бъде запазена в iCloud (хранение на файлове в облак). Телефонът също така събира метаданни за снимки: какво е показано, географски етикет, време. В резултат на това можем да използваме удобния за потребителя интерфейс на iPhone, за да намерим нашата снимка и дори виждаме индикатори, например, когато търся снимки с думата огън, намирам 3 снимки с изображение на огън. За мен това е точно като инструмент за бизнес разузнаване, който работи много бързо и ясно.

И разбира се, не трябва да забравяме сигурността (упълномощаване и удостоверяване), в противен случай нашите данни могат лесно да се окажат публично достояние. Има много новини за големи корпорации и стартиращи компании, чиито данни станаха публично достъпни поради небрежност на разработчиците и неспазване на прости правила.

Дори такава проста картина ни помага да си представим какво представлява езерото от данни, разликите му от традиционното хранилище за данни и основните му елементи:

1. Зареждане на данни (Поглъщане) е ключов компонент на езерото от данни. Данните могат да влизат в хранилището на данни по два начина - пакетно (зареждане на интервали) и поточно (поток от данни).
2. Съхранение на файлове (Съхранение) е основният компонент на Data Lake. Имахме нужда хранилището да бъде лесно мащабируемо, изключително надеждно и с ниска цена. Например в AWS това е S3.
3. Каталог и Търсене (Каталог и търсене) - за да избегнем Data Swamp (това е, когато изхвърляме всички данни на една купчина и след това е невъзможно да работим с тях), трябва да създадем слой с метаданни, за да класифицираме данните така че потребителите лесно да намират данните, които са им необходими за анализ. Освен това можете да използвате допълнителни решения за търсене като ElasticSearch. Търсенето помага на потребителя да намери необходимите данни чрез удобен за потребителя интерфейс.
4. Обработване (Процес) - тази стъпка е отговорна за обработката и трансформирането на данни. Можем да трансформираме данни, да променяме структурата им, да ги почистваме и много повече.
5. сигурност (Сигурност) - Важно е да отделите време за дизайна на сигурността на решението. Например криптиране на данни по време на съхранение, обработка и зареждане. Важно е да използвате методи за удостоверяване и оторизация. И накрая, необходим е инструмент за одит.

От практическа гледна точка можем да характеризираме езерото от данни чрез три атрибута:

1. Събирайте и съхранявайте всичко — езерото от данни съдържа всички данни, както необработени необработени данни за произволен период от време, така и обработени/почистени данни.
2. Дълбоко сканиране — езерото от данни позволява на потребителите да изследват и анализират данни.
3. Гъвкав достъп — Езерото от данни осигурява гъвкав достъп за различни данни и различни сценарии.

Сега можем да говорим за разликата между склад за данни и езеро от данни. Обикновено хората питат:

• Какво ще кажете за хранилището на данни?
• Заменяме ли хранилището за данни с езеро от данни или го разширяваме?
• Все още ли е възможно да се направи без езеро с данни?

Накратко, няма ясен отговор. Всичко зависи от конкретната ситуация, уменията на екипа и бюджета. Например, мигриране на склад за данни към Oracle към AWS и създаване на езеро от данни от дъщерно дружество на Amazon - Woot - Нашата история за езерото с данни: Как Woot.com изгради езеро с данни без сървър на AWS.

От друга страна, доставчикът Snowflake казва, че вече не е необходимо да мислите за езеро от данни, тъй като тяхната платформа за данни (до 2020 г. беше склад за данни) ви позволява да комбинирате както езеро от данни, така и хранилище за данни. Не съм работил много със Snowflake и това наистина е уникален продукт, който може да направи това. Цената на емисията е друг въпрос.

В заключение, личното ми мнение е, че все още се нуждаем от хранилище за данни като основен източник на данни за нашите отчети и всичко, което не пасва, съхраняваме в езеро от данни. Цялата роля на анализа е да осигури лесен достъп на бизнеса за вземане на решения. Каквото и да се каже, бизнес потребителите работят по-ефективно със склад за данни, отколкото с езеро от данни, например в Amazon - има Redshift (склад за аналитични данни) и има Redshift Spectrum/Athena (SQL интерфейс за езеро с данни в S3, базирано на Hive/Presto). Същото важи и за други съвременни аналитични хранилища за данни.

Нека да разгледаме типична архитектура на хранилище за данни:

Това е класическо решение. Имаме изходни системи, като използваме ETL/ELT, копираме данни в склад за аналитични данни и ги свързваме с решение за бизнес разузнаване (моят любим е Tableau, какво ще кажете за вашия?).

Това решение има следните недостатъци:

• ETL/ELT операциите изискват време и ресурси.
• По правило паметта за съхраняване на данни в склад за аналитични данни не е евтина (например Redshift, BigQuery, Teradata), тъй като трябва да закупим цял клъстер.
• Бизнес потребителите имат достъп до изчистени и често обобщени данни и нямат достъп до необработени данни.

Разбира се, всичко зависи от вашия случай. Ако нямате проблеми с вашето хранилище за данни, тогава изобщо не се нуждаете от езеро с данни. Но когато възникнат проблеми с липсата на пространство, мощност или цената играе ключова роля, тогава можете да обмислите опцията за езеро с данни. Ето защо езерото с данни е много популярно. Ето пример за архитектура на езеро с данни:

Използвайки подхода на езерото от данни, ние зареждаме необработени данни в нашето езеро от данни (партида или поточно предаване), след което обработваме данните според нуждите. Езерото от данни позволява на бизнес потребителите да създават свои собствени трансформации на данни (ETL/ELT) или да анализират данни в решения за бизнес разузнаване (ако е наличен необходимият драйвер).

Целта на всяко решение за анализ е да обслужва бизнес потребителите. Затова винаги трябва да работим според изискванията на бизнеса. (В Amazon това е един от принципите - работа назад).

Работейки както със склад за данни, така и с езеро от данни, можем да сравним и двете решения:

Основният извод, който може да се направи е, че хранилището за данни не се конкурира с езерото от данни, а по-скоро го допълва. Но от вас зависи да решите какво е подходящо за вашия случай. Винаги е интересно да опитате сами и да направите правилните заключения.

Бих искал също да ви разкажа за един от случаите, когато започнах да използвам подхода на езерото от данни. Всичко е доста тривиално, опитах се да използвам 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 хиляди файла бяха създадени за един ден. Това не е много повече обем, само 4 гигабайта. Но размерът на нашия клъстер Redshift също беше малък (XNUMX възела). Зареждането на един файл по традиционния начин отне около минута. Тоест проблемът не беше решен челно. И това беше случаят, когато реших да използвам подхода на езерото от данни. Решението изглеждаше така:

Това е доста просто (искам да отбележа, че предимството на работата в облака е простотата). Използвах:

• AWS Elastic Map Reduce (Hadoop) за изчислителна мощност
• AWS S3 като файлово хранилище с възможност за криптиране на данни и ограничаване на достъпа
• Spark като InMemory изчислителна мощност и PySpark за логика и трансформация на данни
• Паркет в резултат на Спарк
• AWS Glue Crawler като колектор на метаданни за нови данни и дялове
• Redshift Spectrum като SQL интерфейс към езерото с данни за съществуващи потребители на Redshift

Най-малкият EMR+Spark клъстер обработи целия стек от файлове за 30 минути. Има и други случаи за AWS, особено много, свързани с Alexa, където има много данни.

Съвсем наскоро научих, че един от недостатъците на езерото от данни е GDPR. Проблемът е, че когато клиентът поиска да го изтрие и данните са в един от файловете, не можем да използваме Data Manipulation Language и операцията DELETE, както в база данни.

Надявам се, че тази статия е изяснила разликата между склад за данни и езеро от данни. Ако се интересувате, мога да преведа още мои статии или статии на професионалисти, които чета. И също така разкажете за решенията, с които работя, и тяхната архитектура.

Източник: www.habr.com