14 ноября 2018 г.

Что такое BI? Стратегии и решения BI

Что такое Business intelligence?

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

Чем BI отличается от BA?

Business intelligence также называют описательной аналитикой, поскольку она описывает прошлое или текущее состояние. «Она не говорит вам, что делать; она говорит вам, что было и что есть», – говорит Майкл Ф. Горман, профессор операционного управления и науки принятия решений в Университете Дейтона в Огайо.
Сравните это объяснение business intelligence (BI) с определением business analytics (BA) – технологического процесса, с помощью которого программное обеспечение анализирует данные для прогнозирования того, что произойдет (прогнозная аналитика) или что может произойти при использовании определенного подхода (предписывающая аналитика). BA также иногда называют передовой аналитикой.

Как работает бизнес-аналитика? 

13 ноября 2018 г.

Размерные модели – логические или физические?

Размерные модели данных существовали в течение очень долгого времени, почти наверняка их происхождение восходит к первоначальному проекту Data Cube, затеянного Dartmouth University и General Mills в конце 1960-х годов. Привлекательность размерного моделирования проистекает из очевидной простоты моделей и естественного способа, с помощью которого как бизнесмены, так и технические специалисты могут понять, что означают модели. 

Размерные модели имеют два совершенно разных выражения: логическое и физическое. Чисто логическим выражением является пузырьковая диаграмма.

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

Продолжение у нас на сайте


29 октября 2018 г.

Основные принципы метода Кимбалла

Большинство рекомендаций в методе Кимбалла для проектирования, разработки и развертывания системы DW/BI состоит именно в этом: руководство. Есть сотни или тысячи правил во многих книгах Kimball Group, и я признаю, что на протяжении десятилетий нарушала многие из них, сталкиваясь с противоречивыми целями или неприятными политическими реалиями.

Размерная модель – это ключевое преимущество

Метод Кимбалла, описанный во втором издании книги «Инструментарий жизненного цикла данных», ориентирован на размерную модель. Принципы размерного моделирования являются наиболее известным вкладом Ральфа Кимбалла и Kimball Group в мир бизнес-аналитики. Наше внимание сосредоточено на этом, потому что хорошая размерная модель абсолютно необходима для успеха вашего предприятия DW/BI. Если вы правильно подберете модель и правильно произведете ее интеграцию, все остальное – просто.

Размерное моделирование – это групповая деятельность

Даже лучший специалист по размерному моделированию создаст плохую размерную модель, если он работает в одиночку. Многомерное моделирование – это не просто групповое действие, а групповое действие, в котором должно участвовать сообщество бизнес-пользователей. За прошедшие годы мы бесчисленное количество раз отказывались от консалтинговых запросов на разработку модели без учета бизнеса. Или, что еще хуже, боролись за мучительные проекты, когда обещанное участие бизнес-пользователей так и не состоялось.
Это, несомненно, важнейшее требование пользовательского сообщества. Наш процесс проектирования обычно занимает 50-60 часов в течение 4-6 недель (или более, в зависимости от сложности проекта). Люди, участие которых необходимо в проектных сессиях, чрезвычайно важны для получения положительного результата. Но если их не убедить вложить время и энергию, полученная система в итоге не сможет работать эффективно.

Размерная модель самая лучшая спецификация для системы DW/BI

15 октября 2018 г.

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

Хранение данных никогда не было более ценным и интересным занятием, чем сейчас.

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

9 октября 2018 г.

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

Владелец хранилища данных должен решить, как реагировать на изменения в описаниях размерных сущностей, таких как «Сотрудник», «Клиент», «Продукт», «Поставщик», «Местоположение» и другие. За 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 года. Это имеет много интересных побочных эффектов, а каких - узнаете у нас на сайте! Продолжение

3 октября 2018 г.

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

Понятие времени пронизывает каждый уголок хранилища данных.

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

Три типа

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

28 сентября 2018 г.

Различия между хранилищем данных и бизнес-аналитикой

