Подписаться
Читать в телеграм
«Хайп прошел, пора строить». Data Lake выпуска 2021 г.
Дата публикации:
07.09.2021
Посетителей:
1056
Просмотров:
1083
Время просмотра:
2.3
Когда озеро данных становится болотом?
Что выбрать: Open Source или вендорские решения?
Почему локальные озера данных в России популярнее облачных?
— Что такое «озеро данных» и как термин эволюционировал за последние годы?
Максим Серпухов: С момента своего появления термин не изменился, он стал понятнее. Озеро данных — система, которая позволяет быстро собирать и хранить информацию, не углубляясь в ее структуру и природу. То есть, когда нужно оперативно собрать и положить куда-то данные, делают озеро. В плане технологий это почти всегда Hadoop.
— Почему в 2021 г. мы снова говорим об озерах данных? Казалось, весь хайп прошел, их все обсудили и почти все построили.
Дмитрий Кулагин: Возможно, сейчас про озера говорят реже, потому что им на смену пришел новый термин — «платформа данных». Он более модный, но суть не меняется: в обоих случаях данные поступают практически в неизменном (сыром) виде, но, в отличие от классического озера, платформа данных включает компоненты концепции Data Governance.
Максим Серпухов: Да, несколько лет назад об озерах данных говорили все, сейчас пик хайпа и завышенных ожиданий прошел. Мы готовимся к выходу на плато продуктивности. Пора строить озера, а не говорить о них.
— Что озера данных дают бизнесу?
Максим Серпухов: Это эволюция процесса сбора информации. Как показывает наш опыт, обычно заказчики задумываются о создании озера после реализации небольшого хранилища данных. Если придерживаться того же вектора и следом строить хранилище побольше, нужно сначала ответить на вопрос: зачем оно нам? Необходимо сразу определиться, какую информацию предстоит собирать, какие источники подключать, как данные будут трансформироваться. Это длительный цикл, проект растянется. У озера другая концепция. Заказчик решает, из каких источников нужно собирать информацию, а система позволяет быстро это сделать. После этого пользователи выбирают из общей массы те данные, которые принесут прибыль бизнесу. Этот подход быстрее и устойчивее к изменениям. Даже если задачи бизнеса изменятся, данные всегда будут доступны.
— Кто в России лидирует по строительству и использованию озер данных?
Максим Серпухов: Финансы, ритейл, производство.
Дмитрий Кулагин: На самом деле это вопрос с подвохом, потому что озера находятся в процессе постоянного изменения. Мы сейчас регулярно сталкиваемся с запросами по модернизации и выводу на корпоративный уровень озер данных, построенных на пике хайпа. Тогда не все понимали, как их правильно создавать, и в результате data lake превращались в болота. То есть формально у компании есть озеро, она в лидерах по строительству, но на самом деле это трясина, в которой невозможно разобраться.
— Как сейчас строят озера данных с технологической точки зрения?
Максим Серпухов: Озеро состоит из трех ключевых составляющих. Первая — система хранения данных. Здесь можно использовать как Open Source, так и вендорские решения. Вторая — механизмы наполнения. Для быстро изменяющейся информации обычно используют технологии, близкие к шинам данных. Например, Apache Kafka. Для загрузки с интервалами подойдут ETL-средства, которые работают с компонентами озера: HDFS, Hive, Hbase. Третья составляющая — механизмы работы с загруженными данными. Библиотеки Python, SQL-запросы, разные специализированные решения — у дата-сайентистов большой выбор.
Дмитрий Кулагин: Выбор технологий зависит от того, как будут использоваться собранные данные. Никто не запрещает строить озеро на решениях Oracle, IBM или SAP, главное — придерживаться выбранного подхода к работе с информацией. На Западе есть кейсы, когда озеро на несколько петабайтов строят на платформе Vertica. При этом в теории ее основное назначение — аналитическая работа.
«Озеро позволяет объединить информацию в неизменном виде из всех внутренних источников компании и дополнить ее данными из внешних сервисов. Так как озера данных постоянно расширяются, к ним подключают все новые системы. Крайне важно на первоначальном этапе заложить все основные механизмы озера».
ДМИТРИЙ КУЛАГИН
— С чего начать компании, которая планирует построить озеро данных?
Максим Серпухов: Единого подхода нет. Я бы рекомендовал начать с вопроса: какие данные нам могут понадобиться? Когда будет ответ, станут понятны примерные контуры озера, требования по объему, быстродействию и нюансам загрузки информации. Этого достаточно, чтобы начать строить. Дальше нужно разбираться, что вы будете делать с данными и кто их потенциальные потребители.
Дмитрий Кулагин: На мой взгляд, «Какие данные нам могут понадобиться?» — это второй вопрос, который должен задать себе бизнес. Первый: зачем нам нужно озеро? Проект взлетит, только если компания заинтересована в работе с данными, извлечении из них дополнительных знаний.
— А если через 5–7 лет компания захочет собирать дополнительные данные из новых источников?
Максим Серпухов: Одно из преимуществ Hadoop — широкая горизонтальная масштабируемость. Если через пять лет бизнес поймет, что ему нужно в 50 раз больше данных, можно будет нарастить мощности без серьезных изменений в архитектуре системы.
— Локальное или облачное озеро? И как при этом меняются CAPEX и OPEX?
Максим Серпухов: В ритейле и финансах облака для озер неприменимы в силу российских законов, менталитета и ряда других мелких факторов. При этом возможности горизонтального масштабирования, о которых я говорил, в полной мере раскрываются именно в облачных решениях. К тому же все хотят, чтобы данные хранились в компании и бизнес не задумывался над вопросом «А что, если…?». В промышленности перспективы у облаков лучше, но пока заказчики склоняются к варианту on-premise.
Дмитрий Кулагин: Если вам нужно распределить затраты между CAPEX и OPEX, не обязательно загонять себя в облако. Есть подходы, которые позволяют переводить затраты в OPEX, даже если вы используете локальное озеро. Так, некоторые программно-аппаратные комплексы и лицензии популярных продуктов, например Cloudera и Arenadata Hadoop, поставляются по подписке. В большинстве случаев CAPEX-затраты — это закупка оборудования и работы по внедрению. Софт же, как правило, идет в OPEX.
Задачи обеспечения безопасности и администрирования озера данных, как правило, лежат на одном сотруднике. Либо ими занимаются несколько человек по мере необходимости, без разделения обязанностей.
— Как вы относитесь к решениям с открытым кодом?
Максим Серпухов: Когда компания не понимает, какие задачи ей нужно решать, какие данные и в каком объеме собирать, Open Source будет хорошим вариантом. У Arenadata Hadoop и Cloudera есть Community Edition, на основе которого можно собрать прототип системы. Если в ходе эксплуатации придет понимание того, что озеро необходимо использовать в промышленном масштабе, можно либо перейти на вендорские решения, либо продолжать своими силами развивать Open Source. Переход, кстати, будет практически незаметным, поскольку в основе всех продуктов лежат одни и те же технологии.
Дмитрий Кулагин: Основная проблема Open Source — отсутствие официальной поддержки. Для промышленной эксплуатации, где предъявляются высокие требования к работоспособности системы, такие решения не подойдут. Придется либо нанять стороннюю компанию, которая будет развивать и поддерживать Open Source, либо набирать собственных специалистов. Это нелогично и слишком рискованно. Open Source хорош на этапе прототипов, MVP или Proof of Concept. В боевых условиях мы все же рекомендуем решения вендоров, которые гарантируют работоспособность всех компонентов собственных сборок Hadoop.
— Как правильно интегрировать озеро данных с системами компании?
Дмитрий Кулагин: Источники данных очень чувствительны к подключению внешних систем. Забирая данные для озера, мы оказываем на них дополнительную нагрузку. Чтобы ее минимизировать, необходимо использовать либо имеющиеся точки интеграции, либо различные CDC-инструменты. Еще один важный момент: мы никогда не подключаемся напрямую к промышленным системам, если у них есть stand by.
— Кадровый вопрос: для строительства и эксплуатации озера понадобятся отдельные специалисты? Где их найти?
Максим Серпухов: Озеро — это большой стек технологий, поэтому здесь нужно либо много специалистов, либо несколько, но с широким спектром навыков. И тут возникает вопрос: всегда ли эти сотрудники будут достаточно загружены? Содержание полного штата специалистов обойдется дорого, поэтому подобные задачи чаще отдают на аутсорсинг.
Дмитрий Кулагин: Нужно разграничивать эксплуатацию и использование озера. Использование — задача бизнеса: как он планирует работать с собранными данными. Скорее всего, эти задачи будут решаться средствами ML c привлечением Data Scientists, которые очень дороги на рынке. Эксплуатация — техническая задача. В озерах используется много разных технологий, редкий специалист знает сразу все. Поэтому вариант аутсорсинга популярен в обеих задачах.
Озеро данных для «Россельхозбанка»
Задача
Озеро данных потребовалось «Россельхозбанку» для работы с профилями клиентов: сбора и обработки информации, оценки эффективности индивидуальных предложений и маркетинговых кампаний в целом. К системе должны были подключаться несколько десятков бизнес-пользователей с разными задачами.
Специалистам компании «Инфосистемы Джет» нужно было не только создать озеро и организовать процесс его наполнения, но и интегрировать решение с ИТ-системами банка, включая системы информационной безопасности.
Решение
Примеры систем-источников:
- процессинговая система;
- CRM;
- системы, организующие продажи в цифровых каналах;
- MDM-система (Master Data Management);
- чат-бот (переписка клиентов с банком).
В основе озера лежат платформы Cloudera Data Platform и Informatica Data Engineering Integration.
Результат
За 3 месяца специалисты компании «Инфосистемы Джет» создали MVP, с помощью которого сотрудники банка начали собирать и анализировать информацию о клиентах. Первый этап проекта завершен. На сегодня к озеру подключены 18 источников данных, из которых в data lake ежедневно заполняется около 10 000 таблиц.
Roadmap проекта расписан до конца 2022 г., сейчас к системе подключают новые источники и реализуют новые бизнес-задачи.
Андрей Серов
ведущий инженер-проектировщик Центра информационной безопасности компании «Инфосистемы Джет»
Комментарий
Как обеспечить информационную безопасность озера
Есть несколько факторов, которые негативно влияют на уровень защищенности data lake в российских компаниях.
При самостоятельной инсталляции системы заказчик порой не до конца прорабатывает вопросы ИБ. Большинство сервисов озера данных на уровне как приложения, так и инфраструктуры настраиваются «по умолчанию». Это означает, что можно получить любую информацию из озера, авторизовавшись под известным пользователем из общедоступной документации вендора.
Сотрудники, ответственные за безопасность и администрирование озера данных, не всегда понимают, какие данные загружаются из тех или иных источников и кому может быть предоставлен доступ к ним. А это могут быть данные, представляющие коммерческую тайну или защищаемые законодательством РФ.
В ряде случаев процессы ИБ (например, мониторинг и аудит действий) не могут быть реализованы без использования специального инструментария. Это обусловлено значительными объемами и разнородностью данных, которые необходимо анализировать. Отсутствие средств защиты и трудоемкость выполнения необходимых действий вручную приводят к тому, что озеро данных оказывается вне ИБ-периметра.
Первое, что мы рекомендуем сделать для обеспечения безопасности экосистемы озера данных, — провести экспертное обследование. Его цель — определить недостатки механизмов обеспечения ИБ, а также сформировать организационные и технические рекомендации по совершенствованию этой системы.
Если мы строим data lake с «чистого листа», то анализируем все источники и витрины данных на предмет наличия чувствительных данных. Результатом такого анализа является комплексный подход к построению архитектуры озера данных с учетом реализации мер безопасности и его интеграции с ИБ-инструментами заказчика.
Безопасность озера данных может быть реализована встроенными и наложенными средствами. Встроенные средства обеспечения ИБ платформы Hadoop:
Наложенные средства ИБ — это, как правило, существующие у заказчика ИБ-инструменты. Это могут быть решения для контроля администраторов (PAM), мониторинга БД (DAM), защиты каналов связи (GOST), средства управления уязвимостями (VM), защиты веб-ресурсов (WAF), антивирусы (AVP), контроль целостности (IC), защита виртуальных сред (VSec) и др.
Если в компании зрелая инфраструктура безопасности, мы анализируем возможность интеграции этих ИБ-инструментов со средствами ИБ озера данных. Например, реализуем сбор и отправку журналов аутентификации и доступа в SIEM заказчика.
Одна из трудностей обеспечения безопасности data lake — большое число подключенных и подключаемых источников и витрин данных разных типов. Каждому из них необходимо обеспечить безопасный механизм обмена данными с озером.
Кроме того, периодически нужно интегрировать аутентификацию сервисов озера данных с IdM на уровне ОС платформы. Сложность заключается в том, что разные средства аутентификации озера (Kerberos c KDC AD) могут быть совместимы только в случае доступности нужных библиотек в ОС. Собственно, в проблеме заключено решение: мы находим такие библиотеки.