🏆 Удержать стоимость 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 | Навигация по каналу

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

🔻 Излишне затянувшееся общение с вендорами и провайдерами сервисов

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

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

🔻 Взаимодействие с пользователями, которым лень

Команда аналитики делает всё, чтобы пользователям было просто и удобно находить ответы на свои вопросы:

— Self-service BI (просто накликай метрик и измерений из меню)
— Документация по метрикам и витринам в вебе
— Широкий набор готовых дашбордов и визуализаций
— Tutorials & Guides

Меня удручает, когда люди просят что-то найти, не потратив на попытку сделать это ни минуты. Также сюда относятся и пользователи, которые считают, что им должны (собрать отчет, прислать выгрузку и т.п.).

🔻 One-time / Ad-hoc которые превращаются в бесконечную череду вопросов и просьб

Вас просят сделать выгрузку (написать довольно сложный запрос). Вы делаете это. В идеале вы высылаете этот запрос вместе с данными.

Далее вас регулярно начинают грузить подобными задачами, хотя для ее решения теперь есть все инструменты. А за эту неделю? А за сегмент iOS? А можешь колонки местами поменять или переименовать?

🔻 Регулярная подготовка отчетных документов, чеков, invoicing

Так выходит, что я owner нескольких приложений в компании - это DWH, Data Pipelines, Business Intelligence.

Значит ли это, что я должен каждый отчетный период запрашивать и выгружать чеки, создавать задачи в JIRA, заполнять billing information, контролировать процессы оплаты?

Скорее нет, ownership означает техническую сторону вопроса. Адекватность используемых решений задачам, пересмотр и выбор альтернативных путей.

💬 Есть что-то, что наболело?

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

Business Intelligence 101: Всё самое важное о BI инструментах

🔸 Ключевые идеи BI

— BI - это набор методов и инструментов для бизнес-анализа
— BI упрощает доступ к данным в DWH
— BI бесполезен без DWH (без данных бесполезны визуализации)
— SQL по-прежнему актуален

🔸 Основные возможности (features) BI

— Семантическая модель: сущности, связи, формулы расчета метрик и правила агрегации
— Визуальный конструктор запросов
— Формирование информационных панелей (dashboards)
— Публикация (sharing), рассылки, уведомления и алерты

🔸 Варианты развертывания

— SaaS / Managed app (Datalens)
— Self-hosted (Metabase)
— Hybrid (Superset / Preset)

🔸 Администрирование

— Production checklist (отказоустойчивость, надежность, масштабирование)
— Развертывание ПО (deployment) и обновление версий (upgrade)
— Конфигурационные настройки (в т.ч. для Metadata DB)
— Создание интеграций (Email, Slack, S3, gSheets, ...)

🔸 Сопровождение решения

— Настройка подключений к источникам данных (DWH)
— Добавление и удаление пользователей
— Аутентификация пользователей (SSO, Google Sign-in, ...)
— Управление правами и полномочиями пользователей (ролевая модель RBAC)
— Мониторинг: ошибки, неисправности, падение производительности

💬 Каким BI пользуетесь в своей компании?
Если бы была возможность использовать другой, что бы это было?

#bi

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

👑 Особенности работы с External Data (на примере обменных курсов валют)

⬜️Бизнес-задача:

— Операции с контрагентами совершаются в около 15 разных валют

— Есть необходимость пересчета финансовых показателей в разные валюты для отчетности

— Обменные курсы актуальны на каждую отдельную дату (курс меняется)

⬜️ Реализация:

— Используется поставщик данных и его API (для примера это Open Exchange Rates)

— Ежедневно несколько раз в течение дня (раз в 3 часа) делаются запросы на получение обменных курсов к каждой из 15 валют (Airflow)

— Ответы в виде JSON сохраняются AS IS в S3 / Object storage

— Эти файлы читаются на стороне DWH и формируется витрина обменных курсов (пар) в разрезе базовой валюты и даты

⬜️ Ключевые моменты, на которые стоит обращать внимание:

🟡Case sensitive identifiers

