В чем причина задержки запроса данных в Bigquery при разделении во время приема?

Question

Я использовал bigquery для пакетирования insert данных из моего python приложения. Столы были partitioned во время приема пищи. Разница, которую я увидел, заключалась в том, что введенные мной данные появятся в течение query через 1,5 часа после приема.

Позже я изменил schema на столбец timestamp

На этот раз я мог query данные сразу после приема.

Почему существует разница в поведение между _PARTITIONTIME псевдостолбцом и timestamp столбцом в таблице schema?

PYTHON КОД ДЛЯ ПОЛУЧЕНИЯ:

Это упрощенная версия кода:

bigquery_client = bigquery.Client()
TABLE_REF = bigquery_client.dataset('DATASET_ID').table('TABLE_ID')
TABLE = bigquery_client.get_table(TABLE_REF)

def ingest_to_bq(data: LIST[LIST]):
    bigquery_client.insert_rows(TABLE, data)

Схема таблицы:

[
    {
        "name": "epoch_ms",
        "type": "INTEGER",
        "mode": "REQUIRED"
    },
    {
        "name": "application_id",
        "type": "STRING",
        "mode": "REQUIRED"
    },
    {
        "name": "ack_id",
        "type": "STRING",
        "mode": "REQUIRED"
    },
    {
        "name": "data",
        "type": "STRING",
        "mode": "REQUIRED"
    }
]

Создана таблица из интерфейса BIGQUERY и распределена во время приема.

Запрос:

Я запрашиваю снова, используя интерфейс BIGQUERY.

SELECT data from <DATASET_ID>.<TABLE_ID> WHERE _PARTITIONTIME="2020-03-30"

Приведенный выше запрос не отображает результаты, полученные, скажем, полчаса назад. Для получения результатов требуется примерно 1,5 часа после приема.

НОВАЯ СХЕМА:

[
    {
        "name": "send_timestamp",
        "type": "TIMESTAMP",
        "mode": "REQUIRED"
    },
    {
        "name": "application_id",
        "type": "STRING",
        "mode": "REQUIRED"
    },
    {
        "name": "ack_id",
        "type": "STRING",
        "mode": "REQUIRED"
    },
    {
        "name": "data",
        "type": "STRING",
        "mode": "REQUIRED"
    }
]

ЗАПРОС НА НОВУЮ СХЕМУ:

SELECT data from <DATASET_ID>.<TABLE_ID> WHERE send_timestamp>="2020-03-30 00:00:00" and send_timestamp<="2020-03-30 23:59:59"

Этот запрос возвращает результат сразу после приема. Мне не нужно ждать.

Answer 1

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

Объяснение этой задержки - BigQuery потоковый буфер . Потоковый буфер - это буфер, который сохраняет недавно вставленные строки и оптимизирован для записи пропускной способности. Другими словами, когда вы вставляете потоковые данные в BigQuery, ваши данные сначала вставляются в потоковый буфер, где они хранятся до 90 минут. На этом этапе данные считаются надежными, и вы можете запрашивать их, однако вам не разрешается выполнять над ними определенные операции c.

Как вы можете видеть в документации , когда ваши данные находятся в потоковом буфере , псевдостолбец _PARTITIONTIME будет NULL. Учитывая это, ваш запрос не может найти новые вставленные строки, потому что ваш _PARTITIONTIME равен NULL. Чтобы убедиться, что в вашем псевдостолбце для недавно вставленных данных установлены значения NULL, вы можете выполнить следующие запросы:

1. Если вы хотите увидеть псевдостолбец для всех строки, запустите SELECT *, _PARTITIONTIME p from <DATASET_ID>.<TABLE_ID>

2. Если вы хотите получить все строки, в которых псевдостолбец равен нулю, запустите SELECT * from <DATASET_ID>.<TABLE_ID> WHERE _PARTITIONTIME is null

Наконец, я хотел бы добавить несколько полезных ссылок для этой топической c.

1. ссылки BigQuery таблицы .
2. потока BigQuery ссылки .
3. Официальная статья о потоковой передаче в BigQuery, в которой обсуждается буфер потоковой передачи и как с ним обращаться.

Надеюсь, это поможет