實(shí)際搞過(guò)離線數(shù)據(jù)處理的同學(xué)都知道，Hive SQL 的各種優(yōu)化方法都是和數(shù)據(jù)傾斜密切相關(guān)的，所以我會(huì)先來(lái)聊一聊 “「數(shù)據(jù)傾斜」” 的基本概念，然后再在此基礎(chǔ)上為大家介紹各種場(chǎng)景下的 Hive 優(yōu)化方案。

Hive 的優(yōu)化分為 「join 相關(guān)的優(yōu)化」 和 「join 無(wú)關(guān)的優(yōu)化」 。

從項(xiàng)目實(shí)際來(lái)說(shuō)， join 相關(guān)的優(yōu)化其實(shí)占據(jù)了 Hive 優(yōu)化的大部分內(nèi)容，而 join 相關(guān)的優(yōu)化又分為 mapjoin 可以解決的 join 優(yōu)化和 mapjoin 無(wú)法解決的 join 優(yōu)化。

一、離線數(shù)據(jù)的主要挑戰(zhàn)：“數(shù)據(jù)傾斜”

首先介紹 “數(shù)據(jù)傾斜” 的概念。

“傾斜”應(yīng)該來(lái)自于統(tǒng)計(jì)學(xué)里的的偏態(tài)分布，數(shù)據(jù)處理中的傾斜和此相關(guān)。

對(duì)于分布式數(shù)據(jù)處理來(lái)說(shuō)，我們希望數(shù)據(jù)平均分布到每個(gè)處理節(jié)點(diǎn)，但是實(shí)際上由于業(yè)務(wù)數(shù)據(jù)本身的問(wèn)題或者分布算法的問(wèn)題，每個(gè)節(jié)點(diǎn)分配到的數(shù)據(jù)量很可能并不是我們預(yù)想的那樣。

也就是說(shuō)，只有待分到最多數(shù)據(jù)的節(jié)點(diǎn)處理完數(shù)據(jù)，整個(gè)數(shù)據(jù)處理任務(wù)才能完成，時(shí)分布式的意義就大打折扣 ，想想那個(gè)卡死的 99% 。

實(shí)際上，即使每個(gè)節(jié)點(diǎn)分配到的數(shù)據(jù)量大致相同，數(shù)據(jù)仍可能傾斜，比如考慮統(tǒng)計(jì)詞頻的極端問(wèn)題，如果某個(gè)節(jié)點(diǎn)分配到的詞都是一個(gè)詞，那么顯此節(jié)點(diǎn)需要的耗時(shí)將很長(zhǎng)，即使其數(shù)據(jù)量和其他節(jié)點(diǎn)的數(shù)據(jù)量相同。

Hive 的優(yōu)化正是采用各種措施和方法對(duì)上述場(chǎng)景的傾斜問(wèn)題進(jìn)行優(yōu)化和處理。

二、Hive 的優(yōu)化

其實(shí)在實(shí)際 Hive SQL 開(kāi)發(fā)的過(guò)程中， Hive SQL 性能的問(wèn)題上實(shí)際只有一小部分和數(shù)據(jù)傾相關(guān)。

很多時(shí)候， Hive SQL 運(yùn)行得慢是由開(kāi)發(fā)人員對(duì)于使用的數(shù)據(jù)了解不夠以及一些不良的使用習(xí)慣引起的。

開(kāi)發(fā)人員 要確定以下幾點(diǎn)：

• 「需要計(jì)算的指標(biāo)真的需要從數(shù)據(jù)倉(cāng)庫(kù)的公共明細(xì)層來(lái)自行匯總么?」 是不是數(shù)據(jù)公共層團(tuán)隊(duì)開(kāi)發(fā)的公共匯總層已經(jīng)可以滿足自己的需求?對(duì)于大眾的、 KPI 相關(guān)的指標(biāo)等通常設(shè)計(jì)良好的數(shù)據(jù)倉(cāng)庫(kù)公共層肯定已經(jīng)包含了，直接使用即可。
• 「真的需要掃描這么多分區(qū)么?」 比如對(duì)于銷售明細(xì)事務(wù)表來(lái)說(shuō)，掃描一年的分區(qū)和掃描一周的分區(qū)所帶來(lái)的計(jì)算、 IO 開(kāi)銷完全是兩個(gè)量級(jí)，所耗費(fèi)的時(shí)間肯定也是不同的。作為開(kāi)發(fā)人員，我們需要仔細(xì)考慮業(yè)務(wù)的需求，盡量不要浪費(fèi)計(jì)算和存儲(chǔ)資源!
• 「盡量不要使用 select * from your_table 這樣的方式，用到哪些列就指定哪些列?！?如 select coll, col2 from your_table ，另外， where 條件中也盡量添加過(guò)濾條件，以去掉無(wú)關(guān)的數(shù)據(jù)行，從而減少整個(gè) MapReduce 任務(wù)中需要處理、分發(fā)的數(shù)據(jù)量
• 「輸入文件不要是大量的小文件?！?Hive 的默認(rèn) Input Split 是 128MB (可配置)，小文件可先合并成大文件。

在保證了上述幾點(diǎn)之后，有的時(shí)候發(fā)現(xiàn) Hive SQL 還是要運(yùn)行很長(zhǎng)時(shí)間，甚至運(yùn)行不出來(lái)， 這時(shí)就需要真正的 Hive 優(yōu)化技術(shù)了!

三、Join 無(wú)關(guān)的優(yōu)化

Hive SQL 性能問(wèn)題基本上大部分都和 join 相關(guān)，對(duì)于和 join 無(wú)關(guān)的問(wèn)題主要有 group by 相關(guān)的傾斜和 count distinct 相關(guān)的優(yōu)化。

group by 引起的傾斜優(yōu)化

group by 引起的傾斜主要是輸入數(shù)據(jù)行按照 「group by 列分布不均勻」 引起的。

比如，假設(shè)按照供應(yīng)商對(duì)銷售明細(xì)事實(shí)表來(lái)統(tǒng)計(jì)訂單數(shù)，那么部分大供應(yīng)商的訂單量顯然非常多，而多數(shù)供應(yīng)商的訂單量就一般，由于 group by 的時(shí)候是按照供應(yīng)商的 ID 分發(fā)到每個(gè) Reduce Task ，那么此時(shí)分配到大供應(yīng)商的 Reduce Task 就分配了更多的訂單，從而導(dǎo)致數(shù)據(jù)傾斜。

對(duì)于 group by 引起的傾斜，優(yōu)化措施非常簡(jiǎn)單，只需設(shè)置下面參數(shù)即可：

set hive.map.aggr = true  
   set hive.groupby.skewindata=true 

此時(shí)Hive 在數(shù)據(jù)傾斜的時(shí)候會(huì)進(jìn)行負(fù)載均衡，生成的查詢計(jì)劃會(huì)有兩個(gè) MapReduce Job。

• 第一個(gè) MapReduce Job 中，Map 的輸出結(jié)果集合會(huì)隨機(jī)分布到 Reduce 中，每個(gè)Reduce 做部分聚合操作并輸出結(jié)果。這樣處理的結(jié)果是相同的 GroupBy Key 有可能被分布到不同的 Reduce 中，從而達(dá)到負(fù)載均衡的目的;
• 第二個(gè) MapReduce Job 再根據(jù)預(yù)處理的數(shù)據(jù)結(jié)果，按照 GroupBy Key 分布到 Reduce 中(這過(guò)程可以保證相同的GroupBy Key被分布到同一個(gè)Reduce中)，最后完成最終的聚合操作。

count distinct 優(yōu)化

在 Hive 開(kāi)發(fā)過(guò)程中，應(yīng)該小心使用 count distinct ，因?yàn)楹苋菀滓鹦阅軉?wèn)題，比如下面的 SQL：

select count(distinct user) from some_table 

由于必須去重，因此 Hive 將會(huì)把 Map 階段的輸出全部分布到 Reduce Task 上，此時(shí)很容易引起性能問(wèn)題。對(duì)于這種情況，可以通過(guò)先 group by 再 count 的方式來(lái)優(yōu)化，優(yōu)化后的 SQL 如下：

select count(*) from ( 
   select user  
   from some_table  
   group by user 
   ) tmp; 

原理為：先利用 group by 去重，再統(tǒng)計(jì) group by 的行數(shù)目。

四、大表 Join 小表優(yōu)化

join 相關(guān)的優(yōu)化主要分為 mapjoin 可以解決的優(yōu)化 ( 即大表 join 小表) 和 mapjoin 無(wú)法解決的優(yōu)化( 即大表 join 大表 )。大表 join 小表相對(duì)容易解決，大表 join 大表相對(duì)復(fù)雜和難以解決，但也不是不可解決的，只是相對(duì)比較麻煩而已。

首先介紹大表 join 小表優(yōu)化 。仍以銷售明細(xì)事實(shí)表為例來(lái)說(shuō)明大表 join 小表的場(chǎng)景。

假如供應(yīng)商會(huì)進(jìn)行評(píng)級(jí)，比如(五星、四星、 兩星、 一星)，此時(shí)業(yè)務(wù)人員希望能夠分析各供應(yīng)商星級(jí)的每天銷售情況及其占比。

開(kāi)發(fā)人員一般會(huì)寫(xiě)出如下 SQL:

select Seller_srar, count(order_id) as ordre_cnt 
   from ( 
   select order_id,seller_id  
       from dwd_sls_fact_detail_table 
       where partition_value ='20170101' 
   ) a 
   Left outer join( 
   select seller_id,seller_star 
       from dim_seller 
       where partition_value='20170101' 
   ) b 
   on a.seller_id = b.seller_id 
   group by b.seller_star; 

但正如上述所言，現(xiàn)實(shí)世界的二八準(zhǔn)則將導(dǎo)致訂單集中在部分供應(yīng)商上，而好的供應(yīng)商的評(píng)級(jí)通常會(huì)更高，此時(shí)更加劇了數(shù)據(jù)傾斜的程度。如果不加以優(yōu)化，上述 SQL 將會(huì)耗費(fèi)很長(zhǎng)時(shí)間，甚至運(yùn)行不出結(jié)果!

通常來(lái)說(shuō)，供應(yīng)商是有限的，比如上千家、上萬(wàn)家，數(shù)據(jù)量不會(huì)很大，而銷售明細(xì)事實(shí)表比較大，這就是典型的大表 join 小表問(wèn)題，可以通過(guò) mapjoin 的方式來(lái)優(yōu)化，只需添加 mapjoin hint 即可，優(yōu)化后的 SQL 如下：

select /*+mapjoin(b)*/ Seller_srar, count(order_id) as ordre_cnt 
from ( 
select order_id,seller_id  
    from dwd_sls_fact_detail_table 
    where partition_value ='20170101' 
) a 
Left outer join( 
select seller_id,seller_star 
    from dim_seller 
    where partition_value='20170101' 
) b 
on a.seller_id = b.seller_id 
group by b.seller_star; 

/*+mapjoin(b)*/ 即 mapjoin himt，如果需要 mapjoin 多個(gè)表，則格式為/*+mapjoin(b,c,d)*/ 。

Hive 對(duì)于 mapjoin 是默認(rèn)開(kāi)啟的，設(shè)置參數(shù)為：

Set hive.auto.convert.join=ture; 

mapjoin 優(yōu)化是在 Map 階段進(jìn)行 join ，而不是像通常那樣在 Reduce 階段按照 join 列進(jìn)行分發(fā)后在每個(gè) Reduce 任務(wù)節(jié)點(diǎn)上進(jìn)行 join ，不需要分發(fā)也就沒(méi)有傾斜的問(wèn)題，相反 Hive 會(huì)將小表全量復(fù)制到每個(gè) Map 任務(wù)節(jié)點(diǎn)(對(duì)于本例是 dim_seller ，當(dāng)然僅全量復(fù)制 b表 sql 指定的列)，然后每個(gè) Map 任務(wù)節(jié)點(diǎn)執(zhí)行 lookup 小表即可。

「從上述分析可以看出，小表不能太大，否則全量復(fù)制分發(fā)得不償失。」

• 實(shí)際上 Hive 根據(jù)參數(shù) hive.mapjoin.smalltable.filesize ( 0.11.0 本后是 hive.auto.convert.join.noconditionaltask.size )來(lái)確定小表的大小是否滿足條件(默認(rèn) 25M)。
• 實(shí)際中此參數(shù)值所允許的最大值可以修改，但是一般最大不能超過(guò) 1GB (太大的話 Map 任務(wù)所在的節(jié)點(diǎn)內(nèi)存會(huì)撐爆， Hive 會(huì)報(bào)錯(cuò) 。另外需要注意的是， HDFS 顯示的文件大小是壓縮后的大小， 當(dāng)實(shí)際加載到內(nèi)存的時(shí)候，容量會(huì)增大很多，很多場(chǎng)景下可能會(huì)膨脹 10 倍)。

五、大表 Join 大表優(yōu)化

如果上述 mapjoin 中小表 dim_seller 很大呢?比如超過(guò)了 1GB 的大小?這種就是大表join 大表的問(wèn)題 。

這類問(wèn)題相對(duì)比較復(fù)雜，我們首先引入具體的問(wèn)題場(chǎng)景，然后基于此介紹各種優(yōu)化方案。

問(wèn)題場(chǎng)景

我們先假設(shè)一個(gè)問(wèn)題場(chǎng)景：

• A 表為一個(gè)匯總表，匯總的是賣家買家最近 N 天交易匯總信息，即對(duì)于每個(gè)賣家最近 N 天，其每個(gè)買家共成交了多少單、總金額是多少，我們這里 N 先只取 90 天，匯總值僅取成交單數(shù) 。A 表的字段有：buyer_id 、seller_id 和 pay_cnt_90d 。
• B 表為賣家基本信息表，其中包含賣家的一個(gè)分層評(píng)級(jí)信息，比如把賣家分為 6 個(gè)級(jí)別：S0、S1、S2、S3、S4、S5、S6 。

要獲得的結(jié)果是每個(gè)買家在各個(gè)級(jí)別賣家的成交比例信息，比如：

• 某買家 S0:10%; S1:20%; S2:20%; S3:10%; S4:20%; S4:10%; S5:10%。
• B表的字段有：seller_id 和 s_level。

正如 mapjoin 中的例子一樣，我們的第一反應(yīng)是直接 join 表并統(tǒng)計(jì)：

select  
m.buyer_id  
,sum(pay_cnt_90d) as pay_cnt_90d  
,sum(case when m.s_level=O then pay_cnt_90d end) as pay_cnt_90d_s0  
,sum(case when m.s_level=l then pay_cnt_90d end) as pay_cnt_90d_sl  
,sum(case when m.s_level=2 then pay_cnt_90d end) as pay_cnt_90d_s2  
,sum(case when m.s level=3 then pay cnt 90d end) as pay_cnt_90d_s3 
,sum(case when m.s_level=4 then pay_cnt_90d end) as pay_cnt_90d_s4  
,sum(case when m.s_level=S then pay_cnt_90d end) as pay_cnt_90d_s5  
from  
( 
select  
a.buyer_id,a.seller_id,b.s_level,a.pay_cnt_90d  
from  
( 
select buyer_id ,seller_id,pay_cnt_90d  
from table A  
) a  
join  
( 
select seller_id,s_level  
from table B  
) b  
on a.seller_id=b.seller_id  
) m  
group by m.buyer_id 

但是此 SQL 會(huì)引起數(shù)據(jù)傾斜，原因在于賣家的二八準(zhǔn)則。某些賣家 90 天內(nèi)會(huì)有幾百萬(wàn)甚至上千萬(wàn)的買家，但是大部分賣家 90 天內(nèi)的買家數(shù)目并不多， join table_A 和table_B 的時(shí)候 ODPS 會(huì)按照 Seller_id 進(jìn)行分發(fā)， table_A 的大賣家引起了數(shù)據(jù)傾斜。

「但是本數(shù)據(jù)傾斜問(wèn)題無(wú)法用 mapjoin table_B 解決，因?yàn)橘u家有超過(guò)千萬(wàn)條、文件大小幾個(gè)GB ，超過(guò)了 mapjoin 表最大 1GB 的限制?！?/p>

方案 1：轉(zhuǎn)化為 mapjoin

大表無(wú)法直接mapjoin，那么是否可以間接呢?實(shí)際上此思路有兩種途徑：限制行和限制列。

• 限制行: 不需要join B全表，只需要join其在A表中存在的。對(duì)于本問(wèn)題場(chǎng)景，就是過(guò)濾掉 90 天內(nèi)沒(méi)有成交的賣家。
• 限制列: 只取需要的字段。

select  
 m.buyer_id  
 ,sum(pay_cnt_90d) as pay_cnt_90d  
 ,sum(case when m.s_level=O then pay_cnt_90d end) as pay_cnt_90d_s0  
 ,sum(case when m.s_level=l then pay_cnt_90d end) as pay_cnt_90d_sl  
 ,sum(case when m.s_level=2 then pay_cnt_90d end) as pay_cnt_90d_s2  
 ,sum(case when m.s level=3 then pay cnt 90d end) as pay_cnt_90d_s3 
 ,sum(case when m.s_level=4 then pay_cnt_90d end) as pay_cnt_90d_s4  
 ,sum(case when m.s_level=S then pay_cnt_90d end) as pay_cnt_90d_s5  
 from  
 ( 
 select /*+mapjoin(b)*/ 
 a.buyer_id,a.seller_id,b.s_level,a.pay_cnt_90d  
 from  
 ( 
 select buyer_id ,seller_id,pay_cnt_90d  
 from table_A  
 ) a  
 join  
 ( 
 select b0.seller id,s_level  
 from table_B b0 
     join 
     (select seller_id from table_A group by seller_id) a0 
     on b0.seller_id=a0.seller_id 
 ) b  
 on a.seller_id=b.seller_id  
 ) m  
 group by m.buyer_id 

此方案在一些情況下可以起作用，但很多時(shí)候還是無(wú)法解決上述問(wèn)題，因?yàn)榇蟛糠仲u家盡管 90 買家不多 ，但還是有一些的，過(guò)濾后的 B 表仍然很大。

方案 2：join 時(shí)用 case when 語(yǔ)句

應(yīng)用場(chǎng)景為: 傾斜的值是明確的而且數(shù)量很少，比如null值引起的傾斜。

將這些引起傾斜的值隨機(jī)分發(fā)到Reduce，其主要核心邏輯在于 join 時(shí)對(duì)這些特殊值concat 隨機(jī)數(shù),從而達(dá)到隨機(jī)分發(fā)的目的。核心邏輯如下：

Select a.user_id,a.order_id,b.user_id  
  From table_a a  
  Join table_b b  
  On (case when a.user_id is null then concat ('hive' ,rand()) else a.user_id end)=b.user_id 

Hive已對(duì)此進(jìn)行了優(yōu)化，不需要修改SQL，只需要設(shè)置參數(shù);比如 table_B 的值 "0" 和 "1" 引起傾斜，只需要如下設(shè)置：

set hive.optimize.skewinfo=table_B:(seller_id)[("0")("1")]; 
   set hive.optimize.skewjoin=true; 

但是方案二還是不能解決上述問(wèn)題，因?yàn)閮A斜的賣家大量存在而且動(dòng)態(tài)變化。

方案 3：倍數(shù)B表，再取模join

通用方案

是建立一個(gè)numbers表,其值只有一列int行，比如從1到10(具體根據(jù)傾斜程度確定)，然后放大B表10倍，再取模join。

select  
  m,buer_id 
  ,sum(pay_cnt_90d) as pay_cnt_90d  
  ,sum(case when m.s_level=O then pay_cnt_90d end) as pay cnt 90d so  
  ,sum(case when m.s_level=l then pay cnt 90d end) as pay cnt 90d_sl  
  ,sum(case when m.s_level=2 then pay_cnt_90d end) as pay_cnt_90d s2  
  ,sum(case when m.s_level=3 then pay_cnt_90d end) as pay_cnt_90d_s3  
  ,sum(case when m.s_level=4 then pay_cnt_90d end) as pay cnt 90d s4  
  ,sum(case when m.s level=S then pay cnt 90d end) as pay cnt 90d s5  
  from  
  ( 
  select  
  a.buyer_id,a.seller_id,b.s_level,a.pay_cnt_90d  
  from 
  ( 
  select buyer_id,seller_id,pay_cnt_90d  
  from table_A  
  ) a  
  JOin  
  ( 
  select /*+mapjoin(members)*/  
  seller_id,s_level,member  
  from table_B  
  join  
  numbers  
  ) b  
  on a.seller_id=b.seller_id  
  and mod(a.pay_cnt_90d,10)+1=b.number  
  ) m  
  group by m.buyer_id 

思路核心在于：既然按照seller_id分發(fā)會(huì)傾斜，那么再人工增加一列進(jìn)行分發(fā)，這樣之前傾斜的值的傾斜程度會(huì)減少為原來(lái)的1/10?？梢酝ㄟ^(guò)配置numbers表修改放大倍數(shù)來(lái)降低傾斜程度，但弊端就是B表會(huì)膨脹N倍。

專有方案

通用方案思路是把B表的每條數(shù)據(jù)都放大了相同的倍數(shù)，實(shí)際上只需要把大賣家放大倍數(shù)即可。

首先需要知道大賣家的名單，即先建立一個(gè)臨時(shí)表動(dòng)態(tài)存放每日最新的大賣家(比如dim_big_seller)，同時(shí)此表的大賣家要膨脹預(yù)先設(shè)定的倍數(shù)(比如1000倍)。

在A表和 B表中分別新建一個(gè) join 列，其邏輯為：如果是大賣家，那么 concat 一個(gè)隨 機(jī)分配正整數(shù)(0到預(yù)定義的倍數(shù)之間，本例為0~1000 );如果不是，保持不變。

相比通用方案，專用方案的運(yùn)行效率明顯好了很多，因?yàn)橹皇菍表中大賣家的行數(shù)放大了 1000 倍，其他賣家的行數(shù)保持不變，但同時(shí)也可以看到代碼也復(fù)雜了很多，而且必須首先建立大賣家表。

方案 4：動(dòng)態(tài)一分為二

實(shí)際上方案 2 和 3 都用到了一分為二的思想，但是都不徹底，對(duì)于 mapjoin 不能解決的 問(wèn)題，終極解決方案就是動(dòng)態(tài)一分為 ，即對(duì)傾斜的鍵值和不傾斜的鍵值分開(kāi)處理，不傾 斜的正常 join 即可，傾斜的把它們找出來(lái)然后做 mapjoin ，最后 union all 其結(jié)果即可。

但是此種解決方案比較麻煩，代碼會(huì)變得復(fù)雜而且需要一個(gè)臨時(shí)表存放傾斜的鍵值。

- 對(duì)于 90 天買家數(shù)超過(guò) 10000 的賣家直接 map join ，對(duì)于其他賣家正常 join 即可

- 對(duì)于 90 天買家數(shù)超過(guò) 10000 的賣家直接 map join ，對(duì)于其他賣家正常 join 即可 
select  
m.buyer_id  
,sum(pay_cnt_90d) as pay_cnt_90d  
,sum(case when rn.s_level=O then pay_cnt_90d end) as pay_cnt_90d_s0  
,sum(case when rn.s_level=l then pay_cnt_90d end) as pay_cnt_90d_sl  
,sum(case when rn.s_level=2 then pay_cnt_90d end) as pay_cnt_90d_s2  
,sum(case when rn.s_level=3 then pay_cnt_90d end) as pay_cnt_90d_s3  
,sum(case when rn.s_level=4 then pay_cnt_90d end) as pay_cnt_90d_s4  
,sum(case when rn.s_level=S then pay_cnt_90d end) as pay_cnt_90d_s5 
from 
( 
select  
    a.buyer_id,a.seller_id,b.s_level,a.pay_cnt_90d 
    from 
    ( 
    select buyer_id,seller_id,pay_cnt_90d 
        from table_A 
    ) a 
    join 
    ( 
     select seller_id ,a.s_level 
        from table_A a 
        left outer join tmp_table_B b 
        on a.user_id = b.seller_id 
        where b.seller_id is null 
    ) b  
on a.seller id=b.seller id  
union all  
select /*+mapjoin(b)*/  
a.buyer_id,a.seller_id,b.s_level,a.pay_cnt_90d  
from  
select buyer_id,seller_id,pay_cnt_90d  
from table A  
) a  
join  
select seller_id,s_level  
from table B  
) b  
on a.seller id=b.seller id 
) m group by m.buyer_id 
) m 
group by m.byer_id 

總結(jié)起來(lái)，方案 1、2 以及方案 3 中的通用方案不能保證解決大表 join 大表問(wèn)題，因?yàn)樗鼈兌即嬖诜N種不同的限制和特定的使用場(chǎng)景。

而方案 3 的專用方案和方案 4 是比較推薦的優(yōu)化方案，但是它們都需要新建一個(gè)臨時(shí)表來(lái)存放每日動(dòng)態(tài)變化的大賣家 。

相對(duì)方案 4 來(lái)說(shuō)，方案 3 的專用方案不需要對(duì)代碼框架進(jìn)行修改，但是 B 表會(huì)被放大，所以一定要是維度表，不然統(tǒng)計(jì)結(jié)果會(huì)是錯(cuò)誤的 。方案 4 的解決方案最通用，自由度最高，但是對(duì)代碼的更改也最大，甚至需要更改代碼框架，可作為終極方案來(lái)使用。