「1C-Bitrix BigData：Personalization」の例を使用したBigData処理のアーキテクチャと技術的アプローチ

今年9月、ビッグデータに特化した会議がキエフ-BigData会議で開催されました。 古い伝統に従って、会議で発表されたいくつかの資料をブログに公開しています。 そして、 Alexander Demidovによるレポートから始めます。



現在、多くのオンラインストアは、彼らにとっての主なタスクの1つが自身の効果を高めることであることを認識しています。 2つの店舗を取り上げて、それぞれ1万人の訪問者を引き付けましたが、1つは100の売り上げ、もう1つは200の売り上げを達成しました。



データ処理のトピック、店舗訪問者の処理モデルは関連性があり重要です。 すべての接続が手動で確立される従来のモデルはどのように機能しますか？ カタログ内の商品の対応、付属品とのバンドルの作成などを行います。 しかし、一般的な冗談が言うように：







このような接続を予測し、希望のものとはまったく関係のないものを購入者に販売することは不可能です。 しかし、その後、緑色のコートを探している次の女性に、前の訪問者の同様の行動モデルに基づいて同じ赤いバッグをお勧めできます。



このアプローチは、ターゲット小売チェーンのケースを非常に明確に示しています。 怒った訪問者が来て、マネージャーを呼びました。 この同じ訪問者の未成年の娘への郵送で、オンラインストアが妊娠中の女性にオファーを送信したことが判明しました。 父はこの事実に非常にinしていました。 彼女は未成年です、彼女はどのくらい妊娠していますか？」 彼は戦いをして去った。 数週間後、少女は実際に妊娠していたことが判明しました。 さらに、オンラインストアは、彼女の好みの分析に基づいて、これよりも早くこのことを学びました。彼女が注文した製品は、ほぼ同じシナリオで行動した他の訪問者のモデルと比較されました。



多くの分析アルゴリズムの結果は魔法のように見えます。 当然、多くのプロジェクトがそのような分析を実装したいと考えています。 しかし、十分なオーディエンスを持つ市場にはプレイヤーがほとんどいないため、実際に数を数えて予測することができます。 基本的に、これらは検索エンジン、ソーシャルネットワーク、大規模なポータル、オンラインストアです。

ビッグデータを使用する最初のステップ

製品にビッグデータ分析を導入することを考えたときに、3つの重要な質問をしました。

• 十分なデータがありますか？
• それらをどのように処理しますか？ スタッフに数学者がいないため、「ビッグデータ」を扱うのに十分な能力がありません。
• これらすべてを既存の製品に組み込む方法は？

私たちのプラットフォームを含め、何百万人ものオーディエンスを持つ大規模なオンラインストアはほとんどありません。 ただし、「1C-Bitrix：サイト管理」を使用する店舗の総数は非常に多く、これらを合わせてさまざまな市場セグメントの印象的なオーディエンスをカバーしています。



その結果、プロジェクトのフレームワーク内で内部スタートアップを組織しました。 どちらから取得するかわからなかったため、小さな問題を解決することから始めることにしました。データの収集と保存の方法です。 この小さなプロトタイプは30〜40分で作成されました。







MVPという用語があります-最小限の実行可能な製品、最小限の機能を備えた製品です。 テクニカルメトリックの収集、訪問者からのページ読み込み速度の収集を開始し、プロジェクトの速度に関する分析をユーザーに提供することにしました。 これは、パーソナライゼーションまたはBigDataとは関係ありませんでしたが、すべての訪問者のオーディエンス全体を処理する方法を学ぶことができました。



JavaScriptには、Navigation Timing APIと呼ばれるツールがあります。このツールを使用すると、ページ速度、DNS解決期間、ネットワークデータ転送、バックエンドでの作業、ページレンダリングに関するクライアント側のデータを収集できます。 これらすべてをさまざまなメトリックに分解してから、分析を提供できます。







