精品亲子伦一区二区三区小说国产,亚洲第一狼人社区,天天艹在线观看,国产精品4区,国产又爽又黄免费网站打游戏 ,国产精品1000,免费一级毛片,午夜久久

背景介紹

涅槃選品是京東零售內(nèi)的戰(zhàn)略級(jí)bigboss項(xiàng)目，項(xiàng)目主要致力于構(gòu)建商品底層能力，打通提報(bào)、投放流程，實(shí)現(xiàn)選品的線(xiàn)上化、規(guī)則化與智能化；通過(guò)多方協(xié)作盤(pán)貨，充分表達(dá)營(yíng)銷(xiāo)、品類(lèi)、運(yùn)營(yíng)/采銷(xiāo)等多方意志。

業(yè)務(wù)上的多樣化需求，導(dǎo)致在項(xiàng)目初期面臨以下眾多技術(shù)難點(diǎn)與挑戰(zhàn)。

面向研發(fā)排障的問(wèn)題解決

為解決以上技術(shù)難點(diǎn)，京東零售整體設(shè)計(jì)了一套這樣的技術(shù)方案：

技術(shù)方案在數(shù)據(jù)存儲(chǔ)查詢(xún)上主要分成三個(gè)大模塊：

模塊一：ClickHouse與Elasticsearch存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)模塊；

模塊二：ClickHouse數(shù)據(jù)推送與校驗(yàn)?zāi)K；

模塊三：Elasticsearch數(shù)據(jù)推送與校驗(yàn)?zāi)K。

一、具體技術(shù)方案

主要解決的問(wèn)題分為三點(diǎn)，第一點(diǎn)是解決快速篩選、快速多維統(tǒng)計(jì)查詢(xún)兩項(xiàng)不可兼得的問(wèn)題，第二點(diǎn)是解決海量商品特征數(shù)據(jù)導(dǎo)入效率低的問(wèn)題，第三點(diǎn)是解決海量商品特征數(shù)據(jù)占用存儲(chǔ)資源較高的問(wèn)題。本場(chǎng)景是一個(gè)商品規(guī)則化選品平臺(tái)的項(xiàng)目，電商平臺(tái)上有數(shù)百億的商品，每一個(gè)商品都具有不同的特征數(shù)據(jù)，平臺(tái)會(huì)持續(xù)發(fā)布一些營(yíng)銷(xiāo)活動(dòng)，店鋪可以提報(bào)部分商品參與這些營(yíng)銷(xiāo)活動(dòng)，以達(dá)到平臺(tái)營(yíng)銷(xiāo)、商家賣(mài)貨的目的，而一個(gè)商家想要對(duì)本店鋪的商品進(jìn)行精準(zhǔn)提報(bào)的話(huà)，就需要根據(jù)一定的規(guī)則選出目標(biāo)商品，并且期望這些商品提報(bào)后能收到很好的效果；為了滿(mǎn)足這一需求，會(huì)計(jì)算出全量商品的特征數(shù)據(jù)，全量商品數(shù)據(jù)量大概在百億級(jí)別，通過(guò)前期的一些粗過(guò)濾，排除掉那部分很明顯不適合參與活動(dòng)的商品后，最終生成一個(gè)大寬表，包含數(shù)億商品和數(shù)百個(gè)標(biāo)簽。

一般的做法是將數(shù)據(jù)直接導(dǎo)入數(shù)據(jù)庫(kù)，或者是對(duì)數(shù)據(jù)進(jìn)行一些預(yù)處理后導(dǎo)入數(shù)據(jù)庫(kù)，提供給到檢索平臺(tái)進(jìn)行查詢(xún)，但是每種數(shù)據(jù)庫(kù)都有其專(zhuān)長(zhǎng)，幾乎沒(méi)有一種數(shù)據(jù)庫(kù)在同時(shí)滿(mǎn)足快速簡(jiǎn)單篩選的同時(shí)還能滿(mǎn)足快速多維統(tǒng)計(jì)的查詢(xún)需求；另外，大量的篩選任務(wù)需要?dú)v史數(shù)據(jù)，隨著項(xiàng)目周期增長(zhǎng)，歷史數(shù)據(jù)占用大量存儲(chǔ)資源的同時(shí)，還會(huì)影響整體查詢(xún)效率。

