2017-11-25 178 views

回答

2

您可以檢查STL System Tables for Logging以發現查詢運行的時間。

您可能需要解析查詢文本以發現哪些表已加載,但是您可以使用歷史加載時間來計算每個表的典型加載時間。

一些特別有用的表格是:

  • STL_QUERY_METRICS:包含度量信息,如已完成在用戶運行處理的行的數量,CPU的使用率,輸入/輸出,和磁盤的使用,用於查詢定義的查詢隊列(服務類)。
  • STL_QUERY:返回有關數據庫查詢的執行信息。
  • STL_LOAD_COMMITS:該表記錄每個數據文件加載到數據庫表時的進度。
0

有一個聰明的方法來做到這一點。您應該有一個將數據從S3遷移到Redshift的ETL腳本。

假設你有一個shell腳本,剛捕獲的時間戳的ETL邏輯開始該表之前(我們稱之爲start),該表的ETL邏輯結束後拍攝另一時間戳(我們稱之爲end)和採取對劇本的結尾的區別:

#!bin/sh 
    . 
    . 
    . 

start=$(date +%s) #capture start time 

#ETL Logic 
     [find the right csv on S3] 
     [check for duplicates, whether the file has already been loaded etc] 
     [run your ETL logic, logging to make sure that file has been processes on s3] 
     [copy that table to Redshift, log again to make sure that table has been copied] 
     [error logging, trigger emails, SMS, slack alerts etc] 
     [ ... ] 


end=$(date +%s) #Capture end time 


duration=$((end-start)) #Difference (time taken by the script to execute) 

echo "duration is $duration" 

PS:持續時間將在幾秒鐘內就可以保持一個日誌文件,進入到一個數據庫表等的時間戳將在epoc,你可以使用功能(取決於你在哪裏登錄):

sec_to_time($duration) - 對於MySQL

SELECT (TIMESTAMP 'epoch' + 1511680982 * INTERVAL '1 Second ')AS mytimestamp - 適用於Amazon Redshift(然後採用epoch中兩個實例的區別)。

0

運行此查詢以瞭解COPY查詢的工作速度。

select q.starttime, s.query, substring(q.querytxt,1,120) as querytxt, 
     s.n_files, size_mb, s.time_seconds, 
     s.size_mb/decode(s.time_seconds,0,1,s.time_seconds) as mb_per_s 
from (select query, count(*) as n_files, 
    sum(transfer_size/(1024*1024)) as size_MB, (max(end_Time) - 
     min(start_Time))/(1000000) as time_seconds , max(end_time) as end_time 
     from stl_s3client where http_method = 'GET' and query > 0 
     and transfer_time > 0 group by query) as s 
LEFT JOIN stl_Query as q on q.query = s.query 
where s.end_Time >= dateadd(day, -7, current_Date) 
order by s.time_Seconds desc, size_mb desc, s.end_time desc 
limit 50; 

一旦你瞭解有多少MB/s的你從S3推動通過你可以大致判斷它需要多長時間按大小每個文件。

相關問題