?

Log in

No account? Create an account

sanatel


Sanatel Consulting

Внедрение систем CRM (система управления взаимоотношениями с клиентами) и BI (бизнес аналитика)


Светлое будущее
sanatel

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

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

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

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


Медленно меняющиеся измерения (часть 2)
sanatel

Владелец хранилища данных должен решить, как реагировать на изменения в описаниях размерных сущностей, таких как «Сотрудник», «Клиент», «Продукт», «Поставщик», «Местоположение» и другие. За 30 лет изучения этого вопроса, я обнаружил, что необходимы только три различных типа реакций. Я называл эти медленно меняющиеся размеры (SCD) типами 1, 2 и 3. В прошлой статье, я описал Тип 1 (SCD Type 1), который перезаписывает измененные данные в измерении. В этой статье я разберу типы 2 и 3 (SCD Type 2 и SCD Type 3).

Тип 2 (SCD Type 2): добавление новой записи измерения

Давайте изменим сценарий предыдущей статьи, где я переписал поле «Город проживания» в записи сотрудника Ральфа Кимбалла, и предположим, что Ральф Кимбалл действительно переехал из Санта-Крус в Боулдер-Крик 18 июля 2008 года. Предположим, что наша политика заключается в точном отслеживании домашних адресов сотрудников в хранилище данных. Это классическое изменение SCD Type 2.

SCD Type 2 требует, чтобы мы выпустили новую запись сотрудника для Ральфа Кимбалла с 18 июля 2008 года. Это имеет много интересных побочных эффектов, а каких - узнаете у нас на сайте! Продолжение


Азбука хранилища данных
sanatel

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

Глоссарий состоит из 2 уровней. На первом уровне термины расположены в алфавитном порядка, а на втором – нет. Таким образом, лучший способ использовать этот глоссарий – поиск по странице (Ctrl-F).

Людям свойственно ошибаться, так что я уверен, что в этой статье есть ошибки. Я был бы признателен, если бы вы в чем-то поправили меня, используя комментарии под публикацией или написав мне на vrainardi@gmail.com.

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

Почему бы им не использовать интернет-поиск или Википедию? Зачем создавать еще что-то? Потому что:


  1. Для поиска информации в интернете требуется больше времени, особенно если вы новичок.

  2. Страницы результатов поиска могут быть технически неправильными.

  3. Иногда я придерживаюсь своего мнения или предпочитаю иначе расставлять акценты.

Archiving – Архивирование: подход, заключающийся в удалении старых данных из таблицы фактов и хранении их в другой таблице (обычно в другой базе данных). Довольно часто старые данные просто удаляются и больше нигде не хранятся.

Продолжение

перевод статьи Vincent Rainardi


Таблица фактов со смешанными гранулами
sanatel

Таблица фактов со смешанными гранулами – это таблица фактов, в которой у нас есть меры с различной гранулярностью. Например, одна мера является еженедельной, а другая – ежемесячной. В этом посте я хотел бы рассказать о преимуществах и недостатках этого подхода. Kimball Group однозначно заявила, что меры в таблице фактов должны иметь одинаковую гранулярность (см. главу 2 книги Кимбалла – The Data Warehouse Toolkit).

Но всегда проще объяснить на примере:

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

Две таблицы фактов


Или мы должны создать таблицу фактов смешанных гранул, например такую (№2):

Таблица фактов смешанных гранул


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

select D.Week, sum(F.WeeklyMeasure) from FactMixedGrain F
join DimDate D on F.DimDate = D.DimDate group by D.Week

Результат:

Еженедельные итоги

select D.Month, sum(F.MonthlyMeasure) from FactMixedGrain F
join DimDate D on F.DimDate = D.DimDate group by D.Month

Результат:

Ежемесячные итоги


Обычно основная причина исполнения варианта №2 состоит в необходимости хранить еженедельные и ежемесячные показатели в одной таблице фактов. Это позволяет сэкономить время на разработку, особенно в части ETL. Легче заполнить одну таблицу, чем две.

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

Продолжение http://sanatel.kz/paper_mixed_grain_fact_tables.htm

PostgreSQL: Linux VS Windows!
sanatel

В сентябре, по приглашению Dalibo, я был в Париже на Postgresql Sessions. Еще раз спасибо за приглашение! Это было событие, которое изменило мою жизнь!

Во время разговора с некоторыми сотрудниками Dalibo, один из них сделал замечание, которое я воспринял как внутренний вызов. Он сказал, что PostgreSQL на ОС Linux, запущенной в виртуальной машине на Windows, работает быстрее, чем PostgreSQL на той же Windows.

Поскольку я новичок в мире PostgreSQL/Linux, я был озадачен этой информацией, но когда я спросил точные цифры, у него их не было. Тогда я понял, что это была просто шутка (я быстро понимаю шутки, особенно со второго или третьего повтора), и что он просто имел в виду, что PostgreSQL на Linux работает быстрее, чем на Windows.

Архитектура Linux в сравнении с архитектурой Windows

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

Linux может использовать fork, а Windows – нет!

Но, что, черт возьми, это такое – fork? Если кратко, то fork – это системный вызов, который позволяет процессу создавать дочерние процессы, при этом продолжая работу параллельно с ними. Они могут делиться своей памятью и взаимодействовать друг с другом.Это стандартный метод разработки в среде Unix/Linux, но он не может быть применен в Windows... поскольку fork не существует в Windows.

Fork не поддерживается архитектурой Windows и, чтобы реализовать его функционал, нужно использовать потоки или...

