SQL执行长时间任务的可选方案

在有些应用程序中,程序的执行可能需要很长的时间,针对这种情况我们在做前后应用时可能会比较棘手,比如建立一个普通的连接对象,然后执行一个长时间的任务,比如数据的同步操作,一般单线程的程序在后台程序执行期间即出现假死现象,对于一些希望在后台执行的长时间任务,在SQL中可以考虑用作业的方式进行解决,建立完成作业后,我们在前台只要调用指定任务就可以了,这里需要注意下面几个问题

1) 在SQL中任务数据库的任务是放在msdb库中统一进行管理的,所以前台应用若要调用任务,则需要建立一个到msdb数据库的连接,另外要保证建立的连接有足够执行任务的权限.
       执行权限默认授予 msdb 数据库中的 public 角色。可执行此存储过程而且是 sysadmin 固定角色成员的用户可以启动任何作业。不是 sysadmin 角色成员的用户使用 sp_start_job 只能启动他/她所拥有的作业。
当 sysadmin 固定服务器角色成员的用户唤醒调用 sp_start_job 时,sp_start_job 将在 SQL Server 服务正在其中运行的安全上下文中执行。当用户不是 sysadmin 固定服务器角色的成员时,sp_start_job 将模拟 SQL Server 代理代理帐户,而该帐户是通过 xp_sqlagent_proxy_account 指定的。如果代理帐户不可用,则 sp_start_job 将失败。只有 Microsoft? Windows NT? 4.0 和 Windows 2000 有上述情况。在 Windows 9.x 上没有模拟,而且 sp_start_job 总是在启动 SQL Server 的 Windows 9.x 用户的安全上下文中执行。

2) 调用具体任务时需要用到扩展的存储过程sp_start_job ,比如要执行一个作业名称为"同步数据"的作业,其语法为
USE msdb
EXEC sp_start_job @job_name = '同步数据'

程序调用时,比如存在一个到msdb数据库的连接对象Connection为cn
cn.execute " EXEC sp_start_job @job_name = '同步数据' "

3)在任务执行期间,如果你试图再次执行同一个任务,程序会报错,所以非常有必要适时知道某一具体作业的执行状态,此时需要用到另外一个存储过程即sp_help_job
关于此过程的详细使用可以查看联机帮助,注意current_execution_status会返回任务的执行状态,
0   只返回那些空闲的或挂起的作业,执行完成后即返回状态0。
1   正在执行。
2   正在等待线程。
3   在两次重试之间。
4   空闲。
5   挂起。
7   正在执行完成操作。
在任务有多步的情况下current_execution_step会返回当前正在执行第几步任务 ,last_run_outcomeint返回作业上一次运行时所得到的结果:
0 = 失败
1 = 成功
3 = 取消
5 = 未知

4)停止作业的执行可以用sp_stop_job存储过程

5)另外如 sp_add_job、sp_delete_job、sp_update_job也有必要对其了解

6)扩展:执行 sp_helptext 'sp_start_job'看看SQL到底都做了些什么

