Так у нас так и работает. Все таски пропускают через себя данные и ничего не ждут. Как на двух последних картинках нарисовано. Если в тасках нет накопления (как в аггрегации), то они поток не останавливают.
По YQL в Яндексе есть экспертиза и если что-то идет не так или если есть хотелки от пользователей, то специально обученные люди все поправят и все напишут
YQL уже был, на новый движок пользователи перешли незаметно для себя и продолжили работать с теми же самыми данными и теми же самыми запросами, просто стало все гораздо быстрее
В нашем случае задачи создаются автоматически на основе SQL запроса. Есть задачи чтения, фильрации, аггрегации, джойна и так далее. Формата данных всего два у нас и определяется настройками. Это либо все в протобуф либо метаданные в протобуф, а данные в собственном формате. То есть форматы мы сами контроллируем.
Кстати синтаксис PostgreSQL тоже уже поддерживается, но если хочет извлечь максимальную производительность пока рекомендуется пользовать YQL синтаксисом.
Здесь просто паттерны описаны, если nginx устраивает, то Ok. Иногда приходится балансировку реализовывать на других уровнях. В клиентских библиотеках, или для каких-нибудь внутренних слоев сервиса, где готовые решения не подходят и приходится выбирать какой из "велосипедов" реализовывать. Это же не какой-то rocket science можно и самому реализовать.
Если есть в std то я бы использовал из std. Если нет в std, но есть в бусте, то я бы все равно не использовал буст, так как есть куча standalone реализаций flat_map'ов, которые не тянут с собой ничего и содержатся в одном заголовочном файле. Возможно, я статью плохо прочитал, но не увидел что конкретно означает "плоский контейнер" и не увидел картинку с хэшем с открытой адресацией.
Спасибо. Где-то полгода назад я тоже развлекался с написанием raft на python. Вот результат: https://github.com/resetius/miniraft Вся логика в raft.py. Есть юнит-тесты. Для сети используется asyncio. Поддержки кластеризации нет. Лог пишется в память.
Я ради интереса пробовал задачи с codeforces скармливать. Правильного решения удалось добиваться всегда только после кучи уточняющих вопросов, задать которые можно только если ты уже знаешь как решить задачу. Leetcode действительно решает лучше, но все равно быстрее закодить самому. Проверял на ChatGPT 3.5. Может быть 4я версия работает лучше.
Никто не мешает пересылать протобафы в чистом http.
Имеется ввиду http 1.1 ? Да, так можно делать, но тогда теряется двунаправленность и всякие сложные кейсы типа потоковости (запрос-поток, ответ-поток).
Спасибо за статью. Для добавления этих правил пришлось патчить спарк или у него есть API для добавления произвольных правил? Если прогнать без оптимизаций и с оптимизациями на бенчмарке типа TPCH, то эффект заметен?
Coroutines in C++ are platform independent. However, the input/output multiplexing mechanism may be platform dependent. In the above examples I use select which is available on all platforms. Platform-dependent code can be viewed on GitHub via the following link https://github.com/resetius/coroio/blob/master/src/all.hpp#L19
Изначально мы строились вокруг стандартного клиентского кода Kafka, а он имел более-менее полный API только для Scala. Также за Scala можно посадить Java-разработчика, а вот с Erlang всё гораздо сложнее, у нас в отделе совсем нет специалистов по нему.
Порядок мы гарантируем только в пределах партиции. У нас каждый источник полностью ложится в одну партицию. При этом, в случае логов, источник это файл в файловой системе с точностью до inode. Если файл переименовали, а на его месте создали файл с тем же именем, то это уже будет новый источник и он польется в общем случае в другую партицию. Консьюмеров, которые зависят от порядка сообщений у нас сейчас нет.
Отставание считаем двумя способами. 1. Текущее отставание считается как high_watermark — offset, оно обновляется только когда работает консьюмер. 2. Есть внешний процесс, который с помощью запросов OffsetRequest определяет размеры партиций, также он ходит в хранилище offset'ов консьюмеров (сейчас это zk) и смотрит текущую позицию. По этим данным строится отставание. Все мониторинги завязаны на работу именно внешнего процесса, так как он может вычислять отставания даже когда не работает система.
Система изначально создавалась для логов, но последнее время мы начали к ней подключать потоки не-логи. Технологии кроме Apache Kafka: Scala, Akka, Spray, C++ (парсинг логов). На клиентской стороне Си (без плюсов :) ),libevent. Для обработки данных и построения отчетов: YT и YAMR.
Динамическое управление данными имеется. 1. Есть система автоматического определения типа данных, которые отправляет источник. В зависимости от типа решается куда поставлять данные и в какую таблицу на кластере (в это очень сильно помогают Kafka Topics). 2. Можно на лету менять правила поставки и «рисовать стрелки» для потоков данных.
Riak не смотрели, но смотрели другие системы, построенные на аналогичных принципах. После негативного опыта взяли более простое, дубовое решение, такое как Apache Kafka :)
У нас есть планы на частичное открытие исходников. Это касается клиетской части, сервера с ограниченным функционалом и клиентских библиотек к Kafka. Но это не в этом году.
Там нужно по сути ядро + один процесс. Уверен, что процесс лочится в памяти с помощью mlock и больше не выгружается на диск.
Так у нас так и работает. Все таски пропускают через себя данные и ничего не ждут. Как на двух последних картинках нарисовано. Если в тасках нет накопления (как в аггрегации), то они поток не останавливают.
Некий аналог есть. Движок поддерживает стриминговые запросы и эта настройка сейчас включена только в нашем внешнем сервисе: https://yandex.cloud/en/docs/query/concepts/stream-processing
По YQL в Яндексе есть экспертиза и если что-то идет не так или если есть хотелки от пользователей, то специально обученные люди все поправят и все напишут
YQL уже был, на новый движок пользователи перешли незаметно для себя и продолжили работать с теми же самыми данными и теми же самыми запросами, просто стало все гораздо быстрее
Синтаксис YQL это почти стандартный SQL. О его плюсах можно прочитать в другой статье: https://habr.com/ru/companies/yandex/articles/312430/
В больших компаниях всегда любят разрабатывать свои технологии, а не пользоваться существующими
В нашем случае задачи создаются автоматически на основе SQL запроса. Есть задачи чтения, фильрации, аггрегации, джойна и так далее. Формата данных всего два у нас и определяется настройками. Это либо все в протобуф либо метаданные в протобуф, а данные в собственном формате. То есть форматы мы сами контроллируем.
Кстати синтаксис PostgreSQL тоже уже поддерживается, но если хочет извлечь максимальную производительность пока рекомендуется пользовать YQL синтаксисом.
Возможно, имеется ввиду unix pipe
epoll backend: https://github.com/resetius/coroio/blob/master/coroio/epoll.hpp
kqueue backend: https://github.com/resetius/coroio/blob/master/coroio/kqueue.hpp
uring backend: https://github.com/resetius/coroio/blob/master/coroio/uring.hpp
Paths in the repository can be changed, if this happens, then use the link to the root of the repository: https://github.com/resetius/coroio
Здесь просто паттерны описаны, если nginx устраивает, то Ok. Иногда приходится балансировку реализовывать на других уровнях. В клиентских библиотеках, или для каких-нибудь внутренних слоев сервиса, где готовые решения не подходят и приходится выбирать какой из "велосипедов" реализовывать. Это же не какой-то rocket science можно и самому реализовать.
Если есть в std то я бы использовал из std. Если нет в std, но есть в бусте, то я бы все равно не использовал буст, так как есть куча standalone реализаций flat_map'ов, которые не тянут с собой ничего и содержатся в одном заголовочном файле. Возможно, я статью плохо прочитал, но не увидел что конкретно означает "плоский контейнер" и не увидел картинку с хэшем с открытой адресацией.
Спасибо. Где-то полгода назад я тоже развлекался с написанием raft на python. Вот результат: https://github.com/resetius/miniraft Вся логика в raft.py. Есть юнит-тесты. Для сети используется asyncio. Поддержки кластеризации нет. Лог пишется в память.
Я ради интереса пробовал задачи с codeforces скармливать. Правильного решения удалось добиваться всегда только после кучи уточняющих вопросов, задать которые можно только если ты уже знаешь как решить задачу. Leetcode действительно решает лучше, но все равно быстрее закодить самому. Проверял на ChatGPT 3.5. Может быть 4я версия работает лучше.
Имеется ввиду http 1.1 ? Да, так можно делать, но тогда теряется двунаправленность и всякие сложные кейсы типа потоковости (запрос-поток, ответ-поток).
Спасибо за статью. Для добавления этих правил пришлось патчить спарк или у него есть API для добавления произвольных правил? Если прогнать без оптимизаций и с оптимизациями на бенчмарке типа TPCH, то эффект заметен?
Coroutines in C++ are platform independent. However, the input/output multiplexing mechanism may be platform dependent. In the above examples I use
selectwhich is available on all platforms. Platform-dependent code can be viewed on GitHub via the following link https://github.com/resetius/coroio/blob/master/src/all.hpp#L19Чтобы не дублировать текст на другом ресурсе.
Отставание считаем двумя способами. 1. Текущее отставание считается как high_watermark — offset, оно обновляется только когда работает консьюмер. 2. Есть внешний процесс, который с помощью запросов OffsetRequest определяет размеры партиций, также он ходит в хранилище offset'ов консьюмеров (сейчас это zk) и смотрит текущую позицию. По этим данным строится отставание. Все мониторинги завязаны на работу именно внешнего процесса, так как он может вычислять отставания даже когда не работает система.
Система изначально создавалась для логов, но последнее время мы начали к ней подключать потоки не-логи. Технологии кроме Apache Kafka: Scala, Akka, Spray, C++ (парсинг логов). На клиентской стороне Си (без плюсов :) ),libevent. Для обработки данных и построения отчетов: YT и YAMR.
Динамическое управление данными имеется. 1. Есть система автоматического определения типа данных, которые отправляет источник. В зависимости от типа решается куда поставлять данные и в какую таблицу на кластере (в это очень сильно помогают Kafka Topics). 2. Можно на лету менять правила поставки и «рисовать стрелки» для потоков данных.
Riak не смотрели, но смотрели другие системы, построенные на аналогичных принципах. После негативного опыта взяли более простое, дубовое решение, такое как Apache Kafka :)