網(wǎng)上有很多關(guān)于pos機(jī)素材設(shè)計(jì),作業(yè)幫基于 StarRocks 畫(huà)像系統(tǒng)的設(shè)計(jì)及優(yōu)化實(shí)踐的知識(shí)，也有很多人為大家解答關(guān)于pos機(jī)素材設(shè)計(jì)的問(wèn)題，今天pos機(jī)之家(www.tjfsxbj.com)為大家整理了關(guān)于這方面的知識(shí)，讓我們一起來(lái)看下吧!
本文目錄一覽：
pos機(jī)素材設(shè)計(jì)
一、背景介紹作業(yè)幫為提高孩子學(xué)習(xí)效率通過(guò)搜題、答題、咨詢等各種行為數(shù)據(jù)以及輔導(dǎo)效果等結(jié)果數(shù)據(jù)，利用算法、規(guī)則等技術(shù)手段建立用戶畫(huà)像，用于差異化輔導(dǎo)提升學(xué)習(xí)效率。我們根據(jù)畫(huà)像標(biāo)簽特點(diǎn)并結(jié)合 StarRocks 能力建設(shè)了一套相對(duì)適合全場(chǎng)景的畫(huà)像圈人系統(tǒng)。本文主要介紹此畫(huà)像服務(wù)、標(biāo)簽接入的系統(tǒng)設(shè)計(jì)及圈人性能優(yōu)化方式。
二、標(biāo)簽特點(diǎn)注：符號(hào)變量為創(chuàng)建人群時(shí)確定。
三、方案設(shè)計(jì)思考為保證系統(tǒng)支持業(yè)務(wù)需求靈活可擴(kuò)展、架構(gòu)合理、實(shí)現(xiàn)后系統(tǒng)穩(wěn)定且性能滿足預(yù)期，在設(shè)計(jì)前梳理相關(guān)問(wèn)題及思考。
如果滿足以上全部標(biāo)簽類(lèi)型，常規(guī)大寬表、標(biāo)簽 bitmap 化設(shè)計(jì)無(wú)法滿足需求。需要將帶有修飾詞的行為類(lèi)數(shù)據(jù)和常規(guī)標(biāo)簽做交叉，而往往兩類(lèi)數(shù)據(jù)存儲(chǔ)在不同的表或數(shù)據(jù)結(jié)構(gòu)中，同時(shí)支持秒級(jí)查詢利用常規(guī) join 又無(wú)法滿足，最合理的方式仍然是利用 bitmap 的交叉能力，針對(duì)不同規(guī)則人群分別形成 bitmap，然后結(jié)果交叉。而使用 bitmap 結(jié)構(gòu)就必須將用戶唯一標(biāo)識(shí)字符串 cuid 轉(zhuǎn)化為數(shù)值類(lèi)型 guid。
如何將用戶唯一標(biāo)識(shí)轉(zhuǎn)化為數(shù)值型全局唯一自增 guid，并且實(shí)時(shí)和離線標(biāo)簽要采用同一套映射關(guān)系。離線時(shí)效性不夠所以必須采用實(shí)時(shí)方案形成映射關(guān)系，然后同步到離線 hive 用于補(bǔ)充離線標(biāo)簽，映射必須覆蓋實(shí)時(shí)和離線標(biāo)簽全部用戶 id。
標(biāo)簽會(huì)越來(lái)越多而且每個(gè)標(biāo)簽基本都需要經(jīng)過(guò)生產(chǎn)計(jì)算、補(bǔ)充 guid、數(shù)據(jù)校驗(yàn)報(bào)警、寫(xiě)入存儲(chǔ)、原子切換上線等一系列操作，同時(shí)需要控制新增標(biāo)簽的接入成本和后期維護(hù)成本。為此需要將標(biāo)簽生產(chǎn)部分和標(biāo)簽接入部分解耦，抽象接入流程，按照指定規(guī)范實(shí)施，盡可能做到標(biāo)簽配置化接入，統(tǒng)一化管理，支持長(zhǎng)線平臺(tái)化建設(shè)兼容。標(biāo)簽生產(chǎn)也可按照業(yè)務(wù)方向多人并行落地。
性能方面保障需要利用真實(shí)數(shù)據(jù)做相關(guān)測(cè)試，并保證每個(gè)環(huán)節(jié)設(shè)計(jì)可按照資源擴(kuò)展線性提高相關(guān)處理能力。例如數(shù)據(jù)入庫(kù)、圈人查詢、實(shí)時(shí) cuid->guid mapping 等。
穩(wěn)定性方面保障需要針對(duì)關(guān)鍵環(huán)節(jié)配置相關(guān)監(jiān)控報(bào)警，設(shè)置預(yù)案并做故障演練。
四、總體方案設(shè)計(jì)1、方案總覽大概由畫(huà)像服務(wù)、實(shí)時(shí)標(biāo)簽接入、離線標(biāo)簽接入三部分組成。
（1）畫(huà)像服務(wù)主要承擔(dān)標(biāo)簽配置管理、標(biāo)簽枚舉值解釋映射、人群圈選人群包管理、其他功能系統(tǒng)對(duì)接、標(biāo)簽數(shù)據(jù)接入配置管理及快速回滾能力等。
（2）實(shí)時(shí)標(biāo)簽接入主要負(fù)責(zé)標(biāo)簽接入規(guī)范、cuid->guid 映射及備份、標(biāo)簽實(shí)時(shí)入庫(kù)三部分。通過(guò)抽象工具，任務(wù)可配置化完成。
（3）離線標(biāo)簽接入主要負(fù)責(zé)標(biāo)簽接入規(guī)范、配置化接入（標(biāo)簽數(shù)據(jù)組裝、cuid->guid 映射、校驗(yàn)、監(jiān)控、入庫(kù)等）。
StarRocks 作為全場(chǎng)景 MPP 數(shù)據(jù)庫(kù)，支持多種表模型、秒級(jí)實(shí)時(shí)分析、并發(fā)查詢等能力，同時(shí)又具有 bitmap 存儲(chǔ)結(jié)構(gòu)和配套的 UDF 函數(shù)，降低了對(duì) bitmap 存儲(chǔ)、交叉、管理等方面的工程復(fù)雜程度，所以我們最終選用 StarRocks 作為標(biāo)簽的存儲(chǔ)。
根據(jù)需求場(chǎng)景、性能、靈活性等方面因素考慮，將標(biāo)簽信息抽象為如下幾類(lèi)進(jìn)行存儲(chǔ)。每個(gè)分類(lèi)會(huì)對(duì)應(yīng)一個(gè)查詢模板解決不同業(yè)務(wù)場(chǎng)景問(wèn)題。因讀寫(xiě)性能、標(biāo)簽更新時(shí)效、冪等接入等因素考慮，同一個(gè)類(lèi)型支持了多個(gè) StarRocks 表模型，同一標(biāo)簽也可存儲(chǔ)在不同業(yè)務(wù)類(lèi)型表中。
2、畫(huà)像服務(wù)畫(huà)像服務(wù)核心能力有兩個(gè)。第一個(gè)人群圈選能力，特點(diǎn)為內(nèi)部系統(tǒng) qps 不高，秒級(jí)返回。第二個(gè)單用戶 id 規(guī)則判定能力，特點(diǎn)為 qps 很高，10 毫秒級(jí)返回。第二個(gè)不在本系統(tǒng)設(shè)計(jì)范圍內(nèi)，只說(shuō)人群圈選部分，大體執(zhí)行過(guò)程如下：
請(qǐng)求 DSL 參數(shù)解析及校驗(yàn)：將人群圈選 DSL 按標(biāo)簽拆分為多個(gè)獨(dú)立的表達(dá)式和組合關(guān)系，然后根據(jù)標(biāo)簽配置信息補(bǔ)充隱含條件，同時(shí)校驗(yàn)每個(gè)表達(dá)式的合理性。查詢邏輯優(yōu)化：標(biāo)簽同表存儲(chǔ)時(shí)合并表達(dá)式，減少單表達(dá)式數(shù)據(jù)返回量加速查詢速度。表達(dá)式轉(zhuǎn) SQL：根據(jù)抽象類(lèi)型對(duì)應(yīng)的查詢模板，將優(yōu)化合并后的表達(dá)式分別轉(zhuǎn)化為多個(gè)子查詢，然后結(jié)合組合關(guān)系形成整條 SQL 。執(zhí)行 SQL 圈選人群。建表語(yǔ)句及查詢模板性能測(cè)試（1）Profile + Agg 測(cè)試
實(shí)時(shí)場(chǎng)景未采用 PK 主要因?yàn)椴恢С?REPLACE_IF_NOT_NULL 和局部列更新，標(biāo)簽間入庫(kù)解耦需要此能力。性能測(cè)試如下：
測(cè)試所用集群：32C 96G 1TSSD * 5臺(tái)，3個(gè)FE，5個(gè)BE，5個(gè)Broker。 1.19.5版本表數(shù)據(jù)：2.58億行，3個(gè)指標(biāo)列，單副本約1.7G，AGGREGATE KEY(`guid`), DISTRIBUTED BY HASH(`guid`)，數(shù)據(jù)分布均勻。 1.profile_b5表 bucket 5 共5個(gè)tablet 每個(gè)tablet 365M 2.profile_b20表 bucket 20 共20個(gè)tablet 每個(gè)tablet 95M 3.profile_b5_p5kw表 bucket 5 共30個(gè)tablet 每個(gè)tablet 67M 1）profile_b5_p5kw表中adpos_id、unit_id加bitmap索引。 2）profile_b5_p5kw表按PARTITION BY RANGE(`guid`) 每5kw一個(gè)分區(qū)。測(cè)試數(shù)據(jù)說(shuō)明： Fragment 1有5個(gè)instance，下邊均采用ip為211的instance相關(guān)數(shù)據(jù)。 Fragment 0有1個(gè)instance，直接引用結(jié)果。 數(shù)據(jù)均為多次查詢后取相對(duì)合理且耗時(shí)較少的profile信息此測(cè)試前已有認(rèn)知： 離線標(biāo)簽采用profile+dup模型測(cè)試bitmap_union(to_bitmap(guid))性能,單BE 1個(gè)instance 1500W/s，to_bitmap耗時(shí)是bitmap_union耗時(shí)的2倍左右，兩個(gè)算子耗時(shí)主要由guid數(shù)量決定。 bitmap_union算子耗時(shí)與單個(gè)tablet內(nèi)guid集中度有關(guān)，guid取值范圍越集中性能越好，建表時(shí)采用Range guid分區(qū)，步調(diào)1000W，bucket為1。
復(fù)制代碼
結(jié)論 1：測(cè)試 1/2 可知查詢耗時(shí)點(diǎn)為 Fragment 1 階段 Scan 操作含 merge-on-Read 過(guò)程[OLAP_SCAN_NODE]、to_bitmap[PROJECT_NODE]、bitmap_union[AGGREGATION_NODE]，而 Fragment 0 階段因數(shù)據(jù)量很少所以耗時(shí)很少。
結(jié)論 2：測(cè)試 2/3 對(duì)比考慮優(yōu)化 Scan 耗時(shí)。增加 bucket 數(shù)量后，Scan 耗時(shí)明顯下降。tablet 數(shù)量增加引起 scan 并行度提高。doris_scanner_thread_pool_thread_num 默認(rèn) 48，tablet 數(shù)量調(diào)整前后為 5->25 均在此范圍內(nèi)，除 profile 信息外還可以通過(guò) Manager 查看對(duì)應(yīng)時(shí)間 Scan 相關(guān)監(jiān)控?？筛鶕?jù)集群負(fù)載情況適當(dāng)增加線程數(shù)用于提高查詢速度。
結(jié)論 3：測(cè)試 3/5 對(duì)比考慮優(yōu)化 bitmap_union 耗時(shí)并兼顧寫(xiě)負(fù)載平衡。采用 Range guid 分區(qū)，5kw 一個(gè)步調(diào)，bucket 設(shè)為 5。每個(gè) tablet 大約 1kw 數(shù)據(jù)量且差值低于 5kw，避免部分 guid 活躍度高帶來(lái)的單分區(qū)寫(xiě)熱點(diǎn)問(wèn)題。同為 5160W+數(shù)據(jù)量 bitmap_union 耗時(shí)減少約 700ms。
結(jié)論 4：測(cè)試 3/4 對(duì)比考慮加上 where 條件后的查詢耗時(shí)表現(xiàn)，因返回?cái)?shù)據(jù)量降低一個(gè)數(shù)量級(jí) bitmap_union(to_bitmap(guid))耗時(shí)明顯減少，性能瓶頸主要表現(xiàn)在 Scan 階段。因增加 where 條件后多掃描了 grade 列，增加耗時(shí)部分主要消耗在此列的數(shù)據(jù)掃描和 merge 過(guò)程，暫無(wú)較好優(yōu)化方式。
（2）Fact + Dup 測(cè)試
實(shí)時(shí)場(chǎng)景 Fact + Agg/Uniq 和 Profile + Agg 情況差不多，相關(guān)優(yōu)化可結(jié)合上邊結(jié)論。針對(duì)離線場(chǎng)景 Fact + Dup 模型測(cè)試數(shù)據(jù)如下：
測(cè)試所用集群：32C 96G 1TSSD * 5臺(tái)，3個(gè)FE，5個(gè)BE，5個(gè)Broker。1.19.5版本表數(shù)據(jù)：按日期天級(jí)別分區(qū)、3個(gè)分區(qū)有數(shù)據(jù)，每個(gè)分區(qū)3.4億，DUPLICATE KEY(`guid`), DISTRIBUTED BY HASH(`guid`)，其他字段見(jiàn)上邊建表sql。測(cè)試過(guò)程無(wú)數(shù)據(jù)寫(xiě)入。dup表： bucket 5。共15個(gè)tablet，每個(gè)tablet 450M，單副本數(shù)據(jù)分布均勻，總大小6G左右dup_b5表： bucket 20 共60個(gè)tablet，每個(gè)tablet 110M，單副本數(shù)據(jù)分布均勻，總大小6G左右dup_bitmap表：bucket 5。共15個(gè)tablet，每個(gè)tablet 670M，單副本數(shù)據(jù)分布均勻，總大小9G左右，adpos_id、unit_id加bitmap索引測(cè)試數(shù)據(jù)說(shuō)明： Fragment 2/1有5個(gè)instance，下邊均采用ip為211的instance相關(guān)數(shù)據(jù)。 Fragment 0有1個(gè)instance，直接引用結(jié)果。 數(shù)據(jù)均為多次查詢后取相對(duì)合理且耗時(shí)較少的profile信息。
復(fù)制代碼
結(jié)論 1：測(cè)試 1/2 可知查詢耗時(shí)點(diǎn)為：
Scan 過(guò)程[OLAP_SCAN_NODE]。兩階段 group by guid [Fragment2 AGGREGATION_NODE 和 Fragment1 的第一個(gè) AGGREGATION_NODE]。group by 耗時(shí)主要為 HashTable 構(gòu)建時(shí)間含 count(1)結(jié)果更新，本質(zhì)取決于 scan 返回?cái)?shù)據(jù)條數(shù)以及 HashTableSize 大小 。to_bitmap[Fragment1 的第一個(gè) PROJECT_NODE] 和 bitmap_union[Fragment1 的第二個(gè) AGGREGATION_NODE] 算子，總體優(yōu)化思路見(jiàn)上邊測(cè)試結(jié)論。結(jié)論 2：測(cè)試 2/3 分析無(wú)論是否增加 bitmap 索引，查詢都有一定程度的下推到存儲(chǔ)層【simd filter】，增加 bitmap 索引但未應(yīng)用，因區(qū)分度太低而不走 bitmap 索引【過(guò)濾條件枚舉值數(shù)量/總數(shù)據(jù)條數(shù) < 1/1000 ，可通過(guò) bitmap_max_filter_ratio 參數(shù)調(diào)節(jié)】，但執(zhí)行計(jì)劃發(fā)生變化 bitmap 表少了一次 group by agg 操作，就總體查詢耗時(shí)變化不大。同時(shí)增加 bitmap 索引后存儲(chǔ)成本增加，所以不增加 bitmap 索引。結(jié)論 3：[推測(cè)未做測(cè)試] 針對(duì)測(cè)試 1 DUPLICATE KEY(guid), DISTRIBUTED BY HASH(guid) ，如果不用 guid 作為排序列和分桶使數(shù)據(jù)分布均勻那么會(huì)因?yàn)槊總€(gè)節(jié)點(diǎn)都有全部 guid 導(dǎo)致 HashTableSize 基本為現(xiàn)在節(jié)點(diǎn)的 5 倍，進(jìn)而影響查詢耗時(shí)會(huì)更長(zhǎng)。
結(jié)論 4：測(cè)試 4 分析 fragment 1/2 實(shí)際并行度計(jì)算公式如下。適當(dāng)增加 tablet 個(gè)數(shù)【partition、bucket】和 exec instance num 可以加快查詢速度。此加速過(guò)程會(huì)作用于結(jié)論 1 中全部耗時(shí)點(diǎn)。
當(dāng) tablet 個(gè)數(shù)【不含副本】小于 parallel_fragment_exec_instance_num * BE 個(gè)數(shù)時(shí)取 tablet 個(gè)數(shù)當(dāng) tablet 個(gè)數(shù)【不含副本】大于 parallel_fragment_exec_instance_num * BE 個(gè)數(shù)時(shí)取 exec_instance_num * BE 個(gè)數(shù)（3）kv + Agg 測(cè)試此部分主要用于存儲(chǔ)標(biāo)簽枚舉值較少的用戶集合，所以數(shù)據(jù)量并不多，基本 1s 內(nèi)返回。
根據(jù)查詢模板猜測(cè)當(dāng)數(shù)據(jù)量較大時(shí)可能的性能瓶頸點(diǎn)主要：
Scan 過(guò)程[OLAP_SCAN_NODE]：bitmap 對(duì)象反序列化和 SegmentRead 過(guò)程。 可考慮用 enable_bitmap_union_disk_format_with_set 優(yōu)化。bitmap_union 算子，如果按照上邊優(yōu)化方案調(diào)整 bitmap 元素分布就需要在表中增加更多行的數(shù)據(jù)性能未必會(huì)好。需要測(cè)試看數(shù)據(jù)后選擇平衡。**（**4）補(bǔ)充說(shuō)明遇到的坑 ：
查詢 bitmap_or(to_bitmap(字段 A)，to_bitmap(字段 B))，字段 A/B 有空值時(shí)計(jì)算錯(cuò)誤。通過(guò) ifnull(to_bitmap(字段名),bitmap_empty())解決。Uniq 模型多副本排除外部干擾的情況下，5be 節(jié)點(diǎn)、無(wú)分區(qū)、bucket 為 5、副本數(shù)為 2，數(shù)據(jù)分布均勻、tablet 狀態(tài)正常。查詢時(shí)會(huì)出現(xiàn) 4 個(gè) Be 節(jié)點(diǎn)工作，其中一個(gè)掃描 2 個(gè) tablet，BE 接收的 task 分布不均勻的情況導(dǎo)致總體耗時(shí)變長(zhǎng)。已反饋 StarRocks 同學(xué)。增加 where 條件后比全量掃描 Scan 耗時(shí)多不太合理。見(jiàn) profile 類(lèi)型性能測(cè)試結(jié)論 4 和 fact 類(lèi)型性能測(cè)試結(jié)論 1 相關(guān)測(cè)試。應(yīng)該可以通過(guò) simd 過(guò)濾 where 部分?jǐn)?shù)據(jù)，這樣 merge 過(guò)程數(shù)據(jù)量就會(huì)減少可降低查詢耗時(shí)。已反饋 StarRocks 同學(xué)。測(cè)試為排除 be 任務(wù)調(diào)度不均勻的情況造成測(cè)試不準(zhǔn)確，全部采用單副本進(jìn)行。優(yōu)化思路主要是依據(jù)對(duì) StarRocks 及其他 OLAP 技術(shù)的認(rèn)識(shí)，猜測(cè)執(zhí)行過(guò)程思考優(yōu)化方式，結(jié)合具體測(cè)試并查看 explain、profile、manager 監(jiān)控來(lái)驗(yàn)證效果迭代認(rèn)識(shí)以達(dá)到優(yōu)化效果。3、實(shí)時(shí)標(biāo)簽接入實(shí)時(shí)標(biāo)簽接入大概分為一個(gè)規(guī)范和三類(lèi) Flink 工具任務(wù)。規(guī)范指實(shí)時(shí)標(biāo)簽計(jì)算后寫(xiě)入指定 Kafka Topic 規(guī)范。三類(lèi) Flink 工具任務(wù)指 1. cuid->guid mapping 過(guò)程。2.根據(jù)標(biāo)簽類(lèi)型進(jìn)行數(shù)據(jù)分發(fā)。3.各標(biāo)簽數(shù)據(jù)獨(dú)立寫(xiě)入到 StarRocks 表。注意全流程按照 cuid 做 kafka partition 分區(qū)保證順序。
（1）接入規(guī)范標(biāo)簽計(jì)算類(lèi)任務(wù)將標(biāo)簽結(jié)果統(tǒng)一輸出為如下格式，寫(xiě)入指定 kafka topic，并按照 cuid 分區(qū)。
{"header":{"type":"", "cuid":"cuid"}, "body":{"xxx":"xxx",...}}type 表是標(biāo)簽類(lèi)型，全局唯一。sys_offline_cuid、sys_cguid_mapping 為 type 保留字用補(bǔ)數(shù)和新映射數(shù)據(jù)輸出。body 為標(biāo)簽的結(jié)果數(shù)據(jù)，接入過(guò)程不做額外處理。
（2）mapping 過(guò)程mapping 過(guò)程邏輯非常簡(jiǎn)單就是獲取全局自增數(shù)值型 guid 和 cuid 形成一一映射關(guān)系。此過(guò)程大體存在如下幾步 1.查 task LRU 堆外內(nèi)存 2.內(nèi)存不存在查 codis 3.codis 不存在通過(guò)發(fā)號(hào)器取新號(hào) 4.逐層緩存 mapping 信息。
此過(guò)程穩(wěn)定性是整個(gè)系統(tǒng)的關(guān)鍵，結(jié)合作業(yè)幫已有的發(fā)號(hào)器和 codis 能力作為選型的主要參考。利用發(fā)號(hào)器產(chǎn)生全局唯一自增數(shù)值 id guid，利用 codis 存儲(chǔ) cuid 與 guid 關(guān)系。為保證一一映射關(guān)系將 mapping 過(guò)程設(shè)計(jì)為一個(gè) flink 任務(wù)。思考如下：
業(yè)務(wù)實(shí)際情況：
cuid 總量 14 億，日增百萬(wàn)高峰期每小時(shí)新增 20W 每秒 30+。全量實(shí)時(shí)標(biāo)簽數(shù)據(jù)最高 10W qps
理論資源測(cè)算：
發(fā)號(hào)器：默認(rèn)支持 3W qps，數(shù)據(jù)第一次初始化耗時(shí) 13 小時(shí)，之后最高 30+qps 不需額外資源即可滿足需求。codis：14 億 mapping 數(shù)據(jù)存儲(chǔ)約 200G【未考慮 buffer 部分】，12 個(gè) pod 每個(gè) pod 16G 內(nèi)存大約可支持 50W qps。flink 任務(wù)：qps 取決于上游 kafka 寫(xiě)入的標(biāo)簽數(shù)據(jù)量約 10W qps。
計(jì)算由近 N 個(gè)月活躍 cuid mapping 總內(nèi)存占用除以每個(gè) task 500M 到 1G 堆外內(nèi)存得到數(shù)值 A，和上游 kafka 數(shù)據(jù) 10W qps 除以在確定內(nèi)存命中率時(shí)單個(gè) task 可處理的 qps 得到數(shù)值 B，然后可算出 flink 并行度 max(A, B) + 對(duì)業(yè)務(wù)預(yù)期發(fā)展給予一定 buffer 決定。
上游 kafka topic 需按照 cuid 分區(qū)并且分區(qū)數(shù)最好為 flink 并行度的 3 倍以上【取決于后續(xù)新增標(biāo)簽數(shù)據(jù)量】。
任務(wù)重啟后對(duì) codis 產(chǎn)生的最大 qps 小于 10W，如果 flink task LRU 緩存足夠平時(shí) codis qps 最高基本在 30+，就目前 codis 資源配置已滿足需求。
任務(wù)本身只關(guān)注 cuid，除 cuid 以外數(shù)據(jù)可不做解析。
潛在風(fēng)險(xiǎn)思考：
數(shù)據(jù)延遲：因使用場(chǎng)景更多用于觸達(dá)，一定程度的延遲可以接受，較大延遲觸發(fā)報(bào)警暫停觸達(dá)。cuid 臟數(shù)據(jù)，當(dāng) guid 超過(guò) Integer.MAX_VALUE 后 StarRocks bitmap 查詢性能下降。增加 cuid 嚴(yán)格校驗(yàn)邏輯，根據(jù)業(yè)務(wù)實(shí)際情況設(shè)置每天 cuid 增量監(jiān)控，超過(guò)后人工排查，如果 cuid 臟數(shù)據(jù)不多時(shí)可不做處理，因錯(cuò)誤 cuid 并不會(huì)收到觸達(dá)信息。如果 cuid 臟數(shù)據(jù)較多時(shí)需要重置發(fā)號(hào)器位置并恢復(fù)到某一時(shí)間點(diǎn)數(shù)據(jù)后重刷全部標(biāo)簽、人群包數(shù)據(jù)。codis+發(fā)號(hào)器替換為 mysql 主鍵自增，此方案并未經(jīng)過(guò)實(shí)際測(cè)試就目前的場(chǎng)景是可以滿足需求的，弊端在于 flink 任務(wù)重啟后會(huì)對(duì) mysql 造成比較大的沖擊【flink 增量 checkpoint 無(wú)人維護(hù)存儲(chǔ)所以暫未使用】，做好 mysql qps 限流后會(huì)造成一段時(shí)間的數(shù)據(jù)延遲。好處在于任務(wù)實(shí)現(xiàn)簡(jiǎn)化同時(shí)可以避免一些特殊情況導(dǎo)致的同一 cuid 被分配多個(gè) guid 造成數(shù)據(jù)錯(cuò)誤的情況。（3）分發(fā)過(guò)程根據(jù)標(biāo)簽類(lèi)型將 mapping 后的數(shù)據(jù)分發(fā)到獨(dú)立的 kafka topic，方便寫(xiě)入 StarRocks 時(shí)表級(jí)別管控。
（4）入 StarRocks 過(guò)程利用 flink-starrocks-connector 將標(biāo)簽數(shù)據(jù)寫(xiě)入 StarRocks。注意考慮寫(xiě)入頻次、數(shù)據(jù)行數(shù)、數(shù)據(jù)大小等參數(shù)配置。
（5）cuid 離線補(bǔ)充映射實(shí)時(shí)已接入激活標(biāo)簽流數(shù)據(jù)，為防止出現(xiàn)遺漏及第一次初始化數(shù)據(jù)采用小時(shí)級(jí)增量補(bǔ)實(shí)時(shí)未覆蓋的 cuid。
4、離線標(biāo)簽接入常規(guī)標(biāo)簽數(shù)據(jù)當(dāng)計(jì)算完成后可統(tǒng)一寫(xiě)入指定的高表【建表語(yǔ)句見(jiàn)下方】中，以高表為媒介做到標(biāo)簽開(kāi)發(fā)和接入的解耦。帶有修飾、行為類(lèi)標(biāo)簽數(shù)據(jù)可直接利用基礎(chǔ)數(shù)倉(cāng)表和標(biāo)簽源數(shù)據(jù)信息完成自動(dòng)接入。
（1）接入規(guī)范離線接入大概分為兩類(lèi)數(shù)據(jù)源，高表接入、數(shù)倉(cāng)行為數(shù)據(jù)接入。
高表接入
標(biāo)簽計(jì)算后寫(xiě)入高表【已按 cuid 排重】,tagkv 為 map 結(jié)構(gòu)，其中 key 為標(biāo)簽名字。高表中如果存增量數(shù)據(jù)數(shù)據(jù)接入走增量邏輯，如果為全量標(biāo)簽走全量接入邏輯。hive 建表 sqlcreate table picasso_all(cuid string comment '同用戶唯一標(biāo)識(shí)體系下的唯一 id',
tagkv Map<string, string> comment '組合標(biāo)簽 kv 數(shù)據(jù)'
)
partitioned by (dt string, tagk string)
stored as parquet
數(shù)倉(cāng)行為數(shù)據(jù)接入：
只能應(yīng)用于單表且需包含 cuid（2）接入步驟任務(wù)入口：通過(guò)畫(huà)像服務(wù)接口獲取需要導(dǎo)入的目標(biāo)表名字，然后通過(guò)調(diào)度系統(tǒng) api 創(chuàng)建并行接入任務(wù)，以下為每個(gè)任務(wù)的執(zhí)行邏輯 。狀態(tài)檢查：根據(jù)目標(biāo)表名通過(guò)畫(huà)像服務(wù)接口獲取需要導(dǎo)入此表標(biāo)簽對(duì)應(yīng)的數(shù)據(jù)來(lái)源信息、hive 字段映射等信息【目前僅支持 hive 數(shù)據(jù)源】，檢查依賴數(shù)據(jù)狀態(tài)。數(shù)據(jù)校驗(yàn)：以元數(shù)據(jù)配置規(guī)則為標(biāo)準(zhǔn)校驗(yàn)標(biāo)簽數(shù)據(jù)，例如標(biāo)簽枚舉值合理性、數(shù)值型標(biāo)簽取值范圍、空值率等。數(shù)據(jù)組裝：根據(jù)不同業(yè)務(wù)場(chǎng)景利用 insert overwrite directory select 組裝數(shù)據(jù)【場(chǎng)景匹配 sql 模板、補(bǔ)充 guid 等】并寫(xiě)入 cos/hdfs 等存儲(chǔ)。數(shù)據(jù)導(dǎo)入：建表/分區(qū)，利用 StarRocks Broker Load 方式導(dǎo)入數(shù)據(jù)。原子切換：調(diào)用畫(huà)像服務(wù)接口，接口內(nèi)完成表相關(guān)字段校驗(yàn)、與線上數(shù)據(jù)交換臨時(shí)分區(qū)/表，歸檔臨時(shí)分區(qū)/表用于回滾恢復(fù)現(xiàn)狀：刪除此過(guò)程中產(chǎn)生的臨時(shí)文件。（3）數(shù)據(jù)組裝四、未來(lái)規(guī)劃標(biāo)簽內(nèi)容還需持續(xù)迭代，此部分主要為業(yè)務(wù)需求驅(qū)動(dòng)。單用戶規(guī)則判定能力支持，用于解決例如某種活動(dòng)、權(quán)益等參與資質(zhì)判定。標(biāo)簽數(shù)據(jù)多表冗余，根據(jù)人群圈選 DSL 支持自動(dòng)化路由查詢，以加快人群數(shù)計(jì)算速度。實(shí)時(shí)、離線標(biāo)簽接入目前是通過(guò)通用化工具實(shí)現(xiàn)，可考慮和調(diào)度系統(tǒng)、數(shù)據(jù)地圖系統(tǒng)打通進(jìn)一步打通，實(shí)現(xiàn)標(biāo)簽生產(chǎn)、接入平臺(tái)化。標(biāo)簽準(zhǔn)確是核心，為保證準(zhǔn)確性還需要豐富標(biāo)簽接入過(guò)程的數(shù)據(jù)校驗(yàn)部分，支持更多數(shù)據(jù)校驗(yàn)方式比如分布同環(huán)比等。以上就是關(guān)于pos機(jī)素材設(shè)計(jì),作業(yè)幫基于 StarRocks 畫(huà)像系統(tǒng)的設(shè)計(jì)及優(yōu)化實(shí)踐的知識(shí)，后面我們會(huì)繼續(xù)為大家整理關(guān)于pos機(jī)素材設(shè)計(jì)的知識(shí)，希望能夠幫助到大家！
