Каков эффективный способ экспорта данных из дескрипторов oop в Oracle, с минимальным временем простоя? - PullRequest
Новая
       4

Каков эффективный способ экспорта данных из дескрипторов oop в Oracle, с минимальным временем простоя?

0 голосов
/ 15 марта 2020

У меня есть это бизнес-требование, когда нам нужно экспортировать данные sq oop из Had oop в Oracle, поскольку sq oop неэффективно обрабатывает удаления, которые мы экспортируем в режиме перезаписи. Чтобы поддерживать минимальное время простоя, мы разработали процесс (записанный как хранимая процедура), который выполняет следующие шаги в следующем порядке:

Создано STG_TABLES (в качестве промежуточных таблиц) И FINAL_TABLES.

После того, как sq oop экспортированные данные в stg_tables.

  1. Хранимая процедура переименовывает final_tables (предположим, у нас есть данные в final_tables из предыдущего запуска) в temp_tables

  2. Хранимая процедура переименовывает stg_tables в final_tables

  3. Хранимая процедура переименовывает temp_tables в stg_tables и усекает (подготавливает их для следующего fre sh экспорт).

Есть ли у вас какие-либо лучшие идеи / предложения по улучшению вышеуказанного процесса?

Пожалуйста, предложите.

Спасибо!

1 Ответ

2 голосов
/ 15 марта 2020

Определите таблицу FINAL, как требуется, и добавьте один технический столбец load_date od DATE type.

Пример: 

create table FINAL_TABLES  
(load_date DATE,
col1 varchar2(10));

Определите таблицу STG с помощью та же структура, но с использованием interval partitioning 

create table STG_TABLES  
(load_date DATE,
col1 varchar2(10))
   PARTITION BY RANGE (load_date)
   INTERVAL(NUMTODSINTERVAL(1, 'DAY'))
( 
  PARTITION p_init VALUES LESS THAN (TO_DATE('15-03-2020', 'DD-MM-YYYY'))
);

Теперь выполните sqoop загрузку данных в таблицу STG. load_date - это отметка времени нагрузки, равное значение во всех строках .

Пример, имитирующий с insert

insert into STG_TABLES (load_date, col1)
values (sysdate,'new load');
commit;

На следующем шаге поменяйте местами содержимое таблиц STG и FINAL с использованием exchange partition

alter table STG_TABLES
exchange partition FOR (to_date('2020-03-15 05:55:00','yyyy-mm-dd hh24:mi:ss'))
with table FINAL_TABLES
without validation;

Раздел таблицы STG идентифицируется текущим значением load_date

Теперь загружен данные находятся в таблице FILNAL, а таблица STG содержит прежнее состояние, если таблица FINAL.

Вы можете избавиться от нее, отбросив раздел, что должно быть сделано непосредственно перед тем, как следующая загрузка. Последний вариант может помочь при устранении неполадок. 

alter table STG_TABLES
drop partition FOR (to_date('2020-03-15 05:55:00','yyyy-mm-dd hh24:mi:ss'));

Заключительные замечания

  1. Производительность этих шагов сопоставима с вашим решением с таблицей переименования (только данные словарь деятельности). Для потребителя таблицы FINAL эта опция намного лучше, поскольку таблица постоянно существует, поэтому запросы не аннулируются с помощью RENAME.

    Если вы отложите DROP PARTITION до следующей загрузки, даже длительные запросы во время загрузки сохранятся и будут продолжены в сегментах таблицы STG.

  2. Если в таблице FINAL есть индексы, определите такую ​​же структуру индексов для STG, как и для LOCAL индексов.

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

    Добавьте INCLUDING INDEXES к оператору раздела exchange.

  3. Вышеописанная схема определяет full refre sh load , т.е. старое состояние полностью перезаписывается новое состояние. Вы можете использовать тот же механизм для дельта-нагрузки , т.е. новая загрузка добавлена ​​ в текущем состоянии.

    Простое определение таблицы STG без разбиения на разделы и таблица FINAL как секционированная.

Приведенный выше пример будет работать для дельта-загрузки один раз в день - настройте схему INTERVAL для разных частот.

...