BI, Data Analyst, Data Mining несколько вопросов.

[Ol]

добрый день.


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

http://social.msdn.microsoft.com/Forums ... isservices

[ie]

Не получится всё равно. У нас пару месяцев назад вроде написали кубы, и толку. "Любые дропдауны" казалось бы. А всё равно приходится сгружать в Excel и переделывать 90% отчётов. Плюс к тому, "любые дропдауны" как оказалось вовсе не любые, не все нужные кубы написали. ведь отчёты нужны мгновенно. Пришла в голову босса светлая идея - завтра отчёт должен быть готов. А новый куб ждать надо неделями. Вот и приходится всю несколько таблиц тупо сгружать в Excel почти полностью, и там уже работать с данными.

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

[mynameiszb]

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

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

[Kateryna]

С другой стороны, я давно не могу понять, зачем в наш век быстрых технологий, когда практически любой бизнес аналист знающий SQL/R (а эти skills сейчас практически по умолчанию), нарисует вам любой кастомизированный отчёт, и быстро, нужны какие-то особенные BI tools? Мне кажется, достаточно чтобы можно было достать данные из базы в более-менее удобоваримой форме и причесать их сиквелом. Остальное делается в R. Разве что у вас таки Big Data, которая в R не влазит (R ограничен оперативной памятью), но тогда Revolution Analytics вроде бы за $1000 продают решение этой проблемы.

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

Не получится всё равно. У нас пару месяцев назад вроде написали кубы, и толку. "Любые дропдауны" казалось бы. А всё равно приходится сгружать в Excel и переделывать 90% отчётов. Плюс к тому, "любые дропдауны" как оказалось вовсе не любые, не все нужные кубы написали. ведь отчёты нужны мгновенно. Пришла в голову босса светлая идея - завтра отчёт должен быть готов. А новый куб ждать надо неделями. Вот и приходится всю несколько таблиц тупо сгружать в Excel почти полностью, и там уже работать с данными.

Excel наше все!!! Программа всех времен и народов. Возникает только несколько вопросов и выводов.

-Нафига было тратить деньги и время на кубы (покупать программы, базы данных, сервера под них, инсталлировать, разрабатывать кубы и отчеты, обучать пользователей итд) если все равно таблицы можно сгрузить в Excel , т.е. данных там далеко не террабайты и даже наврное не миллион транзакций. Почему когда планировали отчеты не учли реальные требования компании, кто готовил requirements? Если 90% отчетов не подходят, то проект по внедрению кубов и отчетов это просто выброшенные деньги на ветер

- Какую такую сложнейшую и срочнейшую бизнес проблему решил ваш босс со светлой головой с помощью ваших отчетов в Excel-е? сколько конкретно времени сотрудников или денег компании было потрачено на построение отчетов в Excel-е против сколько денег было сохранено на основании выводов из отчета в Excel-е?


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

Сценарий действительно жизненный и я с ним сталкивалась когда как раз работала full time Developer DBA Обычно дальше два пути

1. Нафиг некому не нужный кастом отчет не приносит никакой пользы и о нем благополучно забывают через 3 дня. Зато светлоголовые боссы или сотрудники (очень часто с PhD и полным отсутствием понимания чем же компания занимается) показали всем какие они крутые

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

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

[mynameiszb]

В общем, мой опыт такой, что намного еффективнее научить пару-тройку пользователей SQL (not a rocket science, really) и дать им доступ ко всему. Не надо к production, дайте доступ к back-up, меня даже недельной старости устроит. Но фиг вам.

Вот когда руководство дорастает от ступеньки "фиг вам" до "давайте дадим им базу с аналитикой", тогда этим rocket science вполне поможет админ-архитект баз данных. Который по их запросам сможет сделать что-то промежуточное, на котором можно уже играться с цифрами. И где будет некая выжимка, которая позволит получать ответ на "отчет 21 и еще штук сто сверху" за минуты, а не за 5-6 часов ковыряния в миллионах транзакций.

[Kateryna]

В общем, мой опыт такой, что намного еффективнее научить пару-тройку пользователей SQL (not a rocket science, really) и дать им доступ ко всему. Не надо к production, дайте доступ к back-up, меня даже недельной старости устроит. Но фиг вам.

Вот когда руководство дорастает от ступеньки "фиг вам" до "давайте дадим им базу с аналитикой", тогда этим rocket science вполне поможет админ-архитект баз данных. Который по их запросам сможет сделать что-то промежуточное, на котором можно уже играться с цифрами. И где будет некая выжимка, которая позволит получать ответ на "отчет 21 и еще штук сто сверху" за минуты, а не за 5-6 часов ковыряния в миллионах транзакций.

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

ну и если кубы вам не подходят, в транзакционные базы вас не пускают (и правильно делают, так как вероятность пользы вашего запроса 1% как вы сами написали. а вероятность положить всю базу и поставить раком весь бизнесс процесс в компании 80-90%), то вам не back-up нужен, а дата варехауз с реляционными таблицами где вы свои аналитические кастом промежуточные запросы будете выполнять. А для этого действительно нужен админ-архитект-девелопер ETL