本文提出Elasticsearch結(jié)合ClickHouse的方法，在存儲(chǔ)上提出快照表的概念，基于Spark對(duì)Elasticsearch和ClickHouse進(jìn)行離線(xiàn)數(shù)據(jù)導(dǎo)入和校驗(yàn)的方案，在僅保存兩份全量最新數(shù)據(jù)的情況下，大幅降低了存儲(chǔ)資源占用，兼顧了快速篩選和多維度統(tǒng)計(jì)查詢(xún)，同時(shí)又能快速導(dǎo)入商品特征數(shù)據(jù)，極大的提高了數(shù)據(jù)的更新時(shí)效。

具體方法如下：

1、ClickHouse與Elasticsearch存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)，具體方案細(xì)節(jié)如下：

a、存儲(chǔ)上采用ClickHouse結(jié)合Elasticsearch的方案，主要是為了兼顧快速篩選（多基于Elasticsearch進(jìn)行）的同時(shí)，還能進(jìn)行快速多維統(tǒng)計(jì)查詢(xún)（多基于ClickHouse進(jìn)行），雙存儲(chǔ)引擎首先會(huì)遇到一個(gè)問(wèn)題，就是兩份數(shù)據(jù)的一致性問(wèn)題，本發(fā)明通過(guò)在ClickHouse和Elasticsearch數(shù)據(jù)導(dǎo)入階段進(jìn)行數(shù)據(jù)驗(yàn)證來(lái)保證數(shù)據(jù)的一致性；

b、檢索平臺(tái)在進(jìn)行數(shù)據(jù)查詢(xún)的時(shí)候，在時(shí)間范圍上分為兩種，一種是新任務(wù)的實(shí)時(shí)查詢(xún)，針對(duì)這部分任務(wù)，本發(fā)明在ClickHouse和Elasticsearch中分別建立一張表，ClickHouse每天生成一張新表，該表包含每個(gè)分片上的分布式表和本地表，分布式表用于進(jìn)行數(shù)據(jù)查詢(xún)，本地表設(shè)計(jì)為ReplicatedReplacingMergeTree引擎，用于數(shù)據(jù)導(dǎo)入，每日最新數(shù)據(jù)導(dǎo)入完成并數(shù)據(jù)校驗(yàn)通過(guò)后會(huì)清除該表的歷史數(shù)據(jù)；Elasticsearch每天根據(jù)商品的類(lèi)目信息分類(lèi)，生成一批索引，這里之所以不用一個(gè)索引，是因?yàn)橐粋€(gè)索引中數(shù)據(jù)量過(guò)大會(huì)影響查詢(xún)效率，每日最新數(shù)據(jù)導(dǎo)入完成并數(shù)據(jù)校驗(yàn)通過(guò)后會(huì)清除歷史索引的數(shù)據(jù)；

另一種是歷史任務(wù)的實(shí)時(shí)查詢(xún)，這部分查詢(xún)需要用到歷史數(shù)據(jù)，針對(duì)這類(lèi)查詢(xún)，本發(fā)明設(shè)計(jì)出一套快照表的概念，具體方案細(xì)節(jié)是：每日凌晨會(huì)針對(duì)前一天新建的任務(wù)進(jìn)行一次遍歷查詢(xún)，獲取到具體的商品id后，在數(shù)據(jù)倉(cāng)庫(kù)中進(jìn)行加工，最終獲取到前一天新建任務(wù)的全量商品特征數(shù)據(jù)，這部分?jǐn)?shù)據(jù)不會(huì)再發(fā)生更新，是前一天新建任務(wù)的一個(gè)快照，在ClickHouse和Elasticsearch中分別建立一張快照表進(jìn)行存儲(chǔ)，與每日存儲(chǔ)最新數(shù)據(jù)不同的是，Elasticsearch中的快照索引是根據(jù)快照數(shù)據(jù)中的任務(wù)信息生成的一批索引，不再是根據(jù)商品的類(lèi)目信息，因?yàn)楹罄m(xù)所有針對(duì)快照數(shù)據(jù)的查詢(xún)，均是在一個(gè)任務(wù)范圍內(nèi)，這樣設(shè)計(jì)能實(shí)現(xiàn)能快的查詢(xún)效率。

