В моей работе над моделью личности - важный этап: опубликована книга "Инженерная модель личности. Меняя себя и других – понимай устройство". Доступна на ридеро https://ridero.ru/books/inzhenernaya_model_lichnosti/ и других площадках. Можно не только читать электронно, но и заказать печать по требованию в бумажном виде, но я не дорабатывал презентации под черно-белый вариант. По сравнению с серией статей, которую я публиковал зимой, в книгу включен ряд моделей, доработана структура и отдельные разделы на основе обсуждения статей и докладов по теме. Читайте! Исходные статьи по-прежнему доступны на vc.ru, а оглавление здесь https://mtsepkov.org/Self-Det

Забавно. Практически сразу после публикации книги - на складчине появился сбор денег на мою книгу, чтобы получить ее по 35 рублей вместо 380. Те, кто откликаются - такие нищие или такие жадные?

При подготовке книги «Инженерная модель личности» я описал ряд моделей, на которые мне указали при обсуждении статьи «Спиральная динамика, Big Five и другие модели ценностей»: модели базовых ценностей Шолома Шварца и корпоративных культур Шнайдера, а также карты культур Хофстеде и Инглхарта-Венцеля. И сейчас опубликовал этот материал отдельной статьей с логичным названием «Модели ценностей – продолжение» https://vc.ru/hr/1228187, думаю этот материал интересен сам по себе. И хочу напомнить, что книга доступна на ридеро https://ridero.ru/books/inzhenernaya_model_lichnosti/ и других площадках, в ней статьи собраны, дополнены и несколько реструктурированы. А оглавление серии статей доступно на моем сайте https://mtsepkov.org/Self-Det

Сообщество аналитиков Петербурга летом традиционно проводит плов-пати. Я живу в Москва и обычно не попадаю, но в этом году дата оказалась рядом с конференциями Saint Highload и Saint Teamlead, так что у меня сегодня получилось съездить. Было замечательно: - весть день на природе, много общения и вкуснющий плов. Спасибо Владу за организацию.

P.S. Для тех кто не в курсе - ссылка на пост с приглашением на канале сообщества https://news.1rj.ru/str/spbcoa/79033 Оно, конечно, прошло, но в будущем году будет снова. И у сообщества много других активностей - вдруг кто-то о нем не знает.

#Highload Олег Коровин. GraphQL: зачем на самом деле он нужен. Apollo Federation — дар бога. По этому докладу у меня возникла ассоциация с историей. Когда-то давно были базы данных без SQL, только работа с таблицами, и все join надо было вручную писать в коде. Z это еще застал. Потом пришел SQL и проблема была решена. Сейчас это повторяется: микросервисная аргиюетура разложила объекты о сервисами, для каждого есть свой набор API. GrapgQL позволяет объединять данные из разных узлов в единую схему и делать общие запросы. При этом тогда разработчики относились к появившемуся SQL настороженно: это же накладные расходы, сложно и непривычно. Так и сейчас к GraphQL относятся настороженно как к хипстерской поделке, которая не нужна "настоящим программистам" - OpenAPI достаточно. Докладчик показывал, как GraphQL решает проблемы, сокращает объем кода, делает его более компактным. А также - как решаются проблемы контроля доступа, единой точки отказа и безопасности. Решение GraphQL - легкое и масштабируемое, федерации - stateless, и можно поднимать разные федерации для разных клиентов, подключая только необходимые им сервисные данные. И страивать параллельный доступ для миграции, поднимая федерацию для доступа, но запуская через нее только новые запросы. Тут ситуация выгодно отличается от того, что было с миграцией на SQL-базы данных - там это можно было сделать только целиком. На мой взгляд, получился очень удачный доклад.

