Очень красивые и редкие

https://missing-semester-rus.github.io

Может кому надо?

В современном маркетинге данные — это новая нефть, а рекламный идентификатор (Advertising ID) — это трубопровод, по которому эта нефть течет. От смартфона в кармане до умного телевизора в гостиной: каждое устройство имеет свой цифровой паспорт.

В этой статье мы разберем не только скрытую механику «рекламной слежки», но и юридические риски для бизнеса в РФ, новые технологии обхода блокировок и то, как клиентский опыт (CX) меняется в эпоху тотальной приватности.

1. Зоопарк идентификаторов: Кто есть кто

Рынок рекламных ID фрагментирован. Каждый сегмент решает одну задачу — узнать пользователя, — но делает это разными способами.

📱 Мобильные устройства (MAID — Mobile Advertising IDs)

Это самые ценные идентификаторы, так как смартфон является наиболее персональным (“интимным”) устройством.

• IDFA (Identifier for Advertisers): Стандарт Apple (iOS). После внедрения *App Tracking Transparency (ATT)* в iOS 14.5 доступ к нему закрыт по умолчанию.
  > Важно: Лишь 20-30% пользователей в мире нажимают «Разрешить» (Allow Tracking). Это создало огромную «слепую зону» в аналитике.
• GAID (Google Advertising ID) / AAID: Аналог для Android. Позволяет связывать активность пользователя между разными приложениями. Google также движется в сторону ограничения доступа через инициативу Privacy Sandbox on Android.

📺 Телевизоры и Set-Top Box (CTV IDs)

С ростом Smart TV и стримингов маркетологи теперь трекают пользователей «на диване».

• Примеры: TIFA (Samsung), Roku ID, Amazon Fire TV ID.
• Логика Household (Домохозяйство): В отличие от личных смартфонов, эти ID часто привязаны к семье.
  • *Инсайт эксперта по данным:* Это создает проблему «шумных данных». Если вы рекламируете женские духи, а телевизор смотрит муж или ребенок, атрибуция будет ошибочной. Для очистки данных используются Cross-Device графы, связывающие TV ID с мобильными телефонами, находящимися в той же Wi-Fi сети.

🌐 Веб-идентификаторы

• Third-Party Cookies: Старейший и умирающий стандарт. Текстовые файлы, оставляемые рекламными сетями (не владельцем сайта) в браузере.
• Stable IDs / Hashed Emails: Новая валюта рынка. Это зашифрованные (хэшированные) адреса электронной почты или номера телефонов. Используются в таких решениях, как *Unified ID 2.0*.

2. Механика: Как они строятся и живут

Формула генерации

Большинство мобильных ID (GAID, IDFA) представляют собой UUID (Universally Unique Identifier) версии 4. Это 128-битное число.

$$ P(collision) \approx \frac{n^2}{2 \times 2^{128}} $$

Вероятность совпадения двух таких ID астрономически мала.

• Пример: `123e4567-e89b-12d3-a456-426614174000`
• Генерация: Алгоритм использует криптографически стойкий генератор случайных чисел (CSPRNG) + энтропию системы (время запуска, «шум» железа).

Жизненный цикл и безопасность

Главное отличие рекламного ID от аппаратного (IMEI) — возможность сброса (Resettability).

1. Действие пользователя: В настройках конфиденциальности нажимается «Сбросить рекламный ID».
2. Реакция ОС: Генерируется новый UUID.
3. Результат: Для рекламных сетей устройство становится «чистым листом». История интересов разрывается.

3. E-commerce: Сквозь экраны к покупке

В интернет-коммерции ID — это клей, собирающий разрозненные клики в путь покупателя (Customer Journey Map).

Сквозная аналитика (Cross-Device)

Как понять, что телефон `User_A` и ноутбук `Cookie_B` — это один человек?

1. Deterministic (Точный метод): «Золотой стандарт». Пользователь залогинился в магазине под своим Email на обоих устройствах. Связка 100% достоверна.
2. Probabilistic (Вероятностный метод): Система видит, что телефон и ноутбук ежедневно выходят в сеть с одного IP-адреса Wi-Fi в одно время, имеют похожие паттерны посещения сайтов. Алгоритмы с вероятностью 90%+ «склеивают» профили в один Household.

Механика таргетинга (RTB – Real Time Bidding)

Процесс показа рекламы занимает менее 100 миллисекунд:

1. Вы смотрите кроссовки в приложении (система фиксирует ваш `GAID`).
2. Вы открываете новостной сайт. Сайт отправляет ваш `GAID` на рекламную биржу.
3. DSP (платформа закупки) узнает ваш ID в базе сегментов: *«Это тот же, кто смотрел Nike 5 минут назад!»*.
4. Происходит мгновенный аукцион, ставка выигрывает, и вам показывается баннер.

4. Феномен Amazon Ads и Retail Media

Amazon (и его аналоги в РФ) стоит особняком. Это закрытая экосистема (Walled Garden), чья сила не в технологиях трекинга, а в транзакционных данных. Им не нужно *угадывать*, что вы хотите купить, они *знают*, что вы покупаете.

Идентификатор Amazon

В основе лежит не «летучий» UUID устройства, а Internal Customer ID, жестко привязанный к аккаунту.

• Формула матчинга: Для обмена данными с внешним миром используется Hashed Email (HEM). Ваш email превращается в необратимую строку (обычно SHA-256).
• Clean Rooms (AMC): Amazon Marketing Cloud позволяет крупным брендам загружать свои CRM-данные в защищенную среду, где они пересекаются с данными Amazon. Рекламодатель получает инсайты (например, “Клиенты, купившие кофемашину у нас на сайте, покупают капсулы на Amazon”), но не видит персональных данных конкретных людей.

5. Война за приватность и обходные пути

Индустрия находится в состоянии холодной войны между запросом на приватность и эффективностью.

Главные сложности

• Apple ATT: Обрушение эффективности рекламы Facebook на iOS. Стоимость привлечения клиента (CAC) выросла на 40-60%.
• Смерть Cookies: Google Chrome (хоть и откладывает полное отключение) внедряет Privacy Sandbox, заменяя индивидуальные куки на FLoC/Topics API (группировку по интересам).
• Блокировщики: AdBlock режет запросы к доменам трекеров. (на уровне DNS, например AdGuard)

Как рынок обходит блокировки? Технический Deep Dive

1. Server-Side Tracking (S2S / CAPI):
   Вместо отправки данных пикселем из браузера (JS), данные о покупке отправляются напрямую с бэкенда магазина на сервер рекламной системы (например, через Facebook Conversions API).
• Плюс:* Не блокируется AdBlock и браузерами. Точность данных выше.
• Минус:* Сложная техническая реализация. Требует согласия пользователя на передачу данных.

2. Fingerprinting (Серый метод):
   Сбор уникальных параметров устройства без использования cookie:
• `Screen Resolution` + `User Agent` + `Battery Level` + `System Fonts` + `AudioContext`
• Такой “цифровой отпечаток” уникален для 95% пользователей. Apple и Google активно борются с этим методом, считая его нарушением приватности.

Итог: Тренды 2025+ и рекомендации

Эра «дикого запада», когда можно было незаметно следить за каждым шагом, заканчивается. Мы переходим в эру агрегированных данных и доверительного маркетинга (Zero-Party Data).

Ключевые тренды:

1. First-Party Data — король: Компании, владеющие собственными данными и прямым контактом с клиентом (Email, App), выигрывают. Зависимость от Facebook становится токсичной.
2. Retail Media Networks: Бум рекламных сетей маркетплейсов. Они обладают данными о деньгах, а не о кликах.
3. AI вместо Cookies: Алгоритмы машинного обучения будут «достраивать» потерянные данные. Например, Google GA4 уже использует моделирование конверсий для пользователей, отказавшихся от трекинга.

✅ Рекомендация

• Инвестируйте в CDP (Customer Data Platform): Собирайте все данные (CRM, сайт, приложение) в одном месте.
• Внедряйте Server-Side трекинг: Это единственный способ сохранить точность аналитики в будущем.
• Тестируйте новые каналы: Telegram Ads (работает без кук, на контексте каналов) или Retail Media.
• Аудит согласий: Проверьте формы сбора данных на сайте. Галочка «Согласен на рекламную рассылку» должна быть отделена от «Согласен на обработку ПДн». Но мне, если честно, не нравится такой подход. Я бы сделал так – Типа Посмотри 10 рекламных роликов, и спи спокойно сегодня до 12, больше показывать сегодня не буду типа)))
• Обезличивание: Используйте методы обезличивания (деперсонализации) при передаче данных партнерам, как того требуют новые правила consultant.ru.
• Цели обработки: Четко прописывайте цели в политике конфиденциальности (например, не просто “маркетинг”, а “таргетирование рекламы в сетях Яндекса”) rppa.pro. Кстати, хороший справочник.

куча разного софта есть, но этот очень похож на YNAB – который кстати удобный, но платный

https://github.com/actualbudget/actual

Пробуйте ...

Мне еще нравится https://ledger-cli.org но это для особо упоротых и командной строки. :)

2025 год стал поворотным моментом для индустрии баз данных. Мы увидели не просто эволюцию существующих технологий, а фундаментальный сдвиг в том, как приложения взаимодействуют с данными. Эпоха “просто хранения” закончилась — началась эра “интеллектуального взаимодействия” через AI-агентов и глубокую интеграцию векторного поиска.

