Последние сообщения

Артем Матвеев
Артем Матвеев
  • Сообщений: 3
  • Последний визит: 27 марта 2025 в 20:58

Глубокое погружение: Тестирование монолитных приложений

Преимущества:

— Простота начального этапа: На ранних стадиях разработки монолита тестирование относительно простое. Все находится в одном месте, упрощая отладку и интеграционное тестирование.

— Быстрое сквозное тестирование: Поскольку весь код находится в одном месте, сквозное тестирование (end-to-end testing) может быть выполнено относительно быстро.

Недостатки:

— Сложность с ростом проекта: По мере роста приложения, тестирование становится все более сложным и трудоемким. Изменение одной части кода может привести к неожиданным последствиям в других частях.

— Замедление процесса разработки: Длительное тестирование может существенно замедлить процесс разработки.

— Зависимости и конфликты: Тесное взаимодействие компонентов приводит к множеству зависимостей и потенциальных конфликтов, затрудняющих тестирование и отладку.

— Трудоемкая рефакторинг: Изменение архитектуры или отдельных модулей в большом монолите может потребовать огромных усилий и времени.

— Проблемы с масштабированием: Масштабирование монолита — это масштабирование всего приложения целиком, что может быть неэффективным и дорогим.

Тестирование микросервисной архитектуры

Преимущества:

— Изолированное тестирование: Каждый микросервис может быть протестирован независимо от других. Это ускоряет процесс и упрощает поиск ошибок.

— Параллельное тестирование: Возможность параллельного тестирования значительно ускоряет весь процесс.

— Гибкость и масштабируемость: Можно масштабировать только те сервисы, которые нуждаются в дополнительных ресурсах.

— Более быстрая обратная связь: Быстрое тестирование и развертывание позволяют получать более быструю обратную связь от пользователей.

Недостатки:

— Сложность интеграционного тестирования: Необходимо тщательно тестировать взаимодействие между микросервисами. Это требует дополнительных усилий и инструментов.

— Увеличение сложности инфраструктуры: Микросервисная архитектура требует более сложной инфраструктуры и инструментов для оркестрации, мониторинга и управления.

— Повышенные требования к квалификации: Разработка и тестирование микросервисов требуют от разработчиков более высокой квалификации и опыта.

— Увеличение числа точек отказа: Большее количество сервисов увеличивает потенциальное число точек отказа.

Когда монолит, а когда микросервисы?

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

Монолит подходит для:

— Простых проектов: Когда функциональность ограничена и масштабируемость не является критическим фактором.

— Быстрой разработки прототипов: Когда нужно быстро создать минимально жизнеспособный продукт (MVP).

— Небольших команд: Когда команда небольшая и обладает ограниченными ресурсами.

Микросервисы подходят для:

— Больших и сложных проектов: Когда функциональность обширна и требуется высокая гибкость и масштабируемость.

— Проектов с высокой частотой изменений: Когда необходимо часто обновлять и развертывать новые функции.

— Больших команд: Когда команда большая и разделена на независимые группы.

Разница в деталях: Монолит vs. Микросервисы

Ключевое отличие — связность. Монолит — это единый блок кода. Микросервисы — это набор независимых, слабо связанных модулей. Это влияет на все аспекты, от разработки до тестирования и развертывания. Изменение в монолите может затронуть всю систему. В микросервисах изменения локализованы.

Виталий Синицын
Виталий Синицын
  • Сообщений: 9
  • Последний визит: 10 февраля 2025 в 15:21

Вопрос о том, что проще тестировать – монолитное приложение или систему микросервисов – не имеет однозначного ответа. Он зависит от множества факторов, включая размер и сложность системы, опыт команды разработчиков и доступные ресурсы.

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

Микросервисы, напротив, предлагают большую гибкость и масштабируемость. Каждый сервис представляет собой независимую единицу, которую можно тестировать изолированно. Это упрощает локальное тестирование и отладку. Однако, тестирование взаимодействия между сервисами становится более сложным. Необходимо учитывать различные сценарии взаимодействия, сетевые задержки и потенциальные отказы отдельных сервисов. Для полноценного тестирования системы микросервисов требуется разработка интеграционных тестов, что может потребовать больше времени и ресурсов.

