Дата-платформи
Дата-платформа — це стек, який збирає, зберігає й переміщує записи організації, а та, що збудована під надійну мережу, спершу надсилає, а зберігає як побічний ефект. Переверніть це припущення — і разом із ним перевернеться архітектура: вузол пише локально й завжди, надсилання стає фоновою справою за нагоди, якої сьогодні може не бути, а цікавим проєктним рішенням стає те, які записи підуть першими, коли вікно контакту триває сорок секунд. Тут — про цю чергу, про приймальний бік, що очікує обриву, і про три властивості, які мусить нести кожен запис.
- Записувати
- Локально, завжди
- Надсилати
- За пріоритетом, за нагоди
- Кожен запис несе
- Походження й клас
Зберегти й переслати — і черга, що робить це проєктуванням
«Зберегти й переслати» — річ давня й проста: запиши там, де ти є, надішли, коли зможеш. Проєктуванням, а не буфером, це робить те, що стається, коли черга більша за вікно, — а це нормальний випадок, а не виняток.
Порахуйте один раз — і суть стане очевидною. Сорокасекундне вікно на девʼяти кілобітах на секунду переносить близько сорока пʼяти кілобайтів. Критична подія важить два кілобайти й іде щоразу. Оновлення треків — сорок кілобайтів і йдуть здебільшого. Відео — девʼятсот мегабайтів, і цим каналом воно не піде ніколи, — і це проєктний факт, який вирішують наперед, а не несподіванка, яку виявляють у полі. Відео їде на фізичному носії, коли платформа повернеться, або зводиться на борту до чогось, що вміщається, або не їде взагалі.
Приймальний бік припускає, що його обірвуть
Оскільки вікно закривається без попередження, кожна передача є передачею, яка може завершитися наполовину, а відновлене зʼєднання може бути іншим, з іншого вузла й не в тому порядку. Три властивості роблять це переживним, і всі три дешево закласти й боляче додати згодом.
| Властивість | Що це означає конкретно | Що ламається без неї |
|---|---|---|
| Ідемпотентне приймання | Кожен запис має стабільний id, згенерований на краю; отримати його двічі — те саме, що отримати один раз. | Повтор після обірваного вікна дає дублікати, і всі підрахунки тихо стають хибними. |
| Незалежність від порядку | Записи несуть власний час події і розміщуються за ним, а не за послідовністю прибуття. | Учорашня партія, що прийшла після сьогоднішньої, переписує теперішнє минулим. |
| Дописувати, ніколи не перезаписувати | Нова інформація є новим записом із посиланням на старий; ніщо вже збережене не заміщується. | Пізня правка видаляє початкове спостереження, і розбіжність, що важила, зникає. |
| Поновлювана передача | Прогрес відстежується щодо кожного запису, тож наступне вікно продовжує, а не починає спочатку. | Черга, більша за вікно, ніколи не розбирається, бо кожна спроба починається спочатку. |
Разом вони роблять протокол синхронізації обміном незмінними фактами, а не узгодженням змінюваного стану, — а це помітно простіше зробити правильно. Це також та властивість, від якої залежить шар C2: кореляцію можна перезапустити на обʼєднанні побаченого обома сторонами лише тоді, коли обидві зберегли побачене як записи, а не як поточне значення.
Три речі, що мусять їхати з кожним записом
Кожна з них виглядає метаданими, і кожна визначає щось структурне. Додати будь-яку згодом — це міграція через кожного виробника, кожне сховище й кожного споживача, тож їм місце в першій схемі.
Походження
Який пристрій, який сенсор, яка версія ПЗ, який оператор, коли. Запис без джерела неможливо оцінити, виправити чи виключити, коли зʼясується, що джерело було несправним.
Класифікація
Категорія обробки, що вирішує, у якому сховищі запис може законно лежати, хто може його читати і де він може перетнути кордон. Це вхід для архітектури, а не мітка, додана при вивантаженні.
Правило зберігання
Скільки він зберігається і що далі. Тут видалення є обовʼязком, який хтось перевірить, а не способом зменшити рахунок за сховище, — і воно має бути виконуваним на пристрої, до якого ви можете не дістатися.
Саме класифікація дивує інженерів, бо вона переносить юридичне питання в архітектуру. Якщо категорія записів не може покинути юрисдикцію чи не може лежати на спільному сервісі, це обмеження вирішує, де живе сховище, як маршрутизується синхронізація і які керовані продукти вам доступні, — і вирішує це раніше за будь-які міркування продуктивності. Записати категорії рано — саме те, що не дає робочій системі стати невипускною з причин, які взагалі не стосуються того, чи вона працює.
Антипатерни, які варто назвати
- Черга «перший прийшов — перший пішов»: найстаріша рутинна телеметрія їде поперед тривоги, піднятої тридцять секунд тому.
- Id записів, згенеровані на приймальному боці: перша ж обірвана передача стає постійними дублікатами.
- Перезапис при виправленні: зникає початкове спостереження, а з ним і доказ, що щось не збігалося.
- Записи без терміну придатності: черга накопичує оновлення позиції дворічної давнини, які ніколи не варто надсилати.
- Вважати класифікацію міткою на етапі вивантаження, а не входом, що вирішує, де дані можуть жити.
Коли це застосовувати
Застосовуйте, коли
- Щоразу, коли мережа є подією, а не комунальною послугою, і вузол мусить працювати крізь довгу відсутність.
- Коли черга більша за вікно контакту: тоді порядок пріоритетів стає продуктовим рішенням.
- Коли проєктуєте приймання: ідемпотентне, незалежне від порядку, лише на дозапис і поновлюване — усі чотири разом.
- Коли пишете схему: походження, класифікація й зберігання, додані згодом, стають міграціями.
Уникайте, коли
- Як загальний матеріал з дата-інженерії: ним володіють розділи баз даних та інфраструктури, і ця сторінка на них спирається.
- Як настанову щодо спільної картини, збудованої з цих даних: це сторінка C2, а не ця.
- Там, де мережа справді надійна: тоді «зберегти й переслати» є складністю, за яку вам не платять.
- Як привід зберігати все назавжди: зберігання тут є обовʼязком, а не рішенням про сховище.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.