给技术新人的ODPS优化建议

给技术新人的ODPS优化建议

数据开发基本都是从陌生到熟悉,但是写多了就会发现各种好用的工具/函数,也会发现各种坑,本文分享了作者从拿到数据到数据开发到数据监控的一些实操经验。

写在前面

本文档是组内的一份算法ODPS离线开发分享,仅列出了这些年积累下来的一些重要经验和结论,特别是在算法日常数据处理和调度中的技巧和配置方法,至于具体为什么,建议大家去阿里云官网查看底层map reduce以及data flow的工作原理,会有更加深刻的体会:)
参考文档:https://help.aliyun.com/document_detail/89993.html

各种join的用法篇

输入数据:zhule_a, zhule_b两张测试表,具体schema和数据如下(后续为了说明重复数据带来的问题,会在a和b表中各重复插入一条key=2,ds='20220930'的数据):
read zhule_a;
key
ds
1
20220930
2
20220930
1
20221001
2
20221001
3
20221001

read zhule_b;

key
ds
2
20220930
3
20220930
1
20221001
2
20221001
3
20221001
4
20221001
5
20221001

 

Join/Inner Join
用法:Returns the rows that have matching column values in both the left table and the right table based on the join condition。一句话:找出两个表中共同的部分,注意笛卡尔积下面的性能优化
1、每张表先选出来subset,然后再join。

-- better way to perform join, select small range of data first.
SELECT A.*, B.*
FROM
(SELECT * FROM A WHERE ds='20180101') A
JOIN
(SELECT * FROM B WHERE ds='20180101') B
ON a.key = b.key;
注意:在进行各种jion操作前,一定要自查左右表是否有重复数据,否则最终重复的结果会以笛卡尔积的数量增长,比如左右表各有两条重复数据,那么join后重复数据会多达4条!
图片
2、最好的情况下是大表join小表,然后利用mapjoin来实现。
官方解释:In the map stage, MAPJOIN loads all data in the specified tables into the memory of the program that performs the JOIN operation. The tables specified for MAPJOIN must be small tables, and the total memory occupied by the table data cannot exceed 512 MB.
Limits on JOIN operations in MAPJOIN:
  • The left table in a LEFT OUTER JOIN operation must be a large table.

  • The right table in a RIGHT OUTER JOIN operation must be a large table.

  • MAPJOIN cannot be used in a FULL OUTER JOIN operation.

  • The left or right table in an INNER JOIN operation can be a large table.


SELECT  /*+ MAPJOIN(b) */
        a.*
FROM    test_a a
JOIN test_b b
ON      a.user_key = b.user_key
;
//就是在sql语句前加一个标记说这是mapjoin,把小表别名写在括号里
一个有趣的点:
当我们用mapjoin时,除了正常的等式,mapjoin还支持不等式,如下面的例子:
图片

 

Left Join

用法:A LEFT JOIN operation first takes the Cartesian product of the rows in Table A and Table B and returns all the rows of Table A and rows in Table B that meet the join condition. If the join condition finds no matching rows in Table B for a row in Table A, the row in Table A is returned in the result set with NULL values in each column from Table B.一句话:输出左表的所有记录,以及右表中符合关联条件的数据。右表中不符合关联条件的行,输出NULL。
  1. 一定要保留左表的内容是,可以选择用left join,例如加入key_attrs

  2. Right Join和Left Join没有本质区别,建议定义好左表后都利用Left Join来执行

  3. 如果右表有重复数据的情况,那么最终left join的结果会有重复

图片

 

Left Semi Join

用法:A LEFT SEMI JOIN operation returns only the rows in Table A that have a matching row in Table B. 对于左表中的一条数据,如果右表存在符合关联条件的行,则输出左表,否则不输出
  1. 当右表没有重复数据时,和Join是一致的,只会保留相同的列下来

  2. left semi join并不会返回右表B中的任何数据,所以你没法在where条件中指定关于右表B的任何筛选条件,下面得例子能够有更加清晰的对比(例子引用于开源论坛):

