分类:  Azure Databricks    ◆ 标签:  #Azure   #Databricks   ◆ 发布于: 2023-06-18 19:52:08

我们之前有一篇文章就用户的案例提及了Databricks的内存管理，我们本章计划再次深入学习一下内存管理。虽然Databricks是基于Spark开发的平台，但是Databricks的部署和用户自己搭建的Spark集群在配置上还是有不一样的地方。 谁在管理内存 所有的Spark应用都是运行在JVM的进程内的，对于JVM来说，它主要是通过GC来管理内存，而GC对于Spark的内存使用模式是一无所知的，也就是说Spark需要自己管理内存。相对于GC， Spark管理的内存其模式相对固定，它管理的内存主要是被分成两大块，Execute Memory和Storage Memory, 同时Spark应用运行时还有一块内存称为保留内存，需要注意的是这块内存并不是由Spark来管理的，而是由JVM

分类:  Azure Databricks    ◆ 标签:  #Azure   #Databricks   ◆ 发布于: 2023-06-18 19:50:01

如果发现Azure Databricks Workspace被删除了，可以通过Azure Portal的Activity log检查谁删除了Azure Databricks Workspace, 具体步骤如下： 登录到Azure Portal。 在搜素框里搜索Activity, 然后选择Activity Log, 如下图：

分类:  Azure Databricks    ◆ 标签:  #Azure   #Databricks   ◆ 发布于: 2023-06-18 19:46:44

在阅读这篇文章之前需要了解用户问题背景，您可以通过如下链接了解到： 我们之前一篇文章学习通过调整JDBC源配置提高并行度来缓解客户的问题，这是个比较好的解决方案，也是我们和Databricks的团队仔细讨论过的方案，是比较稳妥的做法。为了更好的理解客户的问题发生原因，我们还可以从Databricks的内存管理上入手，来讨论和学习如何从内存上缓解类似的问题。 Databricks是基于Spark的云平台，因此在架构上、内存管理上和传统的Spark会有区别，不过组件结构也是由driver和executor组成的，drvier和executor的分工也很明确： driver的主要负责： 创建SparkContext和SparkSession, 并运行用户代码中的main()

分类:  Azure Databricks    ◆ 标签:  #Azure   #Databricks   ◆ 发布于: 2023-06-18 19:43:36

我们之前的文章介绍了这个用户案例的背景，要学习本章需要认真了解一下背景，您可以通过如下的链接访问：<> 上篇结束时我们谈到过有两个解决方案可以缓解这个问题： 优化客户导入数据的代码，使用JDBC数据源的配置项提升数据导入的并行度，避免发生Out Of Memory这样的问题。 优化集群的配置，调整Spark运行过程中使用到内存环境, 避免发生Out OF Memory的问题。 我们本节来学习和讨论方案一，优化JDBC源配置。 我们可以使用如下的方式来缓解： 优化pushdown query限制数据集，分批次导入数据集。 根据JDBC数据源的配置选项，优化并行配置。 根据JDBC数据源配置选项，配置fetchsize， 优化导入效率。 我们现在来学习这三个方案

分类:  Azure Databricks    ◆ 标签:  #Azure   #Databricks   #Spark   ◆ 发布于: 2023-06-18 19:40:13

近期遇到一个非常典型的用户案例： 用户使用Azure Databricks通过JDBC数据源向Delta Table输入大量的数据，在运行了两个半小时之后报错，数据导入失败，并且报了两种异常： 异常1: 异常2 用户使用的的数据源是Azure Database for mysql, 需要导入的表数据行数330万行，数据大小在44个G左右。仔细检查了客户的notebook, 客户的语句其实非常简单：

分类:  Azure Databricks    ◆ 标签:  #Azure   #Databricks   ◆ 发布于: 2023-06-15 21:34:01

我们之前讨论过了如何快速的缓解Job/Notebook卡住的问题，也分享给大家了如何通过Spark UI来查看thread dump, 我们今天分享给大家我们的第三板斧：通过配置让Cluster自动抓取ThreadDump, 关于之前的文章，请参考链接： 配置集群自动抓取ThreadDump 请使用如下的步骤来配置集群当有长时间运行或者卡住的Job/notebook自动抓取Thread Dump: 登录到workspace, 选择你的cluster:

分类:  Azure Databricks    ◆ 标签:  #Azure   #Databricks   #Spark   ◆ 发布于: 2023-06-15 21:29:22

我们之前已经分享了如何快速的缓解Databricks job/notebook卡住的办法，如果要详细的分析job/notebook卡住的原因，那么还是得再来一板斧：查看long-running或者是stuck task的Threaddump, 如何缓解可以参考之前的文章： 如何通过Spark UI查看long-running task/stuck job的ThreadDump 要查看ThreadDump的步骤如下： 登录到Workspace, 左侧菜单选择Compute, 然后在cluster list里选择运行的cluster:

分类:  Azure Databricks    ◆ 标签:  #Azure   #Databricks   ◆ 发布于: 2023-06-15 21:22:46

最近遇到不少用户运行的job/notebook卡住的情况，特地将解决该类型问题的三板斧记录下来。 板斧一 如果用户有在集群上安装额外的library, 特别是在Azure China通过官方的源安装Python包，Jar包(通过Maven), 有较大机率遇到类似的问题，是由于国内机房某些时候访问这些境外的源会遇到无法访问或者下载速度缓慢的原因，这个问题非常容易重现，重现步骤如下： 创建一个集群，并启动。 进入workspace -> Compute, 选择已经启动并创建的集群，然后在Library栏中选择Install New 选择Pypi, 输入一个包名，Repository选择一个不能访问的地址，因为我们这里是为了重现问题。 点击install 整个步骤如下图所示：

分类:  Azure翻译服务    ◆ 标签:  #Azure   #翻译   #Translator   ◆ 发布于: 2023-06-15 21:09:48

在正式使用文档翻译rest api之前有几个地方需要注意： 文档翻译的API是必须创建一个单独的Translator服务，而不能和Azure认知服务共用。 文档翻译的功能只在定价层S1(pay-as-you-go)和Azure Global的D3 Variable cost plus Fixed plus overage定价层支持。 文档翻译API有自己单独的请求Endpoint，既不是文本翻译的endPoint也不是认知服务的endpoint 文档翻译除了要创建Translator资源之外，还需要一个Azure Storage的资源，并在该存储账号中创建两个blob，一个用于存储需要翻译的文档，另外一个用于输出翻译之后的文档。

分类:  Azure翻译服务    ◆ 标签:  #Azure   #翻译   #Translator   ◆ 发布于: 2023-06-15 21:05:30

我们前面学习了Azure Translator的文本翻译的部分，我们现在来学习文档翻译。 文档翻译顾名思义是对用户的各种格式的文档进行翻译，您可以一次性提交多个文档，然后由服务在后台帮助您异步翻译完成，并尽可能保留原有文档的格式。 和文本翻译不同的是，文档翻译有一些不一样的地方： 文档翻译只能通过创建单一的服务，也就是说必须是创建一个Azure Translator的服务，而不是创建一个Azure认知服务的实例。 文档翻译除了需要一个Azure Translator的实例之后，还需要创建一个Azure Stroage的资源，并且在Azure Storage里创建两个容器，一个用于上传需要翻译的文档，另外一个放置翻译之后的文档。 文档翻译有提供.Net和Python的 S