在上一章中作者對合并/打通這兩種賬號的交互做了概念區(qū)分及處理方式的講解，詳情：《賬號合并/打通的區(qū)分及處理》；接下來會分為兩篇分別對賬號合并、打通后的歷史數(shù)據(jù)處理方法進(jìn)行說明，我們一起來看一下。

先回顧賬號合并：

• 概念：一個(gè)系統(tǒng)內(nèi)，一個(gè)用戶的多個(gè)賬號合并成一個(gè)賬號；
• 場景：一個(gè)系統(tǒng)內(nèi)，相同類型的賬號合并/不同類型的賬號合并；
• 要求：一個(gè)系統(tǒng)中一個(gè)用戶身份只有一個(gè)賬號，且所有登錄方式產(chǎn)生的數(shù)據(jù)都遷移累計(jì)在該賬號下。

由上可知，不論是哪種合并場景，其本質(zhì)都是將多個(gè)賬號的同類型數(shù)據(jù)進(jìn)行了合并，將所有數(shù)據(jù)都合并到一個(gè)用戶緯度，因此本文將圍繞“歷史數(shù)據(jù)的合并處理方法”展開討論。

以下為本文大綱：

一、開始的開始，舉個(gè)“栗子”

所有的解決方案是依附具體背景存在的，因此本文依附以下案例展開討論：

你負(fù)責(zé)一個(gè)問答社群平臺的賬號系統(tǒng)，現(xiàn)在接到一個(gè)需求：給用戶提供賬號合并的功能，用戶可以對名下多個(gè)賬號發(fā)起合并請求，實(shí)現(xiàn)對多個(gè)賬號名下收藏關(guān)注的文章用戶、閱讀簽到等產(chǎn)生的成就權(quán)益等數(shù)據(jù)進(jìn)行統(tǒng)一管理。

在合并完成后，后續(xù)該用戶所有操作產(chǎn)生的數(shù)據(jù)都會進(jìn)入合并后的賬號；那么在合并前，幾個(gè)待合并賬號內(nèi)產(chǎn)生的數(shù)據(jù)呢？這些數(shù)據(jù)也屬于該用戶，也就是本文所指的歷史數(shù)據(jù)；歷史數(shù)據(jù)就是在進(jìn)行合并之前，系統(tǒng)中已經(jīng)存在的原始數(shù)據(jù)。

為了后續(xù)該用戶可以通過合并后的賬號順利調(diào)用歷史數(shù)據(jù)，完成指定的業(yè)務(wù)操作，我們需要將所有賬號的歷史數(shù)據(jù)合并入最終的賬號內(nèi)，即要對歷史數(shù)據(jù)進(jìn)行合并操作；數(shù)據(jù)合并就是將同類型的多個(gè)入口的輸入數(shù)據(jù)集合并為新的單個(gè)輸出數(shù)據(jù)集，為數(shù)據(jù)消費(fèi)者提供唯一數(shù)據(jù)出口的數(shù)據(jù)集成方式。

技術(shù)實(shí)現(xiàn)合并后，發(fā)現(xiàn)幾個(gè)問題：

• 待合并的兩個(gè)賬號，關(guān)注了相同的用戶；合并后賬號產(chǎn)生了重復(fù)關(guān)注的用戶，導(dǎo)致總數(shù)統(tǒng)計(jì)錯(cuò)誤，數(shù)據(jù)冗余。
• 待合并的兩個(gè)賬號，成就勛章分別是1級與3級，合并后用戶依據(jù)勛章級別開放的權(quán)限出現(xiàn)了業(yè)務(wù)沖突。

可見，歷史數(shù)據(jù)的合并不是簡單的1+1=2，若是處理不規(guī)范，可能會產(chǎn)生類似上述的異常；本文就從合并每種類型歷史數(shù)據(jù)可能產(chǎn)生的異常入手，分析對應(yīng)的處理方案。

二、數(shù)據(jù)有哪些類型

從業(yè)務(wù)角度入手，筆者將數(shù)據(jù)拆分為以下五種類型：標(biāo)示類、定義類、關(guān)系類、權(quán)限類、業(yè)務(wù)類。

1. 標(biāo)示類

定義：對身份進(jìn)行標(biāo)示定義的唯一數(shù)據(jù)，例如上例的用戶昵稱、性別；與userid為同一級別，標(biāo)示用戶身份，一般為存儲在數(shù)據(jù)庫user表中的用戶數(shù)據(jù)。

