Xinchuang Compatibility: Hengshi BI's Full-Stack Domestic Technology Practice

Article body

Full article

12 min read

Introduction

Critical industries in China, including finance, government, energy, and defense, continue to adopt Xinchuang, the country’s information-technology application innovation program. Xinchuang promotes an independently controlled technology stack across processors, operating systems, databases, and middleware to protect critical information infrastructure.

For a BI platform, Xinchuang compatibility creates concrete engineering requirements. The system must run on domestic processors and operating systems, connect reliably to domestic databases, and deliver complete functionality within domestic middleware environments.

Hengshi BI has completed full-stack Xinchuang compatibility work from processors and operating systems to databases and middleware, creating a reusable domestic deployment model. This article describes the engineering practices behind that system.

1. Technical Challenges in Xinchuang Compatibility

1.1 Why BI Compatibility Is Complex

An application written in Java or Go may require changes to run across Linux distributions and processor architectures. BI platforms also depend on drivers, system libraries, computing components, and application servers.

CPU instruction-set differences

Kunpeng and Phytium processors use the ARM architecture, while Hygon and Zhaoxin use x86. A C++ extension or machine-learning inference library built only for x86 cannot run in an ARM environment.

Operating-system compatibility

Kylin and UnionTech OS are Linux-based, but their kernels, glibc releases, and system-library versions can differ from general-purpose distributions. Components that depend on specific system calls or library versions require separate validation.

Database drivers and SQL dialects

DM, KingbaseES, OceanBase, GaussDB, and TiDB differ in their JDBC or ODBC drivers, SQL dialects, type mappings, and transaction behavior. A BI platform must validate each database at its connection layer.

Middleware replacement

Some Xinchuang environments require domestic middleware such as TongTech TongWeb or Bessystem BES. The BI deployment must support their data-source configuration, session sharing, and logging mechanisms.

1.2 Compatibility Levels

Xinchuang compatibility can be divided into three levels:

L1, runnable: The system starts on a domestic processor and operating system, and basic functions work.
L2, production-ready: Core functions are complete and performance approaches a general-purpose x86 environment.
L3, full stack: Data sources, caches, message queues, and other parts of the data path also use domestic alternatives.

Hengshi targets a complete L3 solution.

2. Hengshi BI’s Xinchuang Compatibility Architecture

2.1 Processor Layer

Core computing components such as query acceleration and vectorized execution require builds for each processor architecture.

ARM architecture, including Kunpeng 920 and Phytium FT-2000+

Build core components for ARM64.
Optimize vectorized execution for ARM NEON SIMD instructions.
In tests on Kunpeng 920, query performance reached 85% to 92% of an x86 processor at the same clock speed.

x86 architecture, including Hygon C86 and Zhaoxin

Reuse the AVX optimization path for x86.
Tests on Hygon C86 produced performance close to comparable Intel processors.

Hengshi follows a single-source, multi-architecture build model. CI produces separate ARM64 and x86_64 images while the team maintains one codebase and two build configurations.

2.2 Operating-System Layer

Kylin V10

Tune kernel parameters such as file-descriptor limits and network-stack settings.
Align system-library dependencies.

UnionTech OS

Adapt systemd service registration.
Validate the permission model under UOS security modules.

Hengshi BI uses Docker or Kubernetes containers. Containers reduce user-space differences, leaving most operating-system work at the host-kernel and container-runtime boundaries.

2.3 Database Layer

Database connectivity accounts for a large share of the compatibility work.

DM8

Adapt the JDBC driver class and connection string.
Validate its Oracle-compatible dialect and features such as hierarchical queries.
Verify the mapping from types such as NUMBER and VARCHAR2 to Hengshi BI’s internal types.

KingbaseES

Reuse PostgreSQL protocol compatibility.
Handle extended types such as GIS data.

OceanBase

Support both MySQL-compatible and Oracle-compatible modes.
Configure OBProxy routing for the distributed architecture.

GaussDB

Reuse PostgreSQL protocol compatibility.
Optimize query pushdown for distributed tables using Hash and Range distribution.

TiDB

Reuse MySQL protocol compatibility.
Tune large-table joins for TiDB’s distributed execution plans.

Hengshi maintains a compatibility test matrix for each database. It covers connections, basic queries, aggregations, window functions, data types, transactions, and permissions. The team reruns this matrix after a database upgrade.

2.4 Middleware Layer

Hengshi BI supports environments based on domestic application servers such as TongWeb and BES. The main compatibility areas include:

Data-source configuration through JNDI or direct settings.
Session sharing in clustered deployments.
Log formats for domestic logging platforms.

For caches and message queues, the system can use Redis-compatible products such as Tendis and can run asynchronous tasks through RocketMQ.

3. Performance Optimization in Xinchuang Environments

3.1 Performance Benchmarks

Hengshi compared Xinchuang environments with Intel x86 using the same core count and memory.

Workload	Intel x86	Kunpeng 920 (ARM)	Hygon C86 (x86)
Single-table aggregation, 10 million rows	1.2s	1.4s	1.3s
Three-table join	3.5s	4.1s	3.8s
Dashboard load, eight charts	0.9s	1.1s	1.0s
Concurrent queries, 50 QPS	Stable	Stable	Stable

The tested Xinchuang environments remained within a 10% to 20% performance difference, sufficient for common enterprise analytics workloads.

3.2 Optimizations for Domestic Hardware

ARM memory access: Hengshi adjusts query-engine memory alignment for the cache characteristics of ARM processors, reducing cache misses.

Domestic NVMe I/O: Data prefetch and concurrent I/O settings are tuned for the storage controllers used in domestic servers.

Kunpeng NUMA affinity: On multi-socket Kunpeng servers, query processes are bound to nearby NUMA nodes, reducing cross-node memory access.

3.3 Domestic OLAP Engines

Hengshi supports several domestic OLAP engines in Xinchuang environments:

StarRocks can provide a query-acceleration layer.
Apache Doris suits medium-scale analytics.
TiDB suits HTAP workloads.

Projects with strict full-stack requirements can combine a domestic database with StarRocks or Doris to create a domestic data path.

4. Reference Deployment Architectures

4.1 Standard Architecture

A financial institution can use the following Xinchuang deployment:

Hardware: Three dual-socket, 64-core Kunpeng 920 servers, with one primary node and two worker nodes.

Operating system: Kylin V10.

Database layer:

An existing DM8 database supplies business data.
StarRocks runs on the Xinchuang servers as the analytics-acceleration layer.

Middleware: TongTech TongWeb.

BI layer: Hengshi BI runs in containers on a domestic Kubernetes distribution.

This combination uses domestic core components from the processor through the BI application.

4.2 Hybrid Architecture During Migration

Some customers still run core systems on x86 and Oracle while adopting a domestic stack for new systems. Hengshi supports a staged migration:

The BI platform runs in the Xinchuang environment.
Data sources include domestic databases such as DM as well as existing databases such as Oracle.
Hengshi data integration synchronizes Oracle data to StarRocks, which provides a shared analytics layer.

The customer can migrate in stages while existing systems remain in service.

4.3 Certification and Compliance

Hengshi BI has completed compatibility certification with several parts of the Xinchuang ecosystem:

Kylin and UnionTech operating systems.
Kunpeng and Phytium processors.
DM, KingbaseES, and OceanBase databases.
Xinchuang product catalogs used by government and enterprise customers.

Compatibility certification requires product testing, performance validation, and security scanning, giving project teams concrete compatibility evidence during vendor selection.

5. Xinchuang Project Implementation

5.1 Compatibility Checklist

Before implementation, a project team can validate the following items:

Confirm the CPU architecture and select the matching image.
Confirm the operating-system version and tune kernel parameters.
Confirm the database type and version, then run the compatibility matrix.
Confirm the middleware replacement plan.
Benchmark performance against the existing environment.
Run the security scan required by the project.

5.2 Common Problems

Testing only whether the system starts

A successful launch on Kylin does not prove complete compatibility. PDF export can fail because of missing fonts, and scheduled tasks can fail because of an incorrect systemd unit.

Remedy: Validate core queries and the complete feature matrix.

Ignoring execution-plan differences in domestic databases

A complex report that performs well on Oracle can slow down after migration to DM because of different join ordering or execution plans.

Remedy: Compare SQL performance before migration and tune slow queries through indexes and SQL rewrites.

Limited operations experience with the Xinchuang stack

Monitoring and logging tools can differ from those used in a general-purpose environment.

Remedy: Train the operations team early and prepare integrations for domestic APM and logging platforms.

6. Summary

Xinchuang compatibility for a BI platform spans processor architecture, operating systems, databases, middleware, deployment, and operations. Hengshi BI uses three main strategies:

Full-stack coverage from processors and operating systems to databases, middleware, and the data path.
Containers to reduce environmental differences, concentrating compatibility work at database, computing-engine, and host boundaries.
Evidence through testing, including multi-architecture builds, database compatibility matrices, and performance benchmarks.

Enterprises can use this approach to build an independently controlled data platform from the underlying hardware to the analytics application.