Jack
fa95a70656
### What problem does this PR solve? Issue Number: None Related PR: #66052 Problem Summary: SNII shipped before its metadata messages reached upstream, and the version upstreamed in #66052 had INSERTED fields in the middle of two of them rather than appending. protobuf identifies a field by its tag, so the two layouts now disagree about what a tag means, and every SNII segment already written decodes incorrectly under the upstream numbering: SniiStatsPB shipped upstream (#66052) tag 4 null_count sum_total_term_freq tag 5 -- null_count SniiSectionRefsPB shipped upstream (#66052) tag 3 null_bitmap norms tag 4 bsbf null_bitmap tag 5 -- bsbf Neither misread fails. SniiStatsPB tags 4 and 5 are both uint64, so a null count is returned as the collection token sum and feeds avgdl -- a plausible wrong number with no error anywhere. In SniiSectionRefsPB the null bitmap's offset/length is taken for the norms region and bsbf is lost entirely. This PR renumbers both messages back to the shipped layout and appends the two upstream additions after it: sum_total_term_freq becomes 5 and norms becomes 5 in their respective messages. SniiCommonGramsMetadataPB needed no change -- its upstream fields 8-12 were appended, which is the shape every future addition must follow. A new case set asserts the field numbers through protobuf reflection rather than through a byte digest, so the next accidental insert fails with a message naming the field and both tags instead of an opaque checksum mismatch. The twelve SniiWriterGoldenBytes digests were RE-HARVESTED: field tags and the field-number ordering are part of the serialized Core metadata that every SNII segment carries, so all of them moved -- including kGoldenKeywordDocsOnly, whose index has neither norms nor a null bitmap. That one moving is the evidence the change reaches every segment shape rather than one lane. COMPATIBILITY: this changes how existing bytes decode, deliberately. Segments written by an upstream build carrying #66052 are not readable afterwards and must be rebuilt; the format is not yet released upstream, so that population is development data only. Segments written by the shipped build become readable, which is the point.
🌍 Read this in other language
English • العربية • বাংলা • Deutsch • Español • فارسی • Français • हिन्दी • Bahasa Indonesia • Italiano • 日本語 • 한국어 • Polski • Português • Română • Русский • Slovenščina • ไทย • Türkçe • Українська • Tiếng Việt • 简体中文 • 繁體中文
?style=for-the-badge){kind=icon}
?style=for-the-badge){kind=icon}
Apache Doris is an open-source, real-time analytics and search database built on MPP architecture. It provides fast SQL analytics, lakehouse query acceleration, and hybrid search across structured, text, and vector data.
Explore the official website for the latest product overview, use cases, ecosystem updates, blogs, and user stories. For version updates, see all release notes.
📈 Use Cases
| Use Case | What it provides |
|---|---|
| Customer-Facing Analytics | Ship sub-second interactive analytics to external users. |
| Data Warehousing | Build one real-time warehouse across business domains. |
| Observability | Analyze high-throughput logs, events, and metrics with SQL. |
| Doris for AI | Use vector, text, JSON, and structured search in one SQL engine. |
🚀 Core Capabilities
Apache Doris is built around three core capabilities. The website is the source of truth for detailed product descriptions and examples.
| Capability | What it provides |
|---|---|
| Real-Time Analytics | Streaming ingestion, incremental transformation, and sub-second queries under high concurrency. |
| Lakehouse Analytics | Fast SQL analytics over open table formats such as Iceberg, Delta Lake, and Hudi. |
| Hybrid Search | SQL-native analytics across JSON, full-text, and vector data for AI and search workloads. |
🔌 Ecosystem
Doris sits at the center of the modern data stack. It connects upstream databases, streaming systems, and lakehouse storage with downstream BI, AI, analytics, and observability tools.
For the latest ecosystem coverage, visit the official website and the connection and integration documentation.
👣 Get Started
🧱 Architecture
Apache Doris supports both compute-storage coupled and compute-storage decoupled deployments. In decoupled mode, stateless compute groups run over shared object storage, so you can scale compute on demand and isolate workloads.
Learn more in the deployment guide and deployment mode guide.
📣 Project Updates
| Resource | What it provides |
|---|---|
| Community Report | Weekly updates on community activity, merged PRs, contributors, and feature progress. |
| Roadmap 2026 | The 2026 planning discussion for AI and hybrid search, query engine, storage, and data lake work. |
🧩 Components
Doris provides connectors and tools for common data engineering workflows.
- Doris Flink Connector
- Doris Spark Connector
- Doris Kafka Connector
- Doris Stream Loader
- Doris Kubernetes Operator
👨👩👧👦 Users
Apache Doris is used in production by thousands of companies worldwide across internet services, finance, retail, logistics, manufacturing, energy, telecommunications, AI, and other industries.
🙌 Contributors
Apache Doris graduated from the Apache Incubator and became an Apache Top-Level Project in June 2022. Thanks to all community contributors who help build Doris.
🌈 Community and Support
💬 Contact Us
🧰 Links
- Apache Doris official website: doris.apache.org
- X: @doris_apache
- Medium: @ApacheDoris
📜 License
Note
Some licenses of the third-party dependencies are not compatible with Apache 2.0 License. So you need to disable some Doris features to comply with Apache 2.0 License. For details, refer to the
thirdparty/LICENSE.txt