Как организовать хранилище данных

Как создать хранилище данных за 5 шагов

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

Вот основные причины этих неудач.

• Трансформирование стеков данных.
• Недостаточная подготовленность данных.
• Некомпетентность команды.
• Нетерпеливость заинтересованных сторон.
• Чрезмерное усердие руководства.
• Отсутствие инвестиций, необходимых для изменения организационной культуры.

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

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

Шаг №1. Определение основных бизнес-целей

Прежде чем браться за очередной “блестящий” проект, стоит сделать паузу.

Действительно ли вам нужно хранилище данных (DWH)? Наверняка у вас уже есть реализованный проект DWH, если только вы не работаете в недавно запущенном стартапе. Так уж необходимо создавать новый DWH? Если да, то убедитесь, что четко понимаете основные бизнес-задачи.

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

Помните: ключ к задаче > технология, используемая для ее решения.

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

Ниже представлен пример отчетной истории.

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

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

Разработка концептуальных моделей

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

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

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

1. Клиент должен быть уникальным: один и тот же клиент не должен быть учтен дважды.
2. У него может быть 0 или больше заказов: он может быть в базе данных, но никогда ранее не делал заказов.
3. Заказ должен включать 1 или несколько продуктов: заказ не может быть создан без включения продукта.
4. Продукт может присутствовать в 0 или нескольких заказах: продукт может быть в наличии, но никогда не продаваться или продаваться много раз.

Теперь у вас есть:

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

Все это должно быть создано и утверждено совместно с конечными пользователями.

Шаг №2. Создание физической модели данных

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

• имя клиента;
• номер телефона;
• адрес;
• уникальные идентификаторы.

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

Вернемся к первоначальной отчетной истории:

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

Достаточно ли информации в физической модели данных, чтобы решить эту задачу? Скорее всего, нет! На данном этапе нужно определиться с тем, как сформировать эти данные в DWH. Можно использовать несколько различных методов, таких как размерное моделирование в схеме “звезда” или нормализация в 3-й обычной форме в модели “снежинка”.

В данном случае подойдет простая размерная модель с фактами (количественными) и измерениями (качественными).

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

Профиль известных атрибутов данных

На этом этапе необходимо начать профилирование известных исходных данных.

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

Шаг №3. Схема решения с отражением конечного результата

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

Помните: ключ к задаче > технология, используемая для ее решения!

На этом этапе создайте несколько макетов/прототипов конечных отчетов по клиентским запросам. Это позволит быстро понять и сформировать образ конечного продукта. У конечного пользователя может быть видение, которое он не смог связно сформулировать на этапе выявления потребностей. Макет не обязательно должен использовать реальные данные или быть средством построения отчетности. Он может быть просто создан в Powerpoint.

Шаг № 4. Создание, тестирование и итерация

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

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

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

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

Интегральное тестирование обычно решает судьбу всего процесса.

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

Шаг №5. Запуск проекта на стадии полной готовности

Мы с нетерпением ждем даты запуска. Однако системе DWH следует “созреть”. Следовательно, дата запуска не должна иметь большого значения.

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

Если для создания конечного отчета требуется гораздо больше времени, чем ожидалось, настройку производительности придется проводить на постоянной основе.

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

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

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

Заключение

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

• Как построить идеальное хранилище данных
• Эффективное итерирование по строкам в Pandas DataFrame
• Все что нужно знать о древовидных структурах данных

7 шагов успешного создания хранилища данных(DWH)

Проектирование и построение хранилища данных (data warehouse) – задача масштабная и длительная. Необходимо учесть много факторов и нюансов, рассчитать бюджет и только на последнем этапе создавать DWH.

Рассмотрим создание хранилища данных поэтапно, рассказав о каждом шаге и возможных подводных камнях.

Для чего нужно DWH

Хранилище данных представляет собой предметно-ориентированную БД, которая аккумулирует всю информацию внутри организации в единую систему.

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

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

Архитектура DWH

Хранилище данных, построенное любым из методов, обязательно состоит из нескольких компонентов:

• Ядро. Главная часть любой DWH – обеспечивает целостность входящих данных. Структурирует полученную информацию согласно заданным параметрам.
• Область сбора информации. Компонент, который собирает всю входящую информацию с разных источников.
• Аналитическая часть отвечает за предоставления отчетности по требованию владельца.
• Сервис. Компонент отвечает за управление и стабильное взаимодействие трех предыдущих. Мониторит в режиме онлайн состояние каждого компонента и оперативно устраняет ошибки.