知道上面这些内容对执行长时间的SQL任务就很有帮助了    
<think>嗯,用户想了解Hive和Presto执行引擎的区别。首先我得回想一下两者的基本概念。Hive是基于Hadoop的数据仓库工具,通常用于处理大规模数据,而Presto是Facebook开发的分布式SQL查询引擎,适合交互式查询。 那它们的执行引擎有什么不同呢?Hive默认使用MapReduce,但后来有了Tez和Spark作为替代。MapReduce比较适合批处理,延迟高,但稳定可靠。而Tez和Spark在性能上有所提升,尤其是Tez的有向无环图优化,减少中间写入,速度更快。但Hive整体还是适合离线处理,不适合实时查询。 Presto则完全不同,它用的是基于内存的并行查询引擎,不需要把中间数据写入磁盘,这样大大减少了IO开销,所以查询速度快,适合交互式分析。不过内存管理是个挑战,如果数据量太大或者查询复杂,容易导致内存不足的问题。 用户可能需要知道两者的适用场景。比如Hive适合ETL任务,处理大量数据,对延迟不敏感的情况。而Presto适合需要快速响应的ad-hoc查询,但数据量不能太大。另外,Hive支持ACID和事务,适合需要数据一致性的事务处理,而Presto在这方面支持有限,可能不适合更新操作。 还要考虑语法和兼容性。Hive的HQL和Presto的SQL略有差异,比如时间函数或复杂类型处理,用户迁移时需要注意。资源管理方面,Hive通常依赖YARN,而Presto有自己的资源调度机制,可能更灵活,但在集群资源紧张时表现不同。 用户可能是在做技术选型,需要根据具体的业务需求来决定。比如他们处理的数据量、对延迟的要求、是否需要事务支持等因素。需要提醒用户根据实际场景权衡,比如离线分析选Hive,实时查询用Presto,或者两者结合使用。</think>以下从执行引擎角度对比HIVE与Presto的核心区别,采用分步解析: --- ### **1. 计算模型差异** #### HIVE $$ MapReduce/Tez/Spark \rightarrow 磁盘存储中间结果 $$ - **批处理模式**:默认采用MapReduce计算框架(可替换为Tez/Spark) - **执行特点**:每个Stage将中间结果写入HDFS磁盘,适合大规模数据集但延迟高 - **典型延迟**:分钟级到小时级 #### Presto $$ Pipeline \rightarrow 内存流水线处理 $$ - **MPP架构**:Massively Parallel Processing(大规模并行处理) - **执行特点**:通过内存流水线连续传递数据,避免磁盘IO - **典型延迟**:亚秒级到分钟级 --- ### **2. 资源管理对比** | 维度 | HIVE | Presto | |------------|------------------------------|-------------------------------| | 内存使用 | 按需分配,溢出到磁盘 | 严格内存限制,OOM直接报错 | | 任务隔离 | 通过YARN队列隔离 | 基于查询优先级队列 | | 弹性伸缩 | 受YARN资源限制 | 动态调整Worker节点 | --- ### **3. SQL支持差异** #### 语法兼容性 - **HIVE**:支持完整ACID事务(Hive 3+),复杂UDF,`LATERAL VIEW`等特有语法 - **Presto**:兼容ANSI SQL标准,但对UDF支持较弱 #### 典型函数示例 ```sql /* HIVE特有 */ SELECT TRANSFORM(col) USING 'python_script' FROM table; /* Presto标准 */ SELECT approx_distinct(user_id) AS uv FROM logs; ``` --- ### **4. 数据源支持** | 数据源类型 | HIVE支持 | Presto支持 | |-----------|---------|-----------| | HDFS | ✔️原生 | ✔️通过Connector | | S3 | ✔️ | ✔️ | | RDBMS | ✖️ | ✔️ | | Kafka | ✖️ | ✔️ | --- ### **5. 性能优化策略** #### HIVE优化手段 $$ CBO_{cost-based} + PartitionPruning_{分区裁剪} + Vectorization_{向量化} $$ - 需要手动统计`ANALYZE TABLE` - 适合可预测的固定查询模式 #### Presto优化手段 $$ DynamicFiltering_{动态过滤} + JoinReordering_{连接重排} + PredicatePushdown_{谓词下推} $$ - 自动优化复杂Join顺序 - 适合即席查询(ad-hoc) --- ### **6. 适用场景建议** 1. **选择HIVE当**: - 需要处理PB级超大数据集 - 执行长时间ETL作业 - 要求严格的数据一致性(事务支持) 2. **选择Presto当**: - 需要亚秒级响应的交互式查询 - 执行多数据源联邦查询 - 集群内存资源充足 实际生产中常组合使用:用HIVE做数据清洗,Presto提供查询服务,形成$ Lambda_{混合架构} $方案
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值