特征：所有賬號的標(biāo)示類數(shù)據(jù)格式統(tǒng)一，且該類參數(shù)在用戶緯度內(nèi)唯一。

2. 定義類

定義：用戶自己設(shè)置或系統(tǒng)對其配置的定義個(gè)人屬性的參數(shù)。例如上例的用戶簽名、用戶自己配置的系統(tǒng)設(shè)置項(xiàng)、電商系統(tǒng)的收貨地址；這類數(shù)據(jù)是對用戶本人、及操作習(xí)慣等的定義。

特征：此類參數(shù)在用戶緯度內(nèi)不唯一，但是不可重復(fù)。

3. 關(guān)系類

定義：由于用戶本人的操作，用戶與系統(tǒng)中本人、非本人數(shù)據(jù)產(chǎn)生的關(guān)系；例如上例的文章收藏夾、關(guān)注用戶即為與非本人數(shù)據(jù)產(chǎn)生的關(guān)系；印象筆記中的筆記本與筆記即為與本人數(shù)據(jù)產(chǎn)生的關(guān)系，關(guān)聯(lián)的數(shù)據(jù)之間可以產(chǎn)生更多的交互業(yè)務(wù)。

特征：該類參數(shù)在用戶緯度內(nèi)的限制根據(jù)業(yè)務(wù)決定。

4. 權(quán)限類

定義：用戶付費(fèi)、申請或系統(tǒng)賦予的用戶權(quán)限，不同的權(quán)限對應(yīng)用戶不同的操作、可視數(shù)據(jù)，例如上例的用戶成就勛章。

獲取方式：

權(quán)限類數(shù)據(jù)一般有兩種獲取方式：付費(fèi)購買、系統(tǒng)賦予。

系統(tǒng)授予又分為：主動(dòng)與被動(dòng)兩種獲取方式。

• 主動(dòng)：由用戶發(fā)起的權(quán)限申請，例如申請成為專欄作家；
• 被動(dòng)：系統(tǒng)根據(jù)用戶使用情況授予的權(quán)限，例如用戶積分對應(yīng)的權(quán)限；系統(tǒng)根據(jù)用戶在系統(tǒng)中所處的角色授予的權(quán)限，例如將某用戶配置為管理員、將某用戶配置為試用期。

權(quán)限類型：

權(quán)限一般分為以下類型：

• 配置類：直接授予、獲取的角色權(quán)限、操作權(quán)限、數(shù)據(jù)權(quán)限；
• 積累類：根據(jù)用戶操作經(jīng)驗(yàn)產(chǎn)生的積分，對應(yīng)不同的權(quán)限。

權(quán)限類數(shù)據(jù)特征：權(quán)限類數(shù)據(jù)可能不僅是一個(gè)最終結(jié)果，也可能是一個(gè)未完結(jié)的申請流程，該類參數(shù)在用戶緯度內(nèi)限制根據(jù)業(yè)務(wù)決定。

5. 業(yè)務(wù)類

定義：由于用戶操作或使用生成的業(yè)務(wù)流水/創(chuàng)造的數(shù)據(jù)。例如上例中用戶發(fā)布的文章、用戶設(shè)置的收藏文章標(biāo)簽、消息、后臺的每日使用人數(shù)。

特征：該類參數(shù)在用戶緯度內(nèi)的限制根據(jù)業(yè)務(wù)決定。

三、歷史數(shù)據(jù)合并處理方式

1. 標(biāo)示類

場景：用戶持有A、B兩個(gè)賬號，兩個(gè)賬號的昵稱分別為小王、小李，現(xiàn)對兩個(gè)賬號發(fā)起合并，并指定賬號A為主賬號。

問題：數(shù)據(jù)合并后用戶昵稱有兩個(gè)，不知道使用哪個(gè)。

案例中的用戶昵稱為標(biāo)示類數(shù)據(jù)，標(biāo)示類數(shù)據(jù)是對用戶身份的標(biāo)示，與userID同一級別，因此在一個(gè)賬號內(nèi)有唯一性；在上例沒有正確處理該數(shù)據(jù)，產(chǎn)生了數(shù)據(jù)沖突的異常，最終無法精準(zhǔn)定位。

所以標(biāo)示類數(shù)據(jù)的正確合并方式為：由發(fā)起合并的用戶指定保留數(shù)據(jù)的賬號，覆蓋掉其余待合并賬號的數(shù)據(jù)。