Методы создания DWH

Построение хранилища данных происходит по разным методикам.

• Классический метод. В его основе лежит разделение данных на две группы: измерения и факты. Связь между ними представлена в виде классических таблиц с внешним ключом. Возникает неудобство при добавлении новой составляющей в таблице, поскольку жесткая привязка таблиц к внешнему ключу не позволяет гибко менять структура data warehouse.
• Метод Инмона. По задумке создателя способа, сначала проектируется централизованное хранилище данных, а дальше добавляются витрины с информацией. При таком подходе загрузка входящей информации в data warehouse значительно упрощается, но увеличивается время при обработке запросов.
• Метод Кимбалла. В отличие от предыдущего способа DWH создается на основе витрин. Другими словами, сначала они заполняются необходимой информацией, а после проектируется централизованное хранилище.
• Метод 7D. Назван так по названиям этапов, которые включены в него: Discover, Design, Develop, Deploy, Day to day, Defend и Decommission.

Проектирование DWH с помощью 7D
Этап 1. Discover

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

Чтобы получить необходимые данные, следует ответить на шесть главных вопросов: Что? Как? Где? Кто? Когда? Зачем?. Ответы на вопросы являются фундаментом будущей DWH.

Менеджер проекта детерминирует роли и требования по визуализации данных для заказчиков и пользователей.

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

Этап 2. Design

На втором шаге проектируются семантические и схематические реализации DWH. Для проектирования можно воспользоваться двумя методами:

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

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

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

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

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

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

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

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

А в Вашей организации есть хранилище данных?

Создание хранилища данных: пошаговое руководство

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

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

Предварительные условия для создания хранилища данных

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

Планирование проекта хранилища данных

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

Сократите время разработки хранилища данных до 80 %

Разработка традиционного хранилища данных требует значительных инвестиций с точки зрения времени и ресурсов. Однако с Astera DW Builder позволяет сократить весь жизненный цикл проектирования и разработки хранилища данных до 80 %. Узнайте больше в этом техническом документе.

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

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

Сбор квалифицированной команды

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

Хотя успех команды во многом зависит от ее членов, в совокупности они должны обладать комплексом технических навыков. Обычно вам потребуются люди с опытом работы с SQL, процессами ETL и моделирование данных, а также человека, обладающего навыками управления проектами и глубоким пониманием бизнес-сферы. Короче говоря, ваша команда в идеале должна состоять из:

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

Обеспечение безопасности важнейших ресурсов

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

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

• оборудование или облачные сервисы
• лицензии на программное обеспечение
• и профессиональные услуги по проектированию и разработке

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

Создание технической базы

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

Упражнение включает в себя каталогизацию всех источников данных, доступных вашей организации, например, внутренних систем, таких как CRM и ERP, внешних данных от партнеров и источников потоковых данных, таких как устройства IoT. Идентификация источников данных позволяет вам составить карту ландшафта данных и понять природу и бизнес-релевантность каждого источника данных.

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

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

Создайте собственное хранилище данных за несколько дней, а не месяцев

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

Создание хранилища данных: автоматизация этапа выполнения

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

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

Astera Data Warehouse Builder — это комплексная платформа, которая упрощает и ускоряет процесс создания хранилища данных. Его интерфейс перетаскивания позволяет проектировать модели данных и процессы ETL без написания единой строки кода. Встроенные разъемы обеспечивают легкую интеграцию с различными источниками и системами назначения, как локальными, так и в облаке. AsteraВстроенные функции качества данных гарантируют, что в ваше хранилище данных попадут только достоверные данные для точной бизнес-аналитики, анализа и отчетности.

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

Пример использования:

Shop-Stop — это вымышленный розничный интернет-магазин, который хранит данные о продажах в базы данных SQL. Недавно компания решила внедрить хранилище данных, чтобы получить надежную архитектуру отчетности и улучшить BI и аналитику. Однако их ИТ-команда и технические эксперты утверждают, что капитал и ресурсы, необходимые для выполнения и обслуживания всего процесса, можно значительно сократить, используя инструмент автоматического хранения данных.

Shop-Stop решает использовать Astera Data Warehouse Builder для проектирования, создания, развертывания и обслуживания своего хранилища данных. Давайте посмотрим, как происходит процесс построения хранилища данных с использованием Astera выглядит как.

