ИТ-портал компании «Инфосистемы Джет»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: journal@jet.su