Highload-2023: Отчёт Виталия Филиппова — различия между версиями

Материал из YourcmcWiki
Перейти к: навигация, поиск
Строка 212: Строка 212:
 
'''Александр Бирюков (Тинькофф) — Когда нужно делать свою базу данных'''
 
'''Александр Бирюков (Тинькофф) — Когда нужно делать свою базу данных'''
  
...под логи. ''Ответ - когда не взял кликхауз - прим.вред.''
+
…под логи. ''Ответ — когда не взял кликхауз — прим.вред.''
  
 
Было плюс-минус интересно послушать про устройство индексаторов логов. ElasticSearch — обратные индексы, поэтому ЖРЁТ сторадж, Loki — вообще никаких индексов, только дискретное деление по файлам, поэтому тормозит, OpenObserve — новее и круче, паркеты (Parquet), точнее FDAP (Flight, DataFusion, Arrow, Parquet — на эту же связку уже перешли InfluxDB и Parseable), в паркетах есть сжатие, блум фильтры, индексы и всё такое, но фиксированная схема и вроде как не выходит реализовать какие-то оптимизации из-за абстрактности формата. В Clickhouse — тоже схема, а они хотели без схемы вообще (хз, зачем).
 
Было плюс-минус интересно послушать про устройство индексаторов логов. ElasticSearch — обратные индексы, поэтому ЖРЁТ сторадж, Loki — вообще никаких индексов, только дискретное деление по файлам, поэтому тормозит, OpenObserve — новее и круче, паркеты (Parquet), точнее FDAP (Flight, DataFusion, Arrow, Parquet — на эту же связку уже перешли InfluxDB и Parseable), в паркетах есть сжатие, блум фильтры, индексы и всё такое, но фиксированная схема и вроде как не выходит реализовать какие-то оптимизации из-за абстрактности формата. В Clickhouse — тоже схема, а они хотели без схемы вообще (хз, зачем).

Версия 00:55, 2 декабря 2023

Как я уже писал в прошлогоднем отчёте - самая крупная и раскрученная конференция Бунина. Финальная стоимость выросла уже аж до 64 тыр с 60, то есть годовая инфляция по версии Онтико в этот раз составила 6.66 %. :-)

Общее впечатление: Неплохо - "торжество велосипедов" в докладах, всё как мы любим, но перегруженно. Слишком много народу на эту площадку.

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

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

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

День 1

Барсик

Григорий Бутейко (VK, ВКонтакте) — BARSiC — асинхронная репликация и консенсус для 70 баз данных.

Помните, я же написал выше, что конфа — торжество велосипедов. Вот, это велосипед №1, прямо с открытия.

Полная фигня, 150 полуляхов из 250. Технических деталей работы алгоритма в докладе было крайне мало, просто общая мысль — вот, им ничего готовое не подошло, Raft они почему-то сочли слишком сложным (Raft, сложным?!), поэтому сделали всё сами и на основе другого протокола — Viewstamped Replication аж от целой Бабы Лизы… то есть Барбары Лисков.

Самое смешное, что они на замену Raft-у, который им «показался слишком сложным», выбрали алгоритм, который (А) вообще не отличается от Raft по смыслу и (Б) даже сложнее, чем Raft, в деталях реализации! Это более старый алгоритм! Чувак, который придумал Raft, про этот алгоритм даже в своём диссере писал! В котором он, собственно, и придумал Raft.

Я про VR почитал уже после конфы. Единственное реальное отличие — то, что ноды голосуют не за первого заявившегося кандидата, а за кандидата с минимальным ID (IP-адресом). Всё остальное практически идентично, Raft Term = VR View и так далее. При этом у VR 10 типов сообщений вместо 4-х у Raft-а.

Причём аргументы, согласно которым им не подошли готовые решения, меня лично вообще не убедили. Какое-то расхождение данных и метаданных при использовании внешнего сервиса консенсуса… не, ну писать просто надо нормально, что значит — расхождение. Я же юзаю etcd в Vitastor, брат жив. Ну ладно я, ещё пример — TiDB юзает встраиваемый etcd, брат тоже жив. Всё ещё мало? Patroni/Stolon испокон веков юзают Consul/etcd. Ceph OSD хранят метаданные в Ceph Monitor-ах. Какое расхождение?!