В этом обзоре мы разберем ключевые события, техно-потери и главные приобретения, сформировавшие ландшафт года.

Оригинал тут: https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-retrospective.html?utm_source=tldrdev или на интересном канале https://t.me/five_minutes_of_data

🚀 Главные тренды 2025 года

1. Доминирование PostgreSQL и его экосистемы

PostgreSQL окончательно закрепил за собой статус “стандарта де-факто”. Выход PostgreSQL 18 в ноябре 2025 года принес долгожданную подсистему асинхронного ввода-вывода (AIO), что позволяет базе данных меньше зависеть от кэша операционной системы. Также была добавлена поддержка *skip scans*, что значительно ускоряет запросы по B-Tree индексам, даже если пропущены ведущие ключи (префиксы).

Но главный “движ” происходил не в ядре, а вокруг него:

• Распределенный Postgres: В этом году развернулась настоящая битва за горизонтальное масштабирование (шардинг). Проекты вроде Multigres (от Supabase) и Neki (от PlanetScale) нацелились на решение проблемы масштабирования записи, бросая вызов таким ветеранам, как Citus и YugabyteDB.
• Война поглощений: Крупнейшие игроки скупали Postgres-стартапы. Databricks заплатил 1 млрд долларов за Neon, а Snowflake выложил 250 млн долларов за Crunchy Data. Это показывает, что облачные гиганты хотят владеть своими собственными “движками” Postgres, а не просто хостить open-source.

2. Взлет MCP (Model Context Protocol)

Если 2023-й был годом векторных индексов, то 2025-й стал годом MCP от Anthropic. Это стандартизированный протокол (на базе JSON-RPC), позволяющий LLM взаимодействовать с внешними инструментами и базами данных без написания кастомного связующего кода (glue code).

Практически все вендоры (MongoDB, Neo4j, Redis, Snowflake, ClickHouse) выпустили свои MCP-серверы. Теперь AI-агент может самостоятельно “изучить” схему базы данных и выполнить SQL-запрос.

Важно: Это открывает огромные возможности, но и создает риски безопасности. Агент с правами администратора может случайно выполнить `DROP DATABASE`. Внедрение MCP требует жесткого разграничения прав доступа и использования прокси с защитными механизмами.

3. Битва форматов файлов и “Смерть Parquet”?

Неожиданно обострилась конкуренция в области файловых форматов для аналитики. Старый добрый Parquet столкнулся с новыми претендентами: Vortex (от SpiralDB), Nimble (Meta), Lance и другие.
Причина — рост использования GPU для аналитики и необходимость в более быстрых декодерах. Parquet, созданный более 10 лет назад для Hadoop, начинает отставать в эпоху современного “железа” и случайного доступа к данным.

• Появление DuckLake указывает на попытки переосмыслить архитектуру Data Lakehouse.

4. Рост локальных и Edge баз данных

На фоне развития Local AI (запуск нейросетей на устройствах пользователя) вырос спрос на базы данных, работающие “на краю” (on-device). Такие решения, как Turso (на базе libSQL/SQLite) и оптимизированные версии DuckDB, позволяют обрабатывать данные прямо на ноутбуке или смартфоне пользователя, снижая задержки и повышая приватность. AI больше не обязан жить только в облаке.

☠️ Кладбище технологий 2025

Не все пережили этот год. Рынок безжалостен к тем, кто не нашел свою нишу или бизнес-модель.

• Voltron Data: “Супергруппа” разработчиков (создатели Apache Arrow, Ibis и др.), собравшая $110 млн, не смогла выпустить коммерчески успешный продукт Theseus (GPU-ускоренная база). Они закрылись.
• PostgresML: Идея запускать ML прямо внутри Postgres была хорошей, но убедить компании мигрировать на их платформу оказалось сложно.
• Fauna (прекращение поддержки собственного языка?): Хоть компания и жива, игнорирование SQL в начале пути стоило им дорого. В 2025 году стало окончательно ясно: если у тебя нет SQL — ты теряешь рынок.
• Derby: Один из старейших Java-движков (экс-IBM Cloudscape) перешел в режим “read-only” (архивации). Эпоха ушла.

🏆 Интересные технические новинки

🔥 Скандал года: MongoDB против FerretDB

Судебный иск MongoDB против FerretDB стал самым громким юридическим событием. FerretDB предлагает open-source прокси, который конвертирует запросы MongoDB в SQL для PostgreSQL. MongoDB обвинила их в нарушении прав на торговую марку и патенты.
Это дело ставит под вопрос саму возможность создания совместимых API. Если Oracle проиграла Google в битве за Java API, то исход битвы за API баз данных пока не ясен.

МненИИе: Что нас ждет в 2026

*Раздел подготовлен на основе анализа трендов и экстраполяции текущих событий.*

1. “Агентификация” баз данных:
   В 2026 году базы данных перестанут быть пассивными хранилищами. Мы увидим первые промышленные внедрения Autonomous DBA Agents — AI-агентов, которые живут внутри базы, сами строят индексы, оптимизируют запросы в реальном времени и даже исправляют простые ошибки в данных без участия человека. MCP станет стандартом для всех Enterprise-решений.

2. GPU становится стандартом для OLAP:
   Неудача Voltron Data не остановит тренд. Просто GPU-ускорение станет не отдельным продуктом (“GPU Database”), а опцией внутри существующих гигантов (Snowflake, Databricks, PostgreSQL). Запросы будут прозрачно делегироваться на видеокарты там, где это эффективно. Традиционные CPU-only аналитические системы начнут проигрывать в соотношении цена/производительность.

3. Кризис “Open Source” лицензий:
   На фоне исков (как у MongoDB) и желания облачных провайдеров (AWS, Azure) забирать себе всю прибыль от open-source проектов, мы увидим появление новых, более жестких лицензий (наподобие BSL), которые фактически запрещают конкуренцию со стороны облаков, но остаются открытыми для пользователей. Понятие “Open Source” будет размываться в сторону “Source Available”.

4. Смерть специализированных векторных баз:
   Векторные базы данных как отдельный класс продуктов (Pinecone, Weaviate и т.д.) столкнутся с экзистенциальным кризисом. PostgreSQL, Oracle, MongoDB и Elasticsearch уже интегрировали векторный поиск достаточно хорошо для 95% задач. Большие специализированные игроки будут куплены (как Pinecone готовился к продаже в 2025), а мелкие — исчезнут.

2026 год обещает быть годом, когда искусственный интеллект окончательно “поселится” внутри СУБД, а граница между кодом приложения и базой данных станет еще более прозрачной.

Что то вспомнилось мне, решил посмотреть и дополнить. Как то давно был на лекции Губко, очень интересно рассказывал о фракталах. Оригинал тут есть: https://www.klex.ru/1yt1

М.В. Губко «Управление организационными системами с коалиционным взаимодействием участников» (ИПУ РАН, 2003).

Это научная работа в области теории управления, теории игр и исследования операций. Ниже представлен анализ, краткое содержание, контекстуализация знаниями из смежных областей и некоторые переосмысленные выводы. Болекчейн тоже кстати сегодня сталкивается с некоторым трудностями управления, а проблемы организаций DAO прямо явно про это.

1. Анализ

Предмет исследования: Организационные системы (ОС), в которых участники (агенты) могут объединяться в группы (коалиции) для совместного достижения своих целей, которые могут противоречить целям управляющего органа (центра).

Ключевая проблема: Классическая теория управления (в частности, теория активных систем — ТАС) часто рассматривает взаимодействие «Центр — Агент» как игру, где агенты действуют индивидуально (равновесие Нэша). Однако в реальности сотрудники договариваются, обмениваются ресурсами или информацией (образуют коалиции), что может разрушать планы Центра.

Методология: Аппарат кооперативной теории игр (C-ядро, вектор Шепли, решения в угрозах и контругрозах) интегрированный в задачи управления (стимулирование, распределение ресурсов).

2. Краткое содержание по главам

Глава I. Модели коалиционного взаимодействия

Автор проводит ревизию теории кооперативных игр для нужд управления.

• Выбор концепции решения: В качестве основного критерия устойчивости коалиции выбрано C-ядро (Core). Если C-ядро не пусто, существует такое распределение выигрыша, что ни одной группе не выгодно отделяться.
• Проблема: Для многих игр C-ядро пусто (система неустойчива). В таких случаях автор предлагает использовать концепцию решения в угрозах и контругрозах (уточнение переговорного множества), чтобы предсказать, какие коалиции наиболее вероятны.

Глава II. Взаимодействие при полной информации (Стимулирование)

Здесь рассматриваются ситуации, где Центр знает параметры агентов, но агенты могут кооперироваться.

• Веерные структуры: В простой структуре (один начальник — много подчиненных) показано, что если технологии позволяют агентам перераспределять работу, они могут «оптимизировать» выполнение плана так, что Центру это безразлично (он получает результат), но агенты выигрывают за счет перераспределения усилий.
• Матричные структуры: Рассмотрена проблема двойного подчинения. Доказано, что полная кооперация менеджеров среднего звена (проектов и отделов) часто невозможна без специального согласования интересов с высшим руководством.
• Формирование состава: Интересный вывод: агенты могут сами исключать неэффективных участников из системы («увольнять» коллег), перераспределяя их задачи и зарплату между собой, если это выгодно коалиции.