Создание хранилища данных. Шаг 1. Создание модели исходных данных.

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

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

После проверки модели вы можете развернуть ее на сервере и сделать доступной для использования в Трубопроводы ETL (так же как ELT) или для анализа данных. Вот как это сделать. Теперь, когда вы создали, проверили и развернули модель исходных данных, давайте перейдем к следующему шагу.

Создание хранилища данных. Шаг 2. Создание и развертывание многомерной модели.

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

Поскольку Shop-Stop уже имеет схему хранилища данных в базе данных SQL, вам придется перепроектировать базу данных. Опять же, каждый объект в полученной модели хранилища данных представляет собой таблицу в окончательном хранилище данных Shop-Stop.

Далее вам необходимо преобразовать эту модель в многомерную модель, назначив факты и измерения. Тип для каждой сущности устанавливается как Общие по умолчанию, когда база данных подвергается обратному проектированию. Вы можете удобно изменить тип на Факт or Размеры щелкнув правой кнопкой мыши по объекту и наведя курсор на Тип объекта в контекстном меню и выбрав подходящий тип из предложенных вариантов.

Сущность «Продажа» в центре — это сущность факта, а остальные — сущности измерения.

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

Для объектов измерения Роль измерения столбца в Макет Builder предоставляет полный список опций. К ним относятся:

• Суррогатный ключ
• Бизнес-ключ
• Медленно меняющиеся типы измерений (SCD1, SCD2, SCD3 и SCD6)
• Идентификаторы записей для отслеживания исторических данных (даты вступления в силу и окончания срока действия, текущий идентификатор записи и номер версии)
• Измерение-заполнитель для отслеживания опоздавших и ранних фактов и измерений.

Аналогично, сущность факта Макет Builder содержит Роль факта столбец, который позволяет вам назначить Ключ даты транзакции роль одному из полей. Вот как выглядит макет Распродажа сущность будет выглядеть так, как только вы назначили Ключ даты транзакции роль в поле:

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

Создание хранилища данных. Шаг 3. Заполнение хранилища данных

Пришло время заполнить хранилище данных Shop-Stop, загрузив соответствующие исходные данные в таблицы с помощью конвейеров ETL. Astera позволяет вам строить ЭТЛ и ЭЛТ конвейеры с помощью конструктора потоков данных.

Для этого вам придется добавить новый поток данных в проект хранилища данных. Используйте обширный набор объектов, доступных в наборе инструментов потока данных, для разработки процесса ETL. Использовать Загрузчик фактов и Размерный погрузчик объекты для загрузки данных в таблицы фактов и измерений соответственно.

Вот какой поток данных для загрузки данных в Клиент таблица выглядит так:

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

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

Аналогично настройте объект Dimensional Loader с развертыванием целевой размерной модели, как показано на рисунке ниже:

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

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

Теперь, когда вы спроектировали все свои потоки данных, вы можете выполнить каждый из них, чтобы заполнить хранилище данных Shop-Stop данными о продажах. Чтобы избежать выполнения всех потоков данных по отдельности, разработайте рабочий процесс для оркестрации всего процесса.

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

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

Создание хранилища данных. Шаг 4. Визуализация и анализ.

После того как вы спроектировали и развернули свое хранилище данных, вы можете интегрировать его с ведущими в отрасли инструментами визуализации и анализа, такими как Power BI, Tableau, Domo и т. д., через встроенный сервис OData.

Лучшие практики по созданию хранилища данных

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

Начните со стратегии хранилища данных

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

Автоматизируйте все, что можете

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

Обратите внимание на качество данных

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

Примите масштабируемую архитектуру

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

Внедрить надежный процесс ETL

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

Создайте свое хранилище данных без особых усилий с помощью платформы, полностью не требующей программирования

Создайте полнофункциональное хранилище данных за считанные дни. Развертывание локально или в облаке. Используйте мощные конвейеры ETL/ELT. Обеспечьте качество данных во всем. И все это без написания единой строчки кода.

Создайте свое хранилище данных с помощью Astera

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

У вас сжатые сроки, требующие создания хранилища данных в течение нескольких дней, а не месяцев? Свяжитесь с одним из наших экспертов по решениям по адресу +1 888-77-ASTERA. Альтернативно, вы можете скачать 14-дневная бесплатная пробная версия or посмотреть демо.

Вам также может понравиться

Как реализовать стратегию API в 2024 году

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

Что такое управление данными и почему это важно?

