來自乙個使用者匹配的需求。使用者的不同資訊分布於兩個系統，且客觀上無法直接打通。所以就涉及到兩個系統id匹配的問題。
先抽象問題：系統a，系統b；系統a中存在乙個使用者a（字段：a_id, a_img, a_name）， 系統b中可能有a的補充資訊（字段：ab_id, ab_img,ab_name），
目標：如果b中存在使用者a的資訊，那麼希望能找到並進行匹配，並把匹配結果返回系統a，結果格式：a_id, a_img, a_name,ab_id
字段說明：
a_id 使用者a在系統a的id；
a_img 使用者a在系統a的屬性鏈結，注： a_img和ab_img雖然都是使用者a的鏈結，但可能鏈結並不相同。例如a_img: http://sysa/a1.jpg，ab_img：http://sysb/b2.jpg
a_name 使用者a在系統a的屬性暱稱；
ab_id 使用者a在系統b中的id。
這兩個屬性是判定兩個系統中的使用者是否是同乙個的主要依據。
注：以下只是專案初期的簡化匹配策略。因為資料特性，經過統計和特徵分析，驗證準確率可以達到預期，所以初期不會為百分之幾的優化投入過多資源和精力。所以不必糾結策略的準確率
1、首先通過暱稱匹配
當系統a的使用者暱稱，與系統b的有且只有一條記錄暱稱相同時，將這兩個記錄匹配 【根據真實資料經驗，使用者進入兩個系統記錄的時間規律，並允許較低的錯誤率；支援人工修復】；
2-1 分別拉取a_img 和 ab_img的內容（字串），如果內容相同，那麼確定是同一條記錄，記錄匹配關係；
2-2 如果內容不同，計算兩張的相似度（漢明距離）。當相似度大於指定閾值時，認為二者匹配，記錄匹配關係
可以看到，這裡可能會有乙個比較耗費資源的動作，就是需要匹配內容時。我們要拉取內容、字串直接比對、簡化特徵、計算漢明距離，而當這個計算邏輯被併發呼叫的頻率很高時，所需的頻寬、計算能力都有可能成為瓶頸。自運維就需要解決峰值問題，或強制限制呼叫頻率。所以採用函式計算來做彈性支援。
另外，為了減少重複的拉取動作，降低流量消耗，且繫結資料儲存在系統b中。那麼我們先完成系統b內img的內容拉取，和特徵提取工作，對於乙個新的匹配請求，我們只需要拉取a_img的內容並特徵提取就可以了，減少了近一半的工作。
目前，專案已經在開發中，效果已做驗證，即將上線。未來再進行深入優化
socket實踐 第乙個入門案例
伺服器端 第三步 監聽 第四步 接受客戶端，這裡遞迴非同步方法，如果socket不為null，遞迴執行接收訊息的非同步方法 第五步 把控制台的輸入傳送給所有已建立連線的客戶端 view code using system using system.collections.generic using ...
乙個差分計算的案例
今天碰到乙個需求需要做趨勢分析，後來在高人指點下使用移動差分函式進行處理。雖然使用這個函式，但是要計算出來還是比較複雜的。建立測試表 create multiset table sxedrm2.test stddev pop no before journal no after journal de...
ROWNUM 應用案例 實現乙個拉鍊表
有以下資料表 事件標識表未這 票進入 1 或者移除 2 某 票池。我們需要對資料進行去重，就是連續多次的進入，或者連續多次的移除，都只取第一次的日期。如圖中，黃色的記錄是不需要的。這個表命名為demo 首先第一步 select scode,poolid,effective day,adjustmod...