一、銷售數(shù)倉(cāng)介紹

首先介紹下小米銷售數(shù)倉(cāng)，包括發(fā)展歷程、銷售數(shù)倉(cāng)定義、數(shù)據(jù)獲取使用、銷售數(shù)倉(cāng)的內(nèi)容和規(guī)模。

在 2019 年前，小米的中國(guó)區(qū)、國(guó)際部等業(yè)務(wù)數(shù)據(jù)團(tuán)隊(duì)在進(jìn)行獨(dú)立的數(shù)倉(cāng)建設(shè)，這個(gè)時(shí)期是煙囪式的開發(fā)。隨著業(yè)務(wù)飛速發(fā)展，在集團(tuán)技術(shù)委 ABC（AI、Big data、Cloud）策略的指導(dǎo)下，開始建設(shè)統(tǒng)一的銷售數(shù)倉(cāng)。在 2020 年，完成了離線銷售數(shù)倉(cāng)的建設(shè)，同時(shí)在籌備實(shí)時(shí)數(shù)倉(cāng)的建設(shè)。2021 年，實(shí)時(shí)數(shù)倉(cāng)建設(shè)完畢，隨著后續(xù)的業(yè)務(wù)和技術(shù)升級(jí)，進(jìn)入了迭代優(yōu)化和數(shù)據(jù)應(yīng)用階段。

小米的銷售數(shù)倉(cāng)整體上就是存放整個(gè)公司銷售數(shù)據(jù)的倉(cāng)庫(kù)，包括了訂單數(shù)據(jù)、物流數(shù)據(jù)、門店數(shù)據(jù)、用戶行為數(shù)據(jù)及商品數(shù)據(jù)，并按照維度建模和規(guī)范進(jìn)行建設(shè)的高效數(shù)據(jù)集合。

上圖是銷售數(shù)倉(cāng)的場(chǎng)景圖，數(shù)據(jù)主要來自于兩個(gè)部分，一是在線業(yè)務(wù)數(shù)據(jù)，主要是訂單系統(tǒng)、商品中心（小米的所有商品進(jìn)行管理的地方）、門店系統(tǒng)（線下門店進(jìn)行管理的地方）、售后系統(tǒng)和進(jìn)銷存系統(tǒng)。同時(shí)也有一些日志采集數(shù)據(jù)，經(jīng)過銷售數(shù)倉(cāng)的處理，劃分為不同的主題進(jìn)行建設(shè)。銷售數(shù)倉(cāng)整體會(huì)進(jìn)行元數(shù)據(jù)管理，目標(biāo)是做到全域的元數(shù)據(jù)管理。最上層是數(shù)據(jù)應(yīng)用層，包括集團(tuán)數(shù)據(jù)看板、三區(qū)運(yùn)營(yíng)的看板、實(shí)時(shí)大屏、大促戰(zhàn)報(bào)和數(shù)據(jù)挖掘。

銷售數(shù)倉(cāng)數(shù)據(jù)的獲取主要通過以下三種方式：

• 用戶通過數(shù)據(jù)地圖進(jìn)行查詢，數(shù)據(jù)地圖中會(huì)顯示集群、存儲(chǔ)介質(zhì)、表詳情、血緣等。
• 通過數(shù)據(jù)工場(chǎng)，可以進(jìn)行數(shù)據(jù)查詢以及任務(wù)的開發(fā)部署等。
• 通過數(shù)據(jù)百科，對(duì)數(shù)據(jù)指標(biāo)進(jìn)行管理錄入和使用。

數(shù)倉(cāng)的使用形式有多種，包括傳統(tǒng)的離線 Hive、數(shù)據(jù)湖 Iceberg、實(shí)時(shí)消息隊(duì)列 Talos、OLAP 引擎、即時(shí)查詢等。

銷售數(shù)倉(cāng)的目標(biāo)是為公司提供準(zhǔn)確好用的銷售數(shù)據(jù)。在區(qū)域方面，包含全球的業(yè)務(wù)；在品類方面，包含手機(jī)、筆記本、大家電、生態(tài)鏈等；在渠道方面，包含小米網(wǎng)、商城、米家、三方平臺(tái)等。我們的日單量在千萬級(jí)別，每天會(huì)處理上億條日志數(shù)據(jù)。

二、數(shù)倉(cāng)建設(shè)理論

