13 636
правок
Изменения
Нет описания правки
Как я уже пишу каждый раз, включая [[Highload-2022: Отчёт Виталия Филиппова|писалпрошлогодний отчёт]] в прошлогоднем отчёте - — самая крупная и раскрученная конференция Бунина. Финальная стоимость выросла уже аж до 64 тыр с 60, то есть годовая инфляция по версии Онтико в этот раз составила 6.66 %. :-)
'''Общее впечатление:''' Неплохо - "торжество велосипедов" Неплохо — «торжество велосипедов» в докладах, всё как мы любим, но перегруженно. Слишком много народу на эту площадку.
Реально, 3750 человек в Сколково, в котором и проходила конференция - конференция — это перебор. Если чуть более, чем средне-интересный доклад шёл в любом зале, кроме самого большого "Конгресс-холла" «Конгресс- холла» — сесть там было невозможно. Они пытались организовывать какие-то "расширительные бачки" «расширительные бачки» в виде ретрансляций докладов рядом с залами, но это было бесполезно, ибо организовывали не прямо в коридоре, а в маленьких отдельных комнатушках. Какой толк от расширительного бачка на 10 человек, когда не влезло 50...50…
Второй момент - момент — совершенно упоротая топология здания. Поиск нужного зала каждый раз превращался в квест: сначала надо попытаться понять по карте, где ты находишься, решить, в какую сторону идти и с какой стороны всё обходить, а потом ещё иногда искать отдельные лестницы на второй этаж для прохода в некоторые залы (просто подняться в произвольном месте недостаточно). При этом везде столики, стенды, толпы, поэтому даже образовывались заторы и проходы становились полудуплексными. Даже в сортирах был хайлоад. Явно не хватало процессоров на все... все… потоки.
При этом ещё и 11 параллельных залов. Я даже пожалел, что не заявил какую-нибудь хрень на опенсорс-трек - трек — там такую фигню рассказывали, что я бы точно смог не хуже. Не, сама идея опенсорс-трека неплохая, но те доклады бестолковые, на которые я попал, были не очень и хорошо демонстрируют механистический механический подход к опенсорсу: одни рассказывают. Вот, что опенсорс это хорошослышали, потому что признание сообщества, розовые пони и вообще, а вторые - что они попробовали давать по 100$ рандомным разработчикам модулей питона раз в неделю, и профита не обнаружили, но будут ещё пробовать. А третьи вообще вместо рассказа, КАК же они пилят этот самый опенсорс, рассказывают, что они его закрывают и продают как сборник произведений по ГК РФ - это очень важная полезно и интересная информация, которой, конечно, до этого не было ни на одной конференции (тро-ло-ло)пытаются выжать пользу просто из произвольных проектов.
= День 1 =
Полная фигня, 150 полуляхов из 250. Технических деталей работы алгоритма в докладе было крайне мало, просто общая мысль — вот, им ничего готовое не подошло, Raft они почему-то сочли слишком сложным (Raft, сложным?!), поэтому сделали всё сами и на основе другого протокола — Viewstamped Replication аж от целой Бабы Лизы… то есть Барбары Лисков.
Самое смешное, что они на замену Raft-у, который им «показался слишком сложным», выбрали алгоритм, который (А) вообще не отличается от Raft по смыслу и (Б) даже сложнее, чем Raft, в деталях реализации!Это более старый алгоритм! Чувак, который придумал Raft, про этот алгоритм даже в своём диссере писал! В котором он, собственно, и придумал Raft.
Я про VR почитал уже после конфы. Единственное реальное отличие — то, что ноды голосуют не за первого заявившегося кандидата, а за кандидата с минимальным ID (IP-адресом). Всё остальное практически идентично, Raft Term = VR View и так далее. При этом у VR 10 типов сообщений вместо 4-х у Raft-а.
<blockquote>
{{WikiCutBegin|Развёрнутое объяснение под катом, взял [https://groups.google.com/g/raft-dev/c/cBNLTZT2q8o отсюда]}}
With apologies to Barbara, James, and Brian. VR introduced some great
Diego
{{WikiCutEnd}}
</blockquote>
Причём аргументы, согласно которым им не подошли готовые решения, меня лично вообще не убедили. Какое-то расхождение данных и метаданных при использовании внешнего сервиса консенсуса… не, ну писать просто надо нормально, что значит — расхождение. Я же юзаю etcd в Vitastor, брат жив. Ну ладно я, ещё пример — TiDB юзает встраиваемый etcd, брат тоже жив. Всё ещё мало? Patroni/Stolon испокон веков юзают Consul/etcd. Ceph OSD хранят метаданные в Ceph Monitor-ах. Какое расхождение?!
Хоть бы исходники открыли, ё-моё, хоть какая-то польза была бы от этого барсика. А то ну написали тесты, ну пофаззили, ну дополнительно верифицировали на TLA+, ну молодцы. Но какой во всём этом толк, если рядом лежит штук 10 «вот таких же, только меньше, но других», тоже хорошо оттестированных за все эти годы Raft-ов…
== Оптимизации Производительность Go ==
В принципе стандартные вещи, даже не так их много было: * Мелкие объекты — до 32 байт — оптимизируются* Интерфейсы медленнее из-за виртуальных вызовов* Если в массивах срабатывает проверка границ (не срабатывает <abbr title="Bounds Check Elimination">BCE</abbr>) — код замедляется* for по индексам быстрее, чем for по range (подозрительно, stackoverflow говорит обратное — что они не отличаются)* Работа со строками хорошо оптимизирована для частых сценариев == Как привлекать людей в опенсорс-проекты == '''Ксения Романова (Positive Technologies) — Сообщества вокруг технологии: почему быть бесплатным недостаточно"''' Девушка связана с Apache Ignite и фондом Apache (туда ещё проекты умирать часто сдают), сейчас работает у позитивов. Я не уверен, что доклад был именно о том, как я его окрестил, ибо изложение было довольно размытым. Но мне кажется, что это самое близкое. По-моему, она пыталась развивать стереотип о том, что опенсорс — это «бесплатные руки», и надо лучше искать эти бесплатные руки, лучше общаться с людьми и помогать им включиться в проект. «Как бы нам заполучить бесплатных разработчиков». :-) С моей точки зрения — это утопия, хоть я и адепт опенсорса. Времени всем не хватает, видение развития проекта у каждого своё (1 программист пишет программу за 1 месяц, 2 — за 2 месяца), лидеры проекта душнят в пулреквестах, поэтому не стоит рассчитывать, что вы сможете найти серьёзный пул контрибьюторов среди сообщества. Проекты типа Linux — это очень редкие и крутые исключения из правил, так почти никто не умеет. Хотя, кстати, в её родном фонде Apache линукс ещё не факт, что свершился бы — они же не принимают правки от компаний. Всё остальное в докладе — шелуха. Вот… сообщества… технологии… привлекать людей… модель «воронка»… модель «орбита»… людям это надо для чего-то там… компаниям это надо для чего-то там… 80% кода в опенсорс-проектах пишут единичные «герои»… Контрибьюторы классифицируются по 2 осям — качеству кода и любви к проекту… (тут я вообще чуть не взоржал) Из интересного — в конце спросил у неё, а зачем компании сдают проекты в фонд Apache, в чём выгода. Так как, по-моему, проекты туда обычно сдают помирать, на кладбище. Для справки — апачи забирают все права на проект себе и даже потом правки от компаний не принимают — отправлять патчи могут только отдельные физлица-разработчики, даже если они все работают в одной компании. Она ответила, что сдают ради помощи в развитии, типа гайдлайнов/руководств по жизненному циклу проекта и ради готовой инфраструктуры разработки. Ну понятно — Apache пытается строить «завод опенсорса» и на этом в процессе делать деньги. Но вот для сдающей компании особой выгоды, мне кажется, всё-таки нет, так что скорее всего обычно действительно просто «сдают в отстойник».
== Дата скетчи ==
== Шардирование: с нуля до Яндекс Диска Катаем гусей ==
Доклад про Яндексовую реализацию S3 (гусь/goose — это go+s3, название сервера). Глобально всё просто — взят уже готовый надёжный распределённый сторадж для данных, взят шардированный и реплицированный PostgreSQL, одно скрещено с другим и вот вам, пожалуйста, S3. Шардирование раньше было только в виде чанков — диапазонов имён объектов в бакете. Чтобы таскать чанки с шарда на шард — мувер, чтобы порождать новые чанки почкованием — сплиттер. И то, и то — через двухфазный коммит. Но была проблема, что в такой схеме определённые паттерны нагрузки не размазывались по всему кластеру БД. Например, если юзер всегда писал новые объекты в конец бакета — эти вставки всегда попадали в один чанк и, соответственно, шард. Или, например, если юзер сначала делал алфавитный листинг всех объектов, а потом последовательно читал их — такая нагрузка тоже в каждый момент времени попадала только в один шард БД. Поэтому сделали хеш-чанки (диапазоны хешей имён объектов) и такая нагрузка тоже стала размазываться. Был даже график, на котором это было видно наглядно — до переключения на ханки нагрузка шла постоянно то в 1 шард, то во 2, то в 3 и т. п., а после — равномерно во все три. То есть, все три покрашенные разными цветами линии нагрузки в разные шарды сошлись на одном уровне. Кто-то из зала не понял, что на графике изображены не листинги, а обычная нагрузка (то ли GET, то ли PUT), и спросил, так это что же, теперь листинги грузят все шарды? По факту с этим проблем нет, так как, во-первых, запрос листинга в S3 ограничен 1000 записей, во-вторых, и до перехода на ханки запросы листинга часто попадали в несколько шардов — в тех случаях, когда нельзя точно сказать, что 1000 записей можно вернуть из 1 шарда, а в-третьих, с ханками число шардов, на которые размазан каждый бакет, тоже регулируется, просто оно регулируется делением/умножением сразу в 2 раза. Ещё было про счётчики и то, что они считаются через очередь. Ну ещё из интересного (для конкурентов :D) — цифры, например, 120к rps в облаке (2x за год), типичный крупный клиент > 1 ПБ и > 1 млрд объектов, и > 1000 rps. Кстати, ещё Паша не упоминал, что там в PostgreSQL есть хранимки и они весьма неплохо работают. Но про это есть старый пост на хабре: https://habr.com/ru/companies/yandex/articles/417241/ == Хадуп Неудачный опен-аут-сорс == '''Олег Балбеков (Evrone) — (Не)удачный эксперимент по выращиванию культуры Open Source''' Компания — что-то среднее между заказной разработкой и аутсорсерами. Пишут сайтики на Ruby и Python. Вкратце — они проверяли на практике гипотезу, что опенсорс полезен для бизнеса, постаравшись выжать ВСЁ!!!1111 из ну, в облаке общем-то, крох — 5 млн рублей за 5 лет. Что пробовали:* Оплачивать разработку открытых проектов своими разработчиками (но не более, условно, 50% времени)* Донатить на гитхабе; разыгрывать раз в неделю по 100$ среди опенсорс-проектов* Нагонять трафик со своих открытых проектов, но его было 1%* Нагонять трафик, используя проекты как инфоповоды, но поднять удалось всего до 4.4%* Технологический пиар (выступать на конференциях) — получили некоторое внимание сообщества, но не известно, как померить* Прямые продажи (придут инженеры и наймутся, или купят). ''Ога, щаз — прим.вред.'' Получили всего 1% лидов и ровно 1 продажу за 5 лет* Косвенные продажи (подтверждение квалификации компании). Есть, но не известно, как померить* Прямой HR-маркетинг (сбор базы кандидатов). Бесконечно менее эффективно, чем HR-инструменты (через оные и так есть база в 40366 человек). Наняли всего 1 человека за 5 лет* Косвенные плюсы при найме есть. Кандидатам нравится, что в компании можно пилить опенсорс. Но не известно, как померить :-)* Обучение через открытую разработку. Писать и показывать красивый код и т. п. Резюме — эффективно, но не масштабируемо. Причём по факту этим в компании занималось 2.5 человека, они ушли и всё это сдулось. Поэтому он сказал, что ''Если ты тот самый сотрудник Evrone, который бы хотел этим продолжить заниматься — Welcome, мы поддержим!'' — кажется, есть некоторые проблемы с внутренними коммуникациями в компании, если обращаться к сотрудникам приходится через Highload. :-))) Но эксперимент хочет продолжить и вернуться через 3 года с новостями. Ну ждём, чо. Справочно — опенсорс у них донный, фигня в духе мелких npm/pip модулей. Самый крупный проект — я спросил — какой-то линтер, что ли. Понятно, что с такой мелочи особого профита не получишь. Я потом ему задал вопрос, может вам попробовать что-то более крупное пилить? Он такой — ну, это уже продуктовая разработка. Ну конечно, продуктовая, ведь «открытое ПО» это в первую очередь что? Это в первую очередь ПО, то есть программный продукт! А для механистического подхода «просто хотим опенсорс» и всего 5 млн рублей, потраченных за 5 лет, у них весьма неплохо всё получилось. == Кубернетес от перил == '''Андрей Вильмов (ПерилаГлавСнаб) — От CRM к DataLake с K8s и микросервисами''' Немного напомнило старый мем и поэтому очень хотел послушать: [[Файл:Консервы.png|200px]] Но как ни странно, всё довольно разумно. Хотя смотрел в записи, потому что не смог попасть в зал, потому что МЕСТА НА КОНФЕРЕНЦИИ НЕ ХВАТАЛО. Вкратце — была страшная старая CRM-ка и всё было в ней, разрослось. Впилили Airflow, стали складывать в PostgreSQL. Постгря выросла до 3 ТБ, поменяли на Greenplum. Потом добавили Kafka и реалтаймовых потребителей. Потом впилили Kubernetes. Потом Minio в виде стораджа. Где-то рядом появился Spark. Вот так, слово за слово, <s>заяц получил п…ы</s> перила <s>превратились в облако</s> сделали своё мини-облако. =День 2 =
== Петабайт в УДБ на ХДД ==
'''Антон Барабанов (Яндекс) — Петабайт в YDB over HDD в процессингах Яндекс.Метрики'''
Ну, реально пока не петабайт, а 500 ТБ, но, типа, скоро будет петабайт. Но всё равно норм. При потоке записи 20 гбит/сек. 300 дисков в инсталляции. Суть — пробовали YDB на HDD. Справилось оно в их применении в целом неплохо, правда, как обычно, всю автоматику поотрубали — распределение запросов написали своё и данные тоже сами раскладывают по отдельным дневным табличкам.
Само применение — слияние визитов за сутки в метрике. То есть, на входе большой поток посещений сайтов и покупок (или других действий), на выходе надо посещения сцепить с действием, чтобы было понятно, что конверсия произошла. Для оффлайн-покупок аналогично, но дольше период — не сутки, а 20-30 дней, и данные в метрику заливает сам магазин постфактум, возможно даже вручную. Жёстких требований реального времени нет, но некоторые есть — надо, чтобы считалось 10-15 минут, а не сутки.
С YDB сначала наткнулись на проблему потребления RAM, добавлять пришлось и RAM и CPU, так как сказали, что есть жёсткие профили виртуалок во внутреннем «облаке». В итоге CPU на 90% простаивают. Потом YDB не справилось с чтением блоков с HDD, так как читает целыми блоками и только потом понимает, что нужных данных в блоке нет, а bloom фильтр работает по полному первичному ключу, а они запрашивают по одному ID юзера. Для борьбы с этим ключи положили на SSD, данные визитов оставили на HDD. Ещё натыкались на то, что автосплит партиций по нагрузке приводил к большой нагрузке из-за compaction — сначала нагрузка растёт, партиции разделяются, потом нагрузка падает, они сливаются. Всё жрёт compaction.
На вопрос «почему не YT(saurus)» ответили «так сложилось» + YT-шники им не были готовы предоставить такой кластер :-). Не Clickhouse потому, что Clickhouse плохо работает с синхронной репликацией.
== Как разрабатывается опенсорс в АЛЬТ ==
== SQL-регэкспы (MATCH_RECOGNIZE) ==
По сути это SQL-регэкспы — сначала ты задаёшь N WHERE-условий, а потом, ссылаясь на них, говоришь, что хочешь найти последовательность строк, где сначала идёт, например, 1 раз условие №1, потом не меньше 3 раз условие №2, и потом событие №3. SQL-конструкция сама, конечно, получается многоэтажная. Ну ок… природа любит разнообразие. == Индексы mail.ru == '''Рустем Гафаров (VK, Почта Mail.ru) — Устройство индексов в почте mail.ru''' Вот наконец и третья часть архитектуры mail.ru, продолжение [[Highload-2022: Отчёт Виталия Филиппова#Хранилище почты mail.ru|прошлогоднего доклада]]. ''Но вот эту часть — можно часть я не буду у себя нигде повторять, можно же, правда? — прим.вред.'' Резюме:LSM для бедных, с 2 уровнями (L0 и L1), снапшотами в Zepto (объектном хранилище) и WAL-ами в… Tarantool-е, в виде последовательности ключей. Ух, забористые вещества. Ящики полностью изолированные (независимый индекс по каждому), блочного доступа к индексам нет, снапшот грузится в память целиком в B-деревья (в памяти) и на него в памяти накатывается WAL. Теоретически даже поддерживается конкурентный доступ — перед операциями проверяется, не появилось ли что новое в WAL в тарантуле. Но не нужно, индекс ящика держится открытым на 1 сервере, в целом по ящикам — LRU кэш. Посему сильно экономят, не держа в памяти ненужные индексы (неактивные ящики). Вроде как экономят на индексах 600к в год. Называется система <s>Москито, как кто-то сказал из зала</s> Mescalito, формат XTAZ. 5 датацентров… а чего ж тогда в облаке VK нет Managed Postgres на 3 ДЦ. Непорядок.
== Велосипед от Тинькова (SAGE DB) ==
'''Александр Бирюков (Тинькофф) — Когда нужно делать свою базу данных'''
…под логи. ''Ответ — когда не взял кликхауз — прим.вред.''
Было плюс-минус интересно послушать про устройство индексаторов логов. ElasticSearch — обратные индексы, поэтому ЖРЁТ сторадж, Loki — вообще никаких индексов, только дискретное деление по файлам, поэтому тормозит, OpenObserve — новее и круче, паркеты (Parquet), точнее FDAP (Flight, DataFusion, Arrow, Parquet — на эту же связку уже перешли InfluxDB и Parseable), в паркетах есть сжатие, блум фильтры, индексы и всё такое, но фиксированная схема и вроде как не выходит реализовать какие-то оптимизации из-за абстрактности формата.
Проект SAGE у них начался в 2019, когда им не захотел продлевать лицензию Splunk. Сначала сделали на эластике, потом в силу вышеописанных архитектурных нюансов решили писать своё, допилить эластик силами 3-4 лиц не осилили бы. Сначала пробовали сделать свои обратные индексы на RocksDB, но быстро упёрлись. В итоге сделали своё подобие FDAP, но без схемы. Причём даже формат сериализации свой без декодирования и без схемы, и Flexbuffers почему-то не подошёл, хотя Flexbuffers это дословно формат без декодирования и без схемы. Тоже со сжатием (zstd + словарным для ключей) и блум-фильтрами. Общая схема в итоге похожа на Loki поверх S3.
Замеры: по скорости помедленнее эластика, условно 0.5 сек 50% квантиль против 0.15 сек. Но зато на эластике 350 серверов и 7 ПБ, а на SageDB 270 серверов и 700 ТБ. По облачным ценам экономия примерно 360 млн руб в год. Но работают пока обе схемы в параллель, полный переход ещё не состоялся, пока что все запросы зеркалируются. Пилили 3 года.
Ну хз. А чего было просто не взять Clickhouse? Ну схема, да, но ведь в логах не так чтобы прямо много разных форматов и колонок. Сложилось же бы, наверное.
== PATCH в S3 ==
'''Александр Снопов (Yandex Infrastructure) — Частичная модификация объектов в Yandex Object Storage: как мы улучшаем работу ФС поверх S3''' Вкратце: мы запилили в S3 [https://cloud.yandex.ru/docs/storage/s3/api-ref/object/patch PATCH] и поддержали его в [Категорияhttps:Конференции]//github.com/yandex-cloud/geesefs GeeseFS]. Зачем? Затем, чтобы приблизить S3 к ФС, ибо видим потенциал в объединении некоторых юзкейсов ФС и S3. Например, в бэкапах или каком-нибудь мышином облучении / HPC. Новый метод можно использовать как через GeeseFS, так и через обычное REST API. Ну и надо допиливать GeeseFS до состояния полноценной кластерной ФС, тогда будет ещё лучше. [[Категория:VitaliPrivateОтчёты о конференциях]]