Альтернативная реализация от Aiven Open не может успешно вычитать записанные ей в удаленное хранилище данные. Для попытки починки необходимо более детально исследовать механизм chunk-ов.
Это вариант, но не то, что я сделал: в этом случае все равно придется установить gdbserver в контейнере.
Я сделал с помощью namespaces. GDB запускается в PID namespace целевого процесса и в новом mount namespace, аналогично nsenter -t <pid> -p unshare --mount-proc gdb ... -p 1. Нужно еще добавить -iex set sysroot /proc/1/root -iex set auto-load safe-path /proc/1/root/<solib paths> -iex set solib-search-path /proc/1/root/<solib paths>. Еще важно: если в mount namespace GDB есть такой же путь к бинарнику, как в mount namespace целевого процесса (условно /usr/bin/python3), то его нужно скрыть (с помощью bind mount, например), чтобы GDB читал символы из /proc/1/exe.
В каждом контейнере нашего кластера запущен демон, который просыпается раз в несколько минут в случайные моменты времени и присоединяется к профилируемому процессу с помощью GDB.
Кстати, я тут экспериментировал для одного своего проекта и мне удалось сделать так, что GDB подключается к процессу в контейнере, считывает символы там же, но при этом сам установлен и запущен на хосте. Т.е. технически в вашем случае можно было бы запускать один экземпляр демона.
Если так, то не позиционируйте себя как джуна. Делайте упор на свой общий инженерный опыт и т.п. Если человек умеет писать осмысленный код, покрывать его тестами, связно коммуницировать со всеми включенными в процесс, то это уже не джун.
В дейта инжиниринге бывают любые странные сочетания форматов и их преобразований и разные странные кейсы. Например, огромные CSV могут прилетать через какую-то интеграцию извне и конвертировать их в какой-нибудь Parquet, поддерживать преобразованные файлы в актуальном состоянии и т.п. -- лишний геморой, усложнение пайплайна и занятие времени инженеров. Нужны веские причины это делать. А этот SIMD-код нужно написать и поддерживать тольо внутри условного Spark, дальше его все просто используют (даже не зная об этом).
честно говоря не понял, чего и ради чего ускоряется
CSV -- популярный формат для самых разных данных. Если 50 гигабайт CSV приходится перелопачивать много раз за день, то хорошо чтобы бы это происходило быстро.
Обязательно посмотрим, в чем проблема!
Привет
Я разработчик remote storage manager плагина https://github.com/Aiven-Open/tiered-storage-for-apache-kafka, использованного в статье. Как говорится, ask me anything
Возможно, режим тренировок не оптимальный, организм не успевает восстановиться и возникает перетренированность.
Это вариант, но не то, что я сделал: в этом случае все равно придется установить gdbserver в контейнере.
Я сделал с помощью namespaces. GDB запускается в PID namespace целевого процесса и в новом mount namespace, аналогично
nsenter -t <pid> -p unshare --mount-proc gdb ... -p 1. Нужно еще добавить-iex set sysroot /proc/1/root -iex set auto-load safe-path /proc/1/root/<solib paths> -iex set solib-search-path /proc/1/root/<solib paths>. Еще важно: если в mount namespace GDB есть такой же путь к бинарнику, как в mount namespace целевого процесса (условно/usr/bin/python3), то его нужно скрыть (с помощью bind mount, например), чтобы GDB читал символы из/proc/1/exe.Метод 6: использовать gVisor в качестве рантайма, чтобы существенно сократить возможность побега из контейнера через уязвимости ядра.
Кстати, я тут экспериментировал для одного своего проекта и мне удалось сделать так, что GDB подключается к процессу в контейнере, считывает символы там же, но при этом сам установлен и запущен на хосте. Т.е. технически в вашем случае можно было бы запускать один экземпляр демона.
Если интересно, могу рассказать подробнее.
Наполеоновские войны?
За рубежом ИТ -- это тоже денежно (сильно выше среднего по стране даже в социалистической Европе) и престижно.
А как "технологии" помогут решить эти проблемы?
В общем, других причин и не надо.
Go - основной язык в компании.
Citation needed. Я не знаю про .NET, но Java и JVM не "менее эффективны" (чтобы это не значило).
Люди программируют не только веб с микросервисами
Если так, то не позиционируйте себя как джуна. Делайте упор на свой общий инженерный опыт и т.п. Если человек умеет писать осмысленный код, покрывать его тестами, связно коммуницировать со всеми включенными в процесс, то это уже не джун.
Ну а еще есть просто работа на C++.
В дейта инжиниринге бывают любые странные сочетания форматов и их преобразований и разные странные кейсы. Например, огромные CSV могут прилетать через какую-то интеграцию извне и конвертировать их в какой-нибудь Parquet, поддерживать преобразованные файлы в актуальном состоянии и т.п. -- лишний геморой, усложнение пайплайна и занятие времени инженеров. Нужны веские причины это делать. А этот SIMD-код нужно написать и поддерживать тольо внутри условного Spark, дальше его все просто используют (даже не зная об этом).
CSV -- популярный формат для самых разных данных. Если 50 гигабайт CSV приходится перелопачивать много раз за день, то хорошо чтобы бы это происходило быстро.
Наоборот, первое - это худший случай, а второе -- лучший :)
С одной машины трафика будет, наверное, как с просмотра ролика на Ютьюбе. Т.е. так мало, что можно не считать.
Да.