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

Jesse Anderson, директор Big Data Institute, и Martin Kleppmann, автор книги «Высоконагруженные приложения. Программирование, масштабирование, поддержка», вместе исследуют меняющийся ландшафт обработки данных. Они начинают с истории создания книги Мартина, подчеркивая важность искусства задавать правильные вопросы. Мартин рассказывает об изменениях, произошедших в отрасли с 2017 года, подчеркивая рост облачных сервисов. Затем беседа приобретает новый поворот, когда Мартин погружается в академические круги, делясь своими соображениями о программном обеспечении для совместной работы на основе локального подхода и увлекательном мире Automerge. Начинающие инженеры‑программисты получат несколько советов о том, как найти тонкий баланс между простотой и гибкостью. В завершение обсуждают о различных карьерных путях в динамичной сфере инженерии данных, что делает разговор полезным для профессионалов на любом этапе их пути.

28 июля 2015 г.

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

Привет всем, на связи снова Александр Бобряков, техлид в команде МТС Аналитики. Продолжаем цикл статей про фреймворк Apache Flink.

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

Начиная с этой статьи начнём разбирать, как тестировать всё наше приложение Flink + Spring. Многие описанные подходы вполне применимы и в любом другом обычном Spring-приложении, поэтому, надеюсь, вы найдёте для себя что-то новое.

В данной статье мы рассмотрим, как протестировать stateless- и stateful-операторы Flink с помощью абстракций TestHarness.

Общеизвестно, что PostgreSQL - крайне эффективная СУБД с богатой функциональностью. При этом не секрет, что PostgreSQL масштабируется только вертикально и её производительность ограничена возможностями одного сервера.

Написано много хороших постов, в которых сравнивают архитектуру монолитных и распределенных СУБД. К сожалению, обычно авторы ограничиваются теоретическим сравнением и не приводят конкретные цифры. Данный пост же наоборот основан на эмпирическом исследовании с использованием бенчмарка TPC-C, который является промышленным стандартом для оценки производительности транзакционных СУБД (On-Line Transaction Processing, OLTP).

Мы расскажем, когда именно одного Postgres'a становится мало, и какие возможны компромиссы между производительностью и надежностью. Для тех, кто не готов к компромиссам, мы покажем, что могут предложить такие распределенные СУБД, как CockroachDB и YDB.

Привет! Меня зовут Александр Попов, я tech lead команды маркетплейса 05.ru. Сейчас мы занимаемся бэком маркетплейса и некоторыми другими сервисами на рынке Дагестана. 

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

Привет, Хабр! На связи Николай, главный редактор Web3 Tech. Как можно предположить по должности, опыта в разработке я почти не имею. Год назад закончил мини-курс по Python, сделал об этом пост и с тех пор код не писал. Но недавно набрался смелости, заручился посильной поддержкой коллег и решил создать, пусть и локальную, но все же свою блокчейн-сеть!

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

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.

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

TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.

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

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

Всем привет, меня зовут Александр Бобряков. Я техлид в команде МТС Аналитики, занимаюсь Real-Time обработкой данных. Мы начали использовать фреймворк Apache Flink, и я решил поделиться на Хабре своим опытом внедрения этой технологии в цикле статей.

В предыдущей статье — «Apache Flink. Как работает дедупликация данных в потоке Kafka-to-Kafka?» — я рассказывал про построение пайплайна Kafka-to-Kafka с промежуточным разделением потока и дедупликацией событий. Также разобрались, что такое состояние оператора и зачем оно нужно.

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

Когда-то файлы хранили на дискетах, потом на дисках, потом на флэшках. Закончилось всё облаками. Тогда встал ряд различных вопросов по надёжности и приватности. С одной стороны можно просто доверить файлы гуглу или яндексу, но тогда о приватности можно забыть. C другой стороны можно завести собственное облачное хранилище, будь то дорогое железное решение от Synology, или оперсорсное на арендованной vps на nextcloud, но тут требуется вовлечение, что бы облако оставалось в рабочем состоянии (следить за апдейтами, своевременно обновлять оборудование, поддерживать резервное железо). Вместе с развитием блокчейна и развитием децентрализованных технологий web 3.0, появились и облачные хранилища, обещающие приватность, доступность и низкую цену. Предлагаю к рассмотрению 2 проекта, которые появились более 10 лет назад, и до сих пор существуют - Filecoin и Storj.

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

Развитие идей Web 2.0 привело к тому, что пользователи сами стали товаром. Вернее, товаром стала информация об их связях и предпочтениях, которую собирают и монетизируют корпорации типа Google и Facebook. В ответ на это у многих пользователей появилось желание не делиться своими персональными данными с корпорациями, а хранить свои данные в недоступном для корпораций месте. Размышлениям о том, к каким последствиям может привести персонализация хранимых данных, и посвящена данная публикация. Сразу предупреждаю - это просто моё растекание мыслью по древу, а не "сборник рецептов" или разъяснения "как всё устроено". Не очаровывайтесь, чтобы не разочароваться :)

В посте про историю развития смарт-контрактов целый раздел мы посвятили такому понятию, как конфиденциальные смарт-контракты. У блокчейна есть целый ряд преимуществ, которые делают его привлекательных для реализации конфиденциальных систем. Но данные смарт-контрактов, формирующих бизнес-логику блокчейна, по умолчанию хранятся в открытом виде и доступны для всех. Этот конфликт решают конфиденциальные смарт-контракты (КСК) — они стали для нас одной из основных фичей платформы, запланированных на 2023 год, и успешно дошли до релиза. Далее мы раскроем подробности реализации КСК и приведем пример контракта, который вы легко сможете развернуть на оpen-source инстансе нашей сети.

Приветствую, Хабр! Моя предыдущая статья была посвящена формализованным критериям выбора базовой технологии хранения и обработки данных, совокупность которых позволяла ответить на вопрос, использовать ли в конкретной системе блокчейн-технологии или ограничиться хорошо изученными СУБД. При этом ответ на данный вопрос при использовании формализованных методов выбора мог быть получен именно на основе технических факторов, не принимая во внимание различные «политические» аспекты выбора, такие как, например, повышенный информационный шум, продолжающийся вокруг блокчейна.

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

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

Доброго времени суток, коллеги. Я go разработчик, по-этому примеры будут преимущественно на нём. Хочу порассуждать о методах взаимодействия сервисов. Тема очень обширна. Зачастую мы пользуемся реализациями, которые не всегда подходят, т.к. не знаем куда применить ту или иную технологию. Я хочу попытаться начать закрывать этот пробел как у себя, так и у людей. Любые комментарии и конструктивные исправления приветствуются.

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

Всем привет, меня зовут Александр Бобряков. Я техлид в команде МТС Аналитики, занимаюсь Real-Time обработкой данных. Мы начали использовать фреймворк Apache Flink, и я решил поделиться на Хабре своим опытом внедрения этой технологии в цикле статей.

В предыдущей части «Как использовать Spring в качестве фреймворка для Flink-приложений» я рассказывал, как реализовать минимальное Flink-приложение с использованием фреймворка Spring. Мы запустили первую Flink-задачу в поднятом в docker-compose кластере, а также проверили корректность результата по соответствующим логам. В этой статье решим реальную бизнес-задачу дедупликации данных в пайплайне Kafka-to-Kafka.

Привет, Хабр! На полях конференции Yandex.Talks взял интервью у Александра Поломодова, который за 7 лет вырос в Тинькофф до технического директора. Александр рассказал про технологический бум компании благодаря вовремя принятым решениям, возможностям роста, упомянул о важных качествах инженера.

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