Трехбуквенных код валюты указывается в верхнем регистре. Учитывайте это при чтении данных, иначе получите NULLs вместо рейтов.

В случае Redshift + dbt я добавляю hooks:

pre_hook=["SET enable_case_sensitive_identifier TO TRUE"],        
post_hook=["SET enable_case_sensitive_identifier TO FALSE"]   

🟡Корректность файлов JSON содержащихся в S3

Порой ответы от API сервиса приходят с ошибкой, например:

<html>
<head><noscript>504 Gateway Time-out</noscript></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
</body>
</html>

Такие файлы, даже находясь среди корректных, могут вызывать ошибки чтения:

ERROR: Spectrum Scan Error
  Detail: 
  -----------------------------------------------
  error:  Spectrum Scan Error
  code:      15001
  context:   Error while reading next ION/JSON value: Invalid syntax. File: /dwh/currencies/2024-01-14-CHF-2024-01-14-08-15-10-UTC.json Offset: 0 Line: 1 

🟡В рамках одних суток актуален последний курс

Т.е. из всех курсов в течение дня необходимо учитывать только тот, что приходится на закрытие дня.

Я делаю эту пометку и фильтр на нее с помощью window function:

SELECT

...

, (ROW_NUMBER() OVER (PARTITION BY base_currency, business_dt ORDER BY business_ts DESC) = 1) AS is_most_recent

...

WHERE ...
    AND is_most_recent

🟡 Чтение огромного числа маленьких файлов

Требует гораздо большего количества времени нежели чем чтение одного (относительно) большого файла.

Поэтому, рекомендация:

— Делать compaction / merge файлов (сливать множество маленьких в один большой, например, раз в месяц)
— Выполнять загрузку в момент появления нового файла

С этим могут помочь инструменты типа EL SaaS (Hevo, Fivetran), или встроенные в СУБД возможности (Snowpipe для Snowflake)

Дайте знать, если полезно ⭐️

#s3 #object_storage #dwh #dbt #external_data

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

Как выбрать СУБД для аналитики?

Привет! Предположим, что у вас есть:

🟢 Целостное понимание потребностей бизнеса

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

🟢 Возможность предлагать и оценивать альтернативные СУБД для решения задач бизнеса

Объективно, в заданных условиях, некоторые СУБД способны справляться значительно лучше других. Иначе говоря, имеют конкурентные преимущества.

К сожалению, во многих случаях решение о том, какую СУБД использовать уже принято и не подлежит пересмотру: кем-то когда-то давно до вас по принципу "я работал с этим 5 лет назад", "у нас с ними партнерские отношения", "в компании есть экспертиза по (ms sql)".

#database #pricing

✅ Как выбрать СУБД для аналитики? Мой список критериев для выбора Analytics Database

🔵Performance and Scalability

— Работа в периоды пиковых нагрузок (одновременные запросы от EL + dbt + BI + analysts)
— Поддержка масштабируемости и scaling
— Насколько адекватно время ответа на запросы (от простых select * from table limit 10 до сложных дашбордов)

🔵Feature support

— Поддержка semi-structured data (nested JSONs, MongoDB, event tracking)
— Geospatial: GEO-joins (ST_Intersects), H3 library for geo-indexing
— Адекватная поддержка Window functions (+ Qualify)
— Простое создание окружений (Zero copy clone - DEV, TEST sandboxes)
— Time travel, restore deleted data (UNDROP)

🔵Security

— PRIVILEGES management (roles, users, groups, RBAC)
— Privacy: column/row level security, Data Masking
— 2FA access
— Security certified

🔵Maintenance and Administration

— Усилия на администрирование: install, upgrade, scale, assign AWS roles, monitoring
— Наличие удобных интерфейсов для мониторинга (Web UI)
— Introspection: metadata and database statistics

🔵Integrations and Ecosystem

— Интеграция с dbt: dbtCore / dbtCloud, dbt packages support, Semantic layer
— Наличие Data Hub: exchange rates, market data (trends, financial)
— В целом наличие и доступность интеграций с другими инструментами: EL, BI, reverse ETL, etc.

🔵Pricing model