Глава III. Взаимодействие с сообщением информации (Распределение ресурсов)

Рассматривается ситуация, когда Центр не знает истинных потребностей агентов, а агенты подают заявки.

• Системы приоритетного распределения ресурсов проанализированы на устойчивость к сговору.
• Доказано, что объединение в коалиции невыгодно агентам, если полезность *нетрансферабельна* (нельзя передать выигрыш другому).
• При *трансферабельной* полезности (можно передавать деньги/ресурс) найдены условия сбалансированности игры. Показано, что наличие у Центра априорной информации (например, знание, что потребность агента лежит в определенном диапазоне) резко повышает эффективность управления и устойчивость к сговору.

3. Дополнительные знания (контекст)

Чтобы глубже понять работу, стоит добавить знания, которые выходят за рамки текста 2003 года или подразумеваются “между строк”:

1. Связь с Mechanism Design: Работа Губко лежит в русле мировой теории *Mechanism Design* (Гурвич, Маскин, Майерсон). Однако западная школа чаще фокусируется на *Coalition-Proof Nash Equilibrium* (равновесие, устойчивое к коалициям), в то время как Губко адаптирует понятие C-ядра.
2. Эффект «Зайца» (Free Rider Problem): В работе мало акцента на поведенческую экономику, но коалиции часто разваливаются не из-за математической невозможности деления выигрыша, а из-за недоверия и желания отдельных участников «проехать зайцем» за счет усилий коллектива.
3. Блокчейн и DAO: Современные децентрализованные автономные организации (DAO) сталкиваются ровно с теми же проблемами, что описаны в Главе III. Механизмы голосования и распределения токенов часто атакуются именно коалициями пользователей (sybil attacks или сговор «китов»). Математика из этой книги применима к криптоэкономике.
4. Асимметрия информации: Книга подтверждает фундаментальный закон кибернетики: эффективность управления ограничена степенью информированности Центра. Уменьшение неопределенности (знание диапазонов пиков функций полезности) прямо конвертируется в устойчивость системы.

4. Итог

Работа М.В. Губко — это фундаментальное исследование, доказывающее, что игнорирование возможности сговора агентов ведет к ошибкам в управлении. Механизмы, оптимальные для индивидуальных агентов, становятся неэффективными при наличии коалиций.

Главное достижение работы — формулировка условий (на свойства целевых функций и механизмов распределения), при которых интересы максимальной коалиции (всех участников) совпадают с интересами Центра. Это состояние называется полной сбалансированностью.

---

5. Рекомендации и переосмысленные выводы

На основе анализа и современных реалий менеджмента, предлагаю следующие выводы и рекомендации для практиков:

Переосмысленные выводы:

1. Коалиция — не враг, а инструмент: Традиционно считается, что сговор сотрудников — это плохо (коррупция, саботаж). Однако анализ (особенно Глава II) показывает, что коалиция может действовать как *распределенный вычислитель*. Агенты внутри группы могут решать задачи перераспределения нагрузки эффективнее, чем удаленный Центр.
2. Самоочищение системы: Математически обосновано (Глава II), что устойчивая коалиция стремится избавиться от «балласта» (неэффективных агентов). Центру не всегда нужно проводить аттестации — достаточно создать механизм, где фонд оплаты труда фиксирован на группу, и группа сама вытеснит слабых игроков (при условии трансферабельной полезности).
3. Прозрачность ограничений: В Главе III показано: если Центр знает хотя бы границы потребностей агентов, он может гарантировать устойчивость. Отсюда вывод — инвестиции в мониторинг и прозрачность данных о ресурсах важнее, чем усложнение формул премирования.

Рекомендации для проектирования систем управления:

1. Используйте коллективные KPI: Вместо борьбы с коалициями, легализуйте их. Переходите от индивидуального стимулирования к бригадному/отдельному (механизмы с полной сбалансированностью). Пусть C-ядро работает на вас.
2. Механизмы «защиты от сговора»: Если вы распределяете дефицитный ресурс (бюджет, премии), используйте механизмы, которые математически делают сговор невыгодным (например, механизмы Гровса-Кларка или специальные аукционы), либо убедитесь, что ресурс *нетрансферабелен* (сотрудник не может передать свою грамоту или доступ другому).
3. Управление информацией: Введите жесткие интервальные ограничения на заявки. Не позволяйте агентам заявлять «любые» потребности. Зная технические пределы оборудования или рыночные бенчмарки зарплат, Центр сужает пространство для манипуляций коалиций.
4. Матричная структура требует «Налога»: Анализ показывает, что в матричных структурах (проект vs функция) неизбежен конфликт. Для его решения требуется механизм внутреннего трансфертного ценообразования или «налога», который выравнивает интересы менеджеров среднего звена с целями всей компании. Без этого матрица будет либо парализована, либо разорвана борьбой за ресурсы.

А вот еще одна его работа М.В. Губко https://www.klex.ru/1ysn – «Математические модели оптимизации иерархических структур» (2006)

И ее небольшой анализ:

Работа на стыке теории управления, дискретной математики и микроэкономики. Автор строит строгую теорию того, как должна выглядеть идеальная иерархия управления, если мы хотим минимизировать затраты на её содержание.

Ниже анализ и краткое содержание, дополнения и переосмысленные практические выводы. Любопытно, но работа менеджеров сводится к сжатию информации, в целом это конечно так, но есть же еще принятое решение на основе этих сжатий. Но да ладно, в общем вот...

1. Анализ материала и методологии

Предмет исследования: Задача синтеза оптимальной организационной структуры (оргструктуры).
Ключевая гипотеза: Оптимальная структура — это та, которая минимизирует суммарные затраты на содержание всех менеджеров при заданном наборе исполнителей и технологий.

Особенности подхода:

1. Разделение задач: Автор четко отделяет *дизайн структуры* (кто кому подчиняется) от *дизайна технологии* (кто что делает) и *механизмов управления* (мотивация). Это позволяет свести проблему к задаче дискретной оптимизации на графах.
2. Секционные функции затрат: Вводится предположение, что затраты менеджера зависят только от того, кем он управляет *непосредственно* (его «секции»).
3. Однородность: Ключевой математический инструмент — использование однородных функций затрат (свойство самоподобия или масштабируемости). Это согласуется с эмпирическими законами (например, зависимость зарплаты топ-менеджера от размера фирмы по Саймону).

Научная новизна (на момент написания): Получение *аналитических* формул (нижних оценок) для стоимости оптимальной иерархии, что позволяет не перебирать миллионы вариантов, а сразу строить «почти оптимальное» дерево.

2. Краткое содержание по главам

Глава 1. Постановка задачи

Вводится математический аппарат. Иерархия моделируется как ориентированное дерево.

• Исполнители имеют «меру» (сложность работы, объем задач).
• Менеджеры имеют функцию затрат $c(\mu_1, \dots, \mu_r)$, зависящую от мер подчиненных групп.
• Вводятся понятия сужающих (выгодно нанимать помощников, ведет к многоуровневости) и расширяющих (выгодно увольнять промежуточных начальников, ведет к плоской структуре) функций затрат.

Глава 2. Обзор литературы

Автор критически анализирует существующие модели (Бекманн, Вильямсон, Кальво-Веллиц, Раднер).

• *Вывод:* Большинство классических экономических моделей рассматривают только симметричные иерархии с фиксированным числом уровней. Подход Губко более гибок, так как ищет оптимальную структуру без ограничений на симметрию.

Глава 3. Оптимальные деревья (Ядро книги)

Здесь содержится главный теоретический результат.

• Доказано, что для однородных функций затрат оптимальная иерархия стремится быть однородным деревом. Это значит, что на каждом уровне менеджеры имеют примерно одинаковую норму управляемости (число подчиненных).
• Выведена формула нижней оценки затрат $C_L(N)$. Это теоретический минимум расходов, к которому нужно стремиться.
• Предложены алгоритмы построения субоптимальных деревьев (Bottom-Up и Top-Down), которые дают результат, очень близкий к идеальному.

Глава 4. Примеры и приложения

Теория применяется к практике:

1. Сборочное производство: Доказано, что при определенных условиях последовательная сборка (конвейер) экономически выгоднее параллельной.
2. Обработка информации (приказы): Моделируется процесс, где менеджер детализирует приказ сверху для подчиненных. Анализируется баланс между квалификацией менеджера и степенью его специализации.
3. Пределы роста фирмы: Исследуется зависимость затрат на управление от размера фирмы ($n$).
   • Если степень однородности затрат $\gamma < 1$, фирма может расти бесконечно (эффект масштаба положительный).
   • Если $\gamma > 1$, затраты на управление растут быстрее доходов, фирма становится неэффективной при превышении критического размера.

Глава 5. Обобщения

Рассматриваются более сложные случаи: кусочно-однородные функции (скачкообразное изменение затрат) и управление технологическими связями (когда структура подчинения диктуется потоками материалов/информации между цехами).

3. Дополнение новыми знаниями и современный контекст

Книга написана в 2006 году. С позиции сегодняшнего дня (2024+) анализ можно дополнить следующими аспектами:

1. Цифровизация и AI: В моделях Губко функция затрат менеджера $c(\mu)$ — это «черный ящик», зависящий от человеческих когнитивных способностей. Сегодня внедрение AI и ERP-систем меняет эту функцию. IT-системы увеличивают норму управляемости (снижают затраты на контроль), что делает иерархии более плоскими (расширяющий эффект).
2. Сетевые структуры и Agile: Книга фокусируется на *древовидных* иерархиях. Современный менеджмент часто использует матричные или сетевые структуры (двойное подчинение, кросс-функциональные команды). Модель Губко считает такие связи «дорогими» и неоптимальными, но в условиях высокой неопределенности (VUCA-мир) гибкость сети может окупать излишние затраты на коммуникацию, чего статические модели не учитывают.
3. Человеческий фактор: Модель предполагает *анонимность* менеджеров (все менеджеры одного уровня одинаковы). В реальности «звездный» менеджер может эффективно управлять 20 людьми, а слабый — только 3. Современный HR-анализ требует ввода индивидуальных коэффициентов в функцию затрат.
4. Трансакционные издержки: В главе про сборочное производство неявно затрагивается тема трансакционных издержек (Коуз). Современные платформенные экономики (Uber, маркетплейсы) показывают, что алгоритм может заменить целые слои иерархии, сводя функцию затрат менеджера к нулю или константе (стоимость сервера).

4. Итог, рекомендации и переосмысленные выводы

Итог

Книга М.В. Губко — мощное математическое доказательство того, почему классические пирамидальные структуры (где у каждого начальника 5-7 подчиненных) так устойчивы и распространены. Это не просто традиция, это математический оптимум для широкого класса функций затрат, обладающих свойством масштабируемости.

Практические рекомендации (на основе моделей книги):

1. Правило «7 ± 2» имеет математическое обоснование: Если работа менеджеров однотипна (однородная функция затрат), то норма управляемости должна быть одинаковой по всей иерархии. Если у вас в одном отделе начальник руководит 2 людьми, а в соседнем таком же — 15, ваша структура математически неэффективна. Нужно перебалансировать нагрузку.
2. Диагностика предела роста: Оцените, как растут зарплаты и расходы на управление при росте отдела.
   • Если расходы на управление растут быстрее, чем линейно (степень $\gamma > 1$), вашу организацию нельзя масштабировать простым добавлением людей — она «схлопнется» под весом бюрократии.
   • Решение:* Либо дробить компанию на независимые юниты (рыночные отношения внутри фирмы), либо внедрять IT (менять саму функцию $c(\mu)$, снижая $\gamma$).
3. При слияниях и поглощениях: Используйте алгоритм «Bottom-Up» (снизу-вверх). Сначала объединяйте мелкие подразделения в кластеры, потом кластеры в департаменты. Это дешевле, чем пытаться натянуть новую структуру сверху.
4. Квалификация vs Специализация: В главе 4 показано, что при низкой квалификации управленцев выгоднее делать структуру более многоуровневой (узкая норма управляемости). Если вы нанимаете дорогих профи, делайте структуру более плоской. Это математически обоснованный трейд-офф.

Переосмысленные выводы (Insight):

• Иерархия — это компрессор информации. Главный вывод из главы 4.3: смысл иерархии не во власти, а в сжатии информации при передаче снизу вверх и детализации приказов сверху вниз. Оптимальная структура — это оптимальный алгоритм сжатия данных. Если данные не сжимаются (каждый чих сотрудника требует внимания гендиректора), иерархия парализуется.
• Симметрия — признак здоровья. Теоретически доказано, что для выпуклых функций затрат оптимальное дерево стремится к симметрии. Сильные перекосы («флюсы») в оргструктуре — верный признак неэффективности расходов.
• Цена контроля. Стоимость иерархии — это цена, которую мы платим за невозможность одного человека управлять всем сразу. Главная задача организационного дизайна — не «красиво нарисовать квадратики», а минимизировать эту цену через подбор такой нормы управляемости $r$, при которой производная затрат равна нулю. Для большинства стандартных задач это $r \approx 5..9$.

вот же блин, не ждал я тут подвоха 😭

сдулся мой старенький asustor, придется бутылки сдавать ... и еще накатить чего-то с горя, что бы было что сдавать.

🥹

а вот еще тряхнул стариной и решил понарошку собрать комп нестыдный на сегодня :)) ну даже очень.
вот что вышло:

ну прям мечта сисадмина и не только))) это по сути 4 в одном. через proxmox 4 виртуалки. Первая True Nas Scale для массива, вторая ubuntu server для докеров и Portainer тоже с gpu и третья виндовая для gpu в виндовой среде. Встречайте...

Проект “Монолит”: Как собрать домашний сервер мечты за миллион (и зачем это вообще нужно)

Говорят, что универсальных инструментов не бывает. Что “Швейцарский нож” режет хуже скальпеля, а универсальная шина хуже зимней. Мы решили бросить вызов этому утверждению. Ну я и мой электронный друг Gemini.

Задача звучала амбициозно: собрать в одном компактном корпусе устройство, которое заменит целый IT-отдел. Оно должно быть:

1. AI-станцией для запуска “тяжелых” нейросетей (LLM) локально.
2. Графическим ПК топового уровня (4K/8K видео).
3. Корпоративным хранилищем (NAS) на 100+ ТБ с надежностью банка.
4. Лабораторией виртуализации для Docker, Kubernetes и DevOps-экспериментов.

И всё это должно работать 24/7, стоять дома и не напоминать шумом взлетающий Боинг. Спойлер: у нас получилось.

Почему не Mac Pro и не облака?

Первый вопрос, который задают рациональные люди: *“Зачем тратить 1.2 млн рублей на самосбор, если есть MacBook Pro, AWS и простая дисковая шуршалка в углу?”*

• MacBook M4 Max прекрасен, но это “золотая клетка”. На нем не развернешь серьезный кластер виртуализации, в нем нет 100 ТБ памяти, и он все еще слабее в AI-обучении, чем топовые GPU. Ну и закрыл крышку – прод упал.
• Облака — это игла подписки. Аренда мощностей уровня нашей сборки (A100/H100) будет стоить те же деньги за год-полтора, но в итоге у вас не останется ничего.

Мы выбрали путь “Digital Sovereignty” (Цифровой суверенитет). Своё железо, свои данные, свои правила.

Анатомия Монстра: Разбор “железа”

Каждый компонент здесь — результат компромиссов и долгих споров. Вот наша “Золотая конфигурация”:

1. Сердце: Архитектура “Всё в одном”

Мы отказались от серверных Threadripper в пользу AMD Ryzen 9 9950X3D.

• *Зачем?* Нам важна однопоточная производительность для графики и отзывчивости системы. 16 ядер Zen 5 — это избыточно для дома, но идеально для виртуализации. А X3D-кэш делает этот “сервер” лучшим графическим ПК в мире.
• *Материнская плата:* MSI MAG X870E Tomahawk. Надежная база с хорошим VRM, способная переварить этот процессор 24/7. Есть еще Eco режим, что позволит немного снизить мощность, но выиграть в теплоотдач и работе 24x7.

2. Мозг AI: Революция 5090 D

Сначала мы смотрели на RTX 4090. Но потом решили взглянуть на NVIDIA RTX 5090 D (32GB).
Это “Game Changer”.

• Потребительские карты обычно имеют 24 ГБ памяти. Этого мало для серьезных языковых моделей (LLM). Llama-3-70B туда влезает только “порезанной”.
• 32 ГБ GDDR7 памяти у 5090 D открывают портал в мир взрослого AI.
• Двухслотовая турбина выбрасывает горячий воздух из корпуса, спасая остальные компоненты от перегрева. Да, это стоит 340 000 рублей, но альтернатива (профессиональные карты RTX 6000) стоит в 3 раза дороже. Это отличный истребитель, но не космический крейсер enterprise уровня.

3. Хранилище: Надежность прежде всего

• Диски: 8 штук **WD Ultrastar по 22 ТБ. Это 176 ТБ “сырого” объема.
• Контроллер: Настоящий серверный HBA-адаптер **LSI 9300-8i в прошивке IT-Mode. Никаких программных RAID на материнской плате, только хардкор.
• Файловая система: ZFS в режиме **RAIDZ2 (аналог RAID 6). Могут умереть любые два диска одновременно — данные выживут.

4. Память: Золотая (в прямом смысле) DDR5 ECC

Самая болезненная строка бюджета. 128 ГБ DDR5 ECC.
Из-за бума ИИ цены на память взлетели. Комплект из 4 планок по 32 ГБ сейчас стоит около 200 000+ рублей.

• Можно ли сэкономить и взять обычную?* Нет. ZFS активно использует оперативную память. Ошибка в бите памяти может разрушить файловую систему. Для сервера 24/7 ECC (коррекция ошибок) — обязательное требование. Лучше этим не пренебрегать.

5. Корпус: Jonsbo N5

Это магия инженерии. Красивый черный куб, куда помещается E-ATX плата, полноразмерная видеокарта и 8 жестких дисков. Мечта с красивыми деревяшками на лицевой панеле :)

Программная магия: Как этим управлять?

Железо — это только половина дела. Вся мощь раскрывается в софте.
Мы используем Proxmox VE как гипервизор. Это “слоеный пирог”:

