A telephone bill data processing method and device, electronic equipment and storage medium

Abstract

This application provides a call detail record (CDR) data processing method, apparatus, electronic device, and storage medium. The method includes: acquiring CDR data, which includes uplink data and downlink data, wherein the downlink data includes a submission form and a corresponding receipt; determining a message identifier for the CDR data based on the submission form and the corresponding receipt; setting the message identifier as an identifier for a key-value pair and setting the CDR data as the specific value of the key-value pair; and then caching the key-value pair in an in-memory database, which is used to retrieve the CDR data corresponding to the message identifier. In the above implementation, since the in-memory database is directly stored in memory, and the access speed of the in-memory database is much faster than that of a distributed file system, the data user can retrieve the CDR data corresponding to the message identifier almost in real time, thereby effectively improving the real-time performance of associating CDR data.

Description

Technical Field

[0001] This application relates to the technical fields of big data and cloud computing, and more specifically, to a method, apparatus, electronic device, and storage medium for processing call detail record (CDR) data. Background Technology

[0002] A Distributed File System (DFS), also known as a Network File System, is a file system that allows files to be shared across multiple hosts over a network. The physical storage resources managed by the file system are typically connected to nodes via a computer network; or a complete file system formed by combining several different logical disk partitions or volume labels.

[0003] Currently, the typical approach to processing call detail record (CDR) data is to store the collected data in a distributed file system (DFS) such as Hadoop Distributed File System (HDFS). Then, message identifiers are used to associate the submitted and received records within the CDR data, allowing data users (e.g., clients or servers) to extract the corresponding CDR data. However, in practice, it has been found that the capability platform on the telecom server experiences a delay in generating received records based on submitted records. Furthermore, the delay in associating CDR data with message identifiers after the received records are generated and stored in DFS is significant. In other words, the real-time performance of associating CDR data after the received records are generated and stored in DFS is not high. Summary of the Invention

[0004] The purpose of this application is to provide a call detail record (CDR) data processing method, apparatus, electronic device, and storage medium to improve the problem of low real-time performance in associating CDR data.

[0005] This application provides a method for processing call detail record (CDR) data, including: acquiring CDR data, which includes uplink data and downlink data, with the downlink data including a submission form and a corresponding receipt; determining a message identifier for the CDR data based on the submission form and the corresponding receipt; setting the message identifier as an identifier for a key-value pair and setting the CDR data as the specific value of the key-value pair; and then caching the key-value pair in an in-memory database, which is used to extract the CDR data corresponding to the message identifier. In the above implementation, after acquiring the CDR data, the message identifiers of the submission forms and receipts in the associated CDR data are directly stored in an in-memory database. Since the in-memory database is directly stored in memory, it does not need to search for storage nodes like a distributed file system, and its access speed is much faster than that of a distributed file system. This allows data users to extract the CDR data corresponding to the message identifier almost in real time, thereby effectively improving the real-time performance of associating CDR data.

[0006] Optionally, in this embodiment, after caching the key-value pairs in the memory database, the method further includes: extracting the call detail record (CDR) data corresponding to the message identifier from the memory data; performing dimensional analysis on the CDR data to obtain dimensional data; and storing the dimensional data in a relational database or a distributed search engine. In the above implementation process, by extracting the CDR data corresponding to the message identifier from the memory data and storing the dimensional data obtained from the CDR data analysis in a relational database or a distributed search engine, the dimensional data can be better queried and used by the relational database or distributed search engine, effectively improving the utilization efficiency and real-time query performance of the CDR data and dimensional data.

[0007] Optionally, in this embodiment, the call detail record (CDR) data undergoes dimensional analysis, including: obtaining the submission time from the submission form and the receipt time from the receipt form; and performing latency dimensional analysis on the CDR data based on the receipt time and the submission time. In the above implementation, by obtaining the submission time from the submission form and the receipt time from the receipt form, and performing latency dimensional analysis on the CDR data based on the receipt time and the submission time, the time latency related to the CDR data can be improved based on the results of the latency dimensional analysis, effectively improving the utilization efficiency and real-time performance of the CDR data and dimensional data.