В конечном счете, выбор между монолитом и микросервисами зависит от конкретных требований проекта. Если проект небольшой и не предполагает существенного роста функциональности, монолит может быть более подходящим выбором. Если же проект масштабный и требует гибкости и масштабируемости, микросервисы – более предпочтительный вариант. Однако, стоит помнить, что тестирование микросервисной архитектуры требует более комплексного подхода и специальных инструментов. Важно взвесить все «за» и «против» и выбрать архитектуру, которая наилучшим образом соответствует целям и задачам проекта.

Евгений Абрамов
Евгений Абрамов
  • Сообщений: 17
  • Последний визит: 5 апреля 2025 в 19:25

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

— Выбор партнёров по доставке: определите, с какими транспортными компаниями или курьерскими службами вы будете сотрудничать. Оцените их надёжность, тарифы и условия сотрудничества.

— Создание системы отслеживания заказов: разработайте систему, позволяющую отслеживать статус доставки каждого заказа для клиентов и сотрудников.

— Интеграция с платёжными системами: подключите свою торговую площадку к платёжным системам, чтобы покупатели могли оплачивать заказы онлайн.

— Настройка уведомлений о статусе доставки: настройте автоматические уведомления для покупателей о статусе их заказа, например, отправка, в пути, доставлено.

— Обработка возвратов и обменов: предоставьте клиентам возможность вернуть или обменять товары, если они не удовлетворены качеством или характеристиками товара.

— Управление запасами: отслеживайте наличие товаров на складе и своевременно пополняйте запасы, чтобы избежать задержек в доставке.

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

— Мониторинг рынка и оптимизация процессов: постоянно анализируйте рынок и оптимизируйте процессы доставки, чтобы улучшить качество обслуживания клиентов и снизить издержки.

Евгений Абрамов
Евгений Абрамов
  • Сообщений: 17
  • Последний визит: 5 апреля 2025 в 19:25

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

— Выбор партнёров по доставке: определите, с какими транспортными компаниями или курьерскими службами вы будете сотрудничать. Оцените их надёжность, тарифы и условия сотрудничества.

— Создание системы отслеживания заказов: разработайте систему, позволяющую отслеживать статус доставки каждого заказа для клиентов и сотрудников.

— Интеграция с платёжными системами: подключите свой маркетплейс к платёжным системам, чтобы покупатели могли оплачивать заказы онлайн.

— Настройка уведомлений о статусе доставки: настройте автоматические уведомления для покупателей о статусе их заказа, например, отправка, в пути, доставлено.

— Обработка возвратов и обменов: предоставьте клиентам возможность вернуть или обменять товары, если они не удовлетворены качеством или характеристиками товара.

— Управление запасами: отслеживайте наличие товаров на складе и своевременно пополняйте запасы, чтобы избежать задержек в доставке.

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

— Мониторинг рынка и оптимизация процессов: постоянно анализируйте рынок и оптимизируйте процессы доставки, чтобы улучшить качество обслуживания клиентов и снизить издержки.

Ирина Деникеновна
Ирина Деникеновна
  • Сообщений: 8
  • Последний визит: 5 апреля 2025 в 11:20

Организация доставки при запуске маркетплейса

Вы решили запустить свой маркетплейс, и первый шаг в этом направлении — выбрать платформу для его создания. На российском рынке одной из самых популярных платформ является DST Маркетплейс, наряду с такими решениями, как Битрикс, CS Cart и Agora. Выбор правильной платформы — это основа успешного бизнеса, так как она должна соответствовать вашим требованиям и ожиданиям.

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

Организация доставки при запуске маркетплейса на DST Маркетплейс включает в себя несколько этапов. Во-первых, необходимо выбрать надежных логистических партнеров, которые смогут обеспечить быструю и качественную доставку товаров. Это может быть как работа с курьерскими службами, так и сотрудничество с транспортными компаниями для более крупных грузов.

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

Кроме того, не забывайте о маркетинге. Правильное продвижение вашего маркетплейса и его логистических возможностей может существенно повысить интерес клиентов и увеличить объемы продаж.

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

Правильно организованная доставка

Как правило, в платформу на базе которой вы создаете маркетплейс, уже интегрированы несколько видов доставки. Например, в DST Маркетплейс вы найдете множество разных вариантов, включая возможность подключения собственной системы доставки. Это позволяет вам адаптировать логистику под специфические нужды вашего бизнеса и клиентов.

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

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

Непроработанная система логистики

