Нужно ли е езеро от данни? А какво да правим с хранилището на данни?

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

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

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

В тази статия ще разгледаме какво е Data Lake. Статията е предназначена за хора с малко опит в хранилищата на данни или изобщо без такъв.

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

Преди всичко ето най-популярните определения за Data Lake:

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

«Ако смятате, че езерото на данни е бутилка вода — пречистена, опакована и носят за удобно потребление, то езерото с данни е огромен резервоар с вода в естествения й вид. Потребителите могат да вземат вода за себе си, да се гмуркат дълбоко и да изследват» — Джеймс Диксън.

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

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

Всичко е много просто. Ние правим снимка с телефона, снимката се запазва на телефона и може да бъде записана в iCloud (облачна файлова услуга). Също така, телефонът събира метаданни за снимката: какво е изобразено, геолокация, време. Резултатът е, че можем да използваме удобния интерфейс на iPhone, за да намерим снимката си и дори виждаме показатели, напр. когато търся снимки с думата огън (fire), намирам 3 снимки с изображение на огнище. За мен това е като инструмент за бизнес интелигентност, който работи бързо и точно.

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

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

1. Зареждане на данни (Ingestion) — ключов компонент на езерото с данни. Дадените данни могат да влизат в хранилището по два начина — batch (зареждане с интервали) и streaming (поток от данни).
2. Файлово хранилище (Storage) — основният компонент на Езерото с Данни. Необходимо е хранилището да бъде лесно мащабируемо, изключително надеждно и с ниска цена. Например, в AWS това е S3.
3. Каталог и Търсене (Каталог и търсене) — за да избегнем Блатото на данните (когато сваляме всички данни на едно място и след това е невъзможно да работим с тях), е необходимо да създадем слой от метаданни за класификация на данните, така че потребителите лесно да намерят информацията, от която се нуждаят за анализ. Освен това, можем да използваме допълнителни решения за търсене, например ElasticSearch. Търсенето помага на потребителя да намери необходимите данни чрез удобен интерфейс.
4. Обработка (Процес) — стъпката, отговаряща за обработката и трансформацията на данните. Можем да трансформираме данни, променяме техните структури, почистваме и много други.
5. Сигурност (Сигурност) — важно е да отделим време за проектиране на безопасността на решението. Например, шифроване на данни по време на съхранение, обработка и пренос. Важно е да се използват методи за автентикация и авторизация. Накрая, необходим е инструмент за одит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Искам също да споделя един от случаите, когато започнах да използвам подхода на озерото от данни. Всичко беше доста банално - опитах се да използвам инструмент ELT (разполагахме с Matillion ETL) и Amazon Redshift. Моето решение работеше, но не отговаряше на изискванията.

Необходимо ми беше да взема уеб логове, да ги трансформирам и агрегира, за да предоставя данни за два случая:

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 Elastic Map Reduce (Hadoop) като изчислителна мощност.
• AWS S3 като хранилище на файлове с възможност за криптиране на данни и разпределение на достъпа.
• Spark като InMemory изчислителна мощност и PySpark за логика и трансформация на данни.
• Parquet като резултат от работата на Spark.
• AWS Glue Crawler като събирач на метаданни за нови данни и партиции.
• Redshift Spectrum като SQL интерфейс към озерото от данни за съществуващите потребители на Redshift.

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

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

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

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