— Модель ценообразования: Serverless / Reserved nodes / ...
— Примерный порядок расходов: Total Cost of Ownership
— Прозрачная статистика по расходам
— Возможность оптимизировать эти расходы (менять что-то и видеть результаты)

В ближайшие недели у меня запланирован финальный transition с Amazon Redshift в Snowflake. Напишу об этом опыте и результатах.

💬 Какую СУБД используете вы и какие были критерии выбора?

#database #pricing

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

О чем этот блог?

🔻 Меня зовут Артемий Козырь.

У меня 10+ лет опыта на проектах, связанных с DWH и Data в крупных компаниях: PwC, Moscow Exchange, Sber, Sibur, Wheely.

В этом блоге я публикую свои выводы и мнения на разные аспекты сферы работы с Data:

— Data Integration
— Database engines
— Data Modeling
— Business Intelligence
— Semantic Layer
— DataOps and DevOps
— Orchestrating jobs & DAGs
— Business Impact and Value

👍 Здесь не будет буллшита, иллюзий, мемов, воздушных замков и рекламы. Только препарированный контент, опыт, практика, выводы и результаты.

Мои ресурсы:

— YouTube
— [Designing Modern Data Apps]
— Github
— Habr
— LinkedIn

Вопросы и предложения @kzzzr

🌐 @data_apps

🟡 Дайджест самых интересных публикаций по темам:

Data Integration

— ▶ Успешный SaaS на рынке Аналитики – cтановление и планы развития / Алексей Сидоров из mybi connect
— 👨‍💻 Сказ о том как я realtime replication чинил (Kafka + Debezium + Clickhouse)
— 👑 Особенности работы с External Data (на примере обменных курсов валют)
— 🏆 Удержать стоимость SaaS ELT на уровне $13K / year вместо повышения цены в 2,35 раза
— 👀 Где взять динамический датасет для целей тестирования?
— ⚡️ Real time replication работает как в сказке! Но всё далеко непросто
— ⚙️ Clickhouse is advancing at data integration
— Важнейшие критерии при выборе Extract – Load решения для интеграции данных в DWH
— Extract - Load как сервис и как собственное решение. Поиск баланса и дзен

Database engines

— 🟢 Snowflake Cost Management
— ❄️ Финализирую Redshift to Snowflake transition
— ✅ Как выбрать СУБД для аналитики? Мой список критериев для выбора Analytics Database
— ❄️ Наступает время Snowflake
— ❄️ Snowflake - перспективный лидер, и я ищу подводные камни
— ⚡️ I have run a Proof of Concept with Redshift Serverless

Data Modeling

— ▶ SQL + dbt = God Mode Data Modeling / Подходы к созданию витрины корпоративных метрик
— 🔳 The Ultimate Guide to dbt
— 🙂 Переварил и делюсь ключевыми идеями Tristan Handy (CEO dbtLabs) о новом опыте работы с dbt
— ❓ Что делать если в СУБД отсутствуют необходимые функции и преобразования?
— 🚀 Ключевые метрики компании на дашборде - путь от hardcoded cube к live calculated measures
— Моделирование отчета для BI в виде сводной таблицы со сравнением периодов
— Работа с ГЕО-данными в DWH: координаты, зоны, агрегация
— Зрелость DBT-проекта. Есть, куда расти?
— Стратегия инкрементального наполнения витрин: необходимость, реализация, подводные камни

Business Intelligence

— ⭐ Apache Superset — продолжаю использовать и приятно удивлен
— Business Intelligence 101: Всё самое важное о BI инструментах
— 👀 Продлеваю контракт с Looker (Annual Contract Renewal)
— 🔼 Aggregate awareness
— ☄ Хочу 100 графиков на дашборде и чтобы отображались за 10 секунд
— 🙂 Datalens в Open Source

Semantic Layer

— 😒 dbt Semantic Layer - сплошное разочарование
— ⚡️ Replacing Looker with Cube + Superset
— Семантический слой для Аналитики ключевых метрик – dbt Metrics vs. Cube
— Аналитика ключевых метрик компании: dbt Metrics / Cube.js / LookML

DataOps and DevOps