employee (2 columns - e_id and e_name)
10, Tom
20, Jerry 
30, Emily

employee_department_mapping (2 columns - e_id and d_name)
10, IT
10, Sales
20, HR

-- inner join results
SELECT e.e_id, e.e_name, d.d_name FROM 
employee e INNER JOIN employee_department_mapping d
on e.e_id = d.e_id
-- results
10, Tom, IT
10, Tom, Sales
20, Jerry, HR

-- left semi join results
SELECT e.e_id, e.e_name, d.d_name FROM 
employee e LEFT SEMI JOIN employee_department_mapping d
on e.e_id = d.e_id
-- results
10, Tom, IT
20, Jerry, HR

 

Left Anti Join
用法:A LEFT ANTI JOIN operation returns only the rows in Table A that have no matching rows in Table B.一句话:对于左表中的一条数据,如果右表中不存在符合关联条件的数据,则输出左表。
  1. 最好用的场景就是找出两表的差异部分;

  2. 算法日常调度时可以用于每日新增修改商品的提取,将关键字段放到ON条件中就行

图片

 

Full Join

用法:A FULL JOIN operation takes the Cartesian product of the rows in Table A and Table B and returns all the rows in Table A and Table B, whether the join condition is met or not. In the result set, NULL values are returned in the columns from the table that lacks a matching row in the other table.一句话:输出左表和右表的所有记录,对于不符合关联条件的数据,未关联的另一侧输出NULL
  1. 在有增删改情况下更新下游最新数据时,非常好用,但是知道的人比较少
举个栗子,其中today_feat是今天新计算的feature table,yest_feat是上一个分区的feature:

SELECT  COALESCE(a.main_image_url,b.main_image_url) AS main_image_url
        ,COALESCE(a.embedding,b.embedding) AS embedding
FROM    today_feat a
FULL JOIN yest_feat b
ON      a.main_image_url = b.main_image_url

其中full jion的效果如下,正好满足new,old,updated feature的更新,配合COALESCE很丝滑:

图片

合理设置Mapper和Reducepriority

 

set odps.instance.priority

目前ODPS更新后只能在开发dev空间生效,通过设置优先级能够一定程度提升排队任务的执行优先级,但是目前线上正式环境不会生效了,建议大家优化好自己健康分,同时对于重要的线上调度任务设置好基线,保证产出的时效。

 

set odps.sql.mapper.split.size

官方指导:Changes the input data amount of each Map worker, which is the split size of the input file. You can use this property to indirectly control the number of workers at each Map stage (default value: 256, unit: MB)。一句话:如果小文件很多,可以调大split.size的数值,这样可以保证在有限资源下更容易申请到Mapper,提升执行的效率。如果资源丰富,想要更多Mapper资源,那就调小split.size的数值,可以申请到更多的Mapper,提升执行效率。酌情处理哟~
举个栗子: 

-- original sql
CREATE TABLE if not EXISTS tmp_zhl_test LIFECYCLE 1 AS 
SELECT sig, venture, seller_id, COUNT(product_id) as cnt 
FROM sku_main_image_sig
WHERE LENGTH(sig) > 10 --some bad cases may have weird sigs like '#NEXT#'
GROUP BY sig, venture, seller_id
HAVING cnt>2
;
如果是默认设置,553 mappers 和 184 reducers 被分配,大约耗时 3m18s:
图片
在资源充沛的情况下,我们设置odps.sql.mapper.split.size=64, 可以申请到更多的Mapper去处理文件的分片,同时更多的reducer也可以被分配到,同样的SQL代码执行时间降为: 2m34s. 
同样的,如果你的数据量超大,但是每条数据本身很小,同时空间资源也有限(毕竟现在资源管控比较严格),与其等待9999个Mapper被分配,你可以尝试设置odps.sql.mapper.split.size=2048(甚至更大)去减少需要分配的Mapper数量,让任务能够快速执行:)

 

