BigQuery становится все более популярным инструментом для работы с данными. С ростом его распространенности все более ценными становятся и знания о нем. При этом в повседневной практике могут возникать совершенно разные ситуаций, от которых невозможно перестраховаться на 100%. Можно в частности случайно повредить, неверно дозаполнить, а может быть и вовсе уничтожить не те партиции или целую таблицу. В этой заметке мы рассмотрим способы, с помощью которых можно исправить допущенные недоразумения.

Все будет хорошо
Все будет хорошо

Если вы накосячили с данными, то первое о чем нужно помнить, это:

  1. Если вы повредили таблицу. BigQuery хранит состояние вашей существующей таблицы на любой момент времени в течение прошедших 7 дней. Так что вы можете откатиться.

  2. Если вы удалили таблицу. У вас есть 2 суток, чтобы восстановить уничтоженную таблицу с помощью специальной команды.

Можно обратиться и к официальной справке по этому вопросу, а именно к разделу "BigQuery for data warehouse practitioners" >> "Backup and recovery" - ссылка.


После осознания того, что все не так плохо, у вас есть 2 способа восстановить ваши данные: с помощью SQL запроса и с помощью специальной команды в консоли.

Ситуация 1. Таблица была повреждена неуместной операцией

Если вы не удалили таблицу, а лишь повредили ее, применив ненужную операцию, то можно восстановить ее состояние на любой момент времени в течение последних 7 дней, как мы и писали ранее. Для этого нужно всего лишь написать довольно простой SQL запрос.

Пример для случая, когда вы уверены, что еще 1 час назад таблица была “нормальной”.

CREATE OR REPLACE TABLE
  `имя_проекта.имя_датасета.имя_таблицы`
AS


SELECT
    *
FROM
  `имя_проекта.имя_датасета.имя_таблицы`
FOR SYSTEM_TIME AS OF
TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)

Вместо  `INTERVAL 1 HOUR` конечно можно написать любое число часов в пределах 168 или, например, `INTERVAL 1 DAY` , если ваши повреждения замечены поздно. Можно также и не восстанавливать таблицу сразу, а посмотреть на результат выдачи, само собой не используя первую часть запроса `CREATE OR REPLACE`.

Ситуация 2. Партицированная таблица была повреждена неуместной операцией

Если вам нужно восстановить состояние партицированной таблицы, где обязательным условием является указание некоего значения колонки, по которой таблица партицирована, то и с таким кейсом можно справиться. В этом случае вам нужно написать запрос вот такого вида:

CREATE OR REPLACE TABLE
    `имя_проекта.имя_датасета.имя_таблицы`
PARTITION BY
    event_date
OPTIONS (require_partition_filter=TRUE) AS


SELECT
    *
FROM
    `имя_проекта.имя_датасета.имя_таблицы`
FOR SYSTEM_TIME AS OF
TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
WHERE
    event_date <= CURRENT_DATE()

Ситуация 3. Таблица была случайно удалена

Помните, что у вас есть 2 суток, чтобы исправить эту ситуацию. Чтобы восстановить удаленную таблицу, нужно открыть консоль, нажав ‘Activate Cloud Shell’ в правом верхнем углу, как это показано на картинке ниже.

Activate Cloud Shell
Activate Cloud Shell

После этого в нижней части экрана откроется консоль, где можно будет писать команды для восстановления таблиц. При возврате удаленной таблицы, нужно указать момент, когда эта таблица существовала, но в микросекундах. Также у вас есть выбор: или просто восстановить таблицу или сохранить ее в какую-то новую без восстановления старой. Например, можно потренироваться сохраняя ее в виде тестовой, прежде чем точно правильно восстановить старую на ее прежнем месте.

При простом восстановлении ваша команда в консоли будет выглядеть примерно так:

bq cp имя_датасета.имя_таблицы@1665946435000 имя_датасета.имя_таблицы

где цифры 1665946435000 будут обозначать ваш момент времени в соответствии с Unix Timestamp.

