Чому Сучасна Data Architecture Руйнується в Продакшні

Кожен platform lead, який зараз планує міграцію на data warehouse, lake або lakehouse, насправді приймає рішення про найм ще до того, як приймає технологічне рішення — і більшість із них поки що цього не усвідомлюють. У презентації вендора схема завжди виглядає чисто. Питання в іншому: чи здатна ваша реальна інженерна команда — не та, що описана в RFP — підтримувати цю схему в робочому стані через вісімнадцять місяців.

Саме ця незручна теза проходить червоною ниткою через нову статтю Forbes Technology Council за авторством enterprise CIO Тхая Вонга, і вона з'являється саме в той момент, коли platform-команди затверджують семи- та восьмизначні бюджети на AI-готові data-стеки. Рідко ламається сама архітектура. Ламається операційна модель навколо неї.

У чому проблема

Стандартна історія модернізації виглядає так. Platform-команда обирає патерн (warehouse, lake або lakehouse), обґрунтовує вибір платформи на steering committee і презентує reference architecture з чистими блоками для інгесту, трансформації та подачі даних. Через дванадцять-вісімнадцять місяців доставка сповільнюється, чергування перетворюється на пекло, а невелика зміна в source-системі розповсюджується по пайплайнах, яких ніхто повністю не контролює.

Як повідомляє Forbes, Вонг стверджує: найпоширеніша помилка — обирати архітектуру виходячи з того, на що вона здатна, а не з того, що організація реально може підтримувати. Ця фраза звучить як консалтинговий кліше — доки ви не прив'яжете її до бюджету. Capability — це рядок витрат, зрозумілий CFO. Operability — це розмова про штат, яку CFO відкладає.

Технічний патерн, який описує Вонг, знайомий кожному, хто успадковував п'ятирічну data-платформу. Пайплайни множаться. Трансформації дублюються між командами, які не знали про існування одна одної. Легасі-код, захардкоджена логіка та тимчасові «латки» накопичуються, компенсуючи ранні обмеження системи, і живуть значно довше, ніж мали б. Результат — технічне гальмування та те, що Вонг називає institutional knowledge risk: занадто багато розуміння зосереджено в занадто небагатьох людей.

У 2026 році змінилося навантаження. AI use cases тепер є реальною вимогою до цих платформ, а не слайдом про майбутнє. Це означає, що ті самі архітектури, які більш-менш справлялися з тижневими BI-дашбордами, тепер мають забезпечувати feature stores, retrieval-пайплайни та harness'и для оцінки моделей. Гнучкість, яку дають lakes і lakehouses — збирати й використовувати багато даних швидко, не організовуючи все ідеально заздалегідь, у формулюванні Вонга — стає операційним тягарем у той момент, коли downstream-споживачі очікують freshness SLA, що вимірюється хвилинами, а не днями.

Корисний контраст: warehouse-центричний стек вимагає витрат на узгодження наперед, lake відкладає їх. Відкладене узгодження накопичується. На третій рік команда платить відсотки.

Варіанти на столі

Якщо відкинути маркетинг, platform leads обирають між трьома патернами, кожен із яких має власний операційний профіль.

Warehouse-центричний (Snowflake, BigQuery, Redshift). Структура та консистентність — ключові переваги. Schema-дисципліна забезпечується самою платформою, а отже невелика команда analytics engineering може тримати все в порядку. Компроміс — overhead на governance при інгесті та рахунок, який масштабується з compute так, що фінансові команди вже навчилися цього боятися. Документація Snowflake детально описує патерни workload isolation, але саме isolation є причиною, через яку витрати непомітно зростають утричі.

Lake-first (object storage плюс query engines). Максимальна гнучкість, найнижча вартість зберігання та можливість спочатку зберегти дані, а потім вирішити, що з ними робити. Підводний камінь: без жорстких інженерних контролів логіка розповзається по занадто великій кількості пайплайнів, і команди вирішують одну й ту саму проблему різними способами. Слова Вонга. Дебагінг уповільнюється. Платформа технічно працює, але підтримувати її стає дедалі складніше.

Lakehouse (Databricks, відкриті табличні формати на кшталт Iceberg та Delta). Нинішня консенсусна відповідь, що балансує між гнучкістю та структурою. Databricks та екосистема відкритих табличних форматів зробили це рішення достовірним у масштабі. Але lakehouse-архітектури успадковують операційну складність обох батьків. Вам одночасно потрібна governance рівня warehouse та інженерна дисципліна рівня lake.

Фрейм прийняття рішень, який я б запропонував platform leads: кожна модель несе різний рівень складності, гнучкості та governance overhead. Більша гнучкість вимагає більшої дисципліни. Більша структура вимагає більшого узгодження наперед. Питання build-vs-buy зводиться до питання найму. Warehouse-стек може працювати з трьома analytics engineers та part-time platform engineer. Lakehouse порівнянного масштабу реалістично потребує виділеної platform-команди, data reliability-функції та transformation-фреймворку на кшталт dbt зі зрілими CI-конвенціями — і все це до того, як щось потрапляє в продакшн.

