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

Мартин Клеппман (Martin Kleppman) – исследователь в Кембриджском университете, работающий над CRDT и формальной верификацией алгоритмов. Его книга «Designing Data-Intensive Applications», опубликованная в 2017 году, стала бестселлером в области хранения и обработки данных. 

Kevin Scott (CTO в Microsoft) однажды сказал: «Эта книга должна быть обязательной для инженеров-разработчиков. Это редкий ресурс, объединяющий теорию и практику, помогающий разработчикам глубже продумывать дизайн и реализацию инфраструктуры и систем обработки данных». Что-то похожее говорил и Jay Kreps — создатель Apache Kafka и CEO Confluent.

А прежде чем заняться академическими исследованиями, Мартин работал в индустрии и стал сооснователем двух успешных стартапов: Rapportive (купленный LinkedIn в 2012 году) и Go Test It (куплен RedGate).

Этот хабрапост – развернутое интервью с Мартином. Примерные темы обсуждения:

• Переход от бизнеса к академическим исследованиям;
  
• Предпосылки написания Designing Data-Intensive Applications;
  
• Здравый смысл против искусственного ажиотажа и рекламы инструментов;
  
• Ненужность теоремы CAP и другие ошибки индустрии;
  
• Полезность децентрализации;
  
• Блокчейны, Dat, IPFS, Filecoin, WebRTC;
  
• Новые CRDT. Формальная верификация на Isabelle;
  
• Дискуссия про event sourcing. Низкоуровневый подход. XA-транзакции; 
  
• Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
  
• Использование всего этого в реальной жизни;
  
• Порог входа в доклады Мартина и конференция Hydra.
  

Интервью провёл Вадим Цесько (@incubos) — ведущий разработчик в команде Платформы компании Одноклассники. Научные и инженерные интересы Вадима касаются распределённых систем и хранилищ данных, а также верификации программных систем.

Термин Big Data подпорчен современным фантастическим преувеличением новых вещей. Как ИИ поработит людей, а блокчейн построит идеальную экономику — так и большие данные позволят знать абсолютно все про всех и видеть будущее.

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

Появляются новые методы. Вместе с ними — новые профессии. Декан факультета аналитики Big Data в GeekBrains Сергей Ширкин рассказал, что это за профессии, где они нужны, чем там надо заниматься и что надо уметь. Какие используются инструменты и сколько обычно платят специалистам.

Привет, Хабр!

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

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

В этой заметке мы запилим Rust-прототип недавнего предложения от соавтора Lightning Network Paper, Thaddeus Dryja — Utreexo: a dynamic hash-based accumulator optimized for the Bitcoin UTXO set, позволяющего уменьшить требования к дисковому пространству для узлов-валидаторов.

Service Mesh — известный архитектурный паттерн для интеграции микросервисов и перехода на облачную инфраструктуру. Сегодня в облачно-контейнерном мире обойтись без него довольно сложно. На рынке уже доступны несколько open-source реализаций service mesh, но их функциональности, надежности и безопасности далеко не всегда достаточно, особенно когда речь идет о требованиях больших финансовых компаний масштаба всей страны. Поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим рассказать о том, что в Service Mesh круто, что не очень и что мы с этим собираемся сделать.

Лесли Лэмпорт — автор основополагающих работ в распределённых вычислениях, а ещё вы его можете знать по буквам La в слове LaTeX — «Lamport TeX». Это он впервые, ещё в 1979 году, ввёл понятие последовательной согласованности, а его статья «How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs» получила премию Дейкстры (точней, в 2000 году премия называлась по-старому: «PODC Influential Paper Award»). Про него есть статья в Википедии, где можно добыть ещё несколько интересных ссылок. Если вы в восторге от решения задач на happens-before или проблемы византийских генералов (BFT), то должны понимать, что за всем этим стоит Лэмпорт.

Эта хабрастатья — перевод доклада Лесли на Heidelberg Laureate Forum в 2018 году. В докладе пойдёт речь о формальных методах, применяемых в разработке сложных и критичных систем вроде космического зонда Rosetta или движков Amazon Web Services. Просмотр этого доклада является обязательным для посещения сессии вопросов и ответов, которую проведет Лесли на конференции Hydra — эта хабрастатья может сэкономить вам час времени на просмотр видео. На этом вступление закончено, мы передаём слово автору.

---

Когда-то давно Тони Хоар написал: «В каждой большой программе живет маленькая программа, которая пытается выбраться наружу». Я бы это перефразировал так: «В каждой большой программе живет алгоритм, который пытается выбраться наружу». Не знаю, правда, согласится ли с такой интерпретацией Тони.

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