c、除了上述兩種時(shí)間范圍上的查詢(xún)，本場(chǎng)景還存在一種二次選品的實(shí)時(shí)查詢(xún)，二次選品是指在歷史任務(wù)的基礎(chǔ)之上，再次進(jìn)行簡(jiǎn)單的篩選，獲取目標(biāo)商品，這種選品場(chǎng)景比較特殊的是要用到一部分實(shí)時(shí)標(biāo)簽，針對(duì)這部分實(shí)時(shí)標(biāo)簽的存儲(chǔ)設(shè)計(jì)，本發(fā)明采用了Elasticsearch的父子文檔；具體方案是：每天在Elasticsearch中根據(jù)任務(wù)信息生成一批索引（架構(gòu)圖中的回流表），存儲(chǔ)歷史任務(wù)的商品特征數(shù)據(jù)，與快照不同的是，這批索引每天存儲(chǔ)尚在有效期內(nèi)的全量歷史數(shù)據(jù)，并且索引采用的是父子文檔結(jié)構(gòu)，每天離線(xiàn)數(shù)據(jù)導(dǎo)入完成并數(shù)據(jù)校驗(yàn)通過(guò)后會(huì)清除歷史索引數(shù)據(jù)，離線(xiàn)任務(wù)數(shù)據(jù)導(dǎo)入索引父文檔，Structured-streaming任務(wù)會(huì)實(shí)時(shí)對(duì)子文檔中的標(biāo)簽進(jìn)行更新，這么設(shè)計(jì)，是因?yàn)楦肝臋n中存在數(shù)百個(gè)標(biāo)簽，每次更新效率低下，將僅有的幾個(gè)實(shí)時(shí)標(biāo)簽放入子文檔中更新，效率會(huì)比較高。

2、ClickHouse數(shù)據(jù)推送與校驗(yàn)

ClickHouse數(shù)據(jù)推送與校驗(yàn)架構(gòu)流程圖如下：

具體方案實(shí)施細(xì)節(jié)如下：

a、每日在數(shù)據(jù)倉(cāng)庫(kù)中對(duì)商品、用戶(hù)、流量等數(shù)據(jù)進(jìn)行加工融合，生成所需商品的特征數(shù)據(jù)，最終產(chǎn)生一張?zhí)卣鲾?shù)據(jù)寬表；

b、啟動(dòng)Spark任務(wù)，首先讀取到上一步產(chǎn)生的數(shù)據(jù)寬表，對(duì)數(shù)據(jù)進(jìn)行處理，主要包含：根據(jù)配置文件中的ClickHouse表字段類(lèi)型，對(duì)每個(gè)標(biāo)簽字段進(jìn)行類(lèi)型轉(zhuǎn)換，對(duì)空值進(jìn)行填充處理（ClickHouse表默認(rèn)不能存儲(chǔ)空值），對(duì)需要存儲(chǔ)為Array、Nested等結(jié)構(gòu)的字段進(jìn)行特殊處理、格式轉(zhuǎn)換等；

c、Spark任務(wù)從配置文件中獲取到需要在ClickHouse中創(chuàng)建的表元數(shù)據(jù)信息，在ClickHouse集群中首先進(jìn)行檢測(cè)，查驗(yàn)最新表是否存在（分布式表和本地表是否都存在），如果存在則先進(jìn)行數(shù)據(jù)刪除（清除當(dāng)天的誤寫(xiě)的錯(cuò)誤數(shù)據(jù)，不是歷史數(shù)據(jù)），然后校驗(yàn)當(dāng)前表的結(jié)構(gòu)和配置文件是否一致，不一致則進(jìn)行字段刪除、字段增加等操作，保證表結(jié)構(gòu)和配置文件一致；如果表不存在，則新建表，首先根據(jù)配置文件新建ClickHouse集群每個(gè)節(jié)點(diǎn)上的本地表，本地表引擎為ReplicatedReplacingMergeTree，而后根據(jù)本地表新建分布式表，本地表引擎設(shè)計(jì)為ReplicatedReplacingMergeTree主要有以下目的：一是利用Zookeeper的能力，保證ClickHouse每個(gè)分片中的副本間數(shù)據(jù)一致，這樣數(shù)據(jù)導(dǎo)入只需要導(dǎo)入每個(gè)分片中的一個(gè)節(jié)點(diǎn)即可；二是利用ReplacingMergeTree引擎的能力，在數(shù)據(jù)導(dǎo)入完成后，進(jìn)行optimize操作，來(lái)保證每個(gè)節(jié)點(diǎn)上沒(méi)有重復(fù)數(shù)據(jù)；

