Status

Current state: Under Discussion

Discussion thread: here

JIRA: KAFKA-3163

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Kafka has a few timestamp based functions, including

1. Searching message by timestamp
2. Time based log rolling
3. Time based log retention.

Currently these operations depend on the create time / modification time of the log segment file. This has a few issues.

1. Searching offset by timestamp has very coarse granularity (log segment level), it also does not work well when replica is reassigned.
2. The time based log rolling and retention does not work well when replica is reassigned.

In this KIP we propose adding a time based log index using the timestamp of the messages introduced in KIP-32.

Public Interfaces

There will be some behavioral changes to time based log retention and log rolling.

1. The log retention will be changed to base on the time index of a log segment instead of basing on the last modification time of the log segment file.
2. The time based log rolling will have the following change: The log segment will roll out when log.roll.ms has elapsed since the largest timestamp of the messages in the log segment.

This KIP will indroduce another index file for each log segment. So the number of open file handlers will increased by about 1/3.

Proposed Changes

Add a new time-based log index

Broker will build time index based on the timestamp of the messages. The log index works for both LogAppendTime and CreateTime.

Time index format

Create another index file for each log segment with name SegmentBaseOffset.timeindex. The density of the index is defined by index.interval.bytes configuration.

The time index entry format is:

Time Index Entry => Timestamp Offset
  Timestamp => int64
  Offset => int32

Based on the proposal in KIP-32, the broker will build the time index in the following way:

1. When a new log segment is created, the broker will create a time index file for the log segment. 
2. The default initial / max size of the time index files is the same as the offset index files. (time index entry is 1.5x of the size of offset index entry, user should set the configuration accordingly).
3. Each log segment maintains the largest timestamp so far in that segment. The initial value of the largest timestamp is -1 for a newly created segment.
4. When broker receives a message, if the message is not rejected due to timestamp exceeds threshold, the message will be appended to the log. (The timestamp will either be LogAppendTime or CreateTime depending on the configuration)
5. When broker appends the message to the log segment, if an offset index entry is inserted, it will also insert a time index entry if the max timestamp so far is greater than the timestamp in the last time index entry.
   • For message format v0, the timestamp is always -1, so no time index entry will be inserted when message is appended.
6. When the current active segment is rolled out or closed. A time index entry will be inserted into the time index to ensure the last time index entry has the largest timestamp of the log segment.
   1. If largest timestamp in the segment is non-negative (at least one message has a timestamp), the entry will be (largest_timestamp_in_the_segment -> base_offset_of_the_next_segment)
   2. If largest timestamp in the segment is -1 (No message in the segment has a timestamp), the entry will be (last_modification_time_of_the_segment -> base_offset_of_the_next_segment) 

The time index is not globally monotonically increasing. Instead, it is only monotonically increasing within each time index file. i.e. It is possible that the time index file for a later log segment contains smaller timestamp than some timestamp in the time index file of an earlier segment. 

Broker startup

On broker startup, the latest timestamp is needed for the next log index append. The broker will find the largest timestamp by looking at the last time index entry. The last time index entry has the largest timestamp if the broker is shutdown normally before.  Broker will only load the largest timestamp if message.format.version is on or after 0.10.0. Otherwise the broker will skip loading the largest timestamp. On a recovery after hard failure, the broker will scan the active log segment till the log end.

If there is no time index file for an inactive segment, the broker will create an empty time index file and append a time index entry (last_modification_time_of_the_segment -> base_offset_of_the_next_segment). For the active segment, the broker will create the time index file but leave it empty.

Log Truncation

When the log is truncated, because the offset in the time index is also monotonically increasing, we will also truncate the time index entries whose corresponding messages have been truncated. The active segment will reload the largest timestamp after truncation just like it did during startup.

Enforce time based log retention

To enforce time based log retention, the broker will check the last time index entry of a log segment. The timestamp will be the latest timestamp of the messages in the log segment. So if that timestamp expires, the broker will delete the log segment. 

Enforce time based log rolling

Currently time based log rolling is based on the creating time of the log segment. With this KIP, the time based rolling would be changed to based on the largest timestamp ever seen in a log segment. A new log segment will be rolled out if current time is greater than largest timestamp ever seen in the log segment + log.roll.ms. When message.timestamp.type=CreateTime, user should set max.message.time.difference.ms appropriately together with log.roll.ms to avoid frequent log segment roll out.

Search message by timestamp

When searching by timestamp, broker will start from the earliest log segment and check the last time index entry. If the timestamp of the last time index entry is greater than the target timestamp, the broker will do binary search on that time index to find the closest index entry and scan the log from there. Otherwise it will move on to the next log segment.

