成都网站建设设计

将想法与焦点和您一起共享

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

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

专注于为中小企业提供网站设计制作、成都做网站服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业绥化免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了上1000+企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。

开通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 
      -p

在这篇文章里面,我会使用 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 = '',
  VPC_ID = ''
);

这里需要解释一下的是 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 的数据湖实践是怎样的的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注创新互联行业资讯频道,感谢各位的阅读!


网站题目:基于DataLakeAnalytics的数据湖实践是怎样的
文章源于:http://chengdu.cdxwcx.cn/article/pdcjoi.html