- \n
- Табличная структура:** Данные хранятся как таблицы (Log Tables для логов и PK Tables для изменяемых данных), что обеспечивает строгую типизацию.<\/li>\n
- Колоночное хранение:** Использование формата Apache Arrow позволяет читать только нужные колонки (projection pushdown) и эффективнее сжимать данные, что снижает нагрузку на диск и сеть.<\/li>\n
- Интеграция с Lakehouse:** Fluss нативно поддерживает многоуровневое хранение (горячие данные в Fluss, теплые\/холодные в S3\/Iceberg\/Paimon) без лишнего копирования, обеспечивая прозрачный доступ к историческим и оперативным данным.<\/li>\n<\/ul>\n<\/li>\n
- Вывод:<\/b> Fluss в связке с Flink предлагает более дешевую, быструю и удобную архитектуру для современной аналитики реального времени, устраняя недостатки Kafka в этой области.<\/li>\n<\/ol>\n
Ссылка на оригинал:<\/b>
\nWhy Kafka Falls Short for Real-Time Analytics (and What Comes Next<\/a><\/p>\nУ Apache Kafka был замечательный период: она обеспечивала работу событийно-ориентированных архитектур более десяти лет. Но ландшафт изменился, обнажив явные ограничения Kafka для аналитики в реальном времени<\/b> по мере того, как сценарии использования современной потоковой аналитики<\/b> и принятия решений становятся всё более требовательными. Kafka все чаще пытаются заставить выполнять функции в архитектуре аналитики реального времени<\/b>, для поддержки которых она никогда не проектировалась. Чтобы решить сегодняшние проблемы конвейеров потоковой передачи данных и аналитические требования, необходимы новые возможности. Пришло время для «новичка на районе».<\/p>\n
Во время перехода от пакетной обработки к потоковой передаче данных в реальном времени<\/b> значительное внимание и импульс получил проект с открытым исходным кодом, разработанный внутри LinkedIn: Apache Kafka<\/b>. Цель состояла в том, чтобы упростить перемещение данных из точки А в точку Б масштабируемым и устойчивым способом, используя модель издатель\/подписчик. Kafka позволила компаниям создавать ранние конвейеры потоковой передачи данных<\/b> и открыть новый класс событийно-ориентированных сценариев использования. Постоянно растущая экосистема коннекторов и интеграций ускорила внедрение и утвердила Kafka в качестве предпочтительного слоя потокового хранения<\/b>. Однако, по мере того как архитектуры аналитики реального времени<\/b> эволюционировали за пределы простого приема данных (ingestion), ограничения Kafka для аналитических нагрузок становились всё более очевидными.<\/p>\n
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-233.png\")
\n<\/div>\nС архитектурной точки зрения Kafka — это не аналитический движок. Это устойчивая и масштабируемая система хранения на основе записей (record-based storage system)<\/b> для свежих данных в реальном времени — часто называемая «горячим слоем». Следовательно, аналитические нагрузки должны выполняться за пределами кластера Kafka, постоянно перемещая данные между системами хранения и обработки, что увеличивает сетевой трафик и накладные операционные расходы. Кроме того, Kafka нативно не обеспечивает соблюдение схем для данных, публикуемых в топиках.<\/p>\n
Хотя эта гибкость была приемлема для ранних сценариев использования потоковой передачи, современные платформы аналитики реального времени<\/b> требуют схем для обеспечения согласованности, управления и качества данных. В качестве компенсации появились реестры схем (Schema Registries) для обеспечения контрактов между издателями и подписчиками, добавляя сложности аналитическим архитектурам на основе Kafka.<\/p>\n
И последнее, но не менее важное (и, возможно, самый важный аспект): Kafka — это система хранения на основе записей. Это хорошо подходит для использования в качестве очереди сообщений, например, для приема данных в реальном времени или событийно-ориентированных архитектур, но имеет значительные ограничения при решении текущих и будущих задач проектов реального времени. Движки обработки, такие как Spark и Flink, должны потреблять все данные топика, даже если требуется только часть данных события (столбцы). Результатом является ненужный сетевой трафик, снижение производительности обработки и чрезмерные требования к хранилищу.<\/p>\n
Компоненты потокового хранения на основе записей по-прежнему будут занимать свое место в архитектуре данных. Такие решения, как Kafka и Pulsar, хорошо подходят для случаев, требующих чтения полных записей. Архитектурные паттерны, основанные на микросервисах, могут использовать вышеуказанные решения для обмена данными, отделяя функции от транспортировки сообщений для повышения производительности, надежности и масштабируемости. Чтение полных записей также полезно для конвейеров приема данных (ingestion pipelines), в которых данные будут храниться в системах долгосрочного хранения, таких как объектное хранилище (Object Storage), для исторических и архивных целей. Узкие места и ограничения возникают, когда они используются для аналитических нагрузок, требующих возможностей, выходящих за рамки простого слоя транспорта данных.<\/p>\n
Эволюция потоковых данных<\/h3>\n
Сегодняшний разговор движим единственным аспектом: Эволюция. Другими словами, новые потребности требуют новых подходов к управлению данными. Kafka удовлетворила первоначальные потребности в потоковой передаче данных. В этой первой волне в основном доминировали конвейеры приема данных в реальном времени и дискретная (SEP, Simple Event Processing) аналитика. По сути, способность перемещать данные из точки А в точку Б и, в некоторых случаях, выполнять простую подготовку и обработку данных между ними. Kafka, в сочетании со Spark Streaming или специальными коннекторами, справлялась с этими ранними сценариями использования.<\/p>\n
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-234.png\")
\n<\/div>\nПеренесемся вперед: вторая волна привнесла сложность в потоковый конвейер. Помимо дискретной подготовки данных, сценарии использования на этом этапе требовали расширенных аналитических функций, таких как агрегация, обогащение и сложная обработка событий (CEP). Микро-батчинг (micro-batching) оказался недостаточным. Требуется новый архитектурный подход, основанный на колоночном хранении с эффективным проталкиванием проекций (projection pushdown) и прозрачным многоуровневым хранением данных (data tiering), в сочетании с движками обработки с задержкой менее секунды. `Apache Fluss` и `Apache Flink` могут выполнить это обещание и вместе составляют будущее и третью волну по шкале зрелости.<\/p>\n
Каждая техническая статья сегодня упоминает AI\/ML. Эта эволюция «третьей волны» позволяет компаниям создавать AI-конвейеры реального времени, которые внедряют передовые аналитические методы (такие как Generative AI) в потоковые данные. Это увеличивает потребность в современных системах хранения данных в реальном времени с расширенными функциями, которые распределяют данные как по быстрым потоковым, так и по историческим слоям, обеспечивая интегрированный, унифицированный доступ к бизнес-данным.<\/p>\n
Новичок на районе<\/h3>\n
`Apache Fluss` — это современная система хранения потоковых данных в реальном времени для аналитики. Она консолидирует многолетний опыт и уроки, извлеченные из предшественников, отвечая текущим и будущим потребностям организаций. Fluss родился в эпоху, когда для питания моделей машинного обучения требуется больше данных, Лейкхаусы (Lakehouses) являются частью корпоративной экосистемы, а облачная инфраструктура является предпочтительной стратегией для компаний.<\/p>\n
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-02-15-v-13.48.31.png\")
\n<\/div>\nНо хранение данных — это лишь часть архитектурной головоломки. `Apache Flink` предоставляет возможности и устойчивость для обработки огромных объемов данных в реальном времени с задержкой менее секунды, обеспечивая скорость, необходимую для будущих потоковых приложений. Не ограничиваясь Flink, дополнительные движки обработки и библиотеки разрабатывают интеграции с Fluss, тем самым укрепляя экосистему.<\/p>\n
Ниже приведены основные функции современной аналитики реального времени.<\/p>\n
Поток как таблица (Stream as Table)<\/h4>\n
Fluss хранит данные как схематизированные таблицы. Этот подход подходит для большинства сценариев использования в реальном времени, включая те, которые опираются как на структурированные, так и на полуструктурированные данные. Структурируя потоковые данные, компании могут улучшить управление, повысить качество данных и гарантировать, что издатели и потребители используют общий язык. Fluss определяет два типа таблиц:<\/p>\n
- \n
- Log Tables (Лог-таблицы)** работают только на добавление (append-only), аналогично топикам Kafka. Такие сценарии использования, как мониторинг логов, кликстримы (clickstreams), показания датчиков, журналы транзакций и другие, являются хорошими примерами данных только для добавления. События неизменяемы и не должны изменяться или обновляться.<\/li>\n
- Primary Key (PK) Tables (Таблицы с первичным ключом)** — это изменяемые таблицы, определенные ключом. Записи сначала вставляются, а затем обновляются или удаляются с течением времени в соответствии с журналом изменений (changelog), который они представляют. Таблица PK хранит последние изменения всей таблицы, обеспечивая паттерн доступа «поиск записи» (record lookup). Сценарии использования журнала изменений, такие как балансы счетов, корзина покупок и управление запасами, могут извлечь выгоду из этого подхода. Kafka не может выполнять такое поведение, требуя внешних баз данных типа «ключ-значение» или NoSQL для отслеживания текущего статуса записи, что приводит к сложным и трудным в обслуживании решениям.<\/li>\n<\/ul>\n\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-235.png\")
\n<\/div>\nВкратце, PK Tables обеспечивают уникальность записей на основе первичного ключа, операций `INSERT`, `UPDATE` и `DELETE`, а также предоставляют широкие возможности изменения записей. С другой стороны, Log Tables работают только на добавление; обновления записей не требуются.<\/p>\n
Колоночное хранение (Columnar Storage)<\/h4>\n
То, как Fluss хранит данные на диске, возможно, является наиболее фундаментальным архитектурным сдвигом по сравнению с другими решениями. В отличие от Kafka, Fluss использует формат `Apache Arrow` для хранения данных в колоночном формате, что дает следующие преимущества:<\/p>\n
- \n
- Улучшенное использование хранилища**, так как хранение данных в колоночном формате требует меньше дискового пространства. Степень сжатия зависит от множества характеристик данных, но первоначальные тесты показывают многообещающее улучшение в 5 раз при использовании Apache Arrow в качестве базового формата хранения. Меньше хранилища = меньше затрат. Kafka предоставляет лишь несколько вариантов сжатия данных, которые не сравнимы с теми, что доступны в Apache Arrow «из коробки».<\/li>\n
- Эффективные запросы с использованием обрезки столбцов (column pruning).** В общем случае запрашивается или доступно менее половины атрибутов данного бизнес-события, т.е. только те имена столбцов, которые вы добавляете в ваше выражение `SELECT FROM`. Проталкивание проекции (projection pushdown) — это метод, который удаляет ненужные атрибуты (также известный как column pruning) при извлечении данных из системы хранения. Kafka работает по принципу «все или ничего» из-за своего формата хранения на основе записей.<\/li>\n
- И колоночное сжатие, и проталкивание проекции улучшат сетевой трафик — перемещение меньшего количества данных приведет к тому, что сетевые администраторы станут счастливее. С Kafka компании постоянно сталкиваются с перегрузкой сети и потенциально высокими расходами на исходящий трафик (egress costs).<\/li>\n<\/ul>\n\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-236.png\")
\n<\/div>\nУнификация с Lakehouse<\/h4>\n
Kafka была создана в эпоху Data Lake (Озер данных). С самого начала проектирования Fluss создавался для Lakehouse. Это создает большую разницу. Компании поняли, что Озера данных (или во многих случаях «Болота данных» — Data Swamps) трудно поддерживать в рабочем состоянии и окупать инвестиции в лицензии, оборудование и персонал для создания решений больших данных. К счастью, Лейкхаусы преодолевают эти проблемы. Лейкхаусы утверждают, что данные должны быть широко и легко доступны независимо от их возраста. Пакетные события и события реального времени перекрываются, и движки обработки должны иметь возможность прозрачно обращаться к обоим слоям.<\/p>\n
Вот возможности тиринга данных (распределения по уровням) и унифицированного просмотра, которые может предоставить Fluss, в дополнение к слою горячих\/свежих данных:<\/p>\n
- \n
- Теплый слой (Warm layer):** для данных возрастом от минут до часов, в основном хранящихся в решениях объектного хранения (Object Storage).<\/li>\n
- Холодный слой (Cold layer):** для данных возрастом от дней до лет. Решения Lakehouse, такие как `Apache Paimon` и `Iceberg`, являются предпочтительными платформами для этих исторических данных, питающих модели ML, ретроспективную аналитику и комплаенс.<\/li>\n
- Zero-copy data tiering (Тиринг данных без копирования):** старение данных из горячего слоя (таблицы Fluss) в теплые\/холодные слои (Object Storage и Lakehouse). Это означает, что доступна единственная копия единицы данных, либо в слое реального времени, либо в историческом слое. Fluss управляет переключением между слоями, облегчая запросы и доступ. Подход Kafka опирается на дублирование данных с помощью задания потребителя\/издателя, что приводит к увеличению затрат на хранение и необходимости конвертировать топики Kafka в табличный формат Lakehouse.<\/li>\n<\/ul>\n\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-237.png\")
\n<\/div>\nСветлое будущее впереди<\/h3>\n
Аналитика данных в реальном времени становится краеугольным камнем современных компаний. Цифровые бизнес-модели должны обеспечивать лучший пользовательский опыт и своевременные ответы на взаимодействия с клиентами, что заставляет компании создавать системы для использования и управления данными в реальном времени, создавая увлекательный и впечатляющий («wow») опыт. Действовать сейчас — это не просто вопрос технической осуществимости; для большинства предприятий это становится уникальным преимуществом для выживания в высококонкурентной глобальной рыночной среде.<\/p>\n
Fluss помогает компаниям преодолеть разрыв между мирами реального времени и аналитики, предлагая унифицированный доступ как к свежим данным в реальном времени, так и к историческим, холодным данным. Вкратце, Fluss обеспечивает беспрепятственный доступ к данным независимо от возраста набора данных и упрощает сложные архитектуры аналитики данных, которые тянулись годами, в основном из-за отсутствия наиболее подходящих компонентов и фреймворков.<\/p>\n
В то время как Fluss служит слоем хранения в реальном времени для аналитики, Лейкхаусу предоставляется управление, простота и масштабируемость, которые защищают современные архитектуры в будущем.<\/p>\n
С операционной стороны он предлагает значительные преимущества за счет снижения сложности управления, хранения и обслуживания как данных реального времени, так и пакетных данных. Эта эффективность трансформируется в прямую экономию средств, достигаемую в первую очередь за счет оптимизированного формата таблиц Fluss, двухуровневой системы хранения, основанной на температуре данных, и, наконец, минимизации общего использования ЦП конвейера с помощью проталкивания предикатов (predicate pushdown) и обрезки столбцов. В совокупности эти архитектурные элементы снижают накладные операционные расходы, связанные с обслуживанием платформы, ускоряют внедрение новых сценариев использования и облегчают бесшовную интеграцию с существующей ИТ-инфраструктурой предприятия.<\/p>\n", "date_published": "2026-02-12T13:50:00+03:00", "date_modified": "2026-02-15T13:51:18+03:00", "tags": [ "big data", "Data", "Data Engineer", "Data Governance", "Streaming" ], "image": "https:\/\/gavrilov.info\/pictures\/image-233.png", "_date_published_rfc2822": "Thu, 12 Feb 2026 13:50:00 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "318", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/gavrilov.info\/pictures\/image-233.png", "https:\/\/gavrilov.info\/pictures\/image-234.png", "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-02-15-v-13.48.31.png", "https:\/\/gavrilov.info\/pictures\/image-235.png", "https:\/\/gavrilov.info\/pictures\/image-236.png", "https:\/\/gavrilov.info\/pictures\/image-237.png" ] } }, { "id": "278", "url": "https:\/\/gavrilov.info\/all\/sozdaem-streaming-lakehouse-za-chas-rukovodstvo-po-risingwave-la\/", "title": "Создаем Streaming Lakehouse за час: руководство по RisingWave, Lakekeeper и Trino", "content_html": "
Вы когда-нибудь мечтали о платформе, где данные, отправленные через простой API-вызов, через секунды становятся доступны для аналитических запросов в вашем озере данных? Мечты сбываются. Эта статья — подробное, основанное на реальном опыте руководство, которое покажет, как построить современный Streaming Lakehouse с нуля.<\/p>\n
Доки, которые пригодились:<\/p>\n
https:\/\/github.com\/risingwavelabs\/risingwave\/blob\/main\/docker\/docker-compose.yml<\/a>
\nhttps:\/\/github.com\/lakekeeper\/lakekeeper\/blob\/main\/examples\/minimal\/docker-compose.yaml<\/a>
\nhttps:\/\/docs.risingwave.com\/iceberg\/deliver-to-iceberg#rest-catalog<\/a><\/p>\nНаши главные герои:<\/p>\n
- \n
- RisingWave<\/b>: Потоковая база данных, “сердце” нашего пайплайна. Она будет принимать, преобразовывать и материализовывать данные на лету.<\/li>\n<\/ul>\n\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-212.png-1.jpg\")
\n<\/div>\n- \n
- Lakekeeper<\/b>: Современный REST-каталог для Apache Iceberg. Наш “библиотекарь”, который знает все о структуре данных в озере.<\/li>\n<\/ul>\n\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.37.28.png\")
\n<\/div>\n- \n
- Trino<\/b>: Мощный движок для федеративных запросов. Наше “окно” в озеро данных для выполнения ad-hoc аналитики.<\/li>\n<\/ul>\n\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.39.34.png\")
\n<\/div>\nМы пройдем весь путь: от сравнения технологий и настройки окружения до отправки данных и любования результатами на дашбордах Grafana. И самое главное — мы поделимся всеми “граблями”, на которые наступили, чтобы вы могли их обойти.<\/p>\n
Глава 1: Почему RisingWave? Взгляд на альтернативы<\/h3>\n
На рынке потоковой обработки есть много инструментов, но все они предлагают разные подходы. Почему для нашей задачи мы выбрали именно RisingWave?<\/p>\n
RisingWave<\/b> — это распределенная потоковая база данных, созданная для упрощения обработки данных в реальном времени. Ее ключевая особенность — использование материализованных представлений поверх потоков данных. Вы пишете знакомый SQL, а RisingWave берет на себя всю сложную работу по инкрементальному обновлению результатов с минимальной задержкой.<\/p>\n
Давайте сравним его с популярными альтернативами.<\/p>\n
Сравнительная таблица<\/h4>\n
- Trino<\/b>: Мощный движок для федеративных запросов. Наше “окно” в озеро данных для выполнения ad-hoc аналитики.<\/li>\n<\/ul>\n
- Lakekeeper<\/b>: Современный REST-каталог для Apache Iceberg. Наш “библиотекарь”, который знает все о структуре данных в озере.<\/li>\n<\/ul>\n
- RisingWave<\/b>: Потоковая база данных, “сердце” нашего пайплайна. Она будет принимать, преобразовывать и материализовывать данные на лету.<\/li>\n<\/ul>\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.22.20.png.jpg\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.18.25.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.50.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.44.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.35.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.17.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.19.57.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.19.06.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.18.58.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.18.53.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.54.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-11-09-v-17.31.56.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-11-09-v-17.33.31.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-11-09-v-17.34.29.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-11-09-v-17.35.37.png\")
\n<\/div>\n",
"date_published": "2025-09-06T23:03:00+03:00",
"date_modified": "2025-11-09T17:38:42+03:00",
"tags": [
"Data",
"Lakehouse",
"Streaming"
],
"image": "https:\/\/gavrilov.info\/pictures\/image-212.png-1.jpg",
"_date_published_rfc2822": "Sat, 06 Sep 2025 23:03:00 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "278",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css",
"jquery\/jquery.js",
"fotorama\/fotorama.css",
"fotorama\/fotorama.js"
],
"og_images": [
"https:\/\/gavrilov.info\/pictures\/image-212.png-1.jpg",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.37.28.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.39.34.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.22.20.png.jpg",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.18.25.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.50.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.44.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.35.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.17.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.19.57.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.19.06.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.18.58.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.18.53.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-06-v-22.20.54.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-11-09-v-17.31.56.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-11-09-v-17.33.31.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-11-09-v-17.34.29.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-11-09-v-17.35.37.png"
]
}
}
],
"_e2_version": 4171,
"_e2_ua_string": "Aegea 11.4 (v4171e)"
}