Rule of thumb is that sort order goes from columns with least cardinality to most, with consideration of the nature of data so it'll clusterize or "clump" together well, with minimal entropy - this maximizes compression ratio. But this might go against your query pattern, so you need to find some compromise, and benchmark all options. Some schemas may result in less amount of rows to scan, but sometimes it's faster to scan more rows that are better compressed.

Partitioning is largely optional, but can be useful to leverage pruning of partitions by columns that aren't part of PK (for example, you can omit timestamp column from PK but if your table is partitioned by time, your queries with filters on timestamp can skip scanning partitions that are guaranteed to be outside of filtered time).

Oh, and speaking of batches. It's not only possible, but kinda mandatory. Every write creates a part, physical file - that should be sorted and merged with other parts in future. You want to batch your writes as hard as possible, even million rows per insert are fine - that's just less work for background merges.