Хоть бы исходники открыли, ё-моё, хоть какая-то польза была бы от этого барсика. А то ну написали тесты, ну пофаззили, ну дополнительно верифицировали на TLA+, ну молодцы. Но какой во всём этом толк, если рядом лежит штук 10 «вот таких же, только меньше, но других», тоже хорошо оттестированных за все эти годы Raft-ов…

Производительность Go

Никита Галушко (VK, ВКонтакте) — Выжимаем из Go максимум производительности

В принципе стандартные вещи, даже не так их много было:

  • Мелкие объекты — до 32 байт — оптимизируются
  • Интерфейсы медленнее из-за виртуальных вызовов
  • Если в массивах срабатывает проверка границ (не срабатывает BCE) — код замедляется
  • for по индексам быстрее, чем for по range (подозрительно, stackoverflow говорит обратное — что они не отличаются)
  • Работа со строками хорошо оптимизирована для частых сценариев

Как привлекать людей в опенсорс-проекты

Ксения Романова (Positive Technologies) — Сообщества вокруг технологии: почему быть бесплатным недостаточно

Девушка связана с Apache Ignite и фондом Apache (туда ещё проекты умирать часто сдают), сейчас работает у позитивов.

Я не уверен, что доклад был именно о том, как я его окрестил, ибо изложение было довольно размытым. Но мне кажется, что это самое близкое. По-моему, она пыталась развивать стереотип о том, что опенсорс — это «бесплатные руки», и надо лучше искать эти бесплатные руки, лучше общаться с людьми и помогать им включиться в проект. «Как бы нам заполучить бесплатных разработчиков». :-)

С моей точки зрения — это утопия, хоть я и адепт опенсорса. Времени всем не хватает, видение развития проекта у каждого своё (1 программист пишет программу за 1 месяц, 2 — за 2 месяца), лидеры проекта душнят в пулреквестах, поэтому не стоит рассчитывать, что вы сможете найти серьёзный пул контрибьюторов среди сообщества. Проекты типа Linux — это очень редкие и крутые исключения из правил, так почти никто не умеет. Хотя, кстати, в её родном фонде Apache линукс ещё не факт, что свершился бы — они же не принимают правки от компаний.

Всё остальное в докладе — шелуха. Вот… сообщества… технологии… привлекать людей… модель «воронка»… модель «орбита»… людям это надо для чего-то там… компаниям это надо для чего-то там… 80% кода в опенсорс-проектах пишут единичные «герои»… Контрибьюторы классифицируются по 2 осям — качеству кода и любви к проекту… (тут я вообще чуть не взоржал)

Из интересного — в конце спросил у неё, а зачем компании сдают проекты в фонд Apache, в чём выгода. Так как, по-моему, проекты туда обычно сдают помирать, на кладбище. Для справки — апачи забирают все права на проект себе и даже потом правки от компаний не принимают — отправлять патчи могут только отдельные физлица-разработчики, даже если они все работают в одной компании. Она ответила, что сдают ради помощи в развитии, типа гайдлайнов/руководств по жизненному циклу проекта и ради готовой инфраструктуры разработки. Ну понятно — Apache пытается строить «завод опенсорса» и на этом в процессе делать деньги. Но вот для сдающей компании особой выгоды, мне кажется, всё-таки нет, так что скорее всего обычно действительно просто «сдают в отстойник».

Дата скетчи

Сергей Жемжицкий (SberDevices) — Data Sketches — как съесть слона целиком (даже если он бесконечный)

В целом неплохой доклад про алгоритмы семейства Data Sketches. Ну в смысле для меня неплохой, ибо я про эти алгоритмы не знал. Я так понимаю, это новое собирательное название для уже некоторое время существующего класса алгоритмов — потоковых статистических алгоритмов.

TLDR — всё это реализовано в библиотеке Apache DataSketches на Java и C++, бери и юзай. Даже в ClickHouse припилено уже.