А вообще какие у вас объемы данных, ну хоть приблизительно? Меня терзают смутные сомнения, что что-то существенное в плане предиктив аналитик можно извлечь из достаточно больших исторических архивов данных. Т.е. точно не на том уровне что Excel может поддерживать

Вообщем, хорошее описание ситуации для топик стартера, если он еще читает этот топик.

[Ol]

Не получится всё равно. У нас пару месяцев назад вроде написали кубы, и толку. "Любые дропдауны" казалось бы. А всё равно приходится сгружать в Excel и переделывать 90% отчётов. Плюс к тому, "любые дропдауны" как оказалось вовсе не любые, не все нужные кубы написали. ведь отчёты нужны мгновенно. Пришла в голову босса светлая идея - завтра отчёт должен быть готов. А новый куб ждать надо неделями. Вот и приходится всю несколько таблиц тупо сгружать в Excel почти полностью, и там уже работать с данными.

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

Никто не спорит, что корявое BI можно найти где угодно. Я вам соболезную, что для вас такое - повседневная реальность. Однако мой опыт прямо противоположный. Tак пример, один из моих бывших клиентов ( 4года назад делал им кубы подключенные к шарепоинту) держит постоянно открытый оффер специально для меня время от времени повышая предлагаемую ставку. Последнее что предложили $125, 25 часов в неделю, удаленка.

[Kateryna]

Не получится всё равно. У нас пару месяцев назад вроде написали кубы, и толку. "Любые дропдауны" казалось бы. А всё равно приходится сгружать в Excel и переделывать 90% отчётов. Плюс к тому, "любые дропдауны" как оказалось вовсе не любые, не все нужные кубы написали. ведь отчёты нужны мгновенно. Пришла в голову босса светлая идея - завтра отчёт должен быть готов. А новый куб ждать надо неделями. Вот и приходится всю несколько таблиц тупо сгружать в Excel почти полностью, и там уже работать с данными.

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

Никто не спорит, что корявое BI можно найти где угодно. Я вам соболезную, что для вас такое - повседневная реальность. Однако мой опыт прямо противоположный. Tак пример, один из моих бывших клиентов ( 4года назад делал им кубы подключенные к шарепоинту) держит постоянно открытый оффер специально для меня время от времени повышая предлагаемую ставку. Последнее что предложили $125, 25 часов в неделю, удаленка.

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


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

[crypto5]

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

OLAP решения сильно оптимизированы для того что бы делать slice&dice и считать сложные многомерные агрегации, и могут работать намного быстрее обычных РДБМС

[mynameiszb]

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

OLAP решения сильно оптимизированы для того что бы делать slice&dice и считать сложные многомерные агрегации, и могут работать намного быстрее обычных РДБМС

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

[crypto5]

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

OLAP решения сильно оптимизированы для того что бы делать slice&dice и считать сложные многомерные агрегации, и могут работать намного быстрее обычных РДБМС

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

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

[NYgal]

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

OLAP решения сильно оптимизированы для того что бы делать slice&dice и считать сложные многомерные агрегации, и могут работать намного быстрее обычных РДБМС

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

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

Ухватила только хвост дисцуссии.

1. Star-schema и OLAP - несколько разные животные. OLAP построен вокруг нормализованных dimesions, флейкнутых под требования BI. Выстраивается обычно в виде datamart,
который сидит на DWH. Иногда можно отделаться легким испу... matrialized views, вытянутых из DWH
Star-schema по определению денормализована до 2й формы, НА чем ето реализованно - дело десятое. S QlikView я когда-то работала. их плюс - в перформанце, у них первенство в ин-меморы и свои proprietary хорошие алгоритмы хеширования. Сейчас как раз я имплементирую MicroStrategy. QV по сравнению - простой, как дерево. мне МСТР больше нравится, более гибкий тоол.
Но не заблуждайтесь: все требуют удокториваия данных и подготовки некоторой прокладки типа датамарт, на котором они будут сидеть. Тогда натупает щатье.
Простой анекдотичный пример: в MSTR вы с логин именем имеете доступ к шеме по запросу:
select table_name, etc... from ALL_TABLES where owner_name... да... именнo login name


2. До того надо сильно подолбаться с data profiling и data quality.
Можно взять практически бесплатный DQguru, или Talend, в котором есть и елементы MDM. - ето не так уж важно.
Можно и самим организовать и накодировать.
Но мусор в данных надо чистить так или иначе, желательно именно до того.
Ето на 20% программизм и на 80 - организационные меры и большой геморой.

[Albert_al]

Ето на 20% программизм и на 80 - организационные меры и большой геморой.

+1. Как раз сейчас пытаюсь уломать руководство на разработку датамарт, тк обьем данных вырос с сотен тысяч строк до миллионов. Не понимают, дай говорят доступ вот этому гуру Tableau, он все сделает

[Zorkus]

Ето на 20% программизм и на 80 - организационные меры и большой геморой.

+1. Как раз сейчас пытаюсь уломать руководство на разработку датамарт, тк обьем данных вырос с сотен тысяч строк до миллионов. Не понимают, дай говорят доступ вот этому гуру Tableau, он все сделает

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

[KotKot]

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