#Highload Роман Щербаков из Тинькофф. Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны. Рассказ об организации высокой доступности для инфраструктурных потоков: логов, метрик, трейсов. 450 Мб/сек. Целевые хранилища там разные, а архитектура - общая. В докладе - много архитектурных схем, это надо смотреть презентацию. А тут мое краткое резюме принципов.
* Данные пишутся в том же дата-центре, в котором создаются, то есть в каждом - свой набор pipeline, и там же они остывают. А поиск - по всем датацентрам.
* Надо вести мониторинг обращений клиентов и уметь отделять тех, у кого особая нагрузка в отдельный pipeline, с которым отдельно разбираться.
* Worker записи от клиента пишет в Kafka, из которой читает Worker записи в хранилище. И worker записи работает в том темпе, в котором комфортно для БД. Kafka буферизует колебания нагрузки записи. А worker записи делает пакетную запись.
* Отказ операции - нормально. Особые случаи откидываем в отдельную retry-очередь, а если retry не проходит - в очередь ошибок, с которой разбираются вручную. Retry однократный, он на случай, если что-то моргнуло, а если что-то упало - то retry вреден. И такая схема обеспечивает оперативное поступление данных, с которыми все хорошо.
* Если база или узел деградировал - его надо отрубить, для этого фиксировать, что пошли массовые ошибки, для этого Circuit breaking pattern. Аналогично работает bulkhead pattern - ограничение на конкурентные обращения. Это бережет БД.
* Таймауты надо настраивать. Есть бюджет обработки от кафки - таймаут опроса очереди, при превышении которого она считает, что consumer отвалился, и в него надо укладываться, включая все таймауты. И для основного потока там жесткие настройки, а для retry и ошибок - свои.
* Для метрик основной поток пущен напрямую, без kafka, так как на стороне клиента обычно prometheus и у него есть свои буфера. И это экономит. Но при деградации - включается полная схема.

#Highload Николай Никитин из ИТМО. Как обеспечить воспроизводимость научных исследований в AI/ML с помощью Open Source? Основной тезис доклада, на мой взгляд, остался за рамкой: смысл научного исследования в том, что его результаты могут быть использованы другими в своих разработках. Именно это подразумевается под воспроизводимостью, не ограничиваясь просто проверкой результатов. Для Николая это тезис очевиден, в то время, как в социальных реалиях современной науки это далеко не так. Если же принять этот тезис, то для современных исследований, особенно в области AI/ML, просто публикации статьи недостаточно, к статье должен прилагаться код и наборы данных, которые обеспечат легкое использование результатов, включая его проверку, но не ограничиваясь ей. В open source есть площадки для этого. Но ученые - не программисты, разработка и создание open source для них - не профильная работа, получается довольно высокий порог входа, который полезно снизить. Они в 2020 годы в ИТМО начали это делать, и сейчас у них 10+ различных проектов. Был более подробный рассказ про фреймворк FEDOT. Тут есть особенности, связанные с тем, что есть 2-3 человека в ядре команды и ассоциированные стажры, которые делают студенческие работы. Но для успеха ядро должно быть увлеченным, в том числе проводить менторинг для студентов - и административно это не масштабируется. Такие проекты делают пиар, показывают что университет способен достигать серьезных результатов. Однако, несмотря на это уровень энтузиазма довольно велик. Тут есть вопрос финансирования, если на новые версии его еще можно получить, то на поддержку - не получается. Но сейчас есть возможность получить гранты, и то, что продуктом будет не просто публикация. а open source эксперты оценивают. И коммерческие компании тоже становятся толерантными к выкладке результатов в open source, хотя тут это каждый раз вопрос переговоров. Лично я желаю ИТМО всяческих успехов, и надеюсь, что этот опыт будет распространяться.

#Highload Иван Чернов (Островок). Как работать с поставщиками на примере поиска доступных отелей. Чем отличается Островок от Букинга? В силу своей позиции на рынке букинг может от отелей потребовать работать в своей админке, описывать там условия отелей, и резервирование проводить внутри. А еще у него каждый отель представлен однократно. Хотя у каждого отеля есть своя система управления номерами, они очень разные, но проблемы интеграции их с букингом он отдает отелю. Островок сейчас работает как агрегатор, отели продаются через разные каналы, островок все это забирает и предлагает наиболее выгодные цены. В им надо при резервировании получать подтверждение отеля. А еще им важно кешировать запросы, чтобы сокращать число обращений к системам отелей. При этом учитывать, что данные устаревают. Динамика не столь высокая, как для динамического ценообразования в такси, но довольно высокая, при этом сильно различается в зависимости от спроса на конкретный период. При этом у отелей свое ценообразование, для раннего заказа могут быть скидки, для длинных сроков проживания тоже, плюс посредники, предлагающие отели, предлагают скидки по своим правилам. То есть ключ запроса - длинный, включает много данных. В докладе был рассказ про архитектуру решения для кеширования. Использовался redis, но там были сложности, связанные с большими ключами и большим объемом возвращаемых данных. Поэтому перешли на aerospike. В какой-то момент тоже отвалился, при разборе оказалось, что есть два вида ответов: описание доступных номеров и просто отказ, что номеров нет, без информации. И они разделили эти кэши, для кеширования отказов вернулись к redis, в котором использовали фильтр Блума. И тут сои хитрости, потому что некоторые поставщики, если у них проблемы, делают вид, что сервис работает, просто он перестает выдавать доступные номера, и эту ситуацию надо ловить, чтобы временно переставать обращаться. В целом - это был рассказ о решении задачи, в которой у авторов появилась довольно витиеватая схема. Ну и попробовали альтернативу redis.

