⚙️ Добавить логику повторных попыток retry в оркестрацию расчетов DAG

Для того, чтобы бороться с повторяющимися случайными ошибками.

В моем случае это проблемы с сетью (сетевым подключением). В рамках расчетов я делаю обращение из Clickhouse во внешнюю СУБД и порой во время чтения данных подключение прерывается:

05:08:57    :HTTPDriver for https://***:8443 returned response code 500)
05:08:57     Poco::Exception. Code: 1000, e.code() = 2013, mysqlxx::ConnectionLost: Lost connection to MySQL server during query (***:3306) (version 23.3.17.13 (official build))

* Можно тонко конфигурировать настройки, но не всегда это возможно на стороне СУБД-источника данных

В итоге расчет всех витрин прерывается в случайном месте, и в результате имеем в отчетности либо отстающие, либо несогласованные данные.

🔹 Как можно предусмотреть возможность повторных попыток?

— Реализовать собственноручно в коде исполнения (Exception handling, Retries, etc.)
— Настроить встроенные механизмы (Airflow task retries)
— Использовать специальные обертки (Github Actions)

В моем случае использую Github Actions как оркестратор запусков dbt

Step, который прежде выполнял единственную команду dbt build, теперь выглядит так:

  - uses: Wandalen/wretry.action@master
    with:
      command: dbt build
      attempt_limit: 3
      attempt_delay: 2000

В Github Actions я бы рекомендовал использовать retry action. Есть ряд альтернатив, но, например с Retry Step у меня возникли проблемы и я отказался от его использования.

#orchestration #dbt #github_actions

🌐 @data_apps | Навигация по каналу

🚀 Сквозная аналитика + Modern Data Stack 🚀

Запись вебинара на YouTube: https://youtu.be/wkLIPy_pczY?si=_vIHRcCKA6BueeU_

#learning

🌐 @data_apps | Навигация по каналу

❄️ Наступает время Snowflake ❄️

Ранее я писал, что рассматриваю альтернативные СУБД в качестве аналитического движка.

3 февраля 2024 заканчивается резерв Amazon Redshift RA3 Nodes сроком год.
К этой дате я планирую полностью подготовить кластер Snowflake, код dbt-проекта, и все другие необходимые конфигурации.

В один день я просто переключу все нагрузки на Snowflake, и большинство пользователей даже ничего не заметят (поначалу 🙂)

Самый актуальный вопрос, который задавался - а зачем?

🔹 Новый подход к проблемам с производительностью (расчетов, запросов, пиковых нагрузок и т.д.)

— Невероятно быстрое масштабирование благодаря Serverless & Cloud native природе
— Индивидуальная работа с каждым видом нагрузки (workload) с помощью Virtual Warehouses: EL, T, BI, Analysts, и т.д.
— Платим только за потребленные ресурсы - кластер не работает 24/7.

🔹 Ускорение цикла создания ценности (Time to Market)

— Расширенный список поддерживаемых функций: Geospatial, in-database ML, Data streaming, advanced analytics, etc.
— Доступ к экосистеме: marketplace, packages, modules, solutions, code examples, how-to guides
— Developer Experience: разработка features становится приятной и легкой, может занимать часы и дни (не недели и месяцы)
— Фокус аналитиков на поиске ответов на бизнес-вопросы, а не на отладке ошибок и чтении документации к СУБД

🔹 Повышение устойчивости (к миграциям, необходимому набору навыков), совершенствование кодовой базы

— Рефакторинг кода: снижение сложности при сохранении чистоты базы кода. Любая последующая миграция будет значительно быстрее и безболезненнее
— В Snowflake траты на обслуживание и администрирование близки к 0: экономим инженерные ресурсы и время
— Чем меньше устаревшего кода и инструментов, тем легче найти инженера или аналитика (С dbt + Snowflake работать проще, чем с dbt + Redshift + S3 + Lambda + Python + Airflow)
— Если мы используем Snowflake, мы избавляемся от 3-5 бессмысленных джобов dbtCloud (VACUUM + ANALYZE, Job to enable Slim CI)

Это коротко.

Сталкиваетесь ли вы с подобными проблемами?

Дальше будут посты с детальным планом миграции и TODO.

#database #snowflake #redshift

🌐 @data_apps | Навигация по каналу

👀 Где взять динамический датасет для целей тестирования?

Большая часть датасетов и sample databases являются статичными, т.е. представляют из себя снимок. Эти данные не меняются со временем.

Мы привыкли изучать такие данные, проводить Exploratory Data Analysis, строить дашборды, обучать ML-модели. Удобно пользоваться Sample Tutorials от вендоров и тулов. Awesome Public Datasets, Kaggle, Metabase Sample Database, и даже AdventureWorks - это всё примеры статики.

Но ряд задач можно изучать и решать только на динамическом датасете, т.е. тех данных, с которыми происходят мутации в режиме реального времени - INSERT, UPDATE, DELETE:

— Online data replication (Change Data Capture)
— Streaming tasks: Analytics, ML, Inference
— Testing configurations: Database, Queues, Services, Monitoring tools

У меня есть желание иметь песочницу с СУБД с постоянно идущими осмысленными транзакциями. В идеале это осмысленный OLTP с постоянно идущими операциями CRUD.

