Когда витрина данных можно заменить массивом
Перейти к содержимому

Когда витрина данных можно заменить массивом

  • автор:

Витрины данных DATA VAULT

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

Как я анонсировал в предыдущей публикации, эта статья будет посвящена теме BI, а точнее подготовке DATA VAULT в качестве источника данных для BI. Рассмотрим, как создать таблицы фактов и измерений и, тем самым, создать схему звезда.

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

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

И так, давайте переходить к сути.

Таблицы измерений и фактов в DATA VAULT

Самое сложная для понимания информация:

  • Таблицы измерений строятся на информации хабов и их сателлитов;
  • Таблицы фактов строятся на информации линков и их сателлитов.

На этом теория, в принципе заканчивается.

Но, все же, на мой взгляд, необходимо отметить пару понятий, которые могут встретиться в статьях о методологии DATA VAULT:

  • Raw Data Marts – витрины “сырых” данных;
  • Information Marts – информационные витрины.

Понятие “Information Marts” появилось в методологии Data Vault 2.0, оно заменило старое понятие “Data Marts”. Это изменение обусловлено осознанием задачи по реализации модели данных для построения отчетов как преобразование данных в информацию. Схема “Information Marts”, в первую очередь, должна обеспечивать бизнес пригодной для принятия решений информацией.

Достаточно многословные определения отражают два простых факта:

  1. Витрины типа “Raw Data Marts” строятся на сыром (RAW) DATA VAULT, хранилище содержащем только базовые понятия: HUBS, LINKS, SATELLITES;
  2. Витрины “Information Marts” строятся с использование элементов BUSINESS VAULT: PIT, BRIDGE.

Создание витрины, хранящей актуальную информацию каждого атрибута нескольких сателлитов, входящего в хаб, например, номер телефона, адрес, ФИО, подразумевает использование PIT таблицы, через обращение к которой легко получить все даты актуальности. Витрины такого типа относят к “Information Marts”.

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

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

Этой статьей я завершаю цикл о концепции DATA VAULT, надеюсь информация, которой я поделился будет полезна в реализации ваших проектов.

Как всегда, в завершении, несколько полезных ссылок:

  • Статья Кента Грациано, в которой помимо детального описания содержатся схемы модели;
  • Книга: “Building a Scalable Data Warehouse with DATA VAULT 2.0”;
  • Статья “Основы Data Vault”;
  • Статья “Развитие DATA VAULT и переход к BUSINESS DATA VAULT”.

Передача данных из одного массива в другой

Всем привет. Столкнулся с такой проблемой: Мне надо из массива данных (массив1) прочитать 245 байт и положить в другой массив (массив2), после чего повторить операцию, пока первый массив (массив1) не закончится, если в конце массива1 останется меньше 245 байт, то прочитать остаток и положить его в массив2. Имеется вот такой код:

public static void myclass123(int keySize) < byte[] data = new byte[245]; byte[] cipher = new byte[keySize]; DataInputStream fis = new DataInputStream(new DataInputStream("/home/admin/workspace/myproject1/Test.txt")); DataOutputStream fos = new DataOutputStream(new FileOutputStream("/home/admin/workspace/myproject1/Data.enc")); int ret = 0, count = 0; while( (ret = fis.read(data)) >0 ) < fos.write (cipher = cf.doFinal(data, 0, ret)); count += ret; >> 

И все работает чудесно, пока fis у нас DataInputStream , но задача изменилась, и теперь вместо DataInputStream у меня byte[] MyArray1 .
Теперь, когда я передаю массив в класс, например, вот так:

public static void myclass123(int keySize, byte[] fis) < byte[] data = new byte[245]; byte[] cipher = new byte[keySize]; //DataInputStream fis = new DataInputStream(new DataInputStream("/home/admin/workspace/myproject1/Test.txt")); DataOutputStream fos = new DataOutputStream(new FileOutputStream("/home/admin/workspace/myproject1/Data.enc")); int ret = 0, count = 0; while( (ret = fis.read(data)) >0 ) < fos.write (cipher = cf.doFinal(data, 0, ret)); count += ret; >> 