#Highload Максим Метальников, Максим Смоляков из SberDevices. Особенности и вызовы реализации технологии создания готовых музыкальных произведений с применением ИИ. Ребята рассказывали о том, как можно собрать pipeline синтеза песни из различных инструментов ИИ. Фазы pipeline: идея - текст <-> основная мелодия - аранжировка - запись вокала и инструментов - сведение и мастеринг. При этом основная мелодия тоже порождается в несколько тактов: ритм - ноты, и вокал тоже создается этапами. Для каждой фазы подробно рассказывали, какие инструменты использовали, какие там датасеты. И сопровождали это сквозным примером, придуманная на первом этапе ИИ песня в стиле киберпанка. Кроме того, человек может какие-то этапы взять на себя, например, исполнить текст или какую-то партию. Подробнее - смотрите презентацию и запись. По общему впечатлению от результата - нужны необходимые ручки для ручного вмешательства. Поэтапная технология это позволяет, в отличие от генерации готового аудио сразу. И, более того, на ряде этапов у авторов было многослойное представление, например, ритм - ноты - акценты исполнения, или для вокала - слоги, длительности, акценты. И, думаю, этим векторам можно прикрутить понятные ручки управления для снятия шероховатостей. Но пока не сделано.

#Highload Филипп Дельгядо. Enterprise deploy: почему это больно. Рассказ о технике повышения безопасности деплоя. Особенно важно это для enterprise-решений, которые разворачиваются у клиента: мы не контролируем процесс обновлений и их использование.

Когда-то были монолиты, которые для обновлений останавливали. Сейчас у нас много экземпляров серверов, которые работают с общей базой данных, которая тоже может быть в нескольких экземплярах, и остановить работу для изменения невозможно. Изменения правильно делить не на совместимые и несовместимые, а по безопасности: почти безопасные, возможно опасные и точно опасные. Создать новую таблицу - безопасно. Добавить поле - практически безопасно, но требует краткой блокировки таблицы, и на смеси olap и oltp транзакций под высокой нагрузкой это может выстрелить: oltp задержат дольше допустимого. А создание индекса во многих базах блокирует таблицу надолго, а в PostgreSQL есть специальные методы, как это сделать безопасно, ими надо владеть. Добавление нового значения в enum - опасность больше, надо разбираться с работой старых сервисов с объектами, у которых новое значение. Может быть, что такие записи в них в принципе не попадут, но это всегда не точно.

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

Теперь от базы данных к взаимодействию сервисов. В случае синхронного взаимодействия (http, grpc) применяем:
* Версионирование по методам, а не целиком.
* Изменения окружаем флагами для котроля нового поведения
* Используем тольо безопасные изменения внутри endpoint
* Маршрутизация запросов - чтобы метод получал только понятное
* Контроль жизненного цикла: состояния draft, unstable, deprecated. C разными обязательствами.
* Нужен инструмент управление фича-флагами: рассылка по сервисам, контроль зависимостей, канареечные флаги вместо разнесения по узлам сети, удаление неактуальных флагов

Асинхронные взаимодействия через очереди. Тут нет мгновенного изменения, в очереди живут необработанные события старых версий. И на них нельзя запустить обновление, они придут в виде, в котором посланы. Мы не всегда знаем участников взаимодействия - что читает, кто пишет. И делать версии событий базовые инструменты не позволяют. И тут хороших решений нет.
* Самое простое - новый топик для новых событий. Но при этом мы теряем порядок и партиционирование, нужно сложное переключение и администрирование.
* Сначала обновляем консьюмеров, потом продьюсера. Тогда сервисы перестали быть автономны по деплою, и пояляются проблемы с откатом консьюмеров - для этого надо отвалить продьюсер. Частичное решение - фича-флаг в продьюсере, но то, что в очереди - лежит.
* Отправка нескольких версий - и консьюмер выбирает нужную. Это сложно в реализации, потому что стандартные способы передачи и контроля перестают работать - у вас несколько схем на одно событие, например.
* Можно возложить маршрутизацию на service mesh - чтобы он отправлял на нужных консьюмеров.