1. VM TrueNAS: Прямой проброс контроллера LSI. Эта виртуалка управляет дисками и раздает файлы по сети.
2. VM Windows 11: Прямой проброс RTX 5090. Подключаем монитор/клавиатуру — и это мощнейший графический ПК. Или подключаемся удаленно через Moonlight.
3. VM Ubuntu Server + Docker (Portainer): Здесь живут “слуги”: Home Assistant (умный дом), Plex (кинотеатр), Nextcloud (ваше личное облако) и среды для разработки.

Экономика: Игрушка или Инвестиция?

Цена сборки чуть переваливает за 1 250 000 рублей. Безумие?
Смотря как посмотреть.

Если рассматривать это как консоль для игр — безумие.
Но если вы IT-инженер, DevOps или AI-энтузиаст, это устройство становится активом:

• Аренда мощностей: В простое карту 5090 можно сдавать в аренду на площадках типа Vast.ai для обучения чужих нейросетей, отбивая стоимость “железа”.
• Обучение и Карьера: Навыки поднятия Kubernetes-кластера дома или тонкой настройки LLM стоят на рынке труда гораздо дороже миллиона.
• Свой стартап: Это готовый MVP-стенд для запуска своего AI-сервиса без трат на облака.

Итог

Эта собрка не просто компьютер. Это автономная цифровая крепость. В эпоху, когда сервисы закрываются, подписки дорожают, а данные утекают, иметь свой собственный суперкомпьютер под столом — это не паранойя. Это новый уровень свободы для миллионеров из трущоб :)

Добро пожаловать в клуб владельцев виртуальных “Monolith”. 🤪

UPD: 25.01.2026

Первый шаг к монолиту сделан.

Кстати, конфигурация немного поменялась. Самсунг ssd заменил в плане на Микрон серверный по 960gb, но 4 штуки. У них оказался срок службы гораздо большое. в 5-7 раз где-то. Они будут работать в Raid10 или raidz1 с блоком 32к. Места будет чуть меньше в raidz1, где то 2.7tb.

Почему Micron 7450 MAX 1.6TB лучше Samsung 990 PRO

Сравниваем, опираясь на мануал материнской платы и датащит диска:

1. Бессмертие (Endurance):
   • Samsung 990 PRO (2TB):** Ресурс ~1,200 TBW.
   • Micron 7450 MAX (1.6TB): Ресурс **8,700 TBW (См. Table 3 в инструкции).
   • Итог: Micron выносливее **в 7 раз. Вы можете писать на него базы данных и логи круглосуточно, и он переживет сам сервер.

2. Over-provisioning (Резервная область):
   Почему объем такой странный — 1.6 ТБ, а не 2 ТБ?
   Micron намеренно “скрыл” около 400 ГБ флеш-памяти. Контроллер использует это скрытое место, чтобы перемещать данные, выравнивать износ и поддерживать высокую скорость, когда диск заполнен.
   У Samsung 990 PRO этой резервной области почти нет, поэтому при заполнении на 90% он начнет тормозить. Micron 7450 MAX будет работать на полной скорости даже если вы забьете его под завязку.

3. Скорость случайной записи (IOPS):
   Для виртуалок важна запись мелких файлов (4K Random Write).
• Micron 7450 PRO:** 120,000 IOPS.
• Micron 7450 MAX: **250,000 IOPS (См. Table 2).
• Модель MAX в два раза быстрее обычной серверной PRO-версии на запись. Это идеально для баз данных и ZFS SLOG.

Математика массива на Micron 1.6TB

Если берем 4 таких диска и делаем ZFS RAID10:

$$1.6 \text{ ТБ} \times 4 = 6.4 \text{ ТБ (Сырой объем)}$$
$$\text{Полезный объем (RAID10)} = 3.2 \text{ ТБ}$$

Еще большой плюс: PLP (Power Loss Protection) — Защита от потери питания, которая есть в Micron. На плате распаяны танталовые конденсаторы. Если питание пропадает, у диска есть еще несколько миллисекунд, чтобы сбросить всё из оперативной памяти в ячейки NAND = защита от отключения электропитания и потери данных.

Почему это важно для ZFS, он очень зависит от синхронной записи (Sync Writes) для баз данных и виртуальных машин. Зная, что у диска есть защита PLP, ZFS может безопасно отключать некоторые программные тормоза (O_DSYNC), работая значительно быстрее на мелких операциях записи.

Итого:
3.2 ТБ сверхбыстрого, защищенного от потери питания (PLP), “бессмертного” серверного пространства — это мечта для гипервизора Proxmox.

Короче берем Micron 7450 MAX 1.6TB. Это лучший компонент во всей сборке с точки зрения профессионального подхода. Главное найти его в форм-факторе 2280, а то на материнской плате есть только один длинный порт.

Мы привыкли, что для развертывания веб-приложений нужно платить за VPS или разбираться в дебрях Kubernetes. Но если у вас есть домашний сервер (в моем случае — Asustor), вы можете создать свою собственную PaaS-платформу (Platform as a Service), которая работает по принципу *“git push — и готово”*.

Сегодня я расскажу, как настроить Dokku через Portainer, запустить веселое Python-приложение к Новому 2026 году и поделюсь лайфхаками по оптимизации сборки и масштабированию.

Часть 1. Фундамент: Запуск Dokku в Portainer

Dokku — это Docker-контейнер, который управляет другими Docker-контейнерами. Чтобы он заработал на NAS, его нужно правильно запустить. Я использовал Portainer Stack.

Docker Compose конфигурация

Вот рабочий `docker-compose.yml`, который решает главную проблему — доступность приложений из локальной сети.

# version: '3.2'
services:
  agent:
    image: dokku/dokku:${VERSION}
    pid: host.  # ⚠️ важно для работы на NAS
    network_mode: bridge # ⚠️ важно для работы на NAS
    environment:
      DOKKU_HOSTNAME: ${DOKKU_HOSTNAME}
      DOKKU_HOST_ROOT: ${DOKKU_HOST_ROOT}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ${VOLUME_PATH:-/var/lib/dokku}:/mnt/dokku
    ports:
      - "3022:22" # ⚠️ важно для работы через ssh и что бы не конфликтовал с 22 
      - "80:80"    # Внешний порт 80 -> порт 80 внутри контейнера Dokku
      - "443:443"

Нюансы сети:
Чтобы обращаться к приложениям по красивым домегам типа `my-app.dokku.datahub.mother`, я настроил AdGuard Home в качестве локального DNS-сервера (фильтры получил бонусом – где-то 20% это всякие счетчики, ужас:). Добавил правило Rewrite: `*.dokku.datahub.mother` → `192.168.0.20` (IP моего NAS). Теперь все поддомены (приложения) автоматически ведут на Dokku.

Также для удобства я настроил `~/.ssh/config` на ноутбуке, чтобы не вводить порты вручную:

Host dokku.datahub.mother
  HostName 192.168.0.20
  Port 3022
  User dokku

ну и ключ сам так можно добавить

echo "ВАШ_ПУБЛИЧНЫЙ_КЛЮЧ" | dokku ssh-keys:add dokku

Часть 2. Приложение “my-first-app”: Новогоднее гадание

Для теста я написал простое Flask-приложение, которое рассчитывает ваш возраст в наступающем 2026 году.

Код приложения (`app.py`)

from flask import Flask, request

app = Flask(__name__)

@app.route('/')
def home():
    return """
    <h1>Приветствую в игре Нового 2026 года! 🎉</h1>
    <p>Это веселая интерактивная игра в честь Нового года. Угадай свой возраст на 1 января 2026!</p>
    <p>Введи свой год рождения:</p>
    <form action="/result" method="get">
        <input type="number" name="birth_year" min="1900" max="2025" required>
        <button type="submit">Угадать возраст на Новогодний 2026!</button>
    </form>
    """

@app.route('/result')
def result():
    birth_year = request.args.get('birth_year')
    if not birth_year or not birth_year.isdigit():
        return "Ошибка: введи корректный год рождения!"
    
    birth_year = int(birth_year)
    age_in_2026 = 2026 - birth_year
    return f"""
    <h2>Результат: 🎇</h2>
    <p>В 2026 году тебе будет {age_in_2026} лет!</p>
    <p>Счастливого Нового 2026 года! Пусть все твои желания сбудутся!</p>
    <a href="/">Играть снова</a>
    """

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Подготовка к деплою

Чтобы Dokku понял, как запускать это чудо, нужны два файла в корне проекта:

1. `requirements.txt` (зависимости):

Flask==2.3.2
gunicorn==20.1.0
Werkzeug==2.3.3

2. `Procfile` (команда запуска):

web: gunicorn app:app --bind 0.0.0.0:5000

3. `.python-version` (опционально, явная версия Python):

3.11.14

Процесс деплоя

Все делается через Git, как на “взрослых” платформах:

1. Создаем приложение на сервере:

ssh dokku@dokku.datahub.mother apps:create my-first-app

2. Отправляем код:

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

Если вы до этого еще что-то деплоили, то лучше проверить куда гит смотрит

git remote -v

ну и поменяем еще не верное

git remote remove dokku

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

После пуша Dokku сам скачает Python, установит Flask и запустит Gunicorn. Через минуту-две приложение доступно по адресу `http://my-first-app.dokku.datahub.mother`.

Еще нужно домен установить

