Расскажи про объемы данных, с которыми сталкивался

Объёмы данных в Big Data практике

Когда говорят об объёмах данных, важно понимать масштабы и как они влияют на выбор инструментов и архитектуры. Рассмотрю реальные примеры, с которыми сталкиваются Data Engineers.

Единицы измерения и масштабы

1 KB = 10^3 байт
1 MB = 10^6 байт  
1 GB = 10^9 байт
1 TB = 10^12 байт (терабайт)
1 PB = 10^15 байт (петабайт)
1 EB = 10^18 байт (эксабайт)

Аналогии для понимания:

• 1 GB = примерно 4 фильма в HD
• 1 TB = примерно 1000 фильмов
• 1 PB = примерно 1 миллион фильмов

Уровни данных и инструменты

Уровень 1: Small Data (до 100 GB)

Характеристики:

• Помещается на одном ноутбуке/сервере
• Обработка за минуты-часы
• PostgreSQL, MySQL, SQLite достаточно

Пример:

import pandas as pd

# Всё в памяти (16 GB машины)
df = pd.read_csv('users_100gb.csv')
df.groupby('country').agg({'revenue': 'sum'}).sort_values(ascending=False)

Производительность:

• Одна машина 32 cores
• 2-4 часа обработки
• PostgreSQL с 64 GB RAM

Уровень 2: Medium Data (100 GB - 1 TB)

Характеристики:

• Требует оптимизации
• Распределённые системы ещё не критичны
• Можно использовать одну мощную машину или малый кластер

Пример:

import psycopg2
import polars as pl

# Используем Polars вместо Pandas (быстрее)
df = pl.read_csv('events_500gb.csv', streaming=True)
result = (
    df
    .with_columns(pl.col('timestamp').cast(pl.Datetime))
    .filter(pl.col('revenue') > 0)
    .groupby('user_id')
    .agg([pl.col('revenue').sum(), pl.col('*').count()])
)

Инструменты:

• DuckDB для аналитики
• TimescaleDB для time-series
• Одна машина с 256 GB RAM

Уровень 3: Big Data (1 TB - 100 TB)

Характеристики:

• Требует распределённых систем
• Типичный размер для среднего стартапа
• Spark, Hadoop, Presto

Пример архитектуры:

User events (50 GB/day)
    ↓
Kafka (streaming buffer)
    ↓
S3 (raw data)
    ↓
Spark job (ETL)
    ↓
Parquet files (structured)
    ↓
Redshift/BigQuery (DWH)
    ↓
BI tools (Tableau, Looker)

Обработка в Spark:

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, sum, count, date_format

spark = SparkSession.builder     .appName('large_etl')     .config('spark.executor.memory', '16g')     .config('spark.executor.cores', 8)     .config('spark.executor.instances', 10)     .getOrCreate()

# Чтение 50 TB parquet
df = spark.read.parquet('s3://bucket/events/*/*')

# Трансформация
result = (
    df
    .filter(col('event_type') != 'bot')
    .groupBy(date_format('timestamp', 'yyyy-MM-dd'), 'country')
    .agg(
        count('*').alias('events'),
        sum('revenue').alias('total_revenue')
    )
    .write
    .parquet('s3://bucket/aggregated/')
)

Стоимость:

• 10 машин x 16GB RAM = 160 GB
• Обработка: 2-4 часа
• Стоимость AWS: $50-100 за job

Уровень 4: Very Big Data (100 TB - 1 PB)

Характеристики:

• Требует оптимизированной архитектуры
• Парттиционирование критично
• Часто используется облако (AWS, GCP, Azure)

Пример:

# Facebook: 4+ PB в день
# Google: 20+ PB в день
# Uber: 100+ TB в день

# Типичная таблица: 500 TB
# Партиции по дате
SELECT user_id, COUNT(*) as events
FROM events
WHERE DATE(timestamp) = '2024-01-15'  # Читаем только 1 день!
GROUP BY user_id

SQL оптимизация для больших данных:

-- ❌ Медленно: сканирует всё
SELECT COUNT(*) FROM events;

-- ✅ Быстро: партиционированный запрос
SELECT COUNT(*) FROM events 
WHERE partition_date >= '2024-01-01' AND partition_date <= '2024-01-15';

-- ✅ Columnar формат (Parquet)
-- События хранятся столбцами, не строками
-- Чтение только нужных столбцов
SELECT user_id, event_type FROM events 
-- Читается только 2 столбца из 50, а не все 50!

Инструменты:

• Snowflake, BigQuery, Redshift
• ClickHouse для метрик
• Apache Spark кластер (50+ nodes)

Уровень 5: Ultra Big Data (1+ PB)

Характеристики:

• Требует специальной архитектуры
• Обработка может занимать недели
• Только для крупных компаний

Примеры компаний:

• Google: 20+ EB в день
• Facebook: 4+ EB в день
• Amazon: petabytes в день

Реальный pipeline компании с 1 PB:

# 1. Real-time streaming (Kafka)
# 2. Data Lake (S3/HDFS) - raw данные
# 3. Data Warehouse (Snowflake) - обработанные
# 4. Analytics (Looker, Tableau)

# Example job
from airflow import DAG
from airflow.operators.spark_submit_operator import SparkSubmitOperator
from datetime import datetime, timedelta

dag = DAG(
    'petabyte_etl',
    default_args={
        'start_date': datetime(2024, 1, 1),
        'retries': 3
    }
)

# Работает каждый день на 5 TB данных
task = SparkSubmitOperator(
    task_id='process_events',
    application='s3://bucket/spark_jobs/etl.py',
    conf={
        'spark.executor.instances': '200',
        'spark.executor.memory': '32g',
        'spark.executor.cores': 16
    },
    total_executor_cores=3200  # 200 * 16
)

Бенчмарки производительности

Практические рекомендации

Для разных объёмов:

1. < 10 GB: Используй ноутбук, Python, Pandas
2. 10-100 GB: PostgreSQL + Pandas streaming
3. 100 GB - 1 TB: DuckDB или малый Spark кластер (3-5 nodes)
4. 1-100 TB: Spark кластер (10-50 nodes) + S3 + Redshift
5. 100 TB - 1 PB: Снежинка + Spark (100+ nodes) + специалист DevOps
6. 1+ PB: Собственная инфраструктура, команда из 10+ engineers

Оптимизация для больших данных

-- 1. Партиционирование
CREATE TABLE events (
    id INT,
    timestamp TIMESTAMP,
    data JSONB
) PARTITION BY RANGE (timestamp);

-- 2. Индексирование
CREATE INDEX idx_events_user ON events(user_id) WHERE active = true;

-- 3. Denormalization (для аналитики)
-- Создавай плоские таблицы вместо joins

-- 4. Compression
-- Parquet автоматически сжимает данные в 10x раз

-- 5. Columnar формат
-- Читай только нужные столбцы
SELECT 3 columns FROM 50-column table  -- быстро

Вывод

Понимание масштабов критично для выбора:

• Инструментов (Pandas vs Spark vs ClickHouse)
• Архитектуры (одна машина vs распределённая)
• Стоимости ($10 vs $10,000 в месяц)
• Времени обработки (секунды vs часы)

На собеседовании важно показать, что ты работал с реальными масштабами и знаешь trade-offs между разными подходами.