Небольшая оптимизация которую можно сделать в одном из ваших примеров:
Фильтрация после первого соединения. После первого соединения выполняем фильтрацию, оставляя только записи с возрастом больше 30. Это ещё больше уменьшает объём данных.
Вместо фильтрации после первого join можно сделать фильтрацию до него, тогда уже сразу во время join данные отфильтруются. В случае с маленькой таблицей это будет скорее всего не важно, но все равно выглядит более логично
Спасибо за статью, очень интересно было прочитать про масштабы DDoS-атак! Но было бы еще более интересно увидеть больше технических подробностей.
Как делаете инференс? Как удается обеспечить быстрый апскейл сервиса при аттаке? Судя по скриншоту он должен переживать увеличение нагрузки в духе х100 меньше чем за минуту.
В чем именно роль быстрой vs. умной части? У быстрой сильно меньше recall? Какая часть запросов доходит до умной части?
Как размечаете выборку, как проверяете что recall/precision остаются в заданных границах? Делаете какой-то пост-анализ или есть какие-то метрики в реалтайме?
Спасибо большое за статью! Будет очень интересно увидеть вторую часть.
Интересно понять про Data Marts - как вы добиваетесь того что эти же данные доступны и в training и в real-time inference? Или у вас большинство инференса не real-time?
Из графика видно, что при запуске одной реплики инференса пропускная способность на A100 будет ниже, чем на T4 и V100.
Вот это основной нюанс. 7 штук Т4 в GCP стоит практически столько же или даже дешевле чем одна A100, а на большинстве задач дают значительно лучший перформанс и более простой и гибкий сетап чем A100 разделенная на 7 частей.
Поэтому технология интересная, но практическое применение несколько ограниченное, по моим впечатлениям. Но при этом не сомневаюсь что есть случаи когда это актуально.
Если читать оригинальную статью с которой все началось, то там кажется основная соль не в микросервисах а вообще в преждевременной оптимизации.
Whereas running media conversion once and caching its outcome might be considered to be a cheaper option, we found this not be a cost-effective approach.
То есть воткнули некое подобие кэша (со стейтом и всеми сопутствующими приключениями) там где он невыгоден. Ну, ок, бывает.
Отвечая немного на комментарии про то что использовать специализированные решения для геоданных - мне кажется это сильно усложнит систему. Грубо говоря, если у тебя уже есть большой data lake с настроенным к нему доступом из Spark, то поднимать рядом еще одну систему или использовать какой-то отдельный движок - кажется перебором.
Ну и этот вариант должен достаточно хорошо масштабироваться. Там упомянули что это гигабайты для одного дня для одного региона. Ну то есть если хочется проанализировать данные за год в нескольких регионах - это уже влегкую десятки террабайт. А если их еще хочется какими-то другими данными обогатить? Условно поджойнить на еще какие-то атрибуты и тд.
Да, можно сделать предобработку в Spark, нарезать данные, и проанализировать с помощью чего-то еще… Но зачем, когда тут это практически из коробки?
А для вас правда размер хранимых данных является наиболее важным критерием? Диски вроде бы относительно дешевые в наши дни.
Что насчёт того как эти конструкции ведут себя при чтении? А какой паттерн чтений? Например, часто ли нужно прочитать это дополнительное поле?
Я просто веду к тому что денормализация это иногда действительно очень хорошая штука. Вот только делать это ориентируясь исключительно на размер таблицы… Ну такое.
Выглядит на первый взгляд интересно, но немного удивляет описанная в статье архитектура. Неужели Apollo Federation действительно торчит голой ж в интернет доступна с клиентов напрямую?
Кажется же что тогда на неё ложиться ещё вагон всяких задач как раз в духе авторизации, прав доступа и тому подобного, или я ошибаюсь? И они, кажется, могут быть уникальны для каждого сетапа.
Но в роли того чтобы на беке собирать забросы по разным микросервисам - выглядит интересно.
С конкретными примерами, деталями и цифрами. Если же человек не может это вычленить из своего предыдущего опыта, то да, тогда у него проблемы. Но тогда у него несколько более глубокие проблемы связанные с тем, чтобы делать работу не на интуиции, а стабильно и воспроизводимо.
И, да, отчасти, тут начинается "джентельмены верят на слово". Но обычно совсем уж выдуманные кейсы разоблачаются достаточно легко, когда начинаешь углубляться в них и расспрашивать про детали.
Но это не рынок. Рынок нанимает сеньор админов, сеньор программистов, лидов и т.п., кодить и админить, а "ответственность" и "решение проблем" не нанимает. Эти навыки нанимаются только по личным референсам и рекомендациям.
Не могу с этим согласиться. Обычно любому бизнесу нужно именно решение проблем, а не "сеньор админ" или "сеньор программист".
И любые технические собеседования/тестовые задания это не более чем прокси-метрики к оценке того насколько человек умеет решать проблемы.
Но, да, есть вопрос с тем насколько этот навык универсален и насколько получится его показать при процессе найма.
Если человек на прошлом месте поднимал себе зарплату не через разные манипуляции, а показывая свою ценность, то, скорее всего, и людям за пределами компании он сможет её продемонстрировать.
Вот у меня похожий вопрос, который я не совсем понял.
Разве это не тоже самое, что задача о P = NP? Которая давно сведена к решению любой из NP-полных задач?
То есть задача упомянутая в статье это "просто" еще одна NP-полная задача? Судя по тому сколько было проделано работы кажется что нет и где-то кроется принципиальная разница, но, увы, я её не понимаю пока что.
Тоже были очень похожие мысли. Мне сложно говорить конкретно за QA, так как в этой области никогда работать не приходилось, но кажется что это хорошо проецируется на IT в целом.
Как мне кажется, в этом пункте очень важно понимать границы его применимости. С одной стороны, я согласен с автором статьи, что умение человека самостоятельно довести задачу до конца является очень полезным и важном для Senior специалистов.
С другой стороны, ты должен понимать когда нужно остановиться и попросить помощи у коллег, которые более компетентны в данном конкретном кейсе/технологии.
Найденные дыры очень знатные, нисколько это не хочу преуменьшать.
Но очень надеюсь, что «поезд под откос» таким образом пустить невозможно.
Даже если пустить два поезда на встречу на одном пути — есть же механизмы принудительного торможения, если такое произошло, если я ничего не путаю.
Которые реализованы уже на базе семафорной сети на основе просто того что колесной парой замыкается контакт между рельсами.
То есть несмотря на всю серьезность найденных уязвимостей (оставить РЖД без камер видеонаблюдения – это действительно очень стремно) – кажется что настолько жесткий прямой ущерб все-таки невозможен.
Возможно я ошибаюсь, все-таки это совсем не моя сфера интересов и знаю я её в основном по статьям на хабре же :)
2 TB / год + требования по near realtime — точно ли стоит такое добро тащить в хадуп?
Навскидку кажется, что MPP-базы подошли бы лучше (Vertica / ClickHouse).
Ну и при определенной фантазии и в одну классическую реляционную БД можно уложиться, кажется.
Или это всё цифры по какому-то одному производству / тех.процессу и планируется их масштабирование на порядки?
Любопытны результаты запроса с фильтром value LIKE 'foo%'
Как объясняется такое большое отличие для medium при прогретом и непрогретом кэше и отсутствие такого отличия для large?
TOAST-таблица не может быть эффективно закэширована на уровне Postgres?
Мне кажется, что стоит все-таки разделять две сущности.
Первая — давать фидбек, вторая — принимать решение о найме.
Давать фидбек по ходу интервью выглядит абсолютно нормальной практикой. Обсуждаешь с кандидатом вопрос — «финализировали» его, сказали, что «ок все, круто», ну или «ну, норм, но я ожидал еще вот то-то и то-то».
Тут же принимать решение о найме / переходе на следующий этап, лично для меня, кажется спорным по разным причинам.
Во-первых, все-таки есть шанс принять решение на «эмоциях». Мне бывает лучше все-таки записать выводы по собесу, чуть «выдохнуть» и потом уже принять решение.
Во-вторых, когда ведется собеседование вдвоём – у нас принята схема, что каждый независимо пишет свои выводы по кандидату и потом уже принимается решение. На мой взгляд, это позволяет уменьшить влияние мнений интервьюеров друг на друга.
Спасибо!
Для меня было принципиально понять — это совсем редкие кейсы, единичные для отрасли, или же просто действительно хорошие разработчики.
Получается, что достаточно значительное количество людей выбивается за эти границы. Кажется, что было бы здорово это указать где-то в исследовании — это достаточно важно как для кандидатов, так и для компаний.
Грубо говоря, осознание того, что если вы / вам нужен человек из топ-10% сегмента, то стоить это будет дороже.
А можете еще немного раскрыть этот вопрос? У вас там просто дальше есть комментарии, что отброшены некоторые «крайние» цифры для min / max. Любопытно — сколько отброшено? 5%?
Спасибо за статью!
Небольшая оптимизация которую можно сделать в одном из ваших примеров:
Вместо фильтрации после первого join можно сделать фильтрацию до него, тогда уже сразу во время join данные отфильтруются. В случае с маленькой таблицей это будет скорее всего не важно, но все равно выглядит более логично
Спасибо за статью, очень интересно было прочитать про масштабы DDoS-атак! Но было бы еще более интересно увидеть больше технических подробностей.
Как делаете инференс? Как удается обеспечить быстрый апскейл сервиса при аттаке? Судя по скриншоту он должен переживать увеличение нагрузки в духе х100 меньше чем за минуту.
В чем именно роль быстрой vs. умной части? У быстрой сильно меньше recall? Какая часть запросов доходит до умной части?
Как размечаете выборку, как проверяете что recall/precision остаются в заданных границах? Делаете какой-то пост-анализ или есть какие-то метрики в реалтайме?
Спасибо большое за статью! Будет очень интересно увидеть вторую часть.
Интересно понять про Data Marts - как вы добиваетесь того что эти же данные доступны и в training и в real-time inference? Или у вас большинство инференса не real-time?
Вот это основной нюанс. 7 штук Т4 в GCP стоит практически столько же или даже дешевле чем одна A100, а на большинстве задач дают значительно лучший перформанс и более простой и гибкий сетап чем A100 разделенная на 7 частей.
Поэтому технология интересная, но практическое применение несколько ограниченное, по моим впечатлениям. Но при этом не сомневаюсь что есть случаи когда это актуально.
Если читать оригинальную статью с которой все началось, то там кажется основная соль не в микросервисах а вообще в преждевременной оптимизации.
То есть воткнули некое подобие кэша (со стейтом и всеми сопутствующими приключениями) там где он невыгоден. Ну, ок, бывает.
Микросервисы-то тут причём?
Спасибо большое за примеры, выглядит интересно.
Отвечая немного на комментарии про то что использовать специализированные решения для геоданных - мне кажется это сильно усложнит систему. Грубо говоря, если у тебя уже есть большой data lake с настроенным к нему доступом из Spark, то поднимать рядом еще одну систему или использовать какой-то отдельный движок - кажется перебором.
Ну и этот вариант должен достаточно хорошо масштабироваться. Там упомянули что это гигабайты для одного дня для одного региона. Ну то есть если хочется проанализировать данные за год в нескольких регионах - это уже влегкую десятки террабайт. А если их еще хочется какими-то другими данными обогатить? Условно поджойнить на еще какие-то атрибуты и тд.
Да, можно сделать предобработку в Spark, нарезать данные, и проанализировать с помощью чего-то еще… Но зачем, когда тут это практически из коробки?
А для вас правда размер хранимых данных является наиболее важным критерием? Диски вроде бы относительно дешевые в наши дни.
Что насчёт того как эти конструкции ведут себя при чтении? А какой паттерн чтений? Например, часто ли нужно прочитать это дополнительное поле?
Я просто веду к тому что денормализация это иногда действительно очень хорошая штука. Вот только делать это ориентируясь исключительно на размер таблицы… Ну такое.
Выглядит на первый взгляд интересно, но немного удивляет описанная в статье архитектура. Неужели Apollo Federation действительно
торчит голой ж в интернетдоступна с клиентов напрямую?Кажется же что тогда на неё ложиться ещё вагон всяких задач как раз в духе авторизации, прав доступа и тому подобного, или я ошибаюсь? И они, кажется, могут быть уникальны для каждого сетапа.
Но в роли того чтобы на беке собирать забросы по разным микросервисам - выглядит интересно.
Не скажу за все эти компании, но Zalando точно предлагают опционы/акции, и, мне кажется, вплотную к FAANG приближаются по совокупному доходу.
Ну лучший вариант, обычно, рассказать :)
С конкретными примерами, деталями и цифрами. Если же человек не может это вычленить из своего предыдущего опыта, то да, тогда у него проблемы. Но тогда у него несколько более глубокие проблемы связанные с тем, чтобы делать работу не на интуиции, а стабильно и воспроизводимо.
И, да, отчасти, тут начинается "джентельмены верят на слово". Но обычно совсем уж выдуманные кейсы разоблачаются достаточно легко, когда начинаешь углубляться в них и расспрашивать про детали.
Спасибо! Да, оказывается у меня было заблуждение о том, что обращение односторонних функций обычно является NP-полной задачей.
Интересно узнать, что это на самом деле открытый вопрос.
Не могу с этим согласиться. Обычно любому бизнесу нужно именно решение проблем, а не "сеньор админ" или "сеньор программист".
И любые технические собеседования/тестовые задания это не более чем прокси-метрики к оценке того насколько человек умеет решать проблемы.
Но, да, есть вопрос с тем насколько этот навык универсален и насколько получится его показать при процессе найма.
Если человек на прошлом месте поднимал себе зарплату не через разные манипуляции, а показывая свою ценность, то, скорее всего, и людям за пределами компании он сможет её продемонстрировать.
Вот у меня похожий вопрос, который я не совсем понял.
Разве это не тоже самое, что задача о P = NP? Которая давно сведена к решению любой из NP-полных задач?
То есть задача упомянутая в статье это "просто" еще одна NP-полная задача? Судя по тому сколько было проделано работы кажется что нет и где-то кроется принципиальная разница, но, увы, я её не понимаю пока что.
Тоже были очень похожие мысли. Мне сложно говорить конкретно за QA, так как в этой области никогда работать не приходилось, но кажется что это хорошо проецируется на IT в целом.
Как мне кажется, в этом пункте очень важно понимать границы его применимости. С одной стороны, я согласен с автором статьи, что умение человека самостоятельно довести задачу до конца является очень полезным и важном для Senior специалистов.
С другой стороны, ты должен понимать когда нужно остановиться и попросить помощи у коллег, которые более компетентны в данном конкретном кейсе/технологии.
Но очень надеюсь, что «поезд под откос» таким образом пустить невозможно.
Даже если пустить два поезда на встречу на одном пути — есть же механизмы принудительного торможения, если такое произошло, если я ничего не путаю.
Которые реализованы уже на базе семафорной сети на основе просто того что колесной парой замыкается контакт между рельсами.
То есть несмотря на всю серьезность найденных уязвимостей (оставить РЖД без камер видеонаблюдения – это действительно очень стремно) – кажется что настолько жесткий прямой ущерб все-таки невозможен.
Возможно я ошибаюсь, все-таки это совсем не моя сфера интересов и знаю я её в основном по статьям на хабре же :)
Навскидку кажется, что MPP-базы подошли бы лучше (Vertica / ClickHouse).
Ну и при определенной фантазии и в одну классическую реляционную БД можно уложиться, кажется.
Или это всё цифры по какому-то одному производству / тех.процессу и планируется их масштабирование на порядки?
Как объясняется такое большое отличие для medium при прогретом и непрогретом кэше и отсутствие такого отличия для large?
TOAST-таблица не может быть эффективно закэширована на уровне Postgres?
Первая — давать фидбек, вторая — принимать решение о найме.
Давать фидбек по ходу интервью выглядит абсолютно нормальной практикой. Обсуждаешь с кандидатом вопрос — «финализировали» его, сказали, что «ок все, круто», ну или «ну, норм, но я ожидал еще вот то-то и то-то».
Тут же принимать решение о найме / переходе на следующий этап, лично для меня, кажется спорным по разным причинам.
Во-первых, все-таки есть шанс принять решение на «эмоциях». Мне бывает лучше все-таки записать выводы по собесу, чуть «выдохнуть» и потом уже принять решение.
Во-вторых, когда ведется собеседование вдвоём – у нас принята схема, что каждый независимо пишет свои выводы по кандидату и потом уже принимается решение. На мой взгляд, это позволяет уменьшить влияние мнений интервьюеров друг на друга.
Для меня было принципиально понять — это совсем редкие кейсы, единичные для отрасли, или же просто действительно хорошие разработчики.
Получается, что достаточно значительное количество людей выбивается за эти границы. Кажется, что было бы здорово это указать где-то в исследовании — это достаточно важно как для кандидатов, так и для компаний.
Грубо говоря, осознание того, что если вы / вам нужен человек из топ-10% сегмента, то стоить это будет дороже.