While proper splitting of files is very important and highly recommended, it shouldn't cause a CPU spike across the cluster.
What is usually the cause of a CPU spike like what you're describing is if you are loading into a table without any compression settings. The default setting for COPY is that COMPUPDATE is ON. What happens is that Redshift will take the incoming rows, run them through every compression setting we have and return the the appropriate (smallest) compression.
To fix the issue, it's best to make sure that compression is applied to the target table of the COPY statement. Run Analyze Compression command if necessary to figure out what the compression should be and manually apply it to the DDL. For temporary tables LZO can be an excellent choice to choose because it's faster to encode on these transient tables than say ZSTD. Just to be sure also set COMPUPDATE OFF in the COPY statement.
Redshift nodes: 14 x dc2.large vs 4 x ra3.xlplus - COPY performance dropasked a year ago
s3 parquet partitions load to redshift using COPY commandasked 5 months ago
What are the best practices to speed up VACUUM command in Redshift after significant data updates?Accepted Answerasked 2 years ago
Redshift ran out of storage during data CopyAccepted AnswerEXPERTasked 2 years ago
Redshift questions from AWS CustomerAccepted Answerasked 4 years ago
Redshift COPY command CPU spikesAccepted Answerasked 5 years ago
Redshift Insert into s3 file data into existing tableasked 8 months ago
How to use psycopg2 to load data into Redshift tables with the copy commandasked 7 months ago
Redshift COPY commend takes the wrong file from S3asked 6 months ago
Redshift COPY command feature requestasked 10 months ago