Как вы взаимодействуете с дата-сайентистами и бизнес-аналитиками?

Взаимодействие Data Engineer с Data Scientist и BA

Введение

Data Engineer — это мост между бизнесом и технологией. Успех зависит от эффективного сотрудничества с разными специалистами. Каждый имеет разные требования и способ мышления.

1. Взаимодействие с Data Scientist

Различия в фокусе

Сценарий: Data Scientist просит данные

DS: "Мне нужны все события за 2024 с атрибутами user, event_type, timestamp"

DE: "Какой объём? Нужна ли история? Какая гранулярность?
     Нужны ли real-time или батч раз в день?"

DS: "10 млн строк, история за 3 года, для ML модели"

DE: "Создам таблицу на S3 (Parquet), обновляемую раз в день." 

Как DE помогает DS

# 1. Предоставить clean API для данных
# В Spark, Pandas, или через SQL

from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("DataScience").getOrCreate()

# DS может просто использовать
df_events = spark.read.parquet("s3://data-lake/events/")

# 2. Документировать схему и качество
df_events.printSchema()
# root
# |-- event_id: string (nullable = true)
# |-- user_id: string (nullable = true)
# |-- event_type: string (nullable = true)
# |-- timestamp: timestamp (nullable = true)

# 3. Обеспечить воспроизводимость
# Данные версионируются, легко откатить

# 4. Оптимизировать performance
df_events.repartition("date").write.parquet(...)

Частые требования DS и как их решать

# Требование 1: "Нужны данные за конкретный период"
# Решение: партиционирование по дате
df = spark.read.parquet("s3://data/events/date=2024-01-*")

# Требование 2: "Нужна история без гэпов"
# Решение: SCD (Slowly Changing Dimension)
def apply_scd_type2(source, target):
    """Вставить с историей версий"""
    source.write.mode("append").parquet(target)

# Требование 3: "Нужны трансформации"
# Решение: готовые pipelines и feature store
from feast import FeatureStore
fs = FeatureStore(repo_path=".")
features = fs.get_online_features(
    features=["user:age", "user:country"],
    entity_rows=[{"user_id": "123"}]
)

2. Взаимодействие с Business Analyst

Различия

Сценарий: BA просит отчёт

BA: "Нужен отчёт по продажам по категориям"

DE: "За какой период? Нужны ли trends? Какая гранулярность?
     Нужна ли интерактивность или статичный отчёт?"

BA: "Последние 12 месяцев, по неделям, интерактивный"

DE: "Создам dbt модель для витрины, свяжу с BI инструментом (Tableau, Looker)."

Как DE помогает BA

-- 1. Создать витрину (data mart) для BA
CREATE TABLE warehouse.sales_by_category AS
SELECT 
    DATE_TRUNC('week', sale_date)::date as week,
    product_category,
    SUM(amount) as total_sales,
    COUNT(*) as transaction_count,
    AVG(amount) as avg_transaction
FROM warehouse.sales
GROUP BY 1, 2
ORDER BY 1, 2;

-- 2. Добавить документацию (для BA)
-- Таблица обновляется ежедневно в 03:00 UTC
-- Data Freshness: 24 часа
-- Качество: 99.5% (есть 0.5% null values в notes)

-- 3. Обеспечить правильные метрики
-- GMV = SUM(amount) WHERE status = 'completed'
-- Не считаем cancelled, refunded

-- 4. Предоставить доступ через безопасный интерфейс
-- BA может запрашивать через Tableau, не зная SQL

3. Управление требованиями и изменениями

Процесс согласования

1. ПОНИМАНИЕ требования
   BA/DS: "Нужна витрина по клиентам"
   DE: "Расскажи больше..."
   
   Вопросы:
   - Какие метрики? (customer lifetime value, churn rate, ...)
   - За какой период? (last 12 months, last transaction, ...)
   - Какова частота обновления? (real-time, daily, weekly, ...)
   - Какой объём данных? (millions, billions, ...)
   - Какие фильтры? (по region, по segment, ...)

2. ОЦЕНКА затрат
   DE: "Это займёт 3 дня + 5 часов обслуживания"
   
   Учитываем:
   - Сложность трансформаций
   - Нужны ли новые источники?
   - Тестирование и валидация
   - Документация
   - Обучение BA/DS