Searching by timestamp will have better accuracy. The guarantees provided are:

• The messages whose timestamp are after the searched timestamp will be consumed.
• Some messages with earlier timestamp might also be consumed.

The OffsetRequest behaves almost the same as before. If timestamp T is set in the OffsetRequest, the first offset in the returned offset sequence means that if user want to consume from T, that is the offset to start with. The guarantee is that any message whose timestamp is greater than T has a bigger offset. i.e. Any message before this offset has a timestamp < T.

The time index granularity does not change the actual timestamp searching granularity. It only affects the time needed for searching.

Use case discussion

From the use cases list above, generally having a LogAppendTime index is better than having a CreateTime based timestamp.

Compatibility, Deprecation, and Migration Plan

The change is backward compatible after KIP-31 and KIP-32 are checked in.

Broker will keep keep an in-memory maxTimestampSoFar variable, which is initialized to -1 and only gets updated when a message with a larger timestamp is appended to the log segment.

If maxTimestampSoFar is -1, log retention will still be based on last_modification_time. And log rolling will still be based on log create time.

Broker will do the followings during migration for log retention and searching by timestamp:

1. The broker will create a time index for each segment if the segment does not have one.
   1. For the inactive log segments, the broker will append an entry (last_modification_time_of_the_segment -> offset_of_the_first_message_in_the_segment) to each empty time index.
   2. For the active log segments, the time index file will be left empty.
2. After the entire cluster is migrated to use time based log index for log retention. The broker will enforce log retention using time index. Given what we do in step 1, the behavior is:
   1. For segments only having messages whose versions are before 0.10.0, the entry with last modification time in the time index will be used for retention.
   2. For segments having at least one message with version 0.10.0, the max timestamp of the messages will be used for log retention.

Broker will do the followings for log rolling during migration.

1. On startup, broker will initially use the segment last modification time as the largest message timestamp.
2. If a new message whose version is after 0.10.0 and its timestamp is greater than current max message timestamp. The broker updates the current largest message timestamp.
3. Broker always use the difference between current time and largest timestamp of the segment to decide whether roll out a new log segment or not.

Rejected Alternatives

Add a timestamp field to log index entry

The most straight forward approach to have a time index is to let the log index files have a timestamp associate with each entry.

Log Index Entry => Offset Position Timestamp
  Offset => int32
  Position => int32
  Timestamp => int64

Because the index entry size become 16 bytes instead of 8 bytes. The index file size also needs to be doubled. As an example, one of the broker we have has ~3500 partitions. The index file took about 16GB memory. With this new format, the memory consumption would be 32GB.

Option 1 - Time based index using LogAppendTime

In order to enable timestamp based search at finer granularity, we need to add the timestamp to log indices as well. Broker will build time index based on LogAppendTime of messages. 

Because all the index files are memory mapped files the main consideration here is to avoid significantly increasing the memory consumption. 

The time index file needs to be built just like the log index file based on each log segment file.

Use a time index for each log segment to save the timestamp -> log offset at minute granularity

Create another index file for each log segment with name SegmentBaseOffset.time.index to have index at minute level. The time index entry format is:

Time Index Entry => Timestamp Offset
  Timestamp => int64
  Offset => int32

Users don't typically need to look up offsets with seconds granularity.

Option 2 - Time based index using CreateTime

Another option is to build index based on CreateTime of messages. Similar to option 1, we are going to have one time index file per log segment.

The biggest challenge of indexing using CreateTime is that CreateTime can be out of order.

One solution is as below:

1. Each broker keeps in memory a timestamp index map - Map[TopicPartitionSegment, Map[TimestampByMinute, Offset]]
   1. The timestamp is on minute boundary
   2. The offset is the offset of the first message in the log segment that falls into a minute

2. Create a timestamp index file for each log segment. The entry in the file is in following format:

   Time Index Entry => Timestamp Offset
     Timestamp => int64
     Offset => int32

   So the timestamp index file will simply become a persistent copy of timestamp index map. Broker will load the timestamp map from the file on startup.

3. When a broker (regardless leader or follower) receives a message, it does the following:
   1. Find which minute MIN the message with offset OFFSET falls in
   2. Check if MIN has already been in the in memory timestamp map for current log segment. If the timestamp does not exist, then the broker add [MIN->OFFSET] to both the in memory timestamp index map and the timestamp index file.
4. When a log segment is deleted, the broker:
   
   1. Remove the TopicPartitionSegment key from in memory map
   2. Remove the log segment timestamp index file