[0008] Optionally, in this embodiment, after storing the dimension data in relational databases or a distributed search engine, the method further includes: receiving a data query request sent by a terminal device; querying the dimension data according to the data query request to obtain the query results corresponding to the data query request; and sending the query results to the terminal device. In the above implementation process, by receiving a data query request sent by a terminal device and querying the dimension data according to the data query request, the dimension data can be better queried and used, effectively improving the utilization efficiency and real-time query performance of call detail record (CDR) data and dimension data.

[0009] Optionally, in this embodiment, obtaining call detail record (CDR) data includes: acquiring uplink and downlink data from different topics of a distributed event stream platform using a streaming processing engine. In the above implementation, acquiring uplink and downlink data from different topics of a distributed event stream platform using a streaming processing engine improves upon the problems of data dispersion and large data volume in traditional data acquisition processes, effectively enhancing the real-time performance of CDR data processing.

[0010] Optionally, in this embodiment, determining the message identifier of the call detail record (CDR) data based on the submission form and the corresponding receipt form includes: determining whether the specific value of a preset field in the submission form is the same as the specific value of a preset field in the receipt form; if so, the specific value of the preset field is determined as the message identifier of the CDR data. In the above implementation, by associating the submission form and the receipt form based on the specific values ​​of the preset fields in both the submission form and the receipt form, i.e., determining the specific value of the preset field as the message identifier of the CDR data, the problem of low real-time performance caused by first storing the CDR data in the Hadoop Distributed File System and then associating it is avoided, effectively improving the real-time performance of associating CDR data.

[0011] Optionally, in this embodiment, the in-memory database is a Redis database; after caching the key-value pairs in the in-memory database, the method further includes: obtaining the identifier of the message to be queried, and extracting the call detail record (CDR) data corresponding to the CDR identifier from the Redis database. In the above implementation process, by obtaining the identifier of the message to be queried and extracting the CDR data corresponding to the CDR identifier from the Redis database, the CDR data can be better queried and used, effectively improving the utilization efficiency and real-time query performance of CDR data and dimension data.

[0012] This application also provides a call detail record (CDR) data processing apparatus, comprising: a CDR data acquisition module for acquiring CDR data, the CDR data including uplink data and downlink data, the downlink data including a submission form and a corresponding receipt form; a message identifier determination module for determining a message identifier for the CDR data based on the submission form and the corresponding receipt form; and a CDR data caching module for setting the message identifier as an identifier for a key-value pair, setting the CDR data as the specific value of the key-value pair, and then caching the key-value pair in a memory database, the memory database being used to extract the CDR data corresponding to the message identifier.

[0013] Optionally, in this embodiment of the application, the call detail record (CDR) data processing device further includes: a dimension data acquisition module, used to extract the CDR data corresponding to the message identifier from the memory data, perform dimension analysis on the CDR data, and obtain dimension data; and a dimension data storage module, used to store the dimension data in relational data or a distributed search engine.

[0014] Optionally, in this embodiment of the application, the dimension data acquisition module includes: a time data acquisition module, used to acquire the submission time from the submission form and the receipt time from the receipt form; and a latency dimension analysis module, used to perform latency dimension analysis based on the receipt time and submission time dialog form data.

[0015] Optionally, in this embodiment of the application, the call detail record (CDR) data processing device further includes: a query request receiving module, used to receive a data query request sent by a terminal device; a query result obtaining module, used to query the dimension data according to the data query request and obtain the query result corresponding to the data query request; and a query result sending module, used to send the query result to the terminal device.

[0016] Optionally, in this embodiment of the application, the call detail record (CDR) data acquisition module includes: a streaming processing acquisition module, used to acquire uplink and downlink data from different topics of the distributed event stream platform through a streaming processing engine.

[0017] Optionally, in this embodiment of the application, the message identifier determination module includes: a preset field judgment module, used to determine whether the specific value of the preset field of the submission form is the same as the specific value of the preset field of the receipt form; and a field identifier determination module, used to determine the specific value of the preset field as the message identifier of the call detail record data if the specific value of the preset field of the submission form is the same as the specific value of the preset field of the receipt form.