Для analytics-орієнтованих навантажень, де домінує query latency, OLAP-рушій на кшталт ClickHouse, розміщений downstream від будь-якого з патернів, дедалі частіше є правильною відповіддю — не як заміна рішення щодо платформи, а як визнання того, що один рушій не обслуговує всі навантаження однаково добре.

Проблема vendor lock-in реальна і рідко моделюється чесно. Відкриті табличні формати зменшують її. Пропрієтарні stored procedures та warehouse-специфічні SQL-розширення збільшують. Той, хто приймає це рішення, має явно зафіксувати його в architecture review, а не виявляти під час поновлення контракту.

Що data-командам варто робити насправді

Вонг виділяє чотири якості архітектур, які витримують випробування часом: observable пайплайни, повторно використовувані трансформації, контрольовані деплойменти та загальна архітектура, яка залишається зрозумілою в міру розвитку. Це не функції платформи. Це результати інженерних рішень, і саме за ними слід оцінювати будь-який вендор у поточному кварталі.

Перекладіть це в дії. Перед підписанням багаторічного контракту platform lead має конкретно відповісти на чотири питання. Як ми відстежуємо збій пайплайну наскрізно і хто отримує сповіщення? Як ми запобігаємо тому, щоб дві команди писали однакову логіку трансформації, і який review-процес це виявляє? Як виглядає деплоймент і як ми робимо rollback? Коли новий інженер приходить на дев'ятому місяці, чи може він зрозуміти систему лише з документації, чи залежить від трьох людей, які пам'ятають, чому існує певний SQL view?

Якщо відповідей немає до закупівлі, вони не з'являться магічним чином після. Розрив між добре спроектованою та стійкою data architecture, стверджує Вонг, рідко визначається самою технологією. Він визначається інженерними контролями навколо неї.

Моя думка: правильна послідовність — спочатку інвестувати в transformation-інструментарій, observability та deployment-дисципліну, а потім обирати платформу. Більшість організацій роблять це навпаки, бо рішення щодо платформи має підтримку керівництва та бюджетний рядок. Контролі додають пізніше, під тиском, після першого серйозного інциденту.

Пастки та граничні випадки

CFO будь-якої компанії, яка розглядає міграцію на lakehouse в цьому кварталі, має поставити VP of Engineering одне конкретне запитання: яка повна операційна вартість за тридцять шість місяців, включно зі штатом, необхідним для підтримки pipeline observability та повторного використання трансформацій, а не лише контрактом на платформу. Більшість TCO-моделей, що надаються фінансовим відділам, занижують людські витрати вдвічі-втричі — і саме цей розрив перетворює чисту міграцію на багаторічний перевитрата бюджету.

Стежте за такими failure mode під час впровадження. Невеликі зміни, що розповсюджуються по кількох шарах — це ранній сигнал того, що логіка трансформацій не структурована для змін. Якщо перейменування колонки в source-системі вимагає правки дванадцяти файлів, архітектура вже почала деградувати. По-друге, коли занадто багато розуміння зосереджено в занадто небагатьох людей — це проблема ризику на ринку найму, а не лише проблема документації. Два senior-інженери, які звільняються в одному кварталі, можуть фактично заморозити розвиток платформи.

Регуляторний ризик — третя пастка, особливо для fintech- та iGaming-команд, які це читають. Lake-архітектури спочатку збирають дані, а потім їх регулюють — а це рівно навпаки від того, як більшість режимів захисту даних хочуть, щоб ви працювали. Lineage, retention та контроль доступу мають бути закладені в архітектуру, а не переробляться під тиском аудиту.

Ключові висновки

• Обирайте архітектуру, яку ваша команда здатна підтримувати, а не ту, що найкраще виглядає на демо. Центральна теза Вонга: складність випереджає спроможність, коли команди обирають лише за функціональністю.
• Гнучкість має ціну у вигляді дисципліни. Lakes і lakehouses дозволяють швидко збирати дані, але без інженерних контролів ця швидкість перетворюється на хаос протягом вісімнадцяти місяців.
• Чотири якості стійких архітектур мають організаційну, а не технічну природу: observable пайплайни, повторно використовувані трансформації, контрольовані деплойменти та архітектура, яка залишається зрозумілою в міру розвитку.
• Концентрація інституційних знань — це ризик для платформи. Документуйте активно, ротуйте відповідальність і ставтесь до єдиної точки людського збою так само, як до єдиної точки збою системи.
• Команди, які розглядають міграцію платформи у 2026 році, вже зараз мають запитати себе, кого наймати — platform engineer чи data reliability engineer, адже рішення щодо архітектури та рішення щодо організаційної структури — це одне й те саме рішення.