Нужно ли нам озеро данных? А что делать с хранилищем данных?
Это статья перевод моей статьи на 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 как в базе данных.
Надеюсь, статья прояснила разнице между хранилищем данных и озером данных. Если было интересно, то могу перевести еще свои статьи или статье профессионалов, которых читаю. А также рассказать про решения, с которыми работаю, и их архитектуру.
Как я решал соревнование по машинному обучению data-like
Привет, Хабр. Недавно прошло соревнование от Тинькофф и McKinsey. Конкурс проходил в два этапа: первый — отборочный, в kaggle формате, т.е. отсылаешь предсказания — получаешь оценку качества предсказания; побеждает тот, у кого лучше оценка. Второй — онсайт хакатон в Москве, на который проходит топ 20 команд первого этапа. В этой статье я расскажу об отборочном этапе, где мне удалось занять первое место и выиграть макбук. Команда на лидерборде называлась «дети Лёши».
Соревнование проходило с 19 сентября до 12 октября. Я начал решать ровно за неделю до конца и решал почти фулл-тайм.
Краткое описание соревнования:
Летом в банковском приложении Тинькофф появились stories (как в Instagram). На story можно отреагировать лайком, дизлайком, скипнуть или просмотреть до конца. Задача предсказать реакцию пользователя на story.
Соревнование по большей части табличное, но в самих историях есть текст и картинки.
План рассказа
Метрика
Для проверки точности решений используется формула, нормированная на максимально возможный результат:
Какие данные есть:
Далее я подробно расскажу о каждом кусочке данных, как я его обрабатывал и какие признаки (далее фичи) извлекал.
Информация о пользователе
что есть изначально:
как фичи используем всё вышеперечисленное кроме job_title, т.к. предполагаем, что job_position_cd нормально описывает должность человека.
Транзакции
что есть изначально:
MCC — Merchant category code. Это стандартизованный код услуги, которую предоставляет получатель. Эта информация открыта, вот расшифровка. Эти коды можно удобно разбить на категории, например: entertainment, hotels и т.п.
Для каждого customer_id сопоставим следующие фичи:
Stories
Всего историй у нас 959.
что есть изначально:
выглядит json подобным образом:
Это такое дерево элементов, где каждый элемент описывается ключами: [‘guid’, ‘type’, ‘description’, ‘properties’, ‘content’]. В ‘content’ лежит список дочерних элементов. История состоит из страниц. На страницу накиданы фон, текст, картинки. Конструктора историй у нас не было, а самому отрисовать всё это достаточно сложно и не факт, что значительно поможет в дальнейшем.
Регулярками вытащим весь текст и соответствующий размер шрифта. Извлечём следующие фичи:
Реакции
что есть изначально:
Обработаем время и как фичи добавим:
Далее ещё добавится группа фичей исходя из данных по реакциям, а пока что идём в бой с этим арсеналом фичей делать бейзлайн.
Какую задачу мы решаем и как формировать предсказание?
Лучший подход, который использовал весь топ, следующий: cведём задачу к многоклассовой классификации, т.е. предсказываем вероятность каждой реакции. Считаем матожидание оценки 
для данной истории 
:
Бинаризуем : 
— наш ответ для объекта , который может принимать значение 
Модель
С самого начала и до конца я использовал CatBoost. Обусловлено это тем, что CatBoost из коробки строит полезные статистики для категориальных фичей. А статистика по пользователю — то, насколько он склонен к каким реакциям, и статистика по истории — то, как чаще всего не неё реагируют, являются самыми сильными фичами в этой задаче.
Как CatBoost работает с категориальными фичами хорошо объяснено в документации.
TLDR:
берём значение признака, например, один из customer_id, считаем процент случаев, когда этот customer отреагировал лайком, дизлайком, скипнул или просмотрел. Получим 4 числа. Заменяем customer_id на эти 4 числа и используем их как признаки. Делаем так для каждого customer_id.
Текущий результат
С текущими фичами, с неоптимизированным катбустом, на публичном лидерборде я занимал на тот момент 11 место с результатом 0.31209
Киллер фичи
В какой-то момент появилась гипотеза, что приложение может показывать истории чаще или реже в зависимости от того, как пользователь отреагировал на неё ранее. Давайте тогда добавим фичи, которые будут говорить:
Конечно же, эти фичи использовать в продакшне нельзя, т.к. их банально не будет на момент применения модели, но в соревновании любые средства хороши.
Итак, сказано — сделано. Получили 0.35657 на лидерборде.
Оптимизация модели
Перебирал параметры я с помощью байесовской оптимизации
Из интересного можно упомянуть параметр max_ctr_complexity, который отвечает за максимальное количество категориальных фичей, которые могут быть скомбинированы. Пример под спойлером.
Assume that the objects in the training set belong to two categorical features: the musical genre (“rock”, “indie”) and the musical style (“dance”, “classical”). These features can occur in different combinations. CatBoost can create a new feature that is a combination of those listed (“dance rock”, “classic rock”, “dance indie”, or “indie classical”).
Интересные наблюдения
CatBoost можно обучать на GPU, это заметно ускоряет обучение, но также вводит много ограничений, особенно касательно категориальных фичей. В этой задаче обучение на GPU давало результат сильно хуже, чем на CPU.
Важность фичей по мнению CatBoost. Во многом названия фичей говорят сами за себя, но некоторые, не самые очевидные, из топа, я поясню:
Картинка кликабельна.
Давайте посмотрим на распределение реакций с течением времени:
Т.е. в какой то момент распределение по реакциям сильно меняется.
Трешхолд предсказаний
На последнем шаге получения итоговых предсказаний добавим трешхолд: 
В последней модели у меня было что-то около 66% единичек, если бинаризовать с трешхолдом равным 0. Оказалось, что действительно, уменьшение количества +1 давало сильный прирост качества. Оценивались только последние 3 посылки, поэтому я заслал предсказания лучшей модели с разными трешхолдами так, чтобы процент плюс единичек был примерно 62, 58 и 54.
По итогу на публичном лидерборде мой лучший результат был 0.37970.
Результаты соревнования
Как обычно принято в соревнованиях по машинному обучению, когда отправляешь предсказания в систему, результат оценивается только по части всей тестовой выборки. Обычно около 30%. Результаты для этой части отражаются на публичном лидерборде. По оставшейся части теста оценивается итоговый результат, который отображается после окончания соревнования на приватном лидерборде.
В конце соревнования на публичном лидерборде положение было таким:
На приватном лидерборде, по которому считались итоговые результаты, мне повезло и ребята по какой-то причине с первого места упали на 4ое. Вот итоговое положение.
Что не сработало
Выводы
Соревнование получилось интересным, поскольку объединяло много компонентов, таких как табличные данные, тексты и картинки. Было много пространства для исследований, много с чем ещё можно было бы экспериментировать. В общем, скучать не пришлось.
Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop
В этой статье я хочу рассказать про следующий этап развития DWH в Тинькофф Банке и о переходе от парадигмы классического DWH к парадигме Data Lake.
Свой рассказ я хочу начать с такой вот веселой картинки:
Да, ещё несколько лет назад картинка была актуальной. Но сейчас, с развитием технологий, входящих в эко-систему Hadoop и развитием ETL платформ правомерно утверждать то, что ETL на Hadoop не просто существует но и то, что ETL на Hadoop ждет большое будущее. Далее в статье расскажу про то, как мы строим ETL на Hadoop в Тинькофф Банке.
От задачи к реализации
Перед управлением DWH была поставлена большая задача – анализировать интересы и поведение интернет посетителей сайта банка. У DWH образовалось два новых источника данных, больших данных – это clickstream с портала (www.tinkoff.ru) и RTB (Real-Time Bidding) платформа банка. Два источника порождают колоссальный объём текстовых полуструктурированных данных, что конечно для традиционного DWH, построенного в банке на массивно параллельной СУБД Greenplum, совсем не подходит. В банке был развернут кластер Hadoop, на основе дистрибутива Cloudera, он то и лег в основу целевого хранилища данных, а точнее озера данных, для внешних данных.
Концепция построения озера
Важно было на начальных этапах продумать и зафиксировали концептуальную архитектуру, которой нужно будет придерживаться в ходе моделирования новых структур для хранения данных и работы по загрузке данных. Мы очень не хотели превратить наше озеро в болото данных 🙂 Как и в классическом DWH, мы выделили основные концептуальные слои данных (см. Рис. 1).
Data Vault и как мы его готовим
Проанализировав тренды развития технологий Hadoop, мы решили использовать этот подход и засучив рукава принялись моделировать Data Vault для выше озвученной задачи.
Собственно, хочу рассказать несколько концептов, которые мы используем. Например, в загрузке визитов интернет-пользователей по страницам мы не сохраняем каждый раз URL визита. Все URL-ы мы выделили, в терминах Data Vault, в отдельный хаб (см. Рис. 2). Такой подход позволяет значительно сэкономить место в HDFS и более гибко работать с URL-ами на этапе загрузки и дальнейшей обработки данных.
Рис.2 Data Vault для визитов
Ещё один концепт относится к области загрузки интернет пользователей. Мы не получаем на этапе загрузки в DDS единого интернет пользователя, а загружаем данные в разрезе систем источников. Таким образом загрузки в Data Vault из разных источников не зависят друг от друга.
Реки ETL в озере данных
Вот и подошли к самому интересному. Концепцию продумали, моделирование провели, создали структуры данных, теперь хорошо бы было бы это все наполнить данными.
Для того что бы обеспечить стабильный поток данных (файлов) в слой RAW мы используем Apache Flume. Для обеспечения отказоустойчивости и независимости от кластера Hadoop мы разместили Flume на отдельном сервере – получили такой как бы File Gate, перед кластером Hadoop. Ниже приведу пример настройки агента Flume для передачи портального syslog:
Таким образом, мы получили стабильный поток данных в слой RAW. Дальше нужно разложить эти данные в модель, наполнить Data Vault, ну короче нужен ETL на Hadoop.
Барабанная дробь, гаснет свет, на сцену выходит Informatica Big Data Edition. Не буду в красках и много рассказывать про этот ETL инструмент, постараюсь коротко и по делу.
Лирическое отступление. Хочется сразу отметить, что Informatica Platform (в которую входит BDE), это не та всем знакомая Informatica PowerCenter. Это принципиально новая платформа интеграции данных от корпорации Informatica, на которую сейчас постепенно переносят весь тот большой набор полезных функций из старого и всеми любимого PowerCenter.
Теперь по делу. Informatica BDE позволяет достаточно быстро разрабатывать ETL процедуры (маппинги), среда очень удобная и не требует длительного обучения. Маппинг транслируется в HiveQL и выполняется на кластере Hadoop, Informatica обеспечивает удобный мониторинг, последовательность запуска ETL процессов, обработку ветвлений и исключительных ситуаций.
Например, вот так выглядит маппинг, который наполняет хаб интернет юзеров нашего портала (см. Рис. 3).
Оптимизатор Informatica BDE транслирует этот маппинг в HiveQL и сам определяет шаги исполнения (см. Рис. 4).
Рис.4 План выполнения
Informatica BDE позволяет гибко управлять параметрами среды выполнения. Например, мы у себя настроили следующие параметры:
Маппинги можно объединять в потоки. Например, у нас данные из отдельных систем источников загружаются в отдельных потоках (см. Рис. 5).
Рис.5 Поток загрузки данных
Informatica BDE обладает удобным инструментом администрирования и мониторинга (см. Рис. 6).
Рис.6 Мониторинг исполнения потока данных
Из преимуществ Informatica BDE можно выделить следующее:
Из недостатков можно выделить следующее:
В целом инструмент Informatica BDE весьма хорошо показал себя при работе с Hadoop и у нас на него дальше очень большие планы в части ETL на Hadoop. Думаю, в скором времени напишем ещё более предметные статьи о реализации ETL на Hadoop на Informatica BDE.
Результаты
100Gb текстовых логов и получаем в Data Vault примерно на порядок меньше данных, на основе которых собираются витрины данных. Загрузка в модель происходит на ночном регламенте, загружается дневной инкремент данных. Длительность загрузки составляет
2 часа. С этими данными, выполняя Ad-hoc запросы, работают аналитики через Hue и IPython.
Озера данных: как устроены 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. Главная задача — это централизация и консолидация разрозненных сведений. В эпоху микросервисов и распределенных команд часто возникают ситуации, когда один отдел не знает, над чем работает другой. Из-за этого бизнес тратит ресурсы, а разные специалисты выполняют одинаковые задачи, часто не подозревая об этом. В конечном итоге это снижает эффективность и перегружает «оперативную систему» компании. Как показывают опросы, большинство компаний инвестирует в озера данных как раз для повышения операционной эффективности. Но результаты превосходят ожидания: у ранних адептов технологии выручка и прибыль растут быстрее, чем у отстающих, а главное, они быстрее выводят на рынок новые продукты и услуги.
