Джеймс диксон озеро данных

Нужно ли нам озеро данных? А что делать с хранилищем данных?

Это статья перевод моей статьи на 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 инструмент, который работает очень быстро и четко.

И конечно, нам нельзя забывать про безопасность (авторизацию и аутентификацию), иначе наши данных, могут легко попасть в открытый доступ. Очень много новостей, про крупные корпорации и стартапы, у которых данные попали в открытый доступ из-за халатности разработчиков и не соблюдения простых правил.

Даже такая простая картинка, помогает нам представить, что такое озеро данных, его отличия от традиционного хранилища данных и его основные элементы:

  1. Загрузка данных (Ingestion) — ключевой компонент озера данных. Данные могут попадать в хранилище данных двумя способами — batch (загрузка с интервалами) и streaming (поток данных).
  2. Файловое хранилище (Storage) — главный компонент Озера Данных. Нам необходимо, что хранилище было легко масштабируемое, чрезвычайно надежное и обладало низкой стоимостью. Например, в AWS это S3.
  3. Каталог и Поиск (Catalog and Search) — для того чтобы нам избежать Болота Данных (это когда мы сваливаем все данные в одну кучу, и потом невозможно с ними работать), нам необходимо создать слой мета-данных для классификации данных, чтобы пользователи легко могли найти данные, которые им необходимы для анализа. Дополнительно, можно использовать дополнительные решения для поиска, например ElasticSearch. Поиск помогает пользователю искать нужные данные через удобные интерфейс.
  4. Обработка (Process) — это шаг отвечает за обработку и трансформацию данных. Мы можем трансформировать данные, изменять их структуры, очищать и много другое.
  5. Безопасность (Security) — важно потратить время на дизайн безопасности решения. Например, шифрование данных во время хранения, обработки и загрузки. Важно использовать методы аутентификации и авторизации. В заключение, нужен инструмент аудита.
Читайте также:  Поселок санатория озеро белого

С практической точки зрения, мы можем характеризовать озеро данных тремя атрибутами:

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

Теперь можно поговорить о разнице между хранилищем данных и озером данных. Обычно люди спрашивают:

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

Если кратко, то четкого ответа нет. Все зависит от конкретной ситуации, навыков в команде и бюджета. Например миграция хранилища данных на Oracle в AWS и создание озера данных дочерней компанией Амазон — Woot — Our data lake story: How Woot.com built a serverless data lake on AWS.

С другой стороны, вендор Snowflake заявляет, что вам больше не нужно думать про озеро данных, так как их платформа данных (до 2020 это было хранилище данных), позволяет вам совместить и озеро данных и хранилище данных. Я работал не много со Snowflake, и это действительно уникальный продукт, который может так делать. Конечно Snowflake стоит денег, но у крупных компаний на западе серьезные бюджеты на аналитику.

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

Давайте рассмотрим типичную архитектура хранилища данных:

Это классическое решение. У нас есть системы источники, с помощью ETL/ELT мы копируем данные в аналитическое хранилище данных и подключаем к Business Intelligence решению (мое любимое Tableau, а ваше?).

Такое решение имеет следующие недостатки:

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

Конечно, все зависит от ваше кейса. Если у вас нет проблем с вашим хранилищем данных, то вам совершенно не нужно озеро данных. Но когда появляются проблемы с нехваткой места, мощности или цена вопроса имеет ключевую роль, то можно рассмотреть вариант озера данных. Именно поэтому, озеро данных очень популярно. Вот пример архитектуры озера данных:

Используя подход озера данных, мы загружаем сырые данные в наше озеро данных (batch или streaming), далее мы обрабатываем данные по необходимости. Озеро данных позволяет бизнес пользователям создавать свои собственные трансформации данных (ETL/ELT) или анализировать данные в решениях Business Intelligence (если есть нужный драйвер).

Цель любого аналитического решения — служить бизнес пользователям. Поэтому мы всегда должны работать от требований бизнеса. (В Амазон это один из принципов — working backwards).

Работая и с хранилищем данных и с озером данных, мы можем сравнить оба решения:

Главный вывод, который можно сделать, что хранилище данных, никак не соревнуется с озером данных, а больше дополняет. Но это вам решать, что подходит для вашего случая. Всегда интересно, попробовать самому, и сделать правильные выводы.

Я хотел бы также рассказать по один из кейсов, когда я стал использовать подход озера данных. Все довольно банально, я попытался использовать инструмент ELT (у нас был Matillion ETL) и Amazon Redshift, мое решение работала, но не укладывалось в требования.

Мне необходимо было взять веб логи, трансформировать их и агрегировать, чтобы предоставить данные для 2х кейсов:

  1. Команда маркетинга хотела анализировать активность ботов для SEO
  2. IT хотело смотреть метрики по работе сайтов

