PostgreSQL checkpoint log explained
The write and sync phase mean rather different things (unfortunately).  In the middle phase of a checkpoint, it writes out all the dirty buffers from shared buffers.  It does this in a throttled way, mainly regulated by checkpoint_completion_target.  The time reported here is the time it spent writing those buffers, as well as the time it spend sleeping in order to regulate the rate at which the buffers get written.  So not all of the "write" time was spent actively writing.  The length of time spent in the write phase, 2.5 minutes, doesn't really mean anything without knowing what your other settings are.

During the sync phase, it syncs all of those files it just wrote to (as well as any data files other processes may have written to).  This stage is unthrottled, it syncs them as fast as it can.  That this took 34 seconds, with one file in there taking 16.143 seconds, suggests that your IO hardware is not up to the workload you are throwing at it.

The 159 synced files refers to the number of data files that had been dirtied since the end of the last checkpoint, and so needed to be synced before the end of this one.  The 47 refers to WAL files, not data files.  WAL files contain references to changes made to data files.  It is quite easy for 47 WAL files to contain references for 159 data files (or for that matter, 15,900 data files).  But it is not quite that simple, because the WAL files being recycled are the ones from two checkpoints ago, so the relation between 47 and 159 is an analogy, not a concrete count.