FEDOR BORSHEV

Ненавижу Metabase

Мы в школе активно используем Metabase — и для управленческой отчётности, и для операционки: взаиморасчётов с экпертами, проверки домашки и ещё кучи ad-hoc задач. Прежде, чем писать код для полноценных интерфейсов, всегда пробуем решить проблему на Metabase.

Но вот как этот инструмент сделан для администратора — это просто отвратительно. К примеру их команда тратит кучу сил на то, чтобы данные можно было ковырять без знания SQL. Идея крутая — типа дадим пользователям все данные, а они уже сами себе соберут дешборды. Но вот реализация просто отвратительная — все эти инструменты не работают даже на нашем простом сетапе.

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

Но эти модели не работают! Может быть один раз данные из них получить и можно, но вот построить из них более или менее полезный дешборд уже не получится. Данные в моделях нельзя нормально фильтровать, с ними не получается писать SQL: итоговые запросы получаются настолько корявыми, что когда они падают, нет никакого способа их отладить. То есть у ребят получились материализованные вьюхи, которые толком не работают, да ещё и материализуются где-то вне БД, то есть не контролируются миграциями.

Кажется, что выходить с уровня БД на уровень приложения и описывать модельки на языке метабейза стоило бы ради довольно полезной функциональноси, которую умеют все крутые BI — джоинов из двух БД одновременно. Но этого похоже не будет никогда.

В итоге так мы и пишем SQL-запросы, выводя их результаты в дешборды. Получается грустно — у нас нет нормального data lake, и мы делаем выборки просто с продовой базы, а значит не можем делать серьёзные изменения в структуре данных, не сломав всю аналитику. Раз в год я пытаюсь заюзать фишки метабейза, которые позволяют избавиться от этой зависимости, трачу на это 3–4 часа и бросаю.

Может посоветуете замену, которая подходит маленьким ребятам, которые пока не доросли до выделенных ETL-пайплайнов? Или уже доросли и пора делать?

www.group-telegram.com/us/pmdaily.com/1185

21.7K viewsMay 22, 2024 at 07:45

Ненавижу Metabase

Мы в школе активно используем Metabase — и для управленческой отчётности, и для операционки: взаиморасчётов с экпертами, проверки домашки и ещё кучи ad-hoc задач. Прежде, чем писать код для полноценных интерфейсов, всегда пробуем решить проблему на Metabase.

Но вот как этот инструмент сделан для администратора — это просто отвратительно. К примеру их команда тратит кучу сил на то, чтобы данные можно было ковырять без знания SQL. Идея крутая — типа дадим пользователям все данные, а они уже сами себе соберут дешборды. Но вот реализация просто отвратительная — все эти инструменты не работают даже на нашем простом сетапе.

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

Но эти модели не работают! Может быть один раз данные из них получить и можно, но вот построить из них более или менее полезный дешборд уже не получится. Данные в моделях нельзя нормально фильтровать, с ними не получается писать SQL: итоговые запросы получаются настолько корявыми, что когда они падают, нет никакого способа их отладить. То есть у ребят получились материализованные вьюхи, которые толком не работают, да ещё и материализуются где-то вне БД, то есть не контролируются миграциями.

Кажется, что выходить с уровня БД на уровень приложения и описывать модельки на языке метабейза стоило бы ради довольно полезной функциональноси, которую умеют все крутые BI — джоинов из двух БД одновременно. Но этого похоже не будет никогда.

В итоге так мы и пишем SQL-запросы, выводя их результаты в дешборды. Получается грустно — у нас нет нормального data lake, и мы делаем выборки просто с продовой базы, а значит не можем делать серьёзные изменения в структуре данных, не сломав всю аналитику. Раз в год я пытаюсь заюзать фишки метабейза, которые позволяют избавиться от этой зависимости, трачу на это 3–4 часа и бросаю.

Может посоветуете замену, которая подходит маленьким ребятам, которые пока не доросли до выделенных ETL-пайплайнов? Или уже доросли и пора делать?

BY FEDOR BORSHEV