# Snowflake у 2026: архітектура, SQL та питання для співбесіди інженера даних

> Гайд 2026 року з архітектури Snowflake для інженерів даних: як розділяються сховище й обчислення, як працюють virtual warehouses і micro-partitions, а також питання зі співбесід, що перевіряють продакшн-досвід.

- Published: 2026-06-29
- Updated: 2026-07-06
- Author: SharpSkill
- Tags: snowflake, data-engineering, data-warehouse, sql, snowflake-architecture, dynamic-tables
- Reading time: 10 min

---

Питання на співбесідах щодо Snowflake перевіряють, чи розуміє інженер даних роз'єднану архітектуру платформи, а не лише її синтаксис SQL. Дизайн multi-cluster shared data, який запровадив Snowflake, розділяє сховище, обчислення та сервіси на три незалежні рівні, і саме це розділення пояснює майже кожне рішення команди щодо продуктивності й вартості на платформі. Цей матеріал охоплює архітектуру Snowflake, SQL-патерни, які утримують запити швидкими та дешевими у 2026 році, а також питання зі співбесід, що виявляють справжній продакшн-досвід.

> **Триярусна архітектура Snowflake одним реченням**
>
> Snowflake розбиває сховище даних на три незалежні рівні: централізоване storage, що зберігає стиснуті колонкові дані, virtual warehouses, які надають еластичні обчислення, та рівень cloud services, що відповідає за метадані, безпеку й оптимізацію запитів. Кожен рівень масштабується, не впливаючи на інші.

## Архітектура Snowflake: сховище, обчислення та cloud services

Визначальна риса архітектури Snowflake полягає в тому, що сховище й обчислення фізично розділені. Дані зберігаються один раз у централізованому рівні storage, що спирається на хмарні об'єктні сховища на кшталт Amazon S3 чи Azure Blob Storage. Будь-яка кількість обчислювальних кластерів може читати ці самі дані одночасно, не копіюючи їх, — підхід, який початкова інженерна команда назвала [multi-cluster shared data](https://dl.acm.org/doi/10.1145/2882903.2903741) у статті для SIGMOD 2016 року, де вперше було представлено цей дизайн.

Рівень storage тримає дані в незмінних, стиснутих колонкових файлах, що звуться micro-partitions. Користувач ніколи не керує цими файлами напряму. Snowflake записує їх, відстежує їхні метадані й повертає простір. Обчислювальний рівень складається з virtual warehouses, кожен з яких є кластером серверів, що Snowflake виділяє на вимогу. Рівень cloud services стоїть над обома й координує все: він парсить SQL, планує запити, застосовує контроль доступу, керує транзакціями та зберігає метадані, завдяки яким можливі такі функції, як Time Travel і zero-copy cloning.

Оскільки ці рівні незалежні, warehouse можна змінити в розмірі або видалити, не торкаючись жодного байта даних, а сховище може розростатися до петабайтів без виділення обчислень.

```sql
-- setup_warehouse.sql
-- Create an isolated compute cluster and a database.
CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'MEDIUM'      -- 4 credits/hour, doubles each size step
  AUTO_SUSPEND = 60             -- suspend after 60s idle to stop billing
  AUTO_RESUME = TRUE            -- resume automatically on the next query
  INITIALLY_SUSPENDED = TRUE;

CREATE DATABASE sales_analytics;
USE WAREHOUSE analytics_wh;
USE DATABASE sales_analytics;

-- Storage and compute are independent: dropping the warehouse
-- leaves every table in sales_analytics untouched.
```

Видалення `analytics_wh` після виконання цього скрипту зупинить весь білінг за обчислення, тоді як кожна таблиця залишиться доступною для запитів у ту саму мить, щойно буде створено новий warehouse. Саме це роз'єднання є найважливішою ідеєю, яку варто чітко сформулювати на співбесіді.

## Як virtual warehouses масштабують обчислення Snowflake