Непроработанная система логистики несет дополнительные затраты, которые делают работу владельца маркетплейса и продавцов невыгодной. Расходы на содержание или управление движением товаров зачастую занимают более 50% издержек.

Так, например, если вы выбираете формат ручного управления логистикой, то затраты будут выглядеть так:

Оформление заказов вручную = Зарплата сотрудника + ограниченное количество часов в сутки. Такой подход ограничивает скорость оформления и обработки, что, в свою очередь, уже может повлиять на лояльность покупателей при большом потоке.

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

Какой бывает доставка у маркетплейсов

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

— DBS (Delivery by Seller) — упаковка и доставка силами продавца. Продавец хранит товар у себя, собирает заказ и доставляет покупателю. В этом типе доставки сложно организовать контроль. А отсюда вырастают большие репутационные риски для владельцев площадки.

— FBO Fulfilment by Operator (Фулфилмент — это комплекс операций с товаром с момента оформления заказа покупателем до момента получения покупки). В данном случае, хранение товаров, упаковку и доставку берет на себя маркетплейс. Ощутимый плюс здесь — низкие трудозатраты — нужно просто отвезти товары на склад маркетплейса и заниматься генерацией продаж.

— FBOs Fulfilment by Operator — отложенная поставка товаров под созданные заказы. Актуально для сезонной продукции, которую нет смысла хранить на складе. Продавец получает уведомления о заказе, подтверждает передает в доставку или же оперативно подготавливает и привозит товар на фулфилмент склад маркетплейса. Преимущество в том, что продавец может дополнительно продавать один и тот же товар через другие каналы.

— FBS Fulfilment by Seller Plus — “последняя миля”. Продавец после продажи сам собирает заказ и передает его на сортировочный центр маркетплейса. Площадка передает товар в транспортную компанию, при этом самостоятельно управляет расчетами за доставку. Склад для FBS может быть необорудованным — это выгодно для маркетплейса. Необходимы лишь 3 складские зоны: прием, сборка заказа, и зона передачи в транспортную компанию. Это не требует высокой квалификации сотрудников и сложной автоматизации. Плюс для продавца в том, что он везет груз не в 20 разных компаний, а в сорт.центр маркетплейса.

Рассмотрим на примере: Продавец работает по типу DBS и получил заказы в 10 разных транспортных компаний — он развозит их сам. Доставка для покупателя платная, товар — носки по 200 руб, если покупатель закажет их у 10 разных продавцов, с доставкой по 300 руб. за каждую пару, заказ выйдет очень дорогим и его ценность будет утеряна. Если же все это объединится в сортировочном центре в многоместное отправление, то вес всех 10 пар носков не будет превышать лимит по тарификатору и такая отправка будет стоить 300 руб. В таком случае, чем больше отправлений, тем ниже цена для маркетплейса за счет оборота, по этим моделям работают все ключевые маркетплейсы.

В случае с доставкой по модели FBS/DBS у бизнеса неизбежно будет возникать множество процессов, связанных с обработкой заказов, сборкой, упаковкой и отгрузкой. Отлаженность этих процессов особенно важна, если работать на маркетплейсах Ozon, Wildberries или Яндекс Маркет. Уменьшить количество ошибок и повысить эффективность склада поможет интеграция 1С и Wildberries, внедрение ТСД и адресного хранения на складе.

Гибкость при выстраивании логистики маркетплейса

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

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

Гибкость при выстраивании логистики является важной частью финансового успеха маркетплейса. Успешная реализация стратегии доставки не только повышает удовлетворенность клиентов, но и снижает затраты. Специалисты компании DST Global могут рассказать о всех нюансах, связанных с выбором и внедрением оптимальных решений для доставки.

При выборе модели доставки необходимо учитывать множество факторов, включая тип товара, целевую аудиторию и особенности работы с продавцами. Только так можно создать эффективную и прибыльную бизнес-модель, которая будет соответствовать требованиям рынка и ожиданиям клиентов.

Виталий Стрекалов
Виталий Стрекалов
  • Сообщений: 14
  • Последний визит: 11 марта 2025 в 15:41

Есть три основных способа работы на маркетплейсе.

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

FBS (продажа со склада продавца). В данном случае товар хранится на складе продавца. После оформления заказа, продавец самостоятельно собирает, упаковывает и маркирует заказ, после чего отправляет его на склад маркетплейса для дальнейшей доставки покупателю.