А еще - можно не делать асинхронное. Вам нужно сглаживать пики - уберите этот буфер внутрь сервиса, а не располагайте между.

Документация: политики совместимости, сценарии обновления, взаимодействия, особенно неформальные, поверх архитектуры.
Тесты: процесса миграции (непросто, это end2end с фоном), частичной работоспособности, откат обновлений
Инструменты: менеджер миграций, управление фича-флагми, управление выкладкой (подождать полчаса и посмотреть логи). Можно делать обновление поверх jenkins, но им пришлось сделать свое - они не могут потребовать от клиентов поставить и сопровождать Jenkins

#Highload Чему нас учит черный квадрат и причем здесь программирование. Это была идея Олега Бунина: расширить сознание и посмотреть на другую область. Основной рассказ вел Александр Кибасов (Doctrina et Nobiles), а Олег и Вирна Штерн давали реплики и повросы. А тема Малевича была выбрана потому, что онтико использует стиль супрематизма в оформлении презентаций, а с этого года еще начала делать сувенирку - матрешки, расписанные в этом стиле как приз за лучшие вопросы, докладчикам и членам ПК.

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

Итак, тезисы Александра о Малевиче, супрематизме и искусстве в целом. Отмечу, что он в лекции не разделял явно то, что Малевич говорил явно от позднейших интерпретаций.
* До Малевича искусство - это голые или обнаженные женщины, пейзажи или сюжеты с пресонажами, и для понимания предполагалось знание контекста. Малевич черным квадратом сломал этот стереотип, и сделал искусство без явного смысла и контекста, а для прямого восприятия.
* Искусство предназначено для созерцания, а не для интерпретаций и смыслов. Оно не должно иметь смысла, и это - правильно. Идея бессмысленного жеста - спасительна. Потому что жизнь полна смысла. В чем смысл жизни? Конечно, чтобы ходить к вам на работу. Искусство без смысла разрывает такую логику.
* Искусство без смысла, для созерцания - слом мира мещан, которые везде искали смысл, потому что так принято.
* Черный квадрат сломал элитарность художников: черный квадрат может нарисовать любой, он не требует мастерства. При том, что у Малевича мастерство - было.
* В те времена Петербургская и Московская академии каждый год выпускали художников с классическим подходом, их было много. Черный квадрат ломал традицию.
* Были последователи, ученики и те, кто тоже творил и творит в том стиле. Есть художник, который рисует синие картины, просто закрашивает одним цветом, есть - кто черные, устраивают выставки.
* Кандинский - как Малевич, но для тех, кто любит цвета. Вкусы различны, одним нравится кока, другим - пепси. У него еще была бредовая конструкция, как его картины работают и какие эмоции вызывают.
* После Малевича было еще три соразмерных события. Фонтан Мишеля Дюшана (1917) - нестандартно повешенный писсуар: главное, идея, а создавать предмет не обязательно, можно взять готовый, мастерство не нужно вообще. Один и три стула Джозева Кошута (1965) - инсталляция: стул, его описание и его фото; идея - язык - не рабочая структура, он не передает смыслы, провал коммуникации. И Дерьмо художника Пьетро Мандзони (1961) - вообще подвешивает сферу искусства как таковую.

