基於DataLakeAnalytics做跨地域的資料分析

在阿里雲上，很多客戶的應用都是多地域部署的, 比如在北京(cn-beijing)的地域部署一個應用讓北方的客戶訪問快一點，同時在杭州(cn-hangzhou)地域部署一份讓南方的客戶訪問快一點。多地域部署之後，業務資料被拆成了多份，而各個地域的資料庫都是獨立的，網路又不通，給總體業務資料的分析造成了困難。今天我給大家介紹一套基於 DataLakeAnalytics, OSS, DataX 等幾個阿里雲產品的跨地域資料分析的解決方案。

其實雲產品本身(比如我們 DataLakeAnalytics 自己)也有跨地域資料分析的需求，這個方案也同樣適用。這個方案本來就是為了分析 DataLakeAnalytics 自己的業務資料而探索出來的。

方案概覽

我們知道各個地域的RDS是不通的，除非你開公網訪問許可權(有很大的安全風險，不推薦), 而且即使你開公網，要對多個資料庫裡面的資料進行聯合分析也不是一件容易的事情；而且這種資料分析的需求我們不希望它佔用太多的預算。

我們的方案是把各個地域的資料都同步到同一個地域的OSS上面去，然後用 DataLakeAnalytics 進行聯合分析。這個方案的優點在於 OSS 儲存收費非常便宜， DataLakeAnalytics 也是按查詢量收費的，你平時不查詢的時候一分錢都不用花。總體方案如下圖:

匯聚各個地域的資料

我們方案的第一步是把各個地域的RDS資料同步到同一個地域的OSS裡面去。阿里巴巴集團開源了一個很棒的資料搬運的工具: DataX, 可以把資料在各種不同的資料來源之間進行搬運，它支援的資料來源型別非常豐富: 從關係型的 MySQL, SQLServer, 到各種檔案系統如 HDFS, OSS等等，其中我們需要的是從 MySQL 讀資料的 mysqlreader 外掛以及往 OSS 寫資料的 osswriter 外掛。

假定我們有下面這麼一個記錄人員資訊的表 person 需要同步:

create table person (
      id int primary key auto_increment,
      name varchar(1023),
      age int
);

我們寫一個類似下面這樣的DataX任務描述檔案 person.json :

{
 "job": {
   "setting": {
     "speed": {
       "channel": 1,
       "byte": 104857600
     },
     "errorLimit": {
       "record": 10
     }
   },
   "content": [
     {
       "reader": {
         "name": "mysqlreader",
         "parameter": {
           "username": "your-user-name",
           "password": "your-password",
           "column": [
             "id",
             "name",
             "age",
           ],
           "connection": [
             {
               "table": [
                 "person"
               ],
               "jdbcUrl": [
                 "jdbc:mysql://your-rds.mysql.rds.aliyuncs.com:3306/dbname"
               ]
             }
           ]
         }
       },

       "writer": {
         "name": "osswriter",
         "parameter": {
           "endpoint": "http://oss.aliyuncs.com",
           "accessId": "your-access-id",
           "accessKey": "your-access-secret",
           "bucket": "mydb-bucket",
           "object": "mydb/person/region=cn-hangzhou/person.csv",
           "encoding": "UTF-8",
           "fieldDelimiter": "|",
           "writeMode": "truncate"
         }
       }
     }
   ]
 }
}

這裡 MySQL 相關的資訊填你的業務庫的資訊，而 OSS 相關的資訊選擇一個我們同步到的OSS的地址。注意 OSS 配置部分的 object 欄位，mydb 儲存你所有的資料, person 這個目錄儲存你的 person 表的資料，region=cn-hangzhou 這個目錄就有意思了，它儲存的是你的應用在 cn-hangzhou 這個region裡面的資料，同樣的，你可能還會有 cn-beijing, cn-shangahi 的資料等等。

然後執行如下命令:

// 執行前確保你已經下載並正確配置好 DataX 了。
python datax/bin/datax.py person.json

正確執行的話你會看到下面的輸出:

.....省略N行......
2018-09-06 19:53:19.900 [job-0] INFO  JobContainer - PerfTrace not enable!
2018-09-06 19:53:19.901 [job-0] INFO  StandAloneJobContainerCommunicator - Total 251 records, 54067 bytes | Speed 5.28KB/s, 25 records/s | Error 0 records, 0 bytes |  All Task WaitWriterTime 0.001s | All Task WaitReaderTime 0.026s | Percentage 100.00%
2018-09-06 19:53:19.902 [job-0] INFO  JobContainer -
任務啟動時刻                    : 2018-09-06 19:53:09
任務結束時刻                    : 2018-09-06 19:53:19
任務總計耗時                    : 10s
任務平均流量                    : 5.28KB/s
記錄寫入速度                    : 25rec/s
讀出記錄總數                    : 251
讀寫失敗總數                    : 0