DBS, или прямой ввоз и доставка продавцом. В данном случае товар не поступает на склад торговой площадки. Хранение, комплектация и упаковка товара осуществляется продавцом, который затем самостоятельно доставляет его покупателю. Этот вариант подходит для дорогих, хрупких и объемных товаров.

Самые популярные схемы — FBO и FBS, где доставкой занимается маркетплейс

Услуга FBO и FBS платная, на каждом маркетплейсе свои расценки. Средняя стоимость доставки одного обычного (не крупногабаритного) товара — 30–100 рублей.

Хранение на складах маркетплейсов также платное. Обычно есть период бесплатного хранения — от 30 до 120 дней в зависимости от маркетплейса.

Некоторые продавцы торговых площадок вовсе не участвуют в процессах, связанных с логистикой, упаковкой и хранением товаров. Вместо этого они передают эти обязанности сторонним специалистам – фулфилмент-операторам. Такие специалисты берут на себя все заботы: они размещают товары на своих складах, формируют заказы и доставляют их на склады торговой площадки.

Елизавета Кондратенкова
Елизавета Кондратенкова
  • Сообщений: 7
  • Последний визит: 10 февраля 2025 в 15:09

Проще говоря фреймворк это то на чем затем делают CMS системы, например DST Platform это фреймворк, а на нем сделано DST Store, DST Marketplace DST Board и.т.д. Это позволяет дать CMS системе больше возможностей и гибкости 

DST Global
DST Global
  • Сообщений: 19
  • Последний визит: 7 мая 2025 в 18:07

CMS — это система для создания и управления сайтом, интерфейс, с помощью которого можно добавлять и редактировать содержимое сайта.

Платформа – это комплексное решение и управление всеми процессами, а не только содержимым сайта.

Платформа включает в себя множество инструментов, объединённых в единое управление:
— управление содержимым сайта;
— управление дизайном;
— управление маркетингом;
— управление внутренними бизнес-процессами организации (управление сотрудниками и финансовыми показателями);
— управление внешними бизнес-процессами организации (коммуникация с клиентами, продавцами, информирование, обмен документами, порядок оказания услуг, порядок продаж и т.д.);
— управление IT-инфраструктурой (управление базами данных, сервером, файловым хранилищем и т.д.).

Платформа — это совокупность инструментов, необходимых для построения полноценного Интернет-представительства организации, создания виртуальной компании. Задача платформы, не только управлять сайтом, а управление всеми процессами необходимыми для ведения бизнеса.

Алексей Девятов
Алексей Девятов
  • Сообщений: 22
  • Последний визит: 14 февраля 2025 в 22:03

Не знал что есть такие два полезных модуля, большое спасибо, пойду изучать 

Виталий Стрекалов
Виталий Стрекалов
  • Сообщений: 14
  • Последний визит: 11 марта 2025 в 15:41

Для целей регулярной отчетности и бизнес‑аналитики отлично подойдет классическое хранилище данных (DWH). Оно помогает объединить и привести к единому формату данные из информационных систем, баз данных и других источников: CRM, ERP, систем бухгалтерского учета, кассовых систем. Благодаря своей структурированности и оптимизации данных, КХД позволяет получить быстрый доступ к большим объемам информации без значительного влияния на производительность информационных систем и оперативных баз данных.

Data Lake — метод хранения и обработки «больших данных». Сбор структурированных и неструктурированных данных расширяет возможности для продвинутой аналитики или для использования инструментов машинного обучения. Озеро данных становится особенно ценным инструментом в крупных концернах с распределенной структурой, так как позволяет извлекать пользу из неочевидных источников информации.

Концепции Data Lakehouse, Data Fabric и Data Mesh — следующие уровни работы с данными, которые охватывают не только технологический стек, но и организационную структуру компании. Реализация таких архитектур подразумевает полный пересмотр бизнес‑процессов в компании, но при грамотном внедрении повышает эффективность работы всех подразделений.

Окончательный выбор технологий работы с данными зависит от их текущего и потенциального объема, особенностей имеющейся инфраструктуры, масштаба команды, приоритетных бизнес‑целей компании.

В любом случае, лучшим решением станет начать с предпроектного обследования — оценки бизнес‑процессов, источников данных, инфраструктуры компании. 

Александр Репин

Не понимаю эти шарады вокруг ETL и ELT. Что это чуть ли не единственная разница между озером и просто хранилищем. И озеро без трансформации надо было болотом назвать.

