Статьи / Перестаньте думать о хранилищах!

24.05.2018 г., перевод статьи Pedro Alves

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

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

Несколько лет назад в блоге…

Пару лет назад я опубликовал в блоге новость «Kimball устаревает». Она несла в себе одно фундаментальное утверждение: технология развилась до такой степени, что простой взгляд на концепцию корпоративного хранилища данных (EDW) показывает ограниченность такого решения. Пользователей не волнует, с использованием каких технологий хранится информация, им важно, чтобы данные были где-то сохранены, а по-возможности – еще и сделана их резервная копия. Я предложил обратить внимание на эту проблему: возможно, DW Kimball с его организацией в виде схемы звезды, снежинки и прочим – не лучший вариант, и нам следует реализовать что-нибудь другое...

Но я был не совсем прав...

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

Но я совершил 2 большие ошибки:

1. Я спутал понятия «моделирование данных» и «хранилище данных»;
2. Я все это время рассматривал источники данных как единый, монолитный источник для для всего.

Моделирование данных – семантика после данных

Кимбалл был чертовым гением! Моя ошибка состояла в том, что он оказался намного умнее всех остальных. Почему я так говорю? Потому что он придумал не одну, а две новаторские идеи…

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

После этого он стал распространять свою концепцию и объяснил нам, как ее можно перенести на таблицы баз данных. Кимбалл рассказал, как ответить на бизнес-вопросы с помощью технологий реляционных БД, пользуясь схемами «звезда», «снежинка», различными методами агрегации и так далее.

Талант Р.Кимбалл определил то, как мы работаем сегодня. Сколько из нас вовлечено в проекты, где мы говорили о построении хранилищ данных, которые дадут все возможные ответы, в том время как мы с вами даже не знаем вопросов пользователей? Нас научили давать ответы, не сосредотачиваясь на понимании вопросов.

Сложность проекта растет в геометрической прогрессии

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

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

Чтобы быть эффективным (независимо от того, как определен «эффект»), проект BI должен инициировать операционные действия: планировать обслуживание, рассылать оповещения, предотвращать сбои. А еще добавьте ученых data scientist с их алгоритмами прогнозирования и машинного обучения ...

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

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

Все это звучит как описание большой проблемы. Напротив, это большие возможности! В прошлом BI-системы ограничивались предоставлением аналитики, но теперь мы имеем шансы получить гораздо большее влияние на бизнес во всем мире! Осознание и принятие этого является единственным способом продвижения вперед для таких компаний, как Pentaho: мы либо преуспеваем и растем, либо становимся неуместными. И я, безусловно, не хочу становиться неуместным!

Применение принципа неопределенности Гейзенберга в IT: повышение скорости и масштабируемости?

Итак, как нам это сделать?

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

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

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

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

Взгляд на «источники данных» под другим углом

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

1. Мы думаем о них как о целостной сущности (Продажи, Человеческие ресурсы и т.д.), которые содержат всю информацию, относящуюся к теме;
2. Мы думаем о них с технологической точки зрения.

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

Встречается довольно часто, не так ли?

Классический подход

Когда вы думаете об этом сценарии с точки зрения классической реализации, первым желанием становится начать проектирование хранилища данных (даже не обязательно это должно быть EDW как таковое, может быть Hadoop, источник без sql и т. д.). Мы будем строить наш процесс ETL (с PDI или любым другим) из исходных систем, начиная с этапа моделирования, чтобы мы могли добраться до нашего источника данных о продажах, который мог бы ответить на любые запросы.

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

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

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

Деловой подход

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

Сколько я продал вчера и как это отразилось на моем бюджете?

Это единственные цифры, которые его интересуют.

Рассмотрим другие требования: он хочет знать лучших сотрудников месяца. Ему нужен график продаж. Сколько это точек данных? Максимум 30? Я специально упрощаю, но очевидно, что подавляющее большинство запросов не нуждается в обработке Big Data. Запросы могут требовать в расчетов и оркестровки, но, конечно, не во время выполнения.

Итак, вот как можно решить эту задачу:

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

• ActualVsBudgetThisMonth – фактический бюджет в сравнении с бюджетом в этом месяце;
• CustomerSatByDayAndStore – клиенты по дням и магазинам;
• SalesByStore – продажи по магазинам;
• SalesRepsPerformance – показатели менеджеров по продажам.

Тогда я бы реализовал их так, как мне нужно! Материализованные и не материализованные представления, базы данных или Hadoop – все равно как, лишь бы это работало. Суть состоит в том, что мы разделяем все данные, и необходимое для быстрых ответов на наиболее распространенные запросы.

Это позволит нам обработать все возможные запросы? Конечно же нет! Но я считаю, что нет смысла в оптимизации решения таким образом, чтобы оно могло обрабатывать все возможные запросы. Для этого имеется хранилище больших данных, из которого можно получить любую возможную информацию. Основная задача же бизнес-хранилищ – быстрая обработка наиболее часто встречающихся запросов пользователя.

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

• Быстрее реализовать – так как сигнатуры наших источников бизнес-данных гораздо меньше и хорошо идентифицированы, гораздо проще сформировать отчет;
• Легче проверить – поскольку источники данных меньше, их легче проверять с заинтересованными сторонами в бизнесе, так как мы фиксируем их и переходим к другим источникам бизнес-данных;
• Технологический агностицизм – обратите внимание, что каждый раз я упоминал о выборе технологии. Подумайте об этих источниках данных как об API;
• Проще оптимизировать – поскольку мы разделяем большие источники данных на несколько более мелких, становится легче их поддерживать и оптимизировать.

Заключение

Попробуйте – вы не заметите, как быстро такой подход изменит ваше мышление. Мы слишком много внимания уделяем выбору технологий и часто забываем, что же является главным на самом деле…