[0018] Optionally, in this embodiment, the in-memory database is a Redis database; the call detail record (CDR) data processing device further includes: a CDR data query module, used to obtain the identifier of the message to be queried and extract the CDR data corresponding to the identifier of the message to be queried from the Redis database.

[0019] This application also provides an electronic device, including a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the machine-readable instructions, when executed by the processor, perform the method described above.

[0020] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to perform the methods described above. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 The illustrated flowchart shows a call detail record (CDR) data processing method provided in an embodiment of this application.

[0023] Figure 2 The diagram shown is a flowchart illustrating the call detail record (CDR) data dimension analysis provided in an embodiment of this application.

[0024] Figure 3 The diagram shown is a schematic representation of the dimensional data processing flow provided in an embodiment of this application.

[0025] Figure 4 The illustration shown is a flowchart of querying call detail record (CDR) data from an in-memory database according to an embodiment of this application.

[0026] Figure 5 The diagram shown is a structural schematic of the call detail record (CDR) data processing device provided in an embodiment of this application.

[0027] Figure 6 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0029] Before introducing the call detail record (CDR) data processing method provided in the embodiments of this application, let's first introduce some concepts involved in the embodiments of this application:

[0030] Apache Spark, also known as Spark for short, is an open-source cluster computing system based on in-memory computing, and also an open-source cluster computing framework that makes data analysis faster; when migrating Oracle data to a big data environment, data analysis is required.

[0031] Spark Core is the foundation of the entire project, providing distributed task scheduling, scheduling, and basic input / output (IO) functionality; while its underlying program abstraction is called Resilient Distributed DataSets (RDDs), which is a collection of data that can be operated on in parallel and has fault tolerance mechanisms.

[0032] Spark Streaming is a streaming engine that fully leverages the fast scheduling capabilities of the Spark core to run streaming analytics. Spark Streaming captures small batches of data and performs Resilient Distributed Data (RDD) transformations on them; this design allows streaming analytics to use the same set of application code written for batch analysis within the same engine.

[0033] An in-memory database is a collection of data that is accessed based on random access memory (RAM). It is characterized by fast read and write speeds and is therefore also known as a cache database.

[0034] It should be noted that the call detail record (CDR) data processing method provided in this application embodiment can be executed by an electronic device. Here, an electronic device refers to a device terminal or server with the function of executing computer programs. Device terminals include, for example, smartphones, personal computers (PCs), tablet computers, personal digital assistants (PDAs), or mobile Internet devices (MIDs). Servers include, for example, x86 servers and non-x86 servers. Non-x86 servers include, for example, mainframes, minicomputers, and UNIX servers.

[0035] Before introducing the call detail record (CDR) data processing method provided in the embodiments of this application, we will first introduce the application scenarios to which this CDR data processing method is applicable. These application scenarios include, but are not limited to: using this CDR data processing method to improve the real-time performance and accuracy of a large amount of SMS call detail record data, and also using this CDR data processing method to perform multi-dimensional processing of call detail record data, thereby generating more business value from more dimensions of the call detail record data.

[0036] Please see Figure 1 The illustrated flowchart shows a call detail record (CDR) data processing method provided in this application embodiment. The main idea of ​​this CDR data processing method is to directly store the message identifiers of the submission and receipt records in the associated CDR data, along with the CDR data itself, into an in-memory database after acquiring the CDR data. Since the in-memory database is stored directly in memory, it does not require searching for storage nodes like a distributed file system. Furthermore, the access speed of the in-memory database is much faster than that of a distributed file system, enabling data users to extract the CDR data corresponding to the message identifier almost in real-time. This effectively improves the real-time performance of associating CDR data. The aforementioned CDR data processing method may include:

[0037] Step S110: Obtain call detail record (CDR) data. The CDR data includes uplink data and downlink data. The downlink data includes a submission form and the corresponding receipt form.

[0038] Call detail records (CDRs) refer to the documents generated in the telecommunications industry for SMS or call services. These CDRs include: uplink data sent from a mobile number to a service provider (SP) number and downlink data sent from the service provider number to the mobile number. The service provider can be a company in the telecommunications industry or another industry. Uplink data can include D-CDRs, and downlink data includes: D-CDRs, submission forms (also known as S-CDRs), and corresponding receipts (also known as R-CDRs).

[0039] Call detail record (CDR) data is real-time CDR content collected and parsed into TXT text by the collect program and uploaded to different topics on the distributed event streaming platform Kafka. For example, step S110 can be implemented by using a collection program (e.g., the collect program) to collect three types of real-time CDR data (D CDR, submission CDR, and receipt CDR). These three types of raw real-time CDR data can also be parsed into plain text format (e.g., TXT format) CDR data, and then uploaded to different topics on the distributed event streaming platform (e.g., Kafka). This effectively achieves physical isolation of the CDR data and reduces the pressure on the collection program. Uplink and downlink data are obtained from different topics on the distributed event streaming platform (e.g., Kafka) using a streaming engine (e.g., Spark Streaming). Downlink data requires relaying through the telecom company's capability platform. The aforementioned S-order refers to the document sent by the service provider (SP) to the telecom company's capability platform, while the R-order refers to the document sent by the telecom company's capability platform to the mobile phone number.

[0040] After step S110, step S120 is executed: determine the message identifier of the call detail record data based on the submission form and the corresponding receipt form.

[0041] The implementation of step S120 above may include:

[0042] Step S121: Determine whether the specific values ​​of the preset fields in the submission form are the same as the specific values ​​of the preset fields in the receipt form.

[0043] Preset fields refer to common identifier fields in the submission form and the receipt form. If the specific value of the preset field in the submission form is the same as the specific value of the preset field in the receipt form, it means that the submission form and the receipt form are from the same call detail record (CDR) data. In specific business operations, the submission form and the receipt form should be associated.

[0044] The implementation of step S121 above can be exemplified as follows: Assume the specific value of the preset field in the submission form is 123456. If the specific value of the preset field in the receipt is 654321, then it is clear that the specific values ​​of the preset fields in the submission form and the receipt are different. Conversely, if the specific value of the preset field in the receipt is also 123456, then it is clear that the specific values ​​of the preset fields in the submission form and the receipt are the same. The submission forms and receipts mentioned above can come from different topics on a distributed event streaming platform (e.g., Kafka), or they can come from the same topic on the same distributed event streaming platform (e.g., Kafka).

[0045] Step S122: If the specific value of the preset field of the submission form is the same as the specific value of the preset field of the receipt form, then the specific value of the preset field is determined as the message identifier of the call detail record data.

[0046] For example, the implementation of step S122 above is as follows: Suppose the specific value of the preset field of the submission form is 123456. If the specific value of the preset field of the receipt is also 123456, it is obvious that the specific value of the preset field of the submission form is the same as the specific value of the preset field of the receipt. Then the submission form and the receipt should be associated, that is, the specific value of the preset field is determined as the message identifier of the call detail record data. Then the submission form and the receipt in the call detail record data can be found by the message identifier.

[0047] After step S120, step S130 is executed: the message identifier is set as the identifier of the key-value pair, and the call detail record data is set as the specific value of the key-value pair. Then, the key-value pair is cached in the memory database, which is used to extract the call detail record data corresponding to the message identifier.

[0048] An example implementation of step S130 above is as follows: The message identifier is set as the identifier (i.e., the Key) of a key-value pair, and the call detail record (CDR) data is set as the specific value (i.e., the Value) of the key-value pair. Then, the key-value pair is cached in an in-memory database, which is used to retrieve the CDR data corresponding to the message identifier. The in-memory database can be a Redis database or a Memcached database, etc. After caching the key-value pair in the in-memory database, the CDR data for the message identifier (e.g., 123456) can be retrieved from the Redis database or Memcached database, etc. This CDR data includes: D-type CDRs, submission records, and receipt records.

[0049] In the above implementation process, firstly, the message identifier of the call detail record (CDR) data is determined based on the submission form and its corresponding receipt. Then, the message identifier is set as the identifier of the key-value pair, and the CDR data is set as the specific value of the key-value pair. Finally, the key-value pair is cached in an in-memory database. In other words, after retrieving the CDR data, the message identifiers of the submission and receipt forms and the CDR data associated with it are directly stored in an in-memory database. Since the in-memory database is directly stored in memory, it does not need to search for storage nodes like a distributed file system. Furthermore, the access speed of the in-memory database is much faster than that of a distributed file system. This allows data users to extract the CDR data corresponding to the message identifier almost in real time, effectively improving the real-time performance of associating CDR data.

[0050] Please see Figure 2 The illustrated flowchart shows a call detail record (CDR) data dimensional analysis process provided in this application embodiment. Optionally, in this application embodiment, after caching the key-value pairs in the memory database, dimensional analysis can also be performed. The implementation methods of dimensional analysis may include:

[0051] Step S210: The electronic device extracts the call detail record (CDR) data corresponding to the message identifier from the memory data, performs dimensional analysis on the CDR data, and obtains dimensional data.

[0052] The implementation method for extracting the call detail record (CDR) data corresponding to the message identifier from the memory data in step S210 above includes: obtaining the CDR data of the message identifier (e.g., 123456) from a Redis database or a Memcached database, etc. The CDR data includes: D CDR, submission form, and receipt form.

[0053] There are many ways to perform dimensional analysis on the dialog box data in step S210 above, including but not limited to the following:

[0054] The first dimensional analysis method analyzes time delay based on the time delay dimension of the dialog box data. This dimensional analysis method can include:

[0055] Step S211: Obtain the submission time from the submission form and the receipt time from the receipt form.

[0056] For example, after obtaining the call detail record (CDR) data of the message identifier (e.g., 123456) from the memory database, the submission time (also known as the submission time) can be obtained from the submission form, and the receipt time (also known as the receipt time) can be obtained from the receipt form.

[0057] Step S212: Perform latency analysis based on the dialog box data at the receipt time and submission time.

[0058] For example, step S212 can be implemented by subtracting the submission time from the receipt time to obtain the time delay of the call detail record (CDR) data (e.g., if the CDR data is a short message). In practice, other delay dimension analyses can also be performed, such as: statistical indicators like the maximum, average, median, variance, and standard deviation of delay for major customer service provider (SP) numbers, and various statistical indicators of short message time delay for a specific province can also be calculated.

[0059] The second dimension analysis method is to analyze the business volume of the call log data. For example, the business volume dimension analysis is mainly to statistically analyze the business volume in order to provide better service; specifically, it can be used to count the number of SMS messages sent by a major customer in a certain period of time (e.g., the day or the month), or to count the number of SMS messages sent by a certain province in a certain period of time (e.g., the day or the month).

[0060] The third dimension analysis method analyzes dialog box data according to the status code dimension (also known as the error code dimension). For example, in specific practice, if a service provider (SP) fails to send an SMS to a mobile phone number, an error code message will be generated. This allows for the statistical analysis of the number of error codes sent by a major customer or a certain province within a certain time period (such as the current day or the current month), thereby monitoring the probability of failure for a major customer or a certain province and the average recovery time after a failure, etc.

[0061] The fourth dimension of analysis involves analyzing call log data based on the number of users. This dimension includes, for example, counting the number of mobile phone numbers sent by each major customer (corresponding service provider) and the number of SMS messages sent to those numbers. Specifically, mobile phone numbers or SMS messages can be categorized according to various dimensions, such as number ranges or regions. Furthermore, mobile phone numbers can be deduplicated to count how many mobile phone numbers each major customer (corresponding service provider) sent SMS messages to.

[0062] The fifth dimension of analysis involves analyzing call detail record (CDR) data based on peak values. For example, during the processing of CDR data, there are peak values ​​every second of every minute, every minute, every hour, every week, and so on. Specifically, this allows for the statistical analysis of peak values ​​for a major customer or a specific province within a certain time period (e.g., the current hour), thereby reflecting the business capability indicators of that customer or province.

