使用Smart3D生成倾斜数据正射影像与DSM教程

版权申诉
0 下载量 96 浏览量 更新于2024-06-20 收藏 1.09MB PDF 举报
"Smart3D系列教程6详细介绍了如何利用倾斜数据生成正射影像和DSM,以及如何使用ArcGIS进行影像拼接。教程适用于已掌握基础照片三维重建技术的用户,通过Smart3D软件处理垂直拍摄的多角度、重叠度适中的像片,生成的成果包括Orthophoto和DSM,最终通过ArcGIS完成镶嵌和拼接工作。教程内容分为前言、工具材料、方法步骤和小结四个部分,旨在提升用户在三维建模和地理信息处理方面的能力。" 在本教程中,首先强调了Smart3D软件不仅能生成三维模型,还能进一步生产正射影像图和数字表面模型(DSM)。正射影像图提供了一种无透视失真的鸟瞰视图,而DSM则记录了地表所有物体的海拔信息,两者在地理信息系统(GIS)中有着广泛应用。生成这些成果的关键在于先创建三维模型,再基于模型生成正射影像和DSM。 生成模型的步骤包括导入照片、检查照片质量和在3Dview中确认照片分布。导入照片时,确保使用一组满足重建要求的垂直拍摄且多角度重叠的像片。在3Dview中检查照片分布,确保照片覆盖全面且无明显缺失。 生成正射影像图和DSM后,由于生成的成果通常会分块,因此需要使用GIS软件进行拼接。教程推荐使用ArcGIS 10.1,利用其镶嵌功能将分块的正射影像图和DSM合并为一个连续的地理信息产品。这一步骤对于集成和分析大面积的地理信息至关重要。 教程最后的小结部分总结了整个流程,强调了Smart3D与ArcGIS结合使用的高效性和实用性。通过这个系列教程的学习,用户不仅能够掌握Smart3D的基本操作,还能了解如何将生成的三维模型成果转化为更便于分析和展示的正射影像和DSM,从而增强其在地理信息领域的实践能力。
2022-12-24 上传
⼤数据常见问题之数据倾斜 什么是数据倾斜 简单的讲,数据倾斜就是我们在计算数据的时候,数据的分散度不够,导致⼤量的数据集中到了⼀台或者⼏台机器上计算,这些数据的计 算速度远远低于平均计算速度,导致整个计算过程过慢。 相信⼤部分做数据的童鞋们都会遇到数据倾斜,数据倾斜会发⽣在数据开发的各个环节中,⽐如: ⽤Hive算数据的时候reduce阶段卡在99.99% ⽤SparkStreaming做实时算法时候,⼀直会有executor出现OOM的错误,但是其余的executor内存使⽤率却很低。 数据倾斜有⼀个关键因素是数据量⼤,可以达到千亿级。 数据倾斜长的表现 以Hadoop和Spark是最常见的两个计算平台,下⾯就以这两个平台说明: 1、Hadoop中的数据倾斜 Hadoop中直接贴近⽤户使⽤使⽤的时Mapreduce程序和Hive程序,虽说Hive最后也是⽤MR来执⾏(⾄少⽬前Hive内存计算并不普 及),但是毕竟写的内容逻辑区别很⼤,⼀个是程序,⼀个是Sql,因此这⾥稍作区分。 Hadoop中的数据倾斜主要表现在ruduce阶段卡在99.99%,⼀直99.99%不能结束。 这⾥如果详细的看⽇志或者和监控界⾯的话会发现: 有⼀个多⼏个reduce卡住 各种container报错OOM 读写的数据量极⼤,⾄少远远超过其它正常的reduce 伴随着数据倾斜,会出现任务被kill等各种诡异的表现。 经验: Hive的数据倾斜,⼀般都发⽣在Sql中Group和On上,⽽且和数据逻辑绑定⽐较深。 2、Spark中的数据倾斜 Spark中的数据倾斜也很常见,这⾥包括Spark Streaming和Spark Sql,表现主要有下⾯⼏种: Executor lost,OOM,Shuffle过程出错 Driver OOM 单个Executor执⾏时间特别久,整体任务卡在某个阶段不能结束 正常运⾏的任务突然失败 补充⼀下,在Spark streaming程序中,数据倾斜更容易出现,特别是在程序中包含⼀些类似sql的join、group这种操作的时候。 因为 Spark Streaming程序在运⾏的时候,我们⼀般不会分配特别多的内存,因此⼀旦在这个过程中出现⼀些数据倾斜,就⼗分容易造成 OOM。 数据倾斜的原理 1、数据倾斜产⽣的原因 我们以Spark和Hive的使⽤场景为例。他们在做数据运算的时候会设计到,countdistinct、group by、join等操作,这些都会触发 Shuffle动作,⼀旦触发,所有相同key的值就会拉到⼀个或⼏个节点上,就容易发⽣单点问题。 2、万恶的shuffle Shuffle是⼀个能产⽣奇迹的地⽅,不管是在Spark还是Hadoop中,它们的作⽤都是⾄关重要的。那么在Shuffle如何产⽣了数据倾 斜? Hadoop和Spark在Shuffle过程中产⽣数据倾斜的原理基本类似。如下图。 ⼤部分数据倾斜的原理就类似于下图,很明了,因为数据分布不均匀,导致⼤量的数据分配到了⼀个节点。 3、从业务计⾓度来理解数据倾斜 数据往往和业务是强相关的,业务的场景直接影响到了数据的分布。再举⼀个例⼦,⽐如就说订单场景吧,我们在某⼀天在北京和上 海两个城市多了强⼒的推⼴,结果可能是这两个城市的订单量增长了10000%,其余城市的数据量不变。然后我们要统计不同城市的订单 情况,这样,⼀做group操作,可能直接就数据倾斜了。 如何解决 数据倾斜的产⽣是有⼀些讨论的,解决它们也是有⼀些讨论的,本章会先给出⼏个解决数据倾斜的思路,然后对Hadoop和Spark分别 给出⼀些解决数据倾斜的⽅案。 ⼀、⼏个思路 解决数据倾斜有这⼏个思路: 1.业务逻辑,我们从业务逻辑的层⾯上来优化数据倾斜,⽐如上⾯的例⼦,我们单独对这两个城市来做count,最后和其它城市做整 合。 2.程序层⾯,⽐如说在Hive中,经常遇到count(distinct)操作,这样会导致最终只有⼀个reduce,我们可以先group 再在外⾯包 ⼀层count,就可以了。 3.调参⽅⾯,Hadoop和Spark都⾃带了很多的参数和机制来调节数据倾斜,合理利⽤它们就能解决⼤部分问题。 ⼆、从业务和数据上解决数据倾斜 很多数据倾斜都是在数据的使⽤上造成的。我们举⼏个场景,并分别给出它们的解决⽅案。 数据分布不均匀: 前⾯提到的"从数据⾓度来理解数据倾斜"和"从业务计⾓度来理解数据倾斜"中的例⼦,其实都是数据分布不均匀的类型,这种情况和计 算平台⽆关,我们能通过设计的⾓度尝试解决它。 有损的⽅法: 找到异常数据,⽐如ip为0的数据,过滤掉 ⽆损的⽅法: 对分布不均匀的数据,单独计算 先对key做⼀层hash,先将数据打散让它的并⾏度变⼤,再汇集 ·数据预处理 三、Had