プラットフォームで作業している店舗の数、収集する必要があるデータの量を把握しました。 潜在的に、これらは1万件のサイト、1日あたり数千万件のヒット、1秒あたり1000-1500件のデータ書き込み要求です。 多くの情報があり、それをどこに保存し、それから作業しますか？ そして、ユーザーに最高速度の分析サービスを提供する方法は？ つまり、JSカウンターは非常に迅速に回答を提供する義務があるだけでなく、ページの読み込み速度を低下させることもありません。

データの記録と保存

当社の製品は主にPHPとMySQLで構築されています。 最初の要望は、すべての統計をMySQLまたは他のリレーショナルデータベースに単純に保存することでした。 しかし、テストや実験がなくても、これは行き止まりであることがわかりました。 ある時点で、記録時またはデータのフェッチ時に十分なパフォーマンスが得られません。 また、このベースの側面に障害が発生すると、サービスの動作が非常に遅くなるか、通常は動作しなくなるという事実につながります。







さまざまなNoSQLソリューションを検討しました。 Amazonには大規模なインフラストラクチャが展開されているため、最初にDynamoDBに注目しました。 この製品には、リレーショナルデータベースと比較して多くの利点と欠点があります。 DynamoDBの記録およびスケーリングがより良く、より速く動作する場合、複雑な選択を行うことははるかに困難になります。 データの一貫性にも問題があります。 はい、提供されていますが、常にいくつかのデータを選択する必要がある場合、常に最も関連性の高いものを選択するという事実ではありません。



その結果、生データのストレージとしてではなく、ユーザーへの情報の集約とその後の配信にDynamoDBの使用を開始しました。



行ではなく列で機能するカラムナーデータベースを検討しました。 しかし、録音中のパフォーマンスが低いため、それらを拒否する必要がありました。







適切なソリューションを選択して、テキストログの書き込みから始まり、ZeroMQ、Rabbit MQキューなどのサービスで終わるさまざまなアプローチについて説明しました。 しかし、最終的に、彼らは完全に異なるオプションを選択しました。

キネシス

そのときまでに、AmazonはKinesisサービスを開発しました。これは初期データ収集に最適なサービスでした。 これは、必要なものをすべて書き込むことができる、一種の大きな高性能バッファーです。 彼は非常に迅速にデータを受信し、成功した録音について報告します。 その後、バックグラウンドで、選択、フィルター、集計などの情報を安全に操作できます。



Amazonが提供するデータから判断すると、Kinesisはワークロードに簡単に対処できたはずです。 しかし、いくつかの質問が残った。 たとえば、エンドユーザー（サイト訪問者）はKinesisに直接データを書き込むことができませんでした。 サービスを使用するには、Amazon Web Services vの比較的高度な認証メカニズムを使用してリクエストに「署名」する必要があります。 4.したがって、フロントエンドにKinesisにデータを送信させる方法を決定する必要がありました。



次のオプションを検討しました。

• Kinesisにプロキシされる純粋な構成をnginxに書き込みます。 うまくいきませんでした、論理が複雑すぎます。
• フロントエンド+ PHPバックエンドとしてのNginx。 多くのリクエストがあるとバックエンドが遅かれ早かれ対処を停止するため、リソースの面で困難で高価であることが判明しました。水平方向にスケーリングする必要があります。 そして、プロジェクトが成功するかどうかはまだわかりません。
• Nginx + C / C ++のモジュール。 開発の面で長くて難しい。
• Nginx + ngx_http_perl_module。 要求をブロックするモジュールのバリアント。 つまり、このスレッドに入ってきたリクエストは、他のリクエストの処理をブロックします。 バックエンドの使用と同じ欠点があります。 さらに、nginxのドキュメントには、「モジュールは実験的であるため、何でも可能です。」と直接記載されています。
• Nginx + ngx_lua。 当時、私たちはまだLuaに遭遇していませんでしたが、このモジュールは好奇心が強いようでした。 必要なコードは、JavaScriptにいくらか似た言語でnginx configに直接書き込まれるか、別のファイルで取り出されます。 したがって、必要な最も奇妙で異常なロジックを実装できます。

その結果、Luaに賭けることにしました。

ルア

この言語は非常に柔軟性があり、リクエストとレスポンスの両方を処理できます。 書き換えログレベルで、nginxのリクエスト処理のすべてのフェーズに統合できます。 いくつかのメソッドを使用して、サブクエリと非ブロッキングサブクエリを作成できます。 MySQL、暗号化ライブラリなどを操作するための追加モジュールがたくさんあります。



2、3日で、Luaの機能を調査し、必要なライブラリを見つけて、プロトタイプを作成しました。



もちろん、最初のストレステストでは...すべてが落ちました。 ネットワークスタックを最適化するために、負荷の大きいLinuxを構成する必要がありました。 この手順は多くのドキュメントで説明されていますが、何らかの理由でデフォルトでは実行されません。 主な問題は、Kinesisとの発信接続用のポートの不足でした。

/etc/sysctl.conf (man sysctl) #     net.ipv4.ip_local_port_range=1024 65535 #   TIME_WAIT  net.ipv4.tcp_tw_reuse=1 #     FIN_WAIT_2 net.ipv4.tcp_fin_timeout=15 #    net.netfilter.nf_conntrack_max=1048576 #       net.core.netdev_max_backlog=50000 #      net.core.somaxconn=81920 #   syncookies  SYN  net.ipv4.tcp_syncookies=0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

範囲を拡張し、タイムアウトを設定しました。 Iptablesなどのビルトインファイアウォールを使用する場合は、テーブルのサイズを大きくする必要があります。そうしないと、非常に多くのリクエストでテーブルが非常に速くオーバーフローします。 同時に、システム自体のネットワークインターフェイスとTCPスタックのバックログのサイズを調整する必要があります。



その後、すべてが正常に機能しました。 システムは1秒あたり1000件のリクエストの処理を開始しました。このために1台の仮想マシンが必要でした。







ある時点で、システムのリソースはまだ使い果たされていませんが、まだ天井にぶつかり、「 connect() to [...] failed (99: Cannot assign requested address) while connecting to upstream



」というエラーが発生し始めました。 LAによると、負荷はゼロに近く、十分なメモリがあり、プロセッサは過負荷にはほど遠いものの、何かに遭遇しました。







nginxでキープアライブ接続を設定することで問題を解決することができました。

 upstream kinesis { server kinesis.eu-west-1.amazonaws.com:443; keepalive 1024; } proxy_pass https://kinesis/; proxy_http_version 1.1; proxy_set_header Connection "";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2つの仮想コアと4ギガバイトのメモリを搭載したマシンは、1秒あたり1000件のリクエストを簡単に処理します。 さらに必要な場合は、このマシンにリソースを追加するか、水平にスケーリングして、そのようなマシンをバランサーの後ろに2、3、5台配置します。 解決策はシンプルで安価です。 しかし、主なことは、あらゆるデータをあらゆる量で収集して保存できることです。







1日あたり最大7000万件のヒットを収集するプロトタイプを作成するのに約1週間かかりました。 「1C-Bitrix：Site Management」のすべてのクライアント向けの既製サービス「Site Speed」は、3人の努力によって1か月で作成されました。 システムはサイトの表示速度に影響せず、内部管理を行います。 Kinesisサービスの費用は月額250ドルです。 独自のハードウェアですべてを実行し、ストレージに関する決定を完全に記述した場合、メンテナンスと管理の点ではるかに高価であることが判明したでしょう。 そして、はるかに信頼性が低い。

推奨事項とパーソナライズ

システムの一般的なスキームは、次のように表すことができます。







彼女はイベントを登録し、保存し、何らかの処理を実行し、クライアントに何かを提供する必要があります。



プロトタイプを作成しました。次に、技術的な指標からビジネスプロセスの評価に移行する必要があります。 実際、何を収集するかは気にしません。 何でも転送できます：

• クッキー
• ハッシュライセンス
• ドメイン
• カテゴリー、ID、製品名
• 推奨のID

などなど。



ヒットはイベントタイプ別に分類できます。 私たちは店の面で何に興味がありますか？







すべての技術指標を収集し、ビジネス指標と必要な後続の分析にリンクできます。 しかし、このデータをどう処理し、どのように処理するのでしょうか？



推奨システムの仕組みに関するいくつかの言葉。



訪問者が特定の製品を推奨できる主要なメカニズムは、協調フィルタリングメカニズムです。 いくつかのアルゴリズムがあります。 最も単純なのは、ユーザーとユーザーのマッチングです。 2人のユーザーのプロファイルを比較し、最初のユーザーのアクションに基づいて、次の瞬間に最初のユーザーが注文したのと同じ製品が必要になる類似のアクションを実行する他のユーザーを予測できます。 これは最も単純で最も論理的なモデルです。 しかし、彼女にはいくつかの短所があります。

• まず、同じプロファイルを持つユーザーは非常に少ないです。
• 第二に、モデルはあまり安定していません。 ユーザーはさまざまな製品を見て、一致するマトリックスは常に変化しています。
• オンラインストアの全オーディエンスをカバーする場合、これらは数千万人の訪問者です。 そして、すべてのユーザーに一致するものを見つけるために、このマトリックス自体を乗算する必要があります。 そして、そのような百万番目の行列の乗算は、私たちが使用するアルゴリズムとツールの観点から重要なタスクです。

Amazonのオンラインストアでは、別のアルゴリズムが考案されています-アイテム-アイテム：ユーザー向けの通信は確立されていませんが、「メイン」製品と一緒に購入された製品を含む特定の製品用です。 これは、アクセサリーの販売増加に最も関連しています。電話を購入した人は、ケース、充電、その他を推奨できます。 製品の一致はめったに変化しないため、このモデルははるかに堅牢です。 アルゴリズム自体ははるかに高速です。



別のアプローチがあります-コンテンツベースの推奨事項。 ユーザーが興味を持ったセクションと製品、および検索クエリが分析され、その後ユーザーのベクトルが構築されます。 また、ヒントとして、ベクターがユーザーのベクターに最も近い製品が提供されます。







1つのアルゴリズムを選択することはできませんが、それらをすべて組み合わせて使用​​します。 このためのツールは何ですか：

• •MapReduce。 あなたがそれを完全に理解していれば、使用は困難を引き起こしません。 しかし、理論的に「泳ぐ」なら、困難は保証されます。
  
  
  
  
  
  
  
  
• •スパーク。 すべての構造をメモリに保存し、それらを再利用できるため、従来のMapReduceと比べてはるかに高速に動作します。 また、はるかに柔軟性があり、複雑なサンプルや集計を作成する方が便利です。
  
  
  
  
  
  
  
  Javaでプログラミングする場合、Sparkでの作業はそれほど難しくありません。 リレーショナル代数、分散コレクション、処理チェーンを使用します。

このプロジェクトでは、Sparkを選択しました。

プロジェクトのアーキテクチャ

PHPで記述された単純なワーカーでKinesisからデータを読み取ります。 なぜPHPなのか？ それは私たちにとってより馴染みがあり、私たちにとってより便利だからです。 Amazonには、ほとんどすべての一般的な言語のサービスで動作するSDKがあります。 次に、ヒットの初期フィルタリングを行います。検索ボットなどの多数のヒットを削除します。 次に、Dynamo DBですぐにオンラインで提供できる統計を送信します。







Sparkでのモデルの構築など、後続の処理のためのメインデータ配列。 S3に保存します（従来のHDFSの代わりにAmazonストレージを使用します）。 その後の数学、協調フィルタリング、機械学習アルゴリズムは、Apache Mahoutに基づいて構築された推奨事項のクラスターによって処理されます。

• データ処理には、Apache Hadoop / MapReduce、Apache Spark、Dynamo DB（NoSQL）を使用します。
• Apache Mahoutは数学計算に使用され、行列乗算の大規模処理はMapReduceパラダイムを使用して行われます。
• データは、Amazonクラウドの動的コンピューティングクラスターで処理されます。
• ストレージはAmazon S3 Objectiveで行われ、一部はNoSQL DynamoDBで行われます。

Amazon AWSクラウドインフラストラクチャと既製のサービスを使用すると、多大な労力、リソース、時間を節約できます。 このシステムにサービスを提供する管理者の大規模なスタッフは必要ありません。大規模な開発チームは必要ありません。 上記のすべてのコンポーネントを使用すると、非常に少数の専門家を管理できます。



さらに、システム全体がはるかに安価です。 テラバイト単位のデータはすべて、ディスクストレージを備えた別のサーバーを作成したり、バックアップを処理したりするよりも、S3に入れる方が収益性が高くなります。 インフラストラクチャを構成し、管理し、低レベルのメンテナンスタスクを解決するよりも、Kinesisを既製のサービスとして高め、文字通り数分または数時間で使い始める方がはるかに簡単で安価です。



プラットフォームで動作するオンラインストアの開発者にとって、これらはすべて特定のサービスのように見えます。 このサービスを使用するには、一連のAPIを使用します。このAPIを使用して、訪問者ごとに有用な統計情報とパーソナライズされた推奨事項を取得できます。



analytics.bitrix.info/crecoms/v1_0/recoms.php?op=recommend&uid=##&count=3&aid=#_#

• uidはユーザーのCookieです。
• aid-ライセンスハッシュ。
• count-推奨の数。

 { "id":"24aace52dc0284950bcff7b7f1b7a7f0de66aca9", "items":["1651384","1652041","1651556"] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アクセサリやいくつかの追加コンポーネントを販売するのに便利な同様の製品をお勧めします。



analytics.bitrix.info/crecoms/v1_0/recoms.php?op=simitems&aid=#_#&eid=#id_#&count=3&type=combined&uid=##

• uidはユーザーのCookieです。
• aid-ライセンスハッシュ。
• eid-製品ID
• タイプ-ビュー|注文|結合
• count-問題のサイズ。

別の有用なメカニズムは、販売量別の上位製品です。 これはすべて、ビッグデータに煩わされることなく行うことができると主張できます。 ストア自体で-はい、できます。 しかし、統計を使用することで、かなりの割合の負荷を店舗ベースから取り除くことができます。



analytics.bitrix.info/crecoms/v1_0/recoms.php?op=sim_domain_items&aid=#_#&domain=##&count=50&type=combined&uid=##

• uidはユーザーのCookieです。
• aid-ライセンスハッシュ。
• domain-サイトのドメイン。
• タイプ-ビュー|注文|結合
• count-問題のサイズ。

クライアントは、これらのツールをすべて組み合わせて使用​​できます。 個人的な推奨事項のクラウドサービスは、1C-Bitrix：Site Managementプラットフォーム自体と完全に統合されており、ストア開発者は発行された推奨事項のブロックを非常に柔軟に管理できます。 価格または他の基準などによるソートを使用します。



ユーザーのモデルを作成するとき、現在のセッションだけでなく、ユーザーのビューのすべての統計が考慮されます。 さらに、すべてのモデルは非個人化されます。つまり、システム内の各訪問者は、フェースレスIDの形式でのみです。 これにより、機密性を維持できます。



訪問者を訪問した店舗に応じて分割しません。 単一のデータベースがあり、訪問者がどの店に行っても、各訪問者には単一の識別子が割り当てられます。 小さな店舗には、ユーザーの行動を確実に予測できる十分な統計情報がないため、これは当社のサービスの主な利点の1つです。 また、単一のデータベースのおかげで、1日あたり10回の訪問がある店舗でも、この特定の訪問者に関心のある製品を推奨する可能性が高くなります。



データは古くなる可能性があるため、カスタムモデルを構築する場合、たとえば1年前の統計は考慮されません。 先月のデータのみが考慮されます。

実用例

サイト上のツールはどのように見えますか？



個人的な推奨事項のブロック。メインページに表示できます。 サイトへの訪問者ごとに個別です。







特定の製品のカードに表示することもできます。







推奨製品のブロックの例：







ブロックを組み合わせて、最も効率的な組み合わせを探すことができます。



個人的な推奨で販売された注文は、管理パネルに表示されます。







注文を処理する従業員は、チェックアウト時に購入者に推奨できる商品のリストを管理パネルにすぐに表示できます。







私たちのツールとは異なり、サードパーティのレコメンデーションサービスには重要な欠点があります-かなり少ないユーザーです。 これらのサービスを使用するには、推奨事項を表示するためのカウンターとウィジェットを挿入する必要があります。 ツールキットはプラットフォームと非常に緊密に統合されているため、訪問者に発行される推奨事項を改善できます。 たとえば、店舗の所有者は、価格や在庫状況によって推奨を並べ替えることができます。 他の商品の発行に混ぜます。

品質指標

主な疑問が生じます。上記のすべてがどれほど効果的に機能するのでしょうか？ パフォーマンスをどのように測定しますか？

• ビューの総数に対する推奨のビューの割合を計算します。
• また、推奨事項に対する注文数と合計注文数も測定します。
• ユーザー状態マシンで測定を行います。 3週間の行動を示すマトリックスがあり、それらに関する推奨事項を示します。 次に、たとえば1週間で状態を評価し、出された注文を将来提供できる推奨事項と比較します。 一致する場合、正しくお勧めします。 それらが一致しない場合は、アルゴリズムを強化するか完全に変更する必要があります。
• A / Bテスト。 オンラインストアの訪問者をグループに単純に分けることができます。1つは個人的な推奨事項のない製品を示し、もう1つは推奨事項のある製品を示し、売上の違いを評価します。

A / Bテストを使用して、近い将来にパーソナライズされた推奨事項を処理できるようになります。オンラインストアの所有者は、管理パネルで必要なメトリックを選択および構成し、しばらくの間データを収集し、異なるオーディエンスのコンバージョンを比較して差異を推定することができます。



データによると、コンバージョンの増加率は10〜35％です。 10％でさえ、投資の観点からオンラインストアの大きな指標です。 ユーザーは広告やエンゲージメントにより多くのお金を投入する代わりに、視聴者とより効果的に連携します。



しかし、なぜコンバージョンの伸びにそれほどのばらつきがあるのでしょうか？ 以下に依存します：

• さまざまな品揃え、
• トピックス
• サイト上の製品の総数、
• 視聴者の詳細
• 商品の束。

アイテムとアクセサリが少ないカタログでは、成長は少なくなります。 多くの追加のポジションを提供する店舗では、成長率が高くなります。

その他の用途

オンラインストアに加えて、このようなツールをどこで使用できますか？ 視聴者を増やしたいほとんどすべてのインターネットプロジェクトで。 結局のところ、商品ユニットは具体的なものだけではありません。 製品には、記事、テキスト素材、デジタル製品、サービスなどがあります。

• モバイルオペレーター、サービスプロバイダー：出発する準備ができている顧客を識別します。
• 銀行部門：追加サービスの販売。
• コンテンツプロジェクト。
• CRM
• メーリングをトリガーします。

同じモデルを使用して、たとえば無料の関税から有料の関税に、またはその逆に切り替える視聴者とその意欲を評価できます。 または、ユーザーが競合他社に去る可能性を評価できます。 これは、追加の割引マーケティングキャンペーンによって防止できます。 または、クライアントが製品またはサービスを購入しようとしている場合は、興味深いオファーを提供して、視聴者のロイヤルティを高めることができます。 当然、これらすべてをトリガーリンクで可能な限り柔軟に使用できます。 たとえば、製品を表示し、バスケットに入れたが、注文しなかったユーザーは、個人的なオファーを行うことができます。

BigDataプロジェクトの統計：カスタマイズ

現在、当社のプラットフォームでは1万7千の店舗が営業しており、システムは1か月あたり約4億4,000万のイベントを計算しています。 製品カタログ全体には、約1800万のアイテムが含まれています。 合計注文数に対する推奨の注文の割合：9〜37％。



ご覧のとおり、大量のデータがあり、それらは自重ではなく、機能して利益をもたらします。 プラットフォームで営業している店舗の場合、このサービスは無料です。 バックエンド側で変更できるオープンAPIがあり、特定の訪問者により柔軟な推奨を提供します。