在進(jìn)行數(shù)倉(cāng)建設(shè)時(shí)，首先是梳理業(yè)務(wù)，找到核心業(yè)務(wù)邏輯，對(duì)業(yè)務(wù)過程進(jìn)行認(rèn)識(shí)和理解，并在數(shù)據(jù)庫(kù)中找到相關(guān)的數(shù)據(jù)表。在此基礎(chǔ)上，站在更高維度對(duì)業(yè)務(wù)流和數(shù)據(jù)流進(jìn)行匯總和分類，劃分好主題域，便于后續(xù)的管理。然后進(jìn)行事實(shí)表和維表的梳理，借助數(shù)據(jù)百科進(jìn)行指標(biāo)梳理，以具體的業(yè)務(wù)為核心，指標(biāo)與維度同等重要。接下來對(duì)數(shù)倉(cāng)進(jìn)行建模，按照維度建模方式組織數(shù)據(jù)，在這個(gè)過程中需要注意分層和規(guī)范。最后就是物理實(shí)現(xiàn)，這個(gè)環(huán)節(jié)重點(diǎn)關(guān)注的是開發(fā)規(guī)范、交付物、質(zhì)量等

接下來介紹數(shù)倉(cāng)分層方式。數(shù)倉(cāng)分層最底層是 ODS 層，它是貼源數(shù)據(jù)，與業(yè)務(wù)數(shù)據(jù)保持一致。在 ODS 之上是 DW 層，DW 層可以細(xì)分為兩層。一層是 DWD 基礎(chǔ)數(shù)據(jù)，主要做清洗和規(guī)范化，不對(duì)數(shù)倉(cāng)團(tuán)隊(duì)外部開放使用。另一層是 DWM 層通用數(shù)據(jù)。基于 DWD 的數(shù)據(jù)做關(guān)聯(lián)和聚合，會(huì)將核心的邏輯實(shí)現(xiàn)放在這一層，用于提升公共數(shù)據(jù)的復(fù)用性，可以開放給外部團(tuán)隊(duì)使用。數(shù)倉(cāng)中還有 DIM 層（維度層），DM 層（寬表層），ADS 層（應(yīng)用數(shù)據(jù)層），以及 TMP 層（存放臨時(shí)表）

在數(shù)倉(cāng)建模過程中，需要遵循以下一些基本的建模原則：高內(nèi)聚低耦合，公共邏輯下層，成本與性能平衡、一致性、數(shù)據(jù)可回滾。

1、高內(nèi)聚低耦合

將業(yè)務(wù)相近的數(shù)據(jù)設(shè)計(jì)為一個(gè)邏輯模型或者物理模型。例如訂單有很多來源，包括小米商城、小米網(wǎng)、有品商城以及三方數(shù)據(jù)等。在 DW 層會(huì)整合為同一個(gè)訂單表，同時(shí)會(huì)對(duì)一些缺失字段進(jìn)行默認(rèn)處理，保證所有來源的數(shù)據(jù)最終在 DW 層是統(tǒng)一的，從而實(shí)現(xiàn)高內(nèi)聚。訂單和物流被劃定為不同的主題，以減少其耦合度。

2、公共邏輯下沉

前面介紹數(shù)倉(cāng)分層時(shí)，指出公共邏輯要盡量放在 DWM 層處理，對(duì)下游使用方盡量屏蔽復(fù)雜的業(yè)務(wù)邏輯，從而做到口徑統(tǒng)一。例如在訂單處理過程中，會(huì)有很多無效的訂單，識(shí)別無效訂單的核心邏輯在 DWM 層，這樣下游業(yè)務(wù)方就可以直接使用。

3、成本與性能平衡

一定的數(shù)據(jù)冗余，雖然可能帶來成本增加，但查詢性能可以得到提高。例如在區(qū)域維表設(shè)計(jì)中，針對(duì)國(guó)家、省份、城市、區(qū)縣，通過一個(gè)區(qū)域?qū)蛹?jí)字段將其分類，雖然數(shù)據(jù)是冗余的，但用戶使用起來會(huì)比較方便，并且查詢更快速。

4、一致性

在數(shù)倉(cāng)建模過程中，要保證字段含義和命名規(guī)范是統(tǒng)一的，這樣可以降低理解和使用的成本。

