大數(shù)據(jù)筆試題：運營筆試題（一）

　　1.hive SQL的分組topN問題，成績表S，字段sid,cid,score，求每門課程的前2名與后2名sid。

　　2.ES中游標和快照有什么區(qū)別？

　　3.用戶畫像、推薦系統(tǒng)、Flink實時數(shù)倉、準實時數(shù)倉中，遇到的棘手的問題都有什么？

　　4.用戶畫像系統(tǒng)中遇到的比較難的問題是什么？

　　5.如何構建用戶的稠密向量的問題？

　　答案區(qū)

　　1.下面是我的做法，求個更好的

　　select sid from

　　(select sid,

　　rank() over(partition by cid order by score) as RA

　　from S) as A

　　union

　　(select sid,

　　rank() over(partition by cid order by score DESC) as RB

　　from S) as B

　　where RA<3 and RB<3

　　2.它們兩個沒有什么可比性， 在深分頁場景下我們不能使用(from+size)的方式查詢ES，因為性能太低(from+size 方式會從每個分片取出from+size大小的數(shù)據(jù)，讓后在協(xié)調節(jié)點做Merge返回，分頁越深協(xié)需要處理的數(shù)據(jù)量越大)。一般使用`scroll`方式解決深分頁問題，`scroll`在初始化階段會對查詢數(shù)據(jù)生成`快照(不可變的數(shù)據(jù)集，不受索引的更新，刪除的影響，單維護這個快照是需要耗費資源的)`，之后的查詢都會對快照數(shù)據(jù)根據(jù)`scroll_id`進行遍歷查詢。

　　3.用戶畫像

　　我們在選擇如何存儲用戶標簽時，遇到了問題(標簽查詢速度慢，并且構建不夠靈活，標簽更新和刪除比較麻煩)，比如之前用HDFS或者ES存儲，后來切換為ClikcHouse，并用BitMap存儲，原因如下：

　　針對標簽的表示形式，存儲方式有很多，結構為`寬表，BitMap` 都可以，存儲選擇`HDFS，ES，ClickHouse 等` 也都可以，需要衡量的有兩點：

　　1）標簽構建的靈活性和構建速度

　　2）標簽的查詢效率 ` `HDFS [Presot,Impala]：` 標簽的增加，刪除，更新不友好, 一個小變動，要重寫整個`Parquet`, 寫放大問題。 查詢效率還可以，但是不夠優(yōu)秀。 支持查詢并發(fā)較小。 `ES：`標簽的構建的寫入速度一般， 新增和修改標簽需要對ES文檔結構更新，ES的DSL語法不友好，有一定學習成本。查詢效率還算優(yōu)秀，同時支持高并發(fā)。 ES資源占用高，需要較好的硬件配置。 `ClickHouse[BitMap]` 標簽可以并行構建，查詢效率優(yōu)秀，標簽的增加非常方便，標簽的更新和刪除可以實現(xiàn)，但是并不高效，并發(fā)查詢支持比Presto，Impala要好，但同樣不支持高并發(fā)，能夠滿足大部分場景需求。注意兩點：

　　a. BitMap存儲的是用戶ID

　　b. BitMap使用了RoaringBitMap, 解決BitMap空間占用問題，不然1億這一個數(shù)也要占用11.9M空間`

　　如何構建用戶的稠密向量的問題？

　　如果我們直接將用戶的標簽轉換為稀疏向量來存儲，對于類別標簽使用`one-hot`編碼，但這樣會出現(xiàn)維度爆炸的問題，向量過于稀疏，向量之間的余弦相似度計算結果基本沒有意義，根本無法實現(xiàn)用戶相似度的計算。所以就開始思考如何將用戶表示為轉換為稠密向量，經過調研發(fā)現(xiàn)，Word2Vec可以將詞轉換為稠密向量，同時借助Word2Vec思想，也可以將物品轉換為向量Item2Vec，比如將一個Session內，用戶購買的物品或者點擊的物品列表，看成是一句話，每個物品看成是一個單詞，就可以借助Word2Vec的思想將物品轉換為稠密向量表示。(這里注意如果是文章，可以使用分詞，然后抽取關鍵詞，將詞通過Word2Vec轉換為向量的方式) ，我們再將用戶點擊或者購買的物品列表中物品向量加和求平均，就可以得到用戶的稠密向量。后來發(fā)現(xiàn)通過ALS模型`矩陣分解`的方式也可以得到用戶的稠密向量，兩者`表達的用戶向量含義`是不同的，一個是有濃重的物品屬性特征的，一個是有協(xié)同特征的向量。但是都可以作為用戶的向量表示方式。