d、對(duì)ClickHouse的表進(jìn)行新建或更新完成后，Spark對(duì)讀取到的數(shù)據(jù)，依據(jù)數(shù)據(jù)主鍵字段進(jìn)行數(shù)據(jù)分配（對(duì)主鍵進(jìn)行hash，再對(duì)ClickHouse的分片數(shù)量進(jìn)行取模），以保證每個(gè)分片上的數(shù)據(jù)具有相同的規(guī)則，然后對(duì)分配好的數(shù)據(jù)進(jìn)行repartition操作，將數(shù)據(jù)集控制到集群能接受的并行度，最后在Spark的Driver端多線(xiàn)程并行啟動(dòng)數(shù)據(jù)推送程序，利用JDBC的PreparedStatement按一定批次將數(shù)據(jù)寫(xiě)入ClickHouse表，以降低Spark對(duì)ClickHouse的請(qǐng)求頻次；

e、在每個(gè)分片上的數(shù)據(jù)推送完成后，Spark會(huì)按照既定的規(guī)則對(duì)ClickHouse中的數(shù)據(jù)進(jìn)行驗(yàn)證，本發(fā)明以商品的類(lèi)目維度進(jìn)行校驗(yàn)，即查詢(xún)ClickHouse中所有類(lèi)目下的數(shù)據(jù)量，和Spark從倉(cāng)庫(kù)中獲取到的數(shù)據(jù)量進(jìn)行校驗(yàn)，校驗(yàn)過(guò)程中會(huì)出現(xiàn)以下三種情況：

一是ClickHouse與倉(cāng)庫(kù)中統(tǒng)計(jì)到的數(shù)據(jù)量一致，那么當(dāng)前類(lèi)目數(shù)據(jù)驗(yàn)證通過(guò)；

二是ClickHouse中統(tǒng)計(jì)到的數(shù)據(jù)量要大于倉(cāng)庫(kù)中統(tǒng)計(jì)到的數(shù)據(jù)量，這時(shí)對(duì)當(dāng)前分片的本地表進(jìn)行optimize操作，合并數(shù)據(jù)后，再進(jìn)行數(shù)據(jù)驗(yàn)證；

三是ClickHouse中統(tǒng)計(jì)到的數(shù)據(jù)量要小于倉(cāng)庫(kù)中統(tǒng)計(jì)到的數(shù)據(jù)量，這時(shí)對(duì)當(dāng)前分片本地表中當(dāng)前校驗(yàn)類(lèi)目的數(shù)據(jù)進(jìn)行重新推送，推送完成后再進(jìn)行數(shù)據(jù)校驗(yàn)；

采取分維度的方式進(jìn)行數(shù)據(jù)校驗(yàn)，能便于發(fā)現(xiàn)數(shù)據(jù)導(dǎo)入中的出現(xiàn)問(wèn)題、及時(shí)高效的完成數(shù)據(jù)導(dǎo)入和校驗(yàn)；在整體數(shù)據(jù)校驗(yàn)通過(guò)后，Spark任務(wù)會(huì)將當(dāng)前的時(shí)間版本回傳給數(shù)據(jù)檢索平臺(tái)，告知ClickHouse中的最新數(shù)據(jù)已可用，然后對(duì)前天的歷史數(shù)據(jù)進(jìn)行清理，降低整體的存儲(chǔ)資源占用。

該方案同樣適用于快照數(shù)據(jù)、二次選品等數(shù)據(jù)的導(dǎo)入，僅是數(shù)據(jù)清理策略上不同。

3、Elasticsearch數(shù)據(jù)推送與校驗(yàn)

Elasticsearch數(shù)據(jù)推送與校驗(yàn)架構(gòu)流程圖如下：

具體方案實(shí)施細(xì)節(jié)如下：

a、每日在數(shù)據(jù)倉(cāng)庫(kù)中對(duì)商品、用戶(hù)、流量等數(shù)據(jù)進(jìn)行加工融合，生成所需商品的特征數(shù)據(jù)，最終產(chǎn)生一張?zhí)卣鲾?shù)據(jù)寬表（該步驟與ClickHouse數(shù)據(jù)推送與校驗(yàn)中的第一步共用）；

b、啟動(dòng)Spark任務(wù)，首先讀取到上一步產(chǎn)生的數(shù)據(jù)寬表，對(duì)數(shù)據(jù)進(jìn)行處理，主要包含：根據(jù)配置文件中的Elasticsearch索引字段類(lèi)型，對(duì)每個(gè)標(biāo)簽字段進(jìn)行類(lèi)型轉(zhuǎn)換，用ClickHouse導(dǎo)入模塊中相同的方式對(duì)空值進(jìn)行填充處理（保證與ClickHouse中的數(shù)據(jù)一致性），對(duì)需要存儲(chǔ)為Array、Nested等結(jié)構(gòu)的字段進(jìn)行特殊處理、格式轉(zhuǎn)換，當(dāng)推送的索引為父子文檔時(shí)，還需要對(duì)數(shù)據(jù)集進(jìn)行重組，以滿(mǎn)足父子文檔的數(shù)據(jù)結(jié)構(gòu)；

