跳過大資料精準實時推薦

   上 周處理過一個案例。我們博士找到我說一個實時精準推薦場景，需要我幫忙一下。我聽她描述，首先經過大資料系統查詢使用者訂單情況得知他買過什麼？還要透過大資料系統查詢使用者看過什麼？然後結合他買的和看的推薦商品。 我問：“這是不是就是一個類似猜你喜歡的？”答：“是”。我又問：“要實時？”答：“最好實時或者準實時。”我說現在這樣設計不可能啊？ 那個大資料系統走一次幾個小時。博士說現在的確如此，幾天更新一次買過什麼。所以聽到這裡大家知道了背景吧。

     當然之所以要走大資料這就是我一直以來說的那句話，單機（套）是最好的架構。資料庫幾十個，商品、訂單、行為等等無法做到跨庫查詢，怎麼辦？資料集中。

資料集中可以實時嗎？可以也不可以。對於關係型資料庫可以，對於hadoop全家桶成員有的可以，有的不行。這個不行主要還是hive自身缺陷，不支援寫。這就天生註定了，只能定時合併。

    我給出的方案是（本案例恰好，商品和訂單都是MySQL，我採用多源複製的方案進行了資料庫的實時匯聚。如果是遇到Oracle PG等，其實異構資料庫也是可以透過CDC技術來實時匯聚）。對現有SQL進行改寫，目前是30多萬資料中選出50條，其實這已經是海選，不是精準了。何為精準推薦，就是隻推薦1-2個，數量在於精，而不在於多。我個人認為50個其實效果還不如5個好。但是先解決30萬的問題。

      select 商品屬性 from 商品表 where  商品賣家 ='123' and 商品新上架時間>='2022-10-21 00:00:00'   and  （一個買家使用者買過的商品屬性   or  還是一個買家使用者看過的商品屬性）這裡買過的屬性是從訂單表中拿，而且拿最新的一條。看過的屬性從行為表中拿，而且拿最新的一條。也就是說等於拿著兩條資料特徵去商品表中找，很容易很快。

       我在實際環境中測試了一下，平均30毫秒。其實這裡最難的無非就是商品、訂單和行為是三個資料庫。如果都是一個資料庫，更加簡單了。

    本案例典型的使用 資料庫直接完成實時的精準推薦。雖然速度不是最優，但是還可以吧。要讓使用者體驗好，必須在資料庫段壓到100毫秒內，這樣給網路和其他環境留下空間。

    我比較得意的點在於，邏輯清楚，而且真的還算快。沒有中間環節，沒有拖泥帶水。直接資料庫映象複製解決。

   很多時候資料庫本身不慢，但是如果設計無用的太多，那才是真的讓他慢。