Попробуйте спросить своего коллегу, в чем разница между бизнес-аналитикой и хранилищем данных. Я считаю, что многие люди, даже те, кто работает в BI-проектах и BI-индустрии, не понимают разницы. Большинство из них считают, что эти 2 термина взаимозаменяемы. Кто-то предпочитает использовать один термин вместо другого лишь потому, что он просто «звучит лучше». Многие полагают, что бизнес-аналитика – это не только хранилище данных, а нечто большее. Но если их спросить: «Какие системы бизнес-аналитики не являются системами хранилищ данных» или «какая часть бизнес-аналитики не является хранилищем данных», то большинство затрудняется ответить.

В наши дни термин «бизнес-аналитика», а не «хранилище данных» является нормой, используемой большинством поставщиков в отрасли. Большинство из них называют/классифицируют свои инструменты как программное обеспечение бизнес-аналитики, а не программное обеспечение хранилища данных. Название продукта Cognos – «Cognos 8 Business Intelligence». BusinessObjects обозначают себя как «BI-софтверная компания» и «мировой лидер в области программного обеспечения BI». Название одного из продуктов Hyperion – «Hyperion System 9 BI +». SAS Enterprise BI Server предоставляет полностью интегрированный комплексный набор программного обеспечения для бизнес-аналитики. Microsoft продвигает SQL Server 2005 как комплексную платформу бизнес-аналитики. Кажется, что только Kimball Group последовательно использует термин «хранилище данных». Билл Инмон, как изобретатель этого термина, также использует термин «хранилище данных».
Итак, давайте перейдем к деталям. Продолжение.

24 сентября 2018 г.

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

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

Глоссарий состоит из 2 уровней. На первом уровне термины расположены в алфавитном порядка, а на втором – нет. Таким образом, лучший способ использовать этот глоссарий – поиск по странице (Ctrl-F).
Людям свойственно ошибаться, так что я уверен, что в этой статье есть ошибки. Я был бы признателен, если бы вы в чем-то поправили меня, используя комментарии под публикацией или написав мне на vrainardi@gmail.com.
Что меня сподвигло к написанию этой статьи: я заметил, что многие люди, работающие с хранилищем данных, часто не понимают некоторую стандартную терминологию. Даже самый простой термин, такой как «измерение», может быть для них иностранным словом. Мое намерение состоит в том, чтобы обеспечить «быстрый поиск», позволяя им понять термин примерно за 15 секунд или около того.
Почему бы им не использовать интернет-поиск или Википедию? Зачем создавать еще что-то? Потому что:
  1. Для поиска информации в интернете требуется больше времени, особенно если вы новичок.
  2. Страницы результатов поиска могут быть технически неправильными.
  3. Иногда я придерживаюсь своего мнения или предпочитаю иначе расставлять акценты.
Archiving – Архивирование: подход, заключающийся в удалении старых данных из таблицы фактов и хранении их в другой таблице (обычно в другой базе данных). Довольно часто старые данные просто удаляются и больше нигде не хранятся. 


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

17 сентября 2018 г.

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

Таблица фактов со смешанными гранулами – это таблица фактов, в которой у нас есть меры с различной гранулярностью. Например, одна мера является еженедельной, а другая – ежемесячной. В этом посте я хотел бы рассказать о преимуществах и недостатках этого подхода. 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 заключается в том, что гранулярность в таблице фактов является смешанной – есть две гранулы. На практике мы имеем другие ключевые столбцы измерения в таблице фактов. И еще у нас есть другие столбцы мер в таблице фактов. Некоторые из этих мер еженедельные, а некоторые – ежемесячные.

9 сентября 2018 г.

Может ли машинное обучение заменить BI?

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

Business Intelligence (Бизнес-аналитика)

Это – пример типичной информационной панели BI для продаж (источник). На панели мониторинга представлены данные о продажах. Сверху – это продажи и прибыль с течением времени и по продукту. А внизу – продажи по продавцам и прибыль по клиентскому сегменту и товарной группе.
На основании этих данных компания может принимать такие бизнес-решения, как:
  1. Увеличить или уменьшить маржинальную прибыль для определенной группы продуктов.
  2. Сосредоточить маркетинговые усилия на конкретном потребительском сегменте, чтобы увеличить продажи.
  3. Реструктурировать отделы продаж, чтобы повысить эффективность продаж.
