303      iPhone_iPad_Mac_apple

阿裏流計算平台開發實例之電商雙11實時計算

  由於之前沒寫過博客之類的文章，所以這次寫也是心中踹踹，也是由於這個項目間沒有找到相關的一些文檔，當時就想著完成後寫一個出來，如果有寫的不周到的地方，請聯係我改正，謝謝。

一、 項目案例
用戶商業模式含蓋電商零售與加盟店批發零售，本次主要業務需求在於淘寶雙11期間能實時計算用戶所關注的一些指標數據，如：訂單數、訂單金額、商品SKU數、訂單來源地、商品排名等等。
基於這些指標需求，除了要達到實時的要求以外，還需要具備適當的展現圖設計，本次使用的是阿裏雲的DATAV，提供餅狀圖占比分析、商品與類目數據排名、國家地圖熱力展示等等。
二、 技術架構
由於用戶的數據在雲下，我們考慮的首先是遷移數據上雲，再通過DTS將數據同步至DATAHUB，接著使用阿裏流計算開發平台接入DATAHUB數據，並開發流計算代碼，將執行結果輸出至RDS MYSQL，最後DATAV引用RDS數據並開發圖形展現界麵。最終設計的技術架構如下圖所示：

圖：流計算數據邏輯設計圖

三、 技術實現
1、 數據遷移與數據同步：由於數據不能直接到DataHub，使用阿裏雲DTS工具先完成數據遷移至RDS，鏈接：https://dts.console.aliyun.com/ 。再使用其數據同步功能，將RDS數據同步至DataHub(注：RDS收費可包月、DTS收費按小時)。在數據同步環節需要注意，根據企業數據量的大小，調整數據傳輸的通道大小。另外DataHub會自動創建對應同步的表的Topic，所以不需要在同步前自建Topic，建了會報錯。（注意係統生成的Topic與自建的有哪些不同）
2、 StreamComputer流計算開發：其開發方式和技術要求，相比傳統的開源產品，要簡單許多，而且流計算平台功能比較豐富，特別是監控係統。其鏈接地址是：https://stream.console.aliyun.com。
2．1、datahub業務表的引用：
create table table_name( -- a
dts_column1 varchar, -- b
dts_column2 varchar,
dts_column3 bigint,
dts_column4 double,
dts_operation_flag varchar, -- c
dts_instance_id varchar,
dts_db_name varchar,
dts_table_name varchar,
dts_utc_timestamp varchar,
dts_before_flag varchar,
dts_after_flag varchar
) with (
type='datahub', -- d
endPoint='https://dh-cn-hangzhou.aliyuncs.com', -- e
project='project_name', -- f
topic='topic_name', -- g
accessId='accessId',
accessKey='accessKey',
startTime='2017-11-08 00:00:00' -- h
);
注解說明：
a、 在流計算引擎中建一張表，該表的名稱是什麼，建議和DataHub上一致
b、 要引用到該表的哪些字段，建議不需要的字段不要引用
c、 係統自建的TOPIC，該字段紀錄的是該行數據是更新還是插入還是刪除
d、 流計算可以引用多種數據源，這裏表明數據源類型
e、 固定寫法
f、 DataHub上的項目名稱
g、 DataHub上的topic名稱
h、 DataHub默認保留三天內的業務數據，該時間指定流計算引擎從哪個時間點取數
2.2、維表的引用：
create table div_product(
skucode varchar,
skuname varchar,
primary key(skucode), -- a
PERIOD FOR SYSTEM_TIME -- b
) with (
type='rds',
url='jdbc:mysql://yourHostName:3306/databaseName',
tableName=div_project,
userName='username',
password='password'
);
注解說明：
a、 該表的主鍵是什麼，需要指定
b、 表明這個是維表，固定寫法。
注意該表的來源是rds，後麵的連接方式和正常的MYSQL連接方式沒什麼區別。
2.3、數據輸出表的寫法和維表的寫法一致，隻要提前在RDS上建好即可。
2.4、應用腳本開發：將引用到的業務表與維表進行關聯，將數據輸出至目標表
Insert into ads_product_qty
select c.dts_clomun3,
sum(b.dts_qty) as qty_sum
from table_a a
join ( select
dts_clomun1 ,
dts_skuname ,
dts_skucode ,
case
when dts_operation_flag = 'U' and dts_before_flag = 'Y' and dts_after_flag = 'N' then -1 * dts_qty
when dts_operation_flag = 'U' and dts_before_flag = 'N' and dts_after_flag = 'Y' then dts_qty
when dts_operation_flag = 'D' then -1 * dts_qty
else dts_qty
end as dts_qty
from table_b ) b
on a.dts_clomun1 = b.dts_clomun1
join div_project FOR SYSTEM_TIME AS OF PROCTIME() as c on b.dts_skucode = c.skucode -- a
group c.dts_clomun3
注解說明：
a、和標準SQL沒太大區別，主要就是維表的使用方式略有不同，不過也是固定寫法，照抄就行。
注意：由於原始數據有插入、刪除、更新三種動作，所以DataHub上也會有三種狀態的數據，這就需要分別進行處理，否則數據會不準。
3、 DataV開發：此處省略，簡單歸納即：托一個圖形，寫一個SQL。

四、項目預案
由於流計算可能存在的風險，我們考慮以傳統的計算方式開發第二套方案，當流計算出故障時，能快速切換方案，保證數據基本能正常使用，可能延遲會大一些。
通過評估，由於數據量預計不會太大，考慮使用定時調存儲過程的方式計算指標到第二套輸出表上，再開發第二套報表，展現和第一套一致。設計圖如下：

圖：定期調任務刷數據
通過實際測試，大部份指標能在半分鍾內甚至十秒內出來，所以這些延遲勉強可以接受。由於技術實現並不複雜，此處略過。
五、項目壓測
為了保障數據爆發時，平台依然能穩定的工作，我們進行了相關的一些測試。首先模擬大量的數據產生，確認數據從本地庫至RDS的同步時間，RDS至DATAHUB的時間，以及流計算所處理的時間。
通過多次的測驗得出：當數據量持續比較大的情況下，數據會有一些延遲，性能瓶頸主要體現在RDS以及DTS同步至DATAHUB環節，其中後一步比較明顯。而平台穩定性基本上是可以的，流計算的處理效率非常令人滿意。

最後更新：2017-11-13 16:34:45

  上一篇：  地平線餘凱：自動駕駛處理器的“三國時代”| 清華人工智能研習社

  下一篇：  不忘初碼，聚棧前行