Comments 15
есть решение для потоковой обработки данных которое уже пару десятилетий и более работает на миллионах, а может и на миллиардах компьютеров и вы им тоже пользуетесь, я уверен.
Оно настолько эффективное что никто даже не замечает какая система стриминговой обработки данных находится под вашим управлением в момент использования.
Ведь проблема не только в том чтобы данные не сохранять на диск, а использовать напрямую из памяти. Было бы неплохо чтобы последовательные задачи могли использовать данные не только когда все данные полностью полученны из предыдущей стадии, но и когда предыдущая стадия сгенерировала достаточную порцию данных для начала работы задачи из последующей стадии. И даже такая задача, а точнее класс задач решены в той, десятилетиями проверенной системе. Поэтому вы в какой-то степени изобретаете велосипед, только это конечно не велосипед, а космический корабль или атомная станция и для таких задач нужны свои наработки, конечно. Но чужой опыт в том же направлении никогда не мешает подсмотреть, это может очень сильно облегчить вам работу, тем более что на существующую систему есть полная-всеобъемлющая документация, и я, например, очень успешно делал модули для этой системы в свое время, так успешно что начал эту модульную концепцию применять для своих задач далеко за пределами изначального предназначения той системы.
Если интересно какую систему я имею ввиду обращайтесь в личку.
Возможно, имеется ввиду unix pipe
command1 | command2 | command3нет, это озвученное вами решение имеет очень ограниченные возможности конфигурации, поэтому его применение тоже очень ограничено.
надо следить, например еще и за тем, что задача последующей стадии в состоянии работать с форматом данных, которые выдает предыдущая стадия и адекватно и главное вовремя сообщать о таком не соответствии, это проблема тоже решается в той системе с которой я работал. То есть проблема решается не сама по себе - решать должен разработчик очередной задачи, система определяет-предоставляет четкие вместе с тем гибкие правила и возможности для такого решения, по сути предоставляет всю нужную инфраструктуру для реализации такого решения, какую бы сложную задачу мы не задумали мы легко можем контролировать формат входных данных до того, когда все упадет из-за не соответствия форматов и концов будет не найти.
В нашем случае задачи создаются автоматически на основе SQL запроса. Есть задачи чтения, фильрации, аггрегации, джойна и так далее. Формата данных всего два у нас и определяется настройками. Это либо все в протобуф либо метаданные в протобуф, а данные в собственном формате. То есть форматы мы сами контроллируем.
Есть задачи чтения, фильрации, аггрегации, джойна и так далее.
да-да, я с похожим набором работал, только не с атомарными данными а с потоковыми данными, хотя в каком то смысле они все равно всегда остаются атомарными, есть минимальная порция, для которой возможна обработка. Чтения, фильтрации, объединения-наложения, разделения на потоки (если маленько другими словами, хотя смысл тот же).
Но если вы все таки будете решать задачу одновременной работы задач по возможности, то есть когда последующая задача начинает данные принимать и обрабатывать как только они появляются, а не ждать когда полностью отработает предыдущая задача, то вам понадобятся особые метаданные об этих данных как о потоке данных. и не только метаданные, а некоторая техника (интерфейсы, ...) чтобы ими обмениваться
Так у нас так и работает. Все таски пропускают через себя данные и ничего не ждут. Как на двух последних картинках нарисовано. Если в тасках нет накопления (как в аггрегации), то они поток не останавливают.
Картинки у вас красивые, без иронии, но по ним к сожалению не очень видно какой-то одной понятной идеи, по крайней мере мне. Выглядит так, что вы попытались отобразить на одной картинке как можно больше идей, то есть сколько получилось уместить, к сожалению такой подход не способствует пониманию. Вообще видно что у вас все вполне серьезно, а самое главное система работает.
Если что, я просто к тому, что было бы очень интересно сравнить то что у вас получилось, с тем с чем я работал, потому что концептуальное описание задач в наших разных системах звучит очень похоже, при этом предметные области достаточно сильно отличаются. Поэтому интересно насколько те подходы которые я использовал подходят в вашем случае или насколько подходы которые вы используете получились подобными тем которые используются в другой предметной области, то есть вопрос в том а совпали ли эти подходы, а если нет то почему и как это зависит от предметной области. Дело в том что если они совпадают то мы докажем что они универсальные. Такое доказательство было бы очень интересно получить и проанализировать.
У меня есть подозрение что тут может получиться полноценная хорошая теория которая будет иметь прямое отношение к решению широкого круга практических задач и которая даст ответы на многие прикладные вопросы.
Уже вижу комментарии, в которых будут ругать компанию за создание своего продукта вместо использования SQL. Как человек, который пришел в Яндекс на позицию аналитика 3 месяца назад, скажу, что YQL – супер удобный инструмент для работы инструмент, который позволяет более свободно писать запросы, чем другие диалекты SQL
В YQL неплохо решена проблема SQL с NULLs, которая всех уже замучила порядочно. Кстати, решение похоже на то, как предлагал исправить стандарт SQL С.Д. Кузнецов в своей статье
Кстати синтаксис PostgreSQL тоже уже поддерживается, но если хочет извлечь максимальную производительность пока рекомендуется пользовать YQL синтаксисом.
Почему не Apache Spark? В чем разница?
По YQL в Яндексе есть экспертиза и если что-то идет не так или если есть хотелки от пользователей, то специально обученные люди все поправят и все напишут
YQL уже был, на новый движок пользователи перешли незаметно для себя и продолжили работать с теми же самыми данными и теми же самыми запросами, просто стало все гораздо быстрее
Синтаксис YQL это почти стандартный SQL. О его плюсах можно прочитать в другой статье: https://habr.com/ru/companies/yandex/articles/312430/
В больших компаниях всегда любят разрабатывать свои технологии, а не пользоваться существующими
Поддерживается ли аналог dynamic tables из apache flink?
Некий аналог есть. Движок поддерживает стриминговые запросы и эта настройка сейчас включена только в нашем внешнем сервисе: https://yandex.cloud/en/docs/query/concepts/stream-processing
Эволюция обработки данных: от MapReduce к стриминговому движку