StarRocks Terminology Explained: Breaking Down the Acronyms One by One

A StarRocks research report is hard to read not because of the content but because of the acronym density: MPP, CBO, FE, CN, MoR, 2PC — two dozen pieces of jargon stewed together. This post unpacks them one by one, all anchored to a single picture: a restaurant that specializes in on-demand analytical answers. You run retail stores and want to ask, at year-end, "which distributor in East China sells the most personal-care products?" You throw that question into the restaurant and get the dish in seconds. The whole report is about how this restaurant is built.

A sense of scale first: a transaction table accumulates a billion rows a year — printed out, the stack would reach from the first floor to the third. An OLAP engine is the kitchen that can flip through that stack and find an answer in seconds.

1. The Three Umbrella Terms: OLAP, OLTP, MPP

• OLAP (On-Line Analytical Processing): the "ask-now-answer-now" business model itself. One query sweeps a wide swath — asking about annual sales means going through a whole year's ledger.
• OLTP (On-Line Transaction Processing): the flip-side sibling that handles "one row at a time" — a cashier ringing up an order, adjusting one inventory record. This is what ERP and POS systems do. One serves the boss's questions, the other the counter's pen.
• MPP (Massively Parallel Processing): multiple woks stir-frying at once. A big problem is cut into small pieces, ten machines each cook their share, and results are reassembled. Once the restaurant scales up, a single wok is doomed.

2. The Engine Trio: Vectorization, CBO, Pipeline

• Vectorized execution: the way the math is done. Old-style engines compute row by row; vectorized engines compute in batches, one column at a time — the CPU consumes a group of numbers per instruction, like a conveyor belt of trays. This single change often yields a several-fold difference.
• CBO (Cost-Based Optimizer): after the order comes in but before cooking starts, an experienced maitre d' decides "which pot first, which two pots share a burner." He estimates by cost — row counts, filter selectivity, which path requires moving data across machines — and picks the cheapest route. The older alternative is RBO (rule-based optimization): fixed rules, no regard for market conditions.
• Pipeline execution engine: assembly-line work. Data flows forward in small chunks like parts on a conveyor belt, never waiting for a full basket. The belt never stops. Query latency stays low, and hundreds of concurrent queries can run on the belt simultaneously.

3. Architecture Terms: FE, BE, CN, and the Ledger

• FE (Frontend): the maitre d'. Receives SQL, parses, plans, assigns work. Doesn't cook — just talks.
• BDBJE (Berkeley DB Java Edition): the replication library the FE leaders use to copy each other's ledgers. Metadata (where tables are, their schemas) is kept as one shared book, so no single departure loses the accounts.
• Follower / Observer: two kinds of deputies. Followers each hold a copy of the ledger and vote for a new leader if the current one falls; Observers only copy the ledger without voting, handling extra order traffic — scaling reads.
• BE (Backend): the stoves. The machines that actually store and compute data. A restaurant's size is measured by its stove count.
• Tablet: the smallest unit of data movement. A big table is split into small bricks, ideally 1–10 GB each — too big to move, too small and you're left with debris everywhere (metadata explosion).
• Storage-compute separation: the new store format since 3.0. Ingredients go into a central warehouse (object storage like S3/OSS), and the stoves are renamed CN (Compute Node) — cooking only, no stockpiling, keeping just a local fridge (Data Cache for hot data). Opening a new store requires no ingredient搬迁 — instant setup; central storage costs about a tenth of local SSD. JD Logistics publicly reported roughly 90% storage cost savings.
• StarOS: the official name for the scheduling, storage-access, and cache-management layer behind storage-compute separation.
• File Bundling in 4.0: small ingredient batches are packed into big boxes before entering the central warehouse, cutting object-storage API calls by roughly 90% (official figures).

4. Table Models: Four Bookkeeping Styles

• Duplicate (detail model): a raw ledger. Every row is recorded as-is, never merged. The backbone of auditing and tracing.
• Aggregate (aggregation model): a summary ledger. Pre-aggregated by key (e.g., distributor × product × day), with algorithms per metric column — sum for sales, max for inventory, replace for latest values. Fast to query; the cost is losing details, and changing metrics means rewriting the whole book.
• Unique (update model): an overwrite ledger. Same key, new row covers old. Its old implementation is MoR (merge-on-read) — keep old and new at write time, merge at query time; slow queries, predicates can't even be pushed down. The newer MoW (merge-on-write) resolves old values at write time. Doris has defaulted to MoW since 2.1. In short: MoR is lazy bookkeeping that torments auditors — no reason to choose it for new tables.
• Primary Key (PK) model: StarRocks' signature ledger. The primary key index lives in memory; new data checks memory first — if old exists, delete-then-insert, deduplicating on write. The first choice for real-time updates. The obvious cost: the PK index eats memory, so keep keys short — use integer surrogate keys, not long string composites.
• upsert: update + insert. Modify if present, insert if absent. One command, two outcomes.
• Partial update: change only certain columns, leave the rest untouched — e.g., hourly refreshes of a single in-stock quantity column.