[0063] After step S210, step S220 is executed: the electronic device stores the dimensional data into relational data or a distributed search engine.

[0064] Please see Figure 3 The diagram illustrates the dimensional data processing flow provided in this application embodiment. For example, step S220 can be implemented by storing the obtained dimensional data in a relational database or a distributed search engine. Relational databases that can be used include MySQL, PostgreSQL, Oracle, and SQL Server. The distributed search engine can be Elasticsearch, which is a distributed, highly scalable, and real-time search and data analysis engine. It is also a distributed, multi-user, full-text search engine. Elasticsearch can easily enable large amounts of data to be searched, analyzed, and explored. Fully utilizing Elasticsearch's horizontal scalability can make data more valuable in a production environment.

[0065] In the above implementation process, by extracting the call detail record (CDR) data corresponding to the message identifier from the memory data, and storing the dimension data analyzed from the CDR data into relational databases or distributed search engines, the dimension data can be better queried and used by relational databases or distributed search engines, effectively improving the utilization efficiency and real-time query performance of CDR data and dimension data.

[0066] Optionally, in this embodiment of the application, after storing the dimension data in relational databases or a distributed search engine, the dimension data can also be queried. Implementation methods for querying dimension data include:

[0067] After step S220, step S230 is executed: the electronic device receives a data query request sent by the terminal device.

[0068] For example, in the above-mentioned step S230, the terminal device sends a data query request to the electronic device. The data query request includes the dimension identifier and dimension parameters to be queried. The electronic device receives the data query request sent by the terminal device through Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS).

[0069] After step S230, step S240 is executed: the electronic device queries the dimensional data according to the data query request and obtains the query results corresponding to the data query request.

[0070] For example, the implementation of step S240 above is as follows: After receiving a data query request sent by the terminal device, the electronic device parses the data query request to obtain the dimension identifier and dimension parameters to be queried; then, according to the dimension identifier and dimension parameters to be queried, it queries the dimension data in relational databases such as MySQL, PostgreSQL, Oracle, and SQL Server or distributed search engines (such as ElasticSearch) to obtain the query results corresponding to the data query request.

[0071] After step S240, step S250 is executed: the electronic device sends the query result to the terminal device.

[0072] For example, in the above-mentioned step S250, the electronic device sends the query result corresponding to the data query request to the terminal device via the HTTP protocol or the HTTPS protocol, so that the terminal device can perform further processing on the query result after receiving the query result sent by the electronic device.

[0073] In the above implementation process, by receiving data query requests sent by terminal devices and querying dimensional data according to the data query requests, the dimensional data can be better queried and used, effectively improving the utilization efficiency and real-time querying of call detail record data and dimensional data.

[0074] Please see Figure 4The illustrated embodiment of this application provides a flowchart for querying call detail record (CDR) data from an in-memory database. Optionally, after caching key-value pairs in the in-memory database, CDR data can also be queried from the in-memory database. Implementation methods for querying CDR data may include:

[0075] Step S310: The electronic device obtains the identifier of the message to be queried.

[0076] There are many ways to obtain the message identifier to be queried in step S310 above, including but not limited to: the first method is to receive the message identifier to be queried sent by other terminal devices and store the message identifier to be queried in a file system, database or mobile storage device; the second method is to obtain the message identifier to be queried that has been pre-stored by other applications, specifically, for example, obtaining the message identifier to be queried from the file system, or obtaining the message identifier to be queried from the database, or obtaining the message identifier to be queried from the mobile storage device; the third method is to use an application or software to obtain the message identifier to be queried on the server, etc.

[0077] Step S320: The electronic device extracts the call detail record (CDR) data corresponding to the message identifier to be queried from the Redis database.

[0078] The implementation of step S320 above can be exemplified by, for example, the electronic device retrieving the call detail record (CDR) data corresponding to the message identifier to be queried from the Redis database and sending the CDR data to other terminal devices, or storing the CDR data in a file system, database, or mobile storage device, etc. In the above implementation process, by obtaining the message identifier to be queried and retrieving the corresponding CDR data from the Redis database, the CDR data can be better queried and used, effectively improving the utilization efficiency and real-time query performance of CDR data and dimensional data.

[0079] Please see Figure 5 The diagram shown is a structural schematic of the call detail record (CDR) data processing device provided in this application embodiment; this application embodiment provides a CDR data processing device 400, including:

[0080] Call detail record (CDR) data acquisition module 410 is used to acquire CDR data, which includes uplink data and downlink data. Downlink data includes submission orders and corresponding receipts.

[0081] The message identifier determination module 420 is used to determine the message identifier of the call detail record data based on the submission form and the corresponding receipt form.

[0082] The call detail record (CDR) data caching module 430 is used to set the message identifier as the identifier of the key-value pair and set the CDR data as the specific value of the key-value pair. Then, the key-value pair is cached in the memory database, which is used to extract the CDR data corresponding to the message identifier.

[0083] Optionally, in this embodiment of the application, the call detail record (CDR) data processing device further includes:

[0084] The dimensional data acquisition module is used to extract call detail records (CDRs) corresponding to message identifiers from memory data, perform dimensional analysis on the CDRs, and obtain dimensional data.

[0085] The dimensional data storage module is used to store dimensional data in relational databases or distributed search engines.

[0086] Optionally, in this embodiment of the application, the dimension data acquisition module includes:

[0087] The time data acquisition module is used to obtain the submission time from the submission form and the receipt time from the receipt form.

[0088] The latency dimension analysis module is used to perform latency dimension analysis based on the receipt time and submission time of the dialog box data.

[0089] Optionally, in this embodiment of the application, the call detail record (CDR) data processing device further includes:

[0090] The query request receiving module is used to receive data query requests sent by terminal devices.

[0091] The query results acquisition module is used to query the dimensional data according to the data query request and obtain the query results corresponding to the data query request.

[0092] The query result sending module is used to send query results to terminal devices.

[0093] Optionally, in this embodiment of the application, the call detail record (CDR) data acquisition module includes:

[0094] The streaming acquisition module is used to acquire upstream and downstream data from different topics on the distributed event stream platform through the streaming engine.

[0095] Optionally, in this embodiment of the application, the message identifier determination module includes:

[0096] The preset field judgment module is used to determine whether the specific values ​​of the preset fields in the submission form are the same as the specific values ​​of the preset fields in the receipt form.

[0097] The field identifier determination module is used to determine the specific value of the preset field as the message identifier of the call detail record data if the specific value of the preset field in the submission form is the same as the specific value of the preset field in the receipt form.

[0098] Optionally, in this embodiment, the in-memory database is a Redis database; the call detail record (CDR) data processing device further includes:

[0099] The call detail record (CDR) data query module is used to obtain the identifier of the message to be queried and extract the CDR data corresponding to the identifier of the message to be queried from the Redis database.

[0100] It should be understood that this device corresponds to the above-described call detail record (CDR) data processing method embodiment and is capable of performing the various steps involved in the above method embodiment. The specific functions of this device can be found in the description above, and detailed descriptions are omitted here to avoid repetition. The device includes at least one software functional module that can be stored in memory or embedded in the device's operating system (OS) in the form of software or firmware.

[0101] Please see Figure 6 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. An electronic device 500 provided in this application includes a processor 510 and a memory 520. The memory 520 stores machine-readable instructions executable by the processor 510. When the machine-readable instructions are executed by the processor 510, the method described above is performed.

[0102] This application embodiment also provides a computer-readable storage medium 530, on which a computer program is stored, and the computer program is executed by a processor 510 to perform the above method.

[0103] The computer-readable storage medium 530 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0104] It should be understood that the disclosed apparatus and methods can also be implemented in other ways, as provided in the embodiments of this application. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending primarily on the functions involved.

[0105] In addition, the functional modules of each embodiment in the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0106] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0107] The above description is only an optional implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application.

Claims

