Или как понять, что ваши данные кому-то нужны
Есть два героя: Миша (продуктовый аналитик) и Артем (дата инженер). С ними случилась такая история:
🙂 привет, Миша! ты три года назад создавал таблицу user_orders_check_agg_m, она занимает 100тб, последний раз использовалась в прошлом году. она еще нужна, можно удалить?
🦔 привет! можно, мы ее готовили для экспериментов, но их отменили
Кластер задышал, ведь с репликацией это целых 300тб свободного места
Через неделю Миша приходит:
🦔 Артем, помнишь, мы обсуждали табличку user_orders_check_agg_m? у нас снова запускается эксперимент, нам срочно нужно ее восстановить!!!
😳 ......
Артем находит цепочку зависимостей:
user_orders_check_agg_m ->
user_orders_check_agg ->
user_orders_check ->
user_orders_abc, user_orders_def ->
user_orders
Причем все промежуточные таблицы уже удалены
Артем поднимает старые скрипты, адаптирует их под новую версию спарка, переписывает под новую схему данных, пересоздает таблички, тестирует, ставит на расчет. Через месяц все готово
Но команда не успела зарелизить запланированные фичи. Все клиенты ушли к конкурентам
Какие есть варианты, чтобы помочь Артему и команде меньше нервничать в следующий раз?
1️⃣Переименовать табличку - сразу найдем среди сотен процессов те, которым она нужна
ALTER TABLE exp.user_orders_check_agg_m RENAME TO exp.user_orders_check_agg_m_trash;
2️⃣Переместить в .Trash - когда мы удаляем руками из hdfs, они перемещаются в папку .Trash. Там они хранятся столько, сколько задано в fs.trash.interval при настройке кластера. Поэтому будет какое-то время прийти за ними
hdfs dfs -rm -r user_orders_check_agg_m_data
INFO fs.TrashPolicyDefault: Moved: 'hdfs://data/user_orders_check_agg_m_data' to trash at: hdfs://data/.Trash/Current/user/admin/user_orders_check_agg_m_data
3️⃣Переместить в другую папку для мусора и периодически подчищать ее
hdfs dfs -mv user_orders_check_agg_m_data some_trash_folder
Есть еще другие варианты? Или это проблема Миши, что он разрешил дропнуть таблицу? 😁