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

Внедрить что-то новое и получить такие результаты возможно в двух вариантах:

• Если в вашей компании есть сформированный штат специалистов, обладающих нужными навыками

• Если обратиться за помощью к сторонним экспертам с опытом реализации похожих проектов

Только проще кажется третий вариант:

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

Результат такого подхода приводит к разочарованию. Несоответствие внедренного решения потребностям бизнеса и его низкая производительность становятся причинами потери бизнесом денег.

Один из ярких примеров внедрения, в котором не стоит спешить и надеяться на авось – внедрение корпоративного хранилища данных (Data Warehouse, DWH).

DWH — это единый репозиторий структурированных данных для построения бизнес-аналитики, отчётов и обеспечения исторического анализа данных.
Многие компании осознают необходимость создания корпоративного хранилища, но не все понимают, что внедрение DWH при неграмотном, спешном подходе может стать дорогим удовольствием, только усугубляющим проблемы в работе с данными.

А что может пойти не так?

Одна из главных проблем компаний, которые самостоятельно внедрили DWH – хранилище вроде бы было спроектировано верно, согласно потребностям бизнеса на момент разработки, но в концепции не были учтены возможные изменения в данных и процессах. Поменялись источники данных, количество пользователей, задачи и цели, и DWH перестало тянуть такую нагрузку.

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

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

А почему все сломалось?

Бизнес - живой организм, в котором постоянно происходят изменения. Не все их можно проконтролировать, но некоторые можно спрогнозировать и учесть.

Какие условия могут измениться и повлиять на эффективность работы хранилища данных?

• Бизнес расширился, увеличился объем данных, появились ограничения в скорости их обработки

• Появились новые задачи или направления деятельности, а значит, новые информационные системы, для которых нужны другие правила интеграции

• Из-за появления новых источников изменился формат поступающих данных

• Увеличилось количество бизнес-пользователей

• Для отчетности требуются дополнительные поля или подключение новых источников данных

• Нужны новые виды отчетов – например, не только на конец отчетного периода, но и в режиме реального времени

• Нужен детальный анализ, при котором важно сохранять исторические данные, или изменился срок хранения этих данных

Чтобы любые изменения не привели к тому, что «они там все уронили», внедряемое хранилище данных должно быть:

• Гетерогенным, то есть, способным собрать и обработать разные данные из разных источников

• Масштабируемым – модель хранилища должна легко меняться под новые типы данных, а само оно быть расширяемым в соответствии с потребностями бизнеса

• Производительным – одинаково хорошо работать с любыми объемами данных при любой скорости их поступления, при этом актуализируя имеющиеся

И что мы теряем?

Если не учитывать перечисленные факторы, DWH может стать тратой ваших нервов, ресурсов и денег.

Покажем на живом примере.

В 2015 году розничная сеть из 700 торговых точек приняла решение о самостоятельном внедрении корпоративного хранилища данных.

Анализ данных в компании проводился при помощи приложений Qlik. Внедрение DWH было обусловлено запросами пользователей об упрощении процесса формирования отчетов и новом инструменте для хранения и структурирования большого количества данных, в том числе, QVD-фалов из приложений Qlik. Также появилась необходимость расширения количества бизнес-пользователей аналитических отчетов.

ИТ-специалистами компании были предприняты две попытки внедрить хранилище, обе не увенчались успехом. Ниже опишем, с какой предысторией, спустя 8 лет с момента старта проекта, компания обратилась к нам.

Первая попытка построения хранилища была реализована на SQL Server + SSIS (SQL Server Integration Services) и по сути являлась скорее импровизированной базой данных, нежели полноценным DWH, из-за ограничений SQL с точки зрения запросов и обработки данных.

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

Выбранный для решения задачи технологический стек уже тогда был несовременным. Сейчас для построения хранилищ вместо обычных реляционных БД используются колоночные СУБД, например, ClickHouse, которая как раз создана для работы с большими объемами данных.

Сама задача была решена хаотично и точечно, без прицела на дальнейшее масштабирование на всю компанию и появление новых задач.

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

Вывод №1 из данной ситуации – любые временные решения хранения данных потом очень тяжело оторвать от процессов, сложно масштабировать, и они не приносят необходимой эффективности в будущем.

Спустя время бизнес расширялся, потребности росли, данных становилось все больше, и компания все-таки пришла к необходимости создания полноценного DWH.

Вторую версию хранилища разрабатывали на базе более походящего инструмента - Greenplum – MPP-СУБД, основанной на PostgreSQL.

Внедрение DWH — это сложный процесс систематизации данных и знаний о них. В компании уже было реализовано внедрение BI-системы Qlik, часть этого пути уже была пройдена, и этот опыт можно было перенять.

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

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

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

Вывод №2 - если у компании есть опыт работы с данными, например, вы уже пользовались платформой Qlik, есть понимание построения ETL-процессов и структурирования данных, нужно использовать эти знания в процессах построения DWH. Те подходы, которые уже работают и не требуют улучшений, можно наследовать AS IS.

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

За последние годы торговая сеть выросла от 700 до 1000 магазинов, появились новые подразделения и информационные системы, и примерно в 5 раз, относительно старта проекта, увеличился объем поступаемых данных - до 100 ГБ ежемесячно.

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

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

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

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

Вывод № 3 - при построении хранилища важно учитывать перспективы масштабирования и в соответствии с этим выбирать архитектуру DWH. Разбираться в сложной структуре и ходить всё время по краю предельной производительности очень непросто, потому что начинают страдать основные процессы, которые уже завязаны на DWH.

При появлении новых источников и типов данных, во избежание хаоса и потери производительности хранилища, стоит своевременно приводить их в порядок. Внедрение системы управления мастер-данными (НСИ) поможет сопоставить разрозненные данные и структурировать их.

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

Все эти сотрудники, по сути, решали одни и те же задачи, а создание единого DWH сократило бы затраты на персонал в три раза.

Если убрать все эти проводимые впустую, повторяющиеся операции, по нашим подсчетам компания смогла бы оптимизировать используемые мощности и освободить до 30 % ресурса:

• RAM - c 2600 Гб до 1820 Гб

• CPU - с 506 ядер до 354

• HDD - с 22 Тб до 15 Tб

Сейчас разработкой новой концепции DWH и последующим внедрением будут заниматься эксперты Qlever Solutions. Мы обязательно поделимся с вами результатами этого проекта.

Теперь самостоятельно совсем ничего нельзя сделать?

Можно. Только важно понимать нюансы и смотреть вперед в будущее.

Не существует идеального и универсального рецепта построения DWH, которое бы совсем не требовало изменений с течением времени.

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

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

Чтобы справиться с проектом внедрения DWH и получить ожидаемые результаты, стоит:

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

• Определить на старте источники данных и оставить «запас» на случай их изменения или появления новых источников

• Оценить все системы-потребители и подумать над их интеграциями заранее

• Обеспечить качество данных: внедрить систему управления данными, разработать регламенты их ведения и структурирования

• Привлечь к разработке концепции DWH не только технических специалистов, но и бизнес-пользователей, которые в дальнейшем будут реализовывать отчетность

• Использовать предыдущий опыт работы с данными и уже наработанные процессы

• Выбирать гибкие, современные инструменты для проектирования хранилища

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