3CX呼叫数据记录(CDR)系统重大升级

继昨天发布的V20 Update 6 Alpha版本之后，本文将介绍3CX新的呼叫数据记录(CDR)系统。我们将CDR简化为单一表格：cdr_output。我们将分析旧结构，展示新设计，并重点介绍正在改变呼叫数据工作方式的技术优势。请继续阅读详细内容。

传统设置：分散的瓶颈

最初，3CX的CDR/呼叫数据分散在四个表格中：cl_calls、cl_participants、cl_party_info和cl_segments。每个表格存储不同的呼叫生命周期元素：时间戳、参与者数据和路由详情 – 这需要复杂的SQL JOIN操作才能拼凑出完整记录。这种多表设计增加了查询开销，降低了生成报告的性能。对于云规模的分析或实时报告，这种结构根本无法跟上。

新方案：cdr_output

我们将其改造为cdr_output，这是一个将所有呼叫数据整合到一个高效表格的单表解决方案。时间戳、参与者、路由和结果 – 所有内容都统一了，消除了JOIN的需求。只有录音数据需要JOIN，现在存储在单独的cdr_recordingsout表中。在3CX，我们一直能够扩展到数千用户。这种精简的架构进一步增强了我们的可扩展性，降低了复杂性，提升了查询速度，并为云就绪分析做好了准备。这是数据工程的大胆重新思考，旨在提供精确性和强大功能。

进步#1：所有数据整合在一个智能表格中

传统：多表JOIN降低性能 – 深入挖掘呼叫见解时的真正痛点。 新方案：cdr_output将所有内容打包 – 源、目标、时间戳、结果 – 都在一个紧凑的表格中。它简单明了，消除了关系型数据库的混乱，让BI分析师能够轻松跟踪呼叫流程。

为什么出色：

  • **更快的查询：**摒弃多表复杂性，实现单表速度 – 查询平滑扩展，不受数据规模影响。
  • **云就绪：**可直接整合到数据湖或BI工具中 – 无需额外准备。
  • **分析师优势：**呼叫路径清晰快速可追踪，节省大量麻烦。

**技术优势：**cdr_id和call_history_id的索引为PostgreSQL提供闪电般快速的查找，即使处理海量数据集。将call_history_id链接保持在表内降低了SQL开销，提升了速度，减少了数据膨胀。

进步#2：每行都讲述完整故事

传统：元数据不足导致报告分析师只能猜测 – 为什么呼叫失败？上下文在哪里？谁转接给谁？ 新方案：cdr_output嵌入了丰富的属性集：

  • termination_reason（例如，”已取消”、”目标参与者终止”）
  • termination_reason_details（例如，”全部转发”、”在其他地方完成”）
  • creation_method（例如，”路由至”、”转移”）
  • creation_forward_reason（例如，”轮询”、”忙”）
  • continuation_reason（例如，”轮询”、”全部转发”）

影响：

  • **完全清晰：**每一行都是完整的故事 – 不再需要拼凑线索。
  • **更智能的见解：**支持掉线率或队列统计等KPI，无需额外工作。
  • **结果明晰：**立即了解如何、为什么、何时以及谁结束了呼叫。

**技术优势：**termination_reason_details支持精确分析（想想Grafana或PowerBI中的SQL GROUP BY），而基于UUID的cdr_id现在采用GUID标准00000000-01db-87c1-1bab-07aa0000000d，使BI工具能够直接准确理解日期时间和呼叫顺序。所有信息都在那里 – 呼叫如何开始、移动和结束。

进步#3：简化呼叫方向识别

传统：参与者角色定义不清 – 源与目标需要跨表推断、猜测、嵌套操作、多重JOIN和性能损耗。 新方案：cdr_output通过一系列清晰分离的功能处理之前的SQL JOIN混乱：

  • source_participant_id（用于跟踪）
  • source_participant_phone_number（例如，”+1305305305″）
  • destination_dn_name（例如，”Dana White”）
  • 标志如source_participant_is_incoming和destination_participant_is_already_connected

源端新功能

参与者新功能

“source_participant_id”

“destination_participant_id”

“source_entity_type”

“destination_entity_type”

“source_dn_number”

“destination_dn_number”

“source_dn_type”

“destination_dn_type”

“source_dn_name”

“destination_dn_name”

“source_participant_name”

“destination_participant_name”

“source_participant_phone_number”

“destination_participant_phone_number”

“source_participant_trunk_did”

“destination_participant_trunk_did”

“source_participant_is_incoming”

“destination_participant_is_incoming”

“source_participant_is_already_connected”

“destination_participant_is_already_connected”

影响：

  • **精确映射：**呼叫方向一目了然 – 从源到目标，完成，简化流程分析。
  • **处理复杂场景：**在单一架构中无缝跟踪多个队列流程、双向中继和多层转接。

**技术优势：**布尔状态标志反映了数据仓库的维度建模，优化WHERE子句性能。参与者ID中的UUID标准确保与BI平台无缝集成，开箱即可保持呼叫分支排序。

进步#4：时间戳精度

传统：cl_calls提供基本的开始/结束时间；cl_segments分散了其余部分。 新方案：cdr_output提供三个精确的时间戳：cdr_started_at、cdr_ended_at、cdr_answered_at。

影响：

  • **精确指标：**获取精确的响铃到应答时间 – 每一秒都很重要。
  • **分析简单性：**单表计算取代多表聚合。

**专家见解：**UTC时间戳（+00）确保跨区域一致性 – 这对于全球云部署馈送到Snowflake或BigQuery等工具至关重要。基于GUID的cdr_id将这些时间戳与呼叫分支关联，使BI工具能够原生理解序列和持续时间。无需调整。

进步#5：为增长而建

传统：多表设置僵化 – 新功能意味着完整的架构扩展。 新方案：cdr_output是一个单一的、可扩展的表格 – 添加一列，系统就会适应。

影响：

  • **面向未来的扩展：**随3CX路线图发展而增长，无关系开销。
  • **运营效率：**一个表格用于索引、复制或分区 – 设计就是云原生的。

**专家见解：**processed和migrated等标志简化数据管道，实现与Apache Kafka、AWS Athena或Kinesis和Google BigQuery的无缝集成。表内的call_history_id链接加速相关呼叫查询，保持性能紧凑和数据负载精简。

下一步 – 准备云数据

我们将笨重的CDR系统转变为现代可扩展的呼叫报告表格。我们的基准测试显示查询速度提升高达10倍 – 更少的JOIN，更丰富的数据。祝您报告愉快！

开始使用Update 6 Alpha

要试用这些新功能，请升级到V20 Update 6 Alpha。