Virtual warehouse — це іменований обчислювальний кластер, розмір якого задається в одиницях за принципом T-shirt: X-Small, Small, Medium, Large і далі. Кожен крок угору подвоює і кількість серверів, і споживання кредитів за годину, тож warehouse Large коштує вчетверо дорожче за Small, але й завершує запит із важким скануванням приблизно вчетверо швидше. Цей лінійний компроміс «ціна за продуктивність» означає, що найдешевшим варіантом часто є більший warehouse, який працює менший час.

Існують два виміри масштабування, і їх плутанина — поширена пастка на співбесідах. Вертикальне масштабування змінює розмір одного warehouse, щоб прискорити один запит. Горизонтальне масштабування додає кластери до multi-cluster warehouse, щоб обслуговувати більше одночасних запитів. Дашборд, до якого о 9 ранку звертаються 200 аналітиків, потребує більше кластерів, а не більшого; нічний backfill трильйона рядків потребує більшого, а не більшої кількості кластерів.

> **Вертикальне проти горизонтального масштабування**
>
> Змінюйте розмір warehouse (вертикально), щоб прискорити один повільний запит, який сканує багато даних. Додавайте кластери (горизонтально) до multi-cluster warehouse, коли багато користувачів виконують запити водночас і запити починають ставати в чергу. Одне вирішує проблему затримки для важкого завдання; інше вирішує проблему конкурентності для багатьох дрібних завдань.

```sql
-- scale_compute.sql
-- Multi-cluster warehouse: add clusters when concurrency rises and
-- remove them when demand falls. Each cluster is a separate MEDIUM engine.
ALTER WAREHOUSE analytics_wh SET
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4          -- up to 4 clusters during peak load
  SCALING_POLICY = 'STANDARD';   -- favor performance over credit savings

-- Resize vertically for one heavy job, then shrink back afterward.
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'XLARGE';
-- ... run the heavy backfill ...
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'MEDIUM';
```

Саме `AUTO_SUSPEND` і `AUTO_RESUME` роблять це економічно вигідним. Призупинений warehouse не коштує нічого, а Snowflake тарифікує посекундно з мінімумом у 60 секунд. Встановлення короткого auto-suspend на інтерактивних warehouses запобігає тому, щоб простоюючі кластери спалювали кредити між запитами.

## Micro-partitions та clustering keys для швидкого SQL

Snowflake зберігає кожну таблицю як набір [micro-partitions](https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions), кожна з яких містить від 50 до 500 МБ нестиснутих даних у колонковому форматі. Для кожної micro-partition Snowflake записує в метадані мінімальне й максимальне значення кожної колонки. Коли запит фільтрує за колонкою, оптимізатор читає ці метадані й пропускає будь-яку партицію, діапазон значень якої не може відповідати умові, — процес, що зветься partition pruning. Саме тому Snowflake не потребує ручних індексів: pruning відбувається автоматично для кожної колонки.

Pruning працює найкраще, коли колонка фільтра корелює з порядком, у якому дані завантажувалися. Таблиця, куди дані надходять за датою, ефективно виконує pruning для запитів за діапазоном дат. Коли велику таблицю часто фільтрують за колонкою, не пов'язаною з порядком завантаження, clustering key розміщує споріднені рядки поруч у micro-partitions, щоб pruning залишався ефективним у міру зростання таблиці.

```sql
-- clustering.sql
-- Filters on naturally ordered columns prune partitions with no index.
SELECT order_date, SUM(amount_usd) AS revenue
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY order_date;

-- For a multi-terabyte table queried by a non-load-order column,
-- a clustering key co-locates related rows to keep pruning effective.
ALTER TABLE orders CLUSTER BY (customer_region, order_date);

-- Inspect clustering depth before committing to a key.
SELECT SYSTEM$CLUSTERING_INFORMATION('orders', '(customer_region, order_date)');
```

Clustering keys не безкоштовні: Snowflake запускає автоматичний фоновий сервіс для їх підтримки, і цей сервіс споживає кредити. Практичне правило — додавати clustering key лише до таблиць терабайтного масштабу, де профілі запитів показують слабкий pruning. Менші таблиці добре виконують pruning самі по собі, а передчасний clustering key марнує гроші. Пояснення цього компромісу часто й відрізняє відповідь джуніора від відповіді сеньйора.