c、Spark任務(wù)對(duì)數(shù)據(jù)集進(jìn)行數(shù)據(jù)分維度統(tǒng)計(jì)，以便于創(chuàng)建一系列的索引，本發(fā)明是對(duì)數(shù)據(jù)集在商品類(lèi)目維度上進(jìn)行統(tǒng)計(jì)，得到每個(gè)類(lèi)目的數(shù)據(jù)量后，依據(jù)當(dāng)前Elasticsearch索引最新的配置信息，在Elasticsearch集群中創(chuàng)建既定數(shù)量的索引，再依據(jù)一定的算法邏輯，將每個(gè)類(lèi)目分配到其中的一個(gè)索引上，保證同一類(lèi)目的商品數(shù)據(jù)一定處于同一個(gè)索引中，而且每個(gè)索引的數(shù)據(jù)量盡可能的均勻；這樣設(shè)計(jì)的目的是為了避免一個(gè)索引中數(shù)據(jù)量過(guò)大影響查詢(xún)效率，同時(shí)能一定程度上提升整體的查詢(xún)并發(fā)性能，而且該方案可依據(jù)業(yè)務(wù)體量進(jìn)行橫向擴(kuò)充，比如增加集群數(shù)量；

d、從上一步中獲取到了數(shù)據(jù)集每個(gè)類(lèi)目的Elasticsearch索引歸屬信息，依據(jù)該關(guān)系，Spark任務(wù)對(duì)全量數(shù)據(jù)集進(jìn)行分桶處理，每一個(gè)數(shù)據(jù)桶中的數(shù)據(jù)全部屬于同一個(gè)Elasticsearch索引，分桶完成后基于Elasticsearch的Bulkprocessor方法，將數(shù)據(jù)批量的寫(xiě)入Elasticsearch，整體的寫(xiě)入邏輯是：以數(shù)據(jù)集的主鍵為Elasticsearch索引的_id，多集群的索引并行寫(xiě)、同集群的索引串行寫(xiě)；采用這種方式能避免同一個(gè)Elasticsearch集群存在多個(gè)寫(xiě)入點(diǎn)，導(dǎo)致大量reject，致使數(shù)據(jù)寫(xiě)入效率低下的問(wèn)題，而多集群不存在共用寫(xiě)入點(diǎn)的問(wèn)題，可以采用并行寫(xiě)來(lái)提升寫(xiě)入效率，同時(shí)以主鍵為_(kāi)id，能避免數(shù)據(jù)寫(xiě)入重復(fù)的問(wèn)題；

e、在每個(gè)索引的數(shù)據(jù)推送完成后，Spark會(huì)按照既定的規(guī)則對(duì)Elasticsearch中的數(shù)據(jù)進(jìn)行驗(yàn)證，本發(fā)明以商品的類(lèi)目維度進(jìn)行校驗(yàn)，即查詢(xún)Elasticsearch集群每個(gè)索引中所有類(lèi)目下的數(shù)據(jù)量，和Spark從倉(cāng)庫(kù)中獲取到的數(shù)據(jù)量進(jìn)行校驗(yàn)，校驗(yàn)過(guò)程中會(huì)出現(xiàn)以下兩種情況：

一是Elasticsearch與倉(cāng)庫(kù)中統(tǒng)計(jì)到的數(shù)據(jù)量一致，那么當(dāng)前類(lèi)目數(shù)據(jù)驗(yàn)證通過(guò)；

二是Elasticsearch中統(tǒng)計(jì)到的數(shù)據(jù)量要小于倉(cāng)庫(kù)中統(tǒng)計(jì)到的數(shù)據(jù)量，這時(shí)對(duì)當(dāng)前類(lèi)目的數(shù)據(jù)進(jìn)行重復(fù)導(dǎo)入，數(shù)據(jù)導(dǎo)入完成后，再進(jìn)行數(shù)據(jù)驗(yàn)證；

