K
и перелить данные
Size: a a a
2020 January 23
K
потом нужно мск репейр тейбл сделать
K
да сейчас так и делаю, каждую партицию читаю и лью же сразу. Но у меня партиций в таблице сотни, а таблиц штук 30
вообще, я никогда не использовал, но стоит еще наверное как работает mode ignore
DM
@krivdathetriewe не пробовал с ignore, но я думаю стоит посмотреть как он работает. Спасибо!
DM
@krivdathetriewe да по сути можно и каким нибудт distcp сделать это все, только вот я пробовал написать на scal'e, но в моем ноутбуке видимо нет пакета hadoop.tools
DM
@novikov_d_k Да я вроде и не извинялся, да и за что)
ДД
халява с обновлениями HDP закончилась?
E
🆗, да.
Как кто решает сейчас обновление HDP
или какие есть мысли по этому поводу?
Как кто решает сейчас обновление HDP
или какие есть мысли по этому поводу?
BK
А что за халява с обновлениями для HDP ? Они теперь платные ?
S
3.1.4 будет жить вечно
A
А что за халява с обновлениями для HDP ? Они теперь платные ?
сорцы все доступны в гите
бинари для кастомеров
бинари для кастомеров
BK
А понятно
AZ
🆗, да.
Как кто решает сейчас обновление HDP
или какие есть мысли по этому поводу?
Как кто решает сейчас обновление HDP
или какие есть мысли по этому поводу?
для клиентов ничего не изменилось, а остальным надо теперь собирать все самим
MK
Коллеги, добрый день! Помогите решить архитектурную проблему организации правильного надежного пайплайна.
Дано: есть один source данных и два sink'а (две разных таблицы в одном DWH) и работает это через staging.
При этом необходимо обеспечить, чтобы данные в таблицах разбегались как можно меньше, плюс максимально сократить число обращений к источнику.
Разумеется предполагается, что пайплайн может упасть на любой операции: чтение из источника в staging, переливка из staging'а в таблицу 1 или переливка из staging'а в таблицу 2. Например, в ситуации, когда в таблицу 1 данные успели перелиться, а в таблицу 2 – нет, данные разбегутся, но нужно каким-то образом уметь повторять переливку только в таблицу 2 ровно тех данных, что перелились в таблицу 1. При этом по умолчанию сейчас staging очищается перед стартом пайплайна.
У кого-то был опыт в решении подобной задачи? Как правильно это сделать? Меня интересуют не инструменты, а "принципиальная схема" решения.
Дано: есть один source данных и два sink'а (две разных таблицы в одном DWH) и работает это через staging.
При этом необходимо обеспечить, чтобы данные в таблицах разбегались как можно меньше, плюс максимально сократить число обращений к источнику.
Разумеется предполагается, что пайплайн может упасть на любой операции: чтение из источника в staging, переливка из staging'а в таблицу 1 или переливка из staging'а в таблицу 2. Например, в ситуации, когда в таблицу 1 данные успели перелиться, а в таблицу 2 – нет, данные разбегутся, но нужно каким-то образом уметь повторять переливку только в таблицу 2 ровно тех данных, что перелились в таблицу 1. При этом по умолчанию сейчас staging очищается перед стартом пайплайна.
У кого-то был опыт в решении подобной задачи? Как правильно это сделать? Меня интересуют не инструменты, а "принципиальная схема" решения.
DZ
Коллеги, добрый день! Помогите решить архитектурную проблему организации правильного надежного пайплайна.
Дано: есть один source данных и два sink'а (две разных таблицы в одном DWH) и работает это через staging.
При этом необходимо обеспечить, чтобы данные в таблицах разбегались как можно меньше, плюс максимально сократить число обращений к источнику.
Разумеется предполагается, что пайплайн может упасть на любой операции: чтение из источника в staging, переливка из staging'а в таблицу 1 или переливка из staging'а в таблицу 2. Например, в ситуации, когда в таблицу 1 данные успели перелиться, а в таблицу 2 – нет, данные разбегутся, но нужно каким-то образом уметь повторять переливку только в таблицу 2 ровно тех данных, что перелились в таблицу 1. При этом по умолчанию сейчас staging очищается перед стартом пайплайна.
У кого-то был опыт в решении подобной задачи? Как правильно это сделать? Меня интересуют не инструменты, а "принципиальная схема" решения.
Дано: есть один source данных и два sink'а (две разных таблицы в одном DWH) и работает это через staging.
При этом необходимо обеспечить, чтобы данные в таблицах разбегались как можно меньше, плюс максимально сократить число обращений к источнику.
Разумеется предполагается, что пайплайн может упасть на любой операции: чтение из источника в staging, переливка из staging'а в таблицу 1 или переливка из staging'а в таблицу 2. Например, в ситуации, когда в таблицу 1 данные успели перелиться, а в таблицу 2 – нет, данные разбегутся, но нужно каким-то образом уметь повторять переливку только в таблицу 2 ровно тех данных, что перелились в таблицу 1. При этом по умолчанию сейчас staging очищается перед стартом пайплайна.
У кого-то был опыт в решении подобной задачи? Как правильно это сделать? Меня интересуют не инструменты, а "принципиальная схема" решения.
Делать атомарную заливку?
AZ
Коллеги, добрый день! Помогите решить архитектурную проблему организации правильного надежного пайплайна.
Дано: есть один source данных и два sink'а (две разных таблицы в одном DWH) и работает это через staging.
При этом необходимо обеспечить, чтобы данные в таблицах разбегались как можно меньше, плюс максимально сократить число обращений к источнику.
Разумеется предполагается, что пайплайн может упасть на любой операции: чтение из источника в staging, переливка из staging'а в таблицу 1 или переливка из staging'а в таблицу 2. Например, в ситуации, когда в таблицу 1 данные успели перелиться, а в таблицу 2 – нет, данные разбегутся, но нужно каким-то образом уметь повторять переливку только в таблицу 2 ровно тех данных, что перелились в таблицу 1. При этом по умолчанию сейчас staging очищается перед стартом пайплайна.
У кого-то был опыт в решении подобной задачи? Как правильно это сделать? Меня интересуют не инструменты, а "принципиальная схема" решения.
Дано: есть один source данных и два sink'а (две разных таблицы в одном DWH) и работает это через staging.
При этом необходимо обеспечить, чтобы данные в таблицах разбегались как можно меньше, плюс максимально сократить число обращений к источнику.
Разумеется предполагается, что пайплайн может упасть на любой операции: чтение из источника в staging, переливка из staging'а в таблицу 1 или переливка из staging'а в таблицу 2. Например, в ситуации, когда в таблицу 1 данные успели перелиться, а в таблицу 2 – нет, данные разбегутся, но нужно каким-то образом уметь повторять переливку только в таблицу 2 ровно тех данных, что перелились в таблицу 1. При этом по умолчанию сейчас staging очищается перед стартом пайплайна.
У кого-то был опыт в решении подобной задачи? Как правильно это сделать? Меня интересуют не инструменты, а "принципиальная схема" решения.
обычный ETL пайплайн решает эту задачу, у вас на предпоследнем этапе готовы дельты в формате целевых таблиц, их заливка должна быть идемпотентной
DZ
Но в случае идемпотентой может быть момент когда часть залилась
DZ
И как раз то что описано
AZ
(обычный ETL пайплайн это 1) лэндинг 2) генерация суррогатников и потеряшек 3) преобразование в целевую модель 4) определение истории 5) заливка в цель)
OA
(обычный ETL пайплайн это 1) лэндинг 2) генерация суррогатников и потеряшек 3) преобразование в целевую модель 4) определение истории 5) заливка в цель)
Где дата кволити?