apache · gwenshap · Oct 16, 2015
diff --git a/docs/design.html b/docs/design.html
@@ -306,15 +306,15 @@ <h4>Log Compaction Basics</h4>
 
 Here is a high-level picture that shows the logical structure of a Kafka log with the offset for each message.
 <p>
-<img src="/images/log_cleaner_anatomy.png">
+<img src="images/log_cleaner_anatomy.png">
 <p>
 The head of the log is identical to a traditional Kafka log. It has dense, sequential offsets and retains all messages. Log compaction adds an option for handling the tail of the log. The picture above shows a log with a compacted tail. Note that the messages in the tail of the log retain the original offset assigned when they were first written&mdash;that never changes. Note also that all offsets remain valid positions in the log, even if the message with that offset has been compacted away; in this case this position is indistinguishable from the next highest offset that does appear in the log. For example, in the picture above the offsets 36, 37, and 38 are all equivalent positions and a read beginning at any of these offsets would return a message set beginning with 38.
 <p>
 Compaction also allows for deletes. A message with a key and a null payload will be treated as a delete from the log. This delete marker will cause any prior message with that key to be removed (as would any new message with that key), but delete markers are special in that they will themselves be cleaned out of the log after a period of time to free up space. The point in time at which deletes are no longer retained is marked as the "delete retention point" in the above diagram.
 <p>
 The compaction is done in the background by periodically recopying log segments. Cleaning does not block reads and can be throttled to use no more than a configurable amount of I/O throughput to avoid impacting producers and consumers. The actual process of compacting a log segment looks something like this:
 <p>
-<img src="/images/log_compaction.png">
+<img src="images/log_compaction.png">
 <p>
 <h4>What guarantees does log compaction provide?</h4>
 

diff --git a/docs/images/consumer-groups.png b/docs/images/consumer-groups.png
diff --git a/docs/images/kafka_log.png b/docs/images/kafka_log.png
diff --git a/docs/images/kafka_multidc.png b/docs/images/kafka_multidc.png
diff --git a/docs/images/kafka_multidc_complex.png b/docs/images/kafka_multidc_complex.png
diff --git a/docs/images/log_anatomy.png b/docs/images/log_anatomy.png
diff --git a/docs/images/log_cleaner_anatomy.png b/docs/images/log_cleaner_anatomy.png
diff --git a/docs/images/log_compaction.png b/docs/images/log_compaction.png
diff --git a/docs/images/mirror-maker.png b/docs/images/mirror-maker.png
diff --git a/docs/images/producer_consumer.png b/docs/images/producer_consumer.png
diff --git a/docs/images/tracking_high_level.png b/docs/images/tracking_high_level.png
diff --git a/docs/implementation.html b/docs/implementation.html
@@ -191,7 +191,7 @@ <h3><a id="log">5.5 Log</a></h3>
 <p>
 The use of the message offset as the message id is unusual. Our original idea was to use a GUID generated by the producer, and maintain a mapping from GUID to offset on each broker. But since a consumer must maintain an ID for each server, the global uniqueness of the GUID provides no value. Furthermore the complexity of maintaining the mapping from a random id to an offset requires a heavy weight index structure which must be synchronized with disk, essentially requiring a full persistent random-access data structure. Thus to simplify the lookup structure we decided to use a simple per-partition atomic counter which could be coupled with the partition id and node id to uniquely identify a message; this makes the lookup structure simpler, though multiple seeks per consumer request are still likely. However once we settled on a counter, the jump to directly using the offset seemed natural&mdash;both after all are monotonically increasing integers unique to a partition. Since the offset is hidden from the consumer API this decision is ultimately an implementation detail and we went with the more efficient approach.
 </p>
-<img src="../images/kafka_log.png">
+<img src="images/kafka_log.png">
 <h4>Writes</h4>
 <p>
 The log allows serial appends which always go to the last file. This file is rolled over to a fresh file when it reaches a configurable size (say 1GB). The log takes two configuration parameter <i>M</i> which gives the number of messages to write before forcing the OS to flush the file to disk, and <i>S</i> which gives a number of seconds after which a flush is forced. This gives a durability guarantee of losing at most <i>M</i> messages or <i>S</i> seconds of data in the event of a system crash.

diff --git a/docs/introduction.html b/docs/introduction.html
@@ -30,7 +30,7 @@ <h3><a id="introduction">1.1 Introduction</a></h3>
 
 So, at a high level, producers send messages over the network to the Kafka cluster which in turn serves them up to consumers like this:
 <div style="text-align: center; width: 100%">
-  <img src="../images/producer_consumer.png">
+  <img src="images/producer_consumer.png">
 </div>
 
 Communication between the clients and the servers is done with a simple, high-performance, language agnostic <a href="https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol">TCP protocol</a>. We provide a Java client for Kafka, but clients are available in <a href="https://cwiki.apache.org/confluence/display/KAFKA/Clients">many languages</a>.
@@ -40,7 +40,7 @@ <h4>Topics and Logs</h4>
 <p>
 A topic is a category or feed name to which messages are published. For each topic, the Kafka cluster maintains a partitioned log that looks like this:
 <div style="text-align: center; width: 100%">
-  <img src="../images/log_anatomy.png">
+  <img src="images/log_anatomy.png">
 </div>
 Each partition is an ordered, immutable sequence of messages that is continually appended to&mdash;a commit log. The messages in the partitions are each assigned a sequential id number called the <i>offset</i> that uniquely identifies each message within the partition.
 <p>
@@ -76,7 +76,7 @@ <h4><a id="intro_consumers">Consumers</a></h4>
 <p>
 
 <div style="float: right; margin: 20px; width: 500px" class="caption">
-  <img src="../images/consumer-groups.png"><br>
+  <img src="images/consumer-groups.png"><br>
   A two server Kafka cluster hosting four partitions (P0-P3) with two consumer groups. Consumer group A has two consumer instances and group B has four.
 </div>
 <p>

diff --git a/docs/ops.html b/docs/ops.html
@@ -98,7 +98,7 @@ <h4><a id="basic_ops_mirror_maker">Mirroring data between clusters</a></h4>
 
 We refer to the process of replicating data <i>between</i> Kafka clusters "mirroring" to avoid confusion with the replication that happens amongst the nodes in a single cluster. Kafka comes with a tool for mirroring data between Kafka clusters. The tool reads from one or more source clusters and writes to a destination cluster, like this:
 <p>
-<img src="/images/mirror-maker.png">
+<img src="images/mirror-maker.png">
 <p>
 A common use case for this kind of mirroring is to provide a replica in another datacenter. This scenario will be discussed in more detail in the next section.
 <p>