Очень простой, очень простые логи. Вот пример:

Читайте также:  Что будет с озером курочкино

Один файл весил 1-4 мегабайта.

Но была одна трудность. У нас было 7 доменов по всему миру, и за один день создавалось 7 тысяч файлов. Это не очень больше объем, всего 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. Проблема в том, когда клиент просит его удалить, а данные находятся в одном из файлов, мы не можем использовать Data Manipulation Language и операцию DELETE как в базе данных.

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

Источник

Customer Data Lake: как управлять данными в эпоху перемен

Конкуренция на фармрынке все жестче, а клиенты избалованы обилием брендов разных ценовых категорий и цифровым доступом к информации. При этом традиционные методы повышения лояльности в фармацевтике не работают.

Как фармкомпаниям в таких условиях привлекать аудиторию и выстраивать долгосрочные отношения с врачами и первостольниками? И причем здесь «озеро данных»? Обо всем этом рассказывает коммерческий директор компании Navicon Евгений Смирнов.

Почему вам стоит знать о клиентах больше?

— Для продвижения продукции фармкомпании работают с разными категориями клиентов. Среди них — аптеки, лечебно-профилактические учреждения, врачи и провизоры.

Несмотря на то что это разные целевые аудитории, между ними есть кое-что общее. Когда дело касается взаимодействия компании с докторами и фармацевтами, одного канала коммуникации уже недостаточно. Привычный формат продвижения — визит медицинских представителей — не работает одинаково со всеми категориями. Сегодня люди получают информацию из множества дистанционных источников: социальные сети, SMS, мессенджеры, онлайн-лекции. Каждый из них можно задействовать для продвижения фармпродукции.

Но все не так просто, как кажется на первый взгляд. Фармкомпании, которые задумались о том, как справиться с продвижением в многоканальной среде, наверняка столкнулись с множеством вопросов. Как распределить сообщения и нужно ли создавать уникальный контент для каждого из каналов сообщения? Где взять полную и достоверную информацию о том, как та или иная аудитория предпочитает получать информацию? Как классифицировать клиентов и понять интересы и предпочтения каждой из групп?

Омниканальность: новая панацея или реально работающий инструмент?

— В ответ на эти и другие вопросы на рынке появился новый формат продвижения продукции — омниканальный маркетинг. В фармацевтике он предполагает «осознанное» взаимодействие с врачами, фармацевтами и даже пациентами: разработку целостной стратегии продвижения, включающей сегментацию аудитории по различным критериям. Например, можно определить чувствительность аудитории к одному из каналов коммуникации, а затем на основании этих данных создать для каждого сегмента подробный план общения и набора целевых промо-кампаний.

Тем не менее остается вопрос: как эффективно собирать, обрабатывать, оптимизировать и, главное, начать использовать весь этот поток данных? Ведь для того, чтобы омниканальный маркетинг «заработал», необходимо преобразовать информацию о клиентах в одну целостную и мощную контентную стратегию, подходящую для разных типов потребителей. К примеру, посмотрите на корпорацию Amazon. Аналитики и маркетологи ритейл-гиганта практически знают каждого покупателя «в лицо»: что он предпочитает есть на завтрак, где расплачивается картой и сколько зарабатывает его семья. Все это нужно, чтобы обеспечить ему максимально персонализированный, точный и удовлетворяющий потребностям customer experience. В основе их маркетинговой модели, которая и позволяет «большому брату» ежедневно улучшать выдачу рекомендаций сразу по нескольким каналам коммуникаций, лежит огромная централизованная база данных. Именно владение и управление множеством данных о состоянии финансов, предпочтениях и положении клиента, в конечном счете, помогает влиять на его выбор.

Однако фармкомпании долго время не могли прийти к этой константе — каналы коммуникации хоть и использовались активно, но были разрознены, информация, хранящаяся в локальных БД, дублировалась, сообщения клиентам — тоже, а значит ценность работы с ними была минимальна. Кроме того, многие фармпроизводители рассматривали клиента только через призму взаимодействия с ним: как он отреагировал на прошлый визит, сколько лекарств выписал, сколько готов выписывать. Но этой информации было недостаточно.

Читайте также:  Закат над озером летом

Врач — это больше чем покупка или выписка рецепта. Это уникальный человек, который ежедневно получает информацию из разных каналов и оставляет в сети цифровой «след». Всю доступную информацию о его склонностях и поведении в сети можно собирать и формировать из нее «личный профиль» каждого конкретного клиента. Более того, медицинские работники хотят получать от фармкомпаний актуальную и своевременную информацию, полезную для них и их пациентов. Поэтому фарммаркетологи должны быть в курсе отраслевых и медицинских новостей, отлеживать результаты последних исследований рынка, понимать тренды и перспективы.

