Compute EngineGoogle Cloud Platformの機械孊習法に基づいたオンラむンストアの掚奚システム

Google Cloud Platformサヌビスを䜿甚するず、オンラむンストアに効果的でスケヌラブルな掚奚システムを䜜成できたす。



電子商取匕垂堎では興味深い状況が発生しおいたす。 総キャッシュフロヌは増加しおいたすが、売り手の数も増加しおいたす。 これにより、各店舗のシェアが䜎䞋し、競合が激化しおいたす。 平均賌入サむズしたがっお利益を増やす1぀の方法は、顧客に興味のある远加の補品を提䟛するこずです。



この蚘事では、Cloud Platformに基づいお環境を蚭定し、基本的な掚奚システムをサポヌトする方法を孊習したす。基本的な掚奚システムは、さらに開発および拡匵できたす。



ナヌザヌに掚奚事項を遞択しお提䟛できる䞍動産賃貞代理店のWebサむトの゜リュヌションに぀いお説明したす。







Google Cloud Platformを初めお䜿甚する堎合は、䞀連のりェビナヌをご芧ください
[1月19日、朚曜日、1100モスクワ時間]

Google Cloud Platform機胜の抂芁

  • Google Cloud Platformずは䜕ですか、その利点ず独自の機胜は䜕ですか
  • Googleクラりドむンフラストラクチャサヌビスの抂芁IaaS / PaaS、ストレヌゞ、ネットワヌク
  • Google Cloudのビッグデヌタず機械孊習サヌビスの抂芁


りェビナヌ゚ントリぞのリンク



[2月3日、金曜日、1100モスクワ時間]

Google Cloud Platformむンフラストラクチャサヌビス

  • Infrastructure as a ServiceIaaS賃貞甚のコンピュヌティングパワヌの提䟛
  • Google App EngineベヌスのNoOps / PaaS゜リュヌション
  • Google Container Engine-Docker Container Orchestration゜リュヌション


りェビナヌ゚ントリぞのリンク



[2月17日、金曜日、1100モスクワ時間]

Google Cloud Platformのビッグデヌタず機械孊習ツヌル

  • BigQuery-クラりドに倧量のデヌタを保存および取埗するためのデヌタりェアハりゞング゜リュヌション
  • Dataproc-Cloud Hadoopクラスタヌ
  • デヌタフロヌ-ストリヌミングおよびパケットデヌタを凊理するためのETLツヌル
  • CloudML-機械孊習モデルを開発およびトレヌニングするためのプラットフォヌム
  • たた、このりェビナヌでは、GCPでストレヌゞサヌビスを䜿甚するさたざたな偎面に぀いお説明したす


りェビナヌ゚ントリぞのリンク



[3月2日、朚曜日、1100モスクワ時間]

ワヌクショップGoogle Cloud Platformサヌビスのチュヌトリアル

  • Google Compute Engine-仮想マシンの管理グルヌプでタスクを起動し、グロヌバルな負荷分散ず自動スケヌリング
  • Google App Engine-Google PaaSプラットフォヌムでのWebアプリケヌションの反埩的な開発ず展開


りェビナヌリヌド

オレグ・むボニン



@GoogleAmsterdam



クラりドWeb゜リュヌション゚ンゞニア

Olegは、構成のコストを分析し、Google Cloud Platformに基づくクラりド゜リュヌションのアヌキテクチャを蚈画するためのツヌルを開発しおいたす。 Olegの開発は、Google Cloud Platform Pricing Calculatorなどの公開されおいるGCPツヌルで䜿甚されおいたす

ドミトリヌ・ノノァコフスキヌ



@GoogleAmsterdam



カスタマヌ゚ンゞニア

Dmitryは、Google Cloud Platformのビゞネス顧客向けの販売サポヌトずアヌキテクチャ゜リュヌションに埓事しおいたす。 Dmitryの䞻な焊点は、むンフラストラクチャサヌビスの分野にありたすGoogle Compute EngineGCE、Google App EngineGAE、Google Container EngineGKE / Kubernetes。





おそらく、この蚘事を読んで、Google Cloud Platformでこのシナリオを再䜜成するこずをお勧めしたす。 リンクをクリックするず、GCPサヌビスを60日間テストするための300ドルを受け取りたす


スクリプト



アンナは専甚サむトで別荘を探しおいたす。 以前は、圌女はすでにこのサむトから䜏宅を借りおいく぀かのレビュヌを残しおいたため、システムには圌女の奜みに基づいお掚奚事項を遞択するのに十分なデヌタがありたす。 アンナのプロフィヌルの掚定から刀断するず、圌女は通垞、アパヌトではなく家を借りおいたす。 システムは、圌女に同じカテゎリの䜕かを提䟛する必芁がありたす。



゜リュヌションの抂芁



リアルタむムサむト䞊たたは事埌電子メヌル経由で掚奚事項を遞択するには、゜ヌスデヌタが必芁です。 それでもナヌザヌの蚭定がわからない堎合は、ナヌザヌが遞択した提案に基づいお掚奚事項を遞択できたす。 ただし、システムは絶えず孊習し、顧客の奜みに関するデヌタを蓄積する必芁がありたす。 十分な情報が収集されるず、機械孊習システムを䜿甚しお関連する掚奚事項を分析および遞択できるようになりたす。 さらに、システムは他のナヌザヌに関する情報を送信したり、時々再トレヌニングしたりできたす。 この䟋では、掚奚システムはすでに機械孊習アルゎリズムを䜿甚するのに十分なデヌタを蓄積しおいたす。



このようなシステムでのデヌタ凊理は、通垞、収集、保管、分析、掚奚事項の遞択の4段階で実行されたす䞋図を参照。









このようなシステムのアヌキテクチャは、次のように抂略的に衚すこずができたす。









各ステップは、特定の芁件に合わせおカスタマむズできたす。 システムは次の芁玠で構成されおいたす。





コンポヌネントの遞択



高速で䟿利、安䟡で正確な゜リュヌションを埗るために、 Google App Engine 、 Google Cloud SQL 、およびGoogle Compute EngineベヌスのApache Sparkが遞択されたした。 構成は、bdutilスクリプトを䜿甚しお䜜成されたした。



App Engineサヌビスを䜿甚するず、1秒あたり䜕䞇ものリク゚ストを凊理できたす。 さらに、管理が容易で、サむトの䜜成から内郚ストレヌゞぞのデヌタの曞き蟌みたで、あらゆるタスクを実行するコヌドをすばやく蚘述しお実行できたす。



Cloud SQLは、゜リュヌションの䜜成も簡玠化したす。 最倧208 GBのRAMを搭茉した32コアの仮想マシンを展開し、GBあたり毎秒30のI / O操䜜ず数千の同時接続により、オンデマンドで最倧10 TBのストレヌゞを増やすこずができたす。 これは、怜蚎䞭のシステムおよび他の倚くの実際のケヌスにずっお十分すぎるほどです。 さらに、Cloud SQLはSparkからの盎接アクセスをサポヌトしおいたす。



Sparkは、埓来のHadoopプロセッサず比范しお優れおいたす。具䜓的な゜リュヌションにもよりたすが、パフォヌマンスは10〜100倍高くなりたす。 Spark MLlibラむブラリを䜿甚するず、数億の評䟡を数分で分析し、アルゎリズムをより頻繁に実行しお、掚奚事項を最新の状態に保぀こずができたす。 Sparkは、よりシンプルなプログラミングモデル、より䟿利なAPI、およびより汎甚的な蚀語が特城です。 蚈算のために、このフレヌムワヌクはRAMを最倧限に䜿甚しお、ディスクアクセスの回数を枛らしたす。 たた、I / O操䜜の数も最小限に抑えられたす。 分析むンフラストラクチャをホストするこの゜リュヌションでは、Compute Engineが䜿甚されたす。 これにより、䜿甚の事実に応じお毎分支払いが行われるため、コストを倧幅に削枛できたす。



次の図は、同じシステムアヌキテクチャを瀺しおいたすが、珟圚は䜿甚されおいるテクノロゞが含たれおいたす。









デヌタ収集



掚奚システムは、暗黙的な情報動䜜たたは明瀺的な情報評䟡ずレビュヌに基づいおナヌザヌデヌタを収集できたす。



すべおのアクションはナヌザヌの介入なしにログに蚘録できるため、動䜜デヌタの収集は非垞に簡単です。 このアプロヌチの欠点は、収集されたデヌタを分析するのが難しくなるこずです。たずえば、最も重芁なデヌタを識別するこずができたす。 ログ゚ントリを䜿甚しお明瀺的なアクティビティデヌタを分析する䟋は、 ここから入手できたす 。



評䟡ずレビュヌを収集するこずは、倚くのナヌザヌがそれらを残すこずに消極的であるため、より困難です。 ただし、顧客の奜みを理解するのに最も圹立぀のはこのようなデヌタです。



デヌタ保存



アルゎリズムで䜿甚できるデヌタが倚いほど、掚奚事項はより正確になりたす。 ぀たり、すぐにビッグデヌタの操䜜を開始する必芁がありたす。



䜿甚するストレヌゞのタむプの遞択は、掚奚デヌタを䜜成するデヌタに基づいお異なりたす。 NoSQLデヌタベヌス、SQL、たたはオブゞェクトストアでもかたいたせん。 デヌタの量ず皮類に加えお、実装の容易さ、環境に統合する機胜、移行のサポヌトなどの芁因を考慮する必芁がありたす。



スケヌラブルな管理されたデヌタベヌスは、ナヌザヌの評䟡ずアクションを保存するのに最適であり、䜿いやすく、より倚くの時間を費やすこずができたす。 Cloud SQLはこれらの芁件を満たすだけでなく、Sparkからデヌタを簡単にダりンロヌドできるようにしたす。



次のコヌド䟋は、Cloud SQLテヌブルスキヌマを瀺しおいたす。 賃貞物件は「宿泊斜蚭」テヌブルに入力され、この物件のナヌザヌ評䟡は「評䟡」テヌブルに入力されたす。



CREATE TABLE Accommodation ( id varchar(255), title varchar(255), location varchar(255), price int, rooms int, rating float, type varchar(255), PRIMARY KEY (ID) ); CREATE TABLE Rating ( userId varchar(255), accoId varchar(255), rating int, PRIMARY KEY(accoId, userId), FOREIGN KEY (accoId) REFERENCES Accommodation(id) );
      
      





Sparkは、Hadoop HDFSやCloud Storageなどのさたざたな゜ヌスからデヌタを取埗できたす。 この゜リュヌションでは、デヌタはJDBCコネクタヌを䜿甚しお Cloud SQLから盎接抜出されたす 。 Sparkゞョブは䞊行しお実行されるため、このコネクタヌはクラスタヌのすべおのむンスタンスで䜿甚可胜でなければなりたせん。



デヌタ分析



分析を成功させるには、アプリケヌションの芁件を明確に策定する必芁がありたす。





適時性



最初に決定するこずは、ナヌザヌがどれだけ早く掚奚事項を受け取るかです。 すぐに、サむトを衚瀺したずき、たたは埌で、メヌルで 最初のケヌスでは、もちろん、分析はより効率的でなければなりたせん。





任意のカテゎリの適時性を遞択できたすが、オンラむン販売の堎合、トラフィックの量ず凊理されるデヌタのタむプに応じお、バッチ分析ずほがリアルタむムの分析のクロスが最適です。 分析プラットフォヌムは、デヌタベヌスず盎接連携するこずも、氞続ストレヌゞに定期的に保存されるダンプず連携するこずもできたす。



デヌタフィルタリング



フィルタリングは、掚奚システムの重芁なコンポヌネントです。 フィルタリングの䞻なアプロヌチは次のずおりです。





Cloud Platformは3぀のタむプすべおをサポヌトしおいたすが、この゜リュヌションでは、Apache Sparkに基づく協調フィルタリングアルゎリズムが遞択されたした。 コンテンツずクラスタヌフィルタリングの詳现に぀いおは、 付録を参照しおください。



協調フィルタリングにより、補品の属性から抜象化し、ナヌザヌの奜みを考慮した予枬を行うこずができたす。 このアプロヌチは、同じ補品を奜む2人のナヌザヌの嗜奜が同じたたであるずいう前提に基づいおいたす。



評䟡ずアクションに関するデヌタはマトリックスのセットずしお、補品ずナヌザヌは数量ずしお提瀺できたす。 システムはマトリックス内の欠萜セルを埋め、補品に察するナヌザヌの態床を予枬しようずしたす。 以䞋は、1぀のマトリックスの2぀のオプションです。最初のオプションは、既存の掚定倀を瀺しおいたす。 2番目では、それらは単䞀性で瀺され、欠萜した評䟡はれロで瀺されたす。 ぀たり、2番目のオプションは真理倀衚であり、ナニットはナヌザヌず補品ずの察話を瀺したす。







協調フィルタリングでは、䞻に2぀の方法が䜿甚されたす。





この゜リュヌションでは、ナヌザヌ評䟡に基づくモデル手法が䜿甚されたす。



この゜リュヌションに必芁なすべおの分析ツヌルは、SparkのPythonプログラミングむンタヌフェむスであるPySparkで利甚できたす。 ScalaずJavaは远加の機䌚を提䟛したす。 Sparkのドキュメントを参照しおください。



モデルトレヌニング



Spark MLlibは、ALSAlternating Least Squaresアルゎリズムを䜿甚しおモデルをトレヌニングしたす。 倉䜍ず分散の最適な比率を実珟するには、次のパラメヌタヌの倀を調敎する必芁がありたす。





この図は、さたざたな分散および倉䜍比を瀺しおいたす。 タヌゲットの䞭心は、アルゎリズムを䜿甚しお予枬する倀です。









以䞋は、SparkでALSトレヌニングモデルを実行するサンプルコヌドです。



 from pyspark.mllib.recommendation import ALS model = ALS.train(training, rank = 10, iterations = 5, lambda_=0.01)
      
      





モデル遞択



ALSアルゎリズムに基づく協調フィルタリングでは、3぀のデヌタセットが䜿甚されたす。





最適なモデルを遞択するには、蚈算されたモデル、テストサンプル、およびそのサむズを基瀎ずしお、二乗平均平方根誀差RMSEを蚈算する必芁がありたす。 RMSEが小さいほど、モデルの粟床は高くなりたす。



勧告の結論



分析結果の出力を高速化するには、それらをデヌタベヌスにロヌドしお、オンデマンドでク゚リを実行できるようにする必芁がありたす。 これにはCloud SQLが最適です。 Spark 1.4を䜿甚するず、PySparkからデヌタベヌスに分析結果を盎接曞き蟌むこずができたす。



掚奚衚の抂芁は次のずおりです。



 CREATE TABLE Recommendation ( userId varchar(255), accoId varchar(255), prediction float, PRIMARY KEY(userId, accoId), FOREIGN KEY (accoId) REFERENCES Accommodation(id) );
      
      





コヌド分​​析



次に、トレヌニングモデルのコヌドを怜蚎したす。



Cloud SQLからデヌタを取埗する



Spark SQLコンテキストを䜿甚するず、JDBCコネクタを介しおCloud SQLむンスタンスに簡単に接続できたす。 デヌタはDataFrame圢匏でロヌドされたす。



pyspark / app_collaborative.py



 jdbcDriver = 'com.mysql.jdbc.Driver' jdbcUrl = 'jdbc:mysql://%s:3306/%s?user=%s&password=%s' % (CLOUDSQL_INSTANCE_IP, CLOUDSQL_DB_NAME, CLOUDSQL_USER, CLOUDSQL_PWD) dfAccos = sqlContext.load(source='jdbc', driver=jdbcDriver, url=jdbcUrl, dbtable=TABLE_ITEMS) dfRates = sqlContext.load(source='jdbc', driver=jdbcDriver, url=jdbcUrl, dbtable=TABLE_RATINGS)
      
      





DataFrameをRDDに倉換し、デヌタセットを䜜成したす



SparkはRDDResilient Distributed Datasetの抂念に基づいおいたす。これは、芁玠を䞊行しお操䜜できる抜象化です。 RDDは、氞続ストレヌゞに基づく読み取り専甚のデヌタコレクションです。 このようなコレクションはメモリ内で分析できるため、反埩凊理が可胜です。



芚えおいるように、最適なモデルを遞択するには、デヌタセットを3぀のサンプルに分割する必芁がありたす。 次のコヌドでは、重耇しない倀をランダムに60/20/20の割合で分離する補助関数を䜿甚しおいたす。



pyspark / app_collaborative.py



 rddTraining, rddValidating, rddTesting = dfRates.rdd.randomSplit([6,2,2])
      
      





ご泚意 Ratingテヌブルの列は、accoId、userId、ratingの順序で配眮する必芁がありたす。 これは、ALSアルゎリズムが特定の補品/ナヌザヌのペアに基づいお予枬を行うずいう事実によるものです。 順序が狂っおいる堎合は、RDDのマップ機胜を䜿甚しおデヌタベヌスを倉曎するか、列を䞊べ替えるこずができたす。



トレヌニングモデルのパラメヌタヌの遞択



すでに述べたように、ALSメ゜ッドでは、最適なモデルを最終的に取埗できるように、ランク、正則化、および反埩を調敎するこずがタスクです。 システムにはすでにナヌザヌの評䟡があるため、トレむン機胜の結果をテスト遞択ず比范する必芁がありたす。 トレヌニングサンプルがナヌザヌの奜みを考慮に入れおいるこずを確認する必芁がありたす。



pyspark / find_model_collaborative.py



 for cRank, cRegul, cIter in itertools.product(ranks, reguls, iters): model = ALS.train(rddTraining, cRank, cIter, float(cRegul)) dist = howFarAreWe(model, rddValidating, nbValidating) if dist < finalDist: print("Best so far:%f" % dist) finalModel = model finalRank = cRank finalRegul = cRegul finalIter = cIter finalDist = dist
      
      





ご泚意 howFarAreWe関数は、モデルを䜿甚しお、補品/ナヌザヌのペアのみに基づいおテストセットの掚定倀を予枬したす。



pyspark / find_model_collaborative.py



 def howFarAreWe(model, against, sizeAgainst): # Ignore the rating column againstNoRatings = against.map(lambda x: (int(x[0]), int(x[1])) ) # Keep the rating to compare against againstWiRatings = against.map(lambda x: ((int(x[0]),int(x[1])), int(x[2])) ) # Make a prediction and map it for later comparison # The map has to be ((user,product), rating) not ((product,user), rating) predictions = model.predictAll(againstNoRatings).map(lambda p: ( (p[0],p[1]), p[2]) ) # Returns the pairs (prediction, rating) predictionsAndRatings = predictions.join(againstWiRatings).values() # Returns the variance return sqrt(predictionsAndRatings.map(lambda s: (s[0] - s[1]) ** 2).reduce(add) / float(sizeAgainst))
      
      





ナヌザヌにずっお最も正確な予枬の蚈算



最適なモデルを遞択するず、同様の趣味を持぀他のナヌザヌの奜みに基づいお、ナヌザヌが䜕に興味を持぀かを予枬する可胜性が非垞に高くなりたす。 以䞋は、前述のマトリックス図です。



pyspark / app_collaborative.py



 # Build our model with the best found values # Rating, Rank, Iteration, Regulation model = ALS.train(rddTraining, BEST_RANK, BEST_ITERATION, BEST_REGULATION) # Calculate all predictions predictions = model.predictAll(pairsPotential).map(lambda p: (str(p[0]), str(p[1]), float(p[2]))) # Take the top 5 ones topPredictions = predictions.takeOrdered(5, key=lambda x: -x[2]) print(topPredictions) schema = StructType([StructField("userId", StringType(), True), StructField("accoId", StringType(), True), StructField("prediction", FloatType(), True)]) dfToSave = sqlContext.createDataFrame(topPredictions, schema) dfToSave.write.jdbc(url=jdbcUrl, table=TABLE_RECOMMENDATIONS, mode='overwrite')
      
      





最も正確な予枬を保存する



すべおの予枬のリストを受け取った埌、最初の10個の予枬をCloud SQLに保存する必芁がありたす。これにより、たずえばサむトに入るずきにシステムがナヌザヌに掚奚を発行し始めたす



pyspark / app_collaborative.py



 dfToSave = sqlContext.createDataFrame(topPredictions, schema) dfToSave.write.jdbc(url=jdbcUrl, table=TABLE_RECOMMENDATIONS, mode='overwrite')
      
      





゜リュヌションの発売



個々のナヌザヌ向けの掚奚事項を開発および衚瀺できる゜リュヌションを起動するための段階的な手順は、 GitHubで入手できたす 。



SQLク゚リコヌドの最埌のフラグメントは、デヌタベヌスから最も関連性の高い掚奚事項を受け取り、Annaの開始ペヌゞに衚瀺したす。



Cloud Platformコン゜ヌルたたはMySQLクラむアントでこのク゚リを実行した結果の䟋







このク゚リの結果をサむトのスタヌトペヌゞに远加しお、ナヌザヌの関心を高め、コンバヌゞョンレベルを高めるこずができたす。







アンナに関する利甚可胜な情報が蚘述されたシナリオに基づいお、システムはアンナに興味がある提案を遞択したした。



タスク監芖



bdutil構成での監芖



以前にSSH経由で芪むンスタンスに接続したした。 Sparkには、Webむンタヌフェヌスを介しお進行䞭のタスクを監芖できる管理コン゜ヌルがありたす。



デフォルトでは、ポヌト8080からコン゜ヌルにアクセスできたす。むンスタンスごずにこのポヌトぞのアクセスを開く必芁がありたす。 ファむアりォヌルルヌルを远加する手順に぀いおは、 こちらをご芧ください 。 コン゜ヌルを開くには、ブラりザのアドレスバヌにむンスタンスの倖郚IPアドレスを入力したす たずえば、 1.2.3.4 8080。 䞋のスクリヌンショットのSparkコン゜ヌルには、䜜業ノヌド、実行䞭のアプリケヌション、完了したアプリケヌションに関する情報を含む3぀のセクションがありたす。







Sparkコン゜ヌル



Cloud Dataprocでの監芖



出力ずWebむンタヌフェヌスの詳现に぀いおは、Cloud Dataprocのドキュメントを参照しおください。



ガむド



セットアップ手順ずサンプル゜ヌスコヌドを含む完党なガむドは、GitHubで入手できたす 。



アプリ



クロスフィルタリング



䞊蚘の䟋から、協調フィルタリングに基づいお掚奚事項を遞択するための効果的でスケヌラブルな゜リュヌションを䜜成する方法を孊びたした。 掚奚事項をさらに正確にするために、他の方法を䜿甚しお結果をフィルタリングできたす。 これは、コンテンツフィルタリングずクラスタヌフィルタリングの2぀の䞻芁なフィルタリングタむプになりたす。 これらのアプロヌチの組み合わせにより、ナヌザヌはより良い掚奚事項を提䟛できたす。









コンテンツフィルタリング



このタむプのフィルタリングにより、属性ず少数のナヌザヌ評䟡を持぀オブゞェクトの掚奚事項を遞択できたす。 オブゞェクトの類䌌性は、その属性に基づいお決定されたす。 ナヌザヌベヌスが倧きい堎合でも、凊理される属性の数は蚱容レベルのたたです。



コンテンツフィルタリングを远加するには、ディレクトリ内のオブゞェクトに察しお他のナヌザヌが蚭定した既存の評䟡を䜿甚できたす。 これらの評䟡に基づいお、ナヌザヌが衚瀺しおいる補品に最も近い補品が遞択されたす。



原則ずしお、2぀の補品の類䌌性を決定するために、Otiai係数が最初に蚈算され、次に最も近いものが怜玢されたす。















結果は0〜1の範囲の数倀になりたす。1に近いほど、商品の類䌌性は高くなりたす。









次のマトリックスを怜蚎しおください。









P1ずP2の類䌌性は、次の匏を䜿甚しお蚈算されたす。









コンテンツフィルタリングシステムは、さたざたなツヌルを䜿甚しお䜜成できたす。 以䞋に2぀の䟋を瀺したす。





 git clone https://github.com/apache/mahout.git mahout export MAHOUT_HOME=/path/to/mahout export MAHOUT_LOCAL=false #For cluster operation export SPARK_HOME=/path/to/spark export MASTER=spark://hadoop-m:7077 #Found in Spark console
      
      





ご泚意 Mahoutラむブラリを䜿甚するには、Mavenが必芁です。



クラスタリング



怜玢コンテキストを理解し、ナヌザヌが衚瀺しおいる補品を特定するこずが重芁です。 異なる状況では、同じ人が完党に異なる補品を探すこずができたすが、必ずしも自分ではありたせん。 そのため、ナヌザヌが衚瀺しおいる補品ず䌌おいる補品を知る必芁がありたす。 k-meansクラスタリングを䜿甚する堎合、システムは、䞻芁な属性に基づいお類䌌のオブゞェクトをセグメントに結合したす。



珟圚、ロンドンで家を探しおいるナヌザヌは、オヌクランドの䜏宅に興味を持぀可胜性が䜎いため、この䟋では、システムはそのようなオファヌを陀倖する必芁がありたす。



 from pyspark.mllib.clustering import KMeans, KMeansModel clusters = KMeans.train(parsedData, 2, maxIterations=10, runs=10, initializationMode="random")
      
      





結果を改善するには



掚奚事項をさらに正確にするために、分析では、泚文の履歎やサポヌト芁求、人口統蚈情報幎霢、堎所、性別などなどの远加芁因を考慮するこずができたす。 倚くの堎合、このデヌタは顧客関係管理CRMたたはビゞネスリ゜ヌスプランニングERPシステムに既に保存されおいたす。



たた、倖郚芁因がナヌザヌの決定に圱響を䞎える可胜性があるこずに泚意する必芁がありたす。 レクリ゚ヌションの堎所を遞択するずき、倚くの顧客、特に小さな子䟛を持぀家族は、生態孊的に枅朔な地域を探しおいたす。 この䟋では、 BreezometerなどのサヌドパヌティAPIをCloud Platformベヌスの掚奚システムに統合するず、競争䞊の優䜍性をさらに埗るこずができたす。



Softline-Google Cloud Premierパヌトナヌ
Softlineは、ロシアおよびCIS諞囜で最倧の䌁業サヌビスプロバむダヌであり、GoogleおよびGoogle Cloud Premierパヌトナヌのステヌタスを持぀唯䞀のパヌトナヌです。 同瀟は長幎にわたり、゚ンタヌプラむズセグメントの幎間最優秀パヌトナヌ、SMBセグメントのEMEA地域の幎間最優秀パヌトナヌずしお認められたした。






All Articles