Зачем нужен дополнительный слой, если уже есть универсальные сущности по ключевым бизнес-доменам в слое DDS?

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

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

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

Слой витрин данных
(Data Mart Layer или DM)

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

Например, это могут быть:

• Услуги
• Клиенты
• Заказы
• Тарифы
• Обращения

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

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

Слой базовых данных
(Core Layer или DDS)

Из слоя первичных сырых данных информация транслируется в другие слои. Данные из ODS могу подтягиваться в слой витрин (DataMart, DM) напрямую или через слой DDS.

В разных источниках данные хранятся в разных форматах — где-то это может быть БД, где-то файлы на FTP, где-то JSON файлы. Также могут отличаться форматы хранения значений. Например, для десятичных чисел может быть настроена разная точность хранения — разное количество знаков после запятой.

В слое ODS данные преобразуются к единому формату хранения — колоночному представлению. А также учитываются форматы хранения значений — чтобы не потерялась информация.

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

Слой первичных сырых данных
(Primary Data Layer или ODS)

В уровневой архитектуре выделяют три основных слоя:

До этого мы говорили про архитектуру хранилища, как про черный ящик.

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

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

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

Обычно при построении хранилища использую комбинацию обоих подходов — реализуют витрины по запросам бизнеса из данных слоя ODS, чтобы дать результат «здесь и сейчас» и параллельно разрабатывают слой DDS, переключая витрины с ODS на DDS. Это позволяет и получить быстрый эффект для бизнеса, и не превратить хранилище в восточный базар.

Минус подхода — в отсутствии единого замысла, многократном усложнении связей хранилища и дублировании информации. Со временем такое хранилище может напоминать код лапшу, в котором сложно разобраться и создателям, и пользователям. Результаты предыдущих команд не будут переиспользоваться, а команда разработки превратится в ad-hoc комбайн на запросы бизнеса.

Надо сразу начинать что-то делать – думать будем в процессе или никогда потом.

Хранилище по Кимбаллу можно назвать коллекцией витрин данных (отчетов). Проектирование хранилища происходит «снизу-вверх». Что это означает?

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

Собираем потребности от бизнес-пользователей в отчетности, анализируем источники — понимаем откуда брать данные, загружаем данные в хранилище и создаем витрины данных.
То есть загружаем ванные в слой ODS — а оттуда сразу в слой витрин (DataMart, DM).

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

Сперва нужно все тщательно обдумать, а потом уже начинать что-то делать.

Билл Инмон — отец системного подхода в области анализа и проектирования DWH. Он сформулировал свою концепцию DWH в 1992 году.

Инмон говорит о том, что строить хранилище нужно по модели «сверху-вниз». Что это означает?

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

Наверняка вы узнали в концепции Инмона слой DDS, о котором мы говорили ранее.

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

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

У хранилищ данных есть два прародителя — Билл Инмон и Ральф Кимбалл. Мы их упоминали в предыдущем лонгриде и обещали поговорить о них подробнее. Обещали — рассказываем.

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

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

Как повлияли озера данных и большие данных на архитектуру хранилищ?

Когда мы говорили про послойную архитектуру хранилищ данных мы упоминали 3 слоя: ODS, DDS и DM. На самом деле есть еще один технический слой — Staging, в который данные выгружаются из систем источников в исходном виде — в исходных форматах, с исходными настройками данных.

Если мы создаем аналитику для небольшого интернет магазина, скорее всего мы будем строить отчетность в БД операционной системы. Это не сильно повлияет на производительность и не будет смысла инвестировать время в создание отдельного хранилища.
Если у нас 3−4 системы источника, в которые информацию вносят только пользователи — нам подойдет хранилища с монолитной архитектурой (SMP).

Если же у нас сотни систем-источников, то SMP подход не сработает — нужны специальные решения, которые способны хранить и обрабатывать петабайты данных. Это MPP системы.
Для конечного пользователя хранилища (аналитика) — MPP и SMP БД не сильно отличаются. Обе эти технологии работают с данными в табличном виде и поддерживают обычные SQL-запросы к данным.

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

Для решения задачи хранения неструктурированных данных придумали технологию озер данных (DataLake).

Пример такой архитектуры — база данных Greenplum — данные распределяются по множеству мелких серверов, объединенных в кластер.

Пример такой архитектуры — классическая база данных Oracle — все данные хранятся в едином месте.

Появился термин «большие данные» и появились разные подходы к архитектуре и масштабированию систем, в том числе аналитических — хранилищ данных.

Но потом случился бум доткомов, интернет начал бурно развиваться, появились смартфоны, интернет вещей и у нас изменились представление о том, что значит «много информации» и «большая нагрузка». Если все данные CRM-системы можно хранить на едином монолитном сервере, то поисковые логи Google или Яндекс уместить в одну базу на одном сервере невозможно.

Мы также говорили, что нельзя совмещать разные виды нагрузок в одной системе. Но вряд ли существует хотя бы одна операционная система (CRM, биллинг или бухгалтерская система), которая не предоставляет пользователям возможность выгрузить отчетность из интерфейса. Может показаться, что оба вида нагрузок вполне способна потянуть одна система?

Операционные системы, также, как и аналитические, строятся на СУБД — системах управления базами данных. И до конца 90х для обоих видов систем использовались реляционные СУБД — (Oracle, Microsoft) — системы, которые хранят информацию в табличном виде.

Создаются для расчета статистики и глубоких, тяжелых запросов.

Предназначены для выполнения множества коротких операций.

Разберем вопросы программной архитектуры хранилищ и инфраструктуры.

В прошлой статье мы обсудили  разные типы систем — операционные и аналитические.

Термин «большие данные» впервые был использован в статье, опубликованной NASA в 1997 году. Но до сих пор нет четкого определения где та отметка, когда данные становятся большими.

Также как нет единого мнения — существуют ли вообще большие данные, или это просто маркетинговый креатив.

Но можно считать, что большие данные начинаются тогда, когда нужны специальные технологии для работы с ними. Если для работы с данными достаточно Excel или монолитной БД — это нормальные данные. Если данные не помещаются в Excel, а БД на сервере не справляется с объемами информации и пользователи жалуются на длительность обработки из запросов, значит данные стали большими — то есть для их обработки нужны специальные технологии.

Что такое big data?

Такой нет :)

Во-первых, СУБД разные по своей внутренней архитектуре. Некоторые из них — реляционные, например Oracle или PostgreeSQL. Некоторые не реляционные  — MongoDB, Redis и другие.

А во-вторых, есть проприетарные и open-source СУБД. SMP и MPP СУБД, и еще много разных разновидностей.

Самой крутой СУБД будет та, которая эффективнее всего сможет решить вашу задачу — быстрее, дешевле и надежнее.

Какая СУБД самая крутая?

В 2007 году компания Google представила технологию Hadoop и сделала его открытым для использования и доработки. Hadoop разработан для задач дешевого, надежного хранения разноформатных данных и распределённых вычислений.

Как правило, для построения озера данных внутри корпоративной сети компании используется Hadoop. Знаменитый логотип Hadoop — летающий слон. Крылья олицетворяют способность Hadoop обрабатывать большие данные — слона. Эти крылья дают предприятиям возможность парить над конкурентами.

На чем строятся озера данных?

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

Болото — это хранилище данных, в котором находится потенциально ценная информация, но ее никто не использует по разным причинам: не удобно, не умеют, не знают, что она есть.

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

Чем отличаются озера данных и болота данных?

Они терпеть друг друга не могут. Каждый считает, что его концепция самая правильная и именно он — отец-основатель хранилищ данных, а второй подражатель.

Инмон и Кимбалл дружат?

Рубрика: 5 вопросов от джуна