將數據存儲在Amazon S3中可帶來很多好處，包括規模、可靠性、成本效率等方面。最重要的是，你可以利用Amazon EMR中的Apache Spark，Hive和Presto之類的開源工具來處理和分析數據。 儘管這些工具功能強大，但是在處理需要進行增量數據處理以及記錄級別插入，更新和刪除場景時，仍然非常具有挑戰。

與客戶交談時，我們發現有些場景需要處理對單條記錄的增量更新，例如：

• 遵守數據隱私法規，在該法規中，用戶選擇忘記或更改應用程序對數據使用方式的協議。
• 使用流數據，當你必須要處理特定的數據插入和更新事件時。
• 實現變更數據捕獲（CDC）架構來跟蹤和提取企業數據倉庫或運營數據存儲中的數據庫變更日誌。
• 恢復遲到的數據，或分析特定時間點的數據。

從今天開始，EMR 5.28.0版包含Apache Hudi（孵化中），因此你不再需要構建自定義解決方案來執行記錄級別的插入，更新和刪除操作。Hudi是Uber於2016年開始開發，以解決攝取和ETL管道效率低下的問題。最近幾個月，EMR團隊與Apache Hudi社區緊密合作，提供了一些補丁，包括將Hudi更新為Spark 2.4.4，支持Spark Avro，增加了對AWS Glue Data Catalog的支持，以及多個缺陷修復。

使用Hudi，即可以在S3上執行記錄級別的插入，更新和刪除，從而使你能夠遵守數據隱私法律、消費實時流、捕獲更新的數據、恢復遲到的數據和以開放的、供應商無關的格式跟蹤歷史記錄和回滾。 創建數據集和表，然後Hudi管理底層數據格式。Hudi使用Apache Parquet和Apache Avro進行數據存儲，並內置集成Spark，Hive和Presto，使你能夠使用與現在所使用的相同工具來查詢Hudi數據集，並且幾乎實時地訪問新數據。

啟動EMR群集時，只要選擇以下組件之一（Hive，Spark，Presto），就可以自動安裝和配置Hudi的庫和工具。你可以使用Spark創建新的Hudi數據集，以及插入，更新和刪除數據。每個Hudi數據集都會在集群的已配置元存儲庫（包括AWS Glue Data Catalog）中進行註冊，並显示為可以通過Spark，Hive和Presto查詢的表。

Hudi支持兩種存儲類型，這些存儲類型定義了如何寫入，索引和從S3讀取數據：

• 寫時複製（Copy On Write）– 數據以列格式（Parquet）存儲，並且在寫入時更新數據數據會創建新版本文件。此存儲類型最適合用於讀取繁重的工作負載，因為數據集的最新版本在高效的列式文件中始終可用。

• 讀時合併（Merge On Read）– 將組合列（Parquet）格式和基於行（Avro）格式來存儲數據； 更新記錄至基於行的增量文件中，並在以後進行壓縮，以創建列式文件的新版本。 此存儲類型最適合於繁重的寫工作負載，因為新提交（commit）會以增量文件格式快速寫入，但是要讀取數據集，則需要將壓縮的列文件與增量文件合併。

下面讓我們快速預覽下如何在EMR集群中設置和使用Hudi數據集。

結合Apache Hudi與Amazon EMR

從EMR控制台開始創建集群。在高級選項中，選擇EMR版本5.28.0（第一個包括Hudi的版本）和以下應用程序：Spark，Hive和Tez。在硬件選項中，添加了3個任務節點，以確保有足夠的能力運行Spark和Hive。

群集就緒后，使用在安全性選項中選擇的密鑰對，通過SSH進入主節點並訪問Spark Shell。 使用以下命令來啟動Spark Shell以將其與Hudi一起使用：

$ spark-shell --conf "spark.serializer=org.apache.spark.serializer.KryoSerializer"
              --conf "spark.sql.hive.convertMetastoreParquet=false"
              --jars /usr/lib/hudi/hudi-spark-bundle.jar,/usr/lib/spark/external/lib/spark-avro.jar

使用以下Scala代碼將一些示例ELB日誌導入寫時複製存儲類型的Hudi數據集中：

import org.apache.spark.sql.SaveMode
import org.apache.spark.sql.functions._
import org.apache.hudi.DataSourceWriteOptions
import org.apache.hudi.config.HoodieWriteConfig
import org.apache.hudi.hive.MultiPartKeysValueExtractor

//Set up various input values as variables
val inputDataPath = "s3://athena-examples-us-west-2/elb/parquet/year=2015/month=1/day=1/"
val hudiTableName = "elb_logs_hudi_cow"
val hudiTablePath = "s3://MY-BUCKET/PATH/" + hudiTableName

// Set up our Hudi Data Source Options
val hudiOptions = Map[String,String](
    DataSourceWriteOptions.RECORDKEY_FIELD_OPT_KEY -> "request_ip",
    DataSourceWriteOptions.PARTITIONPATH_FIELD_OPT_KEY -> "request_verb", 
    HoodieWriteConfig.TABLE_NAME -> hudiTableName, 
    DataSourceWriteOptions.OPERATION_OPT_KEY ->
        DataSourceWriteOptions.INSERT_OPERATION_OPT_VAL, 
    DataSourceWriteOptions.PRECOMBINE_FIELD_OPT_KEY -> "request_timestamp", 
    DataSourceWriteOptions.HIVE_SYNC_ENABLED_OPT_KEY -> "true", 
    DataSourceWriteOptions.HIVE_TABLE_OPT_KEY -> hudiTableName, 
    DataSourceWriteOptions.HIVE_PARTITION_FIELDS_OPT_KEY -> "request_verb", 
    DataSourceWriteOptions.HIVE_ASSUME_DATE_PARTITION_OPT_KEY -> "false", 
    DataSourceWriteOptions.HIVE_PARTITION_EXTRACTOR_CLASS_OPT_KEY ->
        classOf[MultiPartKeysValueExtractor].getName)

// Read data from S3 and create a DataFrame with Partition and Record Key
val inputDF = spark.read.format("parquet").load(inputDataPath)

// Write data into the Hudi dataset
inputDF.write
       .format("org.apache.hudi")
       .options(hudiOptions)
       .mode(SaveMode.Overwrite)
       .save(hudiTablePath)

