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

может когда у нас будет будет поддержка arrow flight вы сможете без дополнительной перепаковки гнать в терадатку, но сейчас ему нужно построчное представление чтобы начать передавать данные

А юзаешь tdch.teradata.output.truncate?  Проблем или багов не замечал?

это просто очистка таблицы, нужна для того чтобы fastload работал (он умеет только в пустую таблицу), должна работать без проблем

full disclaimer, я его использовал, а также чинил и дописывал потому что тружусь в терадате

если какой-то воспроизводимый баг то его можно завести и пофиксить без проблем, там довольно тривиально все внутри

Спасибо за помощь :)

привет всем, тут вообщем у меня вопрос возник. Выложил его на стекоферфлоу - https://stackoverflow.com/questions/59251352/aggregate-and-sum-vector-sparse-by-cuid-in-spark-scala

Кому-нибудь  приходилось интегрироваться с коллекторами данных моц сетей, для обогащения профиля клиента например?

Кто сейчас этим занимается? Раньше вроде дабл дата была, а сейчас не понятно есть у них такая услуга

а сейчас берите и краулите, только не спалитесь, а то Усманов засудит)

Ну и их "дочка" https://dadata.ru/

Привет. Есть следующая проблема: читаю спарком из jdbc источника. Датасет относительно маленький (250к строк, ширина 200 полей) в паркетнике получается около 10 мб. При этом джоба работает очень долго ~ 2 часа. Попробовал ради интереса распараллелить через lower/upper Bound с numPartitions=10 и заметил интересную вещь - 9 из 10 паркет файлов имеют таймстемп через 15 минут после старта джобы, а последний, десятый, записывается только тогда, когда заканчивается полностью джоба, спустя два часа. В чем может быть причина такого поведения? Может быть, попробовать включить спекулятивное выполнение?

А у вас только чтение происходит? Никаких трансформаций, агрегаций и тд?

Только фильтрация (.filter()) и потом трансформация с помощью кастомной udf. Пробовал убирать трансформацию и делать .take(10).show() - результат такой же, медленный.

Также это может быть что ключ ваших баундов банально плохо распределен

Но последний партишен такой же по размеру получается (примерно), как и остальные 9. Это же было бы, наверное, заметно при неравномерном распределении?

@salatiques самый простой способ это глянуть чем занимаются потоки на воркерах в данный момент

сидят они на jdbc, на генерации паркета, или может у вас там ещё что весёлое есть

Чёрт! Отличный встречный вопрос на эти надоевшие задачки из учебников!