基于DataLakeAnalytics 的数据湖实践是怎样的

发布时间:2021-12-16 16:49:50 作者:柒染
来源:亿速云 阅读:116

基于DataLakeAnalytics 的数据湖实践是怎样的,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。

开通DLA

在开始之前我们要有一个 DLA 的账号,目前 DLA 正在公测,直接申请试用就好了。试用审批成功之后,你会获得一个用户名和密码, 然后在控制台登录就可以使用:

基于DataLakeAnalytics 的数据湖实践是怎样的cdn.nlark.com/lark/0/2018/png/4867/1535975617974-a6185b92-9e74-4e6e-9730-e23858a136ad.png">

或者如果你是极客,更偏爱命令行,你也可以使用普通的 MySQL 客户端就可以连接 DLA 了:

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

在这篇文章里面,我会使用 MySQL 命令行给大家演示 DLA 的功能。

另外你还需要在您的OSS上准备一些测试数据, 我这里准备的是著名的 TPCH 测试数据集。

用DLA分析OSS上的数据

DLA 是一个以 SQL 作为查询语言的数据湖引擎,为了能够让 DLA 能够对 OSS 上的数据进行查询,我们需要以某种方式告诉 DLA 我们 OSS 数据的结构。为了让用户使用更方便,DLA 使用了传统的 数据库, 的概念来维护这些数据的元信息,也就说,OSS的文件结构的数据映射到 DLA 变成了一个数据库和一堆表。

TPCH 数据集来举个例子,我们知道 TPCH 数据集里面包含了如下几块信息: 用户(customer), 订单(orders), 订单的详情(lineitem) 等等,这些数据整体属于一块业务,我们建立一个数据库来对应:

CREATE SCHEMA oss_tpch with DBPROPERTIES(
  CATALOG = 'oss',
  LOCATION = 'oss://public-datasets-cn-hangzhou/tpch/1x/'  
);

这每块数据对应到OSS上一个目录的多个文件,拿 订单 来说,它对应的是 orders_text 目录下面的 1 个文件(这个例子里面只有一个文件,实际使用中,这里可以有多个文件):

基于DataLakeAnalytics 的数据湖实践是怎样的

我们把这个 orders_text 目录映射到我们的数据库 oss_tpch 下面的一张表:

use oss_tpch;

CREATE EXTERNAL TABLE IF NOT EXISTS orders (
    O_ORDERKEY INT, 
    O_CUSTKEY INT, 
    O_ORDERSTATUS STRING, 
    O_TOTALPRICE DOUBLE, 
    O_ORDERDATE DATE, 
    O_ORDERPRIORITY STRING, 
    O_CLERK STRING, 
    O_SHIPPRIORITY INT, 
    O_COMMENT STRING
) 
ROW FORMAT DELIMITED FIELDS TERMINATED BY '|' 
STORED AS TEXTFILE 
LOCATION 'oss://public-datasets-cn-hangzhou/tpch/1x/orders_text/';

这样我们就可以通过 DLA 对OSS上的进行数据分析了, 比如我们先来查个前十条看看:

mysql> select * from orders limit 10;
+------------+-----------+---------------+--------------+-------------+-----------------+-----------------+----------------+---------------------------------------------------------------------------+
| o_orderkey | o_custkey | o_orderstatus | o_totalprice | o_orderdate | o_orderpriority | o_clerk         | o_shippriority | o_comment                                                                 |
+------------+-----------+---------------+--------------+-------------+-----------------+-----------------+----------------+---------------------------------------------------------------------------+
|          1 |   3689999 | O             |    224560.83 | 1996-01-02  | 5-LOW           | Clerk#000095055 |              0 | nstructions sleep furiously among                                         |
|          2 |   7800163 | O             |     75388.65 | 1996-12-01  | 1-URGENT        | Clerk#000087916 |              0 |  foxes. pending accounts at the pending, silent asymptot                  |
|          3 |  12331391 | F             |    255287.36 | 1993-10-14  | 5-LOW           | Clerk#000095426 |              0 | sly final accounts boost. carefully regular ideas cajole carefully. depos |
|          4 |  13677602 | O             |     43119.84 | 1995-10-11  | 5-LOW           | Clerk#000012340 |              0 | sits. slyly regular warthogs cajole. regular, regular theodolites acro    |
|          5 |   4448479 | F             |    125809.76 | 1994-07-30  | 5-LOW           | Clerk#000092480 |              0 | quickly. bold deposits sleep slyly. packages use slyly                    |
|          6 |   5562202 | F             |      56408.2 | 1992-02-21  | 4-NOT SPECIFIED | Clerk#000005798 |              0 | ggle. special, final requests are against the furiously specia            |
|          7 |   3913430 | O             |    240358.24 | 1996-01-10  | 2-HIGH          | Clerk#000046961 |              0 | ly special requests                                                       |
|         32 |  13005694 | O             |    136666.23 | 1995-07-16  | 2-HIGH          | Clerk#000061561 |              0 | ise blithely bold, regular requests. quickly unusual dep                  |
|         33 |   6695788 | F             |    183460.23 | 1993-10-27  | 3-MEDIUM        | Clerk#000040860 |              0 | uriously. furiously final request                                         |
|         34 |   6100004 | O             |     52842.63 | 1998-07-21  | 3-MEDIUM        | Clerk#000022278 |              0 | ly final packages. fluffily final deposits wake blithely ideas. spe       |
+------------+-----------+---------------+--------------+-------------+-----------------+-----------------+----------------+---------------------------------------------------------------------------+
10 rows in set (0.21 sec)

我们再来看看用户 36901 的前十条订单:

mysql> select * from orders where o_custkey= '36901' limit 10;
+------------+-----------+---------------+--------------+-------------+-----------------+-----------------+----------------+------------------------------------------------------------------+
| o_orderkey | o_custkey | o_orderstatus | o_totalprice | o_orderdate | o_orderpriority | o_clerk         | o_shippriority | o_comment                                                        |
+------------+-----------+---------------+--------------+-------------+-----------------+-----------------+----------------+------------------------------------------------------------------+
|    1243264 |     36901 | F             |    103833.45 | 1992-03-23  | 2-HIGH          | Clerk#000000922 |              0 | nts haggle. even, even theodolites are. blithely                 |
|    1274530 |     36901 | O             |    181977.58 | 1997-04-29  | 2-HIGH          | Clerk#000000232 |              0 | bold foxes along the carefully expres                            |
|    1599527 |     36901 | F             |    322352.11 | 1993-10-16  | 2-HIGH          | Clerk#000000674 |              0 | the slyly even dependencies.                                     |
|    1837477 |     36901 | F             |    101653.62 | 1993-05-27  | 5-LOW           | Clerk#000000891 |              0 | lyly special requests. express foxes sleep fu                    |
|    1994082 |     36901 | O             |     77952.78 | 1995-07-05  | 3-MEDIUM        | Clerk#000000525 |              0 | luffily ironic courts. bold, e                                   |
|    2224802 |     36901 | F             |    243852.76 | 1993-01-14  | 1-URGENT        | Clerk#000000827 |              0 | sly final requests. pending, regular ideas among the furiously u |
|    4957636 |     36901 | F             |      5741.32 | 1992-05-20  | 5-LOW           | Clerk#000000230 |              0 | ackages. fluffily even packages solve carefully dolphins. unusua |
|    5078467 |     36901 | F             |    119823.03 | 1994-04-29  | 4-NOT SPECIFIED | Clerk#000000402 |              0 |  regular asymptotes cajo                                         |
|    5173859 |     36901 | F             |    103624.02 | 1994-05-28  | 3-MEDIUM        | Clerk#000000335 |              0 |  regular dependencies poach quickly. unusu                       |
|    5525574 |     36901 | O             |     136098.0 | 1998-02-16  | 4-NOT SPECIFIED | Clerk#000000425 |              0 | cial pinto beans wake. slyly even warthogs use. bo               |
+------------+-----------+---------------+--------------+-------------+-----------------+-----------------+----------------+------------------------------------------------------------------+
10 rows in set (1.07 sec)

再来查一查订单量最多的前是个人:

mysql> select o_custkey, count(*) as cnt from orders group by o_custkey order by cnt desc limit 10;
+-----------+------+
| o_custkey | cnt  |
+-----------+------+
|      3451 |   41 |
|    102022 |   41 |
|    102004 |   41 |
|     79300 |   40 |
|    117082 |   40 |
|    122623 |   40 |
|     69682 |   39 |
|    143500 |   39 |
|    142450 |   38 |
|     53302 |   38 |
+-----------+------+
10 rows in set (2.69 sec)

恩,这些人就是我们要重点服务好的客户啊,我们要把这些用户的ID回写到前台的 RDS 数据库里面让我们的营销同学做一些针对性的营销活动,没问题,DLA支持把分析好的数据回流到RDS

数据回流 RDS

映射 MySQL 数据库信息进 DLA

要把分析好的数据回流到RDS我们首先一种机制来告诉 DLA 数据回流的目的地,得益于DLA统一的设计,我们就像映射 OSS 的数据一样,我们映射一个 MySQL 数据库进来就好了,比如我们要把数据写到如下的数据库里面:

 mysql -habcde.mysql.rds.aliyuncs.com -P3306 -uhello -pworld -Dmarketing

那么我们在 DLA 里面建一个映射的库:

CREATE SCHEMA `mysql_marketing` WITH DBPROPERTIES 
( 
  CATALOG = 'mysql', 
  LOCATION = 'jdbc:mysql://abcde.mysql.rds.aliyuncs.com:3306/marketing',
  USER='hello',
  PASSWORD='world',
  INSTANCE_ID = '<your-rds-instance-id>',
  VPC_ID = '<your-vpc-id-where-your-rds-lives>'
);

这里需要解释一下的是 VPC_IDINSTANCE_ID, 我们知道为了安全的原因在阿里云上购买的 RDS 我们一般都会把它放在一个单独的VPC里面,以保证只有我们自己可以访问,这里为了让 DLA 能够访问到我们的 MySQL 数据库以进行数据回流,我们需要告诉 DLA 这个 RDS的相关信息。

其中 INSTANCE_IDVPC_ID 在 RDS的详情页面都可以找到, 比如 VPC_ID :

基于DataLakeAnalytics 的数据湖实践是怎样的

由于 RDS 的安全组会对访问的来源IP进行控制,我们需要把DLA相关的地址段 100.104.0.0/16 IP地址段加入到你的RDS的白名单列表。

到这里为止,准备工作就完成了,我们的 mysql 数据库建好了。

映射 MySQL 结果表进 DLA

我们要保存的结果很简单,就是下单量前 10 的用户, 这个表在 MySQL 数据库里面的建表语句如下:

create table top10_user (
    custkey int,
    order_cnt bigint
);

而为了把这个表映射进 DLA 我们建一个对应的表,建表语句几乎一样:

use mysql_marketing;
create external table top10_user (
    custkey int,
    order_cnt bigint
);

ETL

下面我们就可以把查出来的数据进行回流了:

mysql> insert into mysql_marketing.top10_user
    -> select o_custkey, count(*) as cnt from oss_tpch.orders
    -> group by o_custkey order by cnt desc limit 10;
+------+
| rows |
+------+
|   10 |
+------+
1 row in set (4.71 sec)

mysql> select * from mysql_marketing.top10_user;
+---------+-----------+
| custkey | order_cnt |
+---------+-----------+
|  143500 |        39 |
|  102004 |        41 |
|   53302 |        38 |
|    3451 |        41 |
|  122623 |        40 |
|  129637 |        38 |
|  102022 |        41 |
|  117082 |        40 |
|   69682 |        39 |
|   79300 |        40 |
+---------+-----------+
10 rows in set (0.14 sec)

看完上述内容,你们掌握基于DataLakeAnalytics 的数据湖实践是怎样的的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注亿速云行业资讯频道,感谢各位的阅读!

推荐阅读:
  1. 数据驱动制造业转型-黑湖智造
  2. Flink+Iceberg 数据湖探索与实践是怎样的

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

datalakeanalytics

上一篇:向kafka集群发布记录的kafka客户端怎么实现

下一篇:怎么解析Python中的Dict

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》