Ich benutze eine ds2.xlarge Redshift-Cluster in US West mit etwa 1 TB Daten. Ich versuche, eine 50GB-Tabelle auf einen S3 Eimer in der gleichen Region auszuladen wie folgt:Redshift entladen zu S3 ist extrem langsam
UNLOAD ('select * from table_name') TO 's3://bucket/folder_name/'
CREDENTIALS 'aws_access_key_id=foo;aws_secret_access_key=bar'
MANIFEST;
Diese Abfrage dauert ca. 1 Stunde zu laufen. Dies erscheint überraschend, da auf der Amazon-Website angegeben wird, dass wir für unseren Cluster eine E/A von 0,5 GB/s haben, was bedeutet, dass die 50 GB-Tabelle weniger als 2 Minuten benötigt, um in S3 hochgeladen zu werden, keine Stunde. (20-30x mal langsamer als angekündigt)
Hat jemand anderes in dieses Problem hineingelaufen und/oder einen Fix/Workaround gefunden? Wenn wir uns dazu entschließen, Redshift zu verwenden, müssen wir täglich etwa 200 GB Daten von Redshift nach S3 verschieben.
Haben Sie nur einen einzigen Knoten im Cluster? Wie viele Zeilen und Spalten befinden sich in der Tabelle? Wenn du eine kleinere Menge machst (zB 'select * from table_name limit 10000') endet es schneller? Nur aus Interesse, wo ist die Erwähnung von 0,5 GB/s für den Cluster? –
Die I/O wird hier erwähnt: https://aws.amazon.com/blogs/aws/amazon-redshift-now-faster-and-more-cost-effective-than-ever/ Ich glaube, die Tabelle hat etwa 80M Zeilen und 10-20 Spalten. Es ist viel schneller mit dem Limit – sparknoob
Ich vermute, dass die E/A-Spalte ist die Geschwindigkeit, die die Datenbank auf den Plattenspeicher zugreifen kann, nicht unbedingt die Geschwindigkeit des Exports zu Amazon S3. Die Tatsache, dass der Export mit weniger Zeilen schneller abgeschlossen wird, zeigt an, dass er mit dem Datenvolumen zusammenhängt. Sie könnten versuchen, Workload Management (WLM) zu verwenden, um dem Prozess Slots (und damit mehr Arbeitsspeicher) zu gewähren. Siehe: ['wlm_query_slot_count'] (http://docs.aws.amazon.com/redshift/latest/dg/r_wlm_query_slot_count.html) –