Article body
Full article
Enterprise dashboards often connect sales, inventory, production, and finance data at the same time. Users opening a page see a single wait, while data teams face multiple stages: source database execution, joins, metric calculations, result transfer, and frontend rendering. Keeping analytics usable as the business grows requires designing these stages as one architecture.
HENGSHI SENSE connects multiple data sources, dataset modeling, HQL metric expressions, query execution, and visual delivery. Enterprises can retain their existing databases and data warehouses, select direct connections or acceleration paths according to business needs, and coordinate query workloads through caching, update schedules, and resource configuration. HENGSHI’s performance capabilities are therefore reflected in how the entire analytics pipeline is organized.
1. Unify Business Calculations with HQL and Execute Queries Close to the Data
The same “net sales” metric may appear in an executive dashboard, a regional report, and a natural-language data question. If every entry point maintains its own SQL, teams must repeatedly write aggregation logic while separately handling database dialects, relationships, and time conditions. HENGSHI uses datasets and relationship models to describe fields and joins, expresses aggregation, filtering, grouping, and time calculations in HQL, and translates queries into a form executable by the target data source.
This approach lets analysts work around business metrics while allowing databases to continue using their own execution capabilities. Filters and aggregations that can run at the source can reduce the transfer of irrelevant detail records. Business users can reuse the same metric meaning when switching between regions, products, and months. Function support differs across data sources, so implementation teams select query paths and calculation methods accordingly.
2. Choose Direct Connections or Acceleration Engines for Different Workloads
Direct-connect datasets send queries to the original data source. This suits scenarios that require the latest source records or where an existing warehouse can handle the analytics workload. Enterprises using analytical databases such as ClickHouse, StarRocks, or Apache Doris can reuse their existing compute infrastructure through the corresponding connections.
When a dataset’s acceleration engine is enabled, the system imports data into an engine table, which subsequent queries access. Depending on the deployment plan, enterprises can select engine configurations such as Greenplum, StarRocks, or Apache Doris, using dedicated analytics resources for repeated aggregation and prepared cross-source analysis. Suitable configurations vary with the data source, data volume, and required functions.
| Execution path | Main capability | Scenarios to evaluate first |
|---|---|---|
| Direct connection | Reuse source-side compute and the latest records | Real-time business queries; an existing high-performance warehouse; data that should not be copied |
| Acceleration engine | Query datasets after importing them into an analytical engine | Repeated multidimensional aggregation; prepared analysis combining different sources |
| Update schedules | Configure scheduling, dependencies, retries, priorities, and alerts | Update engine data at an agreed cadence and track completion times |
The acceleration path also includes data updates. Data administrators can maintain engine tables through immediate updates or update schedules and organize dataset updates by dependency. Query speed and data freshness can then be configured explicitly: production progress may update frequently, while month-end analysis can use a business-approved batch.
3. Reuse Repeated Calculations with Caching and Manage Freshness with Refresh Policies
Business dashboards often receive many repeated visits. HENGSHI provides corresponding caching and acceleration settings at stages including charts, metrics, datasets, and data warehouses to help reduce repeated retrieval and computation. For business topics updated daily, teams can align cache lifetimes with the data update cadence. When checking the latest results, they can refresh through the appropriate entry point and verify the data path used by the query.
Cache design must account for filters, users’ visible data scope, and the data’s point in time. Headquarters and regional managers may use the same metric yet receive different results because of permissions. After refreshing a dataset, teams also need to verify that the page uses the expected data batch. Including these conditions in performance tests helps distinguish acceleration from a cache hit and discrepancies caused by reading old results.
4. Isolate Performance Problems by Stage
When a chart responds slowly, first inspect the query itself. If the query has completed but the page is still waiting, inspect the returned results, chart count, and rendering. When joins inflate data, first verify primary keys, granularity, and relationships. For high-cardinality detail queries, evaluate filter scope, returned fields, and presentation. The data model determines computation volume, the underlying engine determines execution cost, and page design determines how many queries a user must wait for.
Performance records should cover both individual queries and complete dashboards. Data teams can fix the metrics, dimensions, period, account, and data batch, then record query duration, refresh delay, concurrent success rate, and tail latency. Teams using HENGSHI CLI can also use structured query results and available execution-explanation capabilities to establish repeatable checks and locate source execution and page-experience problems separately.
5. Include Large Data Exports in the Delivery Pipeline
Performance delivery also includes file generation. HENGSHI SENSE 6.2 expands chart detail exports to a configurable maximum of ten million rows. Administrators can control actual allowances through user scope and export row-count policies. Exports involve querying, result reading, format conversion, file generation, and downloading. Teams need to check row completeness, field types, generation time, and resource usage together.
Financial reconciliation may require detail files, while business reporting may use summaries or a reading-oriented layout. Selecting the output scope by purpose avoids repeatedly generating and downloading unnecessary fields and records. The ten-million-row capability provides more delivery capacity; actual file size and completion time still depend on field width, query complexity, and deployment capacity.
6. Organize Query Paths for a Manufacturing Dashboard
Suppose a manufacturer wants one dashboard for MES work-order progress, ERP shipments, and financial revenue. The team first defines relationships between factories, orders, and products in the model and establishes reusable metrics such as “on-time delivery rate” and “recognized revenue.” It evaluates direct connections for current-shift work-order progress and acceleration for repeatedly aggregated historical business data, with data-preparation dependencies in update schedules. This is an architecture design example, not a customer performance test.
Once the dashboard is live, business users can analyze by factory, month, and product line. Data teams can identify each chart’s dataset, execution path, and latest update time. If a query slows down, they can inspect the model, filters, source database, cache, and page in sequence. New factories and metrics can continue to reuse existing models and calculation definitions.
HENGSHI brings unified HQL expressions, database compute capabilities, dataset acceleration, and analytics delivery into one platform. Enterprises can choose technical paths around business freshness requirements and workloads, maintaining performance optimization alongside their models, metrics, and applications.