В докладе затронуты алгоритмы:

  • Подсчёт числа уникальных элементов в потоке (Count-Distinct): HLL (HyperLogLog), CPC (Compressed Probability Counting), Theta Sketch
    • HLL: число уникальных примерно равно 2^(максимальное число идущих подряд нулей в начале хешей всех элементов + 1).
    • CPC: число уникальных примерно равно 2^(максимальное число идущих подряд нулей в конце хешей всех элементов, кроме хешей из всех нулей).
    • Theta Sketch: вроде бы это обобщение алгоритма K минимальных значений. Типа, мапим каждое значение в хеш, равномерно распределённый в диапазоне чисел (0, 1). Сохраняем K+1 минимальных значений таких хешей. После чего число уникальных будет примерно равно K/(k+1-ый минимальный хеш). Вот статья про эту тету https://github.com/apache/datasketches-website/blob/master/docs/pdf/ThetaSketchFramework.pdf
  • Частота встречаемости элемента: CountMin Sketch, Misra-Gries
    • CountMin: берём несколько независимых хеш-функций, делаем таблицу — на каждый хеш 1 строка, и заданное K колонок. На каждое значение считаем все хеши и увеличиваем на 1 соответствующую хешу колонку в строчке этого хеша. Потом, чтобы оценить частоту встречаемости элемента, берём минимум от значений ячеек, соответствующих всем его хешам.
    • Misra-Gries: по ходу подсчёта сохраняем K самых часто встречаемых элементов и считаем их частоты. Если же встречаем элемент, не входящий в K, увеличиваем на 1 отдельный счётчик «всех остальных», уменьшаем на 1 все частоты K элементов, удаляем элементы с нулевыми частотами. Далее частоту встречаемости любого элемента принимаем за (счётчик «всех остальных» + счётчик самого элемента).
  • Квантили/гистограммы: куча странных названий, я себе из всего выписал Manku-Rajagopalan-Lindsay (MRL), но в суть расчёта докладчик уже не погружался.

Катаем гусей

Павел Левдик (Yandex Infrastructure) — Внутри S3

Доклад про Яндексовую реализацию 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

Но как ни странно, всё довольно разумно. Хотя смотрел в записи, потому что не смог попасть в зал, потому что МЕСТА НА КОНФЕРЕНЦИИ НЕ ХВАТАЛО.

Вкратце — была страшная старая CRM-ка и всё было в ней, разрослось. Впилили Airflow, стали складывать в PostgreSQL. Постгря выросла до 3 ТБ, поменяли на Greenplum. Потом добавили Kafka и реалтаймовых потребителей. Потом впилили Kubernetes. Потом Minio в виде стораджа. Где-то рядом появился Spark.

Вот так, слово за слово, заяц получил п…ы перила превратились в облако сделали своё мини-облако.

День 2

Шардирование: с нуля до Яндекс Диска

Реконсиляция от Меликова

Хадуп в облаке

Петабайт в УДБ на ХДД

Как разрабатывается опенсорс в АЛЬТ

Евгений Синельников (Базальт СПО) — Как разрабатываются свободные проекты в команде ALT?

Имхо крайне бестолковый доклад. По логике названия тут должно было быть что-то про процесс разработки, а по факту было про то, что вот, опенсорс не мешает ничего продавать, потому что оно продаётся как «сборник произведений», по ГК РФ являющийся самостоятельным произведением. И про то, что бизнес не понимает GPL. Ну и упомянули своё AD под линукс (ужасная виндузятская хрень).

SQL-регэкспы (MATCH_RECOGNIZE)

Нагрузка или задержка?

Устройство индексов в почте mail.ru

Вот наконец и третья часть архитектуры mail.ru. Но вот эту часть — можно я не буду у себя нигде повторять, можно же, правда? :-)

Велосипед от Тинькова (SAGE DB)

Александр Бирюков (Тинькофф) — Когда нужно делать свою базу данных

…под логи. Ответ — когда не взял кликхауз — прим.вред.

Было плюс-минус интересно послушать про устройство индексаторов логов. ElasticSearch — обратные индексы, поэтому ЖРЁТ сторадж, Loki — вообще никаких индексов, только дискретное деление по файлам, поэтому тормозит, OpenObserve — новее и круче, паркеты (Parquet), точнее FDAP (Flight, DataFusion, Arrow, Parquet — на эту же связку уже перешли InfluxDB и Parseable), в паркетах есть сжатие, блум фильтры, индексы и всё такое, но фиксированная схема и вроде как не выходит реализовать какие-то оптимизации из-за абстрактности формата. В Clickhouse — тоже схема, а они хотели без схемы вообще (хз, зачем).

Проект 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