采取分維度的方式進(jìn)行數(shù)據(jù)校驗(yàn)，能便于發(fā)現(xiàn)數(shù)據(jù)導(dǎo)入中的出現(xiàn)問(wèn)題、及時(shí)高效的完成數(shù)據(jù)導(dǎo)入和校驗(yàn)；在整體數(shù)據(jù)校驗(yàn)通過(guò)后，Spark任務(wù)會(huì)將當(dāng)前的時(shí)間版本回傳給數(shù)據(jù)檢索平臺(tái)，告知Elasticsearch中的最新數(shù)據(jù)已可用，然后對(duì)前天的歷史數(shù)據(jù)進(jìn)行清理，降低整體的存儲(chǔ)資源占用。

該方案同樣適用于快照數(shù)據(jù)、二次選品等數(shù)據(jù)的導(dǎo)入，僅是數(shù)據(jù)清理策略上不同。

二、技術(shù)方案實(shí)施流程

具體流程如下：

三、測(cè)試結(jié)論

目前全量商品特征數(shù)據(jù)超過(guò)10億，共490個(gè)標(biāo)簽，每天離線(xiàn)導(dǎo)入ClickHouse用時(shí)40min（40個(gè)分片），相較之前直寫(xiě)分布式表的方式，導(dǎo)入耗時(shí)平均降低80%；每天離線(xiàn)導(dǎo)入Elasticsearch用時(shí)2小時(shí)（單集群，可橫向擴(kuò)充），相較單索引寫(xiě)入的方式（偶爾會(huì)寫(xiě)不進(jìn)去），導(dǎo)入耗時(shí)平均降低60%；在支持簡(jiǎn)單篩選和上下鉆、top、窗口查詢(xún)、多維度排序、關(guān)聯(lián)聚合等復(fù)雜查詢(xún)的同時(shí)，線(xiàn)上檢索平臺(tái)qps最高能達(dá)到300左右，tp99在毫秒級(jí)別；相較普通做法，本方案的方法將存儲(chǔ)資源降低了60%-70%。

未來(lái)展望

該技術(shù)方案自項(xiàng)目上線(xiàn)以來(lái)，支撐了多場(chǎng)景、多業(yè)務(wù)方、多樣化的選品流程，為整個(gè)選品的規(guī)則化、線(xiàn)上化、智能化提供了數(shù)據(jù)和索引的底層能力，雖然該方案滿(mǎn)足了目前多方業(yè)務(wù)的切實(shí)需求，但是仍然存在很多優(yōu)化點(diǎn)、擴(kuò)展點(diǎn)待改進(jìn)，具體如下：

一、雙引擎的設(shè)計(jì)，雖然使目前這一套復(fù)雜的選品平臺(tái)能夠在巨量級(jí)數(shù)據(jù)（10億實(shí)體、600+標(biāo)簽）上兼顧了快速篩選和復(fù)雜計(jì)算的能力，但是也會(huì)導(dǎo)致一個(gè)比較致命的問(wèn)題，那就是雙引擎數(shù)據(jù)一致性的問(wèn)題，目前采取的方式是采取同一套默認(rèn)值，數(shù)據(jù)更新后進(jìn)行校驗(yàn)，但是每天校驗(yàn)的時(shí)間一定程度上影響了整體的數(shù)據(jù)更新時(shí)效，因此，這一塊是后續(xù)需要去優(yōu)化的一個(gè)比較重要的點(diǎn)。

二、目前整套系統(tǒng)600+標(biāo)簽，99%都是離線(xiàn)標(biāo)簽，實(shí)時(shí)標(biāo)簽僅有個(gè)位數(shù)，但是一個(gè)好的選品平臺(tái)，肯定需要大量實(shí)時(shí)標(biāo)簽的加持；實(shí)時(shí)標(biāo)簽的寫(xiě)入、更新、索引建立，和離線(xiàn)標(biāo)簽比較起來(lái)有很大的不同，對(duì)上述所提到的數(shù)據(jù)一致性也會(huì)帶來(lái)比較大的挑戰(zhàn)，甚至是影響整個(gè)數(shù)據(jù)索引底層的架構(gòu)設(shè)計(jì)。

-End-

京東云ClickHouse和ES雙引擎設(shè)計(jì)在零售選品中的應(yīng)用實(shí)踐

一、具體技術(shù)方案

1、ClickHouse與Elasticsearch存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)，具體方案細(xì)節(jié)如下：

2、ClickHouse數(shù)據(jù)推送與校驗(yàn)

3、Elasticsearch數(shù)據(jù)推送與校驗(yàn)

二、技術(shù)方案實(shí)施流程

三、測(cè)試結(jié)論