Не так давно работал с ним активно, использовал для отладки кода Spark Streaming в PyCharm под Windows, показалось очень удобно и позволяет гораздо больше. "Сырость" сейчас есть, но она скорее относится к безопасности — это отсутствие имперсонализации. Над исправлением этого недостатка сейчас активно работают.
Спасибо за комментарий! Spark Connect меняет архитектуру взаимодействия клиента и драйвера, но сам сервер Spark продолжает работать как обычный Spark. То есть, доступ к источникам данных (базам, хранилищам, файловым системам) осуществляется именно со стороны кластера Spark. Если вы в коде подключаетесь к S3/HDFS, то эти подключения инициируются от имени пользователя, от которого запущен Server Spark Connect. Сейчас имперсонализация в Spark Connect не работает, в отличие от других инструментов в составе дистрибутива. Но в будущих версиях мы планируем это исправить. В «ванильном Spark» я планов по исправлению не видел.
Коллеги, а в чем Ваши тайные знания настройки? Взять в два раза больший по ресурсам экземпляр Minio и получить границу деградации в другом диапазоне? Настройка Minio для подобных тестов очень подробно описана в расширенной статье сравнения Minio vs HDFS самими инженерами Minio (Minio vs HDFS), это не искусство. Достаточно только повторить, со своими параметрами.
Важно, а где пример c HDFS, Ozone, на сколько они деградировали на подобном оборудовании? Правильно, они возможно с этим оборудованием вообще не дошли бы до границы деградации. И главное, Вы не очень поняли суть статьи, на деградацию влияет не сам по себе размер файлов. Процессинговый движок «выедает» ресурс (rps) s3 при обработке этих маленьких файлов и начинается интенсивная деградация. Вы получили деградацию в 2,5! раза на границы 140 тыс. файлов за 1000 сек. Прекрасно! Увеличите взятое количество файлов (так как ресурсов выделено значительно больше) и когда получите 8-10, то дальше, сравните это с HDFS (Ozone) и может мы сойдемся в результатах.)) В целом, считаю это подтверждением выводов, которые я представил в своей статье. Спасибо!
Кажется, что ответ вы не читаете, повторю, minio сравнивали только к minio. В статье нет утверждений типа "minio/ozone производительнее чем..." Для minio были диски SSD два. 4 ядра 16 Гб на узел. 4 узла. Для такого объема датасета вполне.
Мы не сравниваем производительность объектного хранилища A и B в каких-либо единицах. И не хотим, чтобы кто-то делал это на основе нашей статьи. Мы сравниваем поведение хранилища при изменении условий. Т.е. вариант А в момент t1 при условии X1 и в t2 при условии X2, естественно, на одних и тех же машинах. Поэтому акцента на оборудовании нет. Оно адекватное и вполне используемо в производственных малых инсталляциях, оно в целом идентично по ядрам и памяти. Но оборудование вообще не имеет значения, как и не имеют значения абсолютные величины измерения. Но имеет значения только поведение, а именно, деградация производительности на одном и том же железе.
На счет оптимизации при загрузке следует отметить. Включена оптимизация или не включена – маленькие файлы будут.
По поводу «А что мешает выбирать правильную Lakehouse-платформу, в которой есть агрегация мелких файлов в S3» - читайте внимательней, есть ссылки на статьи по исследованию некоторого количества озер данных. Маленькие файлы есть там по множеству причин. Смысл об этом спорить? Это данность эксплуатации больших систем. Ее необходимо просто принять.
По поводу «Ждем теста real-time загрузки данных в GreenPlum!» - так она (загрузка) есть)). Есть Kafka-ADB коннектор, который работает в проде, да и на наших стендах он выдает неплохой перфоманс при загрузке CDC-логов.
Вы правы, S3 — это именно протокол, и напрямую он не ограничивает производительность. В статье речь не о самом протоколе, а о том, как его текущие on-premise реализации (в частности, MinIO) ведут себя в сценариях с большим количеством мелких файлов — и именно в этих реализациях возникают серьёзные узкие места.
При этом даже в облачных сервисах (AWS S3 и др.) при активной работе с мелкими файлами остаются фундаментальные ограничения из-за особенностей API (работа по HTTP, операции с метаданными и т. п.). Поэтому вопрос не только в реализации, но и в архитектурной природе подхода.
Спасибо! Нам кажется, что это все-таки немного разные средства и цели их внедрения различаются, но возможно они могут решать одни и те же задачи. По этой причине не сравнивали.
Спасибо!
Не так давно работал с ним активно, использовал для отладки кода Spark Streaming в PyCharm под Windows, показалось очень удобно и позволяет гораздо больше. "Сырость" сейчас есть, но она скорее относится к безопасности — это отсутствие имперсонализации. Над исправлением этого недостатка сейчас активно работают.
Спасибо за комментарий!
Spark Connect меняет архитектуру взаимодействия клиента и драйвера, но сам сервер Spark продолжает работать как обычный Spark. То есть, доступ к источникам данных (базам, хранилищам, файловым системам) осуществляется именно со стороны кластера Spark. Если вы в коде подключаетесь к S3/HDFS, то эти подключения инициируются от имени пользователя, от которого запущен Server Spark Connect. Сейчас имперсонализация в Spark Connect не работает, в отличие от других инструментов в составе дистрибутива. Но в будущих версиях мы планируем это исправить. В «ванильном Spark» я планов по исправлению не видел.
Коллеги, а в чем Ваши тайные знания настройки? Взять в два раза больший по ресурсам экземпляр Minio и получить границу деградации в другом диапазоне? Настройка Minio для подобных тестов очень подробно описана в расширенной статье сравнения Minio vs HDFS самими инженерами Minio (Minio vs HDFS), это не искусство. Достаточно только повторить, со своими параметрами.
Важно, а где пример c HDFS, Ozone, на сколько они деградировали на подобном оборудовании? Правильно, они возможно с этим оборудованием вообще не дошли бы до границы деградации. И главное, Вы не очень поняли суть статьи, на деградацию влияет не сам по себе размер файлов. Процессинговый движок «выедает» ресурс (rps) s3 при обработке этих маленьких файлов и начинается интенсивная деградация. Вы получили деградацию в 2,5! раза на границы 140 тыс. файлов за 1000 сек. Прекрасно! Увеличите взятое количество файлов (так как ресурсов выделено значительно больше) и когда получите 8-10, то дальше, сравните это с HDFS (Ozone) и может мы сойдемся в результатах.)) В целом, считаю это подтверждением выводов, которые я представил в своей статье. Спасибо!
Кажется, что ответ вы не читаете, повторю, minio сравнивали только к minio. В статье нет утверждений типа "minio/ozone производительнее чем..." Для minio были диски SSD два. 4 ядра 16 Гб на узел. 4 узла. Для такого объема датасета вполне.
Мы не сравниваем производительность объектного хранилища A и B в каких-либо единицах. И не хотим, чтобы кто-то делал это на основе нашей статьи. Мы сравниваем поведение хранилища при изменении условий. Т.е. вариант А в момент t1 при условии X1 и в t2 при условии X2, естественно, на одних и тех же машинах. Поэтому акцента на оборудовании нет. Оно адекватное и вполне используемо в производственных малых инсталляциях, оно в целом идентично по ядрам и памяти. Но оборудование вообще не имеет значения, как и не имеют значения абсолютные величины измерения. Но имеет значения только поведение, а именно, деградация производительности на одном и том же железе.
На счет оптимизации при загрузке следует отметить. Включена оптимизация или не включена – маленькие файлы будут.
По поводу «А что мешает выбирать правильную Lakehouse-платформу, в которой есть агрегация мелких файлов в S3» - читайте внимательней, есть ссылки на статьи по исследованию некоторого количества озер данных. Маленькие файлы есть там по множеству причин. Смысл об этом спорить? Это данность эксплуатации больших систем. Ее необходимо просто принять.
По поводу «Ждем теста real-time загрузки данных в GreenPlum!» - так она (загрузка) есть)). Есть Kafka-ADB коннектор, который работает в проде, да и на наших стендах он выдает неплохой перфоманс при загрузке CDC-логов.
Вы правы, S3 — это именно протокол, и напрямую он не ограничивает производительность. В статье речь не о самом протоколе, а о том, как его текущие on-premise реализации (в частности, MinIO) ведут себя в сценариях с большим количеством мелких файлов — и именно в этих реализациях возникают серьёзные узкие места.
При этом даже в облачных сервисах (AWS S3 и др.) при активной работе с мелкими файлами остаются фундаментальные ограничения из-за особенностей API (работа по HTTP, операции с метаданными и т. п.). Поэтому вопрос не только в реализации, но и в архитектурной природе подхода.
Спасибо! Нам кажется, что это все-таки немного разные средства и цели их внедрения различаются, но возможно они могут решать одни и те же задачи. По этой причине не сравнивали.