Компании, как большие, так и малые, сталкиваются с морем информации, часто используя нездоровые данные для бизнес-аналитики (BI).

Что такое качество данных и почему это важно?

Что такое качество данных? Качество данных — это мера работоспособности данных по нескольким параметрам, таким как точность, полнота, согласованность и т. д.

принимая во внимание Astera Для ваших потребностей в управлении данными?

Установите соединение без кода с вашими корпоративными приложениями, базами данных и облачными приложениями для интеграции всех ваших данных.

Как и где хранить большие данные? Технологии хранения big data

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

В 2002 году была создана дочерняя компания AWS, которая занималась отслеживанием популярности сайтов и ведением другой статистики в интернете. Тогда началась работа с большими данными. С 2014 года на big data стали обращать внимание все больше крупных IT-компаний (Google, Microsoft, Oracle, IBM), которые стали обрабатывать их с целью анализа, прогнозирования и принятия решений. На сегодняшний день сложно представить крупную или среднюю компанию, которая развивается онлайн и не работает с Big Data.

Характеристики больших данных

Главные вопросы, которые появляются у тех, кто только начинает работать с большими данными: где и как их хранить? Но, чтобы правильно выбрать хранилище больших данных, для начала нужно получить представление о ключевых характеристиках Big Data. Часто их оформляют в концепцию пяти V — рассмотрим каждый.

Объем (Volume)

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

Скорость (Velocity)

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

Разнообразие (Variety)

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

• Для структурированных данных характерна строгая организация. Типичный пример — таблицы Excel.
• Данные со слабой структурой — наиболее типичный вид данных, поступающих из интернета. К слабо структурированным относятся, например, логи.
• Неструктурированными являются данные без конкретной формы. Пример неструктурированных данных — файлы с различным содержимым (видео, текст, картинки).

Достоверность (Veracity)

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

Изменчивость (Variability)

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

Кроме того, сам формат данных может меняться: могут добавляться и убавляться поля в JSON, пропадать столбцы в таблицах, меняться расширения файлов и т.д.

Ценность (Value)

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

Как собирают и хранят большие данные

Основными источниками Big Data сегодня являются:

• устройства Интернета вещей (IoT),
• социальные сети,
• интернет-сервисы (порталы услуг, интернет-магазины),
• оборудование и приборы различного типа,
• медицинские и социальные организации.

Современные вычислительные мощности позволяют получать мгновенный доступ практически к любому объему данных, поскольку данные хранятся в дата-центрах (ЦОД, центрах обработки данных) на серверах с современными комплектующими. Некоторые компании все еще хранят данные «по старинке», то есть на собственных физических серверах, однако удобнее и надежнее хранить и работать с Big Data в облаке.

Типы систем хранения данных: Data Lake и Data Warehouse

Data Warehouse

Когда мы говорим о Data Warehouse, подразумеваем специализированные СУБД, в которые стекаются данные определенного вида. Data Warehouse работает по типу детской игрушки с геометрическими отверстиями, куда нужно правильно отправить фигурки соответствующей формы. Фигуры другой формы туда не пройдут. Так же, как и игрушки, Data Warehouse собирает структурирует данные по заранее определенному сценарию.

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

В Data Warehouse мы имеем дело с различными таблицами, в которых размещена структурированная информация, и связями между ними. Поскольку мы имеем дело с понятными сущностями таблиц и уже преобразованными («очищенными») данными, как правило, DWH более прост в понимании и использовании.

Отметим и недостатки:

• Такой подход хранения подходит не всем компаниям. DWH может не учитывать часть данных, которые не вписываются в хранилище. Если компания работает с большим количеством сложно структурированных данных, велика вероятность, что пользы от такого хранилища данных она не получит.
• Data Warehouse — недешевый инструмент, особенно если нужно обрабатывать большие объемы данных. Кроме того, на данный момент часть СУБД недоступна для пользователей из РФ.

Инструменты для хранения больших данных: обзор популярных СУБД

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

Рассмотрим наиболее популярные решения и их особенности. Мы не рассматриваем подробно такие СУБД, как Exasol, Teradata, Vertica, поскольку на данный момент они недоступны для пользователей РФ.

ClickHouse

