Continuing image cleanup

basics/architecture.md

@@ -34,7 +34,7 @@ As described in [Apache Pinot™ Concepts](concepts.md), Pinot has four node typ
 * [Server](components/cluster/server.md)
 * [Minion](components/cluster/minion.md)
 
-![](<../.gitbook/assets/Pinot-architecture (1).svg>)
+![](<../.gitbook/assets/Pinot-architecture.svg>)
 
 ### Apache Helix and ZooKeeper
 
@@ -177,7 +177,7 @@ Offline servers host segments created by ingesting batch data. The controller wr
 
 Because offline tables tend to have long retention periods, offline servers tend to scale based on the size of the data they store.
 
-![](<../.gitbook/assets/OfflineServer (4).jpg>)
+![](<../.gitbook/assets/OfflineServer.jpg>)
 
 
 #### Real-time servers
@@ -202,7 +202,7 @@ Pinot [tables](components/table/) exist in two varieties: offline (or batch) and
 
 ### Offline (batch) ingest
 
-![](<../.gitbook/assets/OfflineServer (4).jpg>)
+![](<../.gitbook/assets/OfflineServer.jpg>)
 
 Pinot ingests batch data using an [ingestion job](data-import/batch-ingestion/), which follows a process like this:
 

basics/components/cluster/server.md

@@ -11,7 +11,7 @@ Servers host the data segments and serve queries off the data they host. There a
 **Offline**\
 Offline servers are responsible for downloading segments from the segment store, to host and serve queries off. When a new segment is uploaded to the controller, the controller decides the servers (as many as replication) that will host the new segment and notifies them to download the segment from the segment store. On receiving this notification, the servers download the segment file and load the segment onto the server, to server queries off them.
 
-![](<../../../.gitbook/assets/OfflineServer (4).jpg>)
+![](<../../../.gitbook/assets/OfflineServer.jpg>)
 
 **Real-time**\
 Real-time servers directly ingest from a real-time stream (such as Kafka or EventHubs). Periodically, they make segments of the in-memory ingested data, based on certain thresholds. This segment is then persisted onto the segment store.

basics/indexing/star-tree-index.md

@@ -262,7 +262,7 @@ The star-tree and documents should be something like below:
 
 The values in the parentheses are the aggregated sum of _Impressions_ for all the documents under the node.
 
-![](../../.gitbook/assets/example.png)
+![](../../.gitbook/assets/startree-example.png)
 
 **Star-tree documents**
 

operators/operating-pinot/instance-assignment.md

@@ -16,7 +16,7 @@ There are 3 types of instances for the InstanceAssignmentConfig: `OFFLINE`, `CON
 
 The default instance assignment strategy simply assigns all the servers in the cluster to each table, and uses the [Balanced Segment Assignment](segment-assignment.md#balanced-segment-assignment) for the table. This strategy requires no extra configurations for the cluster, and it works well for small clusters with few tables where all the resources can be shared among all the tables.
 
-![](../../.gitbook/assets/default.png)
+![](../../.gitbook/assets/default-instance-assignment.png)
 
 ## Tag-Based Instance Assignment
 

reference/single-stage-engine.md

@@ -6,4 +6,4 @@ description: An overview of the single-stage query engine.
 
 The Pinot single-stage query engine (v1) uses a scatter-gather query engine model, shown in the following diagram. In certain cases, for example, if you need to query using JOINs on large data sets, the [multi-stage query engine (v2)](multi-stage-engine.md) may be a more performant option. 
 
-<figure><img src="../.gitbook/assets/Multi-Stage-Pinot-Query-Engine-v1 (2).png" alt=""><figcaption><p>Single-stage query engine (v1)</p></figcaption></figure>
+<figure><img src="../.gitbook/assets/Multi-Stage-Pinot-Query-Engine-v1.png" alt=""><figcaption><p>Single-stage query engine (v1)</p></figcaption></figure>