Опубликовал статью на Хабр про переход с MapReduce на стриминговый движок для SQL

Так яндекс же развалился?

В смысле на две половины российскую и зарубежную?

Так YQL в Яндексе раньше был просто обёрткой над YT MapReduce, упрощающий жизнь. Статью не читал, не понял почему «ушли» с MapReduce, если под капотом всё равно YT?

З.Ы. В далёком 2016-2018 от меня хотели что-то подобное для поиска, на основе динамических таблиц. Ничего путного не вышло и я уволился из Яндекса.

Статью не читал, не понял почему «ушли» с MapReduce, если под капотом всё равно YT?

YT там только как хранилище данных, да и то опциональное, можно делать запросы и над S3 и над YDB.

Ушли с MapReduce только для запросов, которые умещаются в память узлов. Это просто работает гораздо быстрее чем MapReduce, так как не надо сохранять данные на диск.

которые умещаются в память узлов

И в чём смысл YT тогда? С тем же успехом можно использовать что-то вроде кубернетиса для запуска одной из миллиона бд на хосте.

И в чём смысл YT тогда?

Система хранения, деплоя кода, MapReduce для очень толстых запросов.

С тем же успехом можно использовать что-то вроде кубернетиса для запуска одной из миллиона бд на хосте.

Можно. Но мы ниасиляторы кубернетиса.

Кстати в Яндекс-Клауде оно крутится в кубернетесе. Это для внешних пользователей. Сервис называется Yandex Query.

Спасибо, интересная статья, поддержал 👍

Ну да. Всё, финита.

Так как описанное в статье является опенсорсом и лежит на гитхабе, то обе части Яндекса могут вносить вклад в разработку :)

Типа Spark?

Или это локализованный Спарк?

Идейно похоже на Спарк.

В спарке код джобов генерируется в виде джава кода, компилируется и исполняется. А как у вас?

А будет Алиса для зарубежной части Яндекса? Она как-то выглядит разумнее других помощников.

У нас LLVM есть.

Если я правильно понял, вы сделали свой ансамбль модели акторов с конечным автоматами обработчиков. И для хабра и для этого форума данная тема - оверхед по техническому уровню, просто не поймут.

Насколько я понял, производительность данного решения в конкретных задачах будет плавать и зависить от того насколько удачно подобрали количество тредов с тредпуле, объёма записи на диск (имхо, самое узкое место) и, возможно, времени холодного старта нового пула (у Amazon serverless с этим же беда бывает) .

У нас пул всегда прогрет и в него просто заселяются таски. При выкатках нового релиза на новый пул не отправляются запросы пока он не прогреется. Узких мест сейчас несколько. Одно из них - составление оптимального плана для сложного SQL запроса с кучей join’ов.

Предварительные ласки по прогреву нового пула это конечно замечательно, но довольно накладно, в смысле не только лишь все могут себе это позволить.

Составление оптимального плана жирных запросов вы осилите, я в этом не сомневаюсь. Вообще, вы молодцы, хорошую систему сделали, теперь есть выбор между спарком и вашим решением.

Комплексы пхп разраба видно за версту, ржу )

Пять звёзд сбоя не дают. Это аксиома Лора.

Интересно как движется история. Сначала нафигачить на ровном месте кучу данных, а потом прилагая немыслимые усилия пытаться быстро их обработать. Петабайты хероты :) Помню книжку профессора Фортрана, где на один диск влазила вся библиотека мира.

С работой повезло, редко в Яндексе занимаются интересными решениями - спасибо за статью.

Петабайты хероты :)

Экзабайты уже: https://habr.com/ru/companies/yandex/articles/721526/