Comments 20
Tableau, Looker, Periscope, Mode
1. Только из Вашей статьи узнал о существовании последних трех:-) 5-минутный гуглинг не выявил внедрений в России. Да и странно сравнивать лидера Tableau c решениями не попадающими в упоминаемый квадрант Gartner даже в разряд аутсайдеров. Полезнее было бы сравнить Tableau c Qlik, Power BI, SAP (BO и т.д.) — 4 лидирующих платформы по внедрениям в РФ (статья на русском ведь ориентирована на российский/СНГ рынок преимущественно?).
2. Выбор ETL(ELT) — инструментов также вызывает вопросы. А Informatica, Talend и еще 3-4 такого же уровня крутых инструментов? Вероятность столкнутся с ними в корпоративных решениях ничуть не меньше, чем в упомянутых выше.
3. Упоминая экзотику для мира BI — In-Memory DB, можно было бы и DB на GPU вспомнить. Единственная выгода у них как раз в математических операциях в задачах со сверточными сетями и прочим DL, что близко тематике ODS. Однако тут необходимо приводить примеры. Я вот сходу не назову ни одного приличного DWH на этих технологиях. Поправьте меня пожалуйста пруфом. Под приличным подразумеваю хотя бы >10Tb данных у продуктовой компании.
И последнее —
по опросу Kaggle, главная сложность, с которой сталкивается половина DS — это грязные данные [2]). Основной проблемой в этом случае, очевидно, будет трудоемкость и неэффективность использования времени аналитиков. Вместо создания полноценного продукта, аналитики/DS будут все свое время готовить показатели, считать метрики, сверять расхождения в цифрах, искать ошибки в SQL-коде и заниматься прочей бесполезной деятельностью.
Тут и до фразы «девопсы/тестировщики = недоразработчики» недалеко. Давайте уважать труд других. Похожими заявлениями Вы создаете ложные представления у джуниоров (статья ведь для них?). Я как Data Engineer, готовящий данные для своего ML Архитектора получаю не меньше его и раза в 2 больше
1. Статья описывает опыт внедрения BI в нашей компании. На момент тестирования мы исключили Power BI и QlikView из перечня по нескольким причинам включая негативный предыдущий опыт работы с некоторыми из них. Если в вкратце, то Power BI, SAP, как мне кажется, больше подходят как enterprise решения, они не очень гибкие и у них довольно крутая кривая обучения для бизнес пользователей. Qlik, на мой взгляд, довольно олд скульная система слабо подходящая для Self Service — если ты хочешь что-то создавать в ней, тебе надо хорошо владеть SQL (а это не про бизнес-пользователей). И в целом, как раз про эти 4 инструмента довольно много уже всего написано, много не добавишь :)
2. ETL — это отдельная история, не без приключений :) постараюсь собраться и описать более подробно как у нас обстоят дела.
3. Не прорабатывал вопрос, но спасибо за идею, изучу.
4. Здесь я не хотел никого обидеть, основная мысль заключалась в том, что хочется по-возможности автоматизировать рутинную работу с данными и отчетность, тем самым повысив эффективность команды.
3. Не прорабатывал вопрос, но спасибо за идею, изучу.
Не стоит) Имел неудовольствие общаться с сейлзами, которые предлагали заменить божественную Вертику своей GPU поделкой. В-общем, этап «технического собеседования» они не прошли. Да и продукт очень узкоспециализированный.
Qlik Sense — вполне себе подходит под Self Service IMHO. Ну и про Power BI немного странный отзыв
" если ты хочешь что-то создавать в ней, тебе надо хорошо владеть SQL (а это не про бизнес-пользователей)."
На мой взгляд очень частое заблуждение, я бы ещё понял если бы было сказано что "у них недостаточно времени на это"/"их время слишком дорого", с другой стороны когда ты вечером в BI живёшь сохранить фильтр, а вернувшись утром видишь песочные часы(понятно что какой-то сбой, но) задумываешься о том что за это время среднестатистический пользователь мог бы изучить азы SQL изучить :)
можно было бы и DB на GPU вспомнить
Кстати, есть вполне российское решение Polymatica, которое на GPU работает и даже с рядом кейсов. www.polymatica.ru/case-studies
- Есть коннекторы к основным БД, набор графиков как в plotly js, есть docker образ и репозиторий на github. Написан на python — можно допиливать напильником при желании.
Zeppelin
- Можно использовать js и питон для визуализации и обработки данных. Можно использовать встроенные готовые графики.
metabase
- Не работал, но там вроде даже аномалии на временных рядах можно детектировать из коробки.
Какое ваше мнение об этих инструментах?
Redash хорош тем, что использует в основе питон, а значит, скорее всего может быть допилен без больших расходов при острой необходимости. Но выглядит достаточно сырым. Хотя и имеет достаточно много типов даже непопулярных визуализаций.
Metabase. Ох уж этот метабейз… прекрасный иопенсурсный продукт, но не обманитесь первыми впечатлениями. Если бизнес чуточку сложнее, чем купи-продай, то вы обязательно наткнетесь на несколько капканов, пару раз выстрелите себе в ногу и разобъетесь об его опенсурсность. У разработчиков свое видение на некоторые вопросы и оно может кардинально различаться с вашим. И судя по их страничке на гитхаб, некоторые вопросы(если ваша точка зрения близка разработчикам) могут решаться годами. Имхо идеальный вариант для небольших компаний, которые могут даже не иметь в штате аналитика и людей знающих sql, или для какого нибудь корпоративного монстра, имеющего раздутый штат java разработчиков, готового взять метабейс под свое крыло. И в отличие от редаш, метабейс все таки более продуман и от полноценного продукта отличается только наличием глюков и багов и отсутствием некоторых возможностей, из-за чего приходится использовать древние техники КунгФу в sql, иногда попутно поднимая парочку микросервисов в качестве спутников.
А самым перспективным open source решением имхо является superset — детище убера и эирбнб емнип, взятый под крыло apache. Если метабейс — BI through sql и даже очень неплохой BI without sql, то superset лучше раскроет себя, при использовании sql+питон. Собственно на него я смотрю уже месяца два и думаю как бы подробнее изучить подводные камни и безболезненнее мигрировать с metabase. Есть несколько статей с упоминанием суперсет, но очень не хватает обзорной статьи про него от тех, кто остановился на нем и успешно использует. Возможно стоит и мне написать про metabase.
Кстати, немножко по другой теме, но у апач есть прекрасный эирфлоу, с которым выбор суперсета выглядит еще более естественным. Все эти продукты как нельзя лучше раскрывают сильные и слабые стороны open-source для бизнеса.
«В Tableau не предусмотрены version control, code review, team collaboration, как и нет продуманной среды разработки и тестирования»— все объекты автоматически версионируются, всё на сервере можно откатить. Исходный код артефактов — XML, т.е. версионирование в github не проблема, что мы и делаем.
team collaboration — этого нет.
Но есть: — очень быстрая работа с большими данными, миллиард строк — не проблема, отображает быстрее, чем эксель свой миллион.
— полноценная система управления правами доступа.
— рассылка данных в форматах pdf, csv, картинки. При этом без костылей, всё красиво и ровно.
— создание не только дашбоардов, но и «data story», топ-менеджмент в восторге.
И ещё замечание
главная сложность, с которой сталкивается половина DS — это грязные данные [2]). Основной проблемой в этом случае, очевидно, будет трудоемкость и неэффективность использования времени аналитиков.
Всегда считал, что хороший аналитик делает именно эту работу: правила, как из грязных данных получить чистые. В грязных данных вся соль. И кто, как ни аналитик, найдёт логическую ошибку в SQL, ведь только он знает, что нужно получить на выходе.
По поводу грязных данных, все верно, добавлю только, что мы с одной стороны пытаемся весь процессинг и очистку данных убрать в ETL, а с другой построить единую для всех модель данных в Looker. Таким образом все работают с одинаково рассчитанными метриками и минимизируется риск ошибки в коде, как в ситуации с отдельным скриптом для каждой агрегации данных.
Это что это у MS устаревшее?
Если говорить о деталях, то в продуктах, описанных в статье, нужно гораздо меньше кликать. Миллион записей для человека — это очень много, но в современных системах их ещё больше и нужны адекватные инструменты, чтобы понять, что там происходит.
Если добавить факторы version control, code review, team collaboration, то бывшим гигантам нужно позволить уйти на покой.
version control, code review, team collaboration
Я не пользуюсь ничем из этого в явном виде. При этом мне сложно представить как мои MS AS кубы на десятки Гб после процессинга запихнуть в Tableau без 3-5 лет рефакторинга. Да и сложно представить чтобы 4-х нодный кластер не лег при первом же обращении пары десятков аналитиков и сотни простых юзеров. MS AS же у меня на 1 железном mid-level сервере. И да — лицензии MS AS 2010 стоят 0.
Каждый инструмент хорош для своих целей. И даже богомерзкий SAP BO vs пока не готовы полностью списать и уйти на Tableau.
— Первым в моём списке оказался стек технологий IBM cognos на базе данных оракла. Застал конец миграции ETL c Informatica на пакеты pl/SQL, т.к. первая перестала справляться. 4 года в области построения отчётов. У cognos сложновато с настройкой и управлением BI инфраструктуры.
— Следующим был стек от SAP и 6 лет с ним. Всё делали BO и BODI средствами. Когда вышел новый релиз без поддержки старого, мы встряли с нашими 4мя тысячами джобов. За год всё переделали на оракл пакеты, репортинг остался на SAP, позже его мигрировали в Tableau. sap тогда казался круче когноса.
— Потом достался BI от оракла и одно хранилище со стеком MS. Полгода ковырялись. Про ODI и OBIEE вообще не хочу писать, это каменный век. Всё это мигрировали в базу оракла и Tableau для репортов. Заодно все сервера перевели на линукс.
— Последние 2 года работа приносит удовольствие, потому что можно сосредоточиться на анализе данных, а не разбираться, почему программы живут своей жизнью. При этом хранилище побольше, чем были до этого: за ночь обрабатывается 10,5 миллиардов записей. Кубы (у Табло они называются экстрактами) тоже большие, но они полезны для аналитиков, чтобы оффлайн работать. Для регулярных отчётов технология кубов устарела, машины справляются если модель быстрая.
— Ещё используем knime, но не продуктивно, а для помощи в анализе, если нужно локально преобразовать данные.
При этом мне сложно представить как мои MS AS кубы на десятки Гб после процессинга запихнуть в Tableau
я бы попробовал «в лоб» решить: сохранить это дело в CSV и просто перетащить в Tableau desktop. Пробовал с одним миллиардом записей — работает, минут 15 думает и проглатывает. Можно упаковать в hyper, тогда файл будет раз в сто меньше и летать как эксель.
Миграция или рефакторинг — это, конечно, целая тема, отдельная.
Поэтому основным критерием выбора аналитической системы должна быть возможность максимально разгрузить аналитиков от ad hoc-задач и текучки.
Явно не понравится владельцам бизнеса. Они обычно понимают, что значение ad hoc задач нельзя приуменьшать.
Семь раз отмерь, один раз внедри BI инструмент