2015-08-31 2 views
1

Я запускаю запрос из командной строки для хранения в новой таблице. В этом запросе у меня есть несколько подзапросов, каждый из которых обращается к нескольким таблицам с TABLE_DATE_RANGE.Командная строка BQ: слишком большой запрос

Для каждого заглушки для стола есть один стол в день. Итак, есть 4 подзапроса, каждый из которых имеет 180 таблиц (90 дней в двух запросах TABLE_DATE_RANGE). Это составляет 720 таблиц. Поэтому я не должен превышать предельный предел 1k.

Я превысил предел таблицы 1k раньше и получил сообщение об ошибке «слишком много таблиц» или тому подобное.

Этот запрос, однако, дает мне ошибку «Query too large». Как вы можете видеть ниже, я допускаю большие результаты. Кто-нибудь знает решение этого?

bq query -n0 --allow_large_results --replace --destination_table="cdate-prod:crm_adhoc.tmp_email_details_event_date" 'select event_date 
,contact_id 
,message_name 
,message_name_join 
,message_id 
,email 
,REGEXP_EXTRACT(email,r'([^@]*$)') as email_domain 
,REGEXP_EXTRACT(REGEXP_EXTRACT(email,r'([^@]*$)'),r'(^[^\.]*)') as email_provider 
,sent 
,sent_unique_hlp 
,open 
,open_unique_hlp 
,open_unique_msg_hlp 
,click 
,click_unique_hlp 
,click_unique_msg_hlp 
,soft_bounce 
,medium_bounce 
,hard_bounce 
,activity 
,type 
,case when type = 1 then 'PPM' 
     when type = 2 then 'NPM' 
     when type = 3 then 'PENDING' 
     when type = 4 then 'CB' 
     when type = 5 then 'REDEBIT' 
     when type = 6 then 'INTCO' 
     when type = 7 then 'EXTCO' 
     else 'XX' 
end as type_str 
from 

(select send_date as event_date 
,contact_id 
,message_name 
,substr(message_name,7) as message_name_join 
,message_id 
,email 
, 1 as sent 
, contact_id as sent_unique_hlp 
, 0 as open 
, string('') as open_unique_hlp 
, string('') as open_unique_msg_hlp 
, 0 as click 
, string('') as click_unique_hlp 
, string('') as click_unique_msg_hlp 
, 0 as soft_bounce 
, 0 as medium_bounce 
, 0 as hard_bounce 
, IFNULL(activity,0) as activity 
, IFNULL(type,0) as type 
from TABLE_DATE_RANGE(crm_data.campaign_messages,date_add(CURRENT_DATE(),-90,"day"),date_add(CURRENT_DATE(),-1,"day")), 
    TABLE_DATE_RANGE(crm_data.interface_messages,date_add(CURRENT_DATE(),-90,"day"),date_add(CURRENT_DATE(),-1,"day"))) ms, 

(select open_date as event_date 
,contact_id 
,message_name 
,substr(message_name,7) as message_name_join 
,message_id 
,email 
, 0 as sent 
, string('')as sent_unique_hlp 
, 1 as open 
, contact_id as open_unique_hlp 
, concat(contact_id,string(TIMESTAMP_TO_MSEC(send_date))) open_unique_msg_hlp 
, 0 as click 
, string('') as click_unique_hlp 
, string('') as click_unique_msg_hlp 
, 0 as soft_bounce 
, 0 as medium_bounce 
, 0 as hard_bounce 
, IFNULL(activity,0) as activity 
, IFNULL(type,0) as type 
from TABLE_DATE_RANGE(crm_data.interface_openings,date_add(CURRENT_DATE(),-90,"day"),date_add(CURRENT_DATE(),-1,"day")), 
    TABLE_DATE_RANGE(crm_data.campaign_openings,date_add(CURRENT_DATE(),-90,"day"),date_add(CURRENT_DATE(),-1,"day"))) op, 