Сегодня я хочу рассказать читателям Хабра об очередях сообщений вообще и о Yandex Message Queue в частности. Сначала я хочу объяснить, что такое «распределённая персистентная очередь сообщений» и зачем она нужна. Показать её практическую ценность, механику работы с сообщениями, поговорить про API и удобство использования. Во второй половине материала мы посмотрим на техническую сторону: как в наших очередях используется Yandex Database (это надежный фундамент нашего сервиса), как выглядят наивный и улучшенный подход к построению архитектуры, какие проблемы вызывает распределённость и как их можно решить.

Почти год назад я начал публиковать серию статей по архитектуре IoT решений. (Ссылка на первую статью habr.com/ru/post/420173). И вот наконец вторая статья серии отдается на ваш суд.

11-12 июля в Санкт-Петербурге состоится конференция Hydra, посвященная разработке параллельных и распределенных систем. Фишка Гидры в том, что она объединяет крутых учёных (которых обычно можно найти только на зарубежных научных конференциях) и известных практикующих инженеров, в одну большую программу на стыке науки и практики.

Hydra — одна из самых важных наших конференций за последние несколько лет. Ей предшествовала очень серьёзная подготовка, отбор спикеров и докладов. На прошлой неделе об этом вышло хаброинтервью с директором компании JUG.ru Group, Алексеем Федоровым (23derevo).

Мы уже рассказывали о трёх важных участниках, основоположниках теории распределенных систем — Лесли Лэмпорте, Морисе Херлихи и Майкле Скотте. Настало время более подробно поговорить о всей программе!

14 июня в Петербурге пройдет митап Apache Ignite Meetup: реальные кейсы. Послушаем парней, у которых получилось. Первый кейс — IMDG для расчета маржинальности торговых контрактов в Heineken. Второй — промышленная платформа Газпромнефти. Почему open source и Ignite? Куда прикрутили? Как и зачем работает? Спикеры ответят на эти и другие вопросы на митапе. Присоединяйтесь к нам вечером пятницы 14 июня. Чтобы было не душно, мы даже помещение нашли побольше — регистрация.

11 июля в Петербурге на конференции Гидра выступит Алексей Зиновьев с докладом “Не все ML-алгоритмы попадают в распределенный рай”. Он поделится своим опытом адаптации классических алгоритмов машинного обучения для выполнения в распределенном режиме, в том числе, расскажет про создание Apache Ignite ML, в котором принимал активное участие.

В понедельник на конференции WWDC компания Apple представила классную новую функцию под названием “Find My". В отличие от стандартной «Найти мой iPhone», которая полагается на инфраструктуру сотовой связи и GPS потерянного устройства, функция «Найди меня» способна найти даже устройства без сим-карты и GPS. Например, ноутбуки, или даже «тупые» метки локации, прикреплённые к любому предмету (Apple намекнула на это только в широком смысле).

Идея заключается в том, чтобы превратить всю существующую сеть айфонов в масштабную краудсорсинговую систему по отслеживанию окружающих объектов. Каждый активный iPhone будет постоянно отслеживать сообщения маячков BLE, которые поступают с других устройств. Когда он находит один из этих сигналов, то помечает пакет своими координатами GPS — и отправляет на серверы Apple. Это очень здорово для растеряш вроде меня, которые постоянно теряют вещи: если я оставлю свой рюкзак в туристическом автобусе в Китае в офисе, то рано или поздно кто-то наткнётся на его сигнал — и я мгновенно узнаю, где его найти.

(Стоит отметить, что идею придумала не Apple. На самом деле компании вроде Tile работают довольно давно. И да, им стоит беспокоиться за свой бизнес).

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

Когда я увидел, что Лесли Лэмпорт (да-да, тот самый товарищ из учебников) приезжает в Россию и делает не доклад, а сессию вопросов-ответов, я немного насторожился. На всякий случай, Лесли — всемирно известный учёный, автор основополагающих работ в распределённых вычислениях, а ещё вы его можете знать по буквам La в слове LaTeX — «Lamport TeX». Вторым настораживающим фактором является его требование: каждый, кто придёт, должен (совершенно бесплатно) заранее прослушать пару его докладов, придумать по ним минимум один вопрос и только тогда уже приходить. Решил посмотреть, что там Лэмпорт вещает — и это великолепно! Это в точности та штука, волшебная ссылка-таблетка для лечения зомбятины. Предупреждаю: от текста может знатно подгореть у любителей сверхгибких методологий и нелюбителей тестировать написанное.

После хаброката, собственно, начинается перевод семинара. Приятного чтения!

