AWS Data Analytics Quiz – Redshift

A) Correct,
https://docs.aws.amazon.com/redshift/latest/dg/federated-overview.html)

B) Incorrect – Glue can make data from S3, RDS (JDBC), DynamoDB accessible to Redshift Spectrum (via external tables),https://docs.aws.amazon.com/redshift/latest/dg/c-spectrum-external-tables.ht
but there are numerous additional configuration steps (and costs) compared to option A)

C)Incorrect – DBlink allows query interworking between Redshift and Amazon RDS (Aurora, PostgreSQL) not S3
D) Incorrect – There is no need to load the data into Redshift to accomplish the ability to query across all three data sources, and DMS is not applicable to S3.

We’re scaling for READ, not write, so both Elastic and Classic resize which will scale both READ & WRITE capacity are unnecessary

A) Incorrect -We’re scaling for READ, not write but Elastic will scale both READ & WRITE capacity and there will be some service interruption.
B) Correct -“With the Concurrency Scaling feature, you can support virtually unlimited concurrent users and concurrent queries, with consistently fast query performance. When concurrency scaling is enabled, Amazon Redshift automatically adds additional cluster capacity when you need it to process an increase in concurrent read queries. Write operations continue as normal on your main clusterhttps://docs.aws.amazon.com/redshift/latest/dg/concurrency-scaling.html

C) Incorrect – Classic resize would be for scaling to meet an ongoing increase and read and write capacity need. Whilst the snapshot approach reduces down-time, the new cluster won’t be available for hours – days.

D) Correct – “With Amazon Redshift, you can already scale quickly in three ways. First, you can query data in your Amazon S3 data lakes in place using Amazon Redshift Spectrum, without needing to load it into the cluster. This flexibility lets you analyze growing data volumes without waiting for extract, transform, and load (ETL) jobs or adding more storage capacity” –https://aws.amazon.com/blogs/big-data/scale-your-amazon-redshift-clusters-up-and-down-in-minutes-to-get-the-performance-you-need-when-you-need-it/

https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-use-copy.html

A) Incorrect – “When you load all the data from a single large file, Amazon Redshift is forced to perform a serialized load, which is much slower. Split your load data files so that the files are about equal size, between 1 MB and 1 GB after compression. For optimum parallelism, the ideal size is between 1 MB and 125 MB after compression. The number of files should be a multiple of the number of slices in your cluster.”
B) Correct –
C) Incorrect – “Use a single COPY command to load data in parallel from S3, EMR, DynamoDB…”
D) Correct

A) Incorrect – https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html
B) Correct – see the above link
C) Incorrect – only STRING and NUMBER data types are supported
D) Correct – see the above link

https://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html

A) Incorrect – AUTO may select the correct distribution style, but it’s not guaranteed to select ‘KEY’
B) Incorrect – EVEN ” distribution is appropriate when a table does not participate in joins or when there is not a clear choice between KEY distribution and ALL distribution.”
C) Correct – KEY
D) Incorrect – ALL “ALL distribution multiplies the storage required by the number of nodes in the cluster, and so it takes much longer to load, update, or insert data into multiple tables. ALL distribution is appropriate only for relatively slow moving tables; that is, tables that are not updated frequently or extensively.”

https://docs.aws.amazon.com/redshift/latest/dg/t_updating-inserting-using-staging-tables-.html

“While Amazon Redshift does not support a single merge, or upsert, command to update a table from a single data source, you can perform a merge operation by creating a staging table and then using one of the methods described “

A) Correct
B) Incorrect
C) Correct
D) Incorrect