Big Data Interview FAQ

Big Data (великі дані) — це великі обсяги даних, які обробляються з високою швидкістю та мають високу різноманітність (структуровані, напівструктуровані та неструктуровані).

Від традиційних підходів відрізняються:

• Масштабами: петабайти та екзабайти даних проти гігабайт/терабайт у звичайних базах даних.
• Інструментами: використання розподілених систем (Hadoop, Spark) замість традиційних RDBMS систем на одному потужному сервері.
• Архітектурою: горизонтальне масштабування (додавання дешевих серверів) замість вертикального (покращення одного дорогого сервера).

Концепція 5V описує основні характеристики великих даних:

• Volume (Обсяг): Величезна кількість даних, що генерується (терабайти, петабайти).
• Velocity (Швидкість): Висока швидкість генерації та обробки даних (наприклад, потік даних у реальному часі).
• Variety (Різноманітність): Різні формати даних (структуровані таблиці, тексти, відео, логи).
• Veracity (Достовірність/Якість): Надійність та точність даних. Дані можуть бути «брудними» або неповними.
• Value (Цінність): Практична користь, яку бізнес може отримати з аналізу цих даних.

Існує багато BI-інструментів (Business Intelligence) для візуалізації даних. Найпопулярніші з них:

• Tableau: потужний інструмент для швидкого створення інтерактивних дашбордів. Дуже популярний у Data Science.
• Power BI: рішення від Microsoft, глибоко інтегроване в їхню екосистему та часто використовується великими корпораціями.
• Grafana: ідеально підходить для моніторингу метрик і систем у реальному часі (часто використовується з time-series БД).
• Apache Superset: open-source рішення, що легко працює з багатьма сучасними Big Data базами (ClickHouse, PostgreSQL, Presto).
• Looker: інструмент від Google, що базується на моделюванні даних через LookML.

• Структуровані дані: мають строго визначену схему (стовпці, типи даних) і легко зберігаються у вигляді традиційних реляційних таблиць. Приклад: Дані про транзакції у базі PostgreSQL (ID, Дата, Сума).
• Слабко (напів) структуровані дані: не мають жорсткої табличної схеми, але використовують теги, маркери або ключі для розділення елементів та ієрархій. Приклад: файли у форматах JSON, XML, логи серверів.
• Неструктуровані дані: не мають наперед заданої структури взагалі. Їх найскладніше аналізувати без допомоги штучного інтелекту або складної попередньої обробки. Приклад: тексти (листи, коментарі в соцмережах), аудіофайли, зображення, відео.

База даних (БД) — це впорядкований масив інформації, до якого можна отримати швидкий і структурований доступ.

Вона використовується для:

• Надійного та безпечного збереження даних.
• Забезпечення швидкого пошуку об'ємних даних (використовуючи індекси).
• Уникнення дублювання інформації і підтримки консистентності даних (у випадку реляційних БД).
• Забезпечення одночасного доступу багатьом користувачам (без конфліктів та втрати даних при перезапису).

Основні типи баз даних:

• Реляційні (RDBMS): Зберігають дані у таблицях, зв'язаних між собою. Орієнтовані на строгу цілісність (ACID) транзакцій. (PostgreSQL, MySQL, Oracle)
• NoSQL: Відмовляються від строгих табличних схем заради гнучкості та легкого горизонтального масштабування. Їх поділяють на:
  • Документоорієнтовані (MongoDB) — зберігають JSON-подібні документи.
  • Ключ-значення (Redis, DynamoDB) — надзвичайно швидкі, часто використовуються для кешу або зберігання сесій.
  • Графові (Neo4j) — для зберігання складних зв'язків (соцмережі, системи рекомендацій).
• Колонкові (Analytical/OLAP): Зберігають дані колонками, а не рядками. Ідеальні для аналітики та сховищ даних. (ClickHouse, Redshift)

Мова SQL складається з 4 основних підгруп команд (блоків):