Недавно были анонсированы сразу два мероприятия о разработке многопоточных и распределённых систем: конференция Hydra (11-12 июля) и школа SPTDC (8-12 июля). Люди, которым близка эта тема, понимают, что приезд в Россию Лесли Лэмпорта, Мориса Херлихи и Майкла Скотта — важнейшее событие. Но возникали другие вопросы:

• Чего ждать от конференции: «академичности» или «продакшна»?
• Как соотносятся школа и конференция? На кого рассчитано то и другое?
• Почему они пересекаются по датам?
• Будут ли они полезны тем, кто не посвятил всю жизнь распределённым системам?

Обо всём этом хорошо известно человеку, благодаря которому Hydra появилась: нашему директору Алексею Федорову (23derevo). Он и ответил на все вопросы.

Больше года назад стало известно о планах мессенджера Telegram выпустить собственную децентрализованную сеть Telegram Open Network. Тогда стал доступен объемный технический документ, который, предположительно, был написан Николаем Дуровым и описывал структуру будущей сети. Для тех, кто пропустил — рекомендую ознакомиться с моим пересказом этого документа (часть 1, часть 2; третья часть, увы, всё ещё пылится в черновиках).

С тех пор никаких значимых новостей о статусе разработки TON не было, пока пару дней назад (в одном из неофициальных каналов) не появилась ссылка на страницу https://test.ton.org/download.html, где размещены:

◦ ton-test-liteclient-full.tar.xz — исходники лёгкого клиента для тестовой сети TON;
◦ ton-lite-client-test1.config.json — конфигурационный файл для подключения к тестовой сети;
◦ README — информация о сборке и запуске клиента;
◦ HOWTO — пошаговая инструкция о создании смарт-контракта с помощью клиента;
◦ ton.pdf — обновлённый документ (от 2 марта 2019 г.) с техническим обзором сети TON;
◦ tvm.pdf — техническое описание TVM (TON Virtual Machine, виртуальной машины TON);
◦ tblkch.pdf — техническое описание блокчейна TON;
◦ fiftbase.pdf — описание нового языка Fift, предназначенного для создания смарт-контрактов в TON.

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

Прошлую неделю я провёл разрабатывая свою первую публичную программку — Telegram-бота который работает в качестве Bitcoin-кошелька и позволяет «бросать монетки» другим участникам групповых чатов а так же совершать внешние Bitcoin-платежи себе или другим т.н. “Lightning Apps”. Подразумеваю, что в целом читатель знаком c Bitcoin и Telegram, т.к. буду стараться писать кратко, не вникая в детали. Выборка ресурсов о Bitcoin доступна по этой ссылке, ну а Телеграм это средство мгновенного обмена сообщениями на мобильных устройства и пк, позволяющее на их платформе создавать свои небольшие приложения (чат-ботов).

Какие ключевые функции этого приложения?

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

И как это применить в деле?

как-то так…

Мы уже давно интересуемся темой анонимности в криптовалютах и стараемся следить за развитием технологий в этой области. В своих статьях мы уже подробно разбирали принципы работы конфиденциальных транзакций в Monero, а также проводили сравнительный обзор технологий, существующих на этом поле. Однако же все анонимные криптовалюты на сегодняшний день построены на модели данных, предложенной Bitcoin — Unspent Transaction Output (далее UTXO). Для account-based блокчейнов как Ethereum существующие решения по реализации анонимности и конфиденциальности (например, Mobius или Aztec) пытались повторить модель UTXO в смарт-контрактах.

В феврале 2019 года группа исследователей из Стэнфордского университета и Visa Research

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

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

Или рассмотрим эту статью, которую вы читаете. Вероятно, вы нашли её в социальной сети, скачали из компьютерной сети и в настоящее время расшифровываете смысл с помощью своей нейронной сети.

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

Это наша тема на сегодня: как, насколько хаотично всё движется и распространяется. Некоторые примеры, чтобы подогреть аппетит:

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

Не так давно ребята из LINBIT представили свое новое SDS-решение — Linstor. Это полностью свободное хранилище в основе которого используются проверенные технологии: DRBD, LVM, ZFS. Linstor сочетает в себе простоту и хорошо проработанную архитектуру, что позволяет добиться стабильности и достаточно внушительных результатов.

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

Linstor в сочетании с OpenNebula позволяет построить быстрое и надежное облако, которое можно без проблем развернуть на собственной инфраструктуре.

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

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

Привет, Хабр!

Напоминаем, что вслед за книгой о Kafka мы выпустили не менее интересный труд о библиотеке Kafka Streams API.



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