注意：最終保留的所有標(biāo)示類數(shù)據(jù)需都取自同一個(gè)賬號，若不同用戶的標(biāo)示數(shù)據(jù)拼合在一起，可能影響后續(xù)業(yè)務(wù)數(shù)據(jù)調(diào)用。

2. 定義類

場景：用戶持有A、B兩個(gè)賬號。分別對某些用戶設(shè)置了黑名單，屏蔽他們的消息，兩個(gè)賬號設(shè)置的內(nèi)容有重復(fù)項(xiàng)，現(xiàn)對兩個(gè)賬號發(fā)起合并申請。

問題：數(shù)據(jù)合并后黑名單出現(xiàn)重復(fù)項(xiàng)。

案例中的黑名單設(shè)置即為定義類數(shù)據(jù)，該類參數(shù)定義個(gè)人屬性，因此在個(gè)人緯度是不可重復(fù)的。在上例中沒有正確處理該數(shù)據(jù)，產(chǎn)生了數(shù)據(jù)重復(fù)的異常，使得最終數(shù)據(jù)統(tǒng)計(jì)錯(cuò)誤、數(shù)據(jù)冗余，嚴(yán)重的話會引發(fā)bug，數(shù)據(jù)失效。

所以定義類數(shù)據(jù)的正確合并方式為：由于定義類參數(shù)定義個(gè)人屬性，因此合并后的賬號需要將所有待合并賬號的定義類數(shù)據(jù)累計(jì)起來；為了避免重復(fù)，需要進(jìn)行去重。

3. 關(guān)系類

場景：對A、B兩個(gè)賬號發(fā)起合并，用戶C關(guān)注了B賬號；合并處理后僅保留A為代表用戶身份的主賬號，并將所有數(shù)據(jù)都遷移累計(jì)到A賬號下，B賬號作廢。

問題：用戶C無法再訪問關(guān)注名單中的B賬號。

案例中的關(guān)注關(guān)系即為關(guān)系類數(shù)據(jù)，該類數(shù)據(jù)是用戶與系統(tǒng)中非本人數(shù)據(jù)產(chǎn)生的關(guān)系，因此要求合并后的賬號與歷史其他非本人數(shù)據(jù)的關(guān)系依舊保存；在上例中沒有正確處理該數(shù)據(jù)，產(chǎn)生了數(shù)據(jù)失位的異常，導(dǎo)致歷史的關(guān)系無法定位追蹤。

場景：一個(gè)文章可以打多個(gè)不同的標(biāo)簽，用戶對A、B兩個(gè)賬號發(fā)起合并，兩個(gè)賬號的收藏夾內(nèi)有相同文章、相同的標(biāo)簽；合并過程中直接將兩個(gè)賬號中這兩個(gè)參數(shù)進(jìn)行合并去重，未考慮對應(yīng)關(guān)系。

問題：數(shù)據(jù)是完完整整都合并入最終賬號內(nèi)，但是每個(gè)文章的標(biāo)簽是什么呢？

案例中的標(biāo)簽與文章存在關(guān)聯(lián)關(guān)系，在合并時(shí)沒有考慮這部分關(guān)系，導(dǎo)致最終的數(shù)據(jù)錯(cuò)位，數(shù)據(jù)間的關(guān)聯(lián)關(guān)系沒辦法恢復(fù)。

綜上，關(guān)系類數(shù)據(jù)的正確合并方式為：待合并賬號與系統(tǒng)中本人、非本人數(shù)據(jù)產(chǎn)生的關(guān)系，需要遷移到最終合并后的賬號。

例如第一例中，需要將C賬號收藏夾中的B賬號，切換為A賬號，實(shí)現(xiàn)關(guān)聯(lián)關(guān)系的遷移。

當(dāng)然了，處理這類需求時(shí)要考慮業(yè)務(wù)場景，不同的場景可能有不同的處理方法：

• 若為強(qiáng)交互的產(chǎn)品，如社交類產(chǎn)品，需要讓其他用戶及時(shí)準(zhǔn)確定位到合并后的賬號；因此需要將B賬號切換為A賬號；
• 若為弱交互的產(chǎn)品，如資訊類產(chǎn)品，只需要讓用戶知道將來如何繼續(xù)跟蹤B賬號；因此，在用戶主動(dòng)查詢、點(diǎn)擊B賬號時(shí)，再提醒其已經(jīng)合并作廢，并提供合并后的A賬號路徑即可。