Теперь мои комментарии, тоже в виде тезисов.
* У черного квадрата и последовавшего за ним направления супрематизма был вполне утилитарный смысл: для славы надо было отличаться от других, причем сильно. За счет мастерства это не получается, оно есть, но не экстра-уровня - значит делаем оригинально. Прием не новый, кто-то из скульпторов, творивших в Италии после возрождения ввел в моду барельефы, где фигуры едва намечены, почти рисунок на мраморе - чтобы отличаться от глубоких барельефов Возрожедния, которые уже у всех были. Здесь логика - та же.
* Как мне рассказали после лекции, первый черный квадрат был вполне утилитарной вещью - это часть декорации к спектаклю, где такая картина, наверное, была уместна по замыслу. А дальше - идея зацепила.
* Очень забавно: Чехов критикует мещан за отсутствие смысла, а Малевич - за то, что они везде ищут смысл. Хотя тут можно понять: у тех, кого называли мещанами, понятный смысл жизни из простых человеческих радостей. Они не ищут высокого предназначения, и не признают непонятное, художнику с ними сложно. Это целенаправлено разрушали, и в 1920-е, пока основным мотивом в СССР было низвержение старого супрематизм был в почете. А потом пошли эпоха, когда потребовалось конструирование нового.
* По сути, супрематизм - начало движение деконструкции смыслов. Тогда оно было в форме протестов против предписываемой традицией формы, которая застыла настолько, что тоже была лишена смысла. Но позднее, во второй половине 20 века у деконструкции появилось идеологическое обоснование, и объявлена долгом. И деконструкция искусства - часть этого мейнстрима. В этой концепции ценность искусства определяется замыслом автора и мерой его страдания, оцениваемой по его собственным заявлениям. За подробностями могут оправить в мой пост https://mtsepkov.org/Snowflake и пост https://ivanov-petrov.livejournal.com/2287616.html Это - гораздо более поздняя история, и отдельный вопрос - в каком объеме это было у Малевича, а насколько это - поздние интерпретации. Потому как сейчас любят говорить, что Достоевский воспевал страдающих, а он их не воспевал, он лишь показывал, что бедные - тоже люди, они живут и страдают также как остальные, сообщение было другим.

На этом все. В комментариях можно обсуждать подробнее. Или очно на конференциях.

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

#Highload Владимир Комаров из СберТех. О распределенных транзакциях. Очень хороший доклад с обзором различных механизмов распределенных баз данных и транзакций. Проблема Сбера - гигантские БД на уникальном оборудовании. Идея замены была - распределенные БД. Он изучал и был противником, потому что разработчики не разбраются с тем, что внутри БД. И в распределенной БД тоже, поэтому пойдут нежелательные эффекты, и разработчик будет винить вендора или поддержку, а не себя. А если вместо распределенной БД предложены механизмы работы на уровне приложения, то проблемные точки видны. А в докладе - результаты изучения разных БД. И они не только в докладе - Влабимир написал книгу Путеводитель по базам данных, потому что не нашел такого готового обзора. Дальше конспект, он заведомо неполный, и лучше его читать, смотря на презентацию - в ней много архитектурных схем.

Распределенные БД - 5 вариантов.
* Кластеризация монолита. Реплики, бесконечный масштаб чтения, запись - через один узел, и он - точка отказа.
* Распределенный консенсус.
* Безопасные типы данных: структуры, которые заранее рассчитаны на ассинхронные изменения в разных местах, и независимо от порядка синхронизации результат будет одинаков
* Компенсирующие механизмы: мы быстрее запишем, а потом как-нибудь согласуем. Или не согласуем.
* Распределенные транзакции. Когда несколько агентов взаимодействуют и либо подтверждают либо откатывают.

Дальше рассказ про распределенные транзакции. Самое известное - протокол двухфазной фиксации. 1986 IBM System R* - протокол уже назван хорошо известным. Проблема - отказы НЕ предусмотрены: участник может пропасть, но диск - надежен, он всегда возрождается. В 1991 XA specification - все предположения зафиксированы.

Реальные диски выходят из строя. Что с этим можно сделать?
* Разделяемые дисковые механизмы. SAP HANA, Microsoft PDW, Oracle Sharding + RAC (exadata), Teradata. SAP HANA - надо считать состояние, перейти на резервный надежнее, чем на основной.
* Отказоустойчивость всех участников. Google Spanner.
* Смириться, что можно потерять часть участников. GreenPlum. Координатор дублирован, а других узлов много, и не страшно потерять один.
* При сбое разбирать последствия остальными. Apache Ignite (координирует тот, кто начал транзакцию), Hazelcast - общение и восстановление сбойной.

А еще двухфазная транзакция - два сетевых обмена, и это - время.

Однофазная транзакция. Если мы понимаем, что завершили на ответственном участнике - то на этом и закончили.
* Oracle sharding - драйвер клиента
* GrinGain - решение координатора транзакции
* SAP HANA - координатор сообщает, к каком узлу присоединиться
* Hazelcast - клиент-приложение должен завершить и отвечает, что меняет на одном узле

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