ему не нравится fis.read(data) , он говорит Cannot invoke read(byte[]) on the array type byte[] , предлагает заменить на fis.lenght и убрать ( data ), после чего конструкция работает, только пишет в /home/admin/workspace/myproject1/Data.enc 0 байт, создает пустой файл — и тишина. Сломал голову уже, честно признаю, что еще плохо понимаю, как работают массивы и java в принципе, но учусь, прошу помочь, уважаемые специалисты. Спасибо.

Витрины данных: определение, типы и преимущества

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

Что такое витрина данных?

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

Кто использует витрины данных?

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

  • Финансы. Витрины финансовых данных помогают компаниям разделять финансы по категориям и хранить отдельные наборы финансовых данных. Это может быть особенно полезно для финансового планирования.
  • Продажи: отделы продаж часто используют витрины данных для сбора данных по конкретным методам продаж или для планирования рекламных периодов. Например, отдел продаж может собирать данные о праздничном сезоне.
  • Маркетинг. Команды по маркетингу могут использовать витрины данных для отделения данных от хранилища данных, которое представляет собой набор общих данных, для быстрого доступа. Специалисты по маркетингу используют данные о клиентах, продуктах и ​​аналитику для создания эффективных маркетинговых кампаний.

Преимущества витрин данных

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

  • Централизованные данные: витрины данных помогают централизовать определенные наборы данных, чтобы каждый мог получать информацию из одного источника. Это помогает предотвратить расхождения данных и уменьшает количество ошибок.
  • Масштабируемое управление данными. Витрины данных обеспечивают большую масштабируемость наборов данных, что означает возможность роста по мере изменения потребностей компании. Команды могут масштабировать данные в киоске данных, чтобы обеспечить соответствие бизнес-требованиям к данным.
  • Быстрое внедрение: витрины данных более специфичны, чем более крупные хранилища данных, что позволяет ускорить и упростить их внедрение. Это может сэкономить время и деньги для компании.
  • Быстрый доступ к данным: витрины данных упрощают для команд просмотр наборов данных и более быстрый доступ к определенным данным. Это может значительно ускорить процесс сбора данных и сэкономить время и деньги.
  • Лучшее принятие решений: имея доступ к более быстрым и более точным наборам данных, команды могут принимать более эффективные решения на основе реальной информации. Это может повысить общую эффективность и снизить затраты.
  • Низкая стоимость: создание витрины данных может стоить значительно меньше, чем полноразмерное хранилище данных для бизнеса. Затем компания может реинвестировать эти сбережения в другие части бизнеса.

Типы витрин данных

Вот три типа витрин данных:

1. Зависимые витрины данных

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

2. Гибридные витрины данных

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

3. Независимые витрины данных

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

Структуры витрин данных

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

Звездная схема

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

Сейф

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

Схема снежинки

Модель снежинки является расширением модели звезды. Он использует существующую схему витрины звездных данных и предоставляет дополнительные измерения данных для центрального набора данных. Благодаря дополнительным таблицам модель «снежинка» предоставляет обширные наборы данных и требует меньше места на диске для хранения и обслуживания.

Как использовать витрину данных

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

1. Разработайте стратегию витрины данных вашей компании

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

2. Создайте архитектуру витрины данных

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

3. Заполните архитектуру витрины данных

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

4. Получите доступ к своим витринам данных

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

6 практических советов для начинающих при построении простого BI-решения

Данной статьей хотелось бы показать шаги и предложить некоторые рекомендации в процессе создания BI-решения с использованием практически всего стека BI компании Microsoft. В создании BI-решения будут использованы SQL Server, SQL Service Integration Services, SQL Server Analysis Services.

Для примера мы выбрали разработку нашей компании RetailIQ — BI-систему глубокого анализа чеков розничных продаж, поставок и складских запасов для сети аптек. Для общего понимания контекста темы: все данные выгружаются из учетных систем (1С, М-Аптека и т.д.), верифицируются, складываются в специальную базу данных с последующим построением многомерных OLAP-кубов. Из источников (учетных систем) с помощью ETL мы перекачиваем данные в хранилище, на основе которого строим куб, о котором дальше пойдет речь.

