spark-dynamodb | DynamoDB data source for Apache Spark

That's a lot of questions in one question, you'll get a high level answer.

DynamoDB scales by increasing the number of partitions. Each item is stored on a partition. Each partition can handle:

• up to 3000 Read Capacity Units
• up to 1000 Write Capacity Units
• up to 10 GB of data

As soon as any of these limits is reached, the partition is split into two and the items are redistributed. This happens until there is sufficient capacity available to meet demand. You don't control how that happens, it's a managed service that does this in the background.

The number of partitions only ever grows.

Based on this information we can address your questions:

1. Does intensive writing affects reading in the case of on-demand tables? Does autoscaling work independently for reading/writing?

   The scaling mechanism is the same for read and write activity, but the scaling point differs as mentioned above. In an on-demand table AutoScaling is not involved, that's only for tables with provisioned throughput. You shouldn't notice an impact on your reads here.

2. Is it fine to set large throughput for a short period of time? As far as I see the cost is the same in the case of on-demand tables. What are the potential issues?

   I assume you set the throughput that spark can use as a budget for writing, it won't have that much of an impact on on-demand tables. It's information, it can use internally to decide how much parallelization is possible.

3. I observe some throttled requests but eventually, all the data is successfully uploaded. How can this be explained? I suggest that the client I use has advanced rate-limiting logic and I didn't manage to find a clear answer so far.

   If the client uses BatchWriteItem, it will get a list of items that couldn't be written for each request and can enqueue them again. Exponential backoff may be involved but that is an implementation detail. It's not magic, you just have to keep track of which items you've successfully written and enqueue those that you haven't again until the "to-write" queue is empty.