基于 DataLakeAnalytics 做跨地域的数据分析

╰+攻爆jí腚メ 2022-01-12 23:41 274阅读 0赞

在阿里云上，很多客户的应用都是多地域部署的, 比如在北京(cn-beijing)的地域部署一个应用让北方的客户访问快一点，同时在杭州(cn-hangzhou)地域部署一份让南方的客户访问快一点。多地域部署之后，业务数据被拆成了多份，而各个地域的数据库都是独立的，网络又不通，给总体业务数据的分析造成了困难。今天我给大家介绍一套基于 DataLakeAnalytics, OSS, DataX 等几个阿里云产品的跨地域数据分析的解决方案。

其实云产品本身(比如我们 DataLakeAnalytics 自己)也有跨地域数据分析的需求，这个方案也同样适用。这个方案本来就是为了分析 DataLakeAnalytics 自己的业务数据而探索出来的。

方案概览  
我们知道各个地域的RDS是不通的，除非你开公网访问权限(有很大的安全风险，不推荐), 而且即使你开公网，要对多个数据库里面的数据进行联合分析也不是一件容易的事情；而且这种数据分析的需求我们不希望它占用太多的预算。

我们的方案是把各个地域的数据都同步到同一个地域的OSS上面去，然后用 DataLakeAnalytics 进行联合分析。这个方案的优点在于 OSS 存储收费非常便宜， DataLakeAnalytics 也是按查询量收费的，你平时不查询的时候一分钱都不用花。总体方案如下图:

![基于 DataLakeAnalytics 做跨地域的数据分析][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上面的数据:

![基于 DataLakeAnalytics 做跨地域的数据分析][DataLakeAnalytics 1]

文件里面数据大概是这样的:

9|ethan|10  
10|julian|20  
11|train|30  
12|wally|40  
完成了一个地域的数据搬运之后，其它地域都可以照葫芦画瓢，唯一需要注意的地方是，虽然 MySQL 数据是各个 地域 的数据，但是 OSS 要用同一个根目录 person ，因为我们要做数据汇集嘛，把几个地域的数据汇集完成之后，person 目录的结构大概是这样的:

![基于 DataLakeAnalytics 做跨地域的数据分析][DataLakeAnalytics 2]

使用 DataLakeAnalytics 分析汇聚后的OSS数据  
下面的分析就可以交给 DataLakeAnalytics 了，分析OSS上的数据是 DataLakeAnalytics 的拿手好戏，在开始之前我们要有一个 DataLakeAnalytics 的账号，目前 DataLakeAnalytics 正在公测，直接申请试用就好了。试用审批成功之后，你会获得一个用户名和密码, 然后在控制台登录就可以使用:

![基于 DataLakeAnalytics 做跨地域的数据分析][DataLakeAnalytics 3]

或者如果你是极客，更偏爱命令行，你也可以使用普通的 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? 还是什么调度系统？这些就留给读者自己去探索了。

转载于:https://blog.51cto.com/14031893/2356891

[DataLakeAnalytics]: https://s1.51cto.com/images/blog/201903/01/aca3a12b3115731d40b8d355b7f9d2ad.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[DataLakeAnalytics 1]: https://s1.51cto.com/images/blog/201903/01/b1f0b2fb71576ec714a0d3c54131b39d.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[DataLakeAnalytics 2]: https://s1.51cto.com/images/blog/201903/01/63e91fb1dc0111631b971ac4b249263c.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[DataLakeAnalytics 3]: https://s1.51cto.com/images/blog/201903/01/bfb90baf388647f82ba94556cc745698.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=