Продолжение


Привет, Hitachi Vantara!
sanatel

Два года назад компания Pentaho была приобретена корпорацией Hitachi Data Systems и вошла в состав Hitachi Group. Сегодня появилась новая информация о дальнейшем развитии Pentaho

19 сентября 2017 года, произошло важное событие. Родилась новая компания. Знакомьтесь: Hitachi Vantara. Hitachi Vantara объединяет Hitachi Data Systems, Hitachi Insight Group и Pentaho в единый проект.


Привет, Hitachi Vantara!


Что это означает?

Мы всегда стремились к тому, чтобы позволить нашим клиентам строить высокопроизводительные решения, основанные на анализе данных. Я считаю, что у нас это отлично получалось! И теперь мы хотим достичь нового уровня – стать лучшими не только в Big Data и аналитике, но и ведущим игроком в решениях в области Интернета вещей (IoT). А объединение в Hitachi Vantara позволит нам это сделать!


Что изменится?

Очевидно, что Pentaho, как продукт, продолжит существовать. А Pentaho, как компания, будет действовать в составе Hitachi Vantara. Это дает нам огромные возможности для развития продукта: мы сможем сосредоточиться на основной задаче наших решений (обработке и аналитике Big Data), но при этом пользоваться разработками на стыке операционных (ОТ) и информационных технологий (ИТ) других компаний, входящих в Hitachi Vantara.

Также мы займемся улучшением совместимости продуктов. Хотя до объединения в Hitachi Vantara наше отношение к этому было очень скептичным, сейчас стоит добавить одну маленькую деталь: нам нужно больше работать со своими решениями – потому что мы это можем!

Продолжение


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

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

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


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

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


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

Я все еще (больше, чем когда-либо?) являюсь большим сторонником...

Продолжение


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

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

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

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

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

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

Я все еще (больше, чем когда-либо?) являюсь большим сторонником ...

Продолжение


Большие данные или хранилище данных: что выбрать?
sanatel

Предположим, что у нас есть 100 файлов, каждый из которых содержит 10 миллионов строк, и нам нужно загрузить их в репозиторий для того, чтобы мы могли проанализировать данные. Как лучше всего поступить? Воспользоваться Hadoop (HDFS) или реляционной СУБД (RDBMS)?

На прошлой неделе я обозначил разницу между большими данными и хранилищем данных: большие данные – это Hadoop, а хранилище данных – это РСУБД. Подробности можно прочитать в моей статье. Сегодня я хотел бы проиллюстрировать на примерах, в каких случаях предпочтителен Hadoop, а в каких – хранилище данных.

Рассмотрим 4 фактора:


  1. Структура данных.

  2. Объем данных.

  3. Неструктурированные данные.

  4. Schema-on-Read (схема при чтении).


1. Структура данных: простая или сложная

Если все 100 файлов имеют одинаковую структуру, например, все они состоят из одних и тех же 10 столбцов, то лучше поместить их в Hadoop. Затем мы сможем использовать Hive, Spark, Presto, R или Python * для анализа данных – например, для поиска закономерностей в данных, выполнения статистического анализа или создания прогнозов. Время разработки будет короче, потому что это только 1 слой.
* или Phoenix, Impala, BigSQL, Stinger, Drill

Если 100 файлов содержат 100 разных таблиц, лучше поместить их в базу данных, создать хранилище данных и использовать аналитический BI-инструмент, такой как Pentaho или MicroStrategy * для анализа данных. Например, чтобы получить срезы данных, найти процент или аномалии и провести анализ временных рядов. Да, нам будет необходимо создать 3 слоя (staging, 3NF, star schema), но это позволит анализировать каждый показатель по различным параметрам.
* или Looker, PowerBI, Tableau, QlikView, BusinessObjects, Cognos BI, Birt, Pentaho, Roambi, SAS, Sisense или другие инструменты BI

Поэтому, если структура данных простая, поместите их в Hadoop, а если сложная – в хранилище данных. Это общее правило, но иногда из него бывают исключения. Можно ли поместить данные с простой структурой в хранилище данных? Конечно можно. Могут ли данные со сложной структурой быть помещены в Hadoop? Несомненно.

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

Проблема заключается в хранении. Связывание 100 таблиц в Hadoop – сложно и неестественно. РСУБД, такие как SQL Server или Oracle, предназначены именно для этой задачи: связывания и объединения таблиц. Построение модели данных, связывающей 100 таблиц, очень подходит для РСУБД. Можем ли мы спроектировать модель данных, связывающую 100 файлов с различными структурами в Hadoop? Конечно, мы можем это сделать. Но это гораздо сложнее. Во-первых, это Schema-on-Read, поэтому столбцы в файлах не имеют типов данных. Schema-on-Read означает, что мы не пытаемся определить взаимосвязь между файлами при их загрузке в Hadoop. Так что да, мы можем загрузить 100 файлов в Hadoop, но мы сохраняем их как отдельные файлы, без связей между ними. То же самое происходит и в Data Lake, где также используется Schema-on-Read и HDFS.


2. Объем данных: маленький или большой

100 файлов, содержащих 10 миллионов строк каждый, составляют 1 миллиард строк в день. Если все 100 файлов имеют одинаковую структуру (скажем, все они состоят из одних тех же 10 столбцов), то у нас будет... Читать далее


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

Data Visualization

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


Путь к качественной визуализации данных – о чем нужно помнить?

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

Читать далее http://sanatel.kz/paper_data_visualization.htm