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

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

Меня зовут Егор Щербин, я работаю в Yandex Infrastructure, в команде планировщика YTsaurus. О нём и расскажу в этой статье. А также о запуске вычислений в кластере YTsaurus, распределении ресурсов между вычислениями и о том, как управлять распределением, чтобы все операции получали ровно столько, сколько требуется.

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

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

Apache Kafka — популярный распределенный брокер сообщений, который собирает и сохраняет сообщения (данные) со всех источников, а после предоставляет их программам и сервисам-получателям. Благодаря своей производительности и архитектуре инструмент довольно активно используется в проектах, где нужно гонять большие объемы данных. Но даже возможностей Kafka не всегда достаточно — иногда системам нужен буст по скорости и надежности. И получить его можно с помощью кэширования данных в Tarantool.

Меня зовут Никита Молоствов. Я старший программист в команде разработки VK Tech. В этой статье я расскажу о том, как можно наладить взаимодействие Kafka и Tarantool, зачем может понадобиться кэширование потока из Kafka в Tarantool, и дам подробную пошаговую инструкцию, с которой каждый сможет применить мои наработки в собственной системе.

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

Итак, что мы сделали.... технология автоматического синтеза математической модели объекта....

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

Привет! Я Антон, работаю в команде базовой инфраструктуры Контура и занимаюсь развитием распределенной системы хранения данных Kanso. Это наш форк GFS (Google File System). Мы развиваем Kanso уже более 15 лет, в статье я расскажу про это подробнее.

Всем привет! Меня зовут Максим, я QA в Максилекте.

Недавно коллеги попросили меня рассказать о базовых вещах в Kafka, которые могут быть полезны при тестировании общающихся между собой микросервисов или сервисов, взаимодействующих со сторонними ресурсами. В этой статье - основные идеи моего рассказа.

Привет, Хабр! Я Роман Щербаков, ведущий инженер в Sage — это платформа мониторинга в Т-Банке, которую мы разрабатываем с 2019 года. За пять лет нагрузка на платформу возросла многократно, и, чтобы ее выдерживать, мы постоянно докручиваем наше решение. 

В этой статье расшифровка моего доклада с Saint HighLoad++ 2024 о том, как мы строим нагруженные пайплайны записи. И о том, как было бы здорово заранее знать, что нам потребуется. Мы придумали много всего для надежной работы пайплайнов, а посмотрели ретроспективно, и оказалось, что это просто одни сплошные стандартные паттерны.

Предположим, что у нас есть Postgres, Kafka и Elastic. В Postgres живет сущность, например, item.

Иногда возникает необходимость создать поисковый индекс отдельно от основной базы.

Например, если мы не хотим обрушивать поисковый трафик на Postgres мы можем вынести данные из него в Elastic.

И все бы хорошо, если актуальность не требуется - просто запускать крон пересборки индекса в Elastic каждую ночь.

Но что если данные нам нужны актуальные, и ситуация, что через секунду после записи сущности в Postgres запрос на её чтение отдает Not Found - неприемлема?

Привет, Хабр! На связи Александр Бобряков, техлид в команде МТС Аналитики. Это мой десятый материал про Apache Flink. В предыдущей части мы закончили разбирать оператор с Flink-таймерами, использующими внутреннее состояние. Также я показал, как их можно тестировать с помощью классов TestHarness или Flink MiniCluster. В дополнение тестами была покрыта вся Flink-джоба, включая E2E-тесты.

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

Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии статей. Эта часть соответствует релизной ветке с названием release/9_JacksonStateSerializer.

По мере выхода новых материалов на Хабре ссылки на них будут появляться ниже.

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

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

Пару недель назад было найдено очередное простое число Мерсенна - и я, пользуясь тем, что это событие подогрело интерес к проектам распределённым вычислений, хочу рассказать вам подробнее, что из себя представляет Great Internet Mersenne Prime Search. И, конечно же, по возможности, убедить присоединиться.

Привет, Хабр! На связи Александр Бобряков, техлид в команде МТС Аналитики. В предыдущей части я рассказал про создание Flink-джобы Kafka-to-Kafka с оператором на основе встроенных таймеров. Такой пайплайн позволяет создавать вызов через определенное время после обработки события.

В этом посте я расскажу, как можно протестировать операторы с таймерами и какие подводные камни могут возникнуть.

Весь разбираемый исходный код есть в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Эта статья соответствует релизной ветке с названием release/8_Test_for_Trigger_Flink_Job.

Это мой девятый материал про Apache Flink. По мере выхода новых ссылки на них будут появляться ниже.

Список моих статей про Flink:

Данная статья является обобщением ранее разбираемых мной тем по современным образовательным технологиям, применительно к реальной задаче обучения специалистов в области бурения (персонала буровых установок разведочного и эксплуатационного бурения), а также специалистов в области ТКРС (текущего и капитального ремонта скважин).....

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

На протяжении нескольких лет я участвовал в разработке блокчейн-платформы, вначале как разработчик, затем как руководитель команды (team lead, как это принято сейчас называть). За это время мне посчастливилось пройти все стадии жизненного цикла продукта, от идеи до выхода в продакшн. И это был уникальный опыт, в каком-то смысле драматический.  Дело в том, что в процессе своей довольно длительной карьеры я участвовал в огромном множестве самых различных проектов, но до сих мне не приходилось сталкиваться с таким количеством нетривиальных задач, которые требовали нестандартных решений.  И я хотел бы поделиться этим опытом.

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

Как строить Spine & Leaf архитектуру в датацентре оптимальнее и дешевле и при этом не уткнуться в «бутылочное горлышко» с большим трафиком.

Тема трансграничных платежей и цифровых финансовых активов (ЦФА) последние годы активно поселилась в медиасфере. К сожалению, обсуждение в основном сводится к оценке финансовой выгоды и юридическим проблемам. Тогда как, существует ещё и проблемы безопасности, которые на сегодняшний день, на мой взгляд, во многом недооценены (хотя, осознание проблемы понемногу уже происходит: об этом начинают говорить публично). В публичной плоскости мало конкретики о безопасности в этой сфере. Между тем, рынок ЦФА растёт: за 3 года ожидается почти 8-кратный рост в РФ (до 500 млрд. руб). А мирового — более 8 трлн $ к 2029. Поэтому вопросы безопасности становятся всё более актуальными. Мне довелось пообщаться с некоторыми разработчиками, исследовать архитектурные решения некоторых корпоративных блокчейнов. Также, я часто сталкивался с устоявшимися заблуждениями относительно факторов риска, которые хотел бы развеять. На основании всего этого, а также своего разнообразного опыта (пентест, разработка, code review, в т.ч. в сфере блокчейна) хочу поделиться своим мнением о текущем состоянии безопасности финансовых решений на основе блокчейн технологий. И тех причин, которые за этим стоят. В примерах для описания проблем будет использоваться блокчейн Hyperledger Fabric. Но, во многих случаях пример может быть общим и для других корпоративных блокчейнов.

Переход от PosgreSQL-only решения к собственному DataLake для отделения read нагрузки под нужды аналитики и AI.