在Spark Shell中，現在就可以計算Hudi數據集中的記錄：

scala> inputDF2.count()
res1: Long = 10491958

在選項（options）中，使用了與為集群中的Hive Metastore集成，以便在默認數據庫（default）中創建表。 通過這種方式，我可以使用Hive查詢Hudi數據集中的數據：

hive> use default;
hive> select count(*) from elb_logs_hudi_cow;
...
OK
10491958

現在可以更新或刪除數據集中的單條記錄。 在Spark Shell中，設置了一些用來查詢更新記錄的變量，並準備用來選擇要更改的列的值的SQL語句：

val requestIpToUpdate = "243.80.62.181"
val sqlStatement = s"SELECT elb_name FROM elb_logs_hudi_cow WHERE request_ip = '$requestIpToUpdate'"

執行SQL語句以查看列的當前值：

scala> spark.sql(sqlStatement).show()
+------------+                                                                  
|    elb_name|
+------------+
|elb_demo_003|
+------------+

然後，選擇並更新記錄：

// Create a DataFrame with a single record and update column value
val updateDF = inputDF.filter(col("request_ip") === requestIpToUpdate)
                      .withColumn("elb_name", lit("elb_demo_001"))

現在用一種類似於創建Hudi數據集的語法來更新它。 但是這次寫入的DataFrame僅包含一條記錄：

// Write the DataFrame as an update to existing Hudi dataset
updateDF.write
        .format("org.apache.hudi")
        .options(hudiOptions)
        .option(DataSourceWriteOptions.OPERATION_OPT_KEY,
                DataSourceWriteOptions.UPSERT_OPERATION_OPT_VAL)
        .mode(SaveMode.Append)
        .save(hudiTablePath)

在Spark Shell中，檢查更新的結果：

scala> spark.sql(sqlStatement).show()
+------------+                                                                  
|    elb_name|
+------------+
|elb_demo_001|
+------------+

現在想刪除相同的記錄。要刪除它，可在寫選項中傳入了EmptyHoodieRecordPayload有效負載：

// Write the DataFrame with an EmptyHoodieRecordPayload for deleting a record
updateDF.write
        .format("org.apache.hudi")
        .options(hudiOptions)
        .option(DataSourceWriteOptions.OPERATION_OPT_KEY,
                DataSourceWriteOptions.UPSERT_OPERATION_OPT_VAL)
        .option(DataSourceWriteOptions.PAYLOAD_CLASS_OPT_KEY,
                "org.apache.hudi.EmptyHoodieRecordPayload")
        .mode(SaveMode.Append)
        .save(hudiTablePath)

在Spark Shell中，可以看到該記錄不再可用：

scala> spark.sql(sqlStatement).show()
+--------+                                                                      
|elb_name|
+--------+
+--------+

Hudi是如何管理所有的更新和刪除？ 我們可以通過Hudi命令行界面（CLI）連接到數據集，便可以看到這些更改被解釋為提交（commits）：

可以看到，此數據集是寫時複製數據集，這意味着每次對記錄進行更新時，包含該記錄的文件將被重寫以包含更新后的值。 你可以查看每次提交（commit）寫入了多少記錄。表格的底行描述了數據集的初始創建，上方是單條記錄更新，頂部是單條記錄刪除。

使用Hudi，你可以回滾到每個提交。 例如，可以使用以下方法回滾刪除操作：

hudi:elb_logs_hudi_cow->commit rollback --commit 20191104121031

在Spark Shell中，記錄現在回退到更新之後的位置：

scala> spark.sql(sqlStatement).show()
+------------+                                                                  
|    elb_name|
+------------+
|elb_demo_001|
+------------+

寫入時複製是默認存儲類型。 通過將其添加到我們的hudiOptions中，我們可以重複上述步驟來創建和更新讀時合併數據集類型：

DataSourceWriteOptions.STORAGE_TYPE_OPT_KEY -> "MERGE_ON_READ"

如果更新讀時合併數據集並使用Hudi CLI查看提交（commit）時，則可以看到讀時合併與寫時複製相比有何不同。使用讀時合併，你僅寫入更新的行，而不像寫時複製一樣寫入整個文件。這就是為什麼讀時合併對於需要更多寫入或使用較少讀取次數更新或刪除繁重工作負載的用例很有幫助的原因。增量提交作為Avro記錄（基於行的存儲）寫入磁盤，而壓縮數據作為Parquet文件（列存儲）寫入。為避免創建過多的增量文件，Hudi會自動壓縮數據集，以便使得讀取盡可能地高效。

創建讀時合併數據集時，將創建兩個Hive表：

• 第一個表的名稱與數據集的名稱相同。
• 第二個表的名稱後面附加了字符_rt； _rt後綴表示實時。

查詢時，第一個表返回已壓縮的數據，並不會显示最新的增量提交。使用此表可提供最佳性能，但會忽略最新數據。查詢實時表會將壓縮的數據與讀取時的增量提交合併，因此該數據集稱為讀時合併。這將導致可以使用最新數據，但會導致性能開銷，並且性能不如查詢壓縮數據。這樣，數據工程師和分析人員可以靈活地在性能和數據新鮮度之間進行選擇。

已可用

EMR 5.28.0的所有地區現在都可以使用此新功能。將Hudi與EMR結合使用無需額外費用。你可以在EMR文檔中了解更多有關Hudi的信息。 這個新工具可以簡化你在S3中處理，更新和刪除數據的方式。也讓我們知道你打算將其用於哪些場景！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

嘉賓：劉雨丹 騰訊 高級研究員

整理：Jane Zhang

來源：DataFunTalk

出品：DataFun

注：歡迎關注DataFunTalk同名公眾號，收看第一手原創技術文章。

導讀：本次分享是微信看一看團隊在 KDD2019 上發表的一篇論文。長尾問題是推薦系統中的經典問題，但現今流行的點擊率預估方法無法從根本上解決這個問題。文章在 look-alike 方法基礎上，針對微信看一看的應用場景設計了一套實時 look-alike 框架，在解決長尾問題的同時也滿足了資訊推薦的高時效性要求。

▌背景

微信大家可能都用過，微信中的“看一看”是 feed 推薦流的形式，涵蓋了騰訊整個生態鏈的內容分發平台，包括騰訊新聞、公眾號文章、騰訊視頻等。每天總分發量在千萬級以上，面對如此大的分發量，要滿足不同興趣偏好的用戶需求，使用傳統的方法時遇到了一些問題。我們針對發現的問題做了優化和改進，接下來分享下我們優化的過程。