2012. Детерминированные транзакции, Кальвин-машина. Название - в честь Кальвина, который говорил про предопределение как замысел Бога, которому следует все живаое. Роль Бога тут выполняют клиенты. система пишет журнал их действий и применяет на всех серверах, получая детерминированный результат. Транзакция - набор чтений и записей, и при чтении в журнале фиксируется версия объектов, при повторении журнала это контролируется. То есть оптимистичные блокировки. Есть секвенсер, который пишет журнал. Если кто-то не может - сообщает остальным.

Ограничения подхода:
* низкоконкурентная среда, потому как оптимистические блокировки.
* задержки, сбор транзакций в пачку 10мс
* архитектурные компромиссы и оптимизации - пекетные передачи и т.п.

YDB. добавлены компромиссы.
* Между секвенсерами и участниками - медиаторы, ограничение обменов.
* Разрешение на изменения порядка операций.
* Слепые транзакции: когда нам не важна версия на чтении, или напрямую записываем в участника
То есть много оптимизаций, которые разработчик должен применять разумно.

Cassandra. Каждый узел сам себе секвенсер. pid+RTC (время)+логическое время. Есть лекция Осипова. Второй узел отвечает, если нет более ранних транзакций. Алгоритм существенно рассчитывает на синхронизацию часов в кластере и учет разбега.

FoundationDB - в нем распределенный менеджер блокировок. Клиент читает данные, выстраивается последовательность изменений и по commit - идем в прокси-сервер. Координатор выдает номер. Дальше прокси говорит "хочу менять ключ", кеш отвечает можно/нельзя. Блокировки протухают через 5 сек, снятие - не нужно.

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

Их подход - сага. Platform V AppSharding. Масштабирование функциональным делением. Если много данных - шардирование. Например, для клиентов - делят, хорошего алгоритма не нашли, явно делят по спискам. Клиента маршрутизируют. L7-маршрутизатор использует межкластерный индекс. Ключ (клиент, сервис), значение - шард. Переводы между клиентами разных шардов - оркестратор, с хранением в Kafka - объект короткоживущий, данные читаются только при сбое, когда восстанавливаем оркестратор.

Хореография. Прекрасна на полотнах Дега и в балете Моисеева. А в финансах - нет. В вопросах была реплика, что это - не так, на биржах -применяется активно.

Облачные БД. Amazon Aurora, Google AlloyDB, MS SQL DB Hyperscale. Облачные БД пишут журналы, а под ним - система хранения, которая накатывает журналы на страницы, в том числе несколько версий страниц, и по необходимости - отдает экземпляру. Все хорошо, кроме сложного деплоя. Доступны только как облачные сервисы.

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

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

#Highload Иван Бондаренко (НГУ) Сильный искусственный интеллект у вас в подвале: как собрать мультимодальную LLM из опенсорса и настроить ее под вашу задачу. Началось все с участия в соревновании Strong Intelligence на AIJ-2023, где надо было сделать ИИ, способный понимать картинки и звуки. Базовую LLM давали организаторы, решение надо было представить в контейнере, дальше организаторы оценивали на своих тестах. Они пошли понятным путем, собрав энкодеры из open source решений. Энкодер - два такта, перекодировка изображения или звуков в вектор параметров, а потом перекодировав вектор параметров в вектор токенов для LLM. В презентации есть подробности - что использовано.

Заняли 14 место из 30, их результат не удовлетворил. И они подумали - а что можно сделать? Анализ показал проблему: энкодеры работают независимо от контекста разговора. И появилась другая идея: сделать общую модель мира во внешней базе данных и искать в нем, создавая контекст разговора, они назвали это припоминанием знаний. Для этого использована китайская ONE-PLANE, которая связывает разные модальности и превращенная в ANNOY-вектор для поиска английская википедия. Дополнительно потребовался генератор коротких подписей к рисункам - его результат фокусирует поиск, распознаватель звуков и преобразователи для речи и других видов звуков. И уже полученный в результате текст подается на вход LLM. В докладе было разобрана механика работы на конкретном примере.

Дальше надо сравнивать результаты с другими. Они сравнивали свои с разными решениями, при этом в качестве арбитра выступал ChatGPT - он оценивал качества ответов разных систем, сравнивал их ответы между собой. Получается относительно объективная метрика. И есть сравнения с разными системами, а также в конфигурациях с разными LLM. B тут оказалось, что основной фокус переносится на этап создания контекста, а мощность LLM уже не столь важна - что существенно для производительности, так как создание контекста - относительно дешевые решения.

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

