Павел Хамрин@PavelKhamrin
Data Engineer, Founder Datapulse
Информация
- В рейтинге
- Не участвует
- Откуда
- Москва, Москва и Московская обл., Россия
- Зарегистрирован
- Активность
Специализация
Data Analyst, Data Engineer
Lead
PostgreSQL
SQL
Database
Microsoft SQL Server
Oracle
Python
OLAP
BI
ETL
DWH
Сказочный америкафил
Вы действительно сравниваете геноцид индейцев с переселением? Уму непостижимо ...
Недавно услышал очень хорошую мысль про DV. DV не про анализ, а про хранение данных. Над DV обязательно должны быть отчетные витрины. Именно с ними работают аналитики.
Тут вы правы на сто процентов, это я упоминал в статье, но вскользь. Вычисляемые меры в DAX, к примеру, гораздо проще считать.
Не думаю, что все сводится к тому, чтобы быстро запилить что-то и принять на фоне этого решение.
А разработка скриптами не сильно дольше ваших любимых drag-n-drop-ов. Особенно если учитывать, что код можно переиспользовать
Конечно, таблетку от всего не придумаешь. Но классический вариант следующий - делаем агрегированные витрины под конкретные показатели. Сотни пользователей посылают запросы к этим витринам. Еще лучше вариант (упоминал в статье) - используя DuckDB, чтобы СУБД не насиловать.
Касательно, менеджера и установки библиотек - не знаю, если честно, на мой взгляд установка элементарная, если инструкцию написать.
Все даром, лишь попроси:))
Если серьезно, PBI Desktop и Pro все же разные вещи.
А что не так?
Без кэширования на стороне стандартного BI тоже БД нагружается. Да и данные берутся часто из агрегированных витрин. А нагрузки на сеть в принципе нет. Вы же не строите дашборды над сотнями Гб
Да, конечно, подобные решения, как streamlit, только для сотрудников с экспертизой в sql, как минимум.
Но, как я писал в статье, я особо не верю в Self-service аналитику. По крайней мере, я ее не встречал.
Именно DataVault мы и пробовали:))
Вы правы, DV весьма сложно разрабатывать и поддерживать без специальной тулзы. Даже сами такую тулзу сделали.
В Airflow DAG пишется на python, это главный вариант работы. dbt + dlt, dagster, spark - как сейчас модно говорить - modern data stack
Можно доверять, если настроена проверка качества данных, а также хранилище создавали квалифицированные кадры :) Обе описанные проблемы вполне решаемы
Настроить стриминг, как один из вариантов.
В статье я помечал, что это та отдельная ситуация, когда автоматизировать процесс скорее всего не получится.
Хорошее замечание, при написании статьи не думал про влияние человеческого фактора:) Тезис из статьи, что данный вариант "самый сложный" стоило бы чуть детальнее раскрыть.
Если я правильно понял, в данном случае меньшие затраты при создании хранилища, но проблема дорогих обслуживания и доработки хранилища не решается.
Имело в виду, что тратить на подготовку данных меньше времени без потери качества :)
Тут и соглашусь, и нет. Практически во всех крупных компаниях бизнес знает, что такое хранилище и с чем его едят (правда зависит от сегмента бизнеса). А также количество МСБ, знакомого с данным понятием, увеличивается. Возможно, они знакомы с другими терминами/синонинами: озеро данных, аналитиская платформа, BI, анализ данных или продуктовая аналитика. Если никто в компании никогда не встречался с подобными терминами, скорее всего им хранилище и не нужно (на текущий момент развития организации).
Что касается вопросов, кто как приходит к пониманию о необходимости хранилища или кому в принципе это нужно, это отдельная и очень интересная тема. Которая еще и затрагивает становление политики компании в отношении самих данных и работы с ними.
Про приведенные два инструмента, я, к сожалению, с ними не встречался. Но знакомые мне инструменты не позволяют минимальными усилиями загрузить и разложить данные в определенную структуру. Чаще всего подобные инструменты позволяют просто консолидировать данные, но работать с сырыми данными сложно. Особенно, когда объем отчетности и показателей растет.
А про "сделать без аналитика что угодно", я если честно совсем не верю:) Только если есть предварительно настроенные типизированные в продукте отчеты.