© 1995-2021 Компания «Инфосистемы Джет»
Как не превратить ваши данные в Data Lake в разрозненное болото
Big Data

Практика говорит: все больше и больше заказчиков приходит с идей построить единое хранилище, да еще на новых технологиях.

Big Data Тема номера

Как не утопить ваши данные в болоте

19.09.2019

Посетителей: 276

Просмотров: 264

Время просмотра: 2.2 мин.

Еще в 2014 г. в Gartner выпустили статью, озаглавленную фразой «Beware of the Data Lake Fallacy», и писать на эту тему в 2018 г. просто неприлично. но практика говорит об обратном: все больше и больше заказчиков приходит с идей построить единое хранилище, да еще на новых технологиях.

  

Как известно, «опыт — сын ошибок трудных», и он тем ценнее, чем сильнее вас ударил черенок от граблей, на которые вы наступили. Но когда речь идет не о выборе цвета галстука и даже не о выборе технологии для корпоративного портала, а о построении такого сложного элемента корпоративной архитектуры, как хранилище, разновидностью которого и является Data Lake, цена ошибки приближается к миллионам долларов. Думаю, это тот самый случай, когда дешевле изучить опыт других, чем приобретать свой.

 

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

 

Но обо всем по порядку

 

Как это ни парадоксально, одна из проблем, способная погубить не только Data Lake, но и вообще любое хранилище, сокрыта в самом определении озера данных, которое гласит: «Data Lake — это хранилище данных, содержащее большие объемы сырых данных в их родном формате до тех пор, пока они не понадобятся». Точнее, проблема не в самом определении, а в том, как его интерпретируют, и основной вопрос не в том, какие объемы считать большими, тут все просто — распределенные системы хранения становятся экономически целесообразными, когда речь заходит о сотнях терабайт и петабайтах. главное недопонимание в другом. Привлекательна сама идея: «Зачем строить хранилище со Staging Area и сложными процедурами ETL? Мы просто возьмем побольше дисков и будем складывать туда данные как есть, а когда они нам понадобятся, мы попросим наших программистов достать их в нужном нам формате. Тем самым мы вроде бы размазываем немалую стоимость проектирования и внедрения хранилища на период его эксплуатации». И эта идея встречалась у наших заказчиков не единожды.  

«A data lake is a storage repository that holds a vast amount of raw data in its native format until it is needed».

TechTarget

 

Ее порочность состоит в одном простом факте: системы источников не идеальны, а если даже и приближаются к идеалу, они не статичны и развиваются. Думаю, каждый, кто хоть раз пытался анализировать данные или организовать их миграцию из legacy-систем, сталкивался с тем, что во вполне структурированной базе встречаются данные, которые из этой структуры выбиваются. Где-то новый разработчик написал код, не разобравшись со старыми таблицами, где-то в новой версии ПО решили поменять структуру хранения и теперь данные лежат в 2, 3, 5 разных таблицах… Особенно это усугубляется тем, что некоторые данные в таких таблицах пересекаются, дублируются и даже противоречат друг другу. В такой ситуации на этап анализа данных даже у закаленных в боях аналитиков уходит масса времени и сил Data Lake без правильной организации метаданных и их структуры умножает эту проблему на порядки. Вы или не сможете доверять результатам, полученным из DL, или будете тратить на элементарные отчеты месяцы. А самое страшное — без правильно организованных метаданных вы, скорее всего, даже не будете знать, какие данные у вас есть, а каких нет. Такое озеро очень быстро покрывается ряской, зарастает травой и превращается в болото данных: все, что в него попало, смогут найти только археологи.

 

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

 

Как показывает практика, самые ценные для моделей данные хранятся в обычных корпоративных системах. Но, даже если вы точно знаете, что подключение, например, к вашим данным профилей клиентов из соцсетей позволит поднять качество скоринговой модели на 2%, это еще не повод строить DL. Простая попытка посчитать экономическую выгоду может привести к удручающему результату: стоимость этих 2% качества может не окупиться и за 15 лет, не так много в России бизнес-структур с подобным горизонтом планирования. В эту ловушку в последнее время, кроме заказчиков из сферы ретейла и страхования, попадают даже банки.

 

Другая особенность подхода «храним все как есть» в том, что даже при использовании относительно дешевого оборудования позволить его при большом потоке данных могут «не только лишь все». Если вы попытаетесь сохранить поток данных в 10 Гбит/с как есть, то столкнетесь не только с тем, что для этого потребуются поистине астрономические объемы дискового пространства, но и с тем, что для обработки таких объемов нужно больше времени, чем для их накопления.