Если вы хотите сохранить старую восстановленную таблицу под новым именем, то ваша команда будет выглядеть как:

bq cp имя_датасета.имя_таблицы@1665946435000 имя_датасета.имя_новой_таблицы

где цифры 1665946435000 будут обозначать ваш момент времени в соответствии с Unix Timestamp.

После ввода этой команды у вас появится строка, где нужно нажать ‘y’, что означает что вы подтверждаете операцию.

Вот пример того, как это может выглядеть в вашей консоли:

Запуск и ответ на команду в нашей консоли
Запуск и ответ на команду в нашей консоли

Вот и все, ваша удаленная таблица успешно восстановлена.


Подводя итог, хочется сказать, что удаление или повреждение вашей таблицы не такая критичная проблема, если вы успели уложиться в 7 дней для таблицы, которую повредили, и в 2 дня для таблицы, которую по ошибке удалили. Все эти команды выручали нас не один раз. Надеюсь, что они помогут и вам восстановить все без потерь.

Комментарии (11)


  1. itallix
    17.10.2022 02:21
    +2

    В конце апреля в превью выкатили фичу configure time travel window.


    1. olga_rogova Автор
      19.10.2022 02:09

      выглядит интересно, спасибо


  1. mentin
    17.10.2022 08:40
    +1

    Я бы добавил что в Cloud Shell приходится лезть если нет локально установленного Google Cloud SDK. Если есть, то же можно в своей консоли сделать.


  1. datacompboy
    17.10.2022 10:55

    Запуск и ответ на команду в нашей консол

    там на скриншоте merge-inn старательно не затерто в одном месте :)

    И ID после bqjob_... лучше тоже затереть, чтобы номер проекта не светить.


    1. olga_rogova Автор
      19.10.2022 02:11

      благодарю за замечание )


  1. Akina
    17.10.2022 12:50

    Если вы не удалили таблицу, а лишь повредили ее, применив ненужную операцию

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

    Во-вторых, факт повреждения может быть выявлен не сразу, и в повреждённую таблицу уже могут лечь какие-то новые данные (и/или изменены существующие). Кстати, вы несколько раз акцентируетесь на том, что на исправление есть неделя - то есть корректировка данных более вероятна, чем отсутствие корректировки. Простой откат в прошлое благополучно "грохнет" все эти изменения. Понимаю, что в этом случае никакого простого и в то же время общего решения, пожалуй, нет, но о возможности такой проблемы есть смысл хотя бы сказать.


    1. datacompboy
      17.10.2022 13:19

      1) В BigQuery как таковую структуру сломать сложно. Худший вариант -- создать новую таблицу на месте старой с совершенно другой схемой. Вариант "bq cp" восстановит в оригинальной форме (я помню раньше была проблема, но она решена вроде была)

      2) Как и с любым бакапом. Если что-то сломали, откат к бакапу теряет всё что было внесено с момента бакапа.

      Особенно функция все же полезна для аналитики -- когда итеративно обрезаешь большие объёмы и внезапно КАААК "ой, а я вот тут шага 3 назад сделал оч оч не правильно". Бакапы в таких случаях редко когда хранишь. Но есть time travel в BigQuery :)


  1. Akina
    17.10.2022 20:23

    В BigQuery как таковую структуру сломать сложно. 

    Ну если учесть, что в BigQuery есть ALTER TABLE, то процитированное утверждение более чем сомнительно. Удаление не того поля или ошибочное изменение типа - да как два пальца.


    1. datacompboy
      17.10.2022 21:50

      https://cloud.google.com/bigquery/docs/managing-table-schemas#change_a_columns_data_type

      Удаления поля нет.

      Изменить тип можно только на приводимый.


      1. Akina
        17.10.2022 21:54
        +1

        1. datacompboy
          18.10.2022 00:22

          О, таки появилось, буду знать, спасибо :)

          Но, таки путешествие во времени все равно вариант.