Что мы поняли, когда сверстали таблицы в Metabase
Работа инженера данных каждый день подкидывает какие-то новые вызовы.

Иногда крайне неожиданные. Например — сделать таблицы в Metabase. Вы когда-нибудь этим занимались? Если что — не советуем. Да, это спойлер.

У заказчика вся отчетность велась в таблицах, и настал момент, когда их стало (как будто) не хватать.
1️⃣ Объем данных вырос — заполнять и обновлять таблицы вручную стало муторно, увеличился риск ошибок: чем больше данных заносит человек, тем выше вероятность, что он где-нибудь опечатается. Нужно было этот процесс автоматизировать.
2️⃣ Захотелось более наглядные и удобные визуализации — на графиках лучше видны тренды и закономерности.

В качестве BI-инструмента вместе с заказчиком выбрали Metabase за простоту и бесплатность — его функционала должно было за глаза хватить под этот проект.

И его хватало, пока мы не пришли к пункту 3:
3️⃣ Потестив новые отчеты, некоторым решили вернуть привычный табличный вид для скорости и удобства.

И вот тут оказалось, что иногда BI-тул критически проигрывает старым добрым гуглшитам. Создать в Metabase таблицу можно, но...
🔵Чтобы закрепить строку или столбец, приходилось исхитрятся с несколькими подтаблицами на одной странице — в рамках одной таблицы это сделать было нельзя.
🔵Чтобы сделать таблицу, которая растет в ширину, а не в высоту, добавили пагинацию. На каждой странице отображались 10 столбцов. Чтобы увидеть 11-й, надо было переходить на следующую страницу. Сделать иначе это было что? Нельзя.
🔵Чтобы пользоваться сводными таблицами, надо было смириться, что они будут просто безбожно лагать при скролле.

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

Вот так мы получше узнали Metabase и его ограничения, а еще в очередной раз поняли, что не всегда стоит менять таблички на BI-тул.