Расскажи про последнее место работы

# Последнее место работы: FinTech стартап (2022-2024)

Компания и контекст

Компания: PayFlow — финтех платформа для микро-кредитования через мобильное приложение. Серия B раунд, ~50 человек, 15 в техе.

Моя роль: Senior Data Engineer (вторая в команде DE после Lead).

Команда: 1 Lead Data Engineer + я + 1 Junior + 2 Аналитика

Ответственности

1. Архитектура Data Pipeline

Построил систему обработки финансовых данных:

• Источники: Mobile app (100K+ DAU), Banking API (интеграция с 5+ банков), Kafka очереди (real-time events)
• Процесс: Kafka → Spark Structured Streaming → Data Lake (S3) → BigQuery
• Объём: ~2TB данных в месяц, 500B+ events в день

Основные DAG в Airflow:

• ingest_raw_events — загрузка raw данных каждые 5 минут
• transform_to_silver — cleaning, validation, deduplication
• build_analytics_warehouse — OLAP cube для дашбордов
• feature_engineering — подготовка features для ML моделей

2. Real-time Analytics

Часто нужны метрики "прямо сейчас":

• Количество активных юзеров
• Сумма кредитов, выданных в текущий день
• Риск дефолтов (красный флаг)

Решение:

Mobile App → Kafka Topic → 
Spark Structured Streaming (aggregation в памяти) → 
Redis (1 минутная кэширование) → 
API для фронтенда

Латентность: 30-50 сек до обновления метрик на дашборде.

3. Data Quality

В финансовых данных ошибки стоят денег. Реализовал:

# Great Expectations для автоматических проверок
expectations = [
    expect_column_values_to_not_be_null('user_id'),
    expect_column_values_to_be_of_type('amount', 'decimal'),
    expect_column_values_to_be_between('amount', 100, 100000),
    # Количество новых записей не должно отличаться от среднего более чем на 50%
    expect_table_row_count_to_be_between(day_avg * 0.5, day_avg * 1.5),
]

Если тест падает:

1. Pipeline приостанавливается
2. Алерт в Slack + PagerDuty
3. Аналитики уведомляются

Удалось предотвратить 3 инцидента с неправильными данными в отчётности.

4. Data Governance

• PII Protection: Стирание sensitive данных (паспорт, адрес) через 90 дней по законодательству
• Audit logs: Кто, когда и что доступ получил
• Lineage tracking: Откуда берётся каждое число в отчёте
• GDPR compliance: Right to be forgotten — удаление всех данных по запросу

5. Оптимизация и Cost

Проблема: Счёт за BigQuery = $15K/месяц (большой рост)

Решение:

• Partitioned tables по дате (_PARTITIONTIME)
• Clustering по частым колонкам (user_id, currency)
• Материализованные views для часто используемых агрегаций
• Автоматический expiration для temp данных (30 дней)

Результат: Сэкономили $8K/месяц (-50%), не потеряв функциональность.

Технический стек

• Streaming: Apache Kafka (AWS MSK), Spark Structured Streaming
• Batch: PySpark, Apache Airflow
• Хранилище: S3 (Data Lake), BigQuery (DWH)
• Инструменты: dbt для трансформации, Great Expectations для QA
• Мониторинг: CloudWatch, custom metrics в Prometheus
• Язык: Python 3.10, SQL

Ключевые достижения

1. Масштабирование без pain

Было: Airflow работал на одной t2.medium машине Проблема: DAG'ы то и дело тайм-аутили при росте данных

Решение: Миграция на управляемый Airflow (Cloud Composer), переход на KubernetesExecutor

Результат: Надёжность поднялась с 95% до 99.9%, DAG'ы выполняют на 30% быстрее

2. Incident Response Time

Было: Когда что-то ломалось, об этом узнавали часами Решение:

• Data Quality tests на каждый источник
• Автоматические alerts
• Runbooks для типичных проблем

Результат: Mean time to detect (MTTD) упал с 4 часов до 15 минут

3. Self-service аналитика

Было: Аналитики просили запросы, я писал Решение: Построил dbt проект с документацией, примерами, semantic layer

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

Уроки и learnings

✅ Что хорошо сделал

1. Внимание к качеству данных с самого начала — финансовые данные требуют строгости
2. Документация — описал каждый DAG, каждое преобразование. Спасло при onboarding нового DE
3. Метрики всё — мониторил не только uptime, но и freshness, completeness, accuracy
4. Общение с stakeholders — регулярный sync с аналитиками, ML team, финансистами

❌ Что бы переделал

1. Dbt внедрил бы раньше — сначала писал SQL в Spark, затем переписал на dbt. Потеряли 2 месяца
2. Testing с самого начала — первые 6 месяцев тестов практически не было. После добавления значительно упал bagcount
3. Schema versioning — изменения схемы вызывали downstream breaks. Нужна была версионизация

Почему ушёл

Компания получила серию B и направилась в более бюрократический путь (корпоративные процессы, много meetings, медленные решения). Мне нравится двигаться быстро и принимать решения. Также хотел вернуться к более крупному масштабу данных (петабайты, не терабайты) и более сложным алгоритмам обработки.

Текущие интересы

Ищу позицию, где можно:

• Работать с multi-petabyte масштабом данных
• Влиять на архитектуру data platform на уровне компании
• Развиваться в direction ML/AI data pipelines
• Иметь autonomy в технических решениях