ssh dokku@dokku.datahub.mother domains:set my-first-app my-first-app.dokku.datahub.mother

или можно сразу глобально его установить:

ssh dokku@dokku.datahub.mother domains:set-global dokku.datahub.mother
# но тогда придется удалить ручную привязку 
ssh dokku@dokku.datahub.mother domains:clear my-first-app

# не забыть перебрать nginx ( на всякий случай ) 
ssh dokku@dokku.datahub.mother proxy:build-config my-first-app

Сертификат сгенерировать

ssh dokku@dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

и проверить порты

ssh dokku@dokku.datahub.mother ports:report my-first-app

если порты не корректные, то можно их установить так:

ssh dokku@dokku.datahub.mother ports:set my-first-app http:80:5000 https:443:5000

Часть 3. Уровень PRO: Скорость (uv) и Marimo

Аппетит приходит во время еды. После простого Flask-приложения я решил развернуть что-то посерьезнее — Data Science ноутбук на Marimo, и столкнулся с реальными сложностями и особенностями. Для примера брал их дело ноутбук https://marimo.app

1. Ускорение сборки с `uv`

Стандартный `pip` устанавливает пакеты медленно. Если проект большой, деплой может висеть минутами.
Я перешел на uv — новый менеджер пакетов на Rust.

Вместо `requirements.txt` я использовал `pyproject.toml` и `uv.lock`. Dokku (благодаря современным buildpacks) увидел `uv.lock` и переключился на быстрый режим. Время сборки сократилось в разы.

2. Ловушка масштабирования (Scaling)

Marimo — это stateful приложение (хранит состояние в памяти). Flask, который мы делали выше — stateless.

Когда я задеплоил Marimo, Dokku по умолчанию все было хорошо, но потом я решил масштабировать его и сделал так

ssh dokku@dokku.datahub.mother ps:scale my-marimo-app web=3

далее Dokku запустил 3 копии контейнера (`web=3`).
Начался хаос:

• Интерфейс открывался.
• При нажатии кнопок вылетала ошибка `Invalid server token`.

Почему? Браузер загружал страницу с *Контейнера 1*, а WebSocket-запрос улетал в *Контейнер 2*, который ничего не знал про мою сессию.

Решение:
Для интерактивных приложений (Streamlit, Marimo, Jupyter) всегда принудительно ставьте одну реплику:
Ну ли придется делать липкие сессии на nginx или еще что-то.

ssh dokku.datahub.mother ps:scale my-marimo-app web=1 # все вернуло в рабочее состояние.

А если не хватает мощности — лучше дайте этому единственному контейнеру больше ресурсов, чем пытаться плодить клонов или дайте каждому запускать свой:

Вот так можно установить лимиты или повысить их:

ssh dokku.datahub.mother resource:limit my-marimo-app --memory 2G --cpu 2

3. SSL в локальной сети

Браузеры блокируют микрофон и иногда WebSockets на HTTP-сайтах. Для локальной сети Let’s Encrypt не сработает (нет публичного IP), ну и его чуть сложнее запускать.
Я решил вопрос генерацией самоподписанного сертификата одной командой Dokku:

ssh dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

Браузер ругается, но приложение работает полноценно.

Еще я прогнал стресс тесты

ab -n 10000 -k -c 2000 ...

Много они не показали, решением было подкрутить nginx, настроить кеш ssl, горизонтальное масштабирование не приносило больших результатов. я упирался в ограничения клиента при тестах нагрузки.

Итог

Dokku на домашнем сервере — это отличный инструмент.

• Для простых API (Flask/FastAPI): Работает “из коробки” идеально.
• Для сложных задач: Использование `uv` делает работу комфортной, а понимание разницы между *Stateless* и *Stateful* приложениями спасает от занудных ошибок и отладки.

Теперь my-first-app готово предсказывать возраст всем гостям на Новый год, а сервер готов к новым экспериментам! 🎄 Пожалуй оставлю его для будущих экспериментов. Прижился как-то быстро. Кстати у Dokku есть коммерческая PRO версия, а точнее не версия, а полноценный UI с кнопочками и стоит он 900$. https://dokku.com/docs/enterprise/pro/

Пора чего-нибудь накатить новогоднего еще :)

Apache Iceberg V3: Готов ли он?

Автор: Guy Yasoor (Ryft Blog)
Перевод и дополнения: Gemini 3 Pro Preview и я кофе носил

Оригинал: https://www.ryft.io/blog/apache-iceberg-v3-is-it-ready

Выход Apache Iceberg V3 — это огромный шаг вперед для экосистемы лейкхаусов (lakehouse). Спецификация V3 была финализирована и ратифицирована в начале этого года, привнеся в ядро формата несколько долгожданных возможностей: эффективные удаления на уровне строк (row-level deletes), встроенное отслеживание происхождения строк (row lineage), улучшенная обработка полуструктурированных данных и зачатки нативного шифрования.

Этим новым возможностям уделяется много внимания, но в разговорах часто упускают вопрос, который важен не меньше: Насколько V3 готов на практике?

Честный ответ: это полностью зависит от ваших движков обработки данных (engines). Некоторые среды, такие как Spark и Flink, уже хорошо поддерживают V3. Другие — пока отстают.

Основные возможности V3

Deletion Vectors (Векторы удаления)

Векторы удаления прикрепляют информацию об удалении строк непосредственно к файлам данных в виде битовых карт, избегая накопления позиционных файлов удалений (positional delete files).

>**поИИснение:**
>В предыдущих версиях (V2) использовались **Positional Delete Files** — это отдельные Parquet-файлы, содержащие пути и позиции удаленных строк. При чтении (Merge-on-Read) движку приходилось считывать файл данных, считывать файл удалений и делать между ними `JOIN`, чтобы отфильтровать ненужное. Это требует много памяти и ввода-вывода (IO).
>
>**Deletion Vector (V3)** — это, по сути, компактная битовая карта (bitmap), хранящаяся внутри или рядом с файлом данных. Движку достаточно прочитать этот маленький массив битов пропустить удаленные строки "на лету", без дорогостоящих операций слияния. Это критически ускоряет чтение активно изменяемых таблиц.

• Статус:
  • Принято в большинстве движков, реализующих V3.
  • Стабильное чтение/запись в `Apache Spark`, `Apache Flink`.
  • Вероятно, самая готовая к продакшену функция.

Row Lineage (Происхождение строк)

Row lineage вводит стабильные идентификаторы строк и метаданные версий. Это упрощает инкрементальную обработку, CDC, аудит и отладку.

>**поИИснение:**
>Без Row Lineage, если вы обновляете таблицу, строки часто физически перезаписываются, и их "личность" теряется. Чтобы понять, что изменилось, приходилось сравнивать полные копии данных (expensive diff).
>V3 присваивает строкам суррогатные ID. Это позволяет реализовать дешевый CDC (Change Data Capture): вы точно знаете, что "Строка #123" была обновлена, и можете каскадно обновить только связанные с ней агрегаты в витринах данных, вместо пересчета всей витрины.

• Статус:
  • Принято в большинстве движков V3.
  • Достаточно зрелая технология для V3-совместимых стеков.

Тип данных VARIANT

`VARIANT` — это нативный тип для полуструктурированных данных, замена хранению JSON в виде простых строк. Однако текущая поддержка частичная: не хватает “шреддинга” (shredding).

>**поИИснение:**
>В чем суть **Shredding (измельчения)**? Если вы храните JSON как строку (String), базе данных нужно парсить весь JSON для каждого запроса, чтобы достать одно поле `{"user": "Ivan", ...}`. Это медленно.
>Тип `VARIANT` хранит данные в бинарном формате. А **Shredding** — это оптимизация, когда движок замечает, что поле `user` встречается в 95% записей. Он автоматически вытаскивает это поле в отдельную физическую колонку Parquet, сохраняя при этом логическую структуру JSON. Это позволяет читать поле `user` так же быстро, как обычную колонку, но сохранять гибкость схемы (schema evolution), не делая `ALTER TABLE` при добавлении новых полей в JSON.

• Статус:**
  • Поддерживается в Spark, Flink, Databricks SQL.
  • Parquet стандартизирует кодировки, что даст общее представление для оптимизации.

Геопространственные типы и Шифрование

V3 вводит типы для гео-данных и блоки для шифрования на уровне таблицы.

• Статус: Гео-типы доступны через расширения (`Apache Sedona`), шифрование находится на ранней стадии (только Spark/Flink).

Поддержка движками: Где V3 реально работает?

Итог: Переходить ли на V3?

Для большинства: пока нет.
Ключевые игроки (Athena, Trino OSS, Snowflake) не готовы. Переходите, только если ваш стек состоит исключительно из Spark или Flink.

🔮 МненИИе и гаданИИе на кофейной гуще

Прогноз на год вперед

Roadmap: 10 шагов развития

1. Аудит совместимости: Проверить всех потребителей данных. Если есть Athena — V3 откладывается.
2. Переход на REST Catalog: Отказ от Hive Metastore.
   >поИИснение:
   >REST Catalog отвязывает клиента (Spark/Trino) от прямого доступа к файловой системе (S3/HDFS). Это безопаснее (можно выдавать временные креды “Vended Credentials”) и позволяет менять физическое расположение данных, не ломая настройки клиентов.