— 🙂 Могли бы покритиковать архитектуру Data Stack?
— 😎 Уже более полугода использую Census App для задач reverse ETL
— Why I use dev containers?
— 💎 Операционализация аналитики c инструментами класса reverse ETL – опыт использования Census

Orchestrating jobs & DAGs

— 🔸 Развернул Self-hosted runner for Github Actions
— 🔺 Рецепт Airflow DAG - а так ли правильно мы его готовим?
— ⚙️ Добавить логику повторных попыток retry в оркестрацию расчетов DAG
— Мои рекомендации по альтернативам (для оркестрации dbt jobs)
— Оркестрация dbt jobs для Dev, Test, Prod без головной боли

Business Impact and Value

— 🤯 Нерелевантные, демотивирующие и бессмысленные задачи
— ☄ Вебинар Сквозная аналитика + Modern Data Stack
— ⭐ Single Person Team в Data Engineering
— Cчитаю, что чем выше уровень maturity в компании, тем меньше должен быть sum of data work.
— 🚀 Released myBI dbt Core and myBI Market showcase
— 🚀 Аналитика продуктивности команд разработки на основе данных Github
— End-to-End решение для аналитики на примере источника MaestroQA

Learning

— ✅ Первый дебютный запуск серии вебинаров Designing Modern Data Apps завершился!
— 🟢 [Designing Modern Data Apps] Цикл вебинаров
— 💰 Подписка на ресурсы издательства O'Reilly - одно из самых выгодных вложений
— 👀 Как вы структурируете свои мысли?


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

🔺 Рецепт Airflow DAG - а так ли правильно мы его готовим?

#orchestration

За многие годы Airflow стал де-факто стандартом в области управления цепочками взаимосвязанных задач.

Хотя сам инструмент позиционируется как полноценное решение для построения пайплайнов данных, мною он всегда рассматривался только как оркестратор (дирижер, раздающий задачи). Решать эти задачи мною призывались специализированные инструменты:

— Processing: curl, jq, awk, sed
— File storage: S3, MinIO
— Transformations: dbt + DBMS (Clickhouse, Snowflake, ...)
— Alerts: Slack, Telegram


🔺 Дам пример: перед нами задача — регулярно получать выгрузки из REST-сервиса для аналитики в Clickhouse.

Вся соль DAG в том, какими инструментами и набором шагов мы решим эту задачу. Сравните

Подход #1:

— 20 разных endpoints (справочники, факты)
— DAG с PythonOperator на каждый endpoint, request с обработкой ответа
— Вставка результата (JSON) в MongoDB как документ
— Создание целевых таблиц в Clickhouse (SQL = CREATE TABLE ...)
— Предобработка данных (типы, название колонок, порядок), возможно в pandas
— Вставка в целевые таблицы (INSERT loop = медленно)

И подход #2:

— Однострочный bash-скрипт с параметрами curl ${ENDPOINT} | jq | s3 copy ${S3_BUCKET_PATH} -
— Конфиг в yaml с параметрами для 20 endpoints
— Генерация DAG по шаблону BashOperator на основе yaml config
— Запись результатов в стиле Extract - Load в S3
— Чтение из Clickhouse с использованием S3 table engine (с чтением схемы schema inference)


🔹 В качестве критериев для сравнения используйте:

— Простота конфигурации и гибкость (endpoint: добавить, убрать, применить фильтр, записать в другой S3 bucket, выполнить полный пересчет)
— Быстрота (скорость работы, устойчивость к росту объема данных)
— Принцип EL = все трансформации в DWH (никаких трансформаций вне DWH)
— Устойчивость к изменениям и проблемам (какие точки отказа? сколько их?)
— Поддержка Schema Evolution (меняются атрибуты, типы данных в выгрузке - будет ли ошибка? требуются ли ручные действия?)


Хочется разразиться целой публикацией на Хабр на этот счет: обзор возможностей, эволюция развития инструмента, лучшие практики (и плохие тоже) и их рационализация. Дайте реакций, и это случится.

🔻 А что вы думаете насчет Airflow и рецептов DAGs? Какого подхода придерживаетесь?


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