A
if (fs.rename(tempPath, path)) {
renameDone = true
} else {Size: a a a
2020 July 24
A
хотя вру, в
* This implementation of rename is atomic.
DistributedFileSystem даже этот “неатомарный” метод оверрайдится и уходит в хдфс одним запросом на методе у которого * This implementation of rename is atomic.
A
либо разрабы дельты не смотрели реализации в хдфс и поверили на слово коментарию
ну или они что-то очень интересное знают =) и мне тоже хочется это знать
ну или они что-то очень интересное знают =) и мне тоже хочется это знать
AS
еще раз, уровни абстракции:
FileSystem (delta) -> HdfsFileSystem (hadoop) -> physical OS
В дельта говорится:
* This implementation should only be used for the underlying file systems that support atomic
* renames, e.g., Azure is OK but HDFS is not.
В HdfsFileSystem говорится:
В этом комменте речь идет о том, что если физическая FS под HDFS гарантирует atomic rename, то и операция в HDFS гарантированно атомарная. Соответственно вопрос - гарантирует ли ваша physical fs (скажем ext4) atomic rename, в особенности под большой нагрузкой. Последнего я не знаю, это все таки не моя сфера деятельности
FileSystem (delta) -> HdfsFileSystem (hadoop) -> physical OS
В дельта говорится:
* This implementation should only be used for the underlying file systems that support atomic
* renames, e.g., Azure is OK but HDFS is not.
В HdfsFileSystem говорится:
Note that atomicity of rename is dependent on the file system implementation. Please refer to the file system documentation for details. This default implementation is non atomic.В этом комменте речь идет о том, что если физическая FS под HDFS гарантирует atomic rename, то и операция в HDFS гарантированно атомарная. Соответственно вопрос - гарантирует ли ваша physical fs (скажем ext4) atomic rename, в особенности под большой нагрузкой. Последнего я не знаю, это все таки не моя сфера деятельности
если верить документации, то поддерживает, если включена auto_da_alloc (по умолчанию включена)
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
AE
а добавь картиночку в ридми
ага, добавил
A
@smirnov_captain операции с метаданными оторваны зачастую от операций с данными, в неймноде они под RW lock все
переименование - операция только на стороне метаданных
удаление - только на уровне метаданных, блоки потом с задержкой уйдут на удаление (там может быть много плясок потом ещё если включен hdfs raid и nl)
а вот у записи более жесткая связка на fsync и тд
да, это всё относится именно к hdfs
если используется просто интерфейс и
там уже нужно смотреть линку которую вы нашли
переименование - операция только на стороне метаданных
удаление - только на уровне метаданных, блоки потом с задержкой уйдут на удаление (там может быть много плясок потом ещё если включен hdfs raid и nl)
а вот у записи более жесткая связка на fsync и тд
да, это всё относится именно к hdfs
если используется просто интерфейс и
RawLocalFileSystem то падает уже в FileSystem java которая в нативку уходит и на обычную fsтам уже нужно смотреть линку которую вы нашли
AZ
либо разрабы дельты не смотрели реализации в хдфс и поверили на слово коментарию
ну или они что-то очень интересное знают =) и мне тоже хочется это знать
ну или они что-то очень интересное знают =) и мне тоже хочется это знать
Для них это не целевая платформа, дельта осс по сути это инструмент РоС перед тем как заехать на проприетарный продукт
A
из-за RW lock попытка удалить много данных может поставить колом может всю hdfs =( даже их тротлер не срабатывает
типо “после N записей отпустим лок, выйдем из цикла и потом опять захватим”
типо “после N записей отпустим лок, выйдем из цикла и потом опять захватим”
R
@smirnov_captain операции с метаданными оторваны зачастую от операций с данными, в неймноде они под RW lock все
переименование - операция только на стороне метаданных
удаление - только на уровне метаданных, блоки потом с задержкой уйдут на удаление (там может быть много плясок потом ещё если включен hdfs raid и nl)
а вот у записи более жесткая связка на fsync и тд
да, это всё относится именно к hdfs
если используется просто интерфейс и
там уже нужно смотреть линку которую вы нашли
переименование - операция только на стороне метаданных
удаление - только на уровне метаданных, блоки потом с задержкой уйдут на удаление (там может быть много плясок потом ещё если включен hdfs raid и nl)
а вот у записи более жесткая связка на fsync и тд
да, это всё относится именно к hdfs
если используется просто интерфейс и
RawLocalFileSystem то падает уже в FileSystem java которая в нативку уходит и на обычную fsтам уже нужно смотреть линку которую вы нашли
Провел небольшой рисеч, да, файловые гарантии для HDFS сохраняются, а коммент outdated:
Вот https://docs.delta.io/latest/delta-storage.html#hdfs :
Вот https://docs.delta.io/latest/delta-storage.html#hdfs :
You can use Delta Lake to read and write data on HDFS. Delta Lake supports concurrent reads and writes from multiple clusters.
A
спасибо
SS
коллеги, кто как редеплоит Spark Structured Streaming жобы через Livy?
A
стриминг не деплоил
но там же только вопрос в конфиге
livy вызывает shell комманду spark-submit
так что главное conf корректный подать
но там же только вопрос в конфиге
livy вызывает shell комманду spark-submit
так что главное conf корректный подать
SS
если я не ошибаюсь:
curl -X DELETE
убивает спарк-сессию, а я хочу корректно остановить стриминг-сессию
curl -X DELETE
убивает спарк-сессию, а я хочу корректно остановить стриминг-сессию
SS
для корректной остановки Streaming-жобы перед редеплоем нужно:
1) настроить в коде Spark сессии бесконечный цикл с проверкой раз в минуту(?) наличия файла-маркера в HDFS. если появился - останавливать стриминг сессию и завершать спарк сессию
2) как-то по REST закидывать файл-маркер в HDFS
3) дожидаться пока REST к Livy скажет, что джоба умерла
4) задеплоить новый код и запустить через Livy
1) настроить в коде Spark сессии бесконечный цикл с проверкой раз в минуту(?) наличия файла-маркера в HDFS. если появился - останавливать стриминг сессию и завершать спарк сессию
2) как-то по REST закидывать файл-маркер в HDFS
3) дожидаться пока REST к Livy скажет, что джоба умерла
4) задеплоить новый код и запустить через Livy
SS
или как-то проще можно?
A
если вам там что-то сильно аккуратно останавливать то да, какой-то маркер нужен
неважно хдфс/зукипер/консул
ну и 4 может я бы делал первым пунктом, чтобы быть уверенным что jar уже на хдфс новый лежит
неважно хдфс/зукипер/консул
ну и 4 может я бы делал первым пунктом, чтобы быть уверенным что jar уже на хдфс новый лежит
A
а уже потом останавливал всё
2020 July 25
SS
коллеги, поделитесь если не жалко примером gitlab-ci.yml для деплоя spark streaming джобы в Livy...
S
из-за RW lock попытка удалить много данных может поставить колом может всю hdfs =( даже их тротлер не срабатывает
типо “после N записей отпустим лок, выйдем из цикла и потом опять захватим”
типо “после N записей отпустим лок, выйдем из цикла и потом опять захватим”
Ода, и даже не то чтобы множко. Искали почему неймноды переезжать начинают после ухода в себя :(
MB
[ONLINE CONFERENCE]International Conference on Data Mining and Software Engineering (DMSE 2020)
September 26 ~ 27, 2020, Copenhagen, Denmark
Here's where you can reach us : dmseATdmse2020DOTorg
Due to the current COVID-19 pandemic, registered authors are now able to present their work through our online platforms.
September 26 ~ 27, 2020, Copenhagen, Denmark
Here's where you can reach us : dmseATdmse2020DOTorg
Due to the current COVID-19 pandemic, registered authors are now able to present their work through our online platforms.