#Highload Андрей Кузнецов (AIRI) Как научить фундаментальные модели читать, видеть, слышать и анализировать все одновременно. Реально доклад был только включение картинок. Конструкция - та же самая, LLM + энкодеры, с помощью которых описание изображения помещается в общий вектор текста. При этом работает и в обратную сторону, в ответе тоже могут быть токены, описывающие изображения, по которым будет порождена картинка. Решение OmniFusion, выложено в open source в апреле. Решение - открытое, можно подключить свои распознавалки для специфических изображений, например, медицинских снимок или космических. И другие виды тоже можно подключать, на очереди аудио и видео. А еще можно добавлять графы знаний. Они таким образом добавили работу с формулами и LaTeX.

#Highload Сергей Ларионенко (Авито) OpenTelemetry и эволюция распределенного пайплайна трейсинга в Авито. Это песня о том, как, сделав пайплайн на открытых инструментах, они разбирались с потерей 70% трейсов, расшивая узкие горла и делая форки в туле. Проблема началась с обнаружения битых трейсов. Вставили проверку на связность графа - и обнаружили что таких 70%. Начали разбираться. Обнаружили, что на нодах следующая конструкция: много обработчиков пишут в Go-канал, а дальше этот канал вычитывается только одним потоком и передается на другую ноду. Запись в Go-канал - точка синхронизации, буфер канала ограничен. И сделано, что когда в буфер нельзя записать, то пакет просто теряется, и увеличивается статистика сбоев. Только они этого не видят, потому что статистика в конструкторе инициализирована NullFactory. А поток вычитывания работает медленно, потому что там синхронный вызов удаленный вызов по gRpc, и на приемной стороне - приличная обработка. Для решения сделали fork Otel batching, несколько процессов чтения, из которых активен один, но при исчерпании буфера переключаемся на следующий. Массовые сбои ушли, остались индивидуальные, причина - падал коллектор данных. А он падал потому, что там две процедуры: обработка очередного события и оценка, что накопленные события пора отправлять пакетом. И оказалось, что там код написан так, что при одновременном выполнении получается конфликт и все падает. Это тоже поправили. Все заработало.

#Highload Илья Иванов из Яндекс 360. Архитектура биллинга: как не стать единой точкой отказа. В докладе - архитектура биллинга. Она по факту трехслойная. Сам биллинг получает сумму, которую надо списать за услуги, выставляет счета, принимает оплату, выдает чеки и готовит отчеты. Тарификацию ведут пребиллинги, связанные с конкретными бизнесами, в них - тарифы, промоакции и промокоды. А также платежные механики - подписки или другие способы учета. Они зависят от каждого бизнеса, свои для Яндекс 360, Яндекс Плюс, Яндекс Облако и так далее, потому что каждый из них ведет свою тарифную и рекламную политику, которую надо менять независимо от других. Собственно, независимое развитие бизнесов как раз является основанием для такой архитектуры, а вовсе не соображения про точку отказа - централизованный биллинг по-прежнему им является.

Пребиллинг в Яндекс 360 переводит конкретные тарифы в наборы подключенных услуг, которые могут быть подключены индивидуально и для компании, при этом часть услуг для компании переводится в индивидуальные для сотрудников. Добавление услуги инициирует добавление для всех сотрудников, каждое добавление выполняется индивидуально и асинхронно, простая модель состояний init-sinking-actual, поэтому даже при больших организациях 10к+ человек выполняется быстро. Добавление услуги означает обращение к конкретному сервису с установкой там каких-то квот, например, объема доступного диска. И далее этот сервис работает в пределах квоты ресурсов, или количества писем. При этом одни ресурсы, например, диск, выделяются индивидуально, а другие, например количество писем в рассылках, может быть установлено общее, на всех сотрудников компании.

Неявное ограничение модели - не должно быть ситуации, когда несколько сервисов расходуют один и тот же ресурс, или они должны сами проверять его расход, чтобы не было преувеличения. Конструкция биллинга для мобильных операторов, когда все сервисы (звонки, смс, интернет) тратят одни и те же деньги на счете в реальном времени до исчерпания тут не сделать. Но это уже мое дополнение.

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