5、數(shù)據(jù)可回滾

要保證數(shù)據(jù)可回滾，在不同時(shí)間去執(zhí)行數(shù)倉(cāng)的調(diào)度，針對(duì)歷史數(shù)據(jù)計(jì)算出的結(jié)果是一致的。

那我們是如何進(jìn)行指標(biāo)管理呢？在小米內(nèi)部會(huì)通過 OSM 模型，根據(jù)公司的目標(biāo)和策略，通過數(shù)倉(cāng)中的度量值進(jìn)行考核。

例如 2023 年的目標(biāo)是手機(jī)出貨量要達(dá)到 X 萬臺(tái)，相關(guān)策略是要設(shè)計(jì)好產(chǎn)品，提高用戶購(gòu)買；同時(shí)嚴(yán)控質(zhì)量，減少質(zhì)量問題帶來的影響?；谀繕?biāo)和策略，在銷售數(shù)倉(cāng)中通過兩個(gè)度量值來衡量，一是手機(jī)妥投數(shù)量，這個(gè)數(shù)值要盡可能高；二是手機(jī)售后退貨數(shù)量，反饋質(zhì)量情況。

指標(biāo)生產(chǎn)是基于 Hive 離線數(shù)據(jù)、MySQL 在線數(shù)據(jù)、分析數(shù)據(jù)進(jìn)行建模，建立語義模型，再進(jìn)行審核認(rèn)證，發(fā)布到集團(tuán)指標(biāo)庫(kù)，與數(shù)據(jù)百科進(jìn)行聯(lián)動(dòng)。在指標(biāo)消費(fèi)側(cè)，用戶可以通過數(shù)據(jù)百科進(jìn)行查詢指標(biāo)口徑詳情、上游血緣、維度等，數(shù)據(jù)百科與公司的 OA 工具進(jìn)行聯(lián)通，提高指標(biāo)易用性和使用效率。

三、銷售數(shù)倉(cāng)架構(gòu)介紹

小米的銷售數(shù)倉(cāng)采用的是 Lambda 架構(gòu)。銷售數(shù)據(jù)是集團(tuán)數(shù)倉(cāng)中的核心之一，內(nèi)部關(guān)注度高。如果是流處理，部分情況下無法達(dá)到百分之百的準(zhǔn)確性，因此需要通過批處理，去保證 T+1 數(shù)據(jù)的準(zhǔn)確性。在批處理層使用 Spark 加 Hive 去處理離線數(shù)據(jù)。在流式處理層，使用 Flink 加消息隊(duì)列 Talos。在 DW 和 DM 層，會(huì)通過 Hologres 進(jìn)行維表的加速查詢。最終再把這兩部分?jǐn)?shù)據(jù)進(jìn)行聯(lián)合，提供給下游業(yè)務(wù)方使用。

我們?cè)谔幚礓N售實(shí)時(shí)數(shù)據(jù)中，會(huì)遇到各樣的問題，這里介紹下實(shí)時(shí)數(shù)據(jù)流狀態(tài)過期問題的解決方法。在實(shí)時(shí)數(shù)據(jù)中，銷售訂單主要分兩部分。第一部分是訂單事實(shí)表，第二部分是訂單明細(xì)事實(shí)表。訂單中所有的狀態(tài)變更都體現(xiàn)在訂單事實(shí)表，而訂單明細(xì)數(shù)據(jù)在第一次創(chuàng)建之后，就不會(huì)再發(fā)生變化。大家都知道，實(shí)時(shí)計(jì)算消息隊(duì)列的保存時(shí)間是有限制的，通常會(huì)設(shè)置一個(gè)時(shí)間周期。Flink 也有計(jì)算狀態(tài)的保存時(shí)間，在一定時(shí)間周期后計(jì)算狀態(tài)會(huì)過期，需要注意的是，由于訂單明細(xì)不再變化，如果一些訂單主表的兩次狀態(tài)變化時(shí)間大于狀態(tài)過期時(shí)間，這時(shí)候銷售相關(guān)指標(biāo)是失準(zhǔn)的。

實(shí)踐中是通過引入一個(gè)離線流，在訂單和訂單明細(xì)上各自去識(shí)別這部分過期數(shù)據(jù)，通過一個(gè)離線數(shù)據(jù)的消息隊(duì)列，與原始的實(shí)時(shí)數(shù)據(jù)流進(jìn)行合并，去重后下發(fā)到下游進(jìn)行處理，大幅度提高同類場(chǎng)景下數(shù)據(jù)準(zhǔn)確性。

但是這樣會(huì)引發(fā)另外一個(gè)問題，即批處理思維方式帶來的物流指標(biāo)異常。

以物流場(chǎng)景為例，一些國(guó)際業(yè)務(wù)在商品出貨后，由于距離較遠(yuǎn)或者報(bào)關(guān)審批等流程，會(huì)導(dǎo)致部分貨物可能三個(gè)月后才發(fā)生一個(gè)狀態(tài)變更。物流主表記錄物流狀態(tài)的變更，物流明細(xì)表以及離線的補(bǔ)充物流明細(xì)表會(huì)進(jìn)行合并操作，之后對(duì)這兩部分進(jìn)行去重，去重后的結(jié)果再與物流主表進(jìn)行關(guān)聯(lián)，然后下發(fā)進(jìn)行其他的處理邏輯。這是一個(gè)典型的離線處理思維。上述處理方法忽略了一個(gè)重要的環(huán)節(jié)，即 Flink 中算子 state 的保存機(jī)制。

在補(bǔ)離線流的時(shí)候，由于補(bǔ)充離線任務(wù)本身也需要調(diào)度時(shí)間，導(dǎo)致數(shù)據(jù)可能無法及時(shí)精準(zhǔn)的補(bǔ)進(jìn)去，為了準(zhǔn)確的補(bǔ)充離線數(shù)據(jù)，會(huì)多補(bǔ)充一部分?jǐn)?shù)據(jù)。在 RANK 算子下發(fā)時(shí)，多補(bǔ)的這一部分?jǐn)?shù)據(jù)，會(huì)導(dǎo)致實(shí)時(shí)流中的明細(xì)數(shù)據(jù)不過期，即離線數(shù)據(jù)流跟實(shí)時(shí)數(shù)據(jù)流進(jìn)行合并和排序操作會(huì)使實(shí)時(shí)數(shù)據(jù)中的原始流過期時(shí)間進(jìn)一步延長(zhǎng)，不會(huì)下發(fā)對(duì)應(yīng)的明細(xì)數(shù)據(jù)到 join 算子。實(shí)際解決是通過利用 Flink 中的處理時(shí)間，按照物理明細(xì)表的業(yè)務(wù)聯(lián)合主鍵下發(fā)最后一條數(shù)據(jù)，主要的解決思路就是深入理解實(shí)時(shí)計(jì)算過程，避免受離線開發(fā)思維影響。

接下來介紹一下基于 Iceberg 的存儲(chǔ)批流一體方案。

主要是將離線處理中的 Hive 和實(shí)時(shí)處理中的 Talos 全部換成 Iceberg 去處理。選擇 Iceberg 的原因是其對(duì)結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)都有很好的支持。小米有一些非結(jié)構(gòu)化的三方數(shù)據(jù)以及一些跟谷歌合作的 BQ 埋點(diǎn)日志，這些數(shù)據(jù)比較復(fù)雜，把這些數(shù)據(jù)存儲(chǔ)在 Iceberg 中會(huì)比較方便。Iceberg 支持事務(wù)寫，在其變更過程中，不影響下游業(yè)務(wù)讀取數(shù)據(jù)，這方面 Hive 是做不到的。另外小米計(jì)算平臺(tái)團(tuán)隊(duì)通過 merge into 語法，實(shí)現(xiàn)了對(duì) Iceberg 數(shù)據(jù)的高效修正，使得離線和實(shí)時(shí)可以高效地相互融合。

但這個(gè)方案也存在不足之處，由于 Iceberg 的事務(wù)提交依賴 Commit，但是在實(shí)時(shí)寫入中每次 Commit 的速度會(huì)依賴 Checkpoint 設(shè)置的時(shí)長(zhǎng)，所以無法做到秒級(jí)別的實(shí)時(shí)。

四、數(shù)倉(cāng)能力層

下面介紹銷售數(shù)倉(cāng)能力層，即數(shù)倉(cāng)經(jīng)過一定的建設(shè)和升級(jí)，逐漸沉淀下來的一些公共能力。

首先是統(tǒng)一的數(shù)據(jù)架構(gòu)。準(zhǔn)實(shí)時(shí)數(shù)據(jù)需求是基于 Iceberg 的分鐘級(jí)流批一體處理方案；在實(shí)時(shí)方面，是基于 Flink + Talos 的秒級(jí)處理方案及離線批處理方案。

數(shù)倉(cāng)規(guī)范在數(shù)倉(cāng)能力層中舉足輕重。日常工作中非常重視具體的開發(fā)過程和規(guī)范，尤其是對(duì)一些新同學(xué)，規(guī)范是必要且實(shí)用的。通過數(shù)倉(cāng)開發(fā)和質(zhì)量規(guī)范，會(huì)統(tǒng)一表命名方式、字段命名方式、數(shù)倉(cāng)分層等，配置 DQC 相關(guān)的完整性校驗(yàn)、一致性校驗(yàn)、空值率校驗(yàn)。

數(shù)據(jù)安全是數(shù)倉(cāng)能力建設(shè)的一個(gè)重要方面。一是通過合規(guī)管控，所有的數(shù)據(jù)生產(chǎn)環(huán)節(jié)都嚴(yán)格遵守國(guó)家的法律法規(guī)。在公司內(nèi)部有質(zhì)量部、隱私委以及法務(wù)部會(huì)對(duì)所有環(huán)節(jié)進(jìn)行監(jiān)控。二是會(huì)進(jìn)行安全分類，即按照數(shù)據(jù)的敏感度和重要性將數(shù)據(jù)進(jìn)行分類。三是在權(quán)限控制方面，會(huì)嚴(yán)格規(guī)范數(shù)據(jù)流程，在每個(gè)部門都會(huì)有對(duì)應(yīng)的安全負(fù)責(zé)人來負(fù)責(zé)最終的安全校驗(yàn)。在審批過程中，會(huì)遵循權(quán)限最小的原則。核心研發(fā)人員和使用人員，簽署數(shù)據(jù)保密協(xié)議。四是集群隔離，小米是一個(gè)國(guó)際化公司。在國(guó)外會(huì)將機(jī)房部署在當(dāng)?shù)?，并且機(jī)房之間的數(shù)據(jù)明細(xì)是不允許傳輸?shù)摹?duì)一些匯總的指標(biāo)，經(jīng)過安全負(fù)責(zé)人的審批之后，可以傳回國(guó)內(nèi)進(jìn)行分析。在歐洲的數(shù)據(jù)業(yè)務(wù)，會(huì)嚴(yán)格遵守歐盟的 GDPR 條例。針對(duì)海外數(shù)據(jù)，會(huì)成立國(guó)際數(shù)據(jù)運(yùn)營(yíng)中心，本地開發(fā)部署和運(yùn)維。

數(shù)倉(cāng)能力建設(shè)的一個(gè)重要環(huán)節(jié)就是指標(biāo)應(yīng)用。具體的指標(biāo)應(yīng)用是數(shù)據(jù)百科，如下圖右側(cè)所示，數(shù)據(jù)百科中包含全部數(shù)據(jù)口徑的描述、基礎(chǔ)信息、維度的拆解和相關(guān)指標(biāo)。在指標(biāo)口徑上會(huì)嚴(yán)格指定權(quán)限審批的負(fù)責(zé)人，明確整個(gè)指標(biāo)的詳情。下游可以通過數(shù)據(jù)百科，快速了解相關(guān)指標(biāo)。部分指標(biāo)會(huì)和集團(tuán)數(shù)據(jù)看板進(jìn)行聯(lián)動(dòng)，提供給集團(tuán)的管理者使用。

五、總結(jié)與展望

最后進(jìn)行一下總結(jié)和展望。

經(jīng)過幾年的建設(shè)和應(yīng)用，我們已經(jīng)基本建成了離線銷售數(shù)倉(cāng)，公司的運(yùn)營(yíng)和管理層都在深度且廣泛的使用銷售數(shù)倉(cāng)數(shù)據(jù)。團(tuán)隊(duì)內(nèi)部沉淀了數(shù)據(jù)架構(gòu)和數(shù)倉(cāng)能力規(guī)范，會(huì)不斷與業(yè)界進(jìn)行交流學(xué)習(xí)，探索最佳實(shí)踐案例。