Концепции… Придумали же они там. Заменить у машины одну деталь и сказать что она теперь самолёт.

Александр Репин
Александр Репин
  • Сообщений: 20
  • Последний визит: 8 апреля 2025 в 12:06

Для целей регулярной отчетности и бизнес‑аналитики отлично подойдет классическое хранилище данных (DWH). Оно помогает объединить и привести к единому формату данные из информационных систем, баз данных и других источников: CRM, ERP, систем бухгалтерского учета, кассовых систем. Благодаря своей структурированности и оптимизации данных, КХД позволяет получить быстрый доступ к большим объемам информации без значительного влияния на производительность информационных систем и оперативных баз данных.

Data Lake — метод хранения и обработки «больших данных». Сбор структурированных и неструктурированных данных расширяет возможности для продвинутой аналитики или для использования инструментов машинного обучения. Озеро данных становится особенно ценным инструментом в крупных концернах с распределенной структурой, так как позволяет извлекать пользу из неочевидных источников информации.

Концепции Data Lakehouse, Data Fabric и Data Mesh — следующие уровни работы с данными, которые охватывают не только технологический стек, но и организационную структуру компании. Реализация таких архитектур подразумевает полный пересмотр бизнес‑процессов в компании, но при грамотном внедрении повышает эффективность работы всех подразделений.

Окончательный выбор технологий работы с данными зависит от их текущего и потенциального объема, особенностей имеющейся инфраструктуры, масштаба команды, приоритетных бизнес‑целей компании.

В любом случае, лучшим решением станет начать с предпроектного обследования — оценки бизнес‑процессов, источников данных, инфраструктуры компании. 

Виталий Стрекалов
Виталий Стрекалов
  • Сообщений: 14
  • Последний визит: 11 марта 2025 в 15:41

Позволяя клиентам сбрасывать большие объемы полуструктурированных и неструктурированных данных в распределенную файловую систему, кластеры Hadoop получили прозвище «озера данных». Клиенты могли обрабатывать и преобразовывать данные для своих конкретных аналитических нужд по требованию, реализуя так называемый подход «structure on read» (стратегия сбора и анализа данных, при которой их структура определяется во время чтения).

Это существенно отличалось от подхода «structure on write» (структура определяется при записи), который использовался в типичных хранилищах данных того времени. До появления Hadoop предприятиям приходилось тратить время на преобразование и очистку транзакционных данных перед их загрузкой в хранилище данных. Это увеличивало затраты времени и денег, но было необходимо для максимального использования дорогостоящих ресурсов хранения и вычислений.

По мере продвижения эксперимента с Hadoop многие предприятия обнаружили, что их озера данных превратились в «болота данных». Хотя сброс необработанных данных в HDFS или S3 радикально увеличивал объем данных, которые они могли хранить, это происходило за счет более низкого качества данных. В частности, в Hadoop отсутствовали средства контроля, позволяющие предприятиям эффективно управлять своими данными, что привело к снижению доверия к аналитике Hadoop.

К середине 2010-х несколько независимых команд работали над решением проблемы. Первую команду возглавлял Винот Чандар, инженер из Uber, которому нужно было решить проблему быстрого перемещения файлов для приложения по совместному использованию автомобилей. Он руководил разработкой формата таблиц, который позволил бы Hadoop обрабатывать данные подобно традиционной базе данных. Чандар назвал его Hudi, что расшифровывается как «Hadoop upserts, deletes, and incrementals». Uber внедрила Hudi в 2016 г.

Год спустя еще две команды представили аналогичные решения для озер данных HDFS и S3. Инженер Netflix Райан Блю и инженер Apple Дэниел Викс совместно создали формат таблиц под названием Iceberg, который должен был привнести в таблицы Apache Hive возможности ACID-подобных транзакций и откатов. В том же году компания Databricks выпустила Delta Lake, объединив возможности хранилищ данных по работе со структурированными данными с облачным озером данных, чтобы привнести «хорошее, лучшее, оптимальное» в управление данными и обеспечение их качества.

Эти три формата таблиц в значительной степени стимулировали рост озер-хранилищ данных, поскольку они позволяли применять традиционные методы управления данными в базах данных в качестве слоя поверх озер данных в стиле Hadoop и S3. Таким образом, клиенты получали лучшее из двух миров: масштабируемость и доступность озер данных и качество и надежность данных в хранилищах данных.