(select click_date as event_date 
,contact_id 
,message_name 
,substr(message_name,7) as message_name_join 
,message_id 
,email 
, 0 as sent 
, string('')as sent_unique_hlp 
, 0 as open 
, string('') as open_unique_hlp 
, string('') as open_unique_msg_hlp 
, 1 as click 
, contact_id as click_unique_hlp 
, concat(contact_id,string(TIMESTAMP_TO_MSEC(send_date))) click_unique_msg_hlp 
, 0 as soft_bounce 
, 0 as medium_bounce 
, 0 as hard_bounce 
, IFNULL(activity,0) as activity 
, IFNULL(type,0) as type 
from TABLE_DATE_RANGE(crm_data.interface_clicks,date_add(CURRENT_DATE(),-90,"day"),date_add(CURRENT_DATE(),-1,"day")), 
    TABLE_DATE_RANGE(crm_data.campaign_clicks,date_add(CURRENT_DATE(),-90,"day"),date_add(CURRENT_DATE(),-1,"day"))) cl, 

(select bounce_date as event_date 
,contact_id 
,message_name 
,substr(message_name,7) as message_name_join 
,message_id 
,email 
, 0 as sent 
, string('')as sent_unique_hlp 
, 0 as open 
, string('') as open_unique_hlp 
, string('') as open_unique_msg_hlp 
, 0 as click 
, string('') as click_unique_hlp 
, string('') as click_unique_msg_hlp 
,case when bounce_category = 1 then 1 end soft_bounce 
,case when bounce_category = 2 then 1 end medium_bounce 
,case when bounce_category in (3,4,5) then 1 end hard_bounce 
, IFNULL(activity,0) as activity 
, IFNULL(type,0) as type 
from TABLE_DATE_RANGE(crm_data.interface_bounces,date_add(CURRENT_DATE(),-90,"day"),date_add(CURRENT_DATE(),-1,"day")), 
    TABLE_DATE_RANGE(crm_data.campaign_bounces,date_add(CURRENT_DATE(),-90,"day"),date_add(CURRENT_DATE(),-1,"day"))) bo' 

Waiting on bqjob_r71fbdcc95fa950e5_0000014f82f52d18_1 ... (0s) Current status: RUNNING 
Waiting on bqjob_r71fbdcc95fa950e5_0000014f82f52d18_1 ... (1s) Current status: RUNNING 
Waiting on bqjob_r71fbdcc95fa950e5_0000014f82f52d18_1 ... (1s) Current status: DONE 
Error in query string: Error processing job 
'cdate-prod:bqjob_r71fbdcc95fa950e5_0000014f82f52d18_1': Query too large 

ответ

2

Моя догадка, от того, что я знаю:

  • Запрос может быть только до х символов. Представленный здесь запрос короче этого, но ...

  • TABLE_DATE_RANGE работает путем внутреннего расширения запроса, чтобы содержать явно все имена таблиц в пределах диапазона. Обычно это нормально, но ...

  • Этот запрос относится к 720 таблицам. Запрос будет расширен, явно указывая длину 720 * (имя_таблицы). Это подталкивает его к пределу.

Предложение: Могли бы вы объединить старые таблицы в ежемесячные сущности вместо ежедневных?

+0

Я вижу вашу точку зрения. Я могу сначала разбить подзапросы, а затем добавить их в таблицу. Благодарю. –

+1

Похоже, что расширение предложения TABLE_DATE_RANGE привело к тому, что текст запроса стал слишком большим, как вы предполагали. Я разделил один запрос на 4. Первый запрос запускается с флагом '--replace', а остальные три - с флагом' --append'. –

+3

Felipe правильно, что все эти ограничения существуют, но тот, который вы нажимаете, на самом деле является внутренним пределом RPC при передаче данных, содержащихся в этих таблицах. Обходной путь тот же, но, надеюсь, мы сможем справиться с этим делом в будущем с некоторыми изменениями на стороне BQ. –

Смежные вопросы