Сбор всей этой информации позволит при планировании рекламной кампании иметь угол обзора 360 о и не пропустить ничего важного — данные станут основой для создания централизованной БД, которая обеспечит единое представление о каждом клиенте по всем каналам. Однако агрегированные данные наверняка будут очень разными и неструктурированными. Для их хранения необходим специальный «контейнер» — Data Lake.

Data Lake: чем больше «озеро», тем лучше

— Впервые о термине Data Lake заговорили еще в 2010 году. Основатель Pentaho Джеймс Диксон сформулировал концепцию «озера»: «Если вы рассматриваете Data Mart (витрину данных — прим. авт.) как хранилище бутилированной воды, очищенной, упакованной и структурированной для удобства потребления, то Data Lake (озеро данных — прим. авт.) представляет собой большой массив воды в естественном состоянии. Содержимое поступает туда из источников, и пользователи могут погрузиться в озеро, взять образцы и исследовать их». Идея быстро набрала популярность: к следующему году, по прогнозу Markets and Markets, рынок Data Lakes достигнет почти 9 млрд долл. США.

Такое хранилище действительно напоминает озеро: в него поступают самые разные данные в их первоначальном формате, структурированные, слабоструктурированные и неструктурированные. В отличие от иерархических систем, которые хранят информацию в файлах, папках или таблицах, для построения Data Lake используется плоская архитектура. Когда пользователь помещает в озеро новый элемент, ему назначается уникальный идентификатор, после чего он располагается на своей «полке».

Из каких источников-«притоков» фармкомпания может сформировать собственное озеро данных?

  • CRM-система, в которой содержится база клиентов и информация обо всех взаимодействиях с ними.
  • DMP (Data Management Platform) как источники информации о поведении аудитории в интернете.
  • SocialMedia — обогащение профиля клиента через информацию о его поведении в соцсетях и мессенджерах.
  • Профессиональные сообщества — для работы с врачами и первостольниками.
  • Рекламные площадки — для размещения в Data Lake информации о доставленных до клиента рекламных сообщениях через digital-каналы.
  • Собственные ресурсы фармкомпании: PSP, образовательные проекты, полезные порталы.
  • Аптеки: информацию о покупках можно получить, например, по результатам промо-акций или из чековой аналитики, а в перспективе после повсеместного внедрения маркировки — из Track&Trace систем.

Чем больше данных об аудитории удастся собрать в едином хранилище, тем проще будет построить с ней омниканальное взаимодействие.

Обзор на 360 градусов

— После формирования озера данных можно начинать формировать в компании инновационный подход к взаимодействию с клиентом — Customer 360 о , подразумевающий подготовку индивидуальной стратегии коммуникаций с каждым конкретным потребителем на основании собранной о нем информации. В таком случае план омниканального взаимодействия будет примерно следующим:

  1. В Data Lake собираются все типы данных, которые может получить фармкомпания: информация из социальных сетей, профессиональных сообществ, PSP, тематических сайтов, результаты звонков и рассылок через e-mail или SMS, сведения о покупках.
  2. BI-специалисты, бренд-менеджеры, маркетологи, Data Scientist фармкомпании используют ИТ-инструменты, чтобы на основе полученной информации провести сегментацию аудитории, сформировать индивидуальные сообщения, распределить маркетинговый бюджет на каждый канал коммуникаций.
  3. Сообщения передаются каждому сегменту аудитории по наиболее подходящим каналам.
  4. После завершения кампании результаты по каждому каналу собираются в «озере данных» и используются специалистами для планирования следующих взаимодействий с клиентами.

Этот цикл может повторяться сколько угодно. При этом он с каждым разом будет становиться все совершеннее благодаря инсайтам. Их можно извлекать из каждой рекламной кампании благодаря инновационным инструментам, таким как машинное обучение, с которыми работают решения для омниканального маркетинга.

Хранить нельзя использовать

— Конечно, и в этом подходе не без ложки дегтя. Его основная проблема в доступности данных и технологий. Слабая технологическая составляющая проекта по переходу к омниканальности может привести к росту его сложности, задержке реализации и как итог к разочарованию маркетологов. Поэтому крайне важно выделять достаточное время для тщательной оценки потребностей и возможностей фармкомпании в части данных и технологий.

С другой стороны, преобразование данных о клиентах в работающие инструменты омниканальной коммуникации может серьезно стимулировать рост фармбизнеса. Исторически фармацевтические компании контролировали распространение информации о своей продукции, но цифровые технологии ослабили это преимущество, открыв для клиентов множество новых независимых информационных каналов. И чтобы не выпасть из конкурентной гонки, компании должны создавать новые возможности для реагирования на эти новые источники данных и оставаться основным источником самых полезных и релевантных данных о своей продукции, который доступен потребителю в любое время, в любом месте и по любому каналу.

Источник

Поделиться с друзьями
Байкал24