기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 자습서: cqlsh를 사용하여 Amazon Keyspaces에 데이터 로드
이 자습서는 `cqlsh COPY FROM` 명령을 사용하여 Apache Cassandra에서 Amazon Keyspaces로 데이터를 마이그레이션하는 프로세스를 안내합니다. 이 `cqlsh COPY FROM` 명령은 학술 또는 테스트 목적으로 Amazon Keyspaces에 작은 데이터세트를 빠르고 쉽게 업로드하는 데 유용합니다. 프로덕션 워크로드를 마이그레이션하는 방법에 대한 자세한 내용은 [오프라인 마이그레이션 프로세스: Apache Cassandra에서 Amazon Keyspaces로](migrating-offline.md) 섹션을 참조하세요. 이 자습서에서는 다음 단계를 완료합니다.
사전 조건 - 자격 증명으로 AWS 계정을 설정하고, 인증서에 대한 JKS 트러스트 스토어 파일을 생성하고, Amazon Keyspaces에 연결`cqlsh`하도록를 구성합니다.
1. **소스 CSV 및 대상 테이블 생성** - 소스 데이터로 CSV 파일을 준비하고 Amazon Keyspaces에서 대상 키스페이스 및 테이블을 생성합니다.
1. **데이터 준비** - CSV 파일에서 데이터를 무작위 배정하고 분석하여 평균 및 최대 행 크기를 결정합니다.
1. **처리량 용량 설정** - 데이터 크기 및 원하는 로드 시간을 기준으로 필요한 쓰기 용량 단위(WCU)를 계산하고 테이블의 프로비저닝된 용량을 구성합니다.
1. **cqlsh 파라미터 구성** - 워크로드를 균등하게 분산하기 위해 `INGESTRATE`, `NUMPROCESSES`, `MAXBATCHSIZE`, `CHUNKSIZE`와 같은 `cqlsh COPY FROM` 파라미터의 최적 값을 결정합니다.
1. **`cqlsh COPY FROM` 명령 실행 ** - `cqlsh COPY FROM` 명령을 실행하여 CSV 파일의 데이터를 Amazon Keyspaces 테이블에 업로드하고 진행 상황을 모니터링합니다.
문제 해결 - 데이터 업로드 프로세스 중에 잘못된 요청, 구문 분석기 오류, 용량 오류 및 cqlsh 오류와 같은 일반적인 문제를 해결합니다.
**Topics**
+ [사전 조건: `cqlsh COPY FROM`을 사용하여 데이터를 업로드하기 전에 완료해야 하는 단계](bulk-upload-prequs.md)
+ [1단계: 데이터 업로드를 위해 소스 CSV 파일 및 대상 테이블 생성](bulk-upload-source.md)
+ [2단계: 성공적인 데이터 업로드를 위해 소스 데이터 준비](bulk-upload-prepare-data.md)
+ [3단계: 테이블의 처리량 용량 설정](bulk-upload-capacity.md)
+ [4단계: `cqlsh COPY FROM` 설정 구성](bulk-upload-config.md)
+ [5단계: `cqlsh COPY FROM` 명령을 실행하여 CSV 파일의 데이터를 대상 테이블에 업로드](bulk-upload-run.md)
+ [문제 해결](bulk-upload-troubleshooting.md)
# 사전 조건: `cqlsh COPY FROM`을 사용하여 데이터를 업로드하기 전에 완료해야 하는 단계
이 자습서를 시작하려면 먼저 다음 작업을 완료해야 합니다.
1. 아직 등록하지 않은 경우의 단계에 AWS 계정 따라에 가입합니다[설 AWS Identity and Access Management정](accessing.md#SettingUp.IAM).
1. [Amazon Keyspaces에 프로그래밍 방식으로 액세스하기 위한 서비스별 자격 증명 만들기](programmatic.credentials.ssc.md)의 단계에 따라 서비스별 자격 증명을 생성합니다.
1. Cassandra 쿼리 언어 쉘(cqlsh) 연결을 설정하고 [`cqlsh` 사용하여 Amazon Keyspace에 접속](programmatic.cqlsh.md)의 단계에 따라 Amazon Keyspaces에 연결할 수 있는지 확인합니다.
# 1단계: 데이터 업로드를 위해 소스 CSV 파일 및 대상 테이블 생성
이 자습서에서는 이름 `keyspaces_sample_table.csv`가 있는 쉼표로 구분된 값(CSV) 파일을 데이터 마이그레이션의 원본 파일로 사용합니다. 제공된 샘플 파일에는 이름이 `book_awards`인 테이블에 대한 몇 개의 데이터 행이 포함되어 있습니다.
1. 소스 파일을 생성합니다. 다음 옵션 중 하나를 선택할 수 있습니다.
+ 다음 아카이브 파일 [samplemigration.zip](samples/samplemigration.zip)에 포함된 샘플 CSV 파일(`keyspaces_sample_table.csv`)을 다운로드합니다. 아카이브의 압축을 풀고 `keyspaces_sample_table.csv`의 경로를 기록해 둡니다.
+ Apache Cassandra 데이터베이스에 저장된 자체 데이터로 CSV 파일을 채우려면 다음 예와 같이 `cqlsh` 및 `COPY TO` 문을 사용하여 소스 CSV 파일을 채울 수 있습니다.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true";
```
생성한 CSV 파일이 다음 요구 사항을 충족하는지 확인합니다.
+ 첫 번째 행에는 열 이름이 포함됩니다.
+ 소스 CSV 파일의 열 이름은 대상 테이블의 열 이름과 일치합니다.
+ 데이터는 쉼표로 구분됩니다.
+ 모든 데이터 값은 유효한 Amazon Keyspaces 데이터 유형입니다. [데이터 타입](cql.elements.md#cql.data-types)을(를) 참조하세요.
1. Amazon Keyspaces에서 대상 키스페이스 및 테이블을 생성합니다.
1. `cqlsh`를 사용하여 Amazon Keyspaces에 연결하고 다음 예제의 서비스 엔드포인트, 사용자 이름 및 암호를 사용자 고유의 값으로 바꿉니다.
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. 다음 예제와 같이 이름 `catalog`를 사용하여 새 키스페이스를 생성합니다.
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. 새 키스페이스를 사용할 수 있게 되면 다음 코드를 사용하여 대상 테이블 `book_awards`를 생성합니다.
```
CREATE TABLE "catalog.book_awards" (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Apache Cassandra가 원본 데이터 소스인 경우 헤더가 일치하는 Amazon Keyspaces 대상 테이블을 생성하는 간단한 방법은 다음 문과 같이 소스 테이블에서 `CREATE TABLE` 문을 생성하는 것입니다.
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
그런 다음 Cassandra 소스 테이블의 설명과 일치하는 열 이름 및 데이터 유형을 사용하여 Amazon Keyspaces에 대상 테이블을 생성합니다.
# 2단계: 성공적인 데이터 업로드를 위해 소스 데이터 준비
효율적인 전송을 위해 소스 데이터를 준비하는 것은 2단계 프로세스입니다. 먼저 데이터를 무작위화합니다. 두 번째 단계에서는 데이터를 분석하여 데이터 업로드가 성공적으로 이루어질 수 있도록 적절한 `cqlsh` 파라미터 값과 필요한 테이블 설정을 결정합니다.
**데이터 무작위화**
이 `cqlsh COPY FROM` 명령은 CSV 파일에 나타나는 것과 동일한 순서로 데이터를 읽고 씁니다. `cqlsh COPY TO` 명령을 사용하여 소스 파일을 만들면 데이터가 키 정렬된 순서대로 CSV에 기록됩니다. Amazon Keyspaces는 내부적으로 파티션 키를 사용하여 데이터를 분할합니다. Amazon Keyspaces에는 동일한 파티션 키에 대한 요청을 로드 밸런싱하는 데 도움이 되는 로직이 내장되어 있지만 순서를 무작위로 지정하면 데이터를 로드하는 것이 더 빠르고 효율적입니다. Amazon Keyspaces가 다른 파티션에 쓸 때 발생하는 내장된 로드 밸런싱을 활용할 수 있기 때문입니다.
쓰기를 파티션 전체에 균등하게 분산하려면 소스 파일의 데이터를 무작위화해야 합니다. 이 작업을 수행하는 애플리케이션을 작성하거나 [Shuf](https://en.wikipedia.org/wiki/Shuf)와 같은 오픈 소스 도구를 사용할 수 있습니다. Shuf는 Linux 배포판, macOS([homebrew](https://brew.sh)에 coreutils 설치), Windows(Windows Subsystem for Linux(WSL) 사용)에서 무료로 사용할 수 있습니다. 이 단계에서 열 이름이 있는 헤더 행이 섞이지 않도록 하려면 한 가지 추가 단계가 필요합니다.
헤더를 보존하면서 소스 파일을 무작위화하려면 다음 코드를 입력합니다.
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf는 `keyspace.table.csv`라는 새 CSV 파일에 데이터를 다시 씁니다. 이제 필요 없는 `keyspaces_sample_table.csv` 파일을 삭제할 수 있습니다.
**데이터 분석**
데이터를 분석하여 평균 및 최대 행 크기를 결정합니다.
이렇게 하는 이유는 다음과 같습니다.
+ 평균 행 크기는 전송할 총 데이터 양을 추정하는 데 도움이 됩니다.
+ 데이터 업로드에 필요한 쓰기 용량을 프로비저닝하려면 평균 행 크기가 필요합니다.
+ 각 행의 크기가 Amazon Keyspaces의 최대 행 크기인 1MB 미만인지 확인할 수 있습니다.
**참고**
이 할당량은 파티션 크기가 아니라 행 크기를 나타냅니다. Apache Cassandra 파티션과 달리 Amazon Keyspaces 파티션은 크기가 사실상 바인딩되지 않을 수 있습니다. 파티션 키와 클러스터링 열에는 메타데이터를 위한 추가 스토리지가 필요하며 이를 행의 원시 크기에 추가해야 합니다. 자세한 내용은 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md) 단원을 참조하십시오.
다음 코드는 [AWK](https://en.wikipedia.org/wiki/AWK)를 사용하여 CSV 파일을 분석하고 평균 및 최대 행 크기를 인쇄합니다.
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
이 코드를 실행하면 다음과 같은 결과가 출력됩니다.
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
이 자습서의 다음 단계에서 평균 행 크기를 사용하여 테이블의 쓰기 용량을 프로비저닝합니다.
# 3단계: 테이블의 처리량 용량 설정
이 자습서에서는 설정된 시간 범위 내에서 데이터를 로드하도록 cqlsh를 조정하는 방법을 보여 줍니다. 얼마나 많은 읽기와 쓰기를 수행하는지 미리 알고 있기 때문에 프로비저닝된 용량 모드를 사용합니다. 데이터 전송을 완료한 후에는 애플리케이션의 트래픽 패턴에 맞게 테이블의 용량 모드를 설정해야 합니다. 용량 관리에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)에서 서버리스 리소스 관리](serverless_resource_management.md) 섹션을 참조하세요.
프로비저닝된 용량 모드를 사용하면 테이블에 프로비저닝할 읽기 및 쓰기 용량을 미리 지정할 수 있습니다. 쓰기 용량은 시간당 청구되며 쓰기 용량 단위(WCU)로 측정됩니다. 각 WCU는 초당 1KB의 데이터 쓰기를 지원하기에 충분한 쓰기 용량입니다. 데이터를 로드할 때 쓰기 속도는 대상 테이블에 설정된 최대 WCU(매개 변수: `write_capacity_units`) 미만이어야 합니다.
기본적으로 테이블에 최대 40,000WCU를 프로비저닝하고 계정의 모든 테이블에 80,000WCU를 프로비저닝할 수 있습니다. 추가 용량이 필요한 경우 [Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas)에서 할당량 증가를 요청할 수 있습니다. 할당량에 대한 자세한 내용은 [Amazon Keyspaces(Apache Cassandra용)에 대한 할당량](quotas.md) 섹션을 참조하세요.
**삽입에 필요한 WCU의 평균 수를 계산합니다.**
초당 1KB의 데이터를 삽입하려면 1WCU가 필요합니다. 360,000개의 행이 있는 CSV 파일에 1시간 내에 모든 데이터를 로드하려면 초당 100개의 행을 작성해야 합니다(360,000행/60분/60초 = 초당 100행). 각 행에 최대 1KB의 데이터가 있는 경우 초당 100개의 행을 삽입하려면 테이블에 100WCU를 프로비저닝해야 합니다. 각 행에 1.5KB의 데이터가 있는 경우 초당 한 행을 삽입하려면 WCU 두 개가 필요합니다. 따라서 초당 100개의 행을 삽입하려면 200개의 WCU를 프로비저닝해야 합니다.
초당 행 하나를 삽입하는 데 필요한 WCU 수를 결정하려면 평균 행 크기(바이트)를 1024로 나누고 가장 가까운 정수로 반올림합니다.
예를 들어 평균 행 크기가 3000바이트인 경우 초당 한 행을 삽입하려면 WCU 3개가 필요합니다.
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**데이터 로드 시간 및 용량 계산**
이제 CSV 파일의 평균 크기와 행 수를 알았으므로 주어진 시간 동안 데이터를 로드하는 데 필요한 WCU 수와 다양한 WCU 설정을 사용하여 CSV 파일의 모든 데이터를 로드하는 데 걸리는 대략적인 시간을 계산할 수 있습니다.
예를 들어 파일의 각 행이 1KB이고 CSV 파일에 1,000,000개의 행이 있는 경우 1시간 내에 데이터를 로드하려면 해당 시간 동안 테이블에 최소 278개의 WCU를 프로비저닝해야 합니다.
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**프로비저닝된 용량 설정 구성**
테이블을 생성할 때 또는 `ALTER TABLE` CQL 명령을 사용하여 테이블의 쓰기 용량 설정을 지정할 수 있습니다. 다음은 `ALTER TABLE` CQL 문을 사용하여 테이블의 프로비저닝된 용량 설정을 변경하는 구문입니다.
```
ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
전체 언어 참조는 [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter) 섹션을 참조하세요.
# 4단계: `cqlsh COPY FROM` 설정 구성
이 섹션에서는 `cqlsh COPY FROM`의 파라미터 값을 결정하는 방법을 간략하게 설명합니다. `cqlsh COPY FROM` 명령은 이전에 준비한 CSV 파일을 읽고 CQL을 사용하여 Amazon Keyspaces에 데이터를 삽입합니다. 이 명령은 행을 나누어 작업자 집합 간에 `INSERT` 작업을 분배합니다. 각 작업자는 Amazon Keyspaces와 연결을 설정하고 이 채널을 통해 `INSERT` 요청을 보냅니다.
`cqlsh COPY` 명령에는 작업자 간에 작업을 균등하게 분배하기 위한 내부 로직이 없습니다. 하지만 작업이 균등하게 분배되도록 수동으로 구성할 수 있습니다. 먼저 다음과 같은 주요 cqlsh 파라미터를 검토합니다.
+ **DELIMITER** - 쉼표 이외의 구분 기호를 사용한 경우 이 파라미터를 설정할 수 있습니다. 기본값은 쉼표입니다.
+ **INGESTRATE** - `cqlsh COPY FROM`이 초당 처리를 시도하는 대상 행 수입니다. 지정되지 않은 경우 기본값은 100,000입니다.
+ **NUMPROCESSES** - cqlsh가 `COPY FROM` 작업을 위해 생성하는 하위 작업자 프로세스의 수입니다. 이 설정의 최대값은 16이며, 기본값은 `num_cores - 1`입니다. 여기서 `num_cores`는 cqlsh를 실행하는 호스트의 프로세싱 코어 수입니다.
+ **MAXBATCHSIZE** – 배치 크기에 따라 단일 배치에서 대상 테이블에 삽입되는 최대 행 수가 결정됩니다. 설정되지 않은 경우 cqlsh는 삽입된 20개 행의 배치를 사용합니다.
+ **CHUNKSIZE** - 하위 작업자에게 전달되는 작업 단위의 크기입니다. 기본적으로 5,000으로 설정됩니다.
+ **MAXATTEMPTS** - 실패한 작업자 청크를 다시 시도할 수 있는 최대 횟수입니다. 최대 시도 횟수에 도달하면 실패한 레코드가 새 CSV 파일에 기록되며 실패를 조사한 후 나중에 다시 실행할 수 있습니다.
대상 테이블에 프로비저닝한 WCU 수를 기반으로 `INGESTRATE`를 설정합니다. `cqlsh COPY FROM` 명령의 `INGESTRATE`는 제한이 아니라 대상 평균입니다. 즉, 설정한 수치를 초과할 수 있으며 종종 그럴 수도 있습니다. 버스트를 허용하고 데이터 로드 요청을 처리할 수 있는 충분한 용량을 확보하려면 `INGESTRATE`를 테이블 쓰기 용량의 90% 설정합니다.
```
INGESTRATE = WCUs * .90
```
그런 다음 `NUMPROCESSES` 파라미터를 시스템의 코어 수보다 하나 적은 것으로 설정합니다. 다음 코드를 실행하여 시스템의 코어 수를 확인할 수 있습니다.
```
python -c "import multiprocessing; print(multiprocessing.cpu_count())"
```
이 자습서에서는 다음 값을 사용합니다.
```
NUMPROCESSES = 4
```
각 프로세스는 작업자를 생성하고 각 작업자는 Amazon Keyspaces에 대한 연결을 설정합니다. Amazon Keyspaces는 모든 연결에서 초당 최대 3,000개의 CQL 요청을 지원할 수 있습니다. 즉, 각 작업자가 처리하는 요청이 초당 3,000개 미만인지 확인해야 합니다.
`INGESTRATE`와 마찬가지로 작업자는 설정한 수를 초과하여 버스트하는 경우가 많으며 클록 초로 제한되지 않습니다. 따라서 버스트를 고려하려면 각 작업자가 초당 2,500개의 요청을 처리하게 지정하도록 cqlsh 파라미터를 설정합니다. 작업자에게 분배된 작업량을 계산하려면 다음 지침을 사용합니다.
+ `INGESTRATE`를 `NUMPROCESSES`로 나눕니다.
+ `INGESTRATE`/`NUMPROCESSES` > 2,500인 경우 `INGESTRATE`를 낮추면 이 공식이 true가 됩니다.
```
INGESTRATE / NUMPROCESSES <= 2,500
```
샘플 데이터의 업로드를 최적화하도록 설정을 구성하기 전에 `cqlsh` 기본 설정을 검토하고 기본 설정을 사용하는 것이 데이터 업로드 프로세스에 어떤 영향을 미치는지 살펴보겠습니다. `cqlsh COPY FROM`은 `CHUNKSIZE`를 사용하여 작업자에게 배포할 작업 청크(`INSERT` 문)를 만들기 때문에 작업이 자동으로 균등하게 분배되지 않습니다. `INGESTRATE` 설정에 따라 일부 작업자는 가만히 앉아 있을 수 있습니다.
작업자 간에 작업을 균등하게 분배하고 각 작업자가 초당 2,500개의 요청 속도를 최적화할 수 있도록 하려면 입력 파라미터를 변경하여 `CHUNKSIZE`, `MAXBATCHSIZE` 및 `INGESTRATE`를 설정해야 합니다. 데이터 로드 중에 네트워크 트래픽 사용률을 최적화하려면 `MAXBATCHSIZE`에 대해 최대값인 30에 가까운 값을 선택합니다. `CHUNKSIZE`를 100으로 `MAXBATCHSIZE`를 25로 변경하면 10,000개의 행이 네 명의 작업자 사이에 균등하게 분산됩니다(10,000/2500 = 4).
다음 코드 예제에서는 이를 보여 줍니다.
```
INGESTRATE = 10,000
NUMPROCESSES = 4
CHUNKSIZE = 100
MAXBATCHSIZE. = 25
Work Distribution:
Connection 1 / Worker 1 : 2,500 Requests per second
Connection 2 / Worker 2 : 2,500 Requests per second
Connection 3 / Worker 3 : 2,500 Requests per second
Connection 4 / Worker 4 : 2,500 Requests per second
```
요약하면 `cqlsh COPY FROM` 파라미터를 설정할 때 다음 공식을 사용합니다.
+ **INGESTRATE** = write\$1capacity\$1units \$1 .90
+ **NUMPROCESSES** = num\$1cores -1(기본값)
+ **INGESTRATE / NUMPROCESSES** = 2,500(true 문이어야 합니다.)
+ **MAXBATCHSIZE** = 30(기본값은 20입니다. Amazon Keyspaces는 최대 30개의 배치를 허용합니다.)
+ **CHUNKSIZE** = (INGESTRATE / NUMPROCESSES) / MAXBATCHSIZE
`NUMPROCESSES`, `INGESTRATE` 및 `CHUNKSIZE` 계산을 마쳤고 이제 데이터를 로드할 준비가 되었습니다.
# 5단계: `cqlsh COPY FROM` 명령을 실행하여 CSV 파일의 데이터를 대상 테이블에 업로드
`cqlsh COPY FROM` 명령을 실행하려면 다음 단계를 완료합니다.
1. cqlsh를 사용하여 Amazon Keyspaces에 연결합니다.
1. 다음 코드를 사용하여 키스페이스를 선택합니다.
```
USE catalog;
```
1. 쓰기 일관성을 `LOCAL_QUORUM`으로 설정합니다. 데이터 내구성을 보장하기 위해 Amazon Keyspaces는 다른 쓰기 일관성 설정을 허용하지 않습니다. 다음 코드를 확인합니다.
```
CONSISTENCY LOCAL_QUORUM;
```
1. 다음 코드 예제를 사용하여 `cqlsh COPY FROM` 구문을 준비합니다.
```
COPY book_awards FROM './keyspace.table.csv' WITH HEADER=true
AND INGESTRATE=calculated ingestrate
AND NUMPROCESSES=calculated numprocess
AND MAXBATCHSIZE=20
AND CHUNKSIZE=calculated chunksize;
```
1. 이전 단계에서 준비한 문을 실행합니다. cqlsh는 구성한 모든 설정을 다시 실행합니다.
1. 설정이 입력과 일치하는지 확인합니다. 다음 예를 참조하세요.
```
Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'}
Using 15 child processes
```
1. 다음 예와 같이 전송된 행 수와 현재 평균 비율을 검토합니다.
```
Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s
```
1. cqlsh가 데이터 업로드를 완료하면 다음 예와 같이 데이터 로드 통계 요약(읽은 파일 수, 런타임, 건너뛴 행 수)을 검토합니다.
```
15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped).
```
자습서의 마지막 단계에서는 Amazon Keyspaces에 데이터를 업로드했습니다.
**중요**
이제 데이터를 전송했으니 대상 테이블의 용량 모드 설정을 애플리케이션의 일반 트래픽 패턴에 맞게 조정합니다. 용량을 변경하기 전까지는 프로비저닝된 용량에 대해 시간당 요금이 부과됩니다.
# 문제 해결
데이터 업로드가 완료된 후 행을 건너뛰었는지 확인합니다. 이렇게 하려면 원본 CSV 파일의 소스 디렉터리로 이동하여 다음 이름의 파일을 검색합니다.
```
import_yourcsvfilename.err.timestamp.csv
```
cqlsh는 건너뛴 데이터 행을 해당 이름의 파일에 기록합니다. 파일이 소스 디렉터리에 있고 그 안에 데이터가 있는 경우 이 행은 Amazon Keyspaces에 업로드되지 않았습니다. 이러한 행을 다시 시도하려면 먼저 업로드 중에 발생한 오류가 있는지 확인하고 그에 따라 데이터를 조정합니다. 이러한 행을 다시 시도하려면 프로세스를 다시 실행하면 됩니다.
**일반적인 오류**
행이 로드되지 않는 가장 일반적인 이유는 용량 오류와 구문 분석 오류입니다.
**Amazon Keyspaces에 데이터를 업로드할 때 잘못된 요청 오류**
다음 예제의 소스 테이블에는 카운터 열이 포함되어 있으며 이로 인해 cqlsh `COPY` 명령의 배치 호출이 로그됩니다. 로그된 배치 호출은 Amazon Keyspaces에서 지원되지 않습니다.
```
Failed to import 10 rows: InvalidRequest - Error from server: code=2200 [Invalid query] message=“Only UNLOGGED Batches are supported at this time.“, will retry later, attempt 22 of 25
```
이 오류를 해결하려면 DSBulk를 사용하여 데이터를 마이그레이션합니다. 자세한 내용은 [자습서: DSBulk를 사용하여 Amazon Keyspaces에 데이터 로드](dsbulk-upload.md) 단원을 참조하십시오.
**Amazon Keyspaces에 데이터를 업로드할 때 구문 분석기 오류**
다음 예는 `ParseError`로 인해 건너뛴 행을 보여 줍니다.
```
Failed to import 1 rows: ParseError - Invalid ... –
```
이 오류를 해결하려면 가져올 데이터가 Amazon Keyspaces의 테이블 스키마와 일치하는지 확인해야 합니다. 가져오기 파일에 구문 분석 오류가 있는지 검토합니다. 오류를 격리하는 `INSERT` 문을 사용하여 단일 데이터 행을 사용해 볼 수 있습니다.
**Amazon Keyspaces에 데이터를 업로드할 때 용량 오류**
```
Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency':
'LOCAL_QUORUM'}, will retry later, attempt 1 of 100
```
Amazon Keyspaces는 처리량 용량이 충분하지 않아 쓰기 요청이 실패하는 경우를 나타내기 위해 `ReadTimeout` 및 `WriteTimeout` 예외를 사용합니다. 용량 부족 예외를 진단하는 데 도움이 되도록 Amazon Keyspaces는 Amazon CloudWatch에 `WriteThrottleEvents` 및 `ReadThrottledEvents` 지표를 게시합니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 Amazon Keyspaces 모니터링](monitoring-cloudwatch.md) 단원을 참조하십시오.
**Amazon Keyspaces에 데이터를 업로드할 때 cqlsh 오류**
cqlsh 오류를 해결하는 데 도움이 되도록 `--debug` 플래그를 사용하여 실패한 명령을 다시 실행합니다.
호환되지 않는 버전의 cqlsh를 사용하는 경우 다음 오류가 표시됩니다.
```
AttributeError: 'NoneType' object has no attribute 'is_up'
Failed to import 3 rows: AttributeError - 'NoneType' object has no attribute 'is_up', given up after 1 attempts
```
다음 명령을 실행하여 올바른 cqlsh 버전이 설치되어 있는지 확인합니다.
```
cqlsh --version
```
출력에 대해 다음과 같은 내용이 표시되어야 합니다.
```
cqlsh 5.0.1
```
Windows를 사용하는 경우 `cqlsh`의 모든 인스턴스를 `cqlsh.bat`로 바꿉니다. 예를 들어 Windows에서 cqlsh 버전을 확인하려면 다음 명령을 실행합니다.
```
cqlsh.bat --version
```
cqlsh 클라이언트가 서버로부터 유형에 상관없이 연속으로 세 개의 오류를 수신한 후 Amazon Keyspaces에 대한 연결이 실패합니다. cqlsh 클라이언트가 실패하고 다음 메시지가 표시됩니다.
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
이 오류를 해결하려면 가져올 데이터가 Amazon Keyspaces의 테이블 스키마와 일치하는지 확인해야 합니다. 가져오기 파일에 구문 분석 오류가 있는지 검토합니다. 오류를 격리하는 INSERT 문을 사용하여 단일 데이터 행을 사용해 볼 수 있습니다.
클라이언트는 자동으로 연결 재설정을 시도합니다.