[發(fā)明專利]一種基于大數(shù)據(jù)架構(gòu)的人效服務(wù)系統(tǒng)及方法

有效

• 申請?zhí)枺?/td>: 201810270173.3
• 申請日: 2018-03-29
• 公開（公告）號: CN108596561B
• 公開（公告）日: 2021-06-01
• 發(fā)明（設(shè)計(jì)）人: 張百明
• 申請（專利權(quán)）人: 時時同云科技（成都）有限責(zé)任公司
• 主分類號: G06Q10/10
• 分類號: G06Q10/10;G06Q10/06;G06F16/215;G06F16/25;G06F16/27;G06Q50/10
• 代理公司: 北京市浩天知識產(chǎn)權(quán)代理事務(wù)所(普通合伙) 11276
• 代理人: 宋菲

本發(fā)明屬于數(shù)據(jù)計(jì)算處理技術(shù)領(lǐng)域，公開了一種基于大數(shù)據(jù)架構(gòu)的人效服務(wù)系統(tǒng)及方法，基于大數(shù)據(jù)架構(gòu)的人效服務(wù)方法包括：應(yīng)用的數(shù)據(jù)存儲在大數(shù)據(jù)平臺，所述大數(shù)據(jù)平臺實(shí)時同步交易數(shù)據(jù)；用戶在任意時間點(diǎn)修改提成方案后重新核算員工績效提成工資；支持重算當(dāng)天、本月、本季度的時間段數(shù)據(jù)；具體采用微服務(wù)架構(gòu)開發(fā)、使用領(lǐng)域模型驅(qū)動設(shè)計(jì)的開發(fā)方式，進(jìn)行高內(nèi)聚低耦合擴(kuò)展。本發(fā)明能實(shí)時核算績效統(tǒng)計(jì)結(jié)果，系統(tǒng)不再因數(shù)據(jù)量多少而延遲，特別是用戶修改提成方案或者關(guān)賬后能快速算出超過一個季度或者半年的績效提成數(shù)據(jù)。

技術(shù)領(lǐng)域

本發(fā)明屬于數(shù)據(jù)處理技術(shù)領(lǐng)域，尤其涉及一種基于大數(shù)據(jù)架構(gòu)的人效服務(wù)系統(tǒng)及方法。

背景技術(shù)

本發(fā)明屬于大數(shù)據(jù)計(jì)算技術(shù)領(lǐng)域，公開了一種基于大數(shù)據(jù)架構(gòu)的人效服務(wù)系統(tǒng)及方法，基于大數(shù)據(jù)架構(gòu)的人效服務(wù)方法包括：應(yīng)用的數(shù)據(jù)存儲在大數(shù)據(jù)平臺，大數(shù)據(jù)平臺實(shí)時同步交易數(shù)據(jù)；用戶在任意時間點(diǎn)修改提成方案后重新核算員工績效提成工資；支持重算當(dāng)天、本月、本季度的時間段數(shù)據(jù)；具體采用微服務(wù)架構(gòu)開發(fā)、使用領(lǐng)域模型驅(qū)動設(shè)計(jì)的開發(fā)方式，進(jìn)行高內(nèi)聚低耦合擴(kuò)展。本發(fā)明能實(shí)時核算績效統(tǒng)計(jì)結(jié)果，系統(tǒng)不再因數(shù)據(jù)量多少而延遲，特別是用戶修改提成方案或者關(guān)賬后能快速算出超過一個季度或者半年的績效提成數(shù)據(jù)。

因此能滿足超大數(shù)據(jù)量、支持高并發(fā)、數(shù)據(jù)實(shí)時同步的人效系統(tǒng)應(yīng)運(yùn)而生。

綜上所述，現(xiàn)有技術(shù)存在的問題是：

現(xiàn)有行業(yè)內(nèi)人效服務(wù)比如員工的績效提成、工資結(jié)算等都是支持較少量訂單數(shù)據(jù)(每天訂單量達(dá)不到百萬，千萬級)，如果遇到訂單量超過千萬級，億級不能做到實(shí)時核算數(shù)據(jù)。原因除了訂單量達(dá)不這個級別，技術(shù)架構(gòu)不夠新穎之外還表現(xiàn)在沒有大數(shù)據(jù)平臺的支持，交易數(shù)據(jù)不能及時同步到大數(shù)據(jù)專用平臺，沒有工作流的調(diào)度器，整個任務(wù)的執(zhí)行過程都需要人工參加，并且得盯著各任務(wù)的進(jìn)度。客如云人效系統(tǒng)解決了大數(shù)據(jù)量的問題，工作流的自動任務(wù)調(diào)度問題，方便靈活設(shè)置提成方案，快速算出計(jì)算結(jié)果，同時支持臨時方案創(chuàng)建后通過定時間任務(wù)自動核算上一個季度的提成。

發(fā)明內(nèi)容

針對現(xiàn)有技術(shù)存在的問題，本發(fā)明提供了一種基于大數(shù)據(jù)架構(gòu)的人效服務(wù)系統(tǒng)及方法。

本發(fā)明是這樣實(shí)現(xiàn)的，該基于大數(shù)據(jù)架構(gòu)的人效服務(wù)方法包括：

應(yīng)用存儲數(shù)據(jù)的大數(shù)據(jù)實(shí)時同步交易數(shù)據(jù)：用DTS工具及Kafka工具將每天的訂單數(shù)據(jù)同步到ODS數(shù)據(jù)庫及Hive數(shù)據(jù)庫；同時每天同步訂單數(shù)據(jù)到用于查詢歷史數(shù)據(jù)及為ETL提供支持的Hive歸檔庫中，Hive歸檔庫的數(shù)據(jù)由ETL工具清洗數(shù)據(jù)并抽取數(shù)據(jù)到其他數(shù)據(jù)倉庫；

用戶在任意時間點(diǎn)修改提成方案后重新核算員工績效提成工資。

訂單交易數(shù)據(jù)存于RDS數(shù)據(jù)庫(MySql數(shù)據(jù)庫),日訂單量200G以上，用DTS工具及Kafka工具將每天的訂單數(shù)據(jù)同步到ODS數(shù)據(jù)庫(本質(zhì)是Mongo DB數(shù)據(jù)庫)及Hive數(shù)據(jù)庫。不過該RDS、ODS及Hive數(shù)據(jù)庫只會存45天的訂單數(shù)據(jù)，隨著時間的推移訂單數(shù)據(jù)會每日執(zhí)行清除操作，包括RDS、ODS、Hive數(shù)據(jù)庫45天以前的數(shù)據(jù)也會清除。這可以減輕交易庫的存儲壓力，很多訂單方面的需求用ODS就能解決，同時也避免了大數(shù)據(jù)量操作效率太低的問題。

大數(shù)據(jù)平臺存短短的45天交易數(shù)據(jù)肯定不夠，45天以前的數(shù)據(jù)存在另外一個Hive庫(簡稱歸檔庫)。大數(shù)據(jù)平臺有另外一條同步線程，每天同步訂單數(shù)據(jù)到Hive歸檔庫，Hive歸檔庫用于查詢歷史數(shù)據(jù)及為ETL提供支持。

Hive歸檔庫的數(shù)據(jù)由ETL工具清洗數(shù)據(jù)并抽取數(shù)據(jù)到其他數(shù)據(jù)倉庫(比如:寬表庫、報(bào)表匯總庫)，這樣可以滿足各類針對大數(shù)據(jù)的需求場景。

進(jìn)一步，績效提成的方法包括：