По России еще можно вроде, но зарубеж точно накрылся вродь как

JB по России тоже забанил

а кто-нить знает можно ли в спарк джобе (именно в джобе) как-то чекпоинтить данные, чтобы в случае ошибки не пересчитывать какую-то операцию?

Или же просто разбивать на большее количество джобов?

Так есть же метод checkpoint или я не понял?

.persist на диск или .cache в память - подойдет?

Допустим долго работующий spark job ломается в самом конце, как сделать, чтобы следующий retry (в airflow, например) не пересчитывал все, а продолжил с момента ошибки?

Я так понимаю persist или cache только в процессе выполнения job'а, после выхода (в случае ошибки) сотрется

а checkpoint это точно не только для spark streaming?

Разбивать на независимые индеподентные таски в Airflow

Ну я так и думал

Коллеги, всем доброго времени суток.

Подскажите плиз теорию. И насколько плохо может быть кластеру от моих клешен)

Задача: Ежедневное выкачивание цен из HANA. Знаем что меняться может только дата действия цены "по". Поэтому было решено партиционировать таблицу по "дата по". И ежедневно сравнивая HANA с HIVE перевыкачивать такие партиции.

Ньюансы:
1. Куча партиций по 1 строке. Когда кто-то делает цену по "2238-12-31" и тому подобное.
2. Партиция в 400млн строк с датой "9999-12-31" (так ведут все активные цены.
Насколько это плохо?

Вопрос по Спарку: Подключаясь по jdbc к HANE и качая партицию в 400млн, я вижу что в HANA "отъедаю" всего 3-4GB памяти. Есть подозрение что Спарк как то качает батчами и в один поток? Что бы можно было покрутить, чтобы ускорить  выкачивание? (и не убить ХАНУ)

У спарка jdbc умеет забирать патрициями. См. Параметры numParitions в настройках ридера. На каждую партицию спарк будет открывать новую коннекцию. Единственное надо бы знать поле по которому можно запараллелить загрузку или сделать его искусственно либо перед загрузкой либо во время сгенерить новое поле (но не забыть про материализацию данных) если у вас есть поле с датой это неплохой выбор, достаточно будет знать верхнюю и нижнюю границу дат которые вы загружаете, но с партицией на 400млн будет плохо.

Ну вот сейчас он тянет 400 млн чуть больше 2х часов. И мне кажется (по ощущениям) что можно это сделать быстрее, как минимум просто взяв бОльшую партицию. Потом уже упрусь в сеть и запись на диски. Но этого даже не требуется. Сократить бы время хотя бы до 1 часа для начала.

А если есть поле "дата по" может есть и "дата с" и попробовать распараллелить по нему ?

partitionColumn, lowerBound, upperBound - вот эти параметры

Тогда небольшие партиции по "дате по" превратятся в кучу мелких. А это уже плохо вроде.

Сейчас получается около 700 партиций, более менее равных. С "выбросами" типа партиций в 1 строку и одна огромная в 400 млн)

был опыт и через orahash бить данные на равные части в террадате, если совсем туго с равномерно распределенным полем, можно посмотреть в эту сторону

Ищите поле по которому можно равномерно забрать)) репартишен в нужную вам структуру сделаете уже в спарке

может быть получится сделать с "дата по" + какое то поле что бы разбавить 400кк строк.=) в качестве имени таблицы можно передать подзапрос

Правильно я понимаю?
Спарком я могу разбить 1 большую партицию на несколько меньших? Это позволит выкачивать быстрее данные?

Пока мне видится, просто решение - это увеличить кол-во вычитываемых данных за раз. Т.к. ХАНА может выделить существенно больше 3-4GB на коннект и по идее отдавать данные быстрее.

да, но нужен ключ для разбивки, если ключ одинаков, то партиция будет одна