Как-то мне попалась на глаза презентация Даниила Охлопкова, в которой он рассказывает об удобных инструментах для создания небольшой аналитической платформы по хранению данных для стартапа. Посмотрел и посмотрел, но информация отложилась. И вот недавно мне пришлось решаать подобную задачу. Поэтому я сразу вспомнил об данной презентации и воспользовался готовыми идеями. Это сэкономило мне несколько дней, а может и неделю на исследования и выбор инструментов. Особенно MetaBase - я об этом слышал разве что мельком. Но добрых два рабочих дня (примерно 16-20 часов) ушло на то, чтобы все это запустить так, как я хотел бы. И если вы хотите сэкономить для себя эти два дня - тогда велком под кат.


Сразу скажу, что теории тут практически никакой не будет. Рассказывать особо нечего. И исли вас, как и меня, интересует только конкретика, тогда вот вам ссылка на git-репозиторий и не тратьте больше времени на этот пост. ;-)

Но как бы для поста на Хабре этого вроде как маловато, поэтому придется написать немного букв со скринами и некоторыми выводы, которые сделал для себя по ходу работы над данным проектом.

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

Почти точь-в-точь, как у Даниила в презентации. Кстати, вот его презентация без видео.

Но все-таки кроме, собственно, готовой сборки, я привнес и несколько своих идей. Но об этом ниже.

Во время размышления над задачей захотел сделать так, чтобы решение было серийным. Во-первых для себя. Было ощущение, что я это смогу переиспользовать в будущем. Ну, а во-вторых, захотелось поделиться с другими на своем канале. Поэтому решил все запаковать в Docker и выложить готовую сборку.

Примерно часа 3-4 потратил на то, чтобы в докере поднять последнюю версию AirFlow 2. Несмотря на то, что разработчики AirFlow побеспокоились и создали готовый docker-compose файл, некоторые особенности поднятия были упущены ими или описаны достаточно витиевато. В частности, AirFlow не работал корректно с БД пока я не прописал в x-airflow-common в environment следующее: AIRFLOW_UID: 0 и AIRFLOW_GID: 0 (для получения этих значений авторы подготовили специальный скрипт, но, видимо, забыли указать, что эти значения нужно добавить в сам docker-compose.

Еще несколько часов потратил на то, чтобы поднять PostgreSQL для хранения данных, которые будут собираться с помощью AirFlow. Дело в том, что я заливал на сервер файлы через Git pull. А для того, чтобы залить в Git пустые директории для volume-директорий, мне пришлось добавить в них файл .gitkeep - иначе пустые директории не загружались. Как следствие, на сервере необходимо было удалить этот файл в директории pgdata_collect_data - иначе не поднималась БД. Додумался не сразу ;-).

Примерно 8 часов ушло на то, чтобы загрузить нужные данные в БД с помощью AirFlow. Данные на сайте, с которого брались, хранились в открытом виде и были разбиты на архивы по кварталам для каждого года с 2021 по 2016. Главной моей ошибкой здесь было начать написать скрипт, который автоматом будет ходить по этим архивам, закачивать их, далее делать предобработку и загружать данные в БД - очень много времени потратил на то, чтобы понять причину, по которой скачанные файлы не загружались в директорию на сервере. Потом понял, что директория ведь находилась в Докере и там нужно было дописать права именно в Докере, а не самом сервере ;-) Но когда я это уже понял, то понял также и то, что мне проще руками качнуть эти файлы и локально провести над ними ETL и загрузить уже подготовленные архивы на сервер, чтобы через AirFlow данные из них загрузить в БД, чем весь ETL делать через AirFlow. По факту, AirFlow в данной задаче - это уже был лишний инструмент ;-))) Но пришлось утешить себя тем, что может в будущем пригодится ;-))) Из этого проекта вынес для себя одну из главных мудростей разработчика (как по мне), до которой дошел своими потом и кровью через год работы на позиции Data Engineer: "Нет никакого смысла делать сложным способом и дольше то, что можно сделать проще и потратить на это меньше времени". ;-))) Просто перед началом работы нужно сесть и точно все продумать. Лучше подумать 7 раз и понять, как все можно сделать проще и дешевле, чем не подумать и сделать все дольше и дороже ;-))) Такая вот мудрость.

Дополнительно к инструментам Даниила привнес один инструмент по быстрой работе с достаточно большими табличными csv-файлами. Обычно используется Pandas для перевода их в DataFrame, но Pandas не любит работать с большими данными. Есть превосходная библиотека для этих задач - datatable (pip install datatable).

Ну и оставшееся время ушло на то, чтобы поднять MetaBase в Docker и потом сделать вторую версию сборки, так как в первой версии нашел некоторые архитектурные проколы, которые захотел переделать.

Ну а если вам уж совсем все тут сильно понравилось, то велком смотреть видео-обзор, в котором я показываю как все это выглядит и работает:

Комментарии (5)


  1. SLASH_CyberPunk
    21.09.2021 15:41

    Если бы вы почитали документацию по поводу поднятия airflow в docker для прода, то смогли узнать, как стоит сделать. Выдавать рута контейнеру, когда его специально забрали - это очень не секьюрно и антипаттерн...

    Ну и конечно момент "По факту, AirFlow в данной задаче - это уже был лишний инструмент ;-)))" прям совсем звучит странно, качаем руками, права сами правим, сами заливаем, действительно, зачем тут автоматизированный инструмент...


    1. vandriichuk Автор
      21.09.2021 15:54

      Ради таких комментов и пишу на Хабре - что-то подчерпну для себя нового. Напишите как сделать более правильнее и я с удовольствием поправлю!


      1. SLASH_CyberPunk
        21.09.2021 16:03

        Я написал, где все можно прочитать


  1. densol92
    28.09.2021 15:42
    +1

    Одобряю такой сетап. Когда данных станет много можно будет вынести тяжелые файлы в s3/redshift и жить в такой конфигурации до десятков Тб данных.

    Советую поменять в Metabase базу на тот же Postgres - иначе после 10-15 дашбордов будет безбожно тормозить. https://www.metabase.com/docs/latest/operations-guide/configuring-application-database.html

    P.S. Cейчас бы я выбрал superset - его проще кастомизовать, есть интеграции с Amundsen


    1. vandriichuk Автор
      28.09.2021 20:44

      Спасибо. Не знал про тормоза при увеличении дашбордов