> **Clustering може коштувати більше, ніж заощаджує**
>
> На таблиці з частими вставками й оновленнями автоматичний сервіс re-clustering безперервно реорганізує micro-partitions, щоб утримати clustering key, і ця підтримка може спалити більше кредитів, ніж запити, які вона прискорює. Спершу виміряйте навантаження запитів за допомогою query profile й залиште clustering для таблиць, які читають значно частіше, ніж пишуть.

## Завантаження й трансформація даних: Snowpipe, Streams та Dynamic Tables

Три патерни завантаження покривають більшість робочих навантажень. Масове `COPY INTO` завантажує застейджені файли однією командою й підходить для запланованих пакетних завдань. Snowpipe завантажує файли безперервно в serverless мікропакетах, спрацьовуючи за подіями хмарного сховища, для надходження даних майже в реальному часі. Snowpipe Streaming проштовхує окремі рядки через низьколатентний API, коли важлива субсекундна свіжість. Вибір між ними за вимогами до затримки й розміру файлів — часте питання на співбесідах, і правильна відповідь починається з «залежить від того, яку свіжість реально потребує споживач нижче за потоком».

Трансформація всередині warehouse історично покладалася на Streams і Tasks. Stream фіксує зміни на рівні рядків у таблиці (change data capture), а Task виконує SQL за розкладом, щоб спожити ці зміни й змерджити їх далі.

```sql
-- incremental_pipeline.sql
-- A stream tracks row-level changes (CDC) on the raw landing table.
CREATE STREAM orders_stream ON TABLE raw_orders;

-- A task consumes the stream on a schedule and merges changes downstream.
CREATE TASK refresh_orders
  WAREHOUSE = analytics_wh
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO orders t
  USING orders_stream s ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET t.amount_usd = s.amount_usd
  WHEN NOT MATCHED THEN INSERT (order_id, amount_usd)
    VALUES (s.order_id, s.amount_usd);
```

У 2026 році Dynamic Tables стали переважним способом виражати інкрементальні трансформації. Замість того щоб з'єднувати Stream із Task і писати merge вручну, Dynamic Table оголошує цільовий lag і запит, а Snowflake сам вираховує інкрементальне оновлення. Це усуває більшу частину оркестраційного шаблонного коду, зберігаючи результати свіжими.

```sql
-- dynamic_table.sql
-- Dynamic Tables replace the stream + task pattern with a declarative
-- target lag. Snowflake computes the incremental refresh automatically.
CREATE DYNAMIC TABLE daily_revenue
  TARGET_LAG = '5 minutes'
  WAREHOUSE = analytics_wh
AS
  SELECT order_date, SUM(amount_usd) AS revenue
  FROM orders
  GROUP BY order_date;
```

