Коли інженер Confluent і відомий Java-розробник Ґуннар Мерлінґ узявся за Hardwood, новий рушій для читання й запису файлів Apache Parquet, він поставив собі нетипову для сучасної Java-екосистеми мету: максимально швидкий багатопотоковий двигун — із мінімально можливим слідом залежностей. У розмові на подкасті Confluent Developer він описує Hardwood як «AI-first» проєкт, але не менш важливою темою стає інша риса: радикальний контроль над залежностями як інструмент спрощення деплойменту й зменшення ризиків у ланцюгу постачання.
Hardwood уже вміє читати Parquet-файли й планує підтримку запису. Але головна інтрига не лише в продуктивності, а в тому, як цей двигун намагається вирватися з тіні Hadoop-спадщини, яка десятиліттями формувала вигляд Java-стека для обробки даних.
Коли один Parquet-джар тягне за собою весь Hadoop
У Java-світі давно існує стандартна бібліотека для роботи з Parquet — parquet-mr, відома як Parquet Java. Вона перевірена часом, використовується в безлічі фреймворків і систем, але має одну суттєву ваду: історичну прив’язку до Hadoop-екосистеми.
Підключення Parquet Java до застосунку означає не лише можливість читати колонковий формат. Разом із нею в проєкт заходить «багаж» у вигляді значної частини Hadoop-стека як транзитивних залежностей. Для багатьох застосунків це виглядає непропорційно: розробник хоче просто прочитати файл, а отримує десятки додаткових бібліотек на classpath.
У сучасних умовах це вже не просто естетична проблема. Кожна додаткова залежність — це потенційне джерело CVE, потреба стежити за оновленнями, ризик конфліктів версій і збільшення площі атаки. Те, що колись було «просто зручністю» — автоматичне підтягування транзитивних залежностей, — сьогодні дедалі частіше сприймається як загроза керованості та безпеці.
Hardwood народжується як відповідь саме на цю ситуацію. Його базова ідея: Parquet-двигун не повинен автоматично тягнути за собою пів Hadoop’а, якщо завдання — лише прочитати чи записати файли.
Нуль за замовчуванням: філософія «спершу без залежностей»
Ключова відмінність Hardwood — не лише в тому, що він «менш залежний», а в тому, як саме сформульовано дизайн-принципи. Мерлінґ описує ментальну модель так: за замовчуванням — нуль залежностей, а все інше додається лише як невеликі, чітко окреслені опційні модулі.
Це не спроба героїчно «переписати світ» і відмовитися від усіх сторонніх бібліотек. Навпаки, підхід побудований на усвідомлених компромісах. Є речі, які доцільно реалізувати самостійно, і є ті, де повторне винаходження велосипеда не має сенсу. Але стартова позиція завжди одна: не підключати нічого, поки немає чіткої, локальної причини це зробити.
Такий підхід різко контрастує з типовою практикою в Java та JavaScript/TypeScript-екосистемах, де одна залежність легко розростається до сотень транзитивних. У Hardwood автоматизм замінюється явним вибором: якщо потрібна додаткова можливість, вона приходить у вигляді окремого модуля, який розробник підключає свідомо.
Це має кілька наслідків.
По-перше, різко скорочується дерево залежностей для базового сценарію: прочитати Parquet-файл із локальної файлової системи. У цьому випадку Hardwood прагне працювати без сторонніх бібліотек взагалі.
По-друге, зменшується ризик «прихованих» залежностей, про які команда дізнається лише тоді, коли з’являється конфлікт версій або критична вразливість у якомусь глибокому транзитивному пакеті.
По-третє, спрощується аудит безпеки. Коли список залежностей короткий і зрозумілий, легше оцінити, що саме потрапляє в продакшн-артефакт і які ризики це несе.
Ланцюг постачання під мікроскопом: безпека як аргумент проти «жирних» стеків
Тема безпеки ланцюга постачання програмного забезпечення за останні роки перетворилася з нішевої на мейнстрим. Інциденти на кшталт SolarWinds, атаки через компрометовані пакети в популярних реєстрах, дедалі жорсткіші регуляторні вимоги — усе це змушує команди уважніше дивитися на те, що саме вони вбудовують у свої системи.
У цьому контексті традиційна модель «підключи одну бібліотеку — отримай десятки інших» стає дедалі менш прийнятною. Кожен додатковий джар — це:
- потенційне джерело вразливостей, які потрібно моніторити;
- додатковий об’єкт для перевірок безпеки й комплаєнсу;
- ще один учасник у складній грі сумісності версій.
Hardwood прямо орієнтується на те, щоб мінімізувати цей ризик. Відмова від великих транзитивних дерев — не лише питання елегантності, а й спосіб зменшити площу атаки. Якщо Parquet-двигун не тягне за собою Hadoop, то й потенційні проблеми в цих бібліотеках не впливають на застосунок, який просто читає файли.
Це особливо важливо для організацій із жорсткими вимогами до безпеки та комплаєнсу, де кожна нова залежність проходить через окремий процес затвердження. У таких умовах «легкий» Parquet-двигун із чітко контрольованими опційними модулями може стати суттєвою перевагою.
Водночас підхід Hardwood не ідеалізує повну ізоляцію. Мерлінґ підкреслює, що питання завжди в балансі: деякі речі доцільно реалізувати самостійно, інші — краще делегувати перевіреним бібліотекам. Але ключове — щоб кожне таке рішення було свідомим, а не наслідком автоматичного підтягування транзитивних залежностей.
HTTP замість SDK: як Hardwood працює з S3 без «важкого» клієнта
Один із найцікавіших прикладів цієї філософії — робота Hardwood з об’єктними сховищами, насамперед Amazon S3. У типовому Java-проєкті для цього використовують офіційний AWS SDK, який сам по собі є значним джерелом залежностей.
Parquet-файли часто зберігаються в S3, і ефективна робота з ними вимагає не повного завантаження файлу, а вибіркового читання окремих ділянок за допомогою HTTP range-запитів. Це дозволяє використовувати статистику й метадані Parquet, щоб мінімізувати обсяг I/O.
Замість того щоб підключати AWS SDK, Hardwood спирається на вбудований HTTP-клієнт Java, доступний починаючи з Java 11. Цей клієнт достатньо потужний, щоб виконувати необхідні range-запити до S3, не додаючи жодних зовнішніх залежностей.
Є, однак, важливий нюанс: запити до API AWS мають бути підписані за специфічним алгоритмом підпису, визначеним Amazon. Традиційно це одна з причин використовувати офіційний SDK, який бере на себе всі деталі реалізації.
У Hardwood цей бар’єр долається інакше. Алгоритм підпису добре задокументований, а Amazon публікує офіційний тестовий набір. Це створює умови, за яких реалізацію можна відтворити самостійно, перевіривши її на відповідність специфікації. Мерлінґ описує, як сучасні інструменти на базі великих мовних моделей дозволяють досить швидко отримати коректну реалізацію такого алгоритму, не вдаючись до повного SDK.
Результат: Hardwood уміє виконувати підписані HTTP-запити до S3, використовуючи лише стандартну бібліотеку Java. Жодних додаткових джарів, жодних транзитивних дерев.
Це показовий приклад того, як поява потужних AI-інструментів змінює «make or buy»-рішення в інженерії. Те, що раніше здавалося надто ризикованим для самостійної реалізації, тепер стає реалістичним варіантом — за умови чіткої специфікації й наявності тестового набору.
Де провести межу: опційний модуль для AWS-автентифікації
Втім, не всі аспекти інтеграції з AWS однаково придатні для «нульової залежності». Автентифікація в екосистемі AWS — це не лише підпис запитів, а й широкий спектр механізмів: статичні ключі доступу, IAM-ролі, прив’язка до EC2-інстансів, тимчасові токени й інші варіанти, які еволюціонують разом із платформою.
Спроба відтворити всю цю гаму можливостей у межах Hardwood означала б постійне стеження за змінами в AWS, підтримку складної логіки й ризик відставання від офіційних реалізацій. Тут філософія «нуль залежностей» наштовхується на практичні обмеження.
У цьому місці Hardwood свідомо змінює підхід. Для сценаріїв, де потрібна інтеграція з IAM-ідентичностями та іншими просунутими механізмами автентифікації AWS, проєкт пропонує окремий опційний модуль — hardwood-aws-auth (назва в розмові згадується саме як «AWS auth module»).
Цей модуль підключається лише тоді, коли застосунку справді потрібні такі можливості. Базовий сценарій — читання Parquet-файлів із S3 за допомогою підписаних HTTP-запитів — залишається можливим без нього. Але якщо інфраструктура покладається на IAM-ролі чи інші складні схеми, розробник може явно додати відповідний модуль.
Такий підхід демонструє, як Hardwood поєднує принцип «нуль за замовчуванням» із прагматизмом. Там, де реалізація чітко окреслена й стабільна (як у випадку алгоритму підпису), проєкт іде шляхом власної реалізації. Там, де простір можливих варіантів широкий і змінний (як у випадку автентифікації AWS), використовується опційний модуль, який може спиратися на офіційні чи сторонні бібліотеки.
Для користувача це означає більший контроль: складність і залежності з’являються лише тоді, коли вони справді потрібні, а не як побічний ефект базової функціональності.
Компресія за запитом: коли бібліотеки все ж потрібні
Ще одна сфера, де Hardwood обирає модульний підхід, — підтримка алгоритмів стиснення. Формат Apache Parquet дозволяє використовувати різні схеми компресії: від класичних на кшталт Gzip до сучасніших варіантів. Реалізовувати всі ці алгоритми з нуля в межах одного проєкту було б нераціонально.
Тут Мерлінґ не намагається «перемогти» екосистему. Навпаки, він прямо визнає, що немає сенсу повторно реалізовувати Gzip та інші поширені алгоритми, які вже якісно реалізовані в існуючих бібліотеках. Але замість того, щоб підключати повний набір компресійних бібліотек «про всяк випадок», Hardwood робить їх опційними.
Логіка проста: якщо Parquet-файли, з якими працює застосунок, використовують певний алгоритм стиснення, тоді й лише тоді в проєкт додається відповідна бібліотека. Якщо ж файли не стиснені або використовують інший алгоритм, непотрібні залежності просто не потрапляють у classpath.
Це знову повертає нас до ідеї свідомого вибору. Замість універсального, але «важкого» набору підтримки всіх можливих алгоритмів Hardwood дозволяє збирати конфігурацію «а-ля карт»: лише ті модулі, які відповідають реальним даним і сценаріям використання.
З погляду безпеки це означає меншу кількість бібліотек, за якими потрібно стежити. З погляду експлуатації — менший розмір артефактів і простіший аналіз залежностей. З погляду розробника — чіткіше розуміння того, які саме можливості Parquet-двигуна задіяні в конкретному застосунку.
Чи варто відмовлятися від транзитивних залежностей як класу?
На тлі Hardwood Мерлінґ ставить ширше питання: чи не завели нас автоматичні транзитивні залежності в глухий кут? Ідея, яка колись здавалася безумовним благом — «одна команда, і всі потрібні бібліотеки підтягуються самі» — сьогодні дедалі частіше обертається неконтрольованим розростанням стеків.
У розмові він припускає, що екосистема могла б виграти, якби транзитивні залежності не підключалися автоматично, а вимагали явного підтвердження. Це змусило б розробників уважніше ставитися до того, що саме вони додають у свій проєкт, і, можливо, зменшило б кількість «прихованих» залежностей, про які ніхто не пам’ятає до першого інциденту безпеки.
Hardwood у цьому сенсі виступає як експериментальна платформа: що буде, якщо спроєктувати інфраструктурну бібліотеку, виходячи з припущення, що транзитивні залежності — це радше виняток, ніж норма? Як зміниться досвід розробників, безпека, керованість деплойменту?
Відповіді на ці питання ще належить побачити в реальних продакшн-сценаріях. Але вже зараз очевидно, що підхід Hardwood резонує з ширшими тенденціями: прагненням до менших, краще контрольованих стеків, зростаючою увагою до ланцюга постачання й бажанням мати більше прозорості в тому, що саме потрапляє в продакшн.
Висновок: Parquet-двигун як маніфест проти «зайвого коду»
Hardwood починався як технічний виклик: створити швидкий, багатопотоковий Parquet-двигун для Java, використовуючи сучасні AI-інструменти. Але в процесі він перетворився ще й на маніфест проти надмірних залежностей.
Мінімальний слід залежностей, відмова від Hadoop-багажу, власна реалізація підпису запитів до S3 на базі стандартного HTTP-клієнта Java, опційні модулі для AWS-автентифікації й компресії — усе це складається в цілісну стратегію. Стратегію, в якій кожна залежність має бути виправданою, локальною й прозорою.
У світі, де безпека ланцюга постачання стає критичною темою, а стек застосунку легко перетворюється на «чорну скриньку» з сотнями джарів, такий підхід виглядає не лише технічно елегантним, а й практично необхідним. Hardwood показує, що навіть у такій усталеній ніші, як Parquet для Java, ще є простір для переосмислення базових інженерних рішень — і що контроль над залежностями може бути не менш важливим, ніж сирі показники продуктивності.
Джерело
Confluent Developer Podcast — Gunnar Morling Built a New Parquet Engine with AI | Ep. 31