4. 權(quán)限類

場景：系統(tǒng)規(guī)定，用戶成就勛章對于一個(gè)賬號是唯一且分等級的，不同的等級對應(yīng)不同的用戶權(quán)益。

用戶對A、B兩個(gè)賬號發(fā)起合并，兩個(gè)賬號的勛章分別是“筆桿子10級”與“筆桿子3級”；合并處理后僅保留A為代表用戶身份的主賬號，并將所有數(shù)據(jù)都遷移累計(jì)到A賬號下。

問題：A的勛章為“筆桿子10級”與“筆桿子3級”，現(xiàn)在用戶到底算是10級還是3級？級別相關(guān)的權(quán)益如何判定？

案例中的勛章即為權(quán)限類數(shù)據(jù)，此類權(quán)限類的數(shù)據(jù)具有唯一性，在上例沒有正確處理該數(shù)據(jù)，產(chǎn)生了數(shù)據(jù)沖突的異常，最終無法精準(zhǔn)提供后續(xù)的服務(wù)。

與標(biāo)示類數(shù)據(jù)處理方式類似，具有唯一性的權(quán)限類數(shù)據(jù)的合并最終只需保留一個(gè)權(quán)限，處理方式也是覆蓋，但是具體保留哪個(gè)賬號的數(shù)據(jù)與具體的業(yè)務(wù)場景相關(guān)。

再舉個(gè)例子，后臺對帳號A的角色配置為編輯，對帳號B的角色配置為運(yùn)營，現(xiàn)對兩個(gè)帳號發(fā)器合并，合并后用戶的角色應(yīng)該是什么？若系統(tǒng)支持一人多角色，那么合并后用戶的權(quán)限為運(yùn)營+編輯，反之就要去抉擇保留哪個(gè)角色。

由此可見，權(quán)限類數(shù)據(jù)對合并規(guī)則與業(yè)務(wù)息息相關(guān)，例如從不同獲取方式來看：

付費(fèi)購買：此類權(quán)限是用戶付出金錢成本置換到的權(quán)限所有權(quán)，因此保留最高權(quán)限，維護(hù)用戶的利益；

系統(tǒng)賦予：

• 配置類：由具體業(yè)務(wù)限制決定是去重合并or保留一種權(quán)限；
• 積累類：雖然積分是用戶操作積累的，但考慮到合并的開發(fā)難度，也可以結(jié)合實(shí)際業(yè)務(wù)場景決定是只保留主賬戶積分or進(jìn)行累計(jì)?？梢該Q算成現(xiàn)金的積分需要進(jìn)行累計(jì)，例如信用卡積分。

5. 業(yè)務(wù)類

業(yè)務(wù)類數(shù)據(jù)是由于用戶操作或使用生成的業(yè)務(wù)流水/創(chuàng)造的數(shù)據(jù)，本著“數(shù)據(jù)是用戶操作產(chǎn)生的，用戶有對其的使用權(quán)及控制權(quán)，非用戶本人主觀操作數(shù)據(jù)不可變動(dòng)，在操作時(shí)要避免歷史數(shù)據(jù)的丟失”的原則，對此類業(yè)務(wù)數(shù)據(jù)使用累計(jì)+重新排序的方式進(jìn)行合并；一般是按照時(shí)間順序，例如用戶消息、訂單流水，此處就不對其進(jìn)行展開描述。

四、總結(jié)

由上述全文可知，在處理合并賬號的歷史數(shù)據(jù)時(shí)，需要保證對所有歷史數(shù)據(jù)的兼融，保留所有原始數(shù)據(jù)；也要進(jìn)行相應(yīng)的限制，避免數(shù)據(jù)處理錯(cuò)誤導(dǎo)致的數(shù)據(jù)錯(cuò)誤等風(fēng)險(xiǎn)。

所以，【兼融】、【限制】就是歷史數(shù)據(jù)處理的原則。

萬變不離其宗，下一篇對系統(tǒng)打通歷史數(shù)據(jù)的處理，也會由這兩個(gè)原則出發(fā)，請大家拭目以待～

作者：橘子；公眾號：橘子周思錄；我是3年產(chǎn)品橘子，每周分享自己對日常工作的總結(jié)思考，希望與您一同成長。

本文由 @橘子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。