3. Апгрейд Spark/Flink: Только свежие версии (Spark 3.5+/4.0) умеют работать с V3 корректно.
4. Внедрение “Puffin” статистики:
   >поИИснение:
   >Puffin — это формат файлов-спутников для Iceberg, которые хранят продвинутую статистику, например, эскизы (sketches) для оценки уникальных значений (`count distinct`) без чтения данных. Внедрение этого шага ускоряет планирование запросов.
5. Изолированный пилот: Запуск V3 на одной стриминговой джобе для проверки Deletion Vectors.
6. Оптимизация CDC: Использование Row Lineage для дедупликации потоков.
7. PyIceberg для легких ETL: Замена тяжелых JVM-джоб на Python там, где объемы небольшие.
8. Миграция JSON в VARIANT: Как только движки поддержат шреддинг, это сэкономит гигабайты и часы CPU.
9. Отказ от позиционных удалений: Полное переключение write-конфигурации на векторы.
10. Масштабирование: Перевод основных витрин на V3.

💡 Было бы круто, если бы еще сделали...

Нативную поддержку самоорганизации данных (Z-Order / Clustering) без внешних компакторов.

Почему: Сейчас, чтобы запросы “летали” и пропускали ненужные файлы (data skipping), данные нужно сортировать (Z-Order). Это делают отдельные тяжелые джобы (`maintenance jobs`).
Было бы круто, если бы спецификация позволяла писателям (writers) автоматически поддерживать приближенную кластеризацию при вставке данных (opportunistic clustering), либо если бы формат поддерживал Secondary Indexes (вторичные индексы на основе B-деревьев или Bitmap), хранящиеся прямо в слое метаданных. Это позволило бы Iceberg конкурировать с ClickHouse и Druid в сценариях интерактивной аналитики (sub-second latency), убрав необходимость в постоянном “обслуживании” таблиц.

Для задач AdTech сегментации (профилирование пользователей, identity resolution, поиск look-alike аудиторий) набор требований к графовой базе данных специфичен: нужна высокая скорость операций чтения/записи (real-time bidding/serving) и горизонтальная масштабируемость (миллиарды событий и связей).

Учитывая популярность текущего стека (ClickHouse, Trino, Qdrant), идеальная графовая база должна уметь интегрироваться в аналитический контур (через Trino или прямые коннекторы) и дополнять ClickHouse (который хранит логи событий), взяв на себя хранение топологии связей.

Ниже представлен небольшой обзор и рейтинг Open Source решений на 2024-2025 год с фокусом на масштабируемость.

Рейтинг Open Source Графовых СУБД для AdTech

Разделим 12 решений на 3 эшелона по пригодности для высоконагруженной сегментации.

1 эшелон: Лидеры производительности и масштабирования (Native Distributed)

Эти базы изначально создавались для кластеров и больших объемов данных.

1. NebulaGraph

• Тип: Native Distributed Graph Database.
• Язык запросов: nGQL (SQL-подобный).
• Архитектура: Разделение Compute (GraphD) и Storage (StorageD). Shared-nothing.
• Плюсы для вас: Это топ-1 выбор для AdTech масштаба Tencent или Meituan. Спокойно переваривает сотни миллиардов вершин и триллионы ребер. Обеспечивает миллисекундный отклик при обходе графа (hops) на большую глубину.
• Минусы: Более крутая кривая обучения, чем у Neo4j. Сообщество меньше, но растет.
• Связь со стеком: Отлично дополнит ClickHouse (CH хранит атрибуты, Nebula — связи). Есть коннекторы для Spark/Flink. А через Spark можно дойти до Trino.

2. Dgraph

• Тип: Native Distributed Graph.
• Язык запросов: GraphQL (модифицированный DQL).
• Архитектура: Распределенная, использует BadgerDB (KV store) под капотом. Поддерживает шардинг и репликацию “из коробки” в open source версии.
• Плюсы: Горизонтальное масштабирование. Очень удобна для фронтенд-разработчиков благодаря GraphQL. Высокая пропускная способность.
• Минусы: Специфичный язык запросов, если вы привыкли к SQL/Cypher. В последние годы темпы разработки ядра немного снизились относительно конкурентов.

3. Memgraph

• Тип: In-Memory Graph Database (написана на C++).
• Язык запросов: Cypher (совместим с Neo4j).
• Архитектура: Работает в оперативной памяти (с возможностью сброса на диск).
• Плюсы: Самая быстрая для задач реального времени (вычисление фичей для RTB). Полная совместимость с экосистемой Neo4j (драйверы, протокол Bolt). Поддерживает Python/Rust процедуры. Отличная работа с Streaming данными (Kafka).
• Минусы: Ограничена объемом RAM (хотя есть disk-spill, это снижает скорость).
• Связь со стеком: Отлично стыкуется с моделями AI (Qdrant), так как позиционируется для “Graph AI”.

2 эшелон: Классика и Универсалы

4. Neo4j (Community Edition)

• Тип: Native Graph.
• Язык: Cypher (стандарт индустрии).
• Плюсы: Огромное сообщество, лучшая документация, куча плагинов (APOC).
• Главный минус для AdTech: Open Source версия (Community) ограничена одним узлом. Нет встроенного кластеризации и шардинга (доступно только в Enterprise за большие деньги). Для “технического задела на вырост” в Open Source варианте — это бутылочное горлышко.

5. ArangoDB

• Тип: Multi-model (Graph, Document, Key/Value).
• Язык: AQL (похож на SQL).
• Плюсы: Гибкость. Можно хранить сложные JSON-документы (как в Mongo) и связывать их.
• Минусы: При глубоких обходах графа (“друзья друзей друзей”) проигрывает специализированным Native Graph базам по скорости. Это компромиссное решение.

6. JanusGraph

• Тип: Layered Graph Database.
• Плюсы: Работает поверх мощных бэкендов (Cassandra, HBase, ScyllaDB) и использует Elasticsearch для индексации. Масштабируемость ограничена только бэкендом.
• Минусы: Очень “тяжелая” инфраструктура (JVM based). Сложна в настройке и эксплуатации. Медленнее на простых запросах из-за сетевых хопов между слоями. Часто считается “устаревающей” архитектурой по сравнению с Nebula/Dgraph.

7. Apache AGE (PostgreSQL Extension)

• Тип: Extension.
• Суть: Превращает PostgreSQL в графовую БД с поддержкой Cypher.
• Плюсы: Если вы знаете Postgres, вы знаете AGE. Не нужно новой инфраструктуры.
• Минусы: Производительность ограничена движком Postgres. Сложно масштабировать горизонтально на запись (проблема шардинга PG).

3 эшелон: Нишевые и Новые игроки

8. HugeGraph (Baidu) — аналог JanusGraph, популярен в Китае, очень мощный, но документация местами страдает.
9. OrientDB — мультимодельная, была популярна, но сейчас развитие замедлилось.
10. FalkorDB — форк закрывшегося RedisGraph (Redis module). Очень быстрый, использует разреженные матрицы. Интересен, если уже есть Redis.
11. Cayley — написана на Go (Google), простая, работает с триплетами (Linked Data), но для сложной AdTech логики может не хватить функционала.
12. TerminusDB — интересная база с концепцией “Git для данных”, но специфична для версионирования знаний, а не высоконагруженной сегментации.

Сравнительная таблица (ТОП-7 для выбора)

Интеграция с текущим стеком (Qdrant, Trino или ClickHouse)

1. Qdrant + Graph DB = GraphRAG / Semantic Search:
   • Сегментация пользователей часто требует поиска не только по связям (“кто кликал то же, что и я”), но и по похожести векторов (“чей профиль похож на мой”).
   • Memgraph и **Neo4j имеют встроенные модули для работы с векторами, но так как у вас уже есть Qdrant, вам нужна база, которая *не пытается заменить Qdrant*, а позволяет хранить ID векторов в узлах графа.
   • NebulaGraph** позволяет хранить embedding в свойствах узла, но поиск лучше делегировать Qdrant.

2. Trino:
   • Вам захочется делать SQL-запросы сразу к ClickHouse (события) и Графу (профиль).
   • У Neo4j и NebulaGraph есть коннекторы, позволяющие Trino (через JDBC или нативные коннекторы) запрашивать данные. Это мощнейшая связка для аналитиков. Отдельно нативного конектора к Trino пока не найти, но скоро может появится поддержка iceberg https://github.com/vesoft-inc/nebula/discussions/5902 или пока можно использоваться связку через Spark.

3. ClickHouse:
   • Паттерн: ClickHouse хранит “сырые” логи (миллиарды строк). Агрегаты и связи (User Graph) пересчитываются и заливаются в Графовую БД для быстрого lookup.
   • NebulaGraph** имеет Exchange (инструмент на основе Spark) для массовой заливки данных из Warehouse.

Итоговая рекомендация

Учитывая, что вы хотите Open Source и вам нужен технический задел (масштабирование) для AdTech:

🏆 Выбор №1: NebulaGraph

Это наиболее близкий аналог “ClickHouse в мире графов”.

• Почему:** Он создан для хранения миллиардов вершин (пользователей/устройств) и работы в кластере. У него shared-nothing архитектура, которая необходима для роста. Язык nGQL будет понятен вашим аналитикам, знающим SQL (ClickHouse/Trino).
• Для AdTech:** Идеально решает проблемы *Identity Resolution* (склеивание cookie, device_id, user_id и других атрибутов в единый граф) на больших объемах.

