Распределённые системы *

Greengage DB — это массивно-параллельная реляционная СУБД на базе Greenplum OSS, которая подходит для хранения и обработки данных. Позволяет выполнять сложные аналитические запросы над большими объёмами данных, предоставляя к ним гетерогенный доступ за счёт различного рода коннекторов и средств интеграции.

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

Компании часто сталкиваются с необходимостью переливать данные между системами. Но нередко это превращается в настоящий квест: форматы данных могут различаться, для интеграции инструментов может не быть готовых коннекторов, самостоятельно гарантировать консистентность данных в целевой системе может быть сложно или невозможно. Поэтому подобные задачи редко обходятся без применения CDC (Change Data Capture).

Меня зовут Андрей Капустин. Я менеджер продукта Tarantool CDC в компании VK Tech. В этой статье я расскажу о Tarantool CDC и о том, как инструмент помогает консолидировать данные из разрозненных хранилищ, в том числе проприетарных СУБД, обеспечивая прозрачность, высокую консистентность и скорость.

И снова здравствуйте! Меня по-прежнему зовут Александр Попов, и я всё ещё TechLead команды разработки маркетплейса 05.ru.

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

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

Всем привет! Меня зовут Александр, и я хочу поделиться опытом использования CIM-модели и моделирования её расширений при разработке интеллектуальной системы учета электроэнергии. На самом деле материалов по этой теме у нашей команды накопилось достаточно — хватит на целую серию статьей. Начну с основ. В чем особенности рынка электроэнергетики, почему важно обеспечить унифицированный обмен данными между его участниками и как в этом помогает CIM? Давайте разбираться.

Решил и я в рамках конкурса рассказать о своём вкладе в развитие open source. Речь про open source блокчейн Hyperledger Fabric. Блокчейн активно используется в разных сферах: цифровые валюты центробанков (Беларусии, Нигерии), операторами информационных систем цифровых финансовых активов, электронное голосование, энергетика, здравоохранение и др.

В этой статье я расскажу как я:

обнаружил проблему;
создал свой первый open source: смарт-контракт для решения этой проблемы;
повлиял на создание патча для блокчейна Hyperledger Fabric, устраняющего проблему.

Привет! С вами Олег, Рамиль и Андрей из Flocktory. Мы руководим машинным обучением и разработкой в компании, сейчас активно внедряем AI для лучшей персонализации. В прошлом году наши команды реализовали ML-сервисы, внедрили ML Feature Store и переработали жизненный цикл моделей (о чём мы подробно рассказывали на HighLoad++: https://highload.ru/moscow/2024/abstracts/12929). В этой статье поразмышляем над следующим шагом для среднего размера компании, которая внедряет AI – как масштабировать проекты машинного обучения. Обработка, анализ и обучение на данных влекут за собой применение ML систем, в том числе нейросетей. Это требует больших вычислительных ресурсов: сотни гигабайт ОЗУ, десятки ядер CPU, а также видеокарты и (или) специальные чипы для ускорения вычислений.

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

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

Почему так сложно пройти первые System Design Интервью? Какие есть подводные камни? Оказывается, что не все понимают базовый алгоритм прохождения, а также нюансы движения по основным этапам.

Меня зовут Владимир и я senior backend в геораспределенной HighLoad системе. Которая выдерживает пиковые нагрузки в млн RPS. Моя страсть System Design. Я успешно прохожу интервью в BigTech компании, а также готовлю учеников. Выделил ТОП-5 ошибок у новичков и готов поделиться их разбором. Подробности под катом.

Заранее оговорюсь, всё что будет описано в данной статье, будет касаться runtime (децентрализованного) кеша и применимо не только к Gо приложениям.
Зачем нам нужен такой кеш? По нескольким причинам.

На собеседованиях часто задают знаменитый вопрос, узнаваемость которому по большей части дал facebook*: «Что происходит после того, как вы вводите URL сайта в адресную строку браузера и нажимаете Enter?». Несмотря на кажущуюся простоту, этот вопрос покрывает широкий спектр тем – DNS, TCP/IP, HTTP, и даже работу браузера. Разработчики разных уровней иногда теряются в деталях ответа. Понимание этого процесса важно для инженеров – оно показывает, как взаимодействуют между собой различные сетевые протоколы и уровни. Ниже мы шаг за шагом рассмотрим, как данные проходят через каждый слой сетевого стека, и проиллюстрируем это примерами.

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

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

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

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

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

В данной статье мы разберем несколько ключевых паттернов, связанных с микросервисами. Речь пойдет о паттернах миграции и интеграции (таких как Strangler Fig – «удушающее дерево» и API Gateway), о сетевых и структурных паттернах (Service Mesh, Sidecar), о шаблонах работы с данными (Database per Service, CQRS) и об особом подходе к хранению состояния (Event Sourcing). Для каждого паттерна мы рассмотрим его суть, назначение, примеры использования, а также плюсы и возможные сложности. К некоторым паттернам приведены упрощенные диаграммы и фрагменты кода, чтобы иллюстративно показать, как они работают на практике.

В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.

Мы начинали с обычного ELK-стека, логи приходили на logstash, записывались в Elasticsearch, а пользователи смотрели их в Kibana. Потом в эту схему добавилась Kafka, так как мы понимали, что на пиках нагрузок не успеваем записать все логи в Elasticsearch. Всё это располагалось в одном ЦОДе, а в Kafka была единая очередь. В результате горизонтального масштабирования Elasticsearch разросся до 30+ нод. Данная схема справлялась с нагрузкой в 100 тысяч документов в секунду.

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

Привет, Хабр! На связи Филипп Бочаров, руководитель платформы наблюдаемости и мониторинга для более 400 продуктов экосистемы МТС, и Юлия Тальцкова, ведущий инженер сервиса логирования и кластеров Open Search с более 400 терабайтами логов клиентов. Этот материал написан на основе нашего доклада для конференции Highload++

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

Для обработки Common Crawl на терабайтных объёмах широко используются архитектуры обработки данных, построенные на фреймворках вроде Apache Spark. Благодаря распределённой обработке данных и структурированному стримингу Spark позволяет разработчикам создавать масштабируемые пайплайны, применять логику фильтрации и формировать итоговые очищенные корпусы для обучения. Эта статья перевод моей статьи на medium.com, я хотел рассматреть, как на практике формируются обучающие наборы из Common Crawl (например, в проектах C4, CCNet, OSCAR, GPT-3, BLOOM, Falcon и др.), а затем показать пример Spark Streaming-приложения, который я написал и опубликовал в GitHub. Мы также приводим пример подхода, реализованного в DeepSeek, для фильтрации математического контента — узкоспециализированная задача, которая способна дать существенный прирост в качестве моделей.

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

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

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

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

Теорема CAP (дословно: Consistency (согласованность), Availability (доступность), Partition Tolerance (устойчивость к разделению)), предложенная Эриком Брюером в 2000 году, объясняет, почему невозможно одновременно обеспечить все три этих свойства.

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

Да, многие могут сказать, что это больше стезя архитектора. Но грань между аналитиком и архитектором в текущих реалиях очень смазана. Хороший системный аналитик фактически является lite версией архитектора. Поэтому щас выскажусь!)))

Продолжаем наращивать базу знаний по System Design! В этот раз освятим использование Pub/Sub, Event-Driven Architecture, Distributed Systems, Leader Election. Посмотрим на их концепции и области применения при проектирование высокодоступных отказоустойчивых систем.