3. СОГЛАСОВАНИЕ
   Все стороны согласны с требованиями и временем
   
4. РАЗРАБОТКА
   DE разрабатывает, документирует, тестирует
   
5. ПЕРЕДАЧА
   DE передаёт с инструкциями по использованию

4. Коммуникация о данных

Как объяснить сложную информацию

# ПЛОХО: технический жаргон
"Я использовал SCD Type 2 с hash-based incremental load 
 на Spark с partition pruning."

# ХОРОШО: на бизнес-языке
"Я создал таблицу, которая отслеживает все изменения
данных клиентов с временными метками. Обновляется
ежедневно и быстро находит нужные данные."

# ХОРОШО: объяснить дополнительные гарантии
"Гарантии:
- Все данные проверены (0 пропусков)
- Обновляется каждый день в 03:00 UTC
- Доступна история за 3 года
- Можно фильтровать по любому полю"

5. Документирование и знания

Вики/Confluence для команды

# Таблица: customer_master

## Описание
Основная витрина по клиентам, источник истины (SoT)
для всех клиентских данных.

## Техническое описание
- **Источник**: raw.customers, raw.addresses
- **Обновление**: ежедневно в 03:00 UTC (SLA 4 часа)
- **Партиционирование**: по customer_id
- **Формат**: Parquet на S3 + PostgreSQL

## Колонки
- customer_id (UUID): уникальный идентификатор
- email (STRING): email клиента, нормализованный
- registration_date (DATE): дата регистрации
- lifetime_value (DECIMAL): LTV, обновляется ежедневно
- is_active (BOOLEAN): активен ли сейчас

## Качество данных
- Полнота: 99.8% (0.2% null в поле registration_date)
- Уникальность: 100% (нет дубликатов по customer_id)
- Актуальность: 24 часа (lag от источника)

## Примеры использования
```sql
SELECT COUNT(*) as active_customers
FROM customer_master
WHERE is_active = true;

Контакт

• Data Engineer: alex@company.com
• Slack канал: #data-engineering

### 6. Регулярные встречи и синхронизация

**Weekly Sync**
- 30 минут
- Участники: DE, DS, BA, Product
- Повестка:
  1. Новые требования
  2. Проблемы с существующими витринами
  3. Планы на следующую неделю

**Ежеквартальное планирование**
- Обсудить большие проекты
- Выделить ресурсы
- Пересмотреть SLA

### 7. Управление конфликтами

**Сценарий: требование требует больше времени**

BA: "Мне нужно завтра!" DE: "Это требует тестирования и документации. Могу сделать через неделю, гарантируя качество."

Решение:

• Понять истинный deadline (всегда ли завтра?)
• Предложить MVP (minimum viable product)
• Расставить приоритеты
• Возможно, попросить ресурсы

**Сценарий: требования противоречивы**

DS: "Нужны raw data для экспериментов" BA: "Данные должны быть только чистые!" DE: "Создам отдельные слои: - raw (для DS экспериментов) - cleaned (для BA отчётов) - trusted (для production)"

### 8. Best Practices

**DO (делай)**
- ✓ Слушай активно и задавай уточняющие вопросы
- ✓ Документируй всё (схему, SLA, ограничения)
- ✓ Будь проактивным (предложи оптимизации)
- ✓ Думай о масштабируемости (что если в 10 раз больше?)
- ✓ Демонстрируй результаты (покажи витрину)
- ✓ Объясняй на их языке (бизнес, не техно)

**DON'T (не делай)**
- ✗ Не говори "это невозможно"
- ✗ Не перекладывай ответственность
- ✗ Не создавай витрины без требований
- ✗ Не обещай то, что не сможешь сделать
- ✗ Не используй жаргон без объяснения
- ✗ Не игнорируй feedback

### Выводы

Data Engineer — это не просто тот, кто пишет код. Это партнёр, который:
- Понимает потребности бизнеса
- Переводит требования в архитектуру
- Обеспечивает надёжность и качество
- Растёт вместе с командой
- Документирует и делится знаниями

Хорошие отношения с DS и BA — это основа успешной data-программы в организации.