Это вторая (и заключительная) часть цикла статей о нашей миграции с Zeppelin. О причинах и первом опыте перехода с Zeppelin я рассказал здесь. В данной статье я хочу большее внимание уделить второму виду Zeppelin notebook, которые срочно нуждались в переносе.
Конечно, отчеты для клиентов не были настолько "забагованы" как рассылки: большая часть проблем с Zeppelin крылась именно в cron-е, который временами работал как хотел (или в интерпретаторах, мы так и не смогли разобраться, но ошибка интерпретатора возникала только когда запускали через cron). В отчетах этого звена не было, поэтому их перенос был плавным и основан скорее на особенностях UI/UX дизайна.
Данная статья может быть полезна аналитикам, которые не знают, какой инструмент использовать для своих задач и думают, что писать графический интерфейс крайне сложно (спойлер, нет), а также для команд, которые устали от Zeppelin как UI-инструмента (и от Zeppelin в целом)

Для задач аналитики Zeppelin - это чуть ли не находка. Он может в одной книжке исполнять код на любом языке (был бы интерпретатор), выводить его в виде красивых табличек, графиков и в любом другом виде, который удобен. И на Хабре есть много статей, посвященных плюсом данного решения для задач аналитики.

В результате в аналитический отдел ТКБ Инвестмент Партнерс данный инструмент проник достаточно глубоко: на нем писались аналитические отчеты для разных отделов, расчетные таблицы, которые затем отсылались в дашборды, также данными книжками могли пользоваться все, кто знал какие-либо языки программирования.

И мы попали в зависимость от него. Панацея, которая должна была стать легким решением для (почти) любой задачи превратилась в наше проклятие. Из-за проблем с данной системой на нас приходило по 5-7 тикеров в неделю, а также потерей доверия к нашим сервисам.