▌未緩解的馬太效應

馬太效應，簡單解釋，在內容的生態系統中，自然分髮狀態會造成一種現象：頭部10%的內容佔據了系統90%的流量、曝光量or點擊量，剩下90%的內容，集中在長尾的10%里。這對於內容的生產方、內容系統的生態和使用系統的用戶來說，都是不健康的狀態。造成這種現象的原因，是因為系統分發能力不夠強，無法處理信息過載的現象，推薦系統設計的初衷就是為了解決馬太效應問題。

回顧推薦系統的發展，從最開始的規則匹配 -> 協同過濾 -> 線性模型 -> deep learning，逐步緩解了馬太效應現象，但沒有完全解決。

造成這個現象的原因是傳統模型、CTR 預估和 deep model，都對部分特徵有依賴，沒有把特徵完全發掘出來，導致模型推薦結果是趨熱的，使生態系統內優質長尾內容投放依然困難。因為 CTR model 最終趨向於行為特徵，或者后驗結果較好的數據，對於優質長尾內容，如小眾興趣的音樂、電影、深度報道的新聞專題等，獲得的相應曝光依舊困難，處於馬太效應 long tail 90%的部分，這會影響推薦系統的生態，導致推薦系統內容越來越窄。

▌為什麼無法準確投放長尾？

怎樣解決這個問題？這個問題歸根結底是對內容的建模不夠完整。我們嘗試分析下問題出在哪：

先看下推薦系統建模流程。首先得到原始樣本，這是業務下的訓練數據，形式是三元組：userid，itemid 和 label。如果是 timeline 的樣本，那就是點擊或者不點擊。原始樣本中，一條樣本可以完整表示一個用戶在某個時間點對一個 item 產生了一次行為，把這個三元組當作信息的最完整形式。對於這個完整形式，直接建模很簡單，如傳統的 item CF，或者協同過濾。協同過濾是最初級的方法，直接對 uid，itemid，label 做擬合，因為可以完全利用初始樣本的信息，擬合的準確性非常好。弱點也很明顯，對原始樣本中沒有包含的 userid 或者 itemid，沒有泛化推理能力，後續新曝光的 user 和 item 是無法處理的。這個問題，就是我們要做的第二步驟，對原始樣本做抽象。既然無法獲取所有的 userid 和 itemid，那就要對 user 或者 item 做一層抽象，如 user 抽象成基礎畫像：年齡、性別或所處地域；item 抽象成語義特徵：topic、tag 等；item 歷史行為特徵，簡單做統計：過去一段時間的點擊率、曝光率、曝光次數。最後基於泛化過的特徵做擬合，得到最終模型。

問題出在哪？做原始特徵抽象，抽象意味着發生了信息損失，這部分信息損失導致模型擬合時走向了比較偏的道路。舉個簡單的例子：同一個 item，有相同的 topic tag，歷史點擊率和歷史曝光次數和點擊次數也相同，可以說這兩個 item 是相同的嗎？顯然有可能是不同的。使用統計特徵無法完整表達，同樣的 item 點擊都是0.5，PV 都是1000 or 2000。有些 item 被這群用戶看過，有些 item 被那群用戶看過。儘管語義特徵和行為特徵都相同，但兩群 user 不同，Item 的受眾也不同。這裏說的抽象的方式，是不完整的 item 行為建模，也是對 item 歷史行為不完整的刻畫，這就導致了整個 model，對 item 后驗數據十分依賴，導致推薦結果趨向於 CTR 表現好或者 PV 表現好的 item。最終后驗數據表現好的數據又會更進一步被模型推薦且曝光，這樣會造成惡性循環：一方面，加劇了頭部效應的影響，使模型陷入局部最優；另一方面，整個推薦系統邊界效應收窄，用戶趨向於看之前表現好的數據，很少看到能拓寬推薦系統邊界或者用戶視野的長尾數據。

▌Look-alike 模型

問題就是這樣產生的， 可以思考一下，問題的本質是什麼？就是因為模型無法對 item 行為完整建模，這一步信息損失太大，怎麼解決這個問題呢？我們首先想到了一種方案：look-alike。

這是廣告領域的經典方案，這類模型的方法也很簡單，首先可以有一個候選集合的 item，我們要推這部分 item，怎麼推呢？第一個步驟：找到歷史上已知的、廣告主提供的對 item 表達過興趣的用戶，這部分用戶稱為種子用戶。然後使用用戶相似度法方法，找到和種子用戶最相似的目標人群，稱為目標用戶，把這部分 item 直接推給目標用戶。這個方法在廣告系統中，是用來做定向投放的，效果很好。為什麼呢？我們來看下模型的整體思路。

把相關的 item 找到對它發生過歷史行為的種子用戶，直接用種子用戶的特徵，作為模型的輸入，這是正樣本；從全局用戶中負採樣一部分用戶作為負樣本。用歷史行為的用戶的特徵來學習 item 的歷史行為，相當於把不同用戶看過的 item 區分開，其實是對 item 的歷史行為特徵的完整建模。之前提到，行為樣本是信息量最大的樣本，它們沒有經過抽象，如果能完整的用受眾用戶的行為來計算 item 的特徵，可以說是最完整的 item 歷史特徵的建模。

Look-alike 在廣告領域的應用已經很完善，也有很多方式。可以把 look-alike 相關的研究分成兩個方向：第一種是基於相似度的 look-alike，這種 look-alike 比較簡單，大體思路是把所有用戶做 user embedding，映射到低維的向量中，對它做基於 k-means 或者局部敏感 hash 做聚類，根據當前用戶屬於哪個聚類，把這個種子用戶的類感興趣的內容推給目標用戶。這種方法的特點：性能強。因為簡單，只需要找簇中心，或者向量相似度的計算，因為簡單、性能好，模型準確性低。

第二種是和第一種相反的，基於回歸。包括 LR，或者樹模型，或者 DNN or deep model 的方法，主要思路是直接建模種子用戶的特徵。把種子用戶當做模型的正樣本， 針對每個 item 訓練一個回歸模型，做二分類，得出種子用戶的特徵規律。這種方法的優點是：準確性高，因為會針對每個 item 建模。缺點也明顯：訓練開銷大，針對每個 item 都要單獨訓練一個模型。對於廣告來說，可以接受，因為廣告的候選集沒有那麼大，更新頻率也沒那麼高。

但是對於我們的推薦場景，有一些問題：1. 對內容時效性要求高，如推薦的新聞專題，必須在5分鐘或10分鐘內要觸達用戶；2. 候選集更新頻率高，我們每天的候選集上千萬，每分鐘、每一秒都有新內容，如果新內容無法進入推薦池，會影響推薦效果。

▌核心需求

在我們的場景下，如果還用廣告領域的經典的 look-alike，是無法解決的。如果要對每個候選集建模，採用 regression-base 的方法，如每分鐘都要對新加進來的候選集做建模，包括積累種子用戶、做負採樣、訓練，等模型收斂后離線預測 target user 的相似分，這對於線上的時效性是不能接受的。

對於 similarity base 的方法，它的問題是計算過於簡單，如果直接和 CTR 模型 PK，核心指標會下降，得出來的結論是：傳統的 look-alike 不能直接照搬到我們的系統中。

針對我們的需求，我們整理出來了應該滿足的3點核心需求：

1. 實時。新 item 分發不需要重新訓練模型，要能實時完成種子用戶的擴展；

2. 高效。因為線上加到 rank 模型 CTR 的後面， 要保持模型核心指標 CTR 的前提下，再去加強長尾內容分發，這樣模型才有意義。要學習準確性和多樣性的用戶表達方式。

3. 快速。Look-alike 模型要部署到線上，實時預測種子用戶和目標用戶群體的相似度，要滿足線上實時計算的耗時性能要求，也要精簡模型預測的計算次數。

▌RALM：Real-time Attention based Look-alike Model

基於這三個核心需求，我們提出了一個新的方法，全稱是 real-time attention based look-alike model，簡稱 RALM。我先簡單講下 RALM 核心的三個點。

1. 核心點

① 模型可總結為 user-users 的 model。回想下經典的 CTR 預估模型，是 user2item 的 point-wise 的處理流程建模。User、item、label，我們做的最大的變化，是借鑒了 look-alike 的思想，把 item 替換成種子用戶。用種子用戶的用戶特徵，代替 item 的行為特徵。所以模型從 user2item 的 model，變成 user2user 的 model。圖中右側是 target user，左側是 seeds。

② 完善的 seeds representation。用種子用戶代替 item 行為特徵。這樣面臨的問題是：怎樣更好地表達一個人群。這個 seeds representation，是我們研究中的核心步驟，要得到一個高效、自適應更新的種子用戶的表達方式。

③ real-time。最終目標是部署在線上，實時預測種子用戶群體相似度，需要是能夠實現 real-time 的框架。

上述是模型表達的思路。I 是一個 item，把 item 用 seeds 的 embedding 的集合來表示，seeds embedding，是組成這個種子用戶的每個用戶的 embedding 的函數。學習了 seeds representation，就是這個函數 f。

1. 整體結構

接下來看下離線訓練部分，這是離線訓練的整體結構。

模型離線訓練分成兩個階段：右側 user representation learning， 左側第二階段是 look alike learning。user representation learning 模型結構，最後的目標是通過一個用戶在不同領域的行為，學習到用戶在所有領域的多樣性且兼顧準確性的用戶興趣的高階畫像。這個畫像在這個位置是低維特徵，向量特徵通過 user presentation learning 的目標學到了所有用戶的 embedding 之後，第二階段是 look alike learning。Look alike learning 模型，是一個 user to user 的 model，右側是目標用戶的特徵輸入，左側是種子用戶人群的 embedding 輸入，左邊種子用戶是一群用戶的 embedding 堆疊到一起，輸入其實是一個矩陣。這兩邊的輸入來源都是第一階段 representation learning 輸出的 embedding。Look alike 的目標是學習目標用戶和候選 item 種子用戶的相似度，最上面是學習兩次相似分的，最後完成種子用戶的擴展。

▌User Representation Learning

按順序來分析下，第一階段，是用戶的表示學習，user representation learning。

這個模型大家看着會比較眼熟，它是用 Youtube 的 representation model 中演化過來的。Youbute 的基礎模型很簡單，下面是用戶在不同領域的行為，下面的基礎特徵可能會有離散值，也可能是連續值。如果是離散值，可以通過 embedding lookup，再過一個 pooling，再和所有領域的特徵做 merge，上面過一個全連接，最後輸出 embedding。右側是感興趣的 item，也會做一些 embedding lookup，整個做 sce loss，或者是多分類。要預測的是：用戶在點擊了這麼多 item 之後，下一個要點擊的 item，最後要預測的就是表達用戶興趣的 embedding。這層 merge layer，最初 Youtube 的版本是用一個 concat。可以看到最初版模型在訓練時遇到了一個問題，最下層是用到了用戶很多個域 ( 每個 field 稱為一個域，可能是每個用戶在每個分佈下的行為，如電商購物下行為，或者是公眾號閱讀的行為 )。

訓練時看到一個現象，有些域的行為學的非常強，參數來看學的非常充分，某些 field 參數分佈不大，最後的權重值較小，對最終預估的分數沒有影響。這裡有兩個名詞：強關聯和弱關聯。最終預估結果關係比較大的 field、參數學習較強的，稱為強關聯特徵域；相反，學的不充分的、對最終結果影響小的，稱為弱關聯特徵域。對於強關聯和弱關聯，如果看到參數分佈是這樣的，是不是就表明弱關聯特徵不重要呢？並不是。舉例來說，representation learning 如果訓練目標是在“看一看”中的閱讀行為，對於某些經常使用微信公眾號、或者閱讀的用戶來說，他們在公眾號平台的閱讀歷史就是非常強的關聯特徵，能夠決定再看一看中的興趣。對於這些特徵來說，這些特徵是很強的，對於其他的如在電商中的購物或者是在搜索中的 query，這些是比較弱的，對看一看的影響很有限。再思考另一種 case，比如，看一看通過某種形式，吸引了很多新用戶。新用戶進來之後，沒有在公眾號平台的閱讀歷史，但是他們在購物或者搜索中有歷史行為，此時這些歷史行為會影響他下一次閱讀的文章，或者感興趣的 item。這些特徵對這些用戶來說是非常重要的。但目前，顯然這些用戶是沒有學到這些變化的。

排查了下模型訓練的過程，可以把結果集中在這一點上，就是這個 merge layer，其實是負責把用戶不同域的特徵 merge 到一起。Merge layer，可以看到右側的圖，原始的 deep model 用的是左側的實現方法，直接用 concat。Concat 的優點是，可以學到所有 field 的參數，缺點是，無法根據輸入的不同分佈，來調整權重值。也就是說，如果80%的用戶的閱讀歷史都是看一看的種子用戶，閱讀歷史都是很豐富的，就很有可能對所有用戶都把這個特徵學的很強。如果是少量用戶，就學不到了，少量用戶關注對其它特徵的啟發作用，concat layer 是學不到的。因為它對於大部分用戶來說，已經把參數學的非常重了，小部分用戶不足以對它產生影響。所以需要一個機制，針對不同用戶的特徵域的輸入動態調整 merge layer 的方式，我們想到的最好的辦法是 attention。Attention 是最近在 NLP 中非常火的，很多模型都會用到。為什麼要用 attetnion？

右下角的結構，就是 attention。我們用到的 attention 是把用戶的輸入的所有的域當做 attention 的 query，key 和 value 都是自身 field 的本身。這是一個典型的 self-attetnion，我們最後要做的是，讓模型根據用戶自己的輸入領域的情況，動態調整不同領域的融合方式，相對於之前的 concat 的方式來說，concat 其實是把所有領域的 field 強行放在同一個向量空間中來學習，自然會有學習不充分的情況。Self-attenion merge 是讓不同的域在自己的向量空間中學習充分，再通過不同的權重組合在一起。其實是相當於讓用戶能有屬於自己的表達，而不是被歷史豐富的用戶帶着走。這是一個優化，可以明顯改善強弱特徵、訓練不均衡的問題。

可以看一下這是我之前訓練的時候在某個特徵域用 tensorboard 打出來的參數分佈的情況，可以看到 attention merge layer 前後，訓練參數有很大變化，之前這些參數基本上都是0，之後會激活出一些值，這個是最後 user presentat learning 的值：precession、recall、auc。也可以看到模型加完 attention 之後，在 auc 和 loss 上都有所優化。

經過 user representation learning 之後，我們現在擁有了所有用戶的兼顧多樣性和準確性的 embedding 表達。接下來要做的是怎麼用 embedding 來表達種子用戶人群？

▌Look-alike learning

Look-alike 要做的第一步就是如何表達 seeds user。

一個種子用戶應該包含什麼信息，這裏我們做兩點假設：

1. 每個用戶都有自己的興趣，但對整個群體的人群信息存在不同的貢獻度，我們稱為群體的共性信息：global info。共性信息和目標用戶無關，只和用戶群體自身有關。

2. 種子用戶群體的個性信息。種子群體中一定存在一小部分用戶和 target 用戶興趣相似，這時，當 target 人群變化時，信息會變化，稱為 local info。

種子用戶的相對表達=個性信息+共性信息。怎樣學習 local info 和 global info 呢？我們想到的是用不同的 attention 機制，學習出兩個 embedding：local & global embedding，分別表示這兩種信息。對於 local embedding，是右上角的圖，稱為 local attention unit，這個 attention，是一個乘法開始，它的公式是把種子用戶的矩陣乘以 w，再乘以 target user 的 embedding，再做一層 softmax，再乘以種子用戶自己，這是一個典型的乘法 attention。它的作用是提取種子用戶群體中和 target user 相關的部分。捕獲種子用戶的 local info。

第二部分是 global info，用 global attention，只和 user 相關，和 attention merge 的方法類似，也是一個 self-attention。作用是把種子用戶乘以矩陣轉換，再乘以種子用戶自己，所做的就是捕捉用戶群體自身內部的興趣分佈。得到的這兩種 local & global embedding 之後，進行加權和，這就是種子用戶群體的全部信息。另一個問題來了，採用兩種 attention union 來捕獲信息，這意味着要計算很多次矩陣乘法，對線上開銷很大。兩個 embedding 需要多少次計算？這裡有個表達公式，這個 h 是 embedding 的維度，K 是種子用戶用戶的數量，總的計算次數 = h * h * K * 2。對於線上耗時，一次預測超過 1000ms，無法接受。

優化耗時，第一個方法是減少種子用戶的數量，這樣會影響種子用戶的表達完整性；另一種是我們線上採取的方式，使用聚類。找到種子用戶內部比較相似的，把它們聚在一起。這種方法：1. 減少 key 的數量，2. 保持種子用戶的全部信息。聚類的方式比較簡單，用的是 k-means。

簡單看下這個模型，右側是 target user embedding，經過全連接，左邊是 series user embedding 矩陣，兩邊都經過 embedding 之後，首先對種子用戶的 embedding 做聚類，得到 k 個聚類中心，把種子用戶的向量根據 k 個聚類中心做聚和，在類似中心內部做類似於 average 的聚和，然後得到 k 個向量，在這 k 個向量之上，一邊做 global embedding，另一邊和 target user 做 local embedding。有了這兩個 embedding 之後，通過加權和的方式，做 cosine，再去擬合 user 到 item 的 label。這裏的 label 用的是點擊。

細節：

聚類的過程需要迭代，比較耗時，並非每個 batch 都去更新聚類中心，而是採取迭代更新的方式，比如把1000個 batch 一輪，訓練完1000個 batch 之後，這1000個 batch 中，不更新聚類中心；到了第二輪，根據全連接參數的變化，再去更新種子用戶的聚類中心，每通過一輪更新一次聚類中心，保證和核心參數是同步的。這樣既保證了訓練的效率，也保證了訓練的準確性。聚類的優化，使線上的計算次數減小到了 k/K 中，之前 K 是萬級別的數量，現在 k 是百級別的數量，耗時也下降了很多。

根據實驗結果，確定不同聚類中心數 k 帶來的影響，選擇了合適的 k。實驗中，k=20，線上 k 是100左右。模型訓練的 label 優化方式，是一個多分類。對不同的種子用戶人群選擇最相似的用戶。多分類的優化方式和 deep model 相似，採用 negative sampling 的方式。

▌系統架構

線上需要實現實時預測，系統實際部署到線上，需要整套系統架構。簡單介紹下 RALM 的配套體系。