　　推薦系統(tǒng)

　　1）SparkML Pipline 訓練模型通過PMML跨平臺部署時字符串轉向量的問題

　　由于我們通過Pipline訓練出來的排序模型，模型的輸入是之前存入HBase中向量(用戶和物品)字符串，當我們使用`jpmml-sparkml` 這個類庫去生成PMML模型，進行擴平臺部署時，發(fā)現(xiàn)無法正常生成PMML。 原因是因為對于字符串轉向量這種`transformer操作` jpmml沒有支持，我們參照jpmml源碼的實現(xiàn)方式，做了自定義transformer的實現(xiàn)。原理是先自定義一個Spark ML的transform，然后再擴展一個jpmml對應的converter即可。

　　2）特征向量Load到HBase慢的問題

　　我們構建出來的用戶特征向量和物品特征向量，最終是存儲到HBase中的，最初是使用HBase API寫入數(shù)據(jù)，但是太慢了，整個數(shù)據(jù)的寫入要耗費5~6個小時，之后我們`使用了bulkLoad的方式`，直接通過使用Spark生成將數(shù)據(jù)`生成HFile文件`寫入到HDFS，然后使用blukLoad直接生成好的HFile文件mv過去即可，15分鐘完成。 更具體點，首先我們把我們將要寫入hbase的rdd，按照設定的行鍵排序，之后將行鍵和值構造一個HFile的KeyValue結構，設定outputformat 為HFileOutputFormat2，將生成的hfile數(shù)據(jù)寫入到hdfs，之后通過doBulkLoad方法將寫到HDFS上hfile數(shù)據(jù)移動到hbase目錄中。(這些項目的代碼中都有)

　　3）多路召回結果如何如何統(tǒng)一排序的問題

　　因為我們采用了多種召回算法，比如ItemCF,ALS, 基于熱門，基于地域 等召回算法。 沒有召回算發(fā)的結果集我們是無法直接排序的，因為各個召回算法表達的含義是不同的，最開始不知道該怎么做，因此就是各個召回算法設定一個人為比例去取。 之后學習了解到可以加`一個排序模型`做這個事情，原理就是用戶向量和物品向量作為基礎特征，用戶是否點擊物品作為標簽，訓練一個排序模型(LR)，只有將各路召回策略輸入排序模型重新排序即可。 # 注意如果你同時說1，3問題，注意順序

　　數(shù)倉問題

　　1）Flink Watermark激增的問題

　　從這上面的我舉的例子，你應該知道這種情況發(fā)生的原因，是因為我們抽取事件事件直接減去延遲時間造成，解決方式就是我們再抽取watermark時，判斷一下事件中的時間和上次watermark的時間，如果兩者時間相差很大，我們就不更新watermark或者將watermark加上一個小值就可以了，一般選擇不更新。

　　2）實時作業(yè)和離線作業(yè)的資源競爭問題

　　因為我們統(tǒng)一用Yarn做資源調度，實時作業(yè)Flink(Spark Streaming)和離線作業(yè)會調度到同一個機器上，集群相對空閑時沒什么問題，但是當集群負載較高時，尤其是晚上大批離線任務啟動，就會造成我們實時作業(yè)的某些Container所在機器負載過高，同時我們實時作業(yè)中如果有重計算邏輯，F(xiàn)link計算不過來，背壓產生，Kafka消費延遲，數(shù)據(jù)積壓。解決這個問題的方法是，YARN Label，給YARN管理的機器打上標簽，離線和實時分開，提交作業(yè)時指定Lable。

　　3）實時作業(yè)調度集中的問題