• DDL (Data Definition Language): створення та зміна структури об'єктів БД (схем, таблиць, індексів, представлень). Команди: CREATE, ALTER, DROP, TRUNCATE.
• DML (Data Manipulation Language): робота з самими даними в таблицях (читання, запис, зміна). Команди: SELECT, INSERT, UPDATE, DELETE.
• DCL (Data Control Language): управління правами доступу користувачів. Команди: GRANT, REVOKE.
• TCL (Transaction Control Language): управління транзакціями (об'єднанням запитів). Команди: COMMIT, ROLLBACK, SAVEPOINT.

• Первинний ключ (Primary Key): Стовпець (або набір стовпців), який унікально ідентифікує кожен рядок у таблиці. PK гарантуує, що не буде дублікатів і не може мати значення NULL. (Наприклад, user_id).
• Зовнішній ключ (Foreign Key): Стовпець, який містить посилання на первинний ключ іншої (або тієї ж) таблиці. Він використовується для створення зв'язків між таблицями і забезпечує "посилальну цілісність" (Refential Integrity) — не можна послатись на ідентифікатор бази, якого не існує.

RIGHT JOIN повертає абсолютно всі рядки з правої таблиці (тієї, що вказана після оператора JOIN), а також лише ті рядки з лівої, які відповідають умові ON.

Якщо збігу в лівій таблиці немає, у відповідних колонках результату будуть заповнені значення NULL.

Відмінність від інших: По суті, він виконує ту саму роботу, що й LEFT JOIN, просто дзеркально. На практиці програмісти і дата-інженери майже завжди віддають перевагу LEFT JOIN (змінюючи порядок таблиць місцями), оскільки читати запити зліва направо набагато зручніше та інтуїтивніше для логіки людини.

Обидві команди працюють із групами (агрегаціями), але принципово відрізняються результатом виводу:

• GROUP BY: "Згортає" всі згруповані рядки в один підсумковий рядок. Тобто ви втрачаєте деталізацію вихідних даних. (Наприклад, SELECT department_name, SUM(salary) GROUP BY department_name — видасть лише 1 рядок на кожен департамент).
• PARTITION BY: Використовується виключно у Віконних функціях (Window Functions). Вона виконує агрегацію (ту ж саму суму) для групи або "вікна", але при цьому зберігає всі початкові рядки у виводі, додаючи результат як новий стовпець до кожного існуючого рядка. Це дозволяє уникнути об'єднання (JOIN) агрегованої таблиці з основною.

Ці таблиці є основою моделі "Зірка" (Star Schema) у сховищах даних:

• Таблиці фактів (Fact Tables): Містять кількісні (метричні) дані або події. Вони складаються з числових вимірів (сума продажу, кількість) та зовнішніх ключів (FK). Оновлюються дуже часто.
• Таблиці вимірів (Dimension Tables): Містять описові (контекстні) атрибути для даних у таблицях фактів. Відповідають на запитання "Хто, Що, Де, Коли". Наприклад: таблиця Клієнти, Товари, Дати. Оновлюються рідко.

Ітератор (Iterator) — це об'єкт, який реалізує протокол ітерації (методи __iter__() та __next__()). Дозволяє перебирати елементи колекції по одному.

Генератор (Generator) — це простіший спосіб створення ітераторів. Створюється за допомогою звичайної функції, але замість return повертає значення через yield.

Різниця та застосування: Генератори є підвидом ітераторів. Вони використовуються для обробки великих наборів даних або файлів (послідовно, рядок за рядком), оскільки не завантажують усі дані в пам'ять (RAM) одночасно.

• Списки (List): Записуються в [ ]. Є мутабельними, тобто їх можна змінювати після створення (додавати, видаляти, редагувати елементи).
• Кортежі (Tuple): Записуються в ( ). Є іммутабельними (незмінними). Після створення жоден елемент не можна змінити. Працюють трохи швидше ніж списки, і через їхню незмінність їх можна використовувати як ключі у словниках (dict).

Лямбда-функція — це невелика анонімна функція (функція без імені), яка може приймати будь-яку кількість аргументів, але містить лише один вираз. Будується через ключове слово lambda.

Коли використовувати: Ідеально підходять, коли функція потрібна лише на короткий проміжок часу і її логіка дуже проста. Наприклад, як аргумент для функцій map(), filter() або при сортуванні sorted(list, key=lambda x: x[1]).

Lazy evaluation — це механізм Apache Spark, який відкладає реальне виконання коду до того моменту, поки не знадобиться результат.

Яку роль відіграє: Поки ви робите трансформації (map, filter), Spark лише запам'ятовує їх, будуючи граф виконання (Lineage Graph/DAG). Він не починає рахувати дані, поки ви не викличете "дію" (Action, наприклад collect() або count()). Це дозволяє Spark застосувати глобальні оптимізації і знайти найбільш ефективний шлях обчислення.

• Трансформації (Transformations): Операції, які створюють новий RDD/DataFrame з існуючого. Вони виконуються ліниво (lazy). Приклади: map(), filter(), groupBy(), join().
• Дії (Actions): Операції, які повертають фінальний або проміжний результат у драйвер-програму або записують дані на диск. Вони запускають реальне обчислення всього графа перетворень. Приклади: count(), collect(), show(), write().

Amazon S3 (Simple Storage Service) — це хмарне об'єктне сховище. Воно призначене для зберігання і завантаження будь-яких обсягів даних з будь-якого місця в Інтернеті.

У світі Big Data S3 найчастіше використовується як базове надійне та дешеве сховище підприємства і є фундаментом для побудови Data Lake. Дані звідти прямо читаються інструментами на зразок Spark, Athena чи Redshift.

AWS Lambda — це Serverless обчислювальний сервіс, який дозволяє запускати код (функції) без виділення серверів і управління ними (все робиться автоматично). Ви платите лише за мілісекунди, коли код фактично виконується.

Різниця:

• EC2 (Elastic Compute Cloud): Це віртуальний сервер. Ви обираєте операційну систему, розмір пам'яті, встановлюєте бібліотеки. Ви платите за час, поки сервер увімкнений (навіть якщо він нічого не робить).
• Lambda: Ідеальна для легких мікросервісів, тригерів та Data pipelines (наприклад: щойно файл впав у S3, Lambda запускає скрипт, який фільтрує цей файл і складає у базу).

Data Lake (Озеро даних) — це централізоване сховище, що дозволяє зберігати всі структуровані, напівструктуровані та неструктуровані дані у їхньому первозданному (сирому) вигляді при будь-якому масштабі.

Для чого використовується:

• Зберігання величезних масивів сирих даних з різних джерел без необхідності їх попереднього структурування (Schema-on-read).
• Машинне навчання, предиктивна аналітика та Data Science.
• Створення єдиного джерела істини для всієї компанії (потім дані зазвичай перетворюються та відправляються у Data Warehouse).

DAG (Спрямований ациклічний граф) — це набір задач (tasks) та залежностей між ними, де кожна задача виконується у строго визначеному порядку. "Ациклічний" означає, що потік виконання ніколи не повертається назад і не створює циклів.

У таких системах, як Airflow, DAG репрезентує весь Data Pipeline в цілому.

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

Чому це важливо: Якщо ваш Batch Job впаде посередині через помилку мережі, і ви його перезапустите (зробите retry), він не повинен задублювати дані, які встиг записати під час першої (невдалої) спроби.

PEP 8 — це офіційний "Style Guide" (звід правил щодо стилю) для написання коду на Python.

Він визначає базові правила форматування: відступи (4 пробіли), максимальну довжину рядка (79 символів), правила іменування змінних (snake_case) та класів (CamelCase), кількість порожніх рядків між функціями тощо. Це робить код читабельним для всіх розробників.

• Числові: int (цілі), float (дробові), complex (комплексні).
• Текстові: str (рядок).
• Логічні (Булеві): bool (True/False).
• Послідовності: list (список), tuple (кортеж), range.
• Словники: dict (пари ключ-значення, хешмова).
• Множини: set (унікальні елементи), frozenset.

Магічні методи (Dunder methods) — це вбудовані методи класу, назви яких починаються і закінчуються подвійним підкресленням (наприклад, __init__, __str__, __len__, __add__).

Вони дозволяють налаштувати базову поведінку об'єктів вашого класу. Наприклад, щоб об'єкт можна було роздрукувати через print() (викличеться __str__) або порахувати його довжину через len() (викличеться __len__).

Comprehensions — це короткий, "елегантний" і швидкий спосіб генерації нових списків, словників чи множин на основі існуючих ітерованих об'єктів в один рядок.

• List comprehension (список): [x**2 for x in range(5) if x % 2 == 0] -> [0, 4, 16]
• Dict comprehension (словник): {x: x**2 for x in range(3)} -> {0: 0, 1: 1, 2: 4}

Екосистема Spark включає 5 основних модулів:

• Spark Core: Базовий рушій для In-Memory обчислень, планування завдань та роботи з RDD.
• Spark SQL: Модуль для обробки структурованих даних за допомогою SQL-запитів та DataFrame/Dataset API.
• Spark Streaming (Structured Streaming): Модуль для мікро-пакетної (micro-batch) обробки потокових даних у реальному часі.
• MLlib: Бібліотека для розподіленого Машинного Навчання (кластеризація, регресія, класифікація).
• GraphX: API для обробки та аналізу графів.

Це ієрархія виконання вашого коду на кластері:

• Job (Завдання): Створюється щоразу, коли ви викликаєте Action (наприклад, collect() або write()). Це найвищий рівень.
• Stage (Етап): Job розбивається на Stage'і в місцях, де відбувається "Wide Dependency" (перемішування даних між воркерами, shuffle). Наприклад, операції groupBy або join створюють новий Stage.
• Task (Задача): Найменша одиниця роботи, призначена одному ядру (CPU) на Воркері для обробки однієї партиції даних. Скільки партицій — стільки й Task'ів у Stage.

Партиція — це логічний "шматок" (фрагмент) великого набору даних (RDD/DataFrame), який обробляється окремо на одному вузлі кластера.

Важливість: Вони дозволяють обробляти гігантські файли паралельно. Якщо у вас файл на 100 ГБ і ви розбили його на 100 партицій, то 100 процесорів зможуть читати його водночас. Проте якщо партицій занадто мало — кластер буде простоювати, а якщо забагато — з'явиться overhead (перевитрата ресурсів) на управління задачами.

CI/CD — це практика DevOps для автоматизації процесів поставки коду:

• Continuous Integration (CI): Безперервна інтеграція. Кожного разу, коли розробник пушить код у Git(Hub), автоматично запускаються юніт-тести, лінтери (перевірка PEP8) та валідація збірки. Це гарантує, що новий код нічого не зламав.
• Continuous Delivery / Deployment (CD): Безперервна доставка. Якщо CI пройдено успішно, код автоматично упаковується (напр. в Docker) та деплоїться (розгортається) на сервери (Staging чи Production) без втручання людини.

Kubernetes (K8s) — це потужна open-source система для оркестрації (управління) контейнеризованими додатками.

Замість того, щоб вручну запускати 50 Docker контейнерів, ви віддаєте їх Kubernetes. Він автоматично розгортає їх на доступних серверах, масштабує вгору при зростанні трафіку, перезапускає в разі падіння (Self-healing), та забезпечує балансування навантаження між ними.

Docker — це платформа для створення та запуску додатків у контейнерах.

Контейнер — це ізольований, легкий пакет коду, який містить абсолютно все необхідне для запуску вашого Pipeline (код, Python, бібліотеки, системні утиліти, файли конфігурації). Завдяки Docker вирішується класична проблема: "У мене на ноутбуці працювало, а на сервері чомусь зламалося!". Контейнер буде працювати абсолютно однаково на будь-якій машині.

JSON (JavaScript Object Notation): Це формат передачі даних у вигляді "ключ-значення". Він напівструктурований, може містити вкладені масиви та інші об'єкти. Переважно використовується в REST API.

CSV (Comma-Separated Values): Текстовий формат, де дані розділені комами (або іншим символом, наприклад ; чи |). Він лінійний і плоский (кожен рядок - новий запис). Легко читається в Excel. Не підтримує складні типи даних та вкладеності.

REST API — це архітектурний стиль взаємодії компонентів через HTTP-запити. Зазвичай повертає дані у форматі JSON.

Data Engineers використовують API для інтеграції (Data Extraction) — написання скриптів на Python (через бібліотеку requests), які "викачують" дані з зовнішніх сервісів (Facebook Ads, Salesforce, Jira) та складають їх у Data Lake.

• List []: Впорядкована колекція елементів, яку можна змінювати (mutable). Підтримує дублікати.
• Tuple (): Впорядкована колекція, але незмінна (immutable). Працює швидше за список, часто використовується для повернення декількох значень з функції.
• Set {}: Невпорядкована колекція унікальних елементів. Ідеальна для видалення дублікатів (set(my_list)).
• Dict {"key": "value"}: Зберігає пари ключ-значення. Ключем може бути лише незмінний тип.

• DELETE: Видаляє окремі рядки за умовою WHERE. Кожне видалення записується в лог транзакцій. Це DML операція (її можна відкотити за допомогою ROLLBACK).
• TRUNCATE: Миттєво видаляє ВІДРАЗУ ВСІ рядки з таблиці. Швидкий, бо не пише кожен рядок у лог. Структура таблиці залишається. DDL операція (в більшості СУБД відкотити неможливо).
• DROP: Повністю знищує таблицю з бази даних, включаючи її структуру, дані та індекси.

Обидва оператори використовуються для фільтрації даних, але на різних етапах запиту:

• WHERE: Фільтрує "сирі" дані до їх групування (GROUP BY). Він не може використовувати агрегатні функції. Наприклад: WHERE age > 18.
• HAVING: Фільтрує вже згруповані результати. Може використовувати агрегатні функції. Наприклад: HAVING COUNT(orders) > 5.

Virtual Environment (venv) — це ізольоване середовище для окремого Python-проєкту.

Воно дозволяє запускати проєкти з різними версіями одних і тих же бібліотек на одній машині (наприклад, Проєкт А вимагає pandas 1.0, а Проєкт Б — pandas 2.0). Без віртуального середовища це спричинило б конфлікт залежностей.

• DDL (Data Definition Language): Мова визначення даних. Використовується для створення та зміни структури бази даних (таблиць, індексів, баз). Команди: CREATE, ALTER, DROP, TRUNCATE.
• DML (Data Manipulation Language): Мова маніпулювання даними. Змінює самі дані всередині таблиць. Команди: INSERT, UPDATE, DELETE. Запити SELECT часто виділяють в окрему групу DQL (Data Query Language).

TCL — це команди для управління транзакціями у базі даних (управління DML-запитами):

• COMMIT: Фіксує (зберігає) всі зміни, зроблені в поточній транзакції назавжди.
• ROLLBACK: Відкочує всі зміни з моменту старту транзакції, якщо сталася помилка.

Stage Zone (Staging) — це тимчасова, проміжна зона зберігання даних між джерелами даних (Data Sources) та Сховищем Даних (Data Warehouse).

Завдання: Дані зчитуються з багатьох повільних або критичних джерел (наприклад, продакшн-БД) і швидко копіюються в Staging без жодних трансформацій. Це робиться для того, щоб не навантажувати джерело важкими обчисленнями під час очищення даних. Вже на Staging серверах дані безпечно об'єднуються та очищуються перед завантаженням у Сховище.

HDFS (Hadoop Distributed File System) — це розподілена файлова система ядра Hadoop.

Вона розбиває величезні файли на блоки (зазвичай по 128 МБ) і розподіляє їх між сотнями фізичних серверів (DataNodes) у кластері. Для забезпечення надійності кожен блок реплікується (дублюється) 3 рази на різних серверах. Якщо один сервер згорає — дані не втрачаються і система продовжує працювати (Fault Tolerance).

NoSQL (Not Only SQL) — це нереляційні БД, які не використовують стандартні таблиці з рядками та стовпцями.

Вони ідеальні для Big Data завдяки горизонтальному масштабуванню (легко додати нові сервери у кластер). Особливості:

• Не мають жорсткої схеми даних (Schema-less), можна зберігати JSON/документи.
• Жертвують жорсткими ACID-гарантіями заради феноменальної швидкості та доступності (CAP-теорема: вибирають AP або CP).

Лямбда-функція — це маленька анонімна (без імені) функція, яка визначається одним рядком за допомогою ключового слова lambda.

Приклад: multiply = lambda x, y: x * y. Їх часто використовують як швидкі одноразові функції всередині інших методів, наприклад, під час сортування (sorted(list, key=lambda x: x[1])) або як User Defined Functions (UDF) у Pandas чи Spark.

Context Manager (Менеджер контексту) — це механізм у Python для зручного управління ресурсами, який гарантує автоматичне очищення/закриття ресурсу після його використання.

Найчастіше це оператор with open('file.txt') as f:. Якщо під час читання файлу відбудеться помилка або цикл закінчиться, контекстний менеджер автоматично викличе метод f.close(), щоб звільнити системний ресурс і не допустити витоку пам'яті (Memory Leak).

• Ітератор: Будь-який об'єкт (список, кортеж, рядок), який можна обійти в циклі for. Під капотом він реалізує магічний метод __next__().
• Генератор: Це "одноразовий" лінивий ітератор, створений за допомогою функції зі словом yield замість return, або через генераторні вирази (x**2 for x in data). Перевага: Генератор не зберігає весь масив у пам'яті. Він видає по одному елементу лише тоді, коли його про це попросять. Це дозволяє Data-інженерам обробляти гігантські файли (по 100 ГБ) на ноутбуці з 8 ГБ RAM.

Lazy Evaluation означає, що Spark взагалі нічого не робить і не обчислює дані, коли ви пишете тисячі перетворень (трансформацій filter(), join()). Він просто "записує" їх у план дій — Граф (DAG).

Дані починають реально читатися і оброблятися лише тоді, коли ви викликаєте спеціальну команду Дію (Action), наприклад show(), count() або write(). Це дозволяє оптимізатору (Catalyst) заздалегідь переглянути весь план і прибрати зайві кроки.

• Трансформації (Transformations): Ліниві операції. Вони застосовуються до існуючого DataFrame і повертають новий DataFrame. Нічого не обчислюють фізично. Приклади: select(), filter(), groupBy().
• Дії (Actions): Примушують Spark виконати всі нагромаджені ліниві трансформації та повернути реальний фізичний результат (на диск або в RAM). Приклади: show(), collect(), write().

Apache Spark може читати майже будь-який формат завдяки DataFrameReader. Найпопулярніші: CSV, JSON, Parquet, Avro, ORC.

Він також підтримує прямі підключення до реляційних баз даних (через JDBC/ODBC драйвери), а також бази даних NoSQL типу Cassandra чи MongoDB.

Pod (Под) — це найменший, найбазовіший об'єкт у Kubernetes, який ви можете створити або яким можна керувати.

Под — це логічна оболонка (обгортка) навколо одного або декількох тісно пов'язаних контейнерів (наприклад, Docker-контейнерів). Ці контейнери завжди запускаються разом на одному сервері, ділять спільну IP-адресу та ресурси збереження (Volumes), що дозволяє їм легко спілкуватися один з одним через localhost.

SQL (реляційні бази даних):

• Мають фіксовану схему (schema-on-write).
• Підтримують складні транзакції (гарантії ACID).
• Масштабуються переважно вертикально.

NoSQL (нереляційні бази даних):

• Мають гнучку схему або безсхемні.
• Відмінно масштабуються горизонтально.
• Ча лають дотримуються теореми CAP і гарантій BASE (замість суворого ACID).

Теорема CAP стверджує, що розподілена система зберігання даних може забезпечити лише дві з трьох наступних властивостей одночасно:

• Consistency (Консистентність): усі вузли бачать однакові дані в один і той самий час.
• Availability (Доступність): кожен запит отримує відповідь (навіть якщо дані можуть бути не найновішими).
• Partition tolerance (Стійкість до розділення): система продовжує працювати навіть якщо зв'язок між вузлами втрачено.

Так як у розподілених системах Partition tolerance (P) є обов'язковою, вибір стоїть між:

• CP (Consistency & Partition tolerance): система стає недоступною, якщо не може гарантувати точність (наприклад, MongoDB, HBase).
• AP (Availability & Partition tolerance): система завжди відповідає, але дані можуть бути дещо застарілими (eventual consistency) (наприклад, Cassandra).

Колонкова база даних зберігає дані не по рядках (як традиційні RDBMS), а по колонках. Кожна колонка зберігається в окремому файлі або блоці на диску.

Використовується для:

• Аналітичних запитів (OLAP): де часто треба читати лише декілька колонок з таблиці, але для мільйонів рядків (наприклад, порахувати суму продажів).
• Стиснення: оскільки всі дані в колонці одного типу (наприклад, всі імена або всі дати), алгоритми стиснення працюють дуже ефективно, економлячи місце і пришвидшуючи I/O.

Приклади: ClickHouse, Amazon Redshift, Google BigQuery, Snowflake.

Індекс — це структура даних (зазвичай B-tree), яка дозволяє швидко знаходити рядки в таблиці без перебору всіх даних (Full Table Scan), що критично для великих баз даних.

• Кластерний індекс (Clustered Index): Фізично сортує дані на диску за ключем індексу. Може бути лише один на таблицю (найчастіше це Primary Key).
• Некластерний індекс (Non-clustered Index): Створює окрему структуру (як покажчик у книзі), де зберігаються ключі індексу та посилання (вказівники) на місця фізичного зберігання реальних даних. Може бути декілька на таблицю.

ACID гарантує надійність виконання транзакцій у реляційних БД:

• Atomicity (Атомарність): Транзакція виконується повністю або не виконується взагалі (без проміжних результатів).
• Consistency (Консистентність): Дані до та після транзакції мають бути коректними (не порушувати обмежень).
• Isolation (Ізоляція): Паралельні транзакції не повинні впливати одна на одну.
• Durability (Довговічність): Якщо транзакція успішна, зміни зберігаються назавжди (навіть при збої системи/електрики).

Рівні ізоляції (Read Uncommitted, Read Committed, Repeatable Read, Serializable) регулюють баланс між швидкістю та захистом від аномалій при паралельному доступі (брудні чи фантомні читання).

• CTE (Common Table Expression - оператор WITH): Варто використовувати для підвищення читабельності складних запитів. Ідеально підходить, якщо результат підзапиту потрібно використати декілька разів в одному запиті, або для написання рекурсивних запитів (де підзапити безсилі).
• Прості підзапити (Subqueries): Добре підходять для дуже коротких умов WHERE або SELECT, де немає потреби пояснювати логіку окремим блоком. Для сучасних баз даних різниця в продуктивності мінімальна.

• Data Lake (Озеро даних): Зберігає сирі, необроблені дані будь-якого формату (текст, відео, логи) у надвеликих обсягах (Schema-on-read). Використовується переважно Data Scientists і Data Engineers для масової обробки та Machine Learning. (Amazon S3, HDFS)
• Data Warehouse (Сховище даних): Зберігає очищені, структуровані, історичні дані для бізнес-звітності та аналітики (Schema-on-write). Використовується Business Analysts для створення дашбордів. (Snowflake, Redshift)

Apache Spark працює значно швидше (у 10-100 разів) за MapReduce.

Чому? MapReduce після кожного кроку обробки (Map або Reduce) обов'язково зберігає проміжні результати на жорсткий диск (HDFS) для забезпечення надійності, що спричиняє величезні затримки через I/O (читання/запис диска).

Spark натомість використовує обробку In-Memory (у RAM). Він виконує максимум перетворень у пам'яті і записує дані на диск лише тоді, коли пам'ять закінчується або коли явно викликається дія (Action).

Вони обидва використовуються для збереження обчисленого RDD/DataFrame в пам'яті, щоб не перераховувати його при наступних зверненнях.

• cache(): Це просто скорочення (обгортка). Вона завжди зберігає дані виключно з рівнем пам'яті за замовчуванням: MEMORY_AND_DISK для DataFrame та MEMORY_ONLY для RDD.
• persist(): Більш гнучкий метод. Дозволяє явно вказати рівень збереження даних (Storage Level), наприклад: MEMORY_ONLY, MEMORY_AND_DISK, DISK_ONLY або навіть додати реплікацію (MEMORY_ONLY_2).

• RDD (Resilient Distributed Dataset): Базовий низькорівневий API у Spark. Це просто розподілена колекція об'єктів. Відсутня оптимізація (Catalyst Optimizer), вимагає багато ручного коду.
• DataFrame: Це RDD з чітко заданою схемою (схоже на таблицю бази даних). Дає змогу Spark використовувати власні оптимізатори (Catalyst) для прискорення запитів. Дані типізуються слабо (помилки типів часто виявляються лише під час виконання - Runtime).
• Dataset: Це строго типізоване розширення DataFrame (строга перевірка під час компіляції). Доступне у Scala та Java. Об'єднує переваги функціонального програмування (RDD) та оптимізатора DataFrame.

DAG (Directed Acyclic Graph) — це колекція всіх задач (tasks), які ви хочете запустити, організована у вигляді графа, який відображає їхні залежності. "Ациклічний" означає, що потік не може зациклюватись (йти по колу).

Основні типи Операторів (будівельних блоків задач):

• Action Operators: Виконують реальну дію (наприклад, PythonOperator, BashOperator, EmailOperator).
• Transfer Operators: Переміщують дані між системами (наприклад, MySqlToS3Operator).
• Sensors (Сенсори): Спеціальні оператори, які чекають (сплять) на певну подію, файл на FTP або час для старту (наприклад, FileSensor).

Обидва це бінарні формати для Big Data, але призначені для різних завдань:

• Avro (Рядковий / Row-based): Оптимізований для швидкого запису та гнучкої еволюції схем. Ідеально підходить для потокового передавання даних (наприклад, у Kafka). Зчитує весь рядок відразу.
• Parquet (Колонковий / Column-based): Оптимізований для швидкого читання та аналітики (SELECT запитів). Зберігає дані у стовпцях, забезпечуючи чудове стиснення даних. Ідеально підходить для Data Lake та Spark SQL обробки.

Індекс — це спеціальна структура даних (часто B-Tree), яка дублює частину таблиці та зберігається в пам'яті у посортованому вигляді, що дозволяє БД знаходити рядки надзвичайно швидко замість сканування всієї таблиці (Full Table Scan).

Автоматичне створення: У більшості реляційних БД (наприклад, Postgres, MySQL) індекси автоматично створюються лише для стовпців з PRIMARY KEY (PK) та стовпців з обмеженням UNIQUE. Для FOREIGN KEY (FK) індекси не створюються автоматично — їх потрібно додавати вручну.

UPSERT (Update or Insert) — це логічна операція: "якщо запис з таким ключем вже існує — онови його. Якщо його ще немає — встав (створи) новий". Це ключовий механізм для створення ідемпотентних пайплайнів.

Реалізація у Postgres: Використовується оператор ON CONFLICT.

INSERT INTO users (id, name) VALUES (1, 'Ivan') ... ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.name;

MERGE — це більш потужна і стандартизована версія UPSERT (також називається SCD - Slowly Changing Dimensions merging). Він дозволяє злити (merge) дані з "Source" таблиці до "Target" таблиці.

Окрім UPDATE і INSERT, MERGE підтримує операцію DELETE, і дозволяє встановлювати складні умови мeтчу (наприклад: WHEN MATCHED AND source.status = 'deleted' THEN DELETE). MERGE активно використовується у Сховищах Даних та Delta Lake системах.

Декоратор — це функція-обгортка, яка приймає іншу функцію (або метод) як аргумент і дозволяє динамічно додати до неї нову логіку до чи після виконання, не змінюючи вихідний код цієї функції.

Використовується із символом @ (наприклад, @property, @staticmethod або власні декоратори для логування, таймерів виконання чи Retry-обгорток).

• Вузькі (Narrow): Кожна партиція дочірнього RDD/DataFrame залежить щонайбільше від однієї партиції батьківського RDD. Не потребують перемішування даних між вузлами кластера (Shuffle). Виконуються надзвичайно швидко. Приклади: map(), filter(), union().
• Широкі (Wide): Дані з однієї батьківської партиції повинні бути розподілені до багатьох (або всіх) дочірніх партицій. Вимагають мережевого перемішування даних (Shuffle), що потребує багато CPU, RAM та дискового I/O, створюючи нові Stage. Приклади: groupBy(), join(), orderBy().

За замовчуванням кожна задача (Task) в Airflow ізольована. Для передачі стану або невеликих даних використовується механізм XCom (Cross-Communication).

Коли Task повертає значення (або явно робить xcom_push()), воно серіалізується і зберігається в мета-базу даних Airflow (Postgres/MySQL). Наступний Task може витягнути це значення (через xcom_pull()).

Важливо: XCom призначений *лише* для метаданих (ID файлів, дати, шляхи на S3). Через нього категорично не можна(і часто неможливо через ліміт метабази) ганяти Pandas DataFrame чи великі об'єми даних.

• Variables (Змінні): Глобальні параметри у вигляді ключ-значення, що зберігаються в метабазі (наприклад, Environment='PROD', API_URL, Bucket_Name). Усувають хардкод з DAG-файлів.
• Connections (Підключення): Спеціалізоване безпечне сховище для налаштувань підключення до інших систем (DB Host, Login, Password, Ports). Паролі в Connections зберігаються у зашифрованому вигляді і не світяться в коді.

Віконні функції поділяються на 3 основні групи:

• Агрегатні віконні функції: SUM(), AVG(), MAX(), MIN() OVER (...). Агрегують дані, але залишають деталі рядків.
• Функції ранжування (Ranking):
  • ROW_NUMBER(): Дає унікальний номер (1,2,3,4) навіть якщо значення однакові.
  • RANK(): Може мати пропуски, якщо є однакові значення (1, 2, 2, 4).
  • DENSE_RANK(): Без пропусків (1, 2, 2, 3).
• Функції зсуву (Value/Analytic): LAG() (значення попереднього рядка у вікні), LEAD() (наступне значення). Використовуються для розрахунку приросту (Delta) день-до-дня (MoM, YoY).

Партиціонування — це поділ однієї величезної логічної таблиці на дрібніші фізичні шматки (партиції) на жорсткому диску за певним ключем (зазвичай за Датою — Date, Рoком, Місяцем).

Навіщо: Коли ви робите SELECT запит з умовою WHERE created_at = '2023-11-01', база даних використовує Partition Pruning (обрізку партицій). Вона відкидає всі інші місяці та роки і сканує лише один малесенький файл, пришвидшуючи запит у десятки разів порівняно з Full Scan.

Data Lineage (походження даних) — це візуалізація та зберігання інформації про життєвий цикл даних: з якого джерела вони прийшли, через які таблиці й трансформації пройшли та в яких фінальних дашбордах були використані.

Чому важлива: Якщо метрика на дашборді СЕО раптом показує від'ємний прибуток, Data Lineage дозволяє швидко "розмотати" клубок і знайти, на якому етапі (в якому скрипті) закралася помилка. Це економить години на дебагінг.

Інкрементальне завантаження (на відміну від Full Reload) обробляє лише нові або змінені дані. Основні підходи:

• Watermarking (High-water mark): Збереження останнього обробленого ID або Timestamp. Наступний запуск запитує лише дані, де updated_at > 'остання_дата'.
• Change Data Capture (CDC): Безпосереднє читання логів транзакцій самої БД (наприклад, WAL у Postgres через Debezium), що захоплює всі INSERT, UPDATE, DELETE.
• Event Tracking (Queue): Сервіс надсилає кожне оновлення як повідомлення у Kafka, а ми його забираємо звідти.

• Схема Зірка (Star Schema): Складається з великої таблиці Фактів у центрі, навколо якої розташовані ненормалізовані (або денормалізовані, плоскі) таблиці Вимірів. Її дуже легко читати та джоїнити (швидкі SELECT-запити).
• Схема Сніжинка (Snowflake Schema): Відрізняється тим, що таблиці Вимірів повністю нормалізовані (виміри розгалужуються на ще менші таблиці: напр. таблиця "Місто" зв'язується з таблицею "Країна"). Займає менше місця, але вимагає багатьох складних JOIN'ів, що уповільнює аналітику.

• Факти (Fact Tables): Це чисельні показники (метрики) бізнес-процесу (кількість, сума, ціна, знижка). Це те, що ми можемо виміряти. Наприклад: таблиця продажів. У них переважають цифри та Foreign ключі.
• Виміри (Dimension Tables): Це описові атрибути, які надають контекст фактам ("хто", "де", "коли", "що"). Наприклад: Клієнти, Продукти, Час, Магазини. Вони містять текст та ідентифікатори.

Якщо бізнес додав нові колонки або змінив тип даних, пайплайн не повинен впасти.

• Avro/Parquet: Використання властивостей цих форматів (додавання нових колонок підтримується з коробки).
• Delta Lake / Iceberg: Вмикання параметра mergeSchema = true під час запису. Якщо з'явилась нова колонка в DataFrame, рушій автоматично змінить DDL таблиці на диску.
• DLQ: Записи, які не відповідають жорсткій схемі, відкидаються в Dead Letter Queue.

Це вирішує концепція Slowly Changing Dimensions (SCD):

• SCD Type 1 (Перезапис): Старе значення просто оновлюється новим (UPDATE). Історія змін втрачається назавжди.
• SCD Type 2 (Збереження історії): Для кожної зміни створюється новий рядок (INSERT) зі статусами (наприклад, is_active = True) та маркерами часу valid_from і valid_to. Старий рядок позначається як неактивний.
• SCD Type 3 (Нова колонка): Додається спеціальна колонка (наприклад previous_city), куди переходить старе значення, а поточна колонка оновлюється.

Дата-каталог — це централізований репозиторій метаданих, що допомагає організаціям структурувати та знаходити свої дані. (Аналог "Google" для внутрішніх даних компанії).

Він автоматично сканує бази даних (Crawling), зберігає схеми таблиць, інформацію про власників таблиць (Data Stewards) та теги. Відомі приклади: Alation, Collibra, AWS Glue Data Catalog, Amundsen.

Це формати відкритих таблиць (Open Table Formats), побудовані поверх Parquet, які приносять властивості ACID баз даних у Data Lake:

• Delta Lake: Розроблений Databricks. Чудово інтегрований у Spark, підтримує MERGE, Time Travel, Schema Evolution.
• Apache Iceberg: Розроблений Netflix. Відрізняється тим, що відстежує зміни на рівні окремих файлів (File-level metadata), завдяки чому гігантські таблиці скануються миттєво.
• Apache Hudi: Фокусується на швидкому Incremental Processing, має спеціальні оптимізації для частих UPSERT-операцій.

Колонкова БД (OLAP) записує дані на диск не рядками (послідовно кожен запис), а по-колонково. (Всі значення колонки Date лежать підряд на диску, далі йдуть всі значення колонки Price).

Випадки використання: Ідеальні для аналітики, бо при запиті SUM(Price) СУБД читає лише одну конкретну колонку. Рядкові ж БД (Postgres, MySQL) довелося б завантажувати в пам'ять усі стовпчики (Full Scan). Приклади колонкових БД: ClickHouse, Amazon Redshift, Snowflake.

• Schema-on-Write: (Властиво Data Warehouse) Перед записом ви маєте створити жорстку таблицю (DDL) і визначити типи даних. Під час INSERT БД перевіряє дані, і якщо вони не збігаються (рядок у колонці INT) – запит падає. Дані безпечні, але запис марудний.
• Schema-on-Read: (Властиво Data Lake). Ви записуєте на диск будь-які "сирі" файли (JSON) без перевірки. А сама "Схема" накладається зверху в момент зчитування (наприклад, через Amazon Athena чи Spark), коли ми задаємо типи 'на льоту'.

Це два популярних колонкових (Columnar) бінарних формати для зберігання Big Data. На відміну від CSV, вони мають власну схему всередині файлу.

• Apache Parquet: Оптимізований для екосистеми Spark/Impala, чудово стискається (проти CSV в 5-10 разів краще) завдяки компресії (Snappy, GZIP). Ідеальний для аналітичних агрегацій та глибоких вкладених структур даних (Lists/Maps).
• Apache ORC: Створювався для екосистеми Hive. Має спеціальний Light-weight індекс всередині файлів (Predicate Pushdown), завдяки чому пропускає читання цілих блоків даних, якщо вони не задовільняють умові.

Оскільки зберігати гігабайти "старих" даних щороку стає дуже дорого, дата-інженери використовують Storage Tiers (класи зберігання) у хмарі (наприклад AWS S3):

• Hot (Standard): Дані за останні 3 місяці (місяць). Найшвидший доступ, але найдорожче зберігання. Для щоденних аналітичних дашбордів.
• Warm (Infrequent Access): Дані від 3 місяців до 1 року. Зберігання дешевше, проте стягується плата за кожне вилучення (читання).
• Cold (Glacier): Дані, старіші як 1 рік. Вартість зберігання копійчана, але для їх зчитування доведеться чекати від кількох хвилин до кількох годин (асинхронне відновлення для аудиту).

AWS Glue — це Serverless платформа для інтеграції, обробки (ETL) та каталогізації даних в AWS.

• Glue Jobs: Дозволяють запускати Spark-скрипти (в основному на Python) в ефемерному (тимчасовому) кластері без його налаштування вами. Сервіс берегроші тільки за секунди роботи пайплайну.
• Glue Crawlers: Кроулери періодично сканують нові файли у S3-бакетах (JSON/Parquet), вгадують їхню схему і зберігають її у єдиний реєстр.
• Glue Data Catalog: Єдиний мета-реєстр таблиць (Hive Metastore) поверх S3. Саме звідси ці таблиці бачить Amazon Athena, щоб можна було робити SQL запити до сирих файлів.

Job Bookmarks (закладки) — це вбудований механізм відстеження стану, який дозволяє інкрементальне завантаження (Incremental ETL).

Після кожного запуску Glue Job зберігає внутрішню позначку "я закінчив роботу ось на цьому файлі" або "ось такий останній timestamp". При наступному запуску Job буде зчитувати тільки нові файли, згенеровані після завершення минулого запуску, ігноруючи старі. Це запобігає дублюванню та економить час/гроші.

Amazon Athena — це Serverless SQL-сервіс для миттєвої аналітики сирих даних прямісінько з об'єктного сховища Amazon S3.

Вона базується на Presto. Не потрібно крутити власні сервери і вантажити дані в базу — ви просто вказуєте SQL-запит до файлу в S3, і він миттєво виконується. Плата знімається лише за 1 Терабайт просканованих даних (близько $5).

AWS Lambda — це FaaS (функції як сервіс). Ви пишете короткий код (Python, Node.js), а AWS запускає його в ізольованому мікро-контейнері ТІЛЬКИ у відповідь на подію (запит до API, поява файлу в S3, тригер CloudWatch).

Обмеження:

• Максимальна тривалість виконання: 15 хвилин. (Тому Lambda не підходить для масивних годинних ETL-джобок).
• Ліміт пам'яті (RAM) та зберігання (/tmp директорія) обмежені кількома ГБ.
• Layers: Механізм зовнішнього підключення "важких" бібліотек (Pandas, Numpy) кільком Лямбдам одночасно, щоб не перевищувати ліміт розміру коду в 250MB.

Amazon RDS (Relational Database Service) — це керований хмарний сервіс реляційних баз даних (PostgreSQL, MySQL, Oracle).

Вам не потрібно власноруч встановлювати ядро БД на сервери. RDS автоматично бере на себе резервне копіювання (Backups), патчі безпеки ОС, мінорині оновлення рушія та надає легку настройку Multi-AZ (гаряча репліка в іншій зоні доступності для миттєвого підняття у разі падіння основної станції).

• Amazon EMR (Elastic MapReduce) — повноцінний, керований вами інфраструктурний кластер (Hadoop/Spark). Дає максимальний контроль. Ви можете встановлювати кастомні бібліотеки рівня ОС і налаштовувати майстер/воркер ноди, вибирати залізо (Spot EC2 інстанси для здешевлення). Оплачується по годинах оренди серверів.
• AWS Glue — 100% Serverless. Ви просто даєте Spark-код і чекаєте результату. Ніяких серверів, ідеально для простоти та епізодичних завдань. Але це виходить значно дорожче за годину роботи, ніж EMR, і немає можливості тонкого "тюнінгу" інфраструктури.

Маскування даних — це метод приховування чутливої інформації (Personal Identifiable Information – PII, як-от кредитні картки, адреси, номери телефонів).

• Статичне (Static): Фізична підміна чутливих колонок на фейкові ще на етапі копіювання БД (наприклад з Production в Test середовище), щоб розробники ніколи не бачили реальних даних.
• Динамічне (Dynamic): Дані на диску лежать реальні, але під час SELECT-запиту база "на льоту" приховує їх (повертає ***-**-2342), залежно від ролі (рівня доступу) юзера, що зробив запит.

• ETL (Extract, Transform, Load): Спочатку дістаємо дані, трансформуємо (очищуємо) їх на нашому сервері (наприклад, за допомогою Spark), і тільки потім кладемо у Сховище. Використовується, коли дані надто брудні, або коли Сховище дороге (не хочемо платити за обчислення в ньому).
• ELT (Extract, Load, Transform): Спочатку сирі дані вантажаться у Сховище, а потім трансформуються потужностями самого Сховища (через dbt / SQL-запити). Це сучасний стандарт для хмарних MPP (Snowflake, BigQuery), які миттєво обробляють гігабайти всередині себе.

• Кластерний індекс: Визначає фізичний порядок рядків у таблиці. Саме тому він буває тільки один (зазвичай це Primary Key). Структурований як дерево пошуку (B-Tree). Дані зберігаються в самих листках дерева.
• Некластерний індекс: Дані не сортуються фізично. Індекс — це окрема структура (довідник у кінці книжки), де лежить копія колонки та вказівник (pointer) на її фізичне місце на диску. Їх може бути багато в одній таблиці. Пошук триває трохи довше.

MPP — це бази даних, що складаються з десятків обчислювальних серверів, які обробляють запити паралельно (напр., Redshift, Teradata).

Завантаження: Ніколи не використовуйте стандартні INSERT INTO для мільйонів рядків, бо воно піде через один вузол-лідер. Завжди використовуйте масові утиліти (наприклад, команду COPY в Redshift для завантаження багатьох файлів із S3 відразу всіма воркерами паралельно).

У класичному розумінні B-Tree індексів (як у Postgres) — рідко, адже вони займають занадто багато місця для Терабайтів і гальмують масовий запис. Натомість використовують:

• Partitioning: Сканується лише потрібна директорія.
• Zone Maps (Min-Max Index): у форматах Parquet / ORC кожен блок описує своє найменше і найбільше значення. Рушій "перестрибує" цілі файли, якщо значення WHERE x = 5 лежить поза блоком `[10...50]`.

Контроль якості (QA) є критичним, щоб BI звіти не обманювали бізнес. Найпопулярніший фреймворк: Great Expectations.

Цей інструмент дозволяє задати "очікування" у вигляді простого тексту або JSON (напр. "значення price має бути більше 0", "колонка email не має бути пустою"). Пайплайн запускає цей тест на свіжому DataFrame; якщо відсоток помилок критичний — завантаження зупиняється намертво (аудит), а дев-команді надсилається алерт.

Черга "мертвих" повідомлень — це патерн архітектури обробки повідомлень.

Якщо ваш Spark Streaming/Kafka пайплайн отримує пошкоджений або некоректний JSON-об'єкт, який не може бути розпарсеним чи обробленим, щоб не "падати" і не зупиняти обробку всього потоку, він "відловлює" цей об'єкт (Exception) і записує його у спеціальну резервну чергу або S3-бакет — DLQ. Там інженери пізніше зможуть проаналізувати поламане повідомлення та повторно завантажити його.

ASG — це можливість хмари автоматично підіймати або видаляти віртуальні сервери (інстанси) залежно від навантаження.

Наприклад, якщо завантаженість процесорів поточних серверів перевищує 80%, ASG автоматично купує і запускає ще два сервери та підключає їх до Load Balancer. Якщо навантаження падає до 20% вночі, ASG "вбиває" зайві сервери, щоб компанія не переплачувала.

• Уникання `SELECT *`. Зчитуйте лише необхідні колонки.
• Фільтрація (`WHERE`) та Партиціювання до застосування важких `JOIN`. (Filter early).
• Уникання `DISTINCT`, якщо можливо використовувати `GROUP BY`, і уникання підзапитів у секції `WHERE` (краще переписати через `LEFT JOIN`).
• Уникання функцій на індексованих стовпцях з лівого боку (наприклад WHERE YEAR(date) = 2023 — це погано, ігнорує індекс. Правильно: WHERE date >= '2023-01-01').

Ідемпотентність — це властивість процесу (pipeline), коли багаторазовий його запуск з тими ж вхідними параметрами дає один і той же фінальний результат у БД (без дублювання даних).

Вона досягається, наприклад, тим, що на початку скрипта ми виконуємо DELETE FROM tgt WHERE date = 'поточна', а потім INSERT, замість просто виконання "сліпого" інсерту. Або за рахунок UPSERT/MERGE (за первинним ключем), яка при повторному запуску тільки оновлює ті самі рядки значеннями, нічого не ламаючи.

Статичне маскування: Фізичний процес заміни конфіденційних даних у базі даних (наприклад, перед створенням копії для розробників/тестувальників). Оригінальні дані втрачаються назавжди в цій копії.

Динамічне маскування: Справжні дані залишаються в безпеці на диску, але "маскуються" (у вигляді ***-**-253) на льоту під час зчитування інформації базою даних, зважаючи на привілеї чи роль користувача, що робить цей запит (наприклад, касир бачить лише останні 4 цифри картки).

MPP (Massively Parallel Processing) — це архітектура масово-паралельної обробки, де дані та запити розподіляються між кількома незалежними вузлами (нодами).

Головні відмінності:

• Shared-Nothing архітектура: кожен вузол має власні оперативну пам'ять (RAM), диск і CPU. Вони не ділять ресурси, що усуває вузькі місця.
• Паралельне виконання: коли надходить важкий аналітичний запит, головний вузол розбиває його на частини та відправляє робочим вузлам для паралельного виконання.

Лямбда-архітектура — це підхід до обробки даних, розроблений для того, щоб одночасно справлятися як з масовими батч-завантаженнями (batch processing), так і з обробкою потоків у реальному часі (stream processing).

Складається з трьох шарів (компонентів):

• Batch Layer (Пакетний шар): зберігає всі незмінні (immutable) сирі дані та повільно перераховує об'ємні агрегації (наприклад, за допомогою Hadoop або Spark). Відрізняється високою точністю.
• Speed Layer (Швидкісний шар): обробляє тільки свіжі дані в реальному часі (через Kafka, Spark Streaming, Flink), щоб компенсувати затримку Batch Layer. Може мати дещо нижчу точність (апроксимація).
• Serving Layer (Шар обслуговування): об'єднує результати Batch Layer та Speed Layer, надаючи кінцевому користувачеві або дашборду повну та актуальну картину (наприклад, через Cassandra або HBase).

Медальна архітектура — це патерн проєктування даних, який використовується для логічної організації даних у Lakehouse (наприклад, в Databricks) для поступового покращення якості даних у міру їх проходження етапами.

• Bronze (Сирий рівень): Дані завантажуються з джерел «як є» (raw data). Без змін схем чи очистки. Зберігається вся історія.
• Silver (Очищений рівень): Дані фільтруються, очищуються (дедуплікація, перевірка схем, стандартизація). Цей шар забезпечує консолідоване уявлення бізнес-об'єктів (наприклад, єдина таблиця "Користувачі").
• Gold (Бізнес-рівень): Високоструктуровані та агреговані дані, готові до використання аналітиками, в BI дашбордах та алгоритмах ML. Орієнтовані на бізнес-метрики (наприклад, "Щоденні продажі за регіонами").

Нормалізація — це процес організації структури БД для мінімізації надмірності даних та запобігання аномаліям оновлення/видалення.

• 1NF (Перша нормальна форма): Кожна комірка має лише одне значення (атомарність). Рядки унікальні.
• 2NF: Таблиця знаходиться в 1NF, і всі неключові атрибути повністю залежать від усього первинного ключа (ліквідація часткової залежності).
• 3NF: Таблиця знаходиться в 2NF, і немає транзитивних залежностей (неключові атрибути не залежать один від одного). (Це стандарт для більшості OLTP).

Incremental data load (Інкрементальне завантаження) — це процес завантаження в Data Warehouse/Lakehouse лише нових або змінених даних з певного моменту часу, замість повного щоденного перезавантаження (Full Load).

Основні методи:

• Watermark (High-Water Mark): Відстеження максимальної дати оновлення (наприклад, WHERE updated_at > 'остання_сесія').
• CDC (Change Data Capture): Читання безпосередньо transaction logs з БД-джерела (Binlog у MySQL, WAL у Postgres) через інструменти типу Debezium. Не створює навантаження на джерело і працює в реальному часі.
• Append-only (Для логів): Просто додавання нових файлів або партицій (дуже ефективно для незмінних даних, таких як події чи логи інтернет-магазину).

Для забезпечення безперебійної потокової передачі та Fault Tolerance:

• Apache Kafka: Гарантує збереження даних через реплікацію партицій (Replication Factor). Навіть якщо брокер впаде, дані читаються з репліки.
• Apache Flink / Spark Streaming: Використовують механізм Checkpointing. Стан застосунку періодично зберігається в надійному сховищі (наприклад, HDFS/S3). При збої обробка перезапускається з останнього чекпоінту (це гарантує Exactly-Once обробку).
• Dead Letter Queue (DLQ): Відхилені або пошкоджені повідомлення (corrupted records), які не вдається обробити, відправляються в окрему чергу для ручного розбору та запобігання блокуванню всього пайплайну.

Data Governance (Управління даними) — це набір внутрішніх правил, політик та процедур компанії, що регулює: якість, доступність, безпеку та використання даних.

Ефективні практики реалізації:

• Data Catalogs: Використання каталогів (Alation, Azure Purview, AWS Glue Catalog) для пошуку даних, метаданих (Data Dictionary) і відстеження їх походження (Data Lineage).
• Access Control (RBAC): Управління доступом до даних на рівні рядків aбо стовпців. Систематичний аудит і контроль конфіденційної інформації (PII, фінанси).
• Data Quality (DQ): Автоматизоване тестування даних (через Great Expectations чи dbt tests).

• Data Skew (Перекіс даних): Ситуація, коли дані розподілені між розділами (партиціями) нерівномірно. Один воркер обробляє 10 ГБ даних, тоді як інші 100 воркерів — по 1 МБ. Це призводить до того, що вся job'а чекає на одного "повільного" воркера. (Вирішується через salting або broadcast join).
• Data Spill: Коли об'єм даних в одній партиції перевищує доступну пам'ять (RAM) виконавця під час агрегацій (groupBy, join, sort), Spark змушений скидати (spill) частину даних на диск. Це надзвичайно сповільнює обробку (затримки дискового I/O). Зазвичай є прямим наслідком невирішеного Data Skew.

Dataset API у Spark побудований на глибокій (compile-time) перевірці типів, яка можлива завдяки строго типізованим мовам (Scala або Java).

Оскільки Python є мовою з динамічною типізацією, він фізично не підтримує жорстку компіляційну перевірку типів. Тому в PySpark всі дані обробляються через DataFrame API (де схема перевіряється в runtime). Імітувати Dataset у Python немає сенсу — він би втратив свою головну перевагу (compile-time type safety) і перетворився б на звичайний DataFrame.

• B-Tree (за замовчуванням): Ідеальний для запитів з рівністю та діапазонами (=, <, >, BETWEEN, IN).
• Hash: Тільки для equality (=). Дуже швидкий, але зараз використовується рідше через оптимізації B-Tree.
• GIN (Generalized Inverted Index): Використовується для індексації масивів та складних типів даних (JSONB, повнотекстовий пошук - tsvector).
• GiST (Generalized Search Tree): Використовується для геометричних і просторових даних (PostGIS) та перекриттів (ranges).
• BRIN (Block Range Index): Ідеальний для дуже великих "лінійних" (часових) таблиць, що постійно доповнюються. Займає мало місця (зберігає лише мін/макс значення для блоків).

Це гарантії доставки повідомлень у розподілених системах (Kafka, RabbitMQ, SQS):

• At-most-once (Щонайбільше раз): Повідомлення відправляється/читається один раз, і система не чекає на підтвердження успіху. Повідомлення ніколи не дублюватиметься, але воно може загубитись. (Low latency, низька надійність).
• At-least-once (Щонайменше раз): Консюмер підтверджує (ack) обробку повідомлення. Якщо брокер не отримує ack, він надсилає його знову. Повідомлення ніколи не губиться, але можуть виникнути дублікати. (Найпопулярніший варіант).
• Exactly-once (Рівно один раз): Ідеальний стан. Забезпечується через транзакційні комміти (як у Kafka Transactions) та використання ідемпотентних консюмерів (які можуть отримувати дублікати, але обробляти/зберігати їх результати лише раз).

Звичайний tuple підтримує лише доступ за індексом (напр. t[0]), що погано читається у складних пайплайнах. Для OОП-стилю (доступ як t.name) існують три основні підходи в Python:

• collections.namedtuple: Створює класичний незмінний кортеж, але додає до нього імена полів. Займає дуже мало пам'яті.
• @dataclass (з Python 3.7): Повноцінний клас, який автоматично генерує магічні методи (__init__, __repr__). За замовчуванням об'єкт можна змінювати (mutable), підтримує Type Hints.
• Pydantic BaseModel: Схожий на Dataclass, але на додачу має вбудовану сувору валідацію типів під час ініціалізації. Ідеальний для валідації JSON JSON у пайплайнах та API.

Це породжувальні патерни проєктування:

• Фабричний метод: Замість прямого створення об'єктів через конструктор, ви створюєте централізований метод (або функцію), який отримує параметр (наприклад, "mysql" або "postgres") і повертає готовий об'єкт підключення відповідного класу.
• Абстрактна фабрика: Піднімає цю логіку на рівень вище. Замість створення одного продукту (об'єкта), вона створює пов’язане сімейство об'єктів (наприклад, фабрика для AWS може повертати AWSLogger та AWSStorage, тоді як GCP фабрика поверне відповідні версії для Google).

• Schedule-based (За розкладом): Найпоширеніший (Airflow Cron). Пайплайн запускається о чітко заданій годині (напр. щоночі о 2:00). Мінус — затримка обробки (графік може бути порожнім, або ж навпаки вже переповненим).
• Event-driven (Подієво-орієнтовані): Тригеруються безпосередньо системною подією (Sensors, AWS EventBridge, S3 trigger). Наприклад: щойно файл успішно впав на FTP сервер, пайплайн запускається одразу. Забезпечує архітектуру реального або біля-реального часу (near real-time).

Amazon SQS FIFO гарантує отримання повідомлень "First-In-First-Out" та Exactly-Once Delivery завдяки вбудованому механізму дедуплікації.

• MessageDeduplicationId: Ви можете явно відправити унікальний ідентифікатор події (напр. ID транзакції БД). SQS запам’ятовує цей ID на 5 хвилин і мовчки ігнорує будь-які повторні повідомлення з тим самим ідентифікатором від продюсера.
• Content-Based Deduplication: Створює хеш SHA-256 з усього тіла повідомлення. Якщо тіло на 100% ідентичне попередньому повідомленню (впродовж 5 хв), SQS відхиляє його.

Брокери (як стандартний SQS) працюють за принципом At-least-once delivery. Дублікати виникають через проблему "Мережевого розриву" (Network Partition або Timeout):

Якщо консюмер (Worker) прочитав повідомлення, обробив його, але відповідь-підтвердження про успішну обробку (ACK) загубилася під час відправки назад брокеру через збій у мережі, брокер подумає, що Worker вмер (Visibility Timeout expired). Брокер поверне це старе повідомлення назад у чергу, після чого його знову прочитає інший Worker. Саме тому кожен етап вашого пайплайну в Data Engineering має бути ідемпотентним!

Найкраща практика (Best Practice) при переведенні SQL у Spark або Pandas:

• Фільтруй до об'єднання (Filter Early): Виконуйте .filter() або .where() ще до .join(). Не робіть join гігантських таблиць, якщо вам цікавий лише 1 регіон.
• Вибирай потрібні стовпці: Завжди робіть .select() лише тих колонок, які потрібні для фінального групування, щоб зменшити об'єм пам'яті (RAM), необхідної для Shuffle під час Join.
• Join оптимізації у Spark: Якщо одна таблиця маленька (< 10 MB), примусово використовуйте broadcast() хінт у DataFrame API, що повністю усуне повільний Shuffle, оскільки маленька таблиця буде розіслана в RAM кожного воркера.

Це вирішується механізмом Consumer Groups (Групи споживачів).

У Apache Kafka, якщо всі ваші мікросервіси/воркери об'єднані однією групою (мають однаковий параметр group.id), Kafka гарантує, що повідомлення з однієї партиції отримає лише один конкретний Consumer з цієї групи.

Якщо ви хочете, щоб це ж повідомлення паралельно обробив зовсім інший застосунок (наприклад, один консюмер пише в БД, а інший шле email), ви повинні дати їм різні імена Consumer Groups.

Data Retention (політика збереження) / TTL (Time To Live) — це правила, що визначають, як довго система повинна фізично зберігати дані, перш ніж вони будуть автоматично і безповоротно видалені, щоб звільнити місце на диску і виконати правила GDPR.

• Kafka: Замовчуванням retention становить 7 днів (параметр log.retention.hours). Після цього брокер видаляє старі партиції (сегменти), навіть якщо консюмери не встигли їх прочитати.
• Amazon S3: Використовуються Lifecycle Policies, де налаштовується: після 30 днів перемістити файли в Glacier (холодне дешеве сховище), а після 365 днів — повне видалення (Delete expire object).

На рівні інженерії даних неякісні дані не повинні блокувати роботу, але й не можуть безконтрольно потрапити в Data Warehouse. Підходи:

• Dead Letter Queue (DLQ): Якщо валідні дані не проходять парсинг (зламаний JSON/формат дат), вони не ламають pipeline, а скидаються в окрему таблицю помилок (DLQ) для ручного розбору.
• Automatic Testing: Інтеграція Data Quality Frameworks типу Великі Очікування (Great Expectations) чи dbt tests. У них прописуються контракти: напр. expect_column_values_to_not_be_null('user_id').
• Imputation/Default values: Заповнення пропусків статичними константами чи середніми значеннями на Bronze / Silver рівнях, щоб звітність не повертала NULL.

• EXPLAIN (ANALYZE): Головний крок — подивитися на План виконання запиту (Execution Plan), щоб побачити, де база робить Full Table Scan або складний Nested Loop Join.
• Індексування: Перевірити наявність індексів на колонках з блоку WHERE або JOIN ... ON. Додати складені індекси.
• Уникати "SELECT *": Читання лише потрібних стовпців сильно зменшує навантаження на диск (I/O) і RAM.
• Partition Pruning: Додавати в WHERE колонку партиції (зазвичай Date-колонку), щоб СУБД сканувала лише 1% даних.
• Спрощення: Виносити складну логіку у матеріалізовані представлення (Materialized Views) або обчислювати заздалегідь через CTE (лише якщо система кешує CTE). Переписати підзапити через LEFT JOIN, де це можливо.

Так, може. Існують розподілені NewSQL бази даних (наприклад, Spanner, CockroachDB), які гарантують ACID транзакції і пристроєні для роботи з безліччю вузлів.

Також зараз популярні формати відкритих таблиць над Data Lake — Apache Iceberg, Delta Lake та Hudi. Вони забезпечують ACID транзакції над звичайними Parquet файлами, використовуючи журналювання транзакцій (Transaction Log). Вони дозволяють декільком процесам Spark одночасно записувати і читати файли на AWS S3, уникаючи ситуацій з частковим записом або пошкодженням даних (dirty reads).

Це концепція логічної організації даних у Lakehouse, популяризована компанією Databricks, яка розділяє дані на 3 рівні якості:

• Bronze (Сирі дані): Дані зберігаються так, як вони прийшли з джерела. Формат може бути будь-який, навіть з дублікатами.
• Silver (Очищені дані): Дані фільтруються, уніфікуються, конвертуються у загальний формат (Parquet/Delta), дублікати видаляються, провадиться маппінг. Це єдине джерело "правди" по сутностях.
• Gold (Бізнес-рівень): Дані сильно агрегуються, обчислюються бізнес-метрики (зіркова схема) для передачі BI-інструментам (Tableau, PowerBI).

Спекулятивне виконання — це конфігурація (spark.speculation=true), спрямована на боротьбу з повільними вузлами (stragglers).

Якщо один чи два Task'и виконуються аномально повільніше від усіх інших (наприклад, через зношений жорсткий диск чи перевантажений процесор на одному з воркерів), Spark "спекулятивно" запускає точнісінько такий самий Task паралельно на іншому, простійному вузлі. Той, хто виконає завдання першим, його результат буде враховано, а повільного "лузера" (straggler) Spark безжально вб'є (kill task).

Масштабування Streaming системи має кілька рівнів:

• Брокер повідомлень (Kafka): Масштабування відбувається шляхом збільшення кількості Партицій в топіку. (Одна партиція = один потік даних).
• Обчислення (Flink/Spark Streaming): Ми збільшуємо кількість Consumer-ів (Executor-ів) рівно до кількості Партицій у брокері, щоб кожен консюмер читав свою порцію (one-to-one mapping).
• База даних (Sink): Вибір БД, здатних до високошвидкісного запису (Cassandra, Clickhouse, або DynamoDB) та їх горизонтальне шардування.

Blue-Green Deployment — це стратегія випуску нових версій без жодного даунтайму (Zero Downtime).

У вас існують два абсолютно ідентичні виробничі середовища. Blue (Синє) — поточне живе середовище, туди йде весь трафік користувачів. Ви деплоїте нову версію коду в Green (Зелене) середовище, яке поки що ніхто не бачить. Після внутрішнього тестування, ви миттєво перемикаєте балансувальник навантаження (Load Balancer) з Blue на Green.

Якщо в Green виявилася критична помилка — ви так само в один клік повертаєте балансувальник назад на Blue.