ClickHouse — это СУБД (система управления базами данных) столбцового (колоночного) типа, разработанная для быстрой обработки структурированных данных Big Data в реальном времени. ClickHouse обеспечивает высокую скорость чтения SQL-запросов благодаря оптимизированной сортировке данных, векторным вычислениям, распараллеливанию операций и поддержке приближенных вычислений. Особенностью ClickHouse является то, что эта СУБД может работать на обычных жестких дисках, а не только в оперативной памяти (как многие столбцовые СУБД).

Плюсы ClickHouse

• очень быстрое чтение,
• высокопроизводительная СУБД, так как написан на C++,
• удобно реализованы распараллеливание и векторизация,
• быстрый парсинг JSON
• и другие дополнительные возможности (подробнее читайте в тексте).

Минусы ClickHouse

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

Greenplum

Еще одна популярная СУБД, облегчающая жизнь тем, кто работает с большими данными объемом от нескольких терабайт. Основу Greenplum составляет интегрированная СУБД PostgreSQL, а также технология массивно-параллельной обработки данных, или MPP.

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

Плюсы Greenplum

• хорошая производительность, обеспечиваемая за счет развертывания нужного количества нод на PostgreSQL,
• совместимость с проектами на Postgres, поскольку Greenplum на нем основан,
• широкая поддержка транзакций,
• многие проблемы БД давно известны и решены,
• поддержка разных видов репликации и шардинга.

Минусы Greenplum

• не всегда сборки Greenplum базируются на свежих версиях Postgres,
• отсутствуют инструменты для инкрементального бэкапа.

Сравниваем СУБД: ClickHouse, Exasol, Greenplum, Teradata, Vertica

Для удобства свели главные особенности интересующих нас СУБД в таблицу. Для полноты сравнения добавили информацию по отсутствующим на рынке РФ СУБД. Hadoop не добавили, потому что инструмент не является базой данных как таковой.

ClickHouse	Exasol	Greenplum	Teradata	Vertica
Open Source	да	нет	да	нет	да (но на данный момент СУБД недоступна для РФ)
Вторичные модели СУБД	временных рядов	нет	пространственная, хранилище документов	пространственная, хранилище документов, временных рядов, графовая	пространственная, временных рядов
Поддержка XML	нет	нет	да	да	нет
Вторичные индексы	да (с движком MergeTree)	да	да	да	не требуются
Поддержка SQL	частичная	да	да	с расширениями	полная
Поддерживаемые ЯП	C++, остальные со сторонними библиотеками	Java, Lua, Python, R	C, Java, Perl, Python, R	C, C++, Cobol, Java, Perl, PL/1, Python, R, Ruby	C#, C++, Java, Perl, PHP, Python, R
Скрипты на стороне сервера	нет	функции, определяемые пользователем	да	да	да
Триггеры	нет	да	да	да	да
MapReduce	нет	да	да	нет	нет
Внешние ключи	нет	да	да	да	да
Возможность хранения только в памяти	да	да	нет	да	нет

Базы данных Greenplum и ClickHouse есть в готовой платформе обработки данных от Selectel. Подробнее читайте в тексте →

В отличие от подхода Data Warehouse, архитектура Data Lake («озеро данных») подразумевает наличие хранилища, куда стекаются и где хранятся все необработанные данные в исходном формате, то есть без преобразования. Данные могут быть самыми разными: структурированными, неструктурированными и слабо структурированными. Каждый элемент в таком хранилище наделяется уникальным идентификатором и набором тегов.

Data Lake

Возвращаясь к аналогии с детскими игрушками, Data Lake — это скорее бокс, куда складываются все существующие игрушки. Какие в этом плюсы?

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

Теперь к ограничениям:

• Data Lake может требовать большей квалификации специалистов для работы с данными и получения ценности из них; часто поверх DL нужно надстраивать дополнительное ПО для трансформации данных — так происходит переход к парадигме Data Lakehouse, которая исключает многие недостатки DWH и DL.
• при неправильно выстроенных процессах легко превращается в бардак, так называемый Data swamp («болото»).

Способы организации Data Lake

Можно выделить три способа:

• использование Hadoop (HDFS),
• организация собственного S3-хранилища,
• использования готового решения от провайдера.

Hadoop (HDFS)

Hadoop — это программная среда, предназначенная для вычислений Big Data. Hadoop используется для хранения и обработки любых типов данных (структурированных, слабо структурированных и неструктурированных). А архитектура платформы основана на трех компонентах: HDFS (собственная файловая система для хранения больших данных), MapReduce (модель распределенных вычислений, разработанная Google) и YARN.