　　問題產生的背景是，當提交一個作業(yè)時(Flink,Spark)，作業(yè)不大，YARN上申請10個Container，發(fā)現(xiàn)10個Container都調度到一個節(jié)點上，或者大部分調度到一個節(jié)點上，幾個調度到另一個節(jié)點，資源分配傾斜。 這樣造成如果我的作業(yè)是一個重計算的作業(yè)，10Container都在一個節(jié)點上，CPU load過高，計算延遲。 當時出現(xiàn)這個問題，比較苦惱，不知道什么原因，也沒有search到解決方案，最后只能去看源碼了(我們用的是Fair調度器)，發(fā)現(xiàn)Container的分配策略是在一個NodeManger心跳中盡可能多的分配Container，這是為了提升調度的吞吐，但是源碼中有參數(shù)可以控制，是否一個心跳允許分配多個Container，以及一次心跳最大分配多少個Container給當前的NodeManager.這個參數(shù)Yarn已經暴露給用戶了`yarn.scheduler.fair.assignmultiple` 默認是true。`yarn.scheduler.fair.max.assign` 默認是-1，就是無限制。 解決的方式是`yarn.scheduler.fair.max.assign` 設置為一個較小的值，比如2.

　　4.我們在選擇如何存儲用戶標簽時，遇到了問題(標簽查詢速度慢，并且構建不夠靈活，標簽更新和刪除比較麻煩)，比如之前用HDFS或者ES存儲，后來切換為ClikcHouse，并用BitMap存儲,原因如下：

　　針對標簽的表示形式，存儲方式有很多，結構為`寬表，BitMap` 都可以，存儲選擇`HDFS，ES，ClickHouse 等` 也都可以，需要衡量的有兩點：

　　1）標簽構建的靈活性和構建速度

　　2）標簽的查詢效率

　　`HDFS [Presot,Impala]：` 標簽的增加，刪除，更新不友好， 一個小變動，要重寫整個`Parquet`，寫放大問題。 查詢效率還可以，但是不夠優(yōu)秀。 支持查詢并發(fā)較小。

　　`ES：`標簽的構建的寫入速度一般， 新增和修改標簽需要對ES文檔結構更新，ES的DSL語法不友好，有一定學習成本。查詢效率還算優(yōu)秀，同時支持高并發(fā)。 ES資源占用高，需要較好的硬件配置。

　　`ClickHouse[BitMap]` 標簽可以并行構建，查詢效率優(yōu)秀，標簽的增加非常方便，標簽的更新和刪除可以實現(xiàn)，但是并不高效，并發(fā)查詢支持比Presto，Impala要好，但同樣不支持高并發(fā)，能夠滿足大部分場景需求。

　　注意兩點：

　　1. BitMap存儲的是用戶ID

　　2. BitMap使用了RoaringBitMap, 解決BitMap空間占用問題，不然1億這一個數(shù)也要占用11.9M空間`

　　5.如果我們直接將用戶的標簽轉換為稀疏向量來存儲，對于類別標簽使用`one-hot`編碼，但這樣會出現(xiàn)維度爆炸的問題，向量過于稀疏，向量之間的余弦相似度計算結果基本沒有意義，根本無法實現(xiàn)用戶相似度的計算。所以就開始思考如何將用戶表示為轉換為稠密向量，經過調研發(fā)現(xiàn)，Word2Vec可以將詞轉換為稠密向量，同時借助Word2Vec思想，也可以將物品轉換為向量Item2Vec，比如將一個Session內，用戶購買的物品或者點擊的物品列表，看成是一句話，每個物品看成是一個單詞，就可以借助Word2Vec的思想將物品轉換為稠密向量表示。(這里注意如果是文章，可以使用分詞，然后抽取關鍵詞，將詞通過Word2Vec轉換為向量的方式) ，我們再將用戶點擊或者購買的物品列表中物品向量加和求平均，就可以得到用戶的稠密向量。后來發(fā)現(xiàn)通過ALS模型`矩陣分解`的方式也可以得到用戶的稠密向量，兩者`表達的用戶向量含義`是不同的，一個是有濃重的物品屬性特征的，一個是有協(xié)同特征的向量，但是都可以作為用戶的向量表示方式。

　　更多關于大數(shù)據(jù)培訓的問題，歡迎咨詢千鋒教育在線名師，如果想要了解我們的師資、課程、項目實操的話可以點擊咨詢課程顧問，獲取試聽資格來試聽我們的課程，在線零距離接觸千鋒教育大咖名師，讓你輕松從入門到精通。