11-12 липня у Санкт-Петербурзі відбудеться конференція , присвячена розробці паралельних та розподілених систем. Фішка Гідри в тому, що вона поєднує крутих вчених (яких зазвичай можна знайти тільки на зарубіжних наукових конференціях) і відомих інженерів-практиків, в одну велику програму на стику науки і практики.
Hydra – одна з найважливіших наших конференцій за останні кілька років. Їй передувала дуже серйозна підготовка, відбір спікерів та доповідей. Минулого тижня про це з директором компанії JUG.ru Group, Олексієм Федоровим ().
Ми про трьох важливих учасників, основоположників теорії розподілених систем — Леслі Лемпорте, Моріса Херліхі та Майкла Скотта. Настав час докладніше поговорити про всю програму!
Мотивація
Якщо ви займаєтеся програмуванням, то так чи інакше маєте справу з багатопоточністю та розподіленими обчисленнями. Фахівці у відповідних областях працюють з ними безпосередньо, але неявно розподіленість дивиться на нас звідусіль: у будь-якому багатоядерному комп'ютері чи розподіленому сервісі знайдеться щось, що паралельно виконує обчислення.
Існує безліч конференцій, які розкривають ті чи інші аспекти прикладного програмування. З іншого боку спектру ми маємо спеціальні наукові школи, у форматі лекцій розкривають величезні обсяги складної теорії. Наприклад, паралельно з Hydra у Пітері проходить . На конференції Hydra ми постаралися звести разом і сувору практику, і науку, і все, що на їхньому стику.
Подумайте ось над чим: ми живемо в дивовижний час, коли можна наживо зустріти засновників тієї галузі науки та інженерії, якими ми займаємося. Фізики не зустрінуть ні Ньютона, ні Ейнштейна - поїзд пішов. Але поряд з нами все ще живуть ті, хто створив основи теорії розподілених систем, вигадав популярні мови програмування, вперше втілив усе це в діючі прототипи. Ці люди не покинули свою роботу на півдорозі, прямо зараз займаються актуальними завданнями у всесвітньо відомих університетах та компаніях, і є найбільшими джерелами знань та досвіду на сьогоднішній день.
З іншого боку, можливість зустрітися з ними зазвичай залишається суто теоретичною: мало хто з нас може постійно моніторити публічні події в якомусь Рочестерському університеті, щоб потім кинутися до США і назад на лекцію до Майкла Скотта. Відвідати взагалі всіх учасників Hydra вийшло б у невеликий стан, за винятком прірви витраченого часу (хоча це звучить як цікавий квест).
З іншого боку, ми маємо безліч топових інженерів, які прямо зараз працюють над актуальними проблемами розподілених систем, і їм точно є що розповісти. Але ось проблема - вони працюють, та його час дорого. Так, якщо ти співробітник Microsoft, Google або JetBrains, ймовірність зустріти одного з відомих спікерів на внутрішньому заході різко зростає, а взагалі ні, не щодня це буває.
Таким чином, конференція Hydra виконує важливе завдання, яке більшість з нас не можуть зробити самі — в одному місці й одночасно об'єднує людей, ідеї яких або спілкування з якими може змінити ваше життя. Припускаю, що не всім потрібні розподілені системи, якісь складні фундаментальні речі. Можна до кінця життя програмувати CRUD на PHP і залишатися цілком щасливим. Але кому потрібні – це ваш шанс.
З першого анонсу конференції Hydra на Хабрі пройшло вже багато часу. За цей час виконано величезну роботу — і ось, у нас є список майже всіх доповідей. Жодних в'яленьких однопотокових алгоритмів, тільки чистий розподілений хардкор! Давайте закінчувати із загальними словами, і подивимося, що тепер у нас на руках.
Кейноути
Кейноути розпочинають та завершують дні конференції. Зазвичай зміст кейноуту, що відкриває, — задати загальний дух і напрям конференції. Кейноут, що закриває, підводить межу і пояснює, як нам жити з набутими в дні конференції знаннями та навичками. Початок і кінець: те, що запам'ятається найкраще, і взагалі має підвищене значення.
Cliff Click
Кліфф - легенда Java-світу. Наприкінці 90-х років для PhD-тези він написав роботу під назвою , яка через деякий час стала основою HotSpot JVM Server Compiler. Через два роки він уже працював у Sun Microsystems над JVM і показав усьому світу, що JIT має право на існування. Вся ця історія про те, що Java — один із найшвидших сучасних рантаймів із найрозумнішими та найшвидшими оптимізаціями пішла саме з Кліффа Кліка. На самому початку вважалося, що якщо щось доступне статичному компілятору — це можна навіть не намагатися джитити. Завдяки роботам Кліффа та команди, всі нові мови почали створюватися з ідеєю про JIT-компіляцію за умовчанням. Безперечно, це була робота не для однієї людини, але Кліфф відіграв у ній дуже важливу роль.
У Кейноуті, що відкриває, Кліфф розповість про інше своє починання — , in-memory платформі для розподіленого та масштабованого машинного навчання для промислового застосування. А точніше - про розподілене сховище пар "ключ-значення" всередині неї. Це дуже швидке сховище з масою цікавих властивостей (точний список є в ), які дозволяють використовувати подібні рішення у математиці стримінгу великих даних.
Ще одна доповідь, з якою виступить Кліфф. . Інша частина його біографії – десять років , де він оновив і покращив багато всього в залізі та стеку технологій Azul: JIT-компілятори, рантайм, тредовую модель, обробку помилок, роботу зі стеком, апаратні переривання, завантаження класів тощо — ну, ви зрозуміли.
Найцікавіша частина почалася, коли вони зробили залізо для великого бізнесу – суперкомп'ютер для запуску Java. Це була досить інноваційна штука, заточена саме під Java, яка має спеціальні вимоги — бар'єри пам'яті на читання для низькопаузного складання сміття, масиви з перевіркою кордонів, віртуальні виклики… Одна з найкрутіших технологій — апаратна транзакційна пам'ять. Весь L1 будь-якого з 864 ядер міг брати участь у транзакційному записі, що особливо важливо для роботи з блокуваннями в Java (synchronized-блоки можуть працювати паралельно, доки немає реального конфлікту з пам'яті). Але гарна ідея розбилася про сувору реальність — і в цій доповіді Кліфф розповість, чому HTM та STM не дуже добре підходять для практичних потреб багатопоточних обчислень.
Michael Scott -
- Професор Computer Science в Рочестерському університеті, з яким доля пов'язала його , а в рідному університеті Wisconsin-Madison був деканом протягом п'яти років. Він займається дослідженнями в галузі паралельного та розподіленого програмування та дизайну мов та навчає цьому студентів.
Весь світ знає Майкла завдяки підручнику , останнє видання якого вийшло порівняно недавно – 2015 року. Його робота отримала як одне з найбільш відомих у галузі розподілених обчислень та в онлайн-бібліотеці Рочестерського університету. Також ви можете знати його як автора того самого алгоритму Майкла-Скотта з .
Що стосується Java-світу, то тут випадок особливий: разом із Doug Lea він розробив ті неблокуючі алгоритми та синхронні черги, на яких працюють бібліотеки Java. Саме про це і буде кейноут "Dual data structures" - впровадження цих структур у Java SE 6 дозволило в 10 разів покращити продуктивність java.util.concurrent.ThreadPoolExecutor. Якщо вам заздалегідь цікаво, що таке «Dual data structures», то про це є .
Maurice Herlihy -
- Володар цілих двох премій Дейкстри. Перша - за роботу з (Brown University), і друга, свіжіша — (Virginia Tech University). Премію Дейкстри дають за роботи, значущість та вплив яких були помітні протягом не менше десяти років, і, очевидно, Моріс — один із найвідоміших фахівців в області. На даний момент він працює професором у Браунівському університеті та має безліч досягнень на цілий абзац завдовжки.
На цьому кейноуті Моріс розповість про теорію і практику блокчейнових розподілених систем з точки зору класики розподілених обчислень і про те, як це спрощує безліч пов'язаних проблем. Це доповідь виключно за темою конференції — зовсім не про майнінговий хайп, а скоріше про те, як наші знання можна вражаюче ефективно і доречно використовувати стосовно різних завдань.
У липні 2017 року Моріс вже приїжджав до Росії на школу SPTDC, брав участь у мітапі JUG.ru, і запис можна переглянути на YouTube:
Основна програма
Далі буде невеликий огляд доповідей, що увійшли до програми. Частина доповідей тут описана докладно, частина більш коротко. Довгі описи дісталися, в основному, англомовним доповідям, які вимагають посилань на наукові роботи, терміни на Вікіпедії тощо. Повний список можна . Список на сайті оновлюватиметься та доповнюватиметься.
Leslie Lamport
Леслі Лемпорт - автор основних робіт у розподілених обчисленнях. розшифровується як "Lamport TeX". Це він уперше, ще 1979 року, ввів поняття , а його стаття здобула премію Дейкстри.
Це найнезвичайніша за форматом частина програми, бо це навіть не доповідь, а сесія запитань та відповідей. Коли значна частина аудиторії вже знайома (чи може познайомитися) з різноманітними роботами, заснованими на «теорії Лемпорта», його власними статтями та доповідями, важливіше витратити весь доступний час на пряме спілкування.
Ідея проста - ви дивитеся на YouTube дві доповіді: и і готуєте бодай одне запитання, а Леслі відповідає.
Перше з цих двох відео ми вже . Якщо у вас немає часу на перегляд відео, можна швиденько прочитати все це у вигляді тексту.
На замітку: на YouTube є набагато більше відео з Леслі Лемпортом. Наприклад, є чудовий . Оффлайн-версія всього цього курсу є на , а на YouTube він його перелив для зручнішого перегляду на мобільних девайсах.
Martin Kleppmann
Мартін Клеппманн — дослідник у Кембриджському університеті, який працює над CRDT та формальною верифікацією алгоритмів. Книга Мартіна , опублікована у 2017 році, виявилася дуже успішною та потрапила до списків бестселерів у галузі зберігання та обробки даних. Кевін Скотт, CTO в Microsoft, : «Ця книга має бути обов'язковою для інженерів-розробників Це рідкісний ресурс, що поєднує теорію та практику, що допомагає розробникам розумніше дизайнувати та реалізовувати інфраструктуру та системи обробки даних». Щось схоже говорив і автор Kafka і CTO Confluent, Джей Крепс.
Перш ніж зайнятися академічними дослідженнями, Мартін працював в індустрії і став співзасновником двох успішних стартапів:
- Rapportive, присвячений відображенню соціального профілю контактів із вашої електронної пошти, який LinkedIn купили у 2012 році;
- Go Test It, сервіс автоматичної перевірки веб-сайтів у різних браузерах, який RedGate купили в 2009 році.
Загалом, Мартін хоч і менш відомий, ніж наші кейноутери, але вже зміг зробити певний внесок і в розвиток розподілених обчислень, і в індустрію.
У цій доповіді Мартін розповідатиме про тему, ближчу до його академічних досліджень. У Google Docs та схожому софі для спільного редагування документів, «спільне редагування» означає завдання реплікації: кожен користувач має власну репліку загального документа, яку вони потім змінюють, і всі зміни надсилаються по мережі іншим учасникам. Зміни документів в офлайні призводить до тимчасової неконсистентності документа щодо інших учасників, і пересинхронізація вимагає обробки конфліктів. Саме для цього існують (CRDT), по суті, досить нова штука, суть якої сформулювали лише в 2011 році. У цій доповіді обговорюється, що відбулося відтоді у світі CRDT, якими є останні досягнення, обговорюється підхід до створення local-first додатків взагалі та використання опенсорсної бібліотеки зокрема.
Наступного тижня ми опублікуємо на Хабрі велике інтерв'ю з Мартіном, що буде цікаво.
Pedro Ramalhete
Педро працює в Cisco і розробляє паралельні алгоритми останніх років десять, включаючи механізми синхронізації, lock-free і wait-free структури даних і все, що ви можете представити на цю тему. Його поточні наукові та інженерні інтереси сфокусовані на Universal Constructions, Software Transactional Memory, Persistent Memory та подібних технологіях, що дозволяють реалізовувати коректні, масштабовані та стійкі до відмови. А ще він автор широко відомого у вузьких колах блогу .
На паралельних структурах даних зараз працює більшість багатопотокових додатків, починаючи з використання черг повідомлень між акторами і закінчуючи індексованими структурами даних у key-value сховищах. У Java JDK вони успішно працюють протягом багатьох років, та й у C++ потихеньку додаються.
Найпростіший спосіб реалізувати паралельну структуру даних - послідовна (однопотокова) реалізація, в якій методи захищені м'ютексами. Це доступно будь-якому джуну, але має очевидні проблеми з масштабуванням та продуктивністю. У той же час, lock-free і wait-free структури даних не тільки краще справляються з помилками, але й мають більш вдалий профіль продуктивності — проте, для їхньої розробки потрібна глибока експертиза та адаптація під конкретний спосіб застосування. Одного неправильного рядка коду вистачить, щоб усе зламати.
Як зробити так, щоб навіть неексперт зміг дизайнувати та реалізовувати такі структури даних? Відомо, що будь-який послідовний алгоритм можна зробити безпечним за допомогою або , чи транзакційної пам'яті. За одним вони можуть знизити поріг входу у вирішення цього завдання. Однак обидва рішення, як правило, призводять до неефективної реалізації. Педро розповість про те, як їм вдалося зробити ці конструкції ефективнішими і як їх можна використовувати для своїх алгоритмів.
Heidi Howard -
Хайді Говард – як і Мартін, дослідник розподілених систем у Кембриджському університеті. Її спеціалізація - консистентність, стійкість до відмов, продуктивність і розподілений консенсус. Вона найбільш відома узагальненням алгоритму Paxos під назвою .
Нагадаємо, що - Сімейство протоколів для вирішення завдання консенсусу в мережі ненадійних обчислювачів, в основу яких лягли роботи Леслі Лемпорта. Таким чином, одні наші доповідачі працюють над завданнями, запропонованими іншими нашими доповідачами — і це чудово.
Можливість знайти консенсус між кількома хостами – для адресації, вибору лідера, блокування чи координації – є фундаментальним питанням сучасних розподілених систем. Paxos зараз є основним способом вирішення завдань знаходження консенсусу, і навколо нього проводиться безліч досліджень з метою розширення та оптимізації алгоритму під різні практичні потреби.
У цій доповіді ми переглянемо теоретичну основу Paxos, послаблюючи початкові вимоги та узагальнюючи алгоритм. Ми побачимо, що Paxos, по суті, є лише одним із варіантів серед величезного спектру підходів до консенсусу, і що інші точки спектру також дуже корисні для побудови хороших розподілених систем.
Alex Petrov -
Алекс — спеціаліст з баз даних та систем зберігання, і що важливіше для нас — коммітер у . Разом з O'Reilly він зараз працює над книгою Database Internals.
Для систем з (в російськомовній термінології — «узгодженістю в кінцевому рахунку»), після падіння вузла або поділу мережі, потрібно вирішити наступну дилему: чи продовжувати виконувати запити, пожертвувавши консистентністю, чи відмовити в їх виконанні і пожертвувати доступністю. У такій системі кворуми, що перекриваються підмножиною вузлів і гарантують, що принаймні один вузол міститиме останнє значення, можуть стати хорошим прикордонним рішенням. Можна пережити збої та втрату з'єднання до деяких вузлів, продовжуючи відповідати найсвіжішими значеннями.
Проте все має свою ціну. Кворумна схема реплікації означає підвищену вартість зберігання: необхідно зберігати надлишкові дані на кількох вузлах відразу, щоб гарантувати достатньо доступних копій на момент виникнення проблеми. Виявляється, можна не зберігати всі дані на всіх репліках. Можна зменшити навантаження на сховище, якщо тримати дані лише на частини вузлів, а для сценаріїв обробки збоїв використовувати спеціальні ноди (Transient Replica).
Під час доповіді ми розглянемо , схему реплікації використовувану в и , та реалізацію цієї концепції в Apache Cassandra під назвами .
Дмитро В'юков -
Дмитро – розробник у Google, який працює над динамічним тестуванням C/C++ та Go – Address/Memory/ThreadSanitizer, та над схожими інструментами для ядра Linux. Законтриб'ютил у Go масштабований планувальник горутин, network poller та паралельний збирач сміття. Є експертом у багатопоточності, автором дюжини нових алгоритмів, що не блокують, і є власником Intel.
Тепер трохи про саму доповідь. У мові Go є нативна підтримка багатопоточності у формі горутин (легких тредів) і каналів (черг FIFO). Завдяки цим механізмам користувачам дуже легко та приємно писати сучасні багатопотокові додатки, і це виглядає як магія. Як ми розуміємо, ніякої магії тут нема. У цій доповіді Дмитро заглибиться у тонкощі роботи планувальника Go та покаже секрети реалізації цієї магії. Спочатку він дасть огляд основних компонентів планувальника, розповість, як він працює. Далі ми ближче познайомимося з окремими аспектами на кшталт стратегії паркування/розпарковування та обробки блокуючих системних викликів. Зрештою, Дмитро трохи розповість про можливі покращення у планувальнику.
Дмитро Бугайченко
Дмитро майже 9 років пропрацював в аутсорсингу, не втрачаючи контакту з університетом та науковим середовищем. Аналіз великих даних в Однокласниках став для нього унікальним шансом поєднати теоретичну підготовку та науковий фундамент із розробкою реальних, затребуваних продуктів.
Розподілений аналіз графів був і залишається складним завданням: коли виникає необхідність отримати інформацію про зв'язки сусідньої вершини, дані часто доводиться переганяти між машинами, що призводить до збільшення часу виконання та навантаження на мережну інфраструктуру. У цій доповіді ми побачимо, як можна отримати суттєве прискорення обробки, використовуючи ймовірні структури даних або факти на кшталт симетричності графа дружб у соціальній мережі. Все це ілюструється прикладами коду Apache Spark.
Денис Рисцов
Денис - розробник , експерт у галузі перевірки моделей консистентності, в алгоритмах консенсусу та у розподілених транзакціях. Зараз він працює в Microsoft, а до цього займався розподіленими системами в Amazon та Yandex.
У цій доповіді ми познайомимося з протоколами розподілених транзакцій, придуманими за останні кілька років, які можна реалізувати на стороні клієнта поверх будь-якого сховища даних, що підтримує умовне оновлення (compare and set). Суть у тому, що життя не закінчується двофазним коммітом, транзакції можна додати поверх будь-яких баз даних - на рівні програми, але різні протоколи (2PC, Percolator, RAMP) мають різні трейдоффи і не даються нам безкоштовно.
Олексій Зінов'єв
Олексій () — наш давній спікер та член програмних комітетів на інших конференціях. Практикуючий тренер у компанії EPAM Systems, і з Hadoop/Spark та іншою бігдатою товаришує з 2012 року.
У цій доповіді Олексій розповість про проблеми адаптації класичних алгоритмів машинного навчання для виконання у розподіленому режимі на основі свого досвіду роботи з Apache Spark ML, Apache Mahout, Apache Flink ML та досвіду створення Apache Ignite ML. Також Олексій розповість про реалізацію розподілених ML-алгоритмів у цих фреймворках.
І на завершення – дві доповіді від компанії Yandex про Yandex Database.
Владислав Кузнєцов
Владислав – розробник в Яндексі у групі розподіленої платформи. Yandex Database — горизонтально масштабована георозподілена стійка до відмови СУБД, що витримує відмову дисків, серверів, стійок і датацентрів без порушення консистентності. Для забезпечення стійкості до відмов застосовується власний алгоритм досягнення розподіленого консенсусу, а також ряд технічних рішень, які детально розглянуті в доповіді. Доповідь може бути цікавою як розробникам СУБД, і розробникам прикладних рішень з урахуванням СУБД.
Семен Чечерінда
Семен – розробник у групі розподіленої платформи в Яндексі, працює над можливістю мультиарендного використання інсталяції YDB.
Yandex Database розрахована на OLTP-запити та відповідає вимогам ACID до транзакційної системи. У доповіді розглянемо алгоритм планування транзакцій, що лежить в основі транзакційної системи YDB. Розберемо, які сутності беруть участь у транзакціях, хто призначає транзакціям глобальний порядок, як досягається атомарність транзакцій, надійність та суворий рівень ізоляції. На прикладі поширеного завдання розглянемо реалізації транзакцій із застосуванням двофазного комміту та детерміністичних транзакцій. Обговоримо їх відмінності.
Що далі?
Програма конференції продовжує наповнюватись новими доповідями. Зокрема, ми чекаємо на доповідь від Микити Коваля () з JetBrains та Олега Анастасьєва () з компанії Однокласники. Микита займається алгоритмами для корутин у команді Kotlin, а Олег розробляє архітектуру та рішення для високонавантажених систем у платформі компанії Однокласники. Крім того, є ще один умовно порожній слот, з кандидатами на який зараз працює програмний комітет.
Конференція Hydra відбудеться 11-12 липня у Санкт-Петербурзі. Квитки можна . Звертаємо увагу на наявність Online-квитків — якщо ви чомусь не можете наживо дістатися Пітера в ці дні.
Зустрінемось на Hydra!
Джерело: habr.com