Построение витрины данных

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

На данном шаге решается, какие данные нужно отобразить (остатки, продажи и т.д.) и в каких разрезах (например, продукт, дата, сотрудник, филиал).

Определяются источники данных, из которых можно получить данные (файлы, web-сервисы, другие БД). Какие преобразования необходимо сделать в получаемых данных для поддержания целостности.

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

Совет #1 Источниками для куба должны быть представления (View)

Источники для OLAP-куба, на наш взгляд, лучше всего делать в виде представлений, а не привязывать непосредственно к таблице. Это позволит делать любые изменения в источнике, не меняя сам OLAP-куб. Также, на наш взгляд, лучше всего не делать запрос в самом Data Source View, так как изменения в DSV проекта SSAS делать проблематично.

Создаем ETL

ETL – это процесс передачи и трансформации данных согласно определенным бизнес-правилам. Для данного шага у нас есть некоторое количество рекомендаций.

Совет #2 Строки NA

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

Например, пусть у нас есть таблица Car, у которой есть привязки к таблицам CarType и CarMark. Делаем примерно так:

INSERT INTO CarType (ID, Name) VALUES (0, ‘NA’) INSERT INTO CarMark (ID, Name) VALUES (0, ‘NA’) INSERT INTO Car (ID, Name, CarTypeID, CarMarkID) VALUES(0, ‘NA’, 0, 0) 
Совет #3 Суррогатные ключи

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

  • сможем определить NA элемент
  • первичные ключи из разных источников могут совпадать
  • у нас есть свобода выбора формата первичного ключа в нашей БД (например, можем использовать Guid, даже если в источниках используется INT).
Совет #4 Установка NA значений в ETL пакете

Если в источнике фактов значения ячеек CarID и EmployeeID содержат NULL, либо те данные, которые отсутствуют в наших измерениях, то используем следующее преобразование:

В обоих Lookup-ах поле “Specify how to handle rows with no matching entries” устанавливаем значение “Ignore failure”. Таким образом, неизвестные ключи будут иметь значение NULL. В элементе “Set NA To Dimension” NULL заменяем на значение NA для каждого измерения.

Совет #5 Документирование ETL

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

По данной таблице можно легко определить, откуда и куда данные “перетекают”.

Создаем куб

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

Обычно OLAP-кубы созданные с помощью SSAS не очень хорошо работают с измерениями, которые содержат большое количество записей. По нашему мнению лучше всего избегать случаев, когда дата и время находятся в одном измерении. Предположим, мы хотим создать измерение Дата-Время, в которой будет точность до секунды. Записей в данном измерении за 10 лет будет: 10 лет * 365 дней * 24 часа * 60мин * 60 сек = 315 360 000 ≈ 315 млн записей.

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

Совет #6 Создание иерархий с одинаковыми элементами

Предположим у нас есть задача построения иерархии: Тип автомобиля->Марка автомобиля->Название автомобиля из таблицы вида:

CarID Name CarTypeID CarType CarMarkID CarMark
1 Mercedes-Benz F 800 Style 1 Sport 1 Mercedes
2 Smart 2 Microcar 1 Mercedes

CarID в данном случае будет ключом к измерению, а CarTypeID и CarMarkID атрибуты измерения. Предполагаем, что после процессинга куба получим следующее:

Но, к сожалению, так просто не получится, группа Mercedes будет принадлежать либо Sport, либо Microcar (зависит, какая строка будет обработана в первую очередь). Данное ограничение можно обойти с помощью составного ключа для атрибута. Сделаем ключ для атрибута CarMark вида CarTypeID + ‘_’ + CarMarkID. В итоге на входе в куб получим примерно такую таблицу:

CarID Name CarTypeID CarType CarMarkID CarMark
1 Mercedes-Benz F 800 Style 1 Sport 1_1 Mercedes
2 Mercedes-Benz F 800 Style 2 Microcar 1_2 Mercedes

В результате получим необходимую для нас иерархию.

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

Источники
Основные информацию о кубах можно прочитать в статье habrahabr.ru/post/66356.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *