【Python使用】嘿馬推薦系統(tǒng)全知識和項目開發(fā)教程第4篇：1、Spark SQL 概述,spark 入門【附代碼文檔】

教程總體簡介：2、DataFrame、spark ml的模型訓(xùn)練是基于內(nèi)存的、如果數(shù)據(jù)過大、內(nèi)存空間小、迭代次數(shù)過多的化、可能會造成內(nèi)存溢出、報錯、設(shè)置Checkpoint的話、會把所有數(shù)據(jù)落盤、這樣如果異常退出、下次重啟后、可以接著上次的訓(xùn)練節(jié)點繼續(xù)運行、但該方法其實指標(biāo)不治本、因為無法防止內(nèi)存溢出、所以還是會報錯、如果數(shù)據(jù)量大、應(yīng)考慮的是增加內(nèi)存、或限制迭代次數(shù)和訓(xùn)練數(shù)據(jù)量級等、從hdfs加載CSV文件、返回一個PythonRDD類型、此時還沒開始計算、用戶對商品類別的打分數(shù)據(jù)、map返回的結(jié)果是rdd類型、需要調(diào)用toDF方法轉(zhuǎn)換為Dataframe、注意、toDF不是每個rdd都有的方法、僅局限于此處的rdd、可通過該方法獲得 user-cate-matrix、但由于cateId字段過多、這里運算量比很大、機器內(nèi)存要求很高才能執(zhí)行、否則無法完成任務(wù)、請謹慎使用、但好在我們訓(xùn)練ALS模型時、不需要轉(zhuǎn)換為user-cate-matrix、所以這里可以不用運行、cate_rating_df.groupBy("userId").povit("cateId").min("rating")、用戶對類別的偏好打分數(shù)據(jù)、使用pyspark中的ALS矩陣分解方法實現(xiàn)CF評分預(yù)測、文檔地址、利用打分數(shù)據(jù)、訓(xùn)練ALS模型、此處訓(xùn)練時間較長、model.recommendForAllUsers(N) 給所有用戶推薦TOP-N個物品、由于是給所有用戶、從HDFS加載用戶基本信息數(shù)據(jù)、發(fā)現(xiàn)pvalue_level和new_user_class_level存在空值、（注意此處的null表示空值、而如果是NULL、則往往表示是一個字符串）、因此直接利用schema就可以加載進該數(shù)據(jù)、無需替換null值、這里的null會直接被pyspark識別為None數(shù)據(jù)、也就是na數(shù)據(jù)、所以這里可以直接利用schem


項目完整code和文檔，小伙伴們---->git倉庫

全套教程部分目錄：

1、Spark SQL 概述

Spark SQL概念

  • Spark SQL is Apache Spark's module for working with structured data.

    • 它是spark中用于處理結(jié)構(gòu)化數(shù)據(jù)的一個模塊

Spark SQL歷史

  • Hive是目前大數(shù)據(jù)領(lǐng)域，事實上的數(shù)據(jù)倉庫標(biāo)準(zhǔn)。
  • Shark：shark底層使用spark的基于內(nèi)存的計算模型，從而讓性能比Hive提升了數(shù)倍到上百倍。
  • 底層很多東西還是依賴于Hive，修改了內(nèi)存管理、物理計劃、執(zhí)行三個模塊
  • 2014年6月1日的時候，Spark宣布了不再開發(fā)Shark，全面轉(zhuǎn)向Spark SQL的開發(fā)

Spark SQL優(yōu)勢

  • Write Less Code
  • Performance

python操作RDD，轉(zhuǎn)換為可執(zhí)行代碼，運行在java虛擬機，涉及兩個不同語言引擎之間的切換，進行進程間 通信很耗費性能。

DataFrame

  • 是RDD為基礎(chǔ)的分布式數(shù)據(jù)集，類似于傳統(tǒng)關(guān)系型數(shù)據(jù)庫的二維表，dataframe記錄了對應(yīng)列的名稱和類型

  • dataFrame引入schema和off-heap(使用操作系統(tǒng)層面上的內(nèi)存)

    • 1、解決了RDD的缺點
    • 序列化和反序列化開銷大
    • 頻繁的創(chuàng)建和銷毀對象造成大量的GC
    • 2、丟失了RDD的優(yōu)點
    • RDD編譯時進行類型檢查
    • RDD具有面向?qū)ο缶幊痰奶匦?/li>

用scala/python編寫的RDD比Spark SQL編寫轉(zhuǎn)換的RDD慢，涉及到執(zhí)行計劃

  • CatalystOptimizer：Catalyst優(yōu)化器
  • ProjectTungsten：鎢絲計劃，為了提高RDD的效率而制定的計劃
  • Code gen：代碼生成器

直接編寫RDD也可以自實現(xiàn)優(yōu)化代碼，但是遠不及SparkSQL前面的優(yōu)化操作后轉(zhuǎn)換的RDD效率高，快1倍左右

優(yōu)化引擎：類似mysql等關(guān)系型數(shù)據(jù)庫基于成本的優(yōu)化器

首先執(zhí)行邏輯執(zhí)行計劃，然后轉(zhuǎn)換為物理執(zhí)行計劃(選擇成本最小的)，通過Code Generation最終生成為RDD

  • Language-independent API

用任何語言編寫生成的RDD都一樣，而使用spark-core編寫的RDD，不同的語言生成不同的RDD

  • Schema

結(jié)構(gòu)化數(shù)據(jù)，可以直接看出數(shù)據(jù)的詳情

在RDD中無法看出，解釋性不強，無法告訴引擎信息，沒法詳細優(yōu)化。

為什么要學(xué)習(xí)sparksql

sparksql特性

  • 1、易整合
  • 2、統(tǒng)一的數(shù)據(jù)源訪問
  • 3、兼容hive
  • 4、提供了標(biāo)準(zhǔn)的數(shù)據(jù)庫連接（jdbc/odbc）

spark 入門

目標(biāo)：

  • 了解spark概念
  • 知道spark的特點（與hadoop對比）
  • 獨立實現(xiàn)spark local模式的啟動

1.1 spark概述

  • 1、什么是spark

    • 基于內(nèi)存的計算引擎，它的計算速度非?？?。但是僅僅只涉及到數(shù)據(jù)的計算，并沒有涉及到數(shù)據(jù)的存儲。

  • 2、為什么要學(xué)習(xí)spark

MapReduce框架局限性

  • 1，Map結(jié)果寫磁盤，Reduce寫HDFS，多個MR之間通過HDFS交換數(shù)據(jù)
  • 2，任務(wù)調(diào)度和啟動開銷大
  • 3，無法充分利用內(nèi)存
  • 4，不適合迭代計算（如機器學(xué)習(xí)、圖計算等等），交互式處理（數(shù)據(jù)挖掘）
  • 5，不適合流式處理（點擊日志分析）
  • 6，MapReduce編程不夠靈活，僅支持Map和Reduce兩種操作

Hadoop生態(tài)圈

  • 批處理：MapReduce、Hive、Pig
  • 流式計算：Storm
  • 交互式計算：Impala、presto

需要一種靈活的框架可同時進行批處理、流式計算、交互式計算

  • 內(nèi)存計算引擎，提供cache機制來支持需要反復(fù)迭代計算或者多次數(shù)據(jù)共享，減少數(shù)據(jù)讀取的IO開銷
  • DAG引擎，較少多次計算之間中間結(jié)果寫到HDFS的開銷
  • 使用多線程模型來減少task啟動開銷，shuffle過程中避免不必要的sort操作以及減少磁盤IO

spark的缺點是：吃內(nèi)存，不太穩(wěn)定

  • 3、spark特點

    • 1、速度快（比mapreduce在內(nèi)存中快100倍，在磁盤中快10倍）

      • spark中的job中間結(jié)果可以不落地，可以存放在內(nèi)存中。
      • mapreduce中map和reduce任務(wù)都是以進程的方式運行著，而spark中的job是以線程方式運行在進程中。

    • 2、易用性（可以通過java/scala/python/R開發(fā)spark應(yīng)用程序）

    • 3、通用性（可以使用spark sql/spark streaming/mlib/Graphx）

    • 4、兼容性（spark程序可以運行在standalone/yarn/mesos）

1.2 spark啟動（local模式）和WordCount(演示)

  • 啟動pyspark

    • 在$SPARK_HOME/sbin目錄下執(zhí)行

      • ./pyspark

sc = spark.sparkContext
words = sc.textFile('file:///home/hadoop/tmp/word.txt')
.flatMap(lambda line: line.split(" "))
.map(lambda x: (x, 1))
.reduceByKey(lambda a, b: a + b).collect()




* 輸出結(jié)果：

```shell
[('python', 2), ('hadoop', 1), ('bc', 1), ('foo', 4), ('test', 2), ('bar', 2), ('quux', 2), ('abc', 2), ('ab', 1), ('you', 1), ('ac', 1), ('bec', 1), ('by', 1), ('see', 1), ('labs', 2), ('me', 1), ('welcome', 1)]

一 個性化電商廣告推薦系統(tǒng)介紹

1.1 數(shù)據(jù)集介紹

  • Ali_Display_Ad_Click是阿里巴巴提供的一個淘寶展示廣告點擊率預(yù)估數(shù)據(jù)集

數(shù)據(jù)集來源：天池競賽

  • 原始樣本骨架raw_sample

淘寶網(wǎng)站中隨機抽樣了114萬用戶8天內(nèi)的廣告展示/點擊日志（2600萬條記錄），構(gòu)成原始的樣本骨架。 字段說明如下：

  1. user_id：脫敏過的用戶ID；
  2. adgroup_id：脫敏過的廣告單元ID；
  3. time_stamp：時間戳；
  4. pid：資源位；
  5. noclk：為1代表沒有點擊；為0代表點擊；
  6. clk：為0代表沒有點擊；為1代表點擊；

用前面7天的做訓(xùn)練樣本（20170506-20170512），用第8天的做測試樣本（20170513）

  • 廣告基本信息表ad_feature

本數(shù)據(jù)集涵蓋了raw_sample中全部廣告的基本信息(約80萬條目)。字段說明如下：

  1. adgroup_id：脫敏過的廣告ID；
  2. cate_id：脫敏過的商品類目ID；
  3. campaign_id：脫敏過的廣告計劃ID；
  4. customer_id: 脫敏過的廣告主ID；
  5. brand_id：脫敏過的品牌ID；
  6. price: 寶貝的價格

其中一個廣告ID對應(yīng)一個商品（寶貝），一個寶貝屬于一個類目，一個寶貝屬于一個品牌。

  • 用戶基本信息表user_profile

本數(shù)據(jù)集涵蓋了raw_sample中全部用戶的基本信息(約100多萬用戶)。字段說明如下：

  1. userid：脫敏過的用戶ID；
  2. cms_segid：微群ID；
  3. cms_group_id：cms_group_id；
  4. final_gender_code：性別 1:男,2:女；
  5. age_level：年齡層次； 1234
  6. pvalue_level：消費檔次，1:低檔，2:中檔，3:高檔；
  7. shopping_level：購物深度，1:淺層用戶,2:中度用戶,3:深度用戶
  8. occupation：是否大學(xué)生 ，1:是,0:否
  9. new_user_class_level：城市層級
  • 用戶的行為日志behavior_log

本數(shù)據(jù)集涵蓋了raw_sample中全部用戶22天內(nèi)的購物行為(共七億條記錄)。字段說明如下：

user：脫敏過的用戶ID； time_stamp：時間戳； btag：行為類型, 包括以下四種： 類型 | 說明 pv | 瀏覽 cart | 加入購物車 fav | 喜歡 buy | 購買 cate_id：脫敏過的商品類目id； brand_id: 脫敏過的品牌id； 這里以user + time_stamp為key，會有很多重復(fù)的記錄；這是因為我們的不同的類型的行為數(shù)據(jù)是不同部門記錄的，在打包到一起的時候，實際上會有小的偏差（即兩個一樣的time_stamp實際上是差異比較小的兩個時間）

1.2 項目效果展示

1.3 項目實現(xiàn)分析

  • 主要包括

    • 一份廣告點擊的樣本數(shù)據(jù)raw_sample.csv：體現(xiàn)的是用戶對不同位置廣告點擊、沒點擊的情況
    • 一份廣告基本信息數(shù)據(jù)ad_feature.csv：體現(xiàn)的是每個廣告的類目(id)、品牌(id)、價格特征
    • 一份用戶基本信息數(shù)據(jù)user_profile.csv：體現(xiàn)的是用戶群組、性別、年齡、消費購物檔次、所在城市級別等特征
    • 一份用戶行為日志數(shù)據(jù)behavior_log.csv：體現(xiàn)用戶對商品類目(id)、品牌(id)的瀏覽、加購物車、收藏、購買等信息

我們是在對非搜索類型的廣告進行點擊率預(yù)測和推薦(沒有搜索詞、沒有廣告的內(nèi)容特征信息)

  1. 推薦業(yè)務(wù)處理主要流程： 召回 ===> 排序 ===> 過濾

    • 離線處理業(yè)務(wù)流

      • raw_sample.csv ==> 歷史樣本數(shù)據(jù)
      • ad_feature.csv ==> 廣告特征數(shù)據(jù)
      • user_profile.csv ==> 用戶特征數(shù)據(jù)
      • raw_sample.csv + ad_feature.csv + user_profile.csv ==> CTR點擊率預(yù)測模型
      • behavior_log.csv ==> 評分數(shù)據(jù) ==> user-cate/brand評分數(shù)據(jù) ==> 協(xié)同過濾 ==> top-N cate/brand ==> 關(guān)聯(lián)廣告
      • 協(xié)同過濾召回 ==> top-N cate/brand ==> 關(guān)聯(lián)對應(yīng)的廣告完成召回

    • 在線處理業(yè)務(wù)流

      • 數(shù)據(jù)處理部分：

        • 實時行為日志 ==> 實時特征 ==> 緩存
        • 實時行為日志 ==> 實時商品類別/品牌 ==> 實時廣告召回集 ==> 緩存

      • 推薦任務(wù)部分：

        • CTR點擊率預(yù)測模型 + 廣告/用戶特征(緩存) + 對應(yīng)的召回集(緩存) ==> 點擊率排序 ==> top-N 廣告推薦結(jié)果

  1. 涉及技術(shù)：Flume、Kafka、Spark-streming\HDFS、Spark SQL、Spark ML、Redis

    • Flume：日志數(shù)據(jù)收集
    • Kafka：實時日志數(shù)據(jù)處理隊列
    • HDFS：存儲數(shù)據(jù)
    • Spark SQL：離線處理
    • Spark ML：模型訓(xùn)練
    • Redis：緩存

1.4 點擊率預(yù)測(CTR--Click-Through-Rate)概念

  • 電商廣告推薦通常使用廣告點擊率(CTR--Click-Through-Rate)預(yù)測來實現(xiàn)

點擊率預(yù)測 VS 推薦算法

點擊率預(yù)測需要給出精準(zhǔn)的點擊概率，比如廣告A點擊率0.5%、廣告B的點擊率0.12%等；而推薦算法很多時候只需要得出一個最優(yōu)的次序A>B>C即可。

點擊率預(yù)測使用的算法通常是如邏輯回歸(Logic Regression)這樣的機器學(xué)習(xí)算法，而推薦算法則是一些基于協(xié)同過濾推薦、基于內(nèi)容的推薦等思想實現(xiàn)的算法

點擊率 VS 轉(zhuǎn)化率

點擊率預(yù)測是對每次廣告的點擊情況做出預(yù)測，可以判定這次為點擊或不點擊，也可以給出點擊或不點擊的概率

轉(zhuǎn)化率指的是從狀態(tài)A進入到狀態(tài)B的概率，電商的轉(zhuǎn)化率通常是指到達網(wǎng)站后，進而有成交記錄的用戶比率，如用戶成交量/用戶訪問量

搜索和非搜索廣告點擊率預(yù)測的區(qū)別

搜索中有很強的搜索信號-“查詢詞(Query)”，查詢詞和廣告內(nèi)容的匹配程度很大程度影響了點擊概率，搜索廣告的點擊率普遍較高

非搜索廣告（例如展示廣告，信息流廣告）的點擊率的計算很多就來源于用戶的興趣和廣告自身的特征，以及上下文環(huán)境。通常好位置能達到百分之幾的點擊率。對于很多底部的廣告，點擊率非常低，常常是千分之幾，甚至更低

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容