Однако, парадокс, там где результаты подзапроса используются как дополнительный набор данных (а результат берется отдельным проходом по таблице) - в explain нет слова subsquery, а там где результат подзапроса непосредственно используется для вывода (после фильтра) - это Subquery Scan :-).
Не взяли то наверное не из за ответа на джуновую задачку (очевидно что хардскиллы выше необходимого на джуновый уровень), а скорее из за неумения общаться и излишней самоуверенности?
Btw, в реальности предпочту решение через rank, так как на производительность в данном случае пофиг, да и индекса по salary скорее всего не будет. А решение с rank не делает полноценных подзапросов/джойнов, и делает в явном виде именно то что требуется в задаче без хаков.
Моя любимая задачка про оконные функции:
Есть файл (или табличка, как удобнее кандидату) куда пишутся значения показателей датчиков. Каждая запись содержит таймстемп, идентификатор датчика, и набор значений его показателей в указанный момент времени. Значения показателей меняются сильно реже интервала считывания. Нужно отфильтровать записи, в которых не происходит изменения значений показателей.
Область MLOps является еще достаточно молодой, и в ней до сих пор не существует единого золотого стандарта.
Я бы сказал что существует пара-тройка, airflow/kubeflow/или любое CI с графами задач, mlflow/wandb/свой велосипед, + dvc по вкусу, либо фуллстек решения databricks/azure?/AWS sagemaker. Но главное конечно - выстроенные процессы, политики, регламенты, и стайлгайды вокруг всего этого, и в статье неплохо описано что они должны покрывать. Но все равно стоит поизучайть доклады по жизненному циклу моделей с Data fest'ов ODS (кажется по ним уже можно сказать что общее понимание как жить mlops инженеру, "золотой стандарт", уже сложилось), да и в целом много информации на Хабре и в интернете на эту тему. А из "300 инструментов интеграции" надо определиться для чего инструменты нужны, ну и, скажем, если включать библиотеки как в посте на картинке, то штук 200 нужных инструментов освоить не такая уж проблема.
Ролик был виральный, как школьница в магазине домашку делала утащив планшет под прилавок. А продавец вместо того чтоб выгнать - поставил ей стул, геймерский.
Проверил - аккаунт ещё живой. Даже пароль почти с первого раза вспомнил (только оно попросило привязать телефон).
Из всей истории - только пара сообщений 2017 года. Старую историю ещё при переезде в мэйл продолбали, жалко :-(. Но вообще она у меня где-то на DVD-шках в кладовке забэкаплена, поищу повспоминаю через лет десять.
Подпись должна идти вместе с образом, а для ее проверки достаточно знать используемый публичный ключ... но Docker Inc всё ещё "We are working on integrating signature validation into our image pull and build processes. This will ensure that all Docker Official Images are verified before use, providing an additional layer of security for our users." (линк), так что проверять пока нечего.
→ docker trust inspect ubuntu:latest --pretty
Signatures for ubuntu:latest
SIGNED TAG DIGEST SIGNERS latest 3f85b7caad41a95462cf5b787d8a04604c8262cdcdf9a472b8c52ef83375fe15 (Repo Admin)
Концепция "всё есть capability" (everything is a capability) представляет собой подход к дизайну систем, где основным элементом является понятие "способности" или "права" (capability), которое определяет, что именно может делать программа или процесс в системе. Эта идея фокусируется на безопасности и изолировании, позволяя контролировать доступ к ресурсам на более тонком уровне, чем традиционные модели, основанные на разграничении доступа (например, Unix-подобные права на файлы).
В контексте "всё есть capability":
1. **Определение**: Capability — это ключ или токен, который предоставляет держателю право на выполнение определенной операции или доступ к ресурсу. Важной особенностью является то, что capability конкретизирует и минимизирует права, тем самым предотвращая злоупотребления и ограничивая возможные точки сбоя.
2. **Ресурсы и операции**: В системе, основанной на capabilities, всё, что требует контроля доступа — файлы, устройства, сетевые соединения и даже более абстрактные действия, такие как возможность перезагрузки системы — представляется через capability. Это означает, что для любого действия или доступа к ресурсу существует соответствующая capability.
3. **Делигирование и распространение**: Capability можно передавать от одного процесса к другому, позволяя создавать тонко настроенные цепочки доверия и делегирования прав. Это делает систему гибкой и позволяет строить сложные многоуровневые архитектуры безопасности.
4. **Изоляция и безопасность**: Использование capability обеспечивает естественную изоляцию между компонентами системы, поскольку каждый компонент имеет доступ только к тем ресурсам, для которых у него есть явно выданные права. Это снижает риск несанкционированного доступа и предотвращает множество атак, связанных с повышением привилегий.
5. **Примеры систем**: Некоторые операционные системы и платформы, например, Genode OS Framework или Google's Fuchsia, используют концепции, близкие к идеям capability для обеспечения безопасности и изоляции.
Концепция "всё есть capability" может значительно улучшить безопасность и гибкость системы за счет более точного контроля над тем, кто и как может взаимодействовать с ресурсами системы. Однако реализация такого подхода требует сложного дизайна и администрирования, а также может потребовать от разработчиков и пользователей изменения привычного подхода к взаимодействию с системой.
Нужно лучше курить матчасть против которой ведёшь риторику, и быть дотошным в тезизах, а так статья хорошая, молодец. Покури ещё концепцию "всё есть capability".
Сложная тема, чтобы представить как оно работает в случае cluster mode или spark submit (не будет ли каких-то side effect от перезапуска драйвера), нужно как минимум понимать как взаимодействуют yarn/driver/applicationmaster.
Помимо прочего, после завершения JVM-процесса драйвера необходимо корректно завершить все открытые соединения с ним. Для этого достаточно вызвать метод shutdown() у экземпляра класса JavaGateway
А нельзя просто shutdown позвать без всех извращений с ручной отправкой команд?
Однако, парадокс, там где результаты подзапроса используются как дополнительный набор данных (а результат берется отдельным проходом по таблице) - в explain нет слова subsquery, а там где результат подзапроса непосредственно используется для вывода (после фильтра) - это Subquery Scan :-).
Лол, пока читал комменты забыл что в статье это решение приведено :-)
(с подачей "и это не то!!!" вместо объяснения про сортировку просто не обратил внимания на это решение)
Задание со звёздочкой для оригинальной задачи (про зарплаты) - как решить её через оконные функции, но без сортировки.
Не взяли то наверное не из за ответа на джуновую задачку (очевидно что хардскиллы выше необходимого на джуновый уровень), а скорее из за неумения общаться и излишней самоуверенности?
Btw, в реальности предпочту решение через rank, так как на производительность в данном случае пофиг, да и индекса по salary скорее всего не будет. А решение с rank не делает полноценных подзапросов/джойнов, и делает в явном виде именно то что требуется в задаче без хаков.
Моя любимая задачка про оконные функции:
Есть файл (или табличка, как удобнее кандидату) куда пишутся значения показателей датчиков. Каждая запись содержит таймстемп, идентификатор датчика, и набор значений его показателей в указанный момент времени. Значения показателей меняются сильно реже интервала считывания. Нужно отфильтровать записи, в которых не происходит изменения значений показателей.
Я бы сказал что существует пара-тройка, airflow/kubeflow/или любое CI с графами задач, mlflow/wandb/свой велосипед, + dvc по вкусу, либо фуллстек решения databricks/azure?/AWS sagemaker. Но главное конечно - выстроенные процессы, политики, регламенты, и стайлгайды вокруг всего этого, и в статье неплохо описано что они должны покрывать. Но все равно стоит поизучайть доклады по жизненному циклу моделей с Data fest'ов ODS (кажется по ним уже можно сказать что общее понимание как жить mlops инженеру, "золотой стандарт", уже сложилось), да и в целом много информации на Хабре и в интернете на эту тему. А из "300 инструментов интеграции" надо определиться для чего инструменты нужны, ну и, скажем, если включать библиотеки как в посте на картинке, то штук 200 нужных инструментов освоить не такая уж проблема.
Нормально оно в карман влазит, уже чуть не постирал.
Не понимаю нафига нужны миники на интелах, когда со встройкой AMD любые игры идут.
Ролик был виральный, как школьница в магазине домашку делала утащив планшет под прилавок. А продавец вместо того чтоб выгнать - поставил ей стул, геймерский.
Вот! Вот оно, настоящее пиратство!) Крадут приложения прямо из магазина!!! :-)
Крошить без оглядки это IDKFA.
Проверил - аккаунт ещё живой. Даже пароль почти с первого раза вспомнил (только оно попросило привязать телефон).
Из всей истории - только пара сообщений 2017 года. Старую историю ещё при переезде в мэйл продолбали, жалко :-(. Но вообще она у меня где-то на DVD-шках в кладовке забэкаплена, поищу повспоминаю через лет десять.
Подпись должна идти вместе с образом, а для ее проверки достаточно знать используемый публичный ключ... но Docker Inc всё ещё "We are working on integrating signature validation into our image pull and build processes. This will ensure that all Docker Official Images are verified before use, providing an additional layer of security for our users." (линк), так что проверять пока нечего.
→ docker trust inspect ubuntu:latest --pretty
Signatures for ubuntu:latest
SIGNED TAG DIGEST SIGNERS
latest 3f85b7caad41a95462cf5b787d8a04604c8262cdcdf9a472b8c52ef83375fe15 (Repo Admin)
Administrative keys for ubuntu:latest
Repository Key: 8273733f491f362bb36710fd8a99f78c3fbaecd8d09333985c76f1064b80760f
Root Key: 1f9bc7ae6335ae41ee03e983c0e31303901be567b4cdb3fc7c7363f0591128ff
Выглядит так, как будто подписи тут нет.
Плохой способ - ключ шифрования мог быть слабый сгенерерирован, или одинаковый на всю серию. Надо выводить из строя сами чипы памяти, без вариантов.
Hidden text
Концепция "всё есть capability" (everything is a capability) представляет собой подход к дизайну систем, где основным элементом является понятие "способности" или "права" (capability), которое определяет, что именно может делать программа или процесс в системе. Эта идея фокусируется на безопасности и изолировании, позволяя контролировать доступ к ресурсам на более тонком уровне, чем традиционные модели, основанные на разграничении доступа (например, Unix-подобные права на файлы).
В контексте "всё есть capability":
1. **Определение**: Capability — это ключ или токен, который предоставляет держателю право на выполнение определенной операции или доступ к ресурсу. Важной особенностью является то, что capability конкретизирует и минимизирует права, тем самым предотвращая злоупотребления и ограничивая возможные точки сбоя.
2. **Ресурсы и операции**: В системе, основанной на capabilities, всё, что требует контроля доступа — файлы, устройства, сетевые соединения и даже более абстрактные действия, такие как возможность перезагрузки системы — представляется через capability. Это означает, что для любого действия или доступа к ресурсу существует соответствующая capability.
3. **Делигирование и распространение**: Capability можно передавать от одного процесса к другому, позволяя создавать тонко настроенные цепочки доверия и делегирования прав. Это делает систему гибкой и позволяет строить сложные многоуровневые архитектуры безопасности.
4. **Изоляция и безопасность**: Использование capability обеспечивает естественную изоляцию между компонентами системы, поскольку каждый компонент имеет доступ только к тем ресурсам, для которых у него есть явно выданные права. Это снижает риск несанкционированного доступа и предотвращает множество атак, связанных с повышением привилегий.
5. **Примеры систем**: Некоторые операционные системы и платформы, например, Genode OS Framework или Google's Fuchsia, используют концепции, близкие к идеям capability для обеспечения безопасности и изоляции.
Концепция "всё есть capability" может значительно улучшить безопасность и гибкость системы за счет более точного контроля над тем, кто и как может взаимодействовать с ресурсами системы. Однако реализация такого подхода требует сложного дизайна и администрирования, а также может потребовать от разработчиков и пользователей изменения привычного подхода к взаимодействию с системой.
Нужно лучше курить матчасть против которой ведёшь риторику, и быть дотошным в тезизах, а так статья хорошая, молодец. Покури ещё концепцию "всё есть capability".
Сложная тема, чтобы представить как оно работает в случае cluster mode или spark submit (не будет ли каких-то side effect от перезапуска драйвера), нужно как минимум понимать как взаимодействуют yarn/driver/applicationmaster.
А нельзя просто shutdown позвать без всех извращений с ручной отправкой команд?
(сорян, промазал полем ответа)
Чем в таком кейсе не подошёл dynamic allocation?
И что помешало разбить процесс на несколько задач (на уровне оркестратора)?
Интересный факт, фанаты эппла и не подозревают о возможности подключения внешней видеокарты (и о том что на apple silicon такой возможности нет :-) ).
Вместо этого у эппла есть возможность продать фичу подключения нескольких мониторов :-).