Yes, it (usually) works in chunks of data bursts.
I myself experimented with live streaming over my own VPS, so possibly avoid Youtube…
Problem was bandwidth, I could not serve to more than approx 40 watchers simultaneously, which is just too few… 
With HLS the stream is split up into fragments, the longer a fragment is, the more data travels to watcher at once, and the longer the delay is.
The shorter the fragment, the smaller the chunks, the lower the delay, but also higher the risk of the next chunk not being received on time (so stutterings, bufferings happen).
Something on-topic for you:
Edit:
No contradiction. Even with Youtube the fact is, that a live stream can have up to 1 minute delay.
So imagine, OBS encodes the video/audio stream on my laptop in real time, the data is sent to Youtube ingest server. The packets have to arrive there.
Some buffering has to be done there, at least the amount of data for 1 chunk of the HLS needs to be collected, then put it into the HLS buffer.
Clients (watchers) grab those chunks, the server hast send them.
On the client side the chunks need to be concatenated, then decoded, played.
As long as there is always enough data on the playback buffer, you (the watcher) sees the stream totally contigous.
Whenever the buffer underruns for any reason: you see the buffering.
Assume, I send out a specific frame of a stream at 10:00:00 am, that specific frame may end up on your screen as late as 10:01:00 am.
But according to my experience usually the delay stays below 30 seconds.
Dose this help you understanding it?