set odps.sql.reducer.instances

显示设置reducer的数量(默认值从0到4000),不设置的话会根据任务动态分配,设置后就会分配设置数量的reducer。同样是上面的例子,当我们设置odps.sql.reducer.instances=1000, 耗时变为2m

 

set odps.sql.mapper(reducer).memory

设置每个Map/Reducer worker的内存(默认值是1024,可以设置为256到12288之间的值)一般我们不需要特别设置这个值,但是当任务报错并说「data exceeds the memory」时,可以根据个人情况来设置这个选项。

在Python UDF中使用第三方库

在这部分主要和大家分享下如何在ODPS的python udf安装需要的第三方库(如numpy,opencv等),以及如果有不同依赖库之间的版本不兼容问题时的有效解决方法。

 

Upload&Call Package

  • 需要下载第三方库的安装包xxx.whl,可以直接下载到自己的电脑上面,这样可以在离线环境验证多个版本的一致性(下面介绍)。一般来说我们需要去看安装包需要的python版本号以及兼容机器环境,一般来说都是cp37-cp37m or py2.py3-none-any在中间,然后末尾是x86_64的安装包;

  • 本地直接将xxx.whl转换为xxx.zip,利用命令「mv xxx.whl xxx.zip」就行

  • 将zip资源文件上传到ODPS对应的环境

  • 在你的UDF中,利用下面的代码指定资源包的路径和引用(直接copy就行)

def include_package_path(res_name, lib_name):    
    archive_files = get_cache_archive(res_name)
    dir_names = sorted([os.path.dirname(os.path.normpath(f.name)) for f in archive_files
                        if '.dist_info' not in f.name], key=lambda v: len(v))
    for dir_name in dir_names:
        if dir_name.endswith(lib_name):
            sys.path.insert(0, os.path.dirname(dir_name))
            break
        elif os.path.exists(os.path.join(dir_name, lib_name + '.py')):
            sys.path.insert(0, os.path.abspath(dir_name))
            break

class PostProcess(BaseUDTF):
    def __init__(self):
        include_package_path('opencv_python-3.4.0.zip','cv2')
        include_package_path('numpy-1.16.6.zip','numpy')
  • python UDF写完后,就可以在创建函数里面的Resources里直接将你的资源名写进去,这样在流程启动后,你的资源才会被有效调用起来。

图片
  • python UDF默认的版本是2.x的,如果你的python版本是3.x,那么需要在ODPS运行前加入下面的指令;同时,部分功能是需要打开沙箱的,所以如果报错的话,可以加入第二行的沙箱命令。
set odps.sql.python.version = cp37; --use python 3.7, default is 2.x version
set odps.isolation.session.enable = true; 

 

Solve Compatibility Issue

有时候在使用多个库时,可能会出现不同版本之间的冲突问题(比如在使用opencv库的时候,如果对应的numpy版本不兼容的话,就会报错)。所以在上传多个库的资源包前,需要先确认版本间的兼容性。一般非常不建议大家用不同版本去试,而应该先在本地确定版本后再上传。可行的步骤如下:
  • 在本地可以用类似conda的工具搭建一个虚拟环境

  • 在本地用pip或者conda install来安装你需要的三方库

  • 查询你下载的三方库以及依赖库的版本,比如python-opencv的话可以打印cv2.__version__

  • 把对应版本的xxx.whl包按照上面的方法现在下来并且上传到ODPS资源中进行依赖

发布任务时的一些额外建议

  • 发布任务配置时,可以灵活使用exclude和extra来去掉或添加你想要的依赖。其中exclude可以去掉你中间产出的临时表,而extra可以帮你增加虽然不在代码里但是希望依赖的上游表(这在汇总不同上游表数据写入下游对应分区并且希望同时产出下游数据时很有用)。
