Nowe rekordy danych połączeń – szczegółowa analiza

Znacząca aktualizacja systemu Call Data Records (CDR) w 3CX.

W nawiązaniu do wczorajszej premiery V20 Update 6 Alpha, w tym wpisie omawiamy nowy system Call Data Records (CDR) w 3CX, w którym uprościliśmy strukturę CDR do jednej tabeli: cdr_output. Przedstawiamy dotychczasową strukturę, nowy projekt oraz kluczowe ulepszenia techniczne, które zmieniają sposób działania danych połączeń. Czytaj dalej, aby poznać wszystkie szczegóły.

Dotychczasowa struktura: rozproszona i mało efektywna

Pierwotnie dane CDR (Call Data Records) w 3CX były rozproszone w czterech tabelach: cl_calls, cl_participants, cl_party_info oraz cl_segments. Każda z nich przechowywała inne elementy cyklu życia połączenia – znaczniki czasu, dane uczestników i szczegóły routingu. Aby uzyskać pełny obraz połączenia, konieczne było stosowanie złożonych zapytań SQL z licznymi operacjami JOIN, co znacząco zwiększało obciążenie zapytań i spowalniało generowanie raportów. W kontekście analityki na dużą skalę czy raportowania w czasie rzeczywistym ta struktura nie była wystarczająco wydajna.

Nowe podejście: cdr_output

Przebudowaliśmy system na cdr_output – jedno-tabelowe rozwiązanie, które konsoliduje wszystkie dane połączeń w jednej, zoptymalizowanej tabeli. Znaczniki czasu, uczestnicy, routing i wyniki połączeń są teraz zebrane w jednym miejscu, eliminując konieczność stosowania JOIN. Wyjątkiem są dane nagrań, które zostały przeniesione do oddzielnej tabeli cdr_recordingsout. 3CX zawsze zapewniało skalowalność na poziomie tysięcy użytkowników, a nowa, uproszczona architektura jeszcze bardziej wzmacnia nasze możliwości. Zmniejsza złożoność, przyspiesza zapytania i przygotowuje 3CX do analityki w chmurze. To odważne podejście do inżynierii danych, które zapewnia precyzję i wydajność.

Ulepszenie #1: Wszystkie dane w jednej zoptymalizowanej tabeli

Dawniej: Operacje JOIN na wielu tabelach spowalniały wydajność – prawdziwy koszmar przy analizie danych o połączeniach.
Teraz: Tabela cdr_output zawiera wszystko – źródło, cel, znaczniki czasu, wyniki – w jednej kompaktowej strukturze. Jest płaska i prosta, eliminując nadmiar relacji, dzięki czemu analitycy BI mogą bez trudu śledzić przepływy połączeń.

Dlaczego to świetne rozwiązanie:

• Szybsze zapytania: Eliminacja złożoności wielu tabel na rzecz jednej struktury przyspiesza działanie i zapewnia skalowalność, niezależnie od ilości danych.
• Gotowe do chmury: Łatwo integruje się z hurtowniami danych lub narzędziami BI – bez dodatkowego przygotowania.
• Ułatwienie dla analityków: Przejrzysta ścieżka połączeń pozwala zaoszczędzić godziny pracy.

Przewaga technologiczna: Indeksy na cdr_id oraz call_history_id przyspieszają PostgreSQL, zapewniając błyskawiczne wyszukiwanie nawet w ogromnych zbiorach danych. Utrzymanie call_history_id w tabeli zmniejsza obciążenie SQL, zwiększa szybkość i ogranicza rozrost danych.

Ulepszenie #2: Każdy wiersz opowiada historię

Dawniej: Ograniczone metadane utrudniały analitykom raportów interpretację danych – dlaczego połączenie nie powiodło się? Gdzie jest kontekst? Kto przekierował rozmowę i do kogo?
Teraz: cdr_output zawiera teraz bogaty zestaw atrybutów:

• termination_reason (np. „cancelled”, „dst_participant_terminated”)
• termination_reason_details (np. „forward_all”, „completed_elsewhere”)
• creation_method (np. „route_to”, „divert”)
• creation_forward_reason (np. „polling”, „busy”)
• continuation_reason (np. „polling”, „forward_all”)

Korzyści:

• Pełna przejrzystość: Każdy wiersz to kompletna historia – koniec z poszukiwaniem brakujących informacji.
• Lepsze analizy: Automatyczne wskaźniki KPI, takie jak współczynnik porzuceń czy statystyki kolejek, bez dodatkowej konfiguracji.
• Wyjaśnienie końcowego etapu połączenia: Natychmiastowy wgląd w to, jak, dlaczego, kiedy i kto zakończył rozmowę.

Przewaga technologiczna: termination_reason_details umożliwia precyzyjną analizę (np. SQL GROUP BY w Grafana lub Power BI), a identyfikator cdr_id oparty na UUID (w formacie 00000000-01db-87c1-1bab-07aa0000000d) pozwala narzędziom BI poprawnie sortować połączenia według daty i kolejności bez dodatkowej konfiguracji. Wszystko jest dostępne – od początku połączenia, przez jego przekierowania, aż po zakończenie.

Ulepszenie #3: Kto do kogo dzwoni? Teraz to proste

Dawniej: Role uczestników były słabo zdefiniowane – określenie źródła i celu wymagało skomplikowanych operacji na tabelach, zgadywania, zagnieżdżonych operacji, wielu złączeń SQL (JOIN) i dużego obciążenia systemu.
Teraz: cdr_output upraszcza dotychczasowe zawiłości SQL JOIN, oferując przejrzysty podział na kluczowe elementy:

• source_participant_id (śledzenie źródła połączenia)
• source_participant_phone_number (np. „+1305305305”)
• destination_dn_name (np. „Dana White”)
• Flagi, takie jak source_participant_is_incoming oraz destination_participant_is_already_connected

Korzyści:

• Precyzyjne mapowanie: Kierunek połączenia jest teraz jednoznaczny – od źródła do miejsca docelowego, co upraszcza analizę przepływu połączeń.
• Obsługa złożonych scenariuszy: Bezproblemowe śledzenie wielu kolejek, dwukierunkowych trunków i złożonych transferów w ramach jednej struktury danych.

Przewaga technologiczna: Flagi logiczne (Boolean) odzwierciedlają modelowanie wymiarowe w hurtowniach danych, optymalizując wydajność zapytań SQL (WHERE). Standard UUID dla identyfikatorów uczestników zapewnia pełną kompatybilność z platformami BI, zachowując prawidłową sekwencję etapów połączenia bez dodatkowej konfiguracji.

Ulepszenie #4: Dokładność znaczników czasowych

Dawniej: cl_calls oferowała jedynie podstawowe znaczniki czasu rozpoczęcia i zakończenia połączenia, a cl_segments zawierała resztę informacji w sposób rozproszony.
Teraz: Tabela cdr_output zapewnia trzy precyzyjne znaczniki czasowe: cdr_started_at, cdr_ended_at, cdr_answered_at.

Korzyści:

• Precyzyjne metryki: Dokładny pomiar czasu od dzwonienia do odebrania połączenia – każda sekunda ma znaczenie.
• Prostsza analiza: Obliczenia można wykonywać w jednej tabeli bez konieczności agregowania danych z wielu źródeł.

Ekspercka analiza: Znaczniki czasu UTC (+00) zapewniają spójność we wszystkich regionach – to kluczowe dla globalnych wdrożeń chmurowych zasilających narzędzia takie jak Snowflake czy BigQuery. Identyfikator cdr_id w formacie GUID łączy te znaczniki czasu z segmentami połączeń, co umożliwia narzędziom BI natywne rozumienie ich kolejności i czasu trwania. Nie wymaga żadnych dodatkowych modyfikacji.

Ulepszenie #5: Gotowe na rozwój

Dawniej: Konfiguracje oparte na wielu tabelach były sztywne – każda nowa funkcja prowadziła do nadmiernej rozbudowy schematu.
Teraz: cdr_output to pojedyncza, elastyczna tabela – wystarczy dodać kolumnę, a system automatycznie się dostosuje.

Korzyści:

• Skalowalność na przyszłość: Rozwija się zgodnie z roadmapą 3CX bez dodatkowego obciążenia relacyjnego.
• Efektywność operacyjna: Jedna tabela do indeksowania, replikacji i partycjonowania, zaprojektowana z myślą o chmurze.

Ekspercka analiza: Flagi, takie jak processed i migrated, usprawniają przepływ danych, umożliwiając płynną integrację z Apache Kafka, AWS Athena, Kinesis oraz Google BigQuery. Powiązanie z call_history_id w obrębie tabeli przyspiesza zapytania dotyczące powiązanych połączeń, utrzymując wysoką wydajność i minimalizując obciążenie danych.

Następny krok – Przygotowanie danych w chmurze

Przekształciliśmy przestarzały system CDR w nowoczesną, skalowalną tabelę do raportowania połączeń. Nasze testy pokazują, że zapytania są nawet 10 razy szybsze – mniej JOIN-ów, bogatsze dane. Udanych raportów!

Zacznij korzystać z Update 6 Alpha

Aby wypróbować te nowe funkcje, zaktualizuj do wersji V20 Update 6 Alpha.

Dołącz do dyskusji na temat V20 na naszych dedykowanych forach dla Partnerów lub Klientów. Śledź nas na X i LinkedIn, aby być na bieżąco z nowościami.