🥈 Выбор №2: Memgraph

Если ваши графы помещаются в память (сотни миллионов узлов, но не десятки миллиардов) и критична задержка (latency) менее 10 мс для *real-time* принятия решений.

• Почему:** Он безумно быстр. Он совместим с Cypher (легко нанимать людей или переезжать с Neo4j). Написан на C++, очень эффективен.
• Интеграция:** Идеально, если вы планируете стримить данные из Kafka, обновлять граф и сразу выдавать сегменты.

🥉 Выбор №3: Apache AGE (или ArangoDB)

Только если объем графа невелик, и вы хотите минимизировать зоопарк технологий, оставаясь в рамках “почти SQL” решений. Но для серьезного AdTech они не рекомендуется как *основное* хранилище графа пользователей.

Совет: Начните пилот (PoC) с NebulaGraph. Попробуйте загрузить туда выгрузку из ClickHouse и сравнить скорость выполнения запросов “найти всех пользователей, связанных через устройство X на глубину 3 шага” с тем, как это делается сейчас (вероятно, через JOINs в реляционке или CH). Если сложность эксплуатации Nebula покажется высокой, можно посмотреть в сторону Memgraph как более легкой альтернативы и применять их не на одном большом графе например, а на нескольких малых в реальном времени, а готовые расчеты уже хранить в привычных местах.

Еще можно почитать:

• Сравнение Memgraph и Neo4j bigdataschool.ru
• Сравнение Neo4j и TigerGraph (для понимания коммерческого рынка bigdataschool.ru
• Обзор графовых БД wiki.merionet.ru

Вот еще мысль и про языки немного. Если проект большой с единым графом для разных нужд, то NebulaGraph выглядит лучшим решением, но архитектурно можно выбрать много средних и малых графов. Для второго подхода хорошо Memgraph с его языком Cypher

1. Семейство Cypher (OpenCypher / ISO GQL)

Базы: *Neo4j, Memgraph, FalkorDB, Apache AGE.*

Cypher — это «SQL для графов». Это декларативный язык, использующий ASCII-арт для визуализации связей в коде (например, `(User)-[:CLICKS]->(Ad)`).

• Функциональность: Очень богатая. Поддерживает сложные паттерны (Pattern Matching), агрегации, пути переменной длины. В апреле 2024 года ISO утвердила стандарт GQL (Graph Query Language), который во многом основан на Cypher.
• Плюсы:
  • Интуитивность: Код читается как предложение на английском. Самая низкая кривая входа.
  • Экосистема: Стандарт де-факто. Если вы знаете Cypher, вы можете переключаться между Neo4j, Memgraph и AGE без переобучения.
  • Выразительность: Идеален для глубокой аналитики и поиска сложных паттернов (Fraud Detection).
• Минусы:
  • Изначально создавался для одноузловых систем. В распределенных системах (шардинг) некоторые конструкции Cypher могут быть сложны для оптимизации движком.
• Оценка для стека:
  • Memgraph/Neo4j: Работает идеально.
  • Apache AGE: Cypher оборачивается внутри SQL запросов Postgres, что немного громоздко, но функционально.
  • FalkorDB: Реализует подмножество Cypher, очень быстро благодаря Redis, но функционал беднее, чем у Neo4j.

2. Семейство Gremlin (Apache TinkerPop)

Базы: *JanusGraph, HugeGraph, OrientDB (частично), Azure CosmosDB.*

Gremlin — это императивный язык обхода графа (Traversals). Вы пишете не «что найти» (как в SQL/Cypher), а «куда идти» шаг за шагом.

• Функциональность: Тьюринговская полнота. Можно написать алгоритм любой сложности прямо внутри запроса. Это скорее язык программирования потоков данных, чем язык запросов.
• Плюсы:
  • Контроль: Вы точно указываете базе, как обходить граф. Это важно для сверхбольших графов (как в JanusGraph/HugeGraph), где неверный план запроса может “положить” кластер.
  • Абстракция: Работает поверх любой БД, поддерживающей TinkerPop.
• Минусы:
  • Сложность: Кривая обучения очень крутая. Код получается вербозным и сложным для отладки («write once, read never»).
  • Устаревание: С появлением стандарта ISO GQL популярность Gremlin падает. Для новых проектов в 2025 году его выбирают редко, если только не привязаны к JanusGraph.
• Пример AdTech: «Найти всех пользователей, кликнувших на этот баннер» на Gremlin будет длинной цепочкой вызовов методов (`g.V().has(‘Banner’...).out(‘CLICKS’)...`).

3. nGQL (NebulaGraph Query Language)

Базы: *NebulaGraph.*

Собственный язык Nebula, который синтаксически мимикрирует под SQL, но логически работает с графами.

• Функциональность: Заточена под распределенный Massive Parallel Processing (MPP).
• Плюсы:
  • SQL-подход: Разработчикам, привыкшим к MySQL/ClickHouse, синтаксис `GO FROM ... OVER ...` будет понятнее, чем Gremlin.
  • Скорость: Спроектирован так, чтобы не позволять писать «плохие» запросы, которые убивают распределенный кластер. Вынуждает думать о том, где лежат данные (VID).
  • Пайпы: Удобный синтаксис передачи результата одного шага в другой через `|` (как в Bash).
• Минусы:
  • Vendor Lock-in: Это не стандарт. Переехать с Nebula на другую базу потребует переписывания всех запросов.
  • Не поддерживает полную гибкость Pattern Matching, как Cypher (хотя добавили поддержку `MATCH`, она менее производительна, чем нативный `GO`).

4. DQL (ранее GraphQL+-)

Базы: *Dgraph.*

Это модифицированный GraphQL.

• Функциональность: Идеальна для API. Вы запрашиваете данные в формате JSON-дерева, и база возвращает JSON.
• Плюсы:
  • Frontend-first: Фронтендерам не нужен бэкенд-прослойка, они могут (теоретически) ходить в базу почти напрямую.
  • Работа с атрибутами: Поскольку Dgraph — это по сути распределенный Key-Value, DQL очень быстро достает атрибуты нод.
• Минусы:
  • Слабая аналитика: Графовые алгоритмы и сложные обходы (traversals) на DQL писать сложнее и менее эффективно, чем на Cypher/nGQL. Это язык выборки данных, а не язык аналитики графов.

5. AQL (ArangoDB Query Language)

Базы: *ArangoDB.*

Гибридный язык, объединяющий возможности SQL (JOINs), работы с JSON (как в Mongo) и графовых обходов.

• Функциональность: Одна из самых мощных среди “универсалов”. Позволяет в одном запросе сделать JOIN трех коллекций, отфильтровать JSON и пройтись по графу друзей.
• Плюсы: Гибкость.
• Минусы: Синтаксис `FOR u IN users FILTER ...` специфичен и многословен. Для чистых графовых задач (deep hopping) он медленнее нативных решений [ArangoDB vs Native Graph].

6. Другие / Устаревающие

• OrientDB (SQL-extended): Пытались расширить SQL для графов. Сейчас проект стагнирует, язык считается тупиковой ветвью эволюции по сравнению с Cypher/GQL.
• SQL Graph (MS SQL / PG SQL): В [статье про SQL Server](https://learn.microsoft.com/ru-ru/sql/relational-databases/graphs/sql-graph-sample?view=sql-server-ver17) показан синтаксис `MATCH`, который Microsoft внедрила в T-SQL. Это попытка “догнать” Cypher, оставаясь в рамках реляционной модели. Удобно, если вы намертво привязаны к MS SQL, но неудобно для сложной аналитики.
• Cayley (Gizmo/MQL): Очень нишевый язык на базе Go или JS. Для AdTech продакшена слишком экзотичен.

Сводная таблица сравнения

Итоговая рекомендация

1. Если приоритет — производительность на масштабе (AdTech, сегментация 100M+ пользователей):
   Вам нужен NebulaGraph и его nGQL.
• *Почему:* В AdTech сценариях (как у Meituan/Tencent) критичны latency на “хопах” (hops). nGQL архитектурно заставляет писать запросы так, чтобы они эффективно параллелились. Он менее удобен, чем Cypher, но более предсказуем в нагрузке.

2. Если приоритет — Real-time аналитика, ML-фичи и скорость разработки:
   Вам нужен Memgraph на Cypher.
• *Почему:* Вы получаете совместимость с самой популярной экосистемой (Neo4j), стандартный язык Cypher (легко найти специалистов) и скорость C++ in-memory движка.

3. Если приоритет — дешевое горизонтальное масштабирование “для бедных” (в хорошем смысле):
   Вам нужен Dgraph (DQL) или NebulaGraph.
• У Dgraph отличный шардинг из коробки и DQL закрывает 90% задач продуктовой разработки, но может буксовать на тяжелой аналитике.

От чего стоит отказаться:

• Neo4j Community: Язык Cypher прекрасен, но ограничения лицензии (отсутствие кластера) убьют проект на росте.
• JanusGraph/HugeGraph (Gremlin): В 2025 году начинать проект на Gremlin — это создавать себе технический долг, так как индустрия движется в сторону ISO GQL (Cypher Style).
• Apache AGE: Пока слишком сыро для High-load, проблемы с горизонтальным масштабированием Postgres никуда не деваются.