Другие платформы данных, включая AWS, Google Cloud и Snowflake, начали принимать один из форматов таблиц. Iceberg, который в 2020 г. стал проектом Apache высшего уровня, получил значительную поддержку от открытой экосистемы Hadoop. Databricks, которая сначала придерживалась Delta Lake и лежащего в ее основе формата таблиц, а затем постепенно открылась, также становилась все более популярной. Третьим по популярности стал формат Hudi, который в 2019 г. получил статус проекта Apache верхнего уровня.

Битва между Apache Iceberg и Delta Lake за доминирование в области форматов таблиц казалось бы зашла в тупик. Однако в июне 2024 г. Snowflake усилила поддержку Iceberg, запустив каталог метаданных для Iceberg под названием Polaris (теперь Apache Polaris). Практически одновременно Databricks объявила о приобретении основанной Райаном Блу, Дэниелом Уиксом и бывшим инженером Netflix Джейсоном Ридом компании Tabular, платформа которой основана на Iceberg, за сумму от 1 до 2 млрд. долл.

Руководители Databricks во главе с генеральным директором Али Годси объявили, что форматы Iceberg и Delta Lake со временем будут объединены: «Мы собираемся стать лидерами в области совместимости данных, чтобы вы больше не были ограничены тем, в каком формате озер-хранилищ хранятся ваши данные».

Запуск Polaris и приобретение Tabular оказали огромное влияние, особенно на сообщество поставщиков, разрабатывающих независимые движки запросов, и сразу же вызвали рост популярности Apache Iceberg. «Если вы принадлежите к сообществу Iceberg, то для вас наступает время вступить в новую эру», — сказал в июне 2024 г. Рид Мэлони, директор по маркетингу компании Dremio.

Семь месяцев спустя этот импульс не иссяк. В январе 2025 г. Dremio опубликовала новый отчет под названием «State of the Data Lakehouse in the AI Era», который составлен на основе опроса 563 лиц, принимающих решения в области данных, проведенного McKnight Consulting Group в IV квартале 2024 г.

Отчет засвидетельствовал растущую поддержку озер-хранилищ данных (которые теперь по умолчанию считаются основанными на Iceberg). «Наш анализ показывает, что озера-хранилища данных достигли критического порога принятия: 55% организаций проводят большинство аналитических операций на этих платформах, — говорится в отчете. — По прогнозам респондентов, в ближайшие три года эта цифра достигнет 67%, что свидетельствует о явном изменении стратегии работы с данными на предприятиях».

Dremio утверждает, что основным фактором роста озер-хранилищ данных остается экономическая эффективность, на которую указали 19% респондентов, за которой следуют унифицированный доступ к данным и повышенная простота использования (по 17%) и аналитика самообслуживания (13%). По данным опроса, 41% пользователей озер-хранилищ данных перешли из облачных хранилищ данных, а 23% — из стандартных озер данных.

Более качественная и открытая аналитика данных занимает первое место в списке причин перехода на озеро-хранилище данных, однако Dremio обнаружила удивительное большое количество организаций, использующих свое озеро-хранилище данных для поддержки другого сценария использования — разработки ИИ. Так, 85% пользователей озер-хранилищ данных в настоящее время используют их для разработки моделей ИИ, а еще 11% планируют это делать. Ошеломляюще мало (4%) пользователей lakehouse заявили, что не планируют поддерживать разработку ИИ.

Несмотря на то, что стремление к ИИ является всеобщим, организациям еще предстоит преодолеть серьезные препятствия, прежде чем они смогут реализовать свою мечту об ИИ. В ходе своего исследования Dremio выяснила, что организации сталкиваются с серьезными проблемами на пути к достижению успеха в подготовке данных для ИИ. В частности, 36% респондентов заявили, что главной проблемой являются регулирование и безопасность при использовании ИИ, затем следуют высокие стоимость и сложность (33%) и отсутствие единой инфраструктуры, готовой к ИИ (20%).

По словам Джеймса Роуленд-Джонса, вице-президента Dremio по управлению продуктами, архитектура lakehouse является ключевым компонентом для создания продуктов данных, которые хорошо управляются и широко доступны, что очень важно для упрощения разработки ИИ-приложений.