大體過程，分成三個模塊，從最底下的離線訓練，到在線異步處理，到在線服務，接下來分別講一下。

1. 離線訓練

離線訓練，就是兩個階段的訓練，representation learning，look alike learning，需要一提的是，進行完 look alike learning 之後，可以把 user 經過全連接層的 user 表達緩存起來。全量用戶，有10多億，可以 catch 到 KV 中。可以提供給在線服務做緩存，線上不用做實時全量傳播。

2.在線異步處理

離線訓練結束后，是在線異步處理，主要作用是某些可以離線且和線上請求無關的計算，可以先計算完，如更新種子用戶。每個 item 候選集都會對應一個種子用戶列表，更新種子用戶列表，可以每一分鐘更新一次，這和訪問用戶無關，只和候選集的 item 有關。可以實時拉取用戶的點擊日誌，更新點擊某個候選集的種子列表。

① 可以把 global embedding 預計算 ( gl 只和種子用戶有關，是 self-attenion，可在線做異步處理，如每隔一分鐘算一次 ）。

② 計算 k-means 聚類中心，也是只和種子用戶有關，可以提前計算好，如推到推薦系統內存中。

③ 所有的東西都是定時更新，不需要線上實時計算。

3.在線服務

線上把聚類中心、global embedding 和所有用戶的 embedding 都已緩存好，只需要拉取 user embedding，和候選集的 global embedding 和聚類中心。線上只需要計算 local embedding，是 target user 到種子用戶的 attention，這需要根據線上請求的 urn 來實時計算。再計算一次 cosine，就可以得到相似度，這個計算量很小。

▌實驗結果

算出 look alike 相似度之後，相似度的分數，可直接給到排序服務，做曝光依據。這是當時寫論文之前做的 ABtest，對比的是用戶畫像匹配推送的策略，上線之後，在擴大曝光規模的前提下，CTR 基本取向穩定，而且有微小提升，多樣性也提升了很多，這都是相對提升。

▌一些細節和思考

特徵：

為什麼要用第一階段的 user representation learning 得到用戶的高階畫像？高階畫像的作用：包含了用戶在某個領域的全部信息，信息量很大，結合 look alike learning 中的行為，需要去學習用戶群體的特徵。不用高階特徵，怎樣學習用戶群體？比較簡單的方法是通過統計的方式：平均年齡分佈和平均閱讀傾向。這些都是基於離散的統計，信息損失很大。如果有了高階的特徵，高階特徵也是從低階特徵，如基礎畫像、年月分佈，這些都是可以學到高階特徵中。如果能夠直接輸出所有領域的高階特徵，之後的利用、或者作為召回、作為 CTR 特徵，都很方便。

模型調優：

① 防止模型過擬合。look alike 的結構很簡單，這樣做的原因: 直接使用用戶的高階特徵，使用了用戶特徵，如果模型不做處理，容易對高階特徵過擬合。採取了2種方式：

1. 盡量保證 look alike learning 結構簡單；

2. 全連接層做 dropout。

② 採用 stacking model 的形式。看一看閱讀、電商、新聞、音樂領域都做一次 user representation learning，這些特徵用 stacking 的模式都放到 look alike model 中學習，這就是不同特徵根據不同目標來訓練的，更加減少了在同一個模型中過擬合的防線。

冷啟動曝光：

Look alike model 中用了種子用戶的表達，如果線上有新的 item，怎樣做曝光？

1. 初始投放策略。使用基於 user item 的語義特徵做線性模型的預測，當做冷啟動 item 的初始投放。這個初始投放不需要積累很多種子用戶，大概到百級別的種子用戶就可以切到 look alike 邏輯了。

2. Look alike 出來的相似度分數，怎麼做曝光的依據？如果直接用相似度分數，需要確定曝光閾值，如對於某個 item，高於多少分才曝光。我們使用的是線上試探曝光機制：最初給1000條流量，做曝光，這次曝光后，收集在用戶側的打分，取打分的分佈統計，根據不同業務的要求，曝光 top 5% 或者 top10%， 來砍一個閾值分數，最後取曝光閾值。

本次分享就到這裏，謝謝大家。

▌Q & A

Q：這個算法有沒有在召迴環節用，曝光該如何理解？

A：目前的策略有兩種方式：

1. 直接採用召回的方式，定一個曝光閾值，直接確定是否曝光；

2. 把相似分數給到下游的 CTR model 作為參考。

Q：能否將兩階段學習合併成一個端到端學習？

A：End-to-End 方式存在兩個問題：

1. 整個模型參數量很大，結構比較複雜，採用 End-to-End 方式不一定能學習到或者學習的很充分；

2. 剛剛講到的 stacking 方式，我們最後需要的是盡可能全的表達用戶的方式，所以右側的 user representation learning 並不是從單一業務領域得出的結果，有可能是在多個領域得到的結果，比如在看一看訓練一版 user representation learning，然後用社交或者電商上的行為，再做一版用戶的表示，最後用 stacking 的方式把它們拼接起來，作為特徵輸入，這樣達到的效果會更好。

Q：如果將第一階段用戶表徵學習換成其他通用能學習表徵用戶向量的模型，效果會有什麼影響？

A：我們單獨用 user representation learning 和其它模型做過對比，比如 CTR 中的 user embedding，是針對當前業務比較精準化的表達，所在在泛化性上沒有 user representation learning 效果好。

▌參考資料

Real-time Attention Based Look-alike Model for Recommender System

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

本文整理了我自己在Java開發中常用的jar包以及常用的API記錄。

<!-- https://mvnrepository.com/artifact/org.apache.commons/commons-lang3 -->
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.8</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/commons-io/commons-io -->
        <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
            <version>2.6</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.8</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.17</version>
        </dependency>

common-lang3

簡介

一個現在最為常用的jar包，封裝了許多常用的工具包

依賴：

<!-- https://mvnrepository.com/artifact/org.apache.commons/commons-lang3 -->
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-lang3</artifactId>
    <version>3.4</version>
</dependency>

主要常見的類如下：

• 數組工具類 ArrayUtils
• 日期工具類 DateUtils DateFormatUtils
• 字符串工具類 StringUtils
• 数字工具類 NumberUtils
• 布爾工具類 BooleanUtils
• 反射相關工具類 FieldUtils、MethodUtils、MemberUtils、TypeUtils、ConstructorUtils
• 對象工具類 ObjectUtils
• 序列化工具類 SerializationUtils

API介紹

這裏我只介紹經常使用的幾個工具類及方法，ArrayUtils，StringUtils，NumberUtils，DateUtils，其他的請查看官方API文檔吧

1.ArrayUtils

方法名	說明
add
remove
clone	複製數組
addAll
removeAll	第二個參數傳入需要刪除的下標（可以指定多個下標）
toObject	把數值（int[],double[]）轉為包裝類(Int[],Double[])
indexOf	在數組按順序查找，找到第一個滿足對應的數值的下標
lastIndexOf	在數組按順序查找，找到最後一個滿足對應的數值的下標
contains	數組是否包含某個值
isEmpty	判斷數組是否為空
isNotEmpty	判斷數組是否不為空
reverse	數組反轉
subarray	指定區間截取數組，區間為半開區間，不包含末尾
toArray	接收一個多個對象，把這幾個對象轉為對應類型的數組
toMap	將一個二維數組轉為Map

2.NumberUtils

方法名	說明
min	比較三個數，返回最小值 或比較指定的幾個數，返回最小值
max	比較三個數，返回最大值 或比較指定的幾個數，返回最大值
createInt	從傳入的String中創建對應類型的數值，createDouble,createFloat…
toInt	將指定字符串轉為Int類型，可以選擇指定默認數值，如果字符串為null則返回默認數值，除此之外，還有toDouble,toLong…等轉為不同類型的方法
compare	比較兩個同類型數值的大小
isDigits	判斷字符串是否只包含数字
isParsable	判斷字符串是否可轉換為Long,Int等類型
isNumber	判斷字符串是否為數值（0x,0X開頭等進制數值）

3.DateUtils

方法名	說明
parseDate	將Date對象轉為字符串
isSameDay	判斷兩個Dated對象是否為同一天
isSameDay	判斷兩個Dated對象是否為同一天
addHour	將指定的Date對象加上指定小時，除此之外，還有addMonth,addDay..等

DateFormatUtils正如其名，是用來把時間轉為字符串，這裏就不再多說

4.StringUtils

方法名	說明
join	將指定的數組連接成字符串，並添加指定的分割字符
containOnly	字符串是否只包含某個字符串
substringBefore	截取指定字符串前面的內容
substringAfter	截取指定字符串後面的內容（不包括指定字符串）
substringBetween	截取字符串某區間內容，如substringBetween(“abcde”,”a”,”e”)=”bcd”
difference	比較兩個字符串，返回兩個字符串不同的內容，具體可以看API文檔給出的示例
isBlank	判斷字符串是否為空白，null,””,” “這三個結果都是為true
isEmpty	判斷字符串是否為空(只要不為null，或傳入的String對象的長度不為0即為true)
countMatches	判斷指定的字符串在某個字符串中出現的次數
deleteWhitespace	刪除字符串中的空格
defaultIfBlank	如果字符串為空白，則返回一個指定的默認值(null或某個String)
defaultIfEmpty	如果字符串為空，則返回一個指定的默認值(null或某個String)
capitalize	將指定字符串首字母大寫
abbreviate	將指定字符串的後面三位轉為…
swapCase	將字符串中的字母大小寫反轉,如aBc變為AbC
lowerCase	將字符串的字母全部轉為小寫
upperCase	將字符串的字母全部轉為大寫
left	取字符串左邊幾個字符，如left(“hello”,3)=”hel”，right與此相反
leftPad	字符串的長度不夠，則使用指定字符填充指定字符串，如leftPad(“hel”,5,”z”)=”zzhel”,rightPad方法與此相反
prependIfMissing	指定字符串不以某段字符串開頭，則自動添加開頭，如prependIfMissing(“hello”,”li”)=”lihello”
prependIfMissing	指定字符串不以某段字符串開頭(忽略大小寫)，則自動添加開頭
getCommonPrefix	獲得多個字符串相同的開頭內容，接收參數為多個字符串
removeEnd	刪除字符串中結尾（滿足是以某段內容結尾），如removeEnd(“hello”,”llo”)=”he”
removeEndIgnoreCase	與上面一樣，忽略大小寫
removeStart	與上面的相反
remove	刪除字符串中的指定內容，如remove(“hello”,”l”)=”heo”
removeIgnoreCase	刪除字符串中的指定內容，如remove(“hello”,”l”)=”heo”
strip	清除字符串開頭和末尾指定的字符(第二個參數為null,用來清除字符串開頭和末尾的空格)，如strip(” abcxy”,”xy”)=” abc”,strip(” abcxy”,”yx”)=” abc”
stripStart	清除字符串開頭指定字符
stripEnd	清除字符串末尾指定的字符

common-io

簡介

常用的IO流工具包

<!-- https://mvnrepository.com/artifact/commons-io/commons-io -->
<dependency>
    <groupId>commons-io</groupId>
    <artifactId>commons-io</artifactId>
    <version>2.6</version>
</dependency>

API

我們主要關心的就是Utils後綴的那幾個類即可，可以看到，common-io庫提供了FileUtils,FileSystemUtils,FileNameUtils,FileFilterUtils,IOUtils

FileUtils

• 寫出文件
• 讀取文件
• 創建一個有父級文件夾的文件夾
• 複製文件和文件夾
• 刪除文件和文件夾
• URL轉文件
• 通過過濾器和擴展名來篩選文件和文件夾
• 比較文件內容
• 文件最後修改時間
• 文件校驗

FileSystemUtils

關於文件系統的相關操作，如查看C盤的大小，剩餘大小等操作

IOUtils

字面意思，是封裝了IO流的各種操作的工具類

Log4j

簡介

Log4J 是 Apache 的一個開源項目，通過在項目中使用 Log4J，我們可以控制日誌信息輸出到控制台、文件、GUI 組件、甚至是數據庫中。

我們可以控制每一條日誌的輸出格式，通過定義日誌的輸出級別，可以更靈活的控制日誌的輸出過程，方便項目的調試。

依賴：

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.17</version>
</dependency>

結構

Log4J 主要由 Loggers (日誌記錄器)、Appenders（輸出端）和 Layout（日誌格式化器）組成。

其中Loggers 控制日誌的輸出級別與日誌是否輸出；
Appenders 指定日誌的輸出方式（輸出到控制台、文件等）；
Layout 控制日誌信息的輸出格式。

日誌級別：

級別	說明
OFF	最高日誌級別，關閉左右日誌
FATAL	將會導致應用程序退出的錯誤
ERROR	發生錯誤事件，但仍不影響系統的繼續運行
WARN	警告，即潛在的錯誤情形
INFO	一般和在粗粒度級別上，強調應用程序的運行全程
DEBUG	一般用於細粒度級別上，對調試應用程序非常有幫助
ALL	最低等級，打開所有日誌記錄

我們主要使用這四個：Error>Warn>Info>Debug

使用

我們可以使用兩種方式來運行Log4j，一種是java代碼方式，另外一種則是配置文件方式

例子（Java方式）

public class Log4JTest {
    public static void main(String[] args) {   
        //獲取Logger對象的實例（傳入當前類）         
        Logger logger = Logger.getLogger(Log4JTest.class);
        //使用默認的配置信息，不需要寫log4j.properties
        BasicConfigurator.configure();
        //設置日誌輸出級別為WARN，這將覆蓋配置文件中設置的級別，只有日誌級別低於WARN的日誌才輸出
        logger.setLevel(Level.WARN);
        logger.debug("這是debug");
        logger.info("這是info");
        logger.warn("這是warn");
        logger.error("這是error");
        logger.fatal("這是fatal");
    }
}

例子（配置文件方式）

上面的例子，我們想要實現打印Log，但是每次都要寫一遍，浪費時間和精力，所以，Log4j提供了另外一種方式來配置好我們的信息

創建一個名為log4j.properties的文件，此文件需要放在項目的根目錄（約定），如果是maven項目，直接放在resources文件夾中即可

log4j.properties

#控制台
log4j.appender.Console=org.apache.log4j.ConsoleAppender
log4j.appender.Console.layout=org.apache.log4j.PatternLayout
log4j.appender.Console.layout.ConversionPattern=%d [%t] %-5p [%c] - %m%n

#log jdbc
log4j.logger.java.sql.ResultSet=INFO
log4j.logger.org.apache=WARN
log4j.logger.java.sql.Connection=DEBUG
log4j.logger.java.sql.Statement=DEBUG
log4j.logger.java.sql.PreparedStatement=DEBUG

#log mybatis設置
#log4j.logger.org.apache.ibatis=DEBUG
log4j.logger.org.apache.ibatis.jdbc=error
log4j.logger.org.apache.ibatis.io=info
log4j.logger.org.apache.ibatis.datasource=info

#springMVC日誌
log4j.logger.org.springframework.web=WARN

# 文件輸出配置
log4j.appender.A = org.apache.log4j.DailyRollingFileAppender
log4j.appender.A.File = D:/log.txt #指定日誌的輸出路徑
log4j.appender.A.Append = true
log4j.appender.A.Threshold = DEBUG
log4j.appender.A.layout = org.apache.log4j.PatternLayout #使用自定義日誌格式化器
log4j.appender.A.layout.ConversionPattern = %-d{yyyy-MM-dd HH:mm:ss}  [ %t:%r ] - [ %p ]  %m%n #指定日誌的輸出格式
log4j.appender.A.encoding=UTF-8 #指定日誌的文件編碼

#指定日誌的輸出級別與輸出端
log4j.rootLogger=DEBUG,Console,A

#指定某個包名日誌級別（不能超過上面定義的級別，否則日誌不會輸出）
log4j.logger.com.wan=DEBUG

之後使用的話就比較簡單了

//Logger的初始化（這個推薦定義為全局變量，方便使用）
Logger logger = Logger.getLogger(Log4JTest.class);
//輸出Log
logger.info("這是info");

參考鏈接：

lombok

簡介

平常我們創建實體類的時候，需要get/set方法，極其麻煩，雖然IDEA等IDE都是有提供了快捷生成，不過，最好的解決方法還是省略不寫

而lombok就是這樣的一個框架，實現省略get/set方法，當然，lombok的功能不只有此，還有equal，toString方法也可以由此框架自動生成

lombok的原理是使用註解，之後就會在編譯過程中，給Class文件自動加上get/set等方法

不過IDEA似乎無法識別，代碼檢查還是會報錯，所以，使用IDEA的時候還得安裝一個插件，在plugin搜索lombok，之後安裝重啟即可，如圖

之後為Java項目添加依賴

<!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.8</version>
    <scope>provided</scope>
</dependency>

使用示例

1.實體類省略get/set
估計Kotlin中的data關鍵字就是參照着lombok實現的

//這裏我們只需要為類添加Data註解，就會自動生成對應屬性的get/set方法，toString，equal等方法
@Data
public class User {
    private String username;
    private String password;
}

2.需要無參構造以及get/set方法

@Getter
@Setter
@NoArgsConstructor
public class User {
    private String username;
    private String password;
}

3.鏈式調用set方法

@Data
@Accessors(chain = true)
public class User {
    private String username;
    private String password;
}

//使用
User user = new User();
user.setUsername("helo").setPassword("123");

4.參數不為空

//如果調用此方法，就會抱一個空指針錯誤
public String print(@NotNull String str){
    ...
}

5.只需要toString

@ToString(callSuper=true, includeFieldNames=true)
public class User {
    private String username;
    private String password;
    //省略的get/set方法
}

6.builder模式創建實體類對象

@Data
@Builder
public class User {
    private String username;
    private String password;
}
//使用
User user1 = User.builder().username("user1").password("123").build();

7.工具類

@UtilityClass
public class MyUtils{
    //會將此方法自動轉為靜態方法
    public void print(String str){
        ...
    }
}
//使用
MyUtils.print("hello");

8.自動關閉流

public static void main(String[] args) throws Exception {
    //使用Cleanup會自動調用close方法
    @Cleanup InputStream in = new FileInputStream(args[0]);
    @Cleanup OutputStream out = new FileOutputStream(args[1]);
    byte[] b = new byte[1024];
    while (true) {
        int r = in.read(b);
        if (r == -1) break;
        out.write(b, 0, r);
    }
}

9.省略Logger時的初始化

@Log4j
@Log
public class User{
    //會自動添加此語句
    //Logger logger = Logger.getLogger(User.class);
    ...
}

參考：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整