Для команд, які будують на відкритих форматах, Iceberg tables у Snowflake дають змогу warehouse читати й писати дані [Apache Iceberg](https://iceberg.apache.org/), що зберігаються у власному хмарному бакеті клієнта, — це уникає прив'язки до вендора, зберігаючи водночас рушій запитів і governance від Snowflake. Багато команд поєднують Snowflake із [dbt](https://docs.getdbt.com/) для версіонованих і протестованих трансформацій — робочий процес, розглянутий у [гайді з трансформацій і тестування даних у dbt](/blog/data-engineering/dbt-data-transformations-testing-interview-2026).

## Питання зі співбесід щодо Snowflake для інженерів даних

Наведені нижче питання раз у раз з'являються на співбесідах з інженерії даних щодо Snowflake. Сильні відповіді пов'язують функцію назад із розділенням сховища й обчислень, а не переказують синтаксис.

**Яку проблему вирішує розділення сховища й обчислень?** Воно усуває конкуренцію за ресурси. Аналітики, що працюють з дашбордами, команда data science, що тренує ознаки, і ELT-завдання, що завантажує дані, можуть кожне працювати на власному warehouse проти тих самих таблиць, не змагаючись за ресурси й не копіюючи дані. Обчислення масштабуються вгору для важкого завдання й призупиняються, коли простоюють, тоді як вартість сховища залишається сталою незалежно від того, скільки обчислень до нього під'єднано.

**Як працюють Time Travel і zero-copy cloning?** Обидві функції спираються на незмінність micro-partitions. Оскільки Snowflake ніколи не перезаписує micro-partition, старіші версії залишаються на диску протягом вікна утримання (до 90 днів на Enterprise). Time Travel запитує таблицю станом на минулу мітку часу, вказуючи на ці старіші партиції, а `CLONE` створює нову таблицю, що посилається на ті самі партиції, не дублюючи сховище, доки одна зі сторін не буде змінена. Саме copy-on-write робить клонування петабайтної таблиці миттєвим і майже безкоштовним.

**Коли слід визначати clustering key?** Лише на великих таблицях (приблизно терабайт і більше), які часто фільтрують чи джойнять за колонкою, не пов'язаною з їхнім порядком завантаження, і лише після того, як query profile підтвердить слабкий pruning. Clustering спричиняє постійну вартість підтримки в кредитах, тож це навмисна оптимізація, а не значення за замовчуванням.

**Як контролюється вартість Snowflake?** Через розмір warehouse, агресивний auto-suspend, узгодження кількості кластерів із реальною конкурентністю та resource monitors, що обмежують витрати кредитів. Resource monitor може автоматично сповіщати або призупиняти warehouses, щойно досягнуто квоти.

```sql
-- cost_control.sql
-- A resource monitor caps credit spend and suspends warehouses
-- automatically when the monthly quota is reached.
CREATE RESOURCE MONITOR monthly_cap
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_cap;
```

**Streams і Tasks чи Dynamic Tables?** Dynamic Tables підходять для декларативних пайплайнів, де вимогою є цільова свіжість, а Snowflake може керувати оновленням. Streams і Tasks залишаються правильним інструментом, коли трансформація потребує імперативного контролю, побічних ефектів або логіки, яку не можна виразити одним запитом. Розуміння того, де що доречне, замість того щоб за замовчуванням хапатися за одне, свідчить про продакшн-досвід.

**Чим ELT у Snowflake відрізняється від традиційного ETL?** Дешеве сховище й еластичні обчислення Snowflake роблять практичним завантаження сирих даних спершу й трансформацію їх на місці — патерн, розглянутий у [гайді з архітектури ETL проти ELT](/blog/data-engineering/etl-vs-elt-data-pipeline-architecture). Кандидати, які готуються до повного циклу, можуть відпрацювати [модуль з патернів ETL та ELT](/technologies/data-engineering/interview-questions/etl-elt-patterns) поряд із ширшим [треком з інженерії даних](/technologies/data-engineering).

## Висновок

- Архітектура Snowflake розділяє сховище, обчислення та cloud services на три незалежні рівні, і майже кожна відповідь щодо дизайну зводиться назад до цього розділення
- Virtual warehouses масштабуються вертикально для важчих окремих запитів і горизонтально для вищої конкурентності; auto-suspend і посекундний білінг залишають простоюючі обчислення безкоштовними
- Micro-partitions із метаданими min/max для кожної колонки дають автоматичний partition pruning, тому Snowflake не потребує ручних індексів
- Додавайте clustering keys лише до таблиць терабайтного масштабу з доведено слабким pruning, оскільки підтримка споживає кредити
- Узгоджуйте патерн завантаження з потрібною свіжістю: масове COPY для пакетів, Snowpipe для безперервних мікропакетів, Snowpipe Streaming для субсекундної затримки
- Надавайте перевагу Dynamic Tables для декларативних інкрементальних трансформацій у 2026 році, а Streams і Tasks залишайте для імперативної логіки
- Time Travel і zero-copy cloning обидва використовують незмінність micro-partitions і copy-on-write, роблячи запити на момент часу й миттєві клони дешевими
- Контролюйте вартість за допомогою правильно підібраних за розміром warehouses, агресивного auto-suspend, узгоджених із конкурентністю кластерів та resource monitors

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/uk/blog/data-engineering/snowflake-architecture-sql-data-engineer-interview-2026