Ваши данные могут не иметь структуры, но ваши метаданные ОБЯЗАНЫ ее иметь.

Не так давно наше законодательство подвигло телеком-операторов массово строить себе хранилища как раз по этому принципу: сырые данные как есть. Однако бизнес не был бы бизнесом, если бы не попытался получить из этих простых хранилищ какую-то выгоду и для себя. И тут мы столкнулись с простым фактом: классическим способом, т.е. на ежедневной основе в режиме batch, мы не можем обработать весь тот объем сырых данных, который накопился за те же сутки. По факту, для того чтобы построить витрины, которые можно было бы использовать в том же процессе машинного обучения или для любой другой аналитики, пришлось применять другой подход — streaming. Данные нужно обрабатывать на лету, укладывая их по мере поступления в требуемую структуру. И получается, что мы вроде бы имеем DL с неструктурированными данными, но все равно вынуждены держать их структурированную копию, для того чтобы ими можно было воспользоваться.

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

Но, пожалуй, самое главное заблуждение, связанное с DL, — это то, что его внедрение несет Business Value само по себе. Очень показательна история одного банка, который на протяжении полугода рассылал RFI, в которых сначала предлагалось построить аналитику на уже внедренном распределенном хранилище, потом просто построить аналитику, возможно с использованием хранилища, и выдать рекомендации по его использованию, а потом уже RFI на проведение аудита возможности использования хранилища как такового, без какой-либо аналитики. Это классический и, к сожалению, далеко не единственный случай, когда в погоне за модными технологиями и в ожидании магического эффекта от внедрения было построено распределенное хранилище на технологиях Hadoop и BigData, но реальной задачи, для которой бы выбирались технологии, по факту не было.

 

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

 

Поэтому, если вдруг вас посетила идея о том, что неплохо бы срочно построить DL, вам нужно честно ответить себе на вопрос: что DL даст мне такого, чего не сможет дать старый добрый DWH? Если причина найдена, строить DL нужно не с выбора технологий и покупки серверов, а с процесса, ради которого вы собираетесь его построить. Как только вы сможете внятно описать процессы и поймете, что затраты на внедрение DL будут перекрыты выгодами, которые вы получите, можно начинать прототипирование.

 

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

 

Не бойтесь пробовать разных поставщиков и ПО, зачастую при внешне одинаковом заявляемом функционале конечное удобство использования может отличаться в разы. Уже на этом этапе вам нужно задуматься о таких вещах, как качество данных, которые вы собираетесь хранить (Data Quality), и управление их метаданными (Data Governance). Ваши данные могут не иметь структуры, но ваши метаданные ОБЯЗАНЫ ее иметь, в противном случае с течением времени вы неизбежно получите то самое болото.

 

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

 

Уведомления об обновлении тем – в вашей почте

Exadata - решение для Big Data?

Уже полтора года в нашей компании развернут демо-центр по Oracle Exadata Database Machine, и мы регулярно на различных мероприятиях докладываем о полученных на этом оптимизированном программно-аппаратном комплексе результах.

Шерлок против Big Data

Шерлок Холмс: Но я-то не каждый, Ватсон, поймите: человеческий мозг — это пустой чердак, куда можно набить всё, что угодно.

Анализ Big Data в ML-проектах

Почему традиционные СУБД не подходят для анализа Big Data? Что дает использование Cloudera Data Platform? Подробности создания Data Lake для Группы НЛМК

Современные Сизифы

Сизиф, царь Коринфа, был великим мошенником. Благодаря своей хитрости он собрал несметные сокровища.

Анализируй это, или Тренды рынка BI

Как Артур Конан Дойл описал ожидания от работы BI за 100 лет до его появления.

Какие профессии в ИТ будут востребованы в 2021 году

Можно сказать однозначно: вакансий для ИТ-специалистов меньше не станет ни в течение нынешнего года, ни в 10-летней и даже более отдаленной перспективе. Материал подготовлен экспертами Trud.com

«Мы строим с нуля и берем лучшие мировые технологии»

Несколько лет подряд Москва становится номинантом престижной международной премии World Smart City Awards.

«Большая вода»… «Большая руда»… Большие Данные!

Термин "Big Data" родился 4 сентября 2008 года с лёгкой руки журнала "Nature" и его редактора Клиффорда Линча (Clifford Lynch). В этот день вышел номер журнала "Nature" с темой номера "Большие Данные. Наука петабайтной эры" ("Science in the Petabyte era").

Как приручить Большие Данные

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

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня