Charging management platform based on correlation data integration

Abstract

The application relates to the technical field of property charge management big data platforms, and discloses a charge management platform based on associated data integration, wherein a data acquisition layer is configured with three kinds of heterogeneous data acquisition modes, namely, a message subscription mode, an asynchronous active pulling mode and a CDC active monitoring mode, and respectively interacts with a business system or a business storage database of a third-party business system layer; a heterogeneous data storage layer comprises four storage engines, namely, a MySQL relational database, a Redis cache database, an Elasticsearch search engine and a ClickHouse columnar database; a compass core task set carries out data consumption based on the heterogeneous data storage layer, and writes back calculation results to the heterogeneous data storage layer; a data service layer encapsulates a standardized data interface for calling by a display layer; the purpose of realizing low-cost and efficient management and accurate decision support of charge data is achieved through real-time fusion of multi-source heterogeneous data, separation of heterogeneous layered storage and calculation, and AI intelligent charge urging.

Description

Technical Field

[0001] This invention relates to the field of big data platform technology for property fee management, and specifically to a fee management platform based on the integration of related data. Background Technology

[0002] With the digital transformation of the property management industry, large property groups have generally deployed multiple business systems, such as fee collection systems, incident reporting systems, financial systems, and property management apps. These systems operate independently with varying data formats, resulting in severe data silos. Existing property fee management platforms mainly suffer from the following shortcomings: First, the data collection methods are limited and lack real-time performance. Traditional platforms often use timed full synchronization or simple direct database connections to acquire data, which cannot handle high-concurrency, high-frequency change billing transaction scenarios. This results in severely delayed billing data for management, making it impossible to keep abreast of business dynamics.

[0003] Second, the data storage architecture is homogenized, resulting in high hardware costs. Existing systems typically store all data uniformly in relational databases (such as MySQL). When faced with hundreds of millions of billing detail data, the performance of traditional row-based OLTP databases drops sharply in OLAP scenarios such as aggregation queries and trend analysis. This necessitates stacking high-end server hardware to improve performance, resulting in persistently high hardware investment costs.

[0004] Third, there is a disconnect between data analysis and business decision-making. Existing platforms mostly remain at the level of basic report statistics, lacking in-depth profiling and analysis of homeowner payment behavior. They are unable to intelligently identify high-value collection opportunities, and collection work relies on the experience judgment of property managers, resulting in low efficiency and unstable collection rates.

[0005] Fourth, data services lack role-based differentiation. Existing systems typically use a "one-size-fits-all" approach to data display, where users at different levels, such as group management, regional managers, and project managers, see the same data. This fails to accurately push key indicators based on job responsibilities, leading to information overload or missing crucial information.

[0006] Fifth, legacy systems face challenges in integration. The property management group's early-stage financial and billing systems often lack standard API interfaces, resulting in high costs and long lead times for retrofitting. Existing platforms struggle to achieve non-intrusive data access, further exacerbating the difficulty of data integration. Summary of the Invention

[0007] The present invention aims to provide a fee management platform based on the integration of related data to solve the technical problems of existing property fee management systems, such as scattered data from multiple systems, high hardware costs due to large data volume, low query and analysis efficiency, and lack of real-time decision support. The goal is to achieve low-cost and efficient management of fee data and accurate decision support through real-time fusion of multi-source heterogeneous data, separation of heterogeneous hierarchical storage and computing, and AI-powered intelligent fee reminders.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: The fee management platform based on the integration of related data includes a layered and decoupled data acquisition layer, a heterogeneous data storage layer, a compass core task set, a data service layer, and a presentation layer. The data acquisition layer is configured with at least three heterogeneous data acquisition modes, including: Message subscription mode: The business system actively publishes data change messages to the MQ middleware, and the MQ data change subscription service subscribes in real time and pushes them to the data storage layer; Asynchronous active fetch mode: The data API collection service actively fetches data from the business system through distributed task scheduling and writes it to the data storage layer through a compensation update mechanism; CDC Active Monitoring Mode: The CDC Data Change Monitoring Service actively monitors changes in the Binlog of the business storage database, captures data changes in real time, and pushes them to the data storage layer; The heterogeneous data storage layer includes at least four storage engines: A MySQL relational database used to store structured business data, with a record volume exceeding 5 million records; Redis is a cache database that caches frequently accessed billing metrics and supports concurrent queries of over 100,000 QPS. The Elasticsearch search engine stores text-based data such as operation logs and payment reminders. ClickHouse columnar database stores time-series billing details data, with a data volume of over 1 billion records, and supports second-level OLAP aggregation queries. The core task set of the compass includes: The asynchronous timed data acquisition module collects incremental data from various business systems every day at midnight and cleans and standardizes it. The data analysis and statistics module, based on ClickHouse, calculates three-level charging indicators for groups, regions, and projects, with a calculation delay of less than 3 seconds. The AI-powered automatic payment reminder module builds payment profile tags based on homeowners' historical payment behavior data, intelligently identifies high-value payment opportunities, and generates personalized payment reminder strategies. The data service layer includes REST API services, backend management basic services, and asynchronous job task services; and The presentation layer consists of a PC web application based on the Vue / React technology stack and an H5 mobile application based on uni-app. Data access control enables differentiated data display for three levels of roles: group management, regional managers, and project managers.

[0009] Beneficial effects: By collaboratively deploying three heterogeneous data collection modes—message subscription, asynchronous retrieval, and CDC monitoring—the technical challenges of data dispersion across multiple systems and non-intrusive integration with legacy systems were resolved. A heterogeneous storage architecture employing MySQL+Redis+ES+ClickHouse engines was implemented, optimizing storage engines for different data characteristics. This resulted in hardware costs reduced by over 40% and query response time shortened from minutes to seconds, even with 5 million structured data entries and 1 billion time-series data entries. An AI-powered automatic payment reminder module increased the payment reminder conversion rate by over 25%. A role-based data view enabled precise "one-household-one-policy" management, preventing information overload.

[0010] Furthermore, the fee management method based on the integration of related data includes the following steps: S1. Data Acquisition: Collect at least 12 types of fee-related data fields, including region, project, owner's name, room number, amount owed, amount owed at the beginning of the period, amount owed at the end of the period, payment amount, payment subject, discount amount, property manager's collection action records, owner payment profile tags, and finalized financial data. S2. Multi-source heterogeneous data aggregation: Three data acquisition modes are adopted: message subscription mode, asynchronous active pull mode, and CDC active monitoring mode to achieve real-time aggregation of multi-source heterogeneous data; S3, Heterogeneous Data Storage and Tiling: Write structured business data into a MySQL relational database, cache hot billing metrics in Redis, and write operation logs and payment reminder records into Elasticsearch, and write time-series billing details into a ClickHouse columnar database; S4. Data Calculation and Task Scheduling: Collect incremental data from the previous day at a set time in the early morning and clean and standardize it; calculate the three-level charging indicators of group, region and project based on ClickHouse, and control the calculation delay within 3 seconds; build payment profile tags based on the owner's historical payment behavior, intelligently identify high-value collection opportunities and generate personalized collection strategies. S5. Data Services and Differentiated Display: Provides standardized data interfaces through REST APIs, and enables differentiated data display for three levels of roles: group management, regional managers, and project managers through PC web and H5 mobile terminals.

[0011] Beneficial effects: By defining 12 standardized data fields related to billing, a unified data semantic layer is established, eliminating integration obstacles caused by inconsistent data formats from multiple systems; through the adaptive selection of three collection modes, billing transaction data with high real-time requirements is synchronized in seconds via message subscription, while low-frequency reporting data is retrieved asynchronously to reduce system load; legacy financial systems that cannot be modified are monitored non-intrusively through CDC; and heterogeneous layered storage allows data with different characteristics to be stored appropriately, improving overall query efficiency by more than 5 times.

[0012] Furthermore, the message subscription model includes: the billing system service acts as a business system, actively publishing messages to the RabbitMQ / Kafka middleware when payment or overdue payment update business events occur; the MQ data change subscription service subscribes to relevant topics, receives change messages in real time, parses them, and synchronously pushes them to MySQL and ClickHouse for storage updates, with end-to-end data synchronization latency controlled within 500 milliseconds.

[0013] Beneficial effects: By adopting a message subscription model for billing transaction data with the highest real-time requirements, the end-to-end synchronization latency is controlled within 500 milliseconds, ensuring that the time difference between the billing data seen by management and the actual business occurrence does not exceed the second level, providing a data foundation for real-time decision-making; by synchronously writing to MySQL and ClickHouse, both transaction consistency requirements and OLAP analysis needs are met, avoiding the ETT latency between OLTP and OLAP databases in traditional solutions.

[0014] Furthermore, the asynchronous active retrieval mode includes: the data API collection service periodically retrieves data from the business system through the XXL-JOB distributed task scheduling platform, compares the data with the previous collection points through a compensation update mechanism, synchronizes only incremental data, and writes it to the MySQL relational database.

[0015] Beneficial effects: By using XXL-JOB distributed task scheduling to achieve load balancing and failover of data collection tasks, and by using a compensation update mechanism to synchronize only incremental data, in scenarios with more than 5 million data entries, the time for a single collection is reduced from more than 2 hours for full synchronization to less than 15 minutes, network bandwidth usage is reduced by more than 90%, and 100% incremental recognition accuracy ensures that no data is missed or duplicated.

[0016] Furthermore, the CDC proactive monitoring mode includes: deploying the CDC data change monitoring service based on Canal or Debezium, proactively monitoring the Binlog logs of the business storage database, capturing change events of the final financial data, parsing the data mirror before and after the change in real time and pushing it to the data storage layer, achieving non-intrusive data synchronization without modifying legacy system interfaces.

[0017] Beneficial effects: By parsing Binlog logs to capture data changes, no interface modifications or code intrusions are required for legacy financial systems, shortening the system integration cycle from more than 3 months in traditional API transformation solutions to less than 2 weeks, and reducing integration costs by more than 80%; by capturing data mirrors before and after changes, data auditing and tracing can be achieved, meeting financial data compliance requirements.

[0018] Furthermore, the calculation of three-level charging indicators for groups, regions, and projects based on ClickHouse includes: using ClickHouse's columnar storage and vectorized computing capabilities to aggregate and calculate more than 1 billion charging details data over the past 3 years, and generate at least 4 complex indicators in real time, including payment rate, arrears aging structure, year-on-year and month-on-month trends, and the housekeeper's collection conversion rate, with the response time for a single aggregate query controlled within 3 seconds.

[0019] Beneficial effects: By using ClickHouse columnar storage, the storage space for 1 billion time-series data entries is compressed to less than 1 / 10 of the original size. Through vectorized computing, the performance of aggregate queries is improved to more than 50 times that of traditional row-based databases. Complex indicator calculations can be performed in less than 3 seconds on ordinary server configurations, reducing hardware costs to 1 / 5 of traditional solutions. Through a three-level indicator penetration design, the group's management can drill down to the details of regions, projects, and individual households, achieving business insights from "seeing" to "understanding".

[0020] Furthermore, the payment profile tags constructed based on homeowners' historical payment behavior include: collecting homeowners' payment timeliness data, payment channel preference data, and overdue payment frequency data for the past 24 months, and using clustering algorithms to classify homeowners into at least three profile tags: timely payment type, reminder payment type, and difficult payment type; intelligent identification of high-value repayment opportunities includes: constructing a repayment probability prediction model based on profile tags, current overdue amount, overdue duration, and historical reminder response rate to identify high-value homeowners with a repayment probability greater than 70%; and generating personalized collection strategies includes: sending SMS reminders to timely payment type homeowners, making phone calls to remind payment type homeowners, and arranging home visits to difficult payment type homeowners, with strategy generation and push delays controlled within 5 minutes.

[0021] Beneficial effects: Through cluster analysis of 24 months of historical behavioral data, homeowners are accurately divided into three profile tags, replacing the traditional "one-size-fits-all" collection model; through the collection probability prediction model, the housekeeper's energy is focused on high-value homeowners with a collection probability of over 70%, increasing the efficiency of the average housekeeper by over 30% and the overall collection rate by over 15%; through strategy generation and push delay within 5 minutes, it is ensured that collection actions reach homeowners within the window of their willingness to pay, improving conversion rates.

[0022] Furthermore, the differentiated data display for the three roles includes: Group management displays the full group's billing dashboard, including macro indicators such as the group's overall payment rate, regional ranking, and year-on-year trends; regional managers display data for their respective regions, including meso indicators such as regional payment rate, project ranking, and arrears structure analysis; and project managers display details for their projects, including micro indicators such as individual household arrears details, collection action records, and homeowner payment profiles. Data access control is implemented through Spring Security OAuth2 to ensure that each role can only access data within its authorized scope, and the data access verification latency is controlled within 100 milliseconds.

[0023] Beneficial effects: By providing a three-tiered, differentiated data view, the group's management is freed from massive amounts of detailed data to focus on strategic decision-making; the management radius of regional managers is visualized to facilitate resource allocation; and the project manager's interface is streamlined to the minimum set of information required for payment collection. The information acquisition efficiency of users at all levels is improved by more than 50%. Through OAuth2 access control and a verification latency of less than 100 milliseconds, user experience is not affected while ensuring data security.

[0024] Furthermore, among the 12 categories of fee-related data fields, the housekeeper's reminder action record field includes three quantitative indicators: number of phone calls, number of home visits, and number of text messages; the homeowner payment profile label field includes three classification labels: timely payment type, reminder payment type, and difficult payment type; and the financial finalization data field includes monthly financial statement verification data.

[0025] Beneficial effects: By quantifying the butler's collection actions into three categories of indicators—number of phone calls, number of in-person visits, and number of text messages—an objective data foundation for butler performance evaluation is established, replacing traditional subjective evaluation; by using three types of payment profile tags to manage homeowners in a tiered manner, the allocation of collection resources shifts from "casting a wide net" to "precision targeting"; by introducing finalized financial data as an authoritative verification benchmark, the consistency between billing data and financial accounting data is ensured, eliminating decision-making biases caused by discrepancies between business and financial data.

[0026] Furthermore, the data service layer also includes the Compass API interface service, which directly queries the business storage database through the real-time data channel to obtain real-time billing data. As a supplement to the three collection modes of message subscription mode, asynchronous active pull mode, and CDC active monitoring mode, it is used to handle temporary and non-periodic real-time data query requests, and the query response time is controlled within 200 milliseconds.

[0027] Beneficial effects: By supplementing the three asynchronous acquisition modes with a fourth real-time data interface, temporary real-time query needs can be met without affecting the stability of the main acquisition link; with a direct query response of less than 200 milliseconds, immediate data support can be provided for emergency decision-making scenarios (such as temporary inspections by group leaders or surprise audits), increasing the data service coverage from 95% to over 99.9%.

[0028] Advantages of the present invention This invention constructs a digital intelligence platform for fee management of large property groups through a complete technical loop of "real-time fusion of multi-source heterogeneous data, separation of heterogeneous hierarchical storage and computing, AI-powered intelligent fee reminders, and role-based differentiated display." Its core advantages are: at the data access level, through an adaptive combination of message subscription, asynchronous retrieval, and CDC monitoring modes, it achieves full coverage and non-intrusive access from real-time transaction data to legacy financial systems; at the data storage level, through a heterogeneous architecture of MySQL+Redis+ES+ClickHouse four engines, it ensures that data with different characteristics are properly stored, reducing hardware costs to 1 / 5 of traditional solutions for data volumes of 1 billion records; at the data application level, through AI-driven resident profiling and intelligent fee reminders, it increases the conversion rate of property management fee reminders by more than 25%; at the data display level, through a three-tiered role-based differentiated view, it allows users at different levels to access information according to their needs, improving information acquisition efficiency by more than 50%.

[0029] Unexpected solutions to technical problems Existing technologies address the problem of scattered data from multi-source systems by typically employing a unified data warehouse or data platform solution, extracting data from various systems to a single platform before integration. However, this "aggregate first, process later" approach encounters fundamental obstacles in property management billing scenarios: billing transaction data requires real-time processing down to the second, while traditional ETL batch synchronization often suffers from delays of hours or even days; incident reporting systems have low data change frequency but complex data structures, making full synchronization a huge waste of resources; legacy financial systems lack standard interfaces, resulting in long transformation cycles and high risks. This invention unexpectedly adopts a "data characteristic-matched acquisition mode" approach. Instead of forcibly aggregating all data into a unified pipeline, it adaptively selects three modes—message subscription, asynchronous retrieval, and CDC monitoring—at the acquisition layer based on three dimensions: data real-time requirements, system modifiability, and data structure complexity. This ensures that real-time billing data is delivered in seconds via message channels, infrequently changing incident reporting data is retrieved on a timed basis to save resources, and legacy systems that cannot be modified are accessed non-intrusively via CDC monitoring. This "differentiated treatment" rather than "one-size-fits-all" strategy reduces the overall collection cost by more than 60% while ensuring the real-time nature of each data source. This is something that those skilled in the art would find hard to conceive when facing the same technical problem.

[0030] Unexpected Technological Means Existing technologies typically address the problem of low query efficiency for large datasets by employing two approaches: upgrading hardware (e.g., using higher-performance servers, SSD storage, and more memory) or using traditional big data batch processing frameworks like Hadoop / Spark. However, hardware upgrades have cost limitations, and the Hadoop ecosystem suffers from inherent drawbacks in sub-second query scenarios, such as high scheduling overhead and small file issues. This invention unexpectedly uses the ClickHouse columnar database as the storage engine for time-series billing details. This choice itself is not obvious: ClickHouse was originally designed for Yandex web traffic analysis scenarios, with its optimization goal being the rapid aggregation of large amounts of data, not transaction processing; in the field of property fee management, those skilled in the art would not typically consider migrating a web analysis engine to a financial data scenario. More importantly, this invention does not simply replace the database, but rather constructs a four-engine collaborative architecture: "transactional data is written to MySQL, analytical data is written to ClickHouse, hotspot caching uses Redis, and log retrieval uses Elasticsearch." Through a dual-write mechanism during data writing (such as synchronous writing of message subscriptions to MySQL and ClickHouse), it ensures both transaction consistency and real-time analytical performance. Redis caching boosts the QPS support for high-frequency queries to over 100,000. This architecture design, where "storage engines are divided according to data characteristics and computing tasks are layered according to timeliness requirements," overcomes the inherent contradiction that a single database cannot simultaneously meet the needs of OLTP and OLAP. It is a technical solution that the commonly used "unified storage" approach in this field cannot achieve. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the platform system architecture of the present invention.

[0032] Figure 2 This is a schematic diagram of data flow according to the present invention. Detailed Implementation

[0033] The following detailed description illustrates the specific implementation method: This invention belongs to the field of big data platform technology for property fee management, and involves the real-time fusion, hierarchical storage and intelligent analysis of multi-source heterogeneous data.

[0034] like Figure 1As shown, the charging management platform based on correlated data integration in this invention includes a layered and decoupled deployment of a data acquisition layer, a heterogeneous data storage layer, a compass core task set, a data service layer, and a presentation layer. Each layer interacts with the others through standardized data interfaces, supporting multi-path data flow. The data acquisition layer is configured with three heterogeneous data acquisition modes: message subscription mode, asynchronous active pull mode, and CDC active monitoring mode, which interact with the business systems or business storage databases of the third-party business system layer, respectively. The heterogeneous data storage layer includes four storage engines: MySQL relational database, Redis cache database, Elasticsearch search engine, and ClickHouse columnar database. The compass core task set consumes data based on the heterogeneous data storage layer and writes the calculation results back to the heterogeneous data storage layer. The data service layer encapsulates standardized data interfaces for the presentation layer to call. Figure 1 This is the system architecture diagram of the present invention, namely the Digital Intelligence Compass system architecture diagram. Figure 1 The layered design of the Digital Compass overall platform architecture is shown, from bottom to top as follows: Third-party business system layer (billing system service, incident reporting system service, financial system service, other services), business database layer (billing system database, incident reporting system database, financial system database, other business system database), collection layer (message subscription mode, asynchronous active pull mode, CDC active monitoring mode, real-time data interface), data storage layer (MySQL, Redis, Elasticsearch, ClickHouse), middleware layer (RabbitMQ / Kafka, Nacos, XXL-JOB, Nginx, Redis), technology stack layer (Spring Cloud microservices), application layer (asynchronous JOB task service, backend management basic service, REST API service), and presentation layer (PC Web, H5 → Android + iOS).

[0035] Figure 2 This is the data flow diagram of the present invention, namely the Data Intelligence Compass Data Flow Diagram. Figure 2The data flow process of the Digital Compass platform is demonstrated: When business systems and business storage databases in the business data source layer undergo data changes, these changes converge to the core service layer of the Compass through four pathways: ① Business systems actively publish messages to the MQ middleware, and the MQ data change subscription service subscribes to and pushes the changes; ② The data API collection service actively pulls data from the business systems; ③ The CDC data change monitoring service actively monitors changes in the business storage database; ④ The Compass API interface service directly queries the business storage database to obtain real-time data. The core service layer of the Compass writes the data to the data storage layer (MySQL, Redis, ES, ClickHouse). The core task set of the Compass (asynchronous and scheduled data collection, data analysis and statistics, AI automatic payment reminders) consumes the data from the storage layer for computation and processing, and the computation results are written back to the storage layer for querying by upper-layer services.

[0036] Data Acquisition Layer MQ (Message Queue) is an asynchronous communication middleware used for system decoupling and peak shaving. This invention specifically uses RabbitMQ or Kafka for implementation. CDC (Change Data Capture) is a technology for monitoring database data changes and capturing change events in real time. DB stands for Database. Binlog (Binary Log) is a log file in MySQL databases that records all data change operations. The CDC service captures data changes by parsing the Binlog. API (Application Programming Interface) is a standardized interface for interaction between systems. REST (Representational State Transfer) is a lightweight web service architecture style. In this invention, the data API acquisition service uses a REST-style interface to interact with the business system. XXL-JOB is an open-source distributed task scheduling platform used to trigger data acquisition tasks on a schedule; its name itself does not have a full English name. Redo Log is the redo log of Oracle databases, recording all data modification operations, functionally equivalent to MySQL's Binlog.

[0037] Data storage layer MySQL is an open-source relational database management system; its product name itself does not have a full English name. In this invention, it is used to store structured business data. Redis (Remote Dictionary Server) is an open-source in-memory key-value store database used for caching frequently accessed data. Elasticsearch (ES) is an open-source distributed search engine used for storing and retrieving text-based data such as operation logs and payment reminders. ClickHouse is an open-source columnar database management system developed by Yandex, specifically optimized for OLAP scenarios; its product name itself does not have a full English name. OLAP (Online Analytical Processing) is a data processing method for complex analytical queries, supporting rapid aggregation and computation of large-scale data. OLTP (Online Transaction Processing) is a data processing method for daily transaction operations, emphasizing transaction consistency and high-concurrency writes. QPS (Queries Per Second) is a performance metric measuring a system's query processing capacity. LRU (Least Recently Used) is a cache eviction policy that prioritizes removing the least recently accessed data. TTL (Time To Live) is the expiration time setting for cached data. GB (Gigabyte) and TB (Terabyte) are units of storage capacity. CSV (Comma-Separated Values) is a plain text data storage format.

[0038] Data service and presentation layer In this invention, PC (Personal Computer) refers to a desktop web browser. H5, or HTML5 (HyperText Markup Language 5), refers to mobile web applications based on HTML5 technology. Vue and React are both front-end JavaScript frameworks; their product names do not have full English names. Vue is used to build user interfaces, while React is developed by Facebook. uni-app is a cross-platform front-end framework; its product name does not have a full English name, and a single codebase can be compiled into applications for iOS, Android, H5, and other platforms. iOS (iPhone Operating System) is Apple's mobile operating system. Android is a mobile operating system developed by Google; its product name does not have a full English name. Spring Cloud is a microservice development framework; its product name does not have a full English name, and it implements a microservice architecture based on Spring Boot. Spring Security is a security framework; its product name does not have a full English name, and it provides security functions such as authentication, authorization, and attack protection. OAuth2 (Open Authorization 2.0) is an industry-standard authorization protocol used for third-party applications to obtain limited access to user resources. A token is a credential string used for user authentication, containing user identity and permission information. ECharts is an open-source data visualization library developed by Baidu; its product name itself has no full English name. It is used to create various charts. ElementUI is a desktop component library based on Vue; its product name itself has no full English name.

[0039] AI and algorithms In this invention, AI (Artificial Intelligence) refers to the analysis of homeowner payment behavior and intelligent payment reminders based on machine learning. K-Means is a K-means clustering algorithm; its name itself has no full English name. It is an unsupervised learning clustering algorithm that divides data into K clusters. XGBoost (eXtreme Gradient Boosting) is an efficient machine learning algorithm used for classification and regression prediction. AUC (Area Under Curve) is a metric for measuring the performance of a binary classification model, ranging from 0 to 1, with values ​​closer to 1 indicating a better model. F1 score is the harmonic mean of precision and recall, a comprehensive indicator of model performance. JSON (JavaScript Object Notation) is a lightweight data exchange format. DML (Data Manipulation Language) is a subset of SQL, including INSERT, UPDATE, and DELETE operations. P99, or 99th Percentile, is a performance metric that indicates that 99% of requests have a response time below this value.

[0040] System architecture and middleware C / S (Client / Server) is a traditional two-tier software architecture. B / S (Browser / Server) is the architecture adopted for the PC-side Web in this invention. Nginx is an open-source, high-performance HTTP server and reverse proxy server; its product name itself has no full English name. Nacos is a dynamic service discovery, configuration management, and service management platform; its product name itself has no full English name. Kafka, RabbitMQ, and RocketMQ are all open-source message middleware; their product names themselves have no full English names. RabbitMQ implements the Advanced Message Queuing Protocol (AMQP), Kafka is a high-throughput message queue, and RocketMQ was developed by Alibaba. Canal is an open-source data synchronization tool; its product name itself has no full English name, and it is based on incremental log parsing of MySQL databases. Debezium is an open-source distributed CDC platform; its product name itself has no full English name. Seata is an open-source distributed transaction solution; its product name itself has no full English name. ETL (Extract, Transform, Load) is the traditional data processing flow in a data warehouse. ETT (Extract, Transform, Transfer) is a variant of ETL that emphasizes the data transmission stage.

[0041] Network and performance related An ID (Identifier) ​​is a unique identifier for an entity. A URL (Uniform Resource Locator) is the standard format for a web page address. HTTP (Hypertext Transfer Protocol) is the fundamental protocol for web communication. HTTPS (Hypertext Transfer Protocol Secure) is an encrypted version of HTTP. IP (Internet Protocol) is the fundamental protocol for communication between network devices. SQL (Structured Query Language) is the standard query language for relational databases. A CPU (Central Processing Unit) is the core computing component of a computer. An SSD (Solid State Drive) is a high-speed storage device based on flash memory. Hadoop is an open-source distributed computing framework (its product name does not have a full English name) used for large-scale batch data processing. Spark is an open-source big data processing engine (its product name does not have a full English name) that supports both batch and stream processing. Sqoop is an open-source data transfer tool (its product name does not have a full English name) used for data migration between Hadoop and relational databases. DataX is an open-source data synchronization tool developed by Alibaba; its product name itself does not have a full English name. Hive is a data warehouse tool based on Hadoop; its product name itself does not have a full English name, and it provides SQL-like query capabilities.

[0042] Business terms BIM (Building Information Modeling) is the three-dimensional digital building modeling technology mentioned in Comparative Document 2. GIS (Geographic Information System) is the spatial information management technology mentioned in Comparative Document 2. Wi-Fi (Wireless Fidelity) is a wireless local area network technology based on the IEEE 802.11 standard. NFC (Near Field Communication) is a short-range, high-frequency wireless communication technology. RFID (Radio Frequency Identification) is a wireless communication identification technology. RFID-SIM (Radio Frequency Identification - Subscriber Identity Module) is a SIM card with integrated RFID functionality used for near-field mobile payments. POS (Point of Sale) is a card payment device. APP (Application) in this invention refers to mobile application software. LED (Light Emitting Diode) is the display device of the information sharing unit in Comparative Document 1.

[0043] The charging management platform based on correlated data integration in this invention can be viewed as a management system primarily focused on charging data management. It prioritizes ease of control and data display for the management team, and user-friendly data management for the application side, forming the overall management platform architecture. It includes the following steps: S1. Data Acquisition: Required fields include: region, project, owner's name, unit number, outstanding amount, initial outstanding amount, ending outstanding amount, payment amount, payment category, discount amount, property manager's payment reminder records, owner payment profile tags, and finalized financial data. S2. Data Acquisition and Analysis Methods: Three data acquisition modes are used to achieve real-time aggregation of multi-source heterogeneous data: S2.1 Message Subscription Mode: The business system actively publishes messages to the MQ middleware, and the MQ data change subscription service subscribes to and pushes the changed data to the data storage layer; S2.2 Asynchronous Active Fetch Mode: The data API collection service actively fetches data from the business system and writes it to MySQL through a compensation update data mechanism; S2.3, CDC Active Monitoring Mode: The CDC Data Change Monitoring Service actively monitors data changes in the business storage DB, captures data changes in real time, and pushes them to the data storage layer; S2.4 Real-time Data Interface: The Compass API interface service directly queries the business storage DB through the real-time data channel to obtain real-time billing data.

[0044] S3, Data Storage and Tiling: Build a heterogeneous data storage layer and select storage engines for different data characteristics: - MySQL: Stores structured business data and supports transactional operations; -Redis: Caches frequently accessed data and supports high-concurrency real-time queries; - ES (Elasticsearch): Stores logs and searchable data, supporting full-text search; -- ClickHouse: Stores large-volume, time-series data for a fee, supporting OLAP analysis.

[0045] S4. Data Computation and Task Scheduling: The core task set of the compass consumes data based on the data storage layer: S4.1 Asynchronous Timed Data Acquisition: Incremental data is collected periodically from various business systems for data cleaning and standardization; S4.2 Data Analysis and Statistics: Based on ClickHouse, perform complex calculations to generate regional / project charging indicators (payment rate, arrears structure, collection trend, etc.). S4.3 AI Automatic Payment Reminder: Based on homeowner payment profile data, it intelligently identifies payment opportunities, generates payment reminder strategies, and pushes them to the property manager's terminal.

[0046] S5, Data Services and Presentation: S5.1 REST API service: Provides standardized interfaces for owners, properties, housekeepers, reporting issues, overdue payments, prepaid balances, unit information, files, authentication, etc. S5.2 Backend Management Basic Services: Backend management basic services provide report management, region management, privacy number management, and system management functions; S5.3 Asynchronous JOB Task Service: Supports AI-powered automatic payment reminders, data analysis and statistical calculations, and other scheduled tasks; S5.4 Presentation Layer: The PC web version is based on the Vue / React technology stack, while the H5 version supports Android and iOS. It uses data visualization components to present real-time billing indicator dashboards and supports differentiated data display under different role permissions.

[0047] The specific implementation process is as follows: Example 1: Data Access to the Billing System (Message Subscription Mode) As the core business system of the property management group, the billing system service processes tens of thousands of payment and arrears update transactions daily, requiring extremely high data real-time performance. In this embodiment, when business events such as payment or arrears updates occur, the billing system service proactively publishes messages to the RabbitMQ middleware. The message body includes metadata such as the data mirror before and after the change, the change timestamp, and the business event type. The MQ data change subscription service subscribes to the "charge.update" related topic, receives change messages in real time, parses the JSON data in the message body, extracts key fields such as owner ID, room number, payment amount, payment subject, and change time, and synchronously pushes them to a MySQL relational database for transactional writing to ensure data consistency; simultaneously, it pushes them to a ClickHouse columnar database for real-time updates for subsequent OLAP analysis. In this mode, the end-to-end latency from the occurrence of a business event in the billing system to data synchronization to ClickHouse is controlled within 500 milliseconds, meeting the management's need to view billing dynamics in real time.

[0048] Implementation Results: In a large property management group's actual deployment, this model processed an average of 120,000 messages per day, with a peak QPS of 8,500. The message consumption latency P99 value remained stable within 400 milliseconds, and the data synchronization success rate reached 99.99%. Compared to the original ETL batch synchronization solution (synchronizing at midnight every day, with yesterday's data only available at 10 AM the next day), the timeliness for management to view billing data improved from T+1 to real-time, and the decision-making response speed increased by more than 24 times.

[0049] Example 2: Data Access to the Incident Reporting System (Asynchronous Active Retrieval Mode) The incident reporting system handles low-frequency change requests such as reports, complaints, and suggestions from homeowners. Its data structure is complex (including text descriptions, image attachments, and processing flows), and its system interface capabilities are limited, making it unsuitable for high-frequency real-time push notifications. In this embodiment, the data API collection service uses the XXL-JOB distributed task scheduling platform to configure scheduled tasks, performing incremental fetching every 6 hours. The collection service first queries the last collection point (using the incident creation time or last update time as a cursor), constructs incremental query conditions (e.g., "update_time>'2024-01-01 06:00:00'), and fetches data from the incident reporting system via the REST API. After fetching, a compensation update mechanism compares the boundaries between the last collection point and the currently fetched data, identifying and supplementing any missing data that may be due to concurrent writes, ensuring 100% accuracy in incremental data identification. The cleaned data is written to a MySQL relational database for subsequent correlation analysis with billing data (e.g., analyzing the correlation between incident processing satisfaction and payment timeliness).

[0050] Implementation Results: In a real-world deployment at a large property management group, the incident reporting system contained approximately 2 million data entries. The initial full synchronization took 3 hours, while subsequent incremental synchronizations of approximately 5,000 data entries each took 8 minutes. Network bandwidth usage was only 0.25% of that of the full synchronization. Through the compensation update mechanism, no data omissions or duplications have occurred in the six months since its implementation, achieving 100% data integrity.

[0051] Example 3: Financial System Data Access (CDC Active Monitoring Mode) The financial system is a legacy system built early on by the property management group. It uses a client / server architecture and an Oracle 11g database, lacks a standard REST API interface, and the system vendor has ceased maintenance, making modification extremely risky. In this embodiment, a CDC data change monitoring service is deployed based on Canal. Canal Server is deployed on the Oracle database server of the financial system, simulating the Oracle slave protocol to read the Redo Log (Binlog equivalent) in real time, parse DML change events (INSERT, UPDATE, DELETE), and capture the data mirroring of the finalized financial data before and after changes. The parsed change data is pushed to RocketMQ via the Canal Client, consumed by the Compass core service, and written to ClickHouse. The entire integration process requires no modification to any code or configuration in the financial system; only read-only permissions need to be granted at the database level, achieving completely non-intrusive data synchronization.

[0052] Implementation Results: In a large property management group's actual deployment, the financial system processed approximately 3,000 data changes daily, with the CDC parsing latency (P99 value) consistently below 800 milliseconds. From starting the CDC service to successfully synchronizing data to ClickHouse, the entire integration cycle took only 10 working days. Compared to traditional API transformation solutions (which require more than 3 months and carry the risk of failure), this represents an 85% reduction in the integration cycle and a more than 90% reduction in integration costs. Furthermore, by capturing data mirroring before and after the changes, a complete financial data audit trail was established, meeting the group's internal audit and external regulatory requirements.

[0053] Example 4: Heterogeneous Data Storage and Tiling This example demonstrates the specific deployment and data distribution of a four-engine heterogeneous storage architecture. The MySQL relational database is deployed in a master-slave architecture, storing structured business data such as basic owner information (approximately 5 million records), property information, and property management organizational structure, supporting transactional operations and complex relational queries. The Redis cluster is deployed in a 6-master, 6-slave architecture, caching current month's billing metrics, real-time data for hot projects, and user session information, supporting 100,000 concurrent queries per second (QPS), with a cache expiration strategy employing a hybrid LRU+TTL approach. The Elasticsearch cluster is deployed in a 3-node architecture, storing text-based search data such as operation logs and payment reminders from the past 6 months, supporting full-text search and audit trails, with indexing strategies based on monthly sharding. The ClickHouse cluster is deployed in a 2-shard, 2-replica architecture, storing billing details data from the past 3 years, approximately 1 billion records, using the MergeTree engine for monthly partitioning, supporting second-level OLAP aggregation queries.

[0054] Implementation Results: In a real-world deployment at a large property management group, the overall storage cost (including servers, storage, and network) was approximately 18% of the traditional unified MySQL cluster solution. Specifically, ClickHouse columnar storage compressed 1 billion billing details records to approximately 150GB (original CSV format approximately 1.5TB), achieving a compression ratio of 10:1; Redis caching reduced the query response time for billing indicator dashboards from 3.2 seconds in MySQL to 12 milliseconds; and Elasticsearch full-text search reduced the query time for "querying all payment reminder records for a property manager in the past 30 days" from 45 seconds in MySQL to 1.5 seconds. Overall query efficiency improved by more than 50 times, while hardware investment decreased by 82%.

[0055] Example 5: Data Analysis and Statistics with AI-Powered Automatic Payment Reminders This example demonstrates the implementation of data analysis and statistics based on ClickHouse and AI-powered automatic payment reminders. Every day at 2:00 AM, the XXL-JOB schedules an asynchronous, timed data collection task, gathering incremental data from the previous day from various business systems. After data cleaning (duplicate removal, format standardization, and missing value imputation), the data is synchronized to ClickHouse. At 9:00 AM, the group's management team opens the PC-based management backend. The payment dashboard uses ClickHouse to calculate macro-level indicators such as the group's overall payment rate, regional ranking, and year-on-year trends in real time, with a single aggregate query response time of 2.3 seconds. Regional managers view data for their respective regions, including meso-level indicators such as regional payment rates, project rankings, and arrears structure analysis, supporting drill-down from the regional level to project and individual household details. Project managers open the H5 mobile app to view the list of owners awaiting payment reminders for their project; the list has been sorted in descending order of payment probability by the AI-powered automatic payment reminder module.

[0056] The AI-powered automatic payment collection module works as follows: It collects homeowners' payment records for the past 24 months, extracting features such as payment timeliness (whether overdue, number of overdue days), payment channel preference (online / offline, WeChat / Alipay / bank transfer), and frequency of arrears (number of arrears in the past 24 months). Using a K-Means clustering algorithm, homeowners are categorized into three profiles: timely payment (approximately 40%), reminder payment (approximately 35%), and difficult payment (approximately 25%). Based on these profiles and the current arrears amount, duration of arrears, and historical collection response rates (call connection rate, SMS click rate, successful in-person visit rate), an XGBoost recovery probability prediction model is constructed to identify high-value homeowners with a recovery probability greater than 70%. For timely payment homeowners, SMS reminders are automatically sent (lowest cost); for reminder payment homeowners, suggestions for phone calls are pushed to the property manager's app (moderate cost); and for difficult payment homeowners, they are marked for "in-person visits" and assigned to senior property managers (highest cost but highest recovery rate). The delay in strategy generation and push is controlled within 5 minutes.

[0057] Implementation Results: In a large property management group's actual deployment, the AI-powered automatic payment collection module covered 120,000 homeowners, generating an average of 36,000 payment collection strategies per month. Compared to the traditional "sorted by outstanding amount" payment collection model, the AI ​​model increased the average efficiency per property manager (number of successfully collected payments / number of property managers) from 15 to 22 per month, an increase of 46.7%; the overall collection rate increased from 68% to 78%, an increase of 10 percentage points; and the collection cost (SMS fee + telephone fee + labor cost) decreased from an average of 35 yuan per household to 28 yuan, a decrease of 20%. Among them, although homeowners with difficult payment collection accounted for only 25%, through accurate identification and allocation of experienced property managers, their collection rate increased from 12% in the traditional model to 31%, showing the most significant improvement.

[0058] Example 6: Role-based Differentiation Display This example demonstrates the specific implementation of differentiated data display for three roles. The system uses the Spring SecurityOAuth2 framework to implement unified identity authentication and access control. When a user logs in, a differentiated menu and data range are loaded based on their role identifier (ROLE_GROUP_ADMIN, ROLE_REGION_ADMIN, ROLE_PROJECT_STEWARD). Group management (ROLE_GROUP_ADMIN) logs in via the PC web interface. The homepage displays the group's billing dashboard, including: the group's overall payment rate (calculated in real-time, refreshed every 5 minutes), the top 10 / bottom 10 regional rankings (sorted by payment rate), year-on-year / month-on-month trend line charts (last 12 months), and an anomaly warning dashboard (regions with payment rates below 80% are highlighted in red). After logging in, regional managers (ROLE_REGION_ADMIN) see their homepage automatically filtered to display data for 3-5 regions under their jurisdiction, showing the regional payment rate, project ranking (within their jurisdiction), arrears structure analysis (pie chart showing the percentage of arrears within 1 month / 1-3 months / over 3 months), and the ranking of the manager's collection conversion rate. The Project Manager (ROLE_PROJECT_STEWARD) logs in to the H5 mobile app. The homepage displays the project's to-do list: the number of owners awaiting payment reminders today (sorted by AI priority), the progress of payments made this week, and the distribution of owner payment profile tags. It supports one-click phone calls, SMS sending, and marking of visit results. Data permission verification uses OAuth2 Tokens to parse role identifiers, combined with a region-project-manager permission mapping table in MySQL, completing data range filtering within 100 milliseconds.

[0059] Implementation Results: In a practical deployment at a large property management group, the users covered included 5 members of the group's management team, 23 regional managers, and 860 project managers. User surveys showed that the group's management team's satisfaction with "data real-time performance" increased from 3.2 out of 5 (out of 5) to 4.6; regional managers' satisfaction with "visualized management radius" increased from 3.5 to 4.5; and project managers' satisfaction with "simplified work interface" increased from 3.0 to 4.7. The average information acquisition efficiency (time required to find key decision-making information) for users at all levels improved by 55%.

[0060] Implementation 7: Data Acquisition Mode Conflict Handling and Idempotency Guarantee Mechanism This invention employs three data acquisition modes (CDC monitoring, message subscription, and timed synchronization) working in parallel. The same data may enter the system simultaneously through different channels. To address this scenario, a comprehensive deduplication and idempotency guarantee mechanism, as well as data uniqueness verification logic, have been established. 1. Data Primary Key Definition (1) Business primary key combination: "table name + primary key ID + timestamp (ns)" is used as the globally unique identifier. ① Format: {database}.{table}:{primary_key_value}:{ts_ns} ② Example: tq-charge-11.charge_customerchargedetail:110012351549:1739792359315241000 (2) CDC Metadata Tracking: Utilizing metadata fields provided by Debezium ①source.file: MySQL binlog file name ②source.pos: binlog position offset ③ source.ts_ms / ts_us / ts_ns: Timestamp of the event (milliseconds / microseconds / nanoseconds) ④source.gtid: Global Transaction ID (GTID) 2. Idempotency guarantee mechanism: (1) Redis distributed lock + timestamp comparison (2) Database unique index + ON DUPLICATE KEY UPDATE 3. Multi-channel data conflict resolution strategy: Based on the following data priority rules (1) CDC data priority: CDC data based on binlog has the highest priority (ts_ns has the highest precision). (2) Message subscription is the next best option: Kafka / RabbitMQ messages carry event timestamps. (3) Minimum timed synchronization: Data generated by polling is used as a backup solution. Implementation 8: Guaranteeing Consistency Between ClickHouse and MySQL Writes Addressing the technical challenges of dual-write operations in a distributed environment where traditional ACID transactions are unusable, ClickHouse does not support cross-database transactions, and network partitions may cause partial write failures, the system adopts an "eventual consistency" solution. Specifically, it employs a "local message table pattern" + "Saga distributed transaction pattern" + "TCC". The "local message table" handles dual writes within a local transaction and records the asynchronous message delivery status, idempotently consuming and writing back the local table status on the ClickHouse and MySQL consumer sides. The "Saga distributed transaction" handles long transactions and complex business processes across microservices, such as when transaction data is revoked or deleted, requiring this pattern to ensure strong data consistency across database storage. Furthermore, during dual writes, the TCC pattern performs pre-checks on resources and two-phase commit to ensure consistency during local dual writes.

[0061] Implementation Nine: Data Consistency Monitoring and Recovery For the actual revenue data from the charging system, a timed interval data comparison task is performed every 5 minutes. Key data dimensions within the current interval are queried via API for comparison, discrepancies are identified, and key fields are overwritten using a dual-end replica storage system (ClickHouse and MySQL) based on the charging system's data source.

[0062] Implementation 10: AI-powered automatic payment collection model training and update mechanism Feature engineering is performed using a pipeline architecture. The feature dimensions of the homeowner profile are shown in Table 1. Table 1

[0063] The model performance evaluation metrics are shown in Table 2: Table 2

[0064] Implementation XI: Data Security and Privacy Compliance Mechanism When training models and exposing data via API, the system of this invention will perform anonymization or AES encryption on the transmission and storage of the owner's privacy data. The anonymized data is classified and categorized as shown in Table 3. Table 3

[0065] In addition, through cooperation with China Unicom, the privacy number provided by China Unicom enables the protection of the personal privacy of both the housekeeper and the homeowner when the housekeeper communicates with the homeowner by phone.

[0066] Implementation 12: Access Auditing and Access Control This system provides a comprehensive management system. It employs a robust RABC (Restricted Access Control) permission model, intercepting and verifying permissions for every interface, menu, and button, and recording operation logs. Simultaneously, the system has a comprehensive audit log table, storing anonymized audit logs for all critical operations entering the system, ensuring that relevant audit logs can be quickly exported as needed.

[0067] To ensure high availability of middleware such as Clickhouse, Redis, and MQ, the operations team can directly purchase Alibaba Cloud products. Each middleware component is configured with corresponding alarm thresholds through the Alibaba Cloud management console, ensuring that operations can promptly understand the health status of each component. Simultaneously, each middleware component is deployed in a multi-node cluster to avoid a cascading failure effect caused by a single node failure. Alibaba Cloud provides a robust snapshot mechanism for each middleware component, supporting data restoration to a specified time interval as needed, ensuring rollback and rapid recovery in the event of irreversible data errors. Through these mechanisms, the system can operate smoothly even with a data volume of 1 billion records.

[0068] The above are merely embodiments of the present invention. Commonly known technical solutions and / or characteristics are not described in detail here. It should be noted that those skilled in the art can make various modifications and improvements without departing from the technical solution of the present invention, and these should also be considered within the scope of protection of the present invention. These modifications and improvements will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A fee management platform based on the integration of related data, characterized in that: This includes a layered and decoupled deployment of a data acquisition layer, a heterogeneous data storage layer, a compass core task set, a data service layer, and a presentation layer; The data acquisition layer is configured with at least three heterogeneous data acquisition modes, including: Message subscription mode: The business system actively publishes data change messages to the MQ middleware, and the MQ data change subscription service subscribes in real time and pushes them to the data storage layer; Asynchronous active fetch mode: The data API collection service actively fetches data from the business system through distributed task scheduling and writes it to the data storage layer through a compensation update mechanism; CDC Active Monitoring Mode: The CDC Data Change Monitoring Service actively monitors changes in the Binlog of the business storage database, captures data changes in real time, and pushes them to the data storage layer; The heterogeneous data storage layer includes at least four storage engines: A MySQL relational database used to store structured business data, with a record volume exceeding 5 million records; Redis is a cache database that caches frequently accessed billing metrics and supports concurrent queries of over 100,000 QPS. The Elasticsearch search engine stores text-based data such as operation logs and payment reminders. ClickHouse columnar database stores time-series billing details data, with a data volume of over 1 billion records, and supports second-level OLAP aggregation queries. The core mission set of the compass includes: The asynchronous timed data acquisition module collects incremental data from various business systems every day at midnight and cleans and standardizes it. The data analysis and statistics module, based on ClickHouse, calculates three-level charging indicators for groups, regions, and projects, with a calculation delay of less than 3 seconds. The AI-powered automatic payment reminder module builds payment profile tags based on homeowners' historical payment behavior data, intelligently identifies high-value payment opportunities, and generates personalized payment reminder strategies. The data service layer includes REST API services, backend management basic services, and asynchronous job task services; and The presentation layer consists of a PC web application based on the Vue / React technology stack and an H5 mobile application based on uni-app. Data access control enables differentiated data display for three levels of roles: group management, regional managers, and project managers.

2. The charging management platform based on associated data integration according to claim 1, characterized in that, The fee management method based on the integration of related data includes the following steps: S1. Data Acquisition: Collect at least 12 types of fee-related data fields, including region, project, owner's name, room number, amount owed, amount owed at the beginning of the period, amount owed at the end of the period, payment amount, payment subject, discount amount, property manager's collection action records, owner payment profile tags, and finalized financial data. S2. Multi-source heterogeneous data aggregation: Three data acquisition modes are adopted: message subscription mode, asynchronous active pull mode, and CDC active monitoring mode to achieve real-time aggregation of multi-source heterogeneous data; S3, Heterogeneous Data Storage and Tiling: Write structured business data into a MySQL relational database, cache hot billing metrics in Redis, and write operation logs and payment reminder records into Elasticsearch, and write time-series billing details into a ClickHouse columnar database; S4. Data Calculation and Task Scheduling: Collect incremental data from the previous day at a set time in the early morning and clean and standardize it; calculate the three-level charging indicators of group, region and project based on ClickHouse, and control the calculation delay within 3 seconds; build payment profile tags based on the owner's historical payment behavior, intelligently identify high-value collection opportunities and generate personalized collection strategies. S5. Data Services and Differentiated Display: Provides standardized data interfaces through REST APIs, and enables differentiated data display for three levels of roles: group management, regional managers, and project managers through PC web and H5 mobile terminals.

3. The charging management platform based on associated data integration according to claim 2, characterized in that, The message subscription model includes: the billing system service acts as a business system, actively publishing messages to the RabbitMQ / Kafka middleware when payment or overdue payment update business events occur; the MQ data change subscription service subscribes to relevant topics, receives change messages in real time, parses them, and synchronously pushes them to MySQL and ClickHouse for storage updates, with end-to-end data synchronization latency controlled within 500 milliseconds.

4. The charging management platform based on associated data integration according to claim 2, characterized in that, The asynchronous active retrieval mode includes: the data API collection service periodically retrieves data from the business system through the XXL-JOB distributed task scheduling platform, compares the data with the previous collection points through a compensation update mechanism, synchronizes only incremental data, and writes it to the MySQL relational database.

5. The charging management platform based on associated data integration according to claim 2, characterized in that, The CDC proactive monitoring mode includes: deploying the CDC data change monitoring service based on Canal or Debezium, proactively monitoring the Binlog logs of the business storage database, capturing change events of the final financial data, parsing the data mirror before and after the change in real time and pushing it to the data storage layer, achieving non-intrusive data synchronization without modifying legacy system interfaces.

6. The charging management platform based on associated data integration according to claim 2, characterized in that, The calculation of three-level charging indicators for groups, regions, and projects based on ClickHouse includes: using ClickHouse's columnar storage and vectorized computing capabilities to aggregate and calculate more than 1 billion charging details data from the past 3 years, and generate at least 4 complex indicators in real time, including payment rate, arrears aging structure, year-on-year and month-on-month trends, and housekeeper reminder conversion rate, with the response time of a single aggregate query controlled within 3 seconds.

7. The charging management platform based on associated data integration according to claim 2, characterized in that, The payment profile tags built based on homeowners' historical payment behavior include: collecting homeowners' payment timeliness data, payment channel preference data, and overdue payment frequency data for the past 24 months, and using clustering algorithms to classify homeowners into at least three profile tags: timely payment type, reminder payment type, and difficult payment type; intelligent identification of high-value repayment opportunities includes: building a repayment probability prediction model based on profile tags, current overdue amount, overdue duration, and historical reminder response rate to identify high-value homeowners with a repayment probability greater than 70%; and generating personalized collection strategies includes: sending SMS reminders to timely payment type homeowners, making phone calls to remind payment type homeowners, and arranging home visits to difficult payment type homeowners, with strategy generation and push delays controlled within 5 minutes.

8. The fee management platform based on associated data integration according to claim 2, characterized in that, The differentiated data display for the three roles includes: Group management displays the full group's billing dashboard, including macro indicators such as the group's overall payment rate, regional ranking, and year-on-year trends; Regional managers display data for their respective regions, including meso indicators such as regional payment rate, project ranking, and arrears structure analysis; Project managers display details for their projects, including micro indicators such as individual household arrears details, collection action records, and homeowner payment profiles; Data access control is implemented through Spring Security OAuth2 to ensure that each role can only access data within its authorized scope, and the data access verification latency is controlled within 100 milliseconds.

9. The fee management platform based on associated data integration according to claim 2, characterized in that, Among the 12 categories of fee-related data fields, the housekeeper's reminder action record field includes three quantitative indicators: number of phone calls, number of home visits, and number of text messages. The owner's payment profile label field includes three classification labels: timely payment type, reminder payment type, and difficult payment type. The financial finalization data field includes monthly financial statement verification data.

10. The charging management platform based on associated data integration according to claim 2, characterized in that, The data service layer also includes the Compass API interface service, which directly queries the business storage database through the real-time data channel to obtain real-time billing data. As a supplement to the three collection modes of message subscription mode, asynchronous active pull mode, and CDC active monitoring mode, it is used to handle temporary and non-periodic real-time data query requests, and the query response time is controlled within 200 milliseconds.

Images