Cloud-Native Architecture for BI Platforms: Technical Evolution from Containerization to Elastic Scaling

Introduction

As BI platforms evolve from “an internal enterprise tool” to “infrastructure embedded in dozens of business systems,” the architecture faces entirely new technical challenges: how to support 200+ tenant concurrent queries? How to auto-scale during traffic peaks? How to complete version upgrades without interrupting service? How to maintain data consistency across multi-region deployments?

The answer to all these questions points to the same technical direction: cloud-native architecture.

HENGSHI SENSE’s cloud-native architecture provides an elastically scalable, zero-downtime upgradeable, and multi-region deployable technical foundation for BI platforms through containerized deployment, microservices decomposition, elastic scaling, and DevOps automation. This article provides an in-depth analysis of BI platform cloud-native architecture design from three dimensions: architecture evolution, core technologies, and operational practices.

---

1. Evolution from Traditional Deployment to Cloud-Native Architecture

1.1 Four Major Bottlenecks of Traditional BI Deployment

Bottleneck 1: Single-Point Performance Ceiling

Traditional BI deployment typically uses a monolithic architecture — all functional modules (data connections, query engines, visualization rendering, and permission management) run in the same application process. When concurrent query volume grows, the single node’s CPU and memory become performance bottlenecks, with no way to scale horizontally by adding nodes.

Bottleneck 2: Low Scaling Efficiency

Traditional deployment scales by “vertical scaling” — increasing the CPU core count and memory capacity of a single node. This approach has two problems: costs grow non-linearly with specifications (high-end servers cost far more than low-end ones), and scaling requires downtime and restart, making “on-demand instant scaling” impossible.

Bottleneck 3: Version Upgrade Service Interruption

Traditional deployment version upgrades typically require downtime — stopping service, replacing binary files, executing database migration scripts, and restarting service. In an embedded BI scenario, BI feature downtime means dozens of dependent business systems are simultaneously affected — upgrade windows can only be arranged in the early morning hours, leaving the operations team exhausted.

Bottleneck 4: Complex Multi-Region Deployment

For BI platforms needing deployment across multiple regions (e.g., multinational enterprises needing independent instances in different countries/regions), traditional deployment requires maintaining a complete independent operations system for each region — inconsistent configurations, out-of-sync versions, and non-interoperable data are common problems.

1.2 Core Characteristics of Cloud-Native Architecture

Cloud-native architecture solves the bottlenecks of traditional deployment through four core technical characteristics:

Characteristic	Technical Implementation	Bottleneck Solved
Containerization	Docker/Kubernetes	Environment consistency, rapid deployment
Microservices	Independent deployment of functional modules	Horizontal scaling, independent upgrades
Elastic Scaling	HPA/VPA automatic scaling	Auto-scaling during traffic peaks
DevOps	CI/CD pipeline	Zero-downtime upgrades, automated operations

---

2. Containerized Deployment Architecture

2.1 Containerization Technology Selection

HENGSHI SENSE’s containerized deployment is based on the Kubernetes (K8s) container orchestration platform:

Container Image Strategy

Each HENGSHI SENSE module is built as an independent Docker image, containing the runtime environment, dependency libraries, and application code. Images are managed through a private image repository, supporting version tags and rollback.

Image building follows the “layered caching” principle — the base layer (operating system, runtime environment) changes infrequently, while the application layer updates frequently. This strategy significantly reduces image build time and push size.

Pod Design

Each HENGSHI SENSE module runs as a K8s Pod, with Pod design following these principles:

• Single-container Pod: each Pod runs only one container, simplifying management and monitoring
• Resource declarations: each Pod declares CPU and memory requests and limits, ensuring predictable resource allocation
• Health checks: liveness probe and readiness probe configured to ensure Pod availability

2.2 Module Decomposition Strategy

HENGSHI SENSE’s microservices decomposition follows the “functional cohesion” principle — each microservice is responsible for one independent functional domain:

Core Microservices

Microservice	Functional Domain	Scaling Strategy
Data Connection Service	Data source management, connection pooling	Scale by connection count
Query Engine Service	SQL generation, execution, result return	Scale by QPS
Semantic Layer Service	HQL parsing, semantic matching	Scale by ChatBI query volume
Visualization Service	Chart rendering, dashboard layout	Scale by dashboard access volume
Permission Service	Authentication, authorization, tenant isolation	Scale by user activity
Audit Service	Operational log recording	Scale by operation volume

Each microservice can scale independently — when the load on the Query Engine Service increases, only the number of Query Engine Pods is increased without affecting other services. This “on-demand scaling” capability is the core advantage of cloud-native architecture.

2.3 Containerization of Data Engines

Containerization of data engines (such as Apache Doris and Greenplum) is a special challenge for BI platform cloud-native architecture — data engines typically require persistent storage and high IO performance, differing from the containerization strategy of stateless microservices:

Containerization of Stateful Services

Data engines are deployed as StatefulSets, ensuring each instance has a stable network identifier and persistent storage. Storage uses K8s PersistentVolumeClaim (PVC) mechanism; data is persisted in independent storage volumes and is not lost after Pod reconstruction.

Storage Performance Guarantee

Data engines have high requirements for storage IO performance. When deploying, StorageClass is configured to select high-performance storage types:

• SSD storage: provides high IOPS and low latency
• Network storage: supports multi-node shared access, suitable for distributed engines
• Local storage: provides the highest IO performance but does not support Pod migration

---

3. Elastic Scaling Mechanism

3.1 Horizontal Pod Autoscaler (HPA)

HENGSHI SENSE’s elastic scaling is based on K8s’ Horizontal Pod Autoscaler (HPA):

Scaling Metrics

HPA automatically adjusts Pod counts based on the following metrics:

• CPU utilization: automatically scales out when CPU utilization exceeds the threshold (e.g., 70%)
• Memory utilization: automatically scales out when memory utilization exceeds the threshold
• Custom metrics: scaling based on business metrics (such as QPS, active connection count)

Scaling Strategy

Microservice	Scaling Metric	Min Pods	Max Pods	Scale-Out Threshold
Query Engine	QPS + CPU	2	20	QPS>50 or CPU>70%
Semantic Layer	ChatBI Query Volume	1	10	Query Volume>20
Visualization	Dashboard Access Volume	2	15	Access Volume>100
Permission	User Active Count	1	5	Active Count>500

Scaling Cooldown Period

To avoid frequent scaling (thrashing), a scaling cooldown period is configured — after a scale-out operation, wait 5 minutes before evaluating whether further scaling is needed; after a scale-in operation, wait 10 minutes before evaluating.

3.2 Traffic Peak Response Strategies

Pre-Scaling

For predictable traffic peaks (such as end-of-month report generation and quarterly business analysis), the system supports “scheduled pre-scaling” — scaling up in advance before the peak arrives, avoiding performance degradation due to scaling delays during peak periods.

Request Queuing and Rate Limiting

When traffic exceeds the system’s carrying capacity, the system automatically initiates rate limiting:

• Low-priority queries are queued and wait
• High-priority queries are executed first
• Requests exceeding the queuing threshold return a “system busy” message

Rate limiting ensures that even in extreme traffic scenarios, the system will not crash — instead, it handles as many requests as possible at an acceptable response time.

3.3 Multi-Region Elastic Deployment

For scenarios requiring multi-region deployment, HENGSHI SENSE supports a “center-edge” architecture:

Center Node

A complete HENGSHI SENSE instance deployed in the central data center, responsible for:

• Global configuration management
• Tenant creation and management
• Global audit data aggregation
• Cross-region data analysis

Edge Node

A lightweight HENGSHI SENSE instance deployed in each region, responsible for:

• Regional data query and visualization
• Regional ChatBI service
• Data caching and pre-computation

Edge nodes synchronize configuration and audit data with center nodes through APIs, ensuring consistency across multi-region deployments.

---

4. Zero-Downtime Upgrades and DevOps

4.1 Rolling Updates

HENGSHI SENSE’s version upgrades adopt K8s’ Rolling Update strategy:

Update Process

1. New-version Pods are created and started
2. Readiness probe verifies new Pod is ready
3. Old-version Pods gracefully stop (waiting for in-progress requests to complete)
4. Traffic gradually switches from old Pods to new Pods
5. Old Pods are completely stopped and deleted

The entire process is transparent to users — users do not perceive service interruption, and query requests may experience brief response time fluctuations during the upgrade process but will not fail.

Rollback Mechanism

If a new version is found to have problems after launch (such as incorrect query results or performance degradation), the system supports one-click rollback — switching the Pod image version back to the previous version, with K8s automatically executing the rolling update process to restore the service to the previous version.

Rollback response time is typically 3-5 minutes — from triggering the rollback to all Pods being restored to the old version. This capability is the core operational advantage of cloud-native architecture over traditional deployment.

4.2 Database Migration Strategy

Database Schema migration during version upgrades is the most complex环节 — needing to complete table structure changes without downtime:

Compatible Migration

Database changes in new versions must be compatible with old versions — both old-version and new-version code can correctly operate the database during migration. This requirement limits database change methods:

• Only add new columns, do not delete or rename existing columns
• Default values for new columns must be compatible with old-version code logic
• Do not modify existing column data types (achieve type changes through adding new columns + data migration)

Phased Migration

Database migration is divided into multiple phases:

1. Add columns (with default values) — both old and new versions work normally
2. Data backfill — calculate and write old column data according to new logic into new columns
3. Code switch — application starts using new columns
4. Old column cleanup — after ensuring new column data is correct, clean up old columns (can be executed in subsequent versions)

4.3 CI/CD Pipeline

HENGSHI SENSE’s continuous delivery pipeline:

Build Stage

• Code commit triggers automatic build
• Unit tests and integration tests
• Docker image build and push

Test Stage

• Automatically deploy new image in test environment
• Automated end-to-end tests
• Performance benchmark tests

Release Stage

• Canary release — deploy new version to 1-2 Pods first, observe for 1 hour
• Gradual rollout — if no anomalies in canary stage, gradually rollout new version to all Pods
• Full release — all Pods updated, old version cleanup

Monitoring Stage

• Continuously monitor key metrics (error rate, response time, resource utilization) after new version goes live
• Anomaly auto-alert — trigger rollback evaluation

---

5. High Availability and Disaster Recovery

5.1 Multi-Replica High Availability

Each microservice deploys at least 2 replicas — when one Pod fails, K8s automatically switches traffic to healthy Pods while starting new Pods to replace failed Pods. The entire failover process completes at the second level, with users barely perceiving it.

5.2 Cross-Availability-Zone Deployment

In cloud platform multi-availability-zone (AZ) deployment scenarios, HENGSHI SENSE’s Pods are distributed across multiple AZs — when an AZ fails, Pods in other AZs continue to provide service. This deployment strategy ensures that even in cloud platform infrastructure-level failures, the BI platform remains available.

5.3 Data Backup and Recovery

Data Engine Backup

Data engine data is backed up through the following strategies:

• Scheduled snapshots: automatically create data snapshots every hour, retaining the last 24 hours
• Daily full backup: perform full backup at midnight daily, retaining 30 days
• Cross-region backup: critical data synchronously backed up to remote backup storage

Configuration Backup

HENGSHI SENSE configurations (dataset definitions, metric definitions, dashboard configurations, permission rules) are stored as structured data in the database and backed up through the database’s backup mechanism. Configuration recovery operations can be completed within minutes.

---

6. Monitoring System for Cloud-Native Architecture

6.1 Three-Layer Monitoring

Infrastructure Layer Monitoring

Monitor K8s cluster node resource utilization — CPU, memory, disk, network. When resource utilization remains consistently high, trigger cluster scaling (adding nodes).

Microservice Layer Monitoring

Monitor each microservice’s health status and performance metrics:

• Pod status (Running/Pending/Failed)
• QPS and response time
• Error rate and error type distribution
• Resource utilization (CPU, memory)

Business Layer Monitoring

Monitor key business metrics for the BI platform:

• Active user count and query volume
• ChatBI match success rate and adoption rate
• Dashboard access volume and loading time
• Tenant-level resource utilization and performance metrics

6.2 Alerting Strategy

Alerts are based on SLO (Service Level Objective) definitions:

• Query response time P99 > 5 seconds → Alert
• Query error rate > 1% → Alert
• Pod failure rate > 5% → Alert
• Data engine disk usage > 80% → Alert

Alerts are pushed in real-time through instant messaging tools (WeCom, Feishu, DingTalk), ensuring the operations team perceives anomalies at the first moment.

---

7. Implementation Recommendations

7.1 Cloud-Native Migration Path

Phase	Core Objective	Key Tasks	Estimated Duration
Phase 1	Containerized deployment	Docker image build, K8s cluster setup, basic deployment	2-3 weeks
Phase 2	Microservices decomposition	Functional module decomposition, independent deployment, service discovery	4-6 weeks
Phase 3	Elastic scaling	HPA configuration, monitoring system, alerting strategy	2-3 weeks
Phase 4	DevOps	CI/CD pipeline, automated testing, zero-downtime upgrades	3-4 weeks

7.2 Cloud-Native Applicability Assessment

Cloud-native architecture is not the best choice for all scenarios. The following assessment matrix can help determine applicability:

Scenario	Cloud-Native Applicability	Recommendation
Multi-tenant SaaS	Highly applicable	Strongly recommended
High-concurrency queries	Highly applicable	Strongly recommended
Heavy regulation/private deployment	Moderately applicable	Containerized deployment + local cluster
Small-scale/low-concurrency	Low applicability	Traditional deployment is sufficient
Requires elastic scaling	Highly applicable	Strongly recommended

---

Conclusion

The value of cloud-native architecture for BI platforms is not “using K8s makes you advanced,” but truly solving the three bottlenecks that traditional deployment cannot break through: “elastic scaling, zero-downtime upgrades, and multi-region deployment.”

When BI platforms evolve from “one system” to “infrastructure embedded in dozens of business systems,” their architectural reliability and scalability are no longer just the concerns of the technical team — they directly impact the availability of dozens of business systems and the daily work experience of hundreds of thousands of users.

HENGSHI SENSE’s cloud-native architecture, through its four-layer technical system of containerization, microservices, elastic scaling, and DevOps, provides BI platforms with an elastically scalable, zero-downtime upgradeable, and multi-region deployable technical foundation. The core design philosophy of this foundation is: making the operational complexity of BI platforms transparent to ISVs and end users — what they perceive is “always available, always fast” service, not the technical complexity behind it.

Good architecture is not about showing off technology — it’s about making complexity disappear below the waterline. This is the true value of cloud-native architecture for BI platforms.