這樣資料就自動同步到 OSS 上去了，你可以下載一個 oss-browser 去檢視oss上面的資料:

檔案裡面資料大概是這樣的:

9|ethan|10
10|julian|20
11|train|30
12|wally|40

完成了一個地域的資料搬運之後，其它地域都可以照葫蘆畫瓢，唯一需要注意的地方是，雖然 MySQL 資料是各個 地域 的資料，但是 OSS 要用同一個根目錄 person ，因為我們要做資料彙集嘛，把幾個地域的資料彙集完成之後，person 目錄的結構大概是這樣的:

使用 DataLakeAnalytics 分析匯聚後的OSS資料

下面的分析就可以交給 DataLakeAnalytics 了，分析OSS上的資料是 DataLakeAnalytics 的拿手好戲，在開始之前我們要有一個 DataLakeAnalytics 的賬號，目前 DataLakeAnalytics 正在公測，直接申請試用就好了。試用審批成功之後，你會獲得一個使用者名稱和密碼, 然後在控制檯登入就可以使用:

或者如果你是極客，更偏愛命令列，你也可以使用普通的 MySQL 客戶端就可以連線 DLA 了:

mysql -hservice.cn-shanghai.datalakeanalytics.aliyuncs.com
     -P10000
     -u<your-user-name>
     -p<your-password>

在這篇文章裡面，我會使用 MySQL 命令列給大家演示 DLA 的功能。

首先我們來建一個 DataLakeAnalytics 的資料庫:

CREATE DATABASE `mydb` WITH DBPROPERTIES (
    catalog = oss,
    location = `oss://your-bucket/mydb/`
);

這裡的 oss://mydb-bucket/mydb/ 就是前面我們資料匯聚的 person 目錄的父目錄。

建好庫之後，我們再建一個表:

CREATE EXTERNAL TABLE IF NOT EXISTS `person` (
 `id` bigint,
 `name` varchar(128),
 `age` int
)
PARTITIONED BY (region varchar(63))
ROW FORMAT DELIMITED FIELDS TERMINATED BY `|`
STORED AS TEXTFILE
LOCATION `oss://mydb-bucket/mydb/person`;

注意這是一個分割槽表，分割槽的key是我們的region，這樣的好處一是各個地域在同步資料的時候比較簡單，不用擔心把別的地域的資料沖掉了；另外利用地域分割槽也使得我們在分析單個地域的時候掃描資料量會比較小，查詢速度更快。

建好表之後，我們執行如下命令讓 DataLakeAnalytics 去對OSS上的檔案列表進行掃描以找到所有的 region 分割槽:

mysql> msck repair table person;
+-----------------------------------------------------------------------------------------------------------+
| Result                                                                                                    |
+-----------------------------------------------------------------------------------------------------------+
| Partitions not in metastore: person:region=cn-beijing person:region=cn-hangzhou person:region=cn-shanghai |
| Repair: Added partition to metastore mydb.person:region=cn-beijing                                        |
| Repair: Added partition to metastore mydb.person:region=cn-hangzhou                                       |
| Repair: Added partition to metastore mydb.person:region=cn-shanghai                                       |
+-----------------------------------------------------------------------------------------------------------+

現在我們就可以開心的對所有地域的資料進行聯合查詢了 ?

mysql> select * from person limit 5;
+------+-------+------+-------------+
| id   | name  | age  | region      |
+------+-------+------+-------------+
|    1 | james |   10 | cn-beijing  |
|    2 | bond  |   20 | cn-beijing  |
|    3 | lucy  |   30 | cn-beijing  |
|    4 | lily  |   40 | cn-beijing  |
|    5 | trump |   10 | cn-hangzhou |
+------+-------+------+-------------+
5 rows in set (0.43 sec)

mysql> select region, count(*) cnt from person group by region;
+-------------+------+
| region      | cnt  |
+-------------+------+
| cn-beijing  |    4 |
| cn-hangzhou |    4 |
| cn-shanghai |    4 |
+-------------+------+
3 rows in set (0.18 sec)

總結

在這篇文章裡面，我們介紹了一種通過 DataLakeAnalytics, OSS, DataX 進行跨地域資料分析的方法。限於篇幅的原因方案的很多細節沒有進一步優化，比如我們其實可以對資料進行進一步按天分割槽，這樣每天同步的資料可以更少，效率更高；再比如我們沒有介紹如何週期性的進行資料同步，用crontab? 還是什麼排程系統？這些就留給讀者自己去探索了。