--exclude input or output tables (especially those tmp tables)--@exclude_input=lsiqg_iqc_sku_product_detection_result--@exclude_output=lsmp_sku_image_url_bizdate
-- include input or output tables (especially those separate venture tables)--@extra_input=lsiqg_iqc_sku_product_detection_result--@extra_output=lsmp_sku_image_url_bizdate
  • 如果在SQL代码过程中你需要使用临时表来过渡中间产出的数据(避免SQL嵌套过于严重,影响运行效率),建议一定在临时表中加入一个时间戳,ex. lsiqg_iqc_input_tmp_${bizdate}不然在补数据或者遇到任务堵塞两个任务同时在调度时,或产生overwrite的一系列问题。
  • 如果存在上游表存在多个分区,但是每个分区处理逻辑一样的话(比如不同国家的分区表处理逻辑其实一样),非常建议在第一步里就把不同分区表的数据汇总起来,可以重新增加一个分区(如venture)来存放融合后的数据。如下示例:

INSERT OVERWRITE TABLE sku_main_image_sig PARTITION (ds = '${bizdate}',venture)
SELECT  id
        ,image_url
        ,venture
FROM    (
            SELECT  id
                    ,image_url
                    ,'ID' AS venture
            FROM    auction_image_id
            WHERE   ds = MAX_PT('auction_image_id')
            UNION
            SELECT  id
                    ,image_url
                    ,'PH' AS venture
            FROM    auction_image_ph
            WHERE   ds = MAX_PT('auction_image_ph')
            UNION
            SELECT  id
                    ,image_url
                    ,'VN' AS venture
            FROM    auction_image_vn
            WHERE   ds = MAX_PT('auction_image_vn')
            UNION
            SELECT  id
                    ,image_url
                    ,'SG' AS venture
            FROM    auction_image_sg
            WHERE   ds = MAX_PT('auction_image_sg')
            UNION
            SELECT  id
                    ,image_url
                    ,'MY' AS venture
            FROM    auction_image_my
            WHERE   ds = MAX_PT('auction_image_my')
            UNION
            SELECT  id
                    ,image_url
                    ,'TH' AS venture
            FROM    auction_image_th
            WHERE   ds = MAX_PT('auction_image_th')
        ) union_table
;
  • 对于重要的数据表,一定要设置监控,防止数据丢失、不正常产出等问题,具体的方法又可以分两类:

    • 设置任务基线(baseline)来保证任务优先级,这样调度的时间更有保障

    • 设置warning的短信/电话或者DQC的监控规则来具体监控数据

简单的任务可以直接在任务中心查看详情中设置:

图片
图片
对于更加细致的数据层面监控可以通过DQC平台进行配置,比如无数据产出,数据波动,数据最大/最小值监控等。
图片

写在最后

数据开发基本都是从陌生到熟悉,但是写多了就会发现各种好用的工具/函数,也会发现各种坑,个人拿到数据到数据开发到数据监控的一些经验是:
  1. 拿到数据第一时间验证数据的重复性,有效性;如果是组内问题就反馈,上游链路问题就自己过滤;

  2. 写完数据的每一部分都先验证合理性,这样会提高最终数据的成功率;

  3. 一般节点上线后,会主动去观察3-4天,确保输出是符合预期的(如果会发现应该稳定的数据反而猛然增加or减少,那很可能是数据逻辑有问题);

  4. 定义合理的数据监控,可以避免数据为空,数据波动过大,数据字段不合理等问题;

Enjoy Data Engineering!!

 

作者|周慧玲(逐乐)

原文链接:https://www.cnblogs.com/88223100/p/ODPS-optimization-suggestions-for-technical-newcomers.html

本站文章如无特殊说明,均为本站原创,如若转载,请注明出处:给技术新人的ODPS优化建议 - Python技术站

(0)
上一篇 2023年4月17日
下一篇 2023年4月17日

相关文章

  • Mysql 错误问题汇总(不断更新中)

    首先,你需要了解这篇文章的主要内容,即 MySQL 常见的错误问题和解决办法的总结,可以帮助开发者更好地排查 MySQL 相关的问题。在这篇文章中,作者结合实际开发中遇到的问题,对错误进行了分类,并分别给出了相应的解决办法。 文章的开头部分通过标题将常见的 MySQL 错误问题进行了归类,包括数据操作错误、连接错误、权限问题、性能问题等等。每一个分类下,作者…

    MySQL 2023年5月18日
    00
  • MySQL数据库如何导入导出(备份还原)

    MySQL数据库备份还原攻略 MySQL数据库是一个非常流行的开源关系型数据库管理系统,它的备份还原功能也非常重要。 在备份还原的过程中,我们需要使用 mysqldump 命令来导出和导入数据库。下面是具体的步骤: 备份数据库 打开命令行终端(如Windows的CMD,或者macOS和Linux的终端); 进入MySQL的bin目录,即终端内输入cd /pa…

    MySQL 2023年5月18日
    00
  • MySQL Workbench操作方法是什么

    这篇“MySQL Workbench操作方法是什么”文章的知识点大部分人都不太理解,所以小编给大家总结了以下内容,内容详细,步骤清晰,具有一定的借鉴价值,希望大家阅读完这篇文章能有所收获,下面我们一起来看看这篇“MySQL Workbench操作方法是什么”文章吧。 Mysql Work Space 右键新建的数据库BMI,设置为此次连接的默认数据库,接下来…

    MySQL 2023年4月11日
    00
  • MySql 之UUID()

    mysql中做了个定时执行的事件,发现原来起作用,现在不行了。 调用/var/lib/mysql中的错误日志文件,发现一句: Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsaf…

    MySQL 2023年4月12日
    00
  • 缓存与数据库双写一致性几种策略分析

    作者:京东零售 于泷 一、背景 在高并发场景中,为防止大量请求直接访问数据库,缓解数据库压力,常用的方式一般会增加缓存层起到缓冲作用,减少数据库压力。引入缓存,就会涉及到缓存与数据库中数据如何保持一致性问题,本文将对几种缓存与数据库保证数据一致性的使用方式进行分析。为保证高并发性能,以下分析场景不考虑执行的原子性及加锁等强一致性要求的场景,仅追求最终一致性。…

    MySQL 2023年4月19日
    00
  • mysql下载,安装及在Navicat for MySQL工具上连接的问题

      之前一直使用的是mysql的数据库,所以总觉得对mysql的安装使用是手到擒来的事,但是因为最近需要重新安装mysql突然发现了很多问题(有点打脸)。事实证明还是有必要记录一下的。这里面我归纳了一下网上的方法和我自己的总结。 *****************************************************************…

    MySQL 2023年4月12日
    00
  • MySQL的索引详解

    MySQL的索引详解 什么是索引 索引是对数据库表中一列或多列的值进行排序的一种结构,它可以让我们更加快速地查找数据,类似于书籍的目录一样。在实际操作中,我们能够在数以千万计的数据记录中,迅速地确定符合条件的记录。 索引的种类 MySQL中常用的索引包括:B树索引、B+树索引、全文索引、哈希索引等。 B树索引:通过二叉树,把每个节点的关键字按照大小顺序依次排…

    MySQL 2023年5月19日
    00
  • MySQL磁盘碎片整理实例演示

    下面是关于MySQL磁盘碎片整理实例演示的完整攻略。 什么是MySQL磁盘碎片? MySQL是一款非常流行的开源数据库,在使用MySQL过程中,经常会发现数据库运行得越久,磁盘空间占用越大的情况。这是由于MySQL的磁盘碎片导致的。 MySQL磁盘碎片是指由于频繁的数据增删改、数据长度变化等原因,导致数据在磁盘上存储的不是连续存储的情况,而是散落在磁盘的不同…

    MySQL 2023年5月19日
    00
合作推广
合作推广
分享本页
返回顶部