銷售數(shù)倉(cāng)未來的兩個(gè)趨勢(shì)，一是數(shù)據(jù)的價(jià)值化，二是指標(biāo)的實(shí)時(shí)化。由于目前公司處于快速發(fā)展的過程中，數(shù)據(jù)部門和業(yè)務(wù)需要更緊密地結(jié)合，充分挖掘數(shù)據(jù)的價(jià)值，真正將數(shù)據(jù)的價(jià)值體現(xiàn)出來，去賦能業(yè)務(wù)，為公司帶來業(yè)績(jī)的增長(zhǎng)。目前實(shí)時(shí)化是一個(gè)大的趨勢(shì)，數(shù)據(jù)以及業(yè)務(wù)的變化，都需要及時(shí)體現(xiàn)出來，做到高實(shí)時(shí)性。

六、問答環(huán)節(jié)

Q1：支付訂單完成訂單之后，可能會(huì)發(fā)生周期性退款的問題，正常的 DWD 模型或 DWS 模型通常會(huì)存在多分區(qū)表，針對(duì)這種類似于多狀態(tài)不斷更新的表，例如有一段退款之后就會(huì)發(fā)生歷史回溯修改 DWS 模型，小米是如何解決的？

A1：我們是通過離線的方式去對(duì)數(shù)據(jù)準(zhǔn)確性進(jìn)行修正。在離線里面會(huì)跑全量數(shù)據(jù)，即每次跑的時(shí)候是從 ODS 層采集到 DW 層的處理，以及 DM 層，每個(gè)分區(qū)里面都是全量數(shù)據(jù)。這一塊計(jì)算會(huì)比較重，用來解決狀態(tài)經(jīng)常變化的問題。

Q2：數(shù)據(jù)權(quán)限一般存儲(chǔ)在哪一層？

A2：我們會(huì)有一個(gè)平臺(tái)部門去負(fù)責(zé)整體的數(shù)據(jù)權(quán)限，我們?cè)诿恳粚樱瑥腛DS到DWD、DWM都會(huì)有權(quán)限管控。

Q3：物流這塊引入 Kudu 或者 Doris 可以嗎？

A3：目前在部門內(nèi)部  Kudu 是將要被替換的狀態(tài)。因?yàn)?Kudu 是一個(gè)相對(duì)小眾的產(chǎn)品，運(yùn)維成本會(huì)比較高。我們正在用阿里的 Hologres 去替代 OLAP 引擎，包括Kudu 和 Doris。

目前在我們的離線和實(shí)時(shí)數(shù)據(jù)生產(chǎn)中，會(huì)使用Doris去加速結(jié)果表，我們會(huì)把一些中間結(jié)果或者最終的匯總數(shù)據(jù)存到 Doris 里面(主要是匯總數(shù)據(jù))，之后利用 Doris 的 OLAP 能力去對(duì)查詢進(jìn)行加速。

Q4：DWM 是跨域的寬表嗎？DWD 和 DWM 到底哪個(gè)是明細(xì)層？

A4：我們將 DWD 和 DWM 統(tǒng)稱為 DW，都是明細(xì)層。DWD 主要是進(jìn)行規(guī)范化，把可能不同的異構(gòu)數(shù)據(jù)統(tǒng)一到 DWD 來。在這個(gè)過程中除了 ETL、規(guī)劃化、標(biāo)準(zhǔn)化之外，不會(huì)進(jìn)行特別復(fù)雜的操作。在 DWM 層我們會(huì)加工一些公共的復(fù)雜的邏輯。DWM 層也是明細(xì)數(shù)據(jù)，是把多個(gè) DWD 表做關(guān)聯(lián)，生成的明細(xì)寬表。

Q5：DM 層以下的分層會(huì)提供給用戶訪問嗎？

A5：我們的 ODS、DWD 以及 TMP 層是不提供外部訪問的，其它層基本都可以對(duì)外部提供讀權(quán)限。DW 層例如 DWM 是可以提供給外部訪問的。因?yàn)?DWM 已經(jīng)進(jìn)行了邏輯的封裝，用戶使用 DWM 通過簡(jiǎn)單的計(jì)算就能得到我們?cè)?DM 中最終得出的指標(biāo)。

Q6：維度指標(biāo)是單獨(dú)分開存儲(chǔ)的嗎？

A6：不是，我們是存在一塊的。