ビッグデータの高額請求: 通信におけるビッグデータについて

2008 年、ビッグデータは新しい用語であり、流行のトレンドでした。 2019 年、ビッグデータは販売の対象であり、利益の源であり、新たな請求の理由となっています。

ロシア政府は昨秋、ビッグデータを規制する法案を提出した。 情報から個人を特定することはできませんが、連邦当局の要請に応じて特定する場合があります。 サードパーティ向けのビッグデータの処理は、Roskomnadzor の通知後にのみ行われます。 100万以上のネットワークアドレスを持つ企業が該当する。 そしてもちろん、レジスタがない場合は、データベース演算子のリストを使用してレジスタを作成する必要があります。 そして、以前はビッグデータが誰もが真剣に受け止めていなかったとしても、これからはそれを考慮する必要があるでしょう。

私は、まさにこのビッグデータを処理する課金開発会社のディレクターとして、データベースを無視することはできません。 私は、通信事業者の視点からビッグ データについて考えます。通信事業者の料金体系には、毎日数千人の加入者に関する情報が流れます。

定理

数学の問題のように始めましょう。まず、通信事業者のデータを BigDat と呼ぶことができることを証明します。 通常、ビッグデータは XNUMX つの VVV 特性によって特徴付けられますが、自由解釈では「V」の数は XNUMX つに達します。

音量。 Rostelecom の MVNO だけでも 44 万人以上の加入者にサービスを提供しています。 主要なホスト事業者は 78 万人から 2019 万人分のデータを扱っています。 トラフィックは毎秒増加しており、3,3 年の第 XNUMX 四半期には、加入者はすでに携帯電話から XNUMX 億 GB にアクセスしました。

速度。 統計よりもこの動向について正確に説明できる人はいないため、シスコの予測について説明します。 2021 年までに、IP トラフィックの 20% がモバイル トラフィックに移行し、2 年間でほぼ XNUMX 倍になります。 モバイル接続の XNUMX 分の XNUMX は MXNUMXM になり、IoT の発展により接続は XNUMX 倍に増加します。 モノのインターネットは収益性が高いだけでなく、リソースを大量に消費するため、一部の事業者はインターネット オブ シングスだけに注力するでしょう。 そして、IoT を別のサービスとして開発する人は、二重のトラフィックを受けることになります。

バラエティ。 多様性は主観的な概念ですが、通信事業者は実際には加入者についてほぼすべてを知っています。 名前やパスポートの詳細から、携帯電話のモデル、購入したもの、訪れた場所、興味のあるものまで。 ヤロバヤ法によれば、メディア ファイルは XNUMX か月間保存されます。 したがって、収集されるデータはさまざまであるということを公理として考えてみましょう。

ソフトウェアと方法論

プロバイダーはビッグデータの主要な消費者の XNUMX つであるため、ほとんどのビッグ データ分析手法は通信業界に適用できます。 もう XNUMX つの疑問は、ML、AI、ディープラーニングの開発、データセンター、データマイニングに投資する準備ができているのは誰かということです。 データベースを使用した本格的な作業はインフラストラクチャとチームで構成されますが、そのコストは誰もが負担できるわけではありません。 すでに社内倉庫を持っている企業、またはデータ ガバナンス方法論を開発中の企業は、ビッグデータに賭けるべきです。 まだ長期的な投資の準備ができていない人には、ソフトウェア アーキテクチャを徐々に構築し、コンポーネントを XNUMX つずつインストールすることをお勧めします。 重いモジュールと Hadoop は最後に残しておいても問題ありません。 データ品質やデータ マイニングなどの問題に対して既成のソリューションを購入する人はほとんどいません。企業は通常、自社で、または開発者の助けを借りて、特定の仕様やニーズに合わせてシステムをカスタマイズします。

ただし、すべての請求を BigData と連動するように変更できるわけではありません。 というか、すべてを変更できるわけではありません。 これができる人はほとんどいません。

請求システムがデータベース処理ツールになる可能性があることを示す XNUMX つの兆候:

• 水平方向のスケーラビリティ。 ソフトウェアは柔軟でなければなりません。ここで話しているのはビッグデータです。 情報量の増加は、クラスター内のハードウェアの比例増加によって処理する必要があります。
• フォールトトレランス。 本格的なプリペイド システムは通常、デフォルトでフォールト トレラントです。請求は複数の地理的位置にあるクラスターに展開され、相互に自動的に保証されます。 また、XNUMX つ以上の障害が発生した場合に備えて、Hadoop クラスター内に十分なコンピューターが必要です。
• 地域性。 データは XNUMX つのサーバーに保存して処理する必要があります。そうしないと、データ転送が失敗する可能性があります。 人気のある Map-Reduce アプローチ スキームの XNUMX つ: HDFS ストア、Spark プロセス。 理想的には、ソフトウェアはデータセンターのインフラストラクチャにシームレスに統合され、情報の収集、整理、分析という XNUMX つのことを XNUMX つで実行できる必要があります。

チーム

プログラムがビッグデータを何を、どのように、どのような目的で処理するかは、チームによって決定されます。 多くの場合、データ サイエンティストという XNUMX 人の人物で構成されます。 ただし、私の意見では、ビッグ データの従業員の最小パッケージには、プロダクト マネージャー、データ エンジニア、マネージャーも含まれます。 XNUMX つ目はサービスを理解し、専門用語を人間の言語に翻訳し、その逆も同様です。 データ エンジニアは、Java/Scala を使用してモデルに命を吹き込み、機械学習を実験します。 マネージャーは調整し、目標を設定し、ステージを制御します。

問題

データの収集と処理時に問題が発生するのは通常、BigData チームの側です。 プログラムは、何を収集し、それをどのように処理するかを説明する必要があります。これを説明するには、まず自分自身で理解する必要があります。 しかし、プロバイダーにとって、物事はそれほど単純ではありません。 私は、加入者の解約を減らすという課題を例にして問題について話しています。これは、そもそも通信事業者がビッグデータの助けを借りて解決しようとしているものです。

目標を設定する。 よく書かれた技術仕様と用語の異なる理解は、フリーランサーだけでなく何世紀にもわたる悩みの種でした。 「ドロップされた」加入者であっても、XNUMX か月、XNUMX か月、または XNUMX 年間通信事業者のサービスを使用していない加入者として、さまざまに解釈される可能性があります。 また、過去のデータに基づいて MVP を作成するには、他の通信事業者を試したり都市を離れて別の番号を使用したりした加入者が解約から戻ってくる頻度を理解する必要があります。 もう XNUMX つの重要な質問は、加入者が退会すると予想されるどれくらい前に、プロバイダーはこれを判断して措置を講じるべきでしょうか? 半年では早すぎますが、XNUMX週間では遅すぎます。

概念の置き換え。 通常、オペレーターは電話番号で顧客を識別するため、それを使用して標識をアップロードするのは論理的です。 個人アカウントやサービス申し込み番号はどうなりますか? オペレータシステム内のデータが変化しないように、どのユニットをクライアントとするかを決定する必要があります。 クライアントの価値の評価にも疑問があります。会社にとってどの加入者がより価値があるのか​​、どのユーザーを維持するためにより多くの努力が必要なのか、そしてどの加入者がいずれにせよ「脱落」するのか、それらの加入者にリソースを費やすのは意味がありません。

情報不足。 すべてのプロバイダーの従業員が、加入者の解約に具体的に影響を与えるものや、請求の考えられる要素がどのように計算されるかを BigData チームに説明できるわけではありません。 たとえそれらの XNUMX つである ARPU に名前が付けられたとしても、それはさまざまな方法で計算できることがわかります。つまり、定期的なクライアントの支払いまたは自動請求料金のいずれかです。 そして、仕事の過程で、他にも何百万もの疑問が生じます。 このモデルはすべてのクライアントをカバーしているのか、クライアントを維持するための価格はいくらなのか、代替モデルを検討することに意味はあるのか、誤って人為的に維持されたクライアントをどうするのか。

目標の設定。 私は、オペレーターがデータベースに対してイライラする原因となる XNUMX 種類の結果エラーを知っています。

1. プロバイダーは BigData に投資し、ギガバイト単位の情報を処理しますが、より安価に得られる結果が得られます。 シンプルな図とモデル、原始的な分析が使用されます。 コストは何倍にもなりますが、結果は同じです。
2. オペレータは多面的なデータを出力として受け取りますが、その使用方法を理解していません。 分析機能があります - ここにありますが、理解可能で膨大ですが、役に立ちません。 「データを処理する」という目標だけで構成される最終的な結果については、十分に検討されていません。 処理するだけでは十分ではありません。分析はビジネス プロセスを更新するための基礎となる必要があります。
3. BigData 分析の使用を妨げるのは、時代遅れのビジネス プロセスや新しい目的に適さないソフトウェアである可能性があります。 これは、準備段階でミスを犯したことを意味します。アクションのアルゴリズムとビッグデータを仕事に導入する段階を熟考していませんでした。

何のために

結果といえば。 通信事業者がすでに使用しているビッグデータの使用方法と収益化方法について説明します。
プロバイダーは加入者の流出だけでなく、基地局の負荷も予測します。

1. 加入者の移動、アクティビティ、および周波数サービスに関する情報が分析されます。 結果: インフラストラクチャの問題領域の最適化と最新化により、過負荷の数が減少します。
2. 電気通信事業者は、POS を開設するときに、加入者の地理位置情報とトラフィック密度に関する情報を使用します。 したがって、BigData 分析は、MTS と VimpelCom によって、新しいオフィスの立地を計画するためにすでに使用されています。
3. プロバイダーは、自社のビッグデータを第三者に提供することで収益化します。 BigData オペレーターの主な顧客は商業銀行です。 データベースを使用して、カードがリンクされている加入者の SIM カードの不審なアクティビティを監視し、リスク スコアリング、検証、監視サービスを利用します。 そして 2017 年、モスクワ政府は技術インフラと交通インフラを計画するために Tele2 の BigData データに基づく移動ダイナミクスを要求しました。
4. ビッグデータ分析はマーケティング担当者にとって宝の山であり、希望に応じて数千もの加入者グループに向けてパーソナライズされた広告キャンペーンを作成できます。 通信会社は、加入者のソーシャル プロファイル、消費者の関心、行動パターンを集約し、収集したビッグデータを使用して新しい顧客を引きつけます。 しかし、大規模なプロモーションや PR 計画の場合、請求書には必ずしも十分な機能があるとは限りません。プログラムでは、クライアントに関する詳細情報と並行して多くの要素を同時に考慮する必要があります。

いまだにビッグデータを空虚な言葉だと考える人もいるが、四大企業はすでにビッグデータで収益を上げている。 MTS はビッグデータ処理から 14 か月で 2 億ルーブルを稼ぎ出し、TeleXNUMX はプロジェクトからの収益を XNUMX 倍に増加させました。 ビッグデータはトレンドから必須へと変わりつつあり、それに基づいて通信事業者の構造全体が再構築されることになります。

出所： habr.com