Таким образом, BI помогает руководству лучше управлять бизнесом, позволяя лучше понимать текущие и прошлые бизнес-ситуации.

Машинное обучение (ML – machine learning)

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

29 августа 2018 г.

PostgreSQL: Linux VS Windows – часть 2!

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

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

Последовав совету, я не стал использовать свой прежний инструмент тестирования. Для второго теста «Windows vs Linux для хостинга PostgreSQL» я использовал PgBench.
Следуя этому совету, я проводил тест с данными, превышающими размер памяти и с большой продолжительностью. М4.xlarge на Amazon имеют 16 Гб данных, а при масштабе 2000, PgBench генерирует БД ±30 Гб.
PgBench, для тех, кто не в курсе (как я), делает тоже самое, что и написанное мной приложение для тестирования, но лучше!
Он имеет большое количество опций и тщательно тестируется, в отличие от моего приложения, которое только было протестировано... только мной.
PGBench – это не совсем то, что я хотел, потому что я хотел провести тест с помощью .NET-приложения, которое использует npgsql (PgBench использует libpq), но, как говорится, «в Риме поступайте, как римляне».

Архитектура для тестов совпадает с предыдущей:
«Клиент»
Сервер Windows 2012 R2 на amazon, тип m4.xlarge, со всеми настройками по умолчанию.
Клиентским «приложением» выступает PgBench.
«Сервер Windows Postgresql» (далее – WS)
Сервер Windows 2012 R2 на Amazon, тип m4.xlarge, со всеми настройками по умолчанию и 100 GB SSD.
PostgreSQL 9.4.5 установлен с помощью мастера.
Я изменил listen_addresses на * и внес необходимые изменения в pg_hba.conf для подключения к работе.
«Сервер PostgreSQL для Linux» (далее – LS)
Amazon Linux AMI, тип m4.xlarge, со всеми настройками по умолчанию и 100 GB SSD.
PostgreSQL 9.4.5 установлен с yum.
Я внес те же самые изменения в postgresql.conf и pg_hba.conf, которые я делал для Windows.

Сценарий

15 августа 2018 г.

PostgreSQL: Linux VS Windows!

В сентябре, по приглашению 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 и, чтобы реализовать его функционал, нужно использовать потоки или...

7 августа 2018 г.

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

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

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

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

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

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

3 августа 2018 г.

Привет, Hitachi Vantara!

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

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

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

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

25 июля 2018 г.

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

Предположим, что у нас есть 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 столбцов), то у нас будет ... Читать далее

14 июля 2018 г.

15 примеров визуализации данных

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

22 апреля 2018 г.

5 шагов погружения в DWBI

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

 Этап 1. Составление отчетов (Стоимость: £25 тыс./год. Длительность: 2-3 года)

В большинстве компаний BI-подразделение начиналось с одного сотрудника IT-отдела, занимающегося составлением отчетов. IT-отделу ставилась задача – подготовить сводный бизнес-отчет для какого-либо собрания на основе информации из базы данных. Отчет формировался с помощью встроенных средств отчетности – SSRS, Jasper или Crystal. Тогда никто ничего не слышал о Business Intelligence. Руководству требовался просто «Отчет», не BI и даже не Management Information.

Компания, состоящая из 100 сотрудников и имеющая годовой оборот в размере 5 млн. фунтов стерлингов, обходилась IT-отделом, в котором было всего 5 человек. Они в основном занимались технической поддержкой – Exchange и Email, администрированием файлового и SQL-серверов, локальной сети. Подготовка отчета для них была всего лишь одной из множества задач.

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

Сколько это стоит? Расходы на этом этапе составляют около 20-25 тыс. фунтов стерлингов в год.

Читать далее...