基地局分析を支えるデータ基盤

まえがき

スマートフォンの普及により、いつでも、どこでも高速なインターネットにアクセスできることが当たり前になった現代。
より速く、より安定した移動通信を支えるには移動通信基地局（基地局）のトラフィックログを分析し、基地局設定を最適化し続けることが不可欠です。
また、基地局の異常や故障をいち早く検知し、迅速な補完処理を行うことでサービスエリアに穴を作らないことも安定した品質を実現するために重要です。
これらを実現するためには基地局から生成されるログデータの分析は必須の工程であると言え、迅速なデータ分析には対象となるデータを整形した状態でData Lakehouseへ格納する必要があります。
しかしトラフィックログ集計対象と指定される基地局は日本全国に6.5万基以上（LTE／5G 合計）ありそれらのログを分析可能な状態へ変換するには多大な時間と計算リソースが必要です。
ドコモではこれらのデータ変換にApache Sparkおよびその実行プラットフォームとしてDatabricksを用い、基地局データを高速に変換しネットワークエンジニアへ届けることに成功しました。

技術の概要

Apache Sparkは複数のコンピューターへデータを分散して並列演算を行うフレームワークです。
基地局から送られるログデータの集合体は単体のコンピューターで変換処理を行うには非常に容量が大きく、迅速にデータを変換するための分散処理フレームワークとしてApache Sparkを採用しました。
Apache Sparkでは従来のMapReduce環境と異なりデータをストレージよりも高速なDRAM（Dynamic Random Access Memory）に配置することでより高速な処理を実現しています。
併せて、遅延評価により最適化された実行計画が立てられることで効率的な経路で処理結果に到達することができます。
処理を実行するプラットフォームにはDatabricksを採用し、Lakeflow JobsとPhoton acceleratorを使用することで処理時間の短縮とSpark Clusterの運用負荷削減、コスト最適化も実現しました。
ここで処理された基地局のトラフィックログは迅速にData Lakehouseへ格納され、ネットワークの正常性監視や移動通信網のパフォーマンス監視、通信品質向上へ向けた分析に用いられます。

技術の詳細

ドコモの基地局は基地局自身の状態を100以上の項目に渡って1時間ごとにレポートします。
このレポートは項目ごとに1分単位で測定されたものや、1回の測定で複数のデータが生み出されるものなど多種多様なデータの集合体です。
Databricks上に構築されたSpark Clusterはこの基地局から届くデータのファイルや内容を展開し、あらかじめ仕様として定義された内容に従って

- Validation：データの妥当性チェック
- Extraction：必要な情報の抽出
- Reshaping：項目ごとの再整形

を行い、基地局単位のデータを測定されたデータの項目ごとの分析アナリストが利用しやすい形に整えます。

処理の詳細

処理は大きく分けて以下の2つの流れで行われます。

- データの解凍と整合性の確認
- データのバリデーション・変換処理・再整形

データの解凍と整合性の確認

今回の基地局トラフィックの変換処理ではSpark Clusterは.tar.gz形式でアーカイブ・圧縮したバイナリ形式で受け取ります。
この形式を現段階のSparkではネイティブ機能で解凍することは出来ないため、UDFやmapInPandasを避けることは出来ません。
今回の実装では一度.tar.gzごとバイナリ形式で読み込み、mapInPandasを用いて解凍します。
このときに、以下2つの観点でファイルの整合性（チェックサムの突合）の確認を行います。

1. .tar.gzを正常に受け取れているか（転送の整合性）
2. アーカイブ内のバイナリファイル（トラフィックログの実体）が基地局の書き出したかった内容であるか（ログ内容の整合性）

1に関しては解凍処理時にCRC-32 チェックサムの突合を行うことで整合性の検証を行います。

2に関してはRFC 1071 Internet Checksumに類似する処理を独自実装しチェックサムの突合を実施しています。
この処理は負荷そのものは大きくないものの、ファイル数が多いことやComputeリソースのスケールのタイミングを考慮すると制約が大きい状況でした。

当初はmapInPandasによる.tar.gzの解凍処理の後に一度Dataframeを更新し、Sparkのネイティブ関数でチェックサムの計算を行っていました。
この方法だと正しい結果を得ることは出来たものの、十分なパフォーマンスを得ることが出来ませんでした。

実装方法として、mapInPandas内にこのチェックサムの計算を実装することで、.tar.gzの解凍処理で一度DRAMからCPU（Central Processing Unit）に取り込まれたデータをそのまま計算に活用することを目指し、Pythonプロセス内での解凍（Decompression）とチェックサム計算を連続して処理することでメモリコピーのオーバーヘッドを削減することを目指しました。

また、memoryviewなどを使用してmapInPandas実行における内部でのデータのコピーも抑制、併せてNumPyを用いて演算効率を高めています。
NumPyを経由することで今後CPUアーキテクチャの変更が発生してもコードの修正を最小限に抑える実装にもなっています。
この計算結果はDeltaテーブルに書き出され、永続化（materialize）されます。

データのバリデーション・変換処理・再整形

Spark Clusterがこの処理に着手する際にはすでにSpark Dataframeとして前処理が済んでいる状態であるため、Photon acceleratorのカバーする機能を優先的に選択し、処理を組み上げていくことでパフォーマンスを向上させました。
データの変換はデータ項目ごとに異なった規則がありますが、規則をあらかじめSpark Dataframeとして保持し、データごとに結合（JOIN）することでパフォーマンスを維持しつつ、データの分割処理や変換処理を行います。

まとめ

ドコモではネットワークの正常性やパフォーマンスの監視・品質向上施策に基地局のログデータを分析し、その前段階にあたる変換処理にApache Sparkを用いてより早く、より多くのデータをデータアナリストへ届けることが可能になりました。
今後も移動通信の品質向上を通して「つなぐ」で社会に貢献し続けていきます。