1. A method for processing call detail record (CDR) data, characterized in that, include: Obtain call detail record (CDR) data, which includes uplink data and downlink data, wherein the downlink data includes a submission form and a corresponding receipt form. The message identifier of the call detail record data is determined based on the submission form and the corresponding receipt form. The message identifier is set as the identifier of the key-value pair, and the call detail record (CDR) data is set as the specific value of the key-value pair. Then, the key-value pair is cached in an in-memory database, which is used to extract the CDR data corresponding to the message identifier. Specifically, the in-memory database is used to: extract the CDR data corresponding to the message identifier in real time after the receipt is generated, so as to associate the submission form with the receipt in real time. The call detail record (CDR) data is real-time CDR content collected by the collect program, parsed into txt text, and uploaded to different topics of the distributed event stream platform Kafka. The acquisition of CDR data includes: obtaining the uplink data and the downlink data from different topics of the distributed event stream platform through a streaming processing engine; the CDR data is a document for SMS service or communication service. After caching the key-value pairs in the memory database, the method further includes: extracting the call detail record (CDR) data corresponding to the message identifier from the memory data; performing dimensional analysis on the CDR data to obtain dimensional data; and storing the dimensional data in a relational database or a distributed search engine. The in-memory database is a Redis database; after caching the key-value pairs in the in-memory database, the method further includes: obtaining the identifier of the message to be queried, and extracting the call detail record data corresponding to the identifier of the message to be queried from the Redis database.

2. The method according to claim 1, characterized in that, The dimensional analysis of the call detail record (CDR) data includes: Obtain the submission time from the submission form and the receipt time from the receipt form; The call detail record (CDR) data is analyzed for latency based on the receipt time and the submission time.

3. The method according to claim 1, characterized in that, After storing the dimensional data in relational databases or a distributed search engine, the method further includes: Receive data query requests sent by terminal devices; The data of the dimension is queried according to the data query request to obtain the query result corresponding to the data query request; The query result is sent to the terminal device.

4. The method according to claim 1, characterized in that, The step of determining the message identifier of the call detail record (CDR) data based on the submission form and the corresponding receipt form includes: Determine whether the specific values ​​of the preset fields in the submission form are the same as the specific values ​​of the preset fields in the receipt form; If so, the specific value of the preset field will be determined as the message identifier of the call detail record (CDR) data.

5. A call detail record (CDR) data processing device, characterized in that, include: The call detail record (CDR) data acquisition module is used to acquire CDR data, which includes uplink data and downlink data. The downlink data includes a submission form and a corresponding receipt form. The message identifier determination module is used to determine the message identifier of the call detail record data based on the submission form and the corresponding receipt form. The call detail record (CDR) data caching module is used to set the message identifier as the identifier of a key-value pair, set the CDR data as the specific value of the key-value pair, and then cache the key-value pair in a memory database. The memory database is used to extract the CDR data corresponding to the message identifier. Specifically, the memory database is used to: extract the CDR data corresponding to the message identifier in real time after the receipt is generated, so as to associate the submission form with the receipt in real time. The call detail record (CDR) data is real-time CDR content collected by the collect program, parsed into txt text, and uploaded to different topics of the distributed event stream platform Kafka. The call detail record (CDR) data acquisition module includes: The streaming processing acquisition module is used to acquire the uplink data and the downlink data from different topics of the distributed event stream platform through the streaming processing engine. The call detail record (CDR) data refers to documents for SMS or communication services. The device further includes: The dimension data acquisition module is used to extract the call detail record (CDR) data corresponding to the message identifier from the memory data, perform dimensional analysis on the CDR data, and obtain dimensional data. The dimension data storage module is used to store the dimension data in relational databases or a distributed search engine; The in-memory database is a Redis database, and the device further includes: The call detail record (CDR) data query module is used to obtain the identifier of the message to be queried and extract the CDR data corresponding to the identifier of the message to be queried from the Redis database.

6. An electronic device, characterized in that, include: A processor and a memory, the memory storing machine-readable instructions executable by the processor, which, when executed by the processor, perform the method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the method as described in any one of claims 1 to 4.

Images