Вот то, что я нашел на текущий момент:

— Samples of Docker Compose applications with multiple integrated services. Много всего, сложно найти что-то релевантное и подходящее.

— Online Boutique (GCP): Sample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC. Это уже более конкретно и похоже на то, что нужно. Но это GCP, слишком большое количество сервисов для моей задачи.

— Взять любую СУБД с датасетом и написать к ней SQL-запросы. Запросы запускать по расписанию. Однако это дополнительные траты времени и усилий (изучи структуру, напиши запросы, шаблонизируй, запускай)

— Использовать для запуска запросов тулы для нагрузочного тестирования: locust.io, Jmeter

— RSS feed -> PostgreSQL (INSERTs only), но это простенько, уже СУБД + сервис для чтения RSS (на Python, например)

💬 Подскажите мне свои идеи, как можно быстро и просто (например, в контейнере) получить пример динамического датасета (например, в СУБД Postgres / MySQL / MSSQL)?

🌐 @data_apps | Навигация по каналу

🌟 Привет, друзья!

С наступающим Новым Годом!

Обещаю радовать вас и развиваться. В новом году я планирую:

— Делать больше обзоров Data Tools и Инструментов, сравнивать их и делать выводы

— Создавать новый обучающий и полезный для каждого контент

— Активизироваться на YouTube с онлайн-стримами по интересным темам и короткими кастами

— Систематизировать накопленные в канале знания, добавить навигацию и хэштеги

— Писать review на новые (и не очень) книги, интернет-публикации и самые интересные Data-события

— Запустить email-рассылку

Желаю всем уютно отметить в кругу близких и друзей, помечтать как следует, и полными сил вступить в новое путешествие в наступающем году! 🥳

До связи,
Артемий

🥳🥳🥳

🏆 Удержать стоимость SaaS ELT на уровне $13K / year вместо повышения цены в 2,35 раза

В компании для интеграции данных я использую SaaS ELT решение от вендора Hevo Data.

Еще в начале 2020 году я провел сравнительный анализ и proof of concept среди основных игроков на рынке в поисках подходящего решения.

В финале оказались Hevo и Fivetran. Hevo победил по ряду критериев, в том числе по стоимости (total cost of ownership).

Коротко, мой сетап:

— 1 Destination connector (sync каждые 15 минут)
— 10 Source connectors (самые важные: MongoDB, Postgres, Event stream)
— 500M events / month

Начиная с 2020 года стоимость сервиса составляла $12K в год с платежами раз в квартал. На мой взгляд, это отличная стоимость за работающее решение, выполняющее свою задачу на 100%. Сервис работает замечательно более 3-х лет.

Но в ноябре, к своему удивлению, я получил уведомление о том, что новый платеж за квартал составит $7K вместо $3K.

На свой вопрос я получил типичный ответ:

As discussed our prices had been revised last year and we kept our customers on the same pricing for 1 full year and all our customers were being asked to move to the new pricing to ensure that we are able to serve all our customers at the highest level. The prices applicable are further discounted by 28% over the list price keeping in mind the long standing relationship.

Also to provide you more context - prices had not been revised since 2020.

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

И тут я начал учиться вести переговоры и искать аргументы для этих переговоров.

🟢 Первое, что я сделал - обратился к заключенному договору на предмет пункта, описывающего правила. повышения стоимости сервиса.
В этом мне помогла команда Legal в компании.

🟢 Второе, что я сделал - это консультация с представителем агентства Vendr. Обладая полнотой информации (условия контрактов других компаний, прайсинг среди конкурентов), их задача заключается в том, чтобы помогать компаниям находить лучшие решения на рынке и заключать максимально выгодные контракты.

В результате продуманной и аргументированной стратегии переговоров, предложение Hevo трансформировалось в 750M events / monthly for $13K / year вместо 500M events / monthly for $28K / year.

Это удивительно. Но порой стоит задавать вопросы и оценивать рынок вокруг.

💬 Есть ли кто-то, кто использует аналогичные SaaS - Fivetran, Rivery, Segment, Stitch?
Расскажите, какой сетап и сколько это стоит?

Дайте реакций, и я расскажу про renewal Looker - одно из самых продвинутых и дорогих BI-решений на рынке.

#saas #elt #hevo #pricing

🌐 @data_apps | Навигация по каналу

😵‍💫 Нерелевантные, демотивирующие и бессмысленные задачи

Давайте поговорим про раздражающие и отвлекающие факторы в работе.

Вчера у меня возникла ситуация:

Amazon Redshift ночью автоматически обновился на свежий релиз, что привело к ошибкам в расчетах (dbt), и проблемам с отчетностью (Looker). Ряд самых важных дашбордов перестал работать (пусто, либо ERROR SQL Query). Бизнес-пользователи сообщают о проблемах и ждут исправления.

Я потратил около 4-5 часов на поиск и локализацию проблемы, её исправление (rollback, upgrade, чуть не дошло до restore from backup) и проверки (что-то продолжаю делать и сейчас).

В это время команда из 6 человек (Finance & Accounting) пишет письма с просьбой найти и выслать какой-то invoice на оплату, а затем подтвердить его корректность (я не шучу).

Я решил вспомнить и структурировать подобные примеры в моем опыте работы.

🌐 @data_apps | Навигация по каналу