«Важно то, как происходит обмен данными и что с этим связано, — говорит Роуленд-Джонс. — Как они обогащаются? Как вы понимаете их и рассуждаете о них как конечный пользователь? Получаете ли вы статистическую выборку данных? Можете ли вы понять, что это за данные? Документированы ли они? Регулируются ли они? Есть ли глоссарии? Можно ли использовать глоссарий в разных представлениях, чтобы люди не дублировали все эти усилия?».

Самым большим бенефициаром роста открытых платформ lakehouse на базе Iceberg являются предприятия, которые больше не зависят от поставщиков монолитных облачных платформ, желающих заблокировать данные клиентов, чтобы получить от них больше денег. Побочным эффектом появления озер-хранилищ стало то, что их потребители теперь имеют возможность свободно выбирать механизм запросов для удовлетворения своих конкретных потребностей.

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

Виталий Стрекалов
Виталий Стрекалов
  • Сообщений: 14
  • Последний визит: 11 марта 2025 в 15:41

По мере роста онлайн-мошенничества и атак вымогателей группы безопасности должны быть готовы к тому, что любое физическое лицо или устройство может привести к нарушению данных. Это верно, даже если это внутренний источник, которому, как вы ожидаете, вы можете доверять.

Модель нулевого доверия обеспечивает лучшую защиту, чем традиционные ИТ-модели, помогая обнаруживать атаки. По прогнозам, в 2022 году более 80% бизнес-приложений будут доступны через ZTNA, что доказывает высокую эффективность этой модели.

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

Сибсети
Сибсети
  • Сообщений: 11
  • Последний визит: 23 февраля 2025 в 20:23

Спасибо за развернутый ответ, а не можете ещ пояснить какие причины внедрить? 

Елизавета Кондратенкова

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

1. Защитите свои данные о клиентах

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

2. Сократите время обнаружения нарушений

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

3. Получите представление о вашем корпоративном трафике

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

4. Сделайте свой стек безопасности менее сложным

Когда каждое устройство пытается получить доступ к вашим бизнес-операциям из периметра, ваши виртуальные среды могут стать громоздкими. Поскольку модель нулевого доверия содержит одни и те же протоколы для всего доступа пользователей, гораздо проще организовать пользователей и управлять ими с помощью единого централизованного расположения.

5. Решите проблему низкой квалификации сотрудников

В недавних отчетах говорилось, что 65% нынешних корпоративных сотрудников считают, что им необходимо больше обучаться методам кибербезопасности для выполнения своих обязанностей. Человеческий фактор всегда присутствует в защитных протоколах, и часто возникают внутренние угрозы. Приняв модель нулевого доверия, все сотрудники, внутренние команды и сторонние заинтересованные стороны остаются на первом месте, помогая повысить безопасность ИТ-ресурсов и одновременно способствуя созданию возможностей для обучения работников.

6. Оптимизируйте взаимодействие с конечными пользователями

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

7. Переместитесь в облако

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

5 шагов к реализации модели нулевого доверия

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

1. Определите свою защитную поверхность

Поверхность защиты (или поверхность атаки) включает в себя все важные данные и приложения в ваших ИТ-системах. Вы должны тщательно изучить эти элементы и убедиться, что выбрали только наиболее важные аспекты для обеспечения безопасности. Чем меньше поверхность атаки, тем сложнее злоумышленникам получить доступ к вашей конфиденциальной информации. Эта поверхность будет развиваться в облачных средах. Тем не менее, вы должны попытаться сохранить оптимальное пространство, которое обеспечит доступ для пользователей и облегчит его защиту.

2. Составьте карту ваших транзакционных потоков

Во-первых, обратите внимание на то, как ваши пользователи перемещаются между вашими бизнес-системами. Затем добавьте защиту, чтобы исключить боковое перемещение. Если определенным пользователям не требуется доступ к определенным областям вашей карты трафика, обновите для них свои разрешения.

3. Создайте сеть с нулевым доверием

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

4. Напишите политику нулевого доверия

После создания сети с нулевым доверием вы можете затем написать четкую политику, в которой будет указано, кто и что может получить доступ к каждому аспекту ваших ИТ-систем. Благодаря такой подробной стратегии обеспечения соблюдения внутренним командам становится проще управлять инцидентами безопасности и предотвращать их.

5. Мониторинг и обслуживание сети

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

Елизавета Кондратенкова
Елизавета Кондратенкова
  • Сообщений: 7
  • Последний визит: 10 февраля 2025 в 15:09

Спасибо за развернутый ответ, а не можете ещ пояснить какие причины внедрить?