5. Speed Terms: From Flipping Ledgers to Pre-made Dishes

• Prefix index: each ledger is pre-sorted (the sort key); the leading columns are the fastest way to flip through. If queries always filter by distributor, put distributor first. Set at table design time, hard to change later.
• Bitmap index: for low-cardinality columns — e.g., a dozen store formats. Each value gets a 0/1 string; the nth store's bit is 1 if it has that format. Lightning-fast equality filtering.
• Bloomfilter: for high-cardinality point lookups — order numbers, terminal IDs, millions of distinct values. Its temperament: "no" means definitely no; "yes" might be a false positive. Used to skip batches that "probably don't contain it."
• BITMAP exact distinct count: counting "how many stores sold" via bitmaps is an order of magnitude faster than pairwise comparison. Column type must be BITMAP.
• Partitioning: ledgers bound by month. Querying March pulls only March's book. Partition pruning is the fulfillment of that promise — irrelevant volumes are skipped entirely. TTL (Time To Live): each book's shelf life; expired ones are auto-recycled so the warehouse isn't strangled by prehistoric data.
• Bucketing: within each ledger, rows are hashed by key into different cabinets. Two benefits: more cabinets means more clerks searching in parallel; the same key always lives in the same cabinet (setting up the next term). Rule of thumb for bucket count: stoves × disks per stove, times 1–2.
• Colocate Join: two tables bucketed by the same key, locked into the same row of cabinets. When reconciling, cabinets open facing each other — no pushing ingredients across the store (shuffle-free). The constraint: both tables must have identical bucket counts; decide at table creation.
• Bucket Shuffle Join: at join time only one table is scattered to the other's cabinets by key — less hauling than all-to-all.
• Runtime Filter: cleverness in reverse. Before the big table finishes scanning, the join side already knows "East China only" and shouts back: "non-East-China rows, stop flipping!" Scan volume shrinks on the spot.
• Materialized View (MV): pre-made dishes. Frequently ordered dishes are prepared ahead; reorders are served instantly. Synchronous MVs refresh within the import transaction and cover single tables only. Asynchronous MVs (since 2.4) are far more capable — multi-table joins, scheduled refreshes, and partition-level incremental refresh (redo only the changed month). Query rewrite is its magic: you order fresh-cooked, but the kitchen finds the same dish already plated — served instantly, and you never notice except on the bill.

6. Loading Terms: How Goods Enter the Warehouse

• Stream Load: HTTP batch receiving. The distributor's daily hand-made file, pushed in with one shove.
• Routine Load: a standing subscription. Hooked to a Kafka stream; goods auto-unload on arrival, never stopping.
• Broker Load: bulk-moving history from big warehouses like data lakes or HDFS.
• Flink Connector: the conveyor belt between the Flink stream engine and StarRocks — the main force of real-time loading.
• 2PC exactly-once (two-phase commit): the conveyor belt can lose power without losing or duplicating goods. First ask "is everyone ready?" — only after unanimous nodding is the entry committed; a mid-way crash rolls everything back. For inventory numbers, one duplicate is an incident; this is what prevents it.

7. Misc: Profile, TPC-DS, External Catalog

• Profile: the health report of a query — every step's timing laid out plainly. Tuning isn't mysticism; it's reading the report: did partition pruning hit, did the join flow, did the MV rewrite fire, is parallelism sufficient.
• TPC-DS: the industry's standardized mock exam (TPC's Decision Support benchmark), dozens of business-analytics questions, engines queuing up to compare total scores. The 4.0 claim of ~60% speedup over the previous generation is the score on this exam.
• External catalog: hanging a nameplate on data lakes like Iceberg or Hive and querying them directly without moving data. This is how five years of cold detail in the lake gets queried.
• Iceberg: an open table format on object storage, the current standard of lakehouse architecture.
• ClickHouse: another engine lineage — terrifyingly fast single-table queries, but joins and high concurrency are weaknesses. Doris: StarRocks' sibling from the same origin; they split in 2020 and grew into different trees.

8. Closing

Thirty-odd acronyms, unpacked into just this much: one front desk and several stoves, four ledgers, a handful of ledger-flipping tricks, a few supply channels. Next time someone throws acronyms around in a review meeting, ask them to speak plainly — if they can't, they haven't unpacked them either.

A previous series covers another set of terms (ODS/DWD/DWS/DIM, SCD, fact tables) in the plain-language posts on data warehouse layering and slowly changing dimensions — not repeated here.