Hadoop — экосистема компонентов для работы с данными, поэтому напрямую сравнивать ее с S3 будет некорректно. В рамках этого блока рассмотрим именно HDFS (Hadoop Distributed File System) — распределенная файловая система Hadoop для хранения больших файлов с возможностью потокового доступа к информации.

Плюсы HDFS

• большой размер блока по сравнению с другими файловыми системами,
• файлы пишутся однократно, что исключает внесение в них любых произвольных изменений,
• принцип WORM (Write-once and read-many) полностью освобождает систему от блокировок типа «запись-чтение»; запись в файл в одно время доступен только одному процессу, что исключает конфликты множественной записи.
• HDFS оптимизирована под потоковую передачу данных,
• самодиагностика — каждый узел данных через определенные интервалы времени отправляет диагностические сообщения узлу имен, который записывает логи операций

Минусы HDFS

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

Развертывание собственного S3-хранилища

Организовать локальную S3 можно на собственном или арендованном сервере. У этого подхода есть несколько минусов. Вы потратите время разработчиков на организацию собственного хранилища (это нетривиальная задача). Также, возможно, вам придется нанимать новых сотрудников для реализации проекта. Если вы будете развертывать хранилище на физических серверах, вам придется докупать или арендовать серверы по мере роста количества данных (если ваш сервис подразумевает накопление данных, а не только хранение статики). Не стоит забывать и о необходимости резервирования инфраструктуры — добавим к затратам один-два сервера для репликации данных. Если у вас on-premises, добавьте к статье расходов штатного сисадмина и обслуживание инфраструктуры.

Готовое облачное хранилище от провайдера

Готовое облачное хранилище исключает минусы, перечисленные в предыдущем блоке:

• У вас уже есть готовый к работе storage — просто приносите данные.
• Специалисты компании обслуживают как работу хранилища, так и инфраструктуру под ним.
• Гибкость облака позволит легко масштабировать кластеры под рост объема данных.
• Облачное хранилище легче связать с другой инфраструктурой проекта — например, веб-серверами или базами данных (если другую инфраструктуру также арендуете у провайдера). Трафик между элементами системы тарифицироваться не будет.
• Готовые хранилища, как правило, подразумевают встроенную репликацию данных. Например, в Selectel объектное хранилище хранит данные в трех копиях.

Объектное хранилище Selectel

Храните данные аналитики и датасеты для ML-обучения в S3-хранилище, соответствующем 152-ФЗ.

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

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

Проблемы облачных сервисов за пределами РФ

• Самая важная проблема — в том, что на данный момент их просто не купить либо сделать это очень и очень сложно.
• Также существуют законодательные ограничения. В соответствии с постановлением Правительства РФ № 728 от 26.06.2018 г. хранение данных пользователей российских компаний допускается только на территории РФ. Не стоит забывать и о законе «О персональных данных» (152-ФЗ), в котором четко прописаны критерии безопасности хранения данных, в том числе ограничения и даже запрет на передачу персональных данных на территории других государств.
• Еще одна проблема связана с языковым барьером. Поддержку на русском языке предоставляют далеко не все зарубежные сервисы, а привлечение таких специалистов за границей обойдется недешево. Кроме того, на стоимость облачных услуг оказывают влияние и колебания курса валют.
• Наконец, при работе с большими данными требуется канал с большой пропускной способностью. Однако при размещении облачных серверов за границей увеличивается количество точек связности, что снижает скорость передачи Big Data. А при увеличении предела канала придется платить значительно больше.

Сложности Big Data Storage

Ни одна технология не обходится без подводных камней. Есть свои проблемы и у хранения Big Data:

• Большим данным нужна серьезная инфраструктура, которая могла бы справляться с хранением таких объемов информации. Поэтому во многих случаях для этого потребуется довольно сильно вложиться в аренду инфраструктуры.
• Для создания аналитической модели требуется время и солидные массивы данных.
• Трудности представляет и выбор стека технологий под конкретные задачи. Но можно с уверенностью сказать, что с любыми данными, попадающими в категорию Big Data, удобнее, безопаснее и дешевле работать в облаке (исключение могут составлять банковские системы). Тем более, что современные облачные провайдеры предлагают любое необходимое ПО, часто уже полностью готовое к работе.

Работа с Big Data: кто уже использует хранилища больших данных

Программные решения для хранения и обработки больших данных используются сегодня во многих отраслях:

• Структуры государственного управления. Анализ Big Data помогает членам правительств разных стран принимать более взвешенные решения в различных областях: здравоохранении, социальной сфере, экономике, безопасности.
• Промышленные предприятия. Благодаря обработке больших данных руководители предприятий и аналитики сегодня используют методику «предиктивного производства», которая повышает точность прогнозирования спроса.
• Медицина. Анализ данных, собираемых медучреждениями и устройствами IoT (например, фитнес-трекерами), в сочетании с ИИ помогает медикам разрабатывать новые лекарственные препараты и улучшать диагностику заболеваний и лечение пациентов.
• Продажи. За счет обработки Big Data компании в сфере ритейла могут персонализировать ассортимент, повышать качество доставки и удерживать клиентов.
• Интернет вещей. Устройства IoT посылают ценные данные, анализ которых позволяет улучшать эти приборы.
• Недвижимость. Собираемые данные используются для удобства поиска объектов недвижимости. Пользователи сайтов получают персонализированные предложения и могут осматривать понравившиеся дома и квартиры без участия продавца, даже не выходя из дома.
• Спорт. В командных видах спорта обработка огромных объемов информации по игрокам помогает клубам вести качественную селекцию и готовиться к играм с соперниками.
• Сельское хозяйство. Собираемые данные с метеодатчиков позволяют строить прогноз погоды буквально по часам, что помогает сельскохозяйственным предприятиям оперативно реагировать на ситуацию.

Немного статистики

В 2012 году общий объем цифровых данных составил 2,7 зеттабайт (или 2,7 млрд ТБ), увеличившись по сравнению с 2011 годом на 50%. В 2015 году он увеличился еще в 2,4 раза, превысив отметку в 6,5 ЗБ. И с этого момента количество данных в мире начало расти экспоненциально. Причина: накопление больших объемов Big Data, которые чаще генерируются не пользователями, а самими компаниями.

Также наблюдается устойчивый рост прибыли компаний, работающих с большими данными. Уже в 2018 году прибыль от их использования превысила 160 млрд долларов, а в 2019-м вышла на отметку $189 млрд. В настоящее время лидером по обработке больших данных является США, где с этой информацией работает уже более 55% представителей крупного и среднего бизнеса. Не отстает и Китай, где принято более 200 законов по защите персональной информации пользователей.

В России же рынок больших данных делает только первые шаги. С Big Data у нас работают пока только крупные IT-компании и банки. Однако уже есть отечественные компании, специализирующиеся именно на работе с Big Data, — например, Mediascope и oneFactor.

Обзор технологии Big Data в бизнесе

Польза для бизнеса от Big Data связана, во-первых, с возможностью улучшения клиентского опыта от конкретных продуктов или услуг. Во-вторых, большие данные помогают определять перспективные продукты. И в-третьих, анализ Big Data позволяет компаниям привлекать и удерживать клиентов. Например, анализируя трафик абонента, интернет-провайдер может определить, собирается ли человек пользоваться услугой дальше или склонен перейти к другому провайдеру. Это позволяет оперативно реагировать, предлагая клиенту более выгодные условия и качественное обслуживание.

Уровни зрелости аналитики в компании

Кратко опишем, какая аналитика доступна компаниям в зависимости от их уровня зрелости:

• Описательная аналитика. Ее целью является предоставление конкретных фактов: например, сколько пользователей вчера заходили или зарегистрировались в приложении.
• Диагностическая аналитика. Также встречается термин факторный анализ, из чего понятно, что при таком анализе на первый план выходят причины изменений. Пример: поступили данные о выходе из строя устройства IoT. Задача диагностического анализа в том, чтобы разобраться, почему это произошло.
• Прогнозная аналитика. Статистические модели позволяют на основе получаемых данных делать прогнозы о вероятных сценариях развития в какой-либо сфере: от курса ценных бумаг и роста продаж до прогноза погоды.
• Предписательная аналитика. Современный аналитический метод, в основе которого лежат рекомендации ИИ по дальнейшим действиям. Однако конечное решение все равно остается за человеком, а ИИ должен рассматриваться лишь как умный помощник, предлагающий различные варианты.

Заключение о технологиях хранения больших данных

Потенциал Big Data огромен и вывод напрашивается сам собой: работать с большими данными сегодня выгодно многим компаниям. Причем независимо от того, насколько крупная ваша компания и какова ее специфика. Часто лучшим решением является размещение инфраструктуры по сбору и обработке Big Data в облаке.