Озеро данных что это
Озеро, хранилище и витрина данных
Рассмотрим три типа облачных хранилищ данных, их различия и области применения.
Озеро данных
Озеро данных (data lake) — это большой репозиторий необработанных исходных данных, как неструктурированных, так и частично структурированных. Данные собираются из различных источников и просто хранятся. Они не модифицируются под определенную цель и не преобразуются в какой-либо формат. Для анализа этих данных требуется длительная предварительная подготовка, очистка и форматирование для придания им однородности. Озера данных — отличные ресурсы для городских администраций и прочих организаций, которые хранят информацию, связанную с перебоями в работе инфраструктуры, дорожным движением, преступностью или демографией. Данные можно использовать в дальнейшем для внесения изменений в бюджет или пересмотра ресурсов, выделенных коммунальным или экстренным службам.
Хранилище данных
Хранилище данных (data warehouse) представляет собой данные, агрегированные из разных источников в единый центральный репозиторий, который унифицирует их по качеству и формату. Специалисты по работе с данными могут использовать данные из хранилища в таких сферах, как data mining, искусственный интеллект (ИИ), машинное обучение и, конечно, в бизнес-аналитике. Хранилища данных можно использовать в больших городах для сбора информации об электронных транзакциях, поступающей от различных департаментов, включая данные о штрафах за превышение скорости, уплате акцизов и т. д. Хранилища также могут использовать разработчики для сбора терабайтов данных, генерируемых автомобильными датчиками. Это поможет им принимать правильные решения при разработке технологий для автономного вождения.
Витрина данных
Витрина данных (data mart) — это хранилище данных, предназначенное для определенного круга пользователей в компании или ее подразделении. Витрина данных может использоваться отделом маркетинга производственной компании для определения целевой аудитории при разработке маркетинговых планов. Также производственный отдел может применять ее для анализа производительности и количества ошибок, чтобы создать условия для непрерывного совершенствования процессов. Наборы данных в витрине данных часто используются в режиме реального времени для аналитики и получения практических результатов.
Озеро, хранилище и витрина данных: ключевые различия
Все упомянутые репозитории используются для хранения данных, но между ними есть существенные различия. Например, хранилище и озеро данных — крупные репозитории, однако озеро обычно более рентабельно с точки зрения затрат на внедрение и обслуживание, поскольку в нем по большей части хранятся неструктурированные данные.
За последние несколько лет архитектура озер данных эволюционировала, и теперь способна поддерживать бо́льшие объемы данных и облачные вычисления. Большие объемы данных поступают от разных источников в централизованный репозиторий.
Хранилище данных можно организовать одним из трех способов:
Витрина данных содержит небольшой по сравнению с хранилищем и озером объем данных, которые разбиты на категории для применения конкретной группой людей или подразделением компании. Витрина данных может быть представлена в виде различных схем (звезды, снежинки или свода), которые определяются логической структурой данных. Формат свода данных (data vault) является самым гибким, универсальным и масштабируемым.
Существует три типа витрин данных:
IBM предлагает различные решения для облачного хранения и интеллектуального анализа данных.
Озера данных: как устроены data lakes и зачем они нужны
Читайте «Хайтек» в
Озера, витрины и хранилища
Представьте, что у компании есть доступ к неисчерпаемому информационному ресурсу — погружаясь в него, аналитики регулярно получают ценные бизнес-инсайты и запускают новые, более совершенные продукты. Примерно по такому принципу работают озера данных — data lakes. Это относительно новый вид data-архитектуры, позволяющий воедино собирать сырые и разрозненные сведения из разных источников, а потом находить им эффективное применение. Первыми с технологией начали экспериментировать такие гиганты, как Oracle, Amazon и Microsoft — они же разработали удобные сервисы для построения озер.
Сам термин data lake ввел Джеймс Диксон, основатель платформы Pentaho. Он сравнивал витрины данных с озерами данных: первые похожи на бутилированную воду, которую очистили, отфильтровали и упаковали. Озера — это открытые водоемы, в которые вода стекается из разных источников. В них можно погружаться, а можно брать образцы с поверхности. Существуют еще дата-хранилища, которые выполняют конкретные задачи и служат определенным интересам. Озерные репозитории, напротив, могут принести пользу многим игрокам, если их грамотно использовать.
Казалось бы, потоки сведений только усложняют работу аналитикам, ведь сведения не структурированы, к тому же их слишком много. Но если компания умеет работать с данными и извлекать из них пользу, озеро не превращается в «болото».
Извлекаем данные из «бункера»
И все-таки какую пользу приносят data lakes компаниям? Их главное преимущество — это изобилие. В репозиторий попадают сведения от разных команд и подразделений, которые обычно никак между собой не связаны. Возьмем для примера онлайн-школу. Разные отделы ведут свою статистику и преследуют свои цели — одна команда следит за метриками удержания пользователей, вторая изучает customer journey новых клиентов, а третья собирает информацию о выпускниках. Доступа к полной картине нет ни у кого. Но если аккумулировать разрозненные сведения в едином репозитории, то можно обнаружить интересные закономерности. Например, окажется, что пользователи, которые пришли на курсы дизайна и просмотрели хотя бы два вебинара, чаще других доходят до конца программы и строят успешную карьеру на рынке. Эта информация поможет компании удержать студентов и создать более привлекательный продукт.
Часто неожиданные закономерности обнаруживаются случайно — так, озеро данных помогает дата-аналитикам экспериментально «скрещивать» разные потоки сведений и находить параллели, которые в других обстоятельствах они бы вряд ли обнаружили.
Источники данных могут быть любыми: у онлайн-школы это будет статистика с разных каналов продвижения, у фабрики — показатели IoT-датчиков, график использования станков и показатели износа оборудования, у маркетплейса — сведения о наличии товаров в стоке, статистика продаж и данные о самых популярных платежных методах. Озера как раз помогают собирать и изучать массивы информации, которые обычно никак не пересекаются и попадают в поле внимания разных отделов.
Еще один плюс дата-озер — это извлечение данных из разрозненных репозиториев и закрытых подсистем. Часто сведения хранятся в подобии информационного «бункера», доступ к которому есть только у одного подразделения. Перенести из него материалы сложно или невозможно — слишком много ограничений. Озера эту проблему решают.
Итак, можно выделить как минимум восемь преимуществ озер данных:
Озера в первую очередь нужны распределенным и разветвленным командам. Классический пример — Amazon. Корпорация аккумулировала данные из тысячи разных источников. Так, одни только финансовые транзакции хранились в 25 различных базах, которые были по-разному устроены и организованы. Это создавало путаницу и неудобства. Озеро помогло собрать все материалы в одном месте и установить единую систему защиты данных. Теперь специалисты — дата- и бизнес-аналитики, разработчики и CTO — могли брать нужные им компоненты и обрабатывать их, используя разные инструменты и технологии. А машинное обучение помогло аналитикам Amazon строить сверхточные прогнозы — теперь они знают, сколько коробок определенного размера потребуется для посылок в условном Техасе в ноябре.
Четыре шага к дата-озерам
Но у data lakes есть и недостатки. В первую очередь они требуют дополнительных ресурсов и высокого уровня экспертизы — по-настоящему извлечь из них пользу могут только высококвалифицированные аналитики. Также потребуются дополнительные инструменты Business Intelligence, которые помогут преобразовать инсайты в последовательную стратегию.
Другая проблема — это использование сторонних систем для поддержания data lakes. В этом случае компания зависит от провайдера. Если в системе произойдет сбой или утечка данных, это может привести к крупным финансовым потерям. Однако главная проблема озер — это хайп вокруг технологии. Часто компании внедряют этот формат, следуя моде, но не знают, зачем на самом деле им это нужно. В результате они тратят большие суммы, но не добиваются окупаемости. Поэтому эксперты советуют еще на стадии подготовки к запуску определить, какие бизнес-задачи будут решать озера.
Эксперты McKinsey выделяют четыре стадии создания data lakes:
Алгоритмы-аналитики
В самом аккумулировании данных нет ничего принципиально нового, но благодаря развитию облачных систем, платформ с открытым кодом и в целом увеличению компьютерных мощностей работать с озерной архитектурой сегодня могут даже стартапы.
Еще одним драйвером отрасли стало машинное обучение — технология отчасти упрощает работу аналитиков и дает им больше инструментов для пост-обработки. Если раньше специалист потонул бы в количестве файлов, сводок и таблиц, теперь он может «скормить» их алгоритму и быстрее построить аналитическую модель.
Использование дата-озер в комплексе с ИИ помогает не просто централизованно анализировать статистику, но и отслеживать тренды на протяжении всей истории работы компании. Так, один из американских колледжей собрал сведения об абитуриентах за последние 60 лет. Учитывались данные о количестве новых студентов, а также показатели по трудоустройству и общая экономическая ситуация в стране. В результате вуз скорректировал программу так, чтобы студенты заканчивали учебу, а не бросали курсы на полпути.
Какие еще бизнес-задачи могут решать дата-озера:
Впрочем, озера используют не только в бизнес-среде — например, в начале пандемии AWS собрала в едином репозитории сведения о COVID-19: данные исследований, статьи, статистические сводки. Информацию регулярно обновляли, а доступ к ней предоставили бесплатно — платить нужно было только за инструменты для аналитики.
Data lakes нельзя считать универсальным инструментом и панацеей, но в эпоху, когда данные считаются новой нефтью, компаниям важно искать разные пути исследования и применения big data. Главная задача — это централизация и консолидация разрозненных сведений. В эпоху микросервисов и распределенных команд часто возникают ситуации, когда один отдел не знает, над чем работает другой. Из-за этого бизнес тратит ресурсы, а разные специалисты выполняют одинаковые задачи, часто не подозревая об этом. В конечном итоге это снижает эффективность и перегружает «оперативную систему» компании. Как показывают опросы, большинство компаний инвестирует в озера данных как раз для повышения операционной эффективности. Но результаты превосходят ожидания: у ранних адептов технологии выручка и прибыль растут быстрее, чем у отстающих, а главное, они быстрее выводят на рынок новые продукты и услуги.
Проектирование озера данных с открытым исходным кодом
Проектирование потока данных
Типичный логический поток озера данных включает следующие функциональные блоки:
На этапе приёма сырые данные приходят из одного или нескольких источников данных. Механизм приёма чаще всего реализуется в виде одной или нескольких очередей сообщений с простым компонентом, направленным на первичную очистку и сохранение данных. Для того, чтобы построить эффективное, масштабируемое и целостное озеро данных, рекомендуется различать простую очистку данных и более сложные задачи обогащения данных. Одно из проверенных правил заключается в том, что задачи очистки требуют данных из одного источника в пределах скользящего окна.
Под обогащением данных подразумеваем насыщение данных дополнительной информацией из других источников (это могут быть какие-то справочники, информациях из сторонних сервисов и т.п.). Обогащение данных распространённый процесс, когда следует учесть все возможные аспекты для проведения дальнейшего анализа.
Как пример, удаление дублей, которое ограничено только сравнением ключей от событий, полученных в течение 60 секунд друг от друга из одного и того же источника, будет типичной задачей очистки. С другой стороны, задача слияния данных из нескольких источников данных в течение относительно длительного промежутка времени (например, за последние 24 часа), скорее соответствует фазе обогащения.
После того, как данные приняты и очищены, они сохраняются в распределенной файловой системе (для повышения отказоустойчивости). Часто данные записываются в табличном формате. Когда новая информация записывается в узел хранения, каталог данных, содержащий схему и метаданные, может обновляться с помощью автономного краулера. Запуск краулера обычно запускается событийно, например при поступлении нового объекта в хранилище. Хранилища обычно интегрированы со своими каталогами. Они выгружают базовую схему для того, чтобы к данным можно было обращаться.
Далее данные попадают в специальную область, предназначенную для «золотых данных». С этого момента данные готовы для обогащения другими процессами.
В процессе обогащения данные дополнительно изменяются и очищаются в соответствии с бизнес-логикой. В результате они сохраняются в структурированном формате в хранилище данных или в базе данных, которое используется для быстрого получения информации, аналитики или обучающей модели.
Наконец, использование данных — аналитика и исследования. Именно здесь извлечённая информация преобразуется в бизнес-идеи при помощи визуализации, дашбордов и отчётов. Также эти данные — источник для прогнозирования с помощью машинного обучения, результат которого помогает принимать лучшие решения.
Компоненты платформы
Облачная инфраструктура озёр данных требует надёжного, а в случае гибридных облачных систем ещё и унифицированного уровня абстракции, который поможет развёртывать, координировать и запускать вычислительные задачи без ограничений в API провайдеров.
Kubernetes — отличный инструмент для такой работы. Он позволяет эффективно развёртывать, организовывать и запускать различные сервисы и вычислительные задачи озера данных надёжным и выгодным способом. Он предлагает унифицированный API, который будет работать и локально и в каком-либо публичном или приватном облаке.
Платформу можно условно разделить на несколько слоёв. Базовый слой — это то место, где мы развертываем Kubernetes или его эквивалент. Базовый слой также можно использовать для обработки вычислительных задач вне компетенций озера данных. При использовании облачных провайдеров, перспективно было бы использовать уже наработанные практики облачных поставщиков (ведение журнала и аудит, проектирование минимального доступа, сканирование уязвимостей и отчетность, сетевая архитектура, архитектура IAM и т.д.) Это позволит достичь необходимого уровня безопасности и соответствия другим требованиям.
Над базовым уровнем есть два дополнительных — само озеро данных и уровень вывода значений. Эти два уровня отвечают за основу бизнес-логики, а также за процессы обработки данных. Несмотря на то, что существует множество технологий для этих двух уровней, Kubernetes снова окажется хорошим вариантом из-за его гибкости для поддержки различных вычислительных задач.
Уровень озера данных включает в себя все необходимые сервисы для приёма (Kafka, Kafka Connect), фильтрации, обогащения и переработки (Flink и Spark), управления рабочим процессом (Airflow). Помимо этого, он включает хранилища данных и распределённые файловые системы (HDFS), а также базы данных RDBMS и NoSQL.
Самый верхний уровень — получение значений данных. По сути, это уровень потребления. Он включает в себя такие компоненты, как инструменты визуализации для понимания бизнес-аналитики, инструменты для исследования данных (Jupyter Notebooks). Другим важным процессом, который происходит на этом уровне, является машинное обучение с использованием обучающей выборки из озера данных.
Важно отметить, что неотъемлемой частью каждого озера данных является внедрение распространённых практик DevOps: инфраструктура как код, наблюдаемость, аудит и безопасность. Они играют важную роль в решении повседневных задач и должны применяться на каждом отдельном уровне, чтобы обеспечивать стандартизацию, безопасность и быть удобными в использовании.
Взаимодействие компонентов платформы
Кластер Kafka будет получать неотфильтрованные и необработанные сообщения и будет функционировать как узел приёма в озере данных. Kafka обеспечивает высокую пропускную способность сообщений надёжным способом. Кластер обычно содержит несколько разделов для сырых данных, обработанных (для потоковой обработки) и недоставленных или искажённых данных.
Flink принимает сообщение из узла c необработанными данных от Kafka, фильтрует данные и делает, при необходимости, предварительное обогащение. Затем данные передаются обратно в Kafka (в отдельный раздел для отфильтрованных и обогащенных данных). В случае сбоя, или при изменении бизнес-логики, эти сообщения можно будет вызвать повторно, т.к. что они сохраняются в Kafka. Это распространенное решение для в потоковых процессов. Между тем, Flink записывает все неправильно сформированные сообщения в другой раздел для дальнейшего анализа.
Используя Kafka Connect получаем возможность сохранять данные в требуемые бекенды хранилищ данных (вроде золотой зоны в HDFS). Kafka Connect легко масштабируется и поможет быстро увеличить количество параллельных процессов, увеличив пропускную способность при большой загрузке:
При записи из Kafka Connect в HDFS рекомендуется выполнять разбиение контента для эффективности обращения с данными (чем меньше данных для сканирования тем меньше запросов и ответов). После того, как данные были записаны в HDFS, serverless функциональность (вроде OpenWhisk или Knative) будет периодически обновлять хранилище метаданных и параметров схемы. В результате, к обновленной схеме становится возможно обращаться через SQL-подобный интерфейс (например, Hive или Presto).
Для последующего data-flows и управления ETL-процессом можно использовать Apache Airflow. Он позволяет пользователям запускать многоступенчатые pipline обработки данных с использованием Python и объектов типа Directed Acyclic Graph (DAG). Пользователь может задавать зависимости, программировать сложные процессы и отслеживать выполнение задач через графический интерфейс. Apache Airflow также может служить для обработки всех внешних данных. Например, для получения данных через внешний API и сохранения их в постоянном хранилище.
Spark под управлением Apache Airflow через специальный плагин, может периодически обогащать сырые отфильтрованные данные в соответствии с бизнес-задачами, и подготавливать данные для исследования специалистами по данным, и бизнес-аналитикам. Специалисты по данным могут использовать JupyterHub для управления несколькими Jupyter Notebook. Поэтому стоит воспользоваться Spark для настройки многопользовательских интерфейсов для работы с данными, их сбором и анализом.
Для машинного обучения можно воспользоваться фреймворками, вроде Kubeflow, используя возможность масштабируемости Kubernetes. Получившиеся модели обучения могут быть возвращены в систему.
Если сложить паззл воедино, мы получим что-то вроде этого:
Операционное совершенство
Мы уже говорили, что принципы DevOps и DevSecOps являются важными компонентами любого озера данных и никогда не должны упускаться из виду. С большой властью приходит большая ответственность, особенно когда все структурированные и неструктурированные данные о вашем бизнесе находятся в одном месте.
Основные принципы будут следующими:
Один из рекомендуемых методов — разрешить доступ только для определённых сервисов, распределив соответствующие права, и запретить прямой доступ пользователей, чтобы пользователи не смогли изменить данные (это касается и команды). Также для защиты данных важен полный мониторинг при помощи фиксации действий в журнал.
Шифрование данных — ещё один механизм для защиты данных. Шифрование хранимых данных может производиться при помощи системы управления ключами (KMS). Это зашифрует вашу систему хранения и текущее состояние. В свою очередь, шифрование при передаче может производиться при помощи сертификатов для всех интерфейсов и эндпоинтов сервисов вроде Kafka и ElasticSearch.
А в случае систем поиска, которые могут не соответствуют политике безопасности, лучше отдавать предпочтение serverless-решениям. Необходимо также отказаться от ручных деплоев, ситуативных изменений в любом компоненте озера данных; каждое изменение должно приходить из системы контроля версий и проходить серию CI-тестов перед развертыванием на продуктовое озеро данных (smoke-тестирование, регрессия, и т. д.).
Нужно ли нам озеро данных? А что делать с хранилищем данных?
Это статья перевод моей статьи на medium — Getting Started with Data Lake, которая оказалась довольно популярной, наверное из-за своей простоты. Поэтому я решил написать ее на русском языке и немного дополнить, чтобы простому человеку, который не является специалистом по работе с данными стало понятно, что такое хранилище данных (DW), а что такое озеро данных (Data Lake), и как они вместе уживаются.
Почему я захотел написать про озеро данных? Я работаю с данными и аналитикой больше 10 лет, и сейчас я точно работаю с большими данными в Amazon Alexa AI в Кембридже, который в Бостоне, хотя сам живу в Виктории на острове Ванкувер и часто бываю и в Бостоне, и в Сиэтле, и в Ванкувере, а иногда даже и в Москве выступаю на конференциях. Так же время от времени я пишу, но пишу в основном на английском, и написал уже несколько книг, так же у меня есть потребность делиться трендами аналитики из Северной Америке, и я иногда пишу в телеграмм.
Я всегда работал с хранилищами данных, и с 2015 года стал плотно работать с Amazon Web Services, да и вообще переключился на облачную аналитику (AWS, Azure, GCP). Я наблюдал эволюцию решений для аналитики с 2007 года и сам даже поработал в вендоре хранилищ данных Терадата и внедрял ее в Сбербанке, тогда-то и появилась Big Data с Hadoop. Все стали говорить, что прошла эра хранилищ и теперь все на Hadoop, а потом уже стали говорить про Data Lake, опять же, что теперь уж точно хранилищу данных пришел конец. Но к счастью (может для кого и к несчастью, кто зарабатывал много денег на настройке Hadoop), хранилище данных не ушло.
В этой статье мы и рассмотрим, что такое озеро данных. Статья рассчитана на людей, у которых мало опыта с хранилищами данными или вовсе нет.
На картинке озеро Блед, это одно из моих любимых озер, хотя я там был всего один раз, но запомнил его на всю жизнь. Но мы поговорим о другом типе озера — озеро данных. Возможно многие из вас уже не раз слышали про это этот термин, но еще одно определение никому не повредит.
Прежде всего вот самые популярные определения Озера Данных:
«файловое хранилище всех типов сырых данных, которые доступны для анализа кем-угодно в организации» — Мартин Фовлер.
«Если вы думаете, что витрина данных это бутылка воды — очищенной, запакованной и расфасованной для удобного употребления, то озеро данных это у нас огромный резервуар с водой в ее естественном виде. Пользователи, могу набирать воды для себя, нырять на глубину, исследовать» — Джеймс Диксон.
Теперь мы точно знаем, что озеро данных это про аналитику, оно позволяет нам хранить большие объемы данных в их первоначальной форме и у нас есть необходимый и удобный доступ к данным.
Я часто люблю упрощать вещи, если я могу рассказать сложный термин простыми словами, значит для себя я понял, как это работает и для чего это нужно. Как то, я ковырялся в iPhone в фотогалерее, и меня осенило, так это же настоящее озеро данных, я даже сделал слайд для конференций:
Все очень просто. Мы делаем фотографию на телефон, фотография сохраняется на телефон и может быть сохранено в iCloud (файловое хранилище в облаке). Также телефон собирает мета-данные фотографии: что изображено, гео метка, время. Как результат, мы может использовать удобный интерфейс iPhone, чтобы найти нашу фотографию и при этому мы даже видим показатели, например, когда я ищу фотографии со словом огонь (fire), то я нахожу 3 фотографии с изображение костра. Для меня это прям как Business Intelligence инструмент, который работает очень быстро и четко.
И конечно, нам нельзя забывать про безопасность (авторизацию и аутентификацию), иначе наши данных, могут легко попасть в открытый доступ. Очень много новостей, про крупные корпорации и стартапы, у которых данные попали в открытый доступ из-за халатности разработчиков и не соблюдения простых правил.
Даже такая простая картинка, помогает нам представить, что такое озеро данных, его отличия от традиционного хранилища данных и его основные элементы:
С другой стороны, вендор Snowflake заявляет, что вам больше не нужно думать про озеро данных, так как их платформа данных (до 2020 это было хранилище данных), позволяет вам совместить и озеро данных и хранилище данных. Я работал не много со Snowflake, и это действительно уникальный продукт, который может так делать. Конечно Snowflake стоит денег, но у крупных компаний на западе серьезные бюджеты на аналитику.
В заключении, мое личное мнение, что нам все еще нужно хранилище данных как основной источник данных для нашей отчетности, и все, что не помещается, мы храним в озере данных. Вся роль аналитики — это предоставить удобный доступ бизнесу для принятия решений. Как ни крути, но бизнес пользователи работаю эффективней с хранилищем данных, чем озером данных, например в Amazon — есть Redshift (аналитическое хранилище данных) и есть Redshift Spectrum/Athena (SQL интерфейс для озера данных в S3 на базе Hive/Presto). Тоже самое относится к другим современным аналитическим хранилищам данных.
Давайте рассмотрим типичную архитектура хранилища данных:
Это классическое решение. У нас есть системы источники, с помощью ETL/ELT мы копируем данные в аналитическое хранилище данных и подключаем к Business Intelligence решению (мое любимое Tableau, а ваше?).
Такое решение имеет следующие недостатки:
Цель любого аналитического решения — служить бизнес пользователям. Поэтому мы всегда должны работать от требований бизнеса. (В Амазон это один из принципов — working backwards).
Работая и с хранилищем данных и с озером данных, мы можем сравнить оба решения:
Главный вывод, который можно сделать, что хранилище данных, никак не соревнуется с озером данных, а больше дополняет. Но это вам решать, что подходит для вашего случая. Всегда интересно, попробовать самому, и сделать правильные выводы.
Я хотел бы также рассказать по один из кейсов, когда я стал использовать подход озера данных. Все довольно банально, я попытался использовать инструмент ELT (у нас был Matillion ETL) и Amazon Redshift, мое решение работала, но не укладывалось в требования.
Мне необходимо было взять веб логи, трансформировать их и агрегировать, чтобы предоставить данные для 2х кейсов:
Один файл весил 1-4 мегабайта.
Но была одна трудность. У нас было 7 доменов по всему миру, и за один день создавалось 7 тысяч файлов. Это не очень больше объем, всего 50 гигабайт. Но размер нашего кластера Redshift был тоже небольшим (4 ноды). Загрузка традиционным способом одного файла занимала около минуты. То есть, в лоб задача не решалась. И это был тот случай, когда я решил использовать подход озера данных. Решение выглядело примерно так:
Оно достаточно простое (я хочу заметить, что преимущество работы в облаке это простота). Я использовал:
Совсем недавно я узнал один из недостатков озера данных — это GDPR. Проблема в том, когда клиент просит его удалить, а данные находятся в одном из файлов, мы не можем использовать Data Manipulation Language и операцию DELETE как в базе данных.
Надеюсь, статья прояснила разнице между хранилищем данных и озером данных. Если было интересно, то могу перевести еще свои статьи или статье профессионалов, которых читаю. А также рассказать про решения, с которыми работаю, и их архитектуру.