1. 关系梳理

一个Account下可以创建多个EMR Studio，一个EMR Studio下又可以创建多个Workspace，EMR Studio和Workspace均拥有独立公网地址，两者已经类似于SaaS服务。

EMR Studio的核心配置是网络和身份认证（Authentication），可以简单地说：一个EMR Studio对应一个VPC + 一种身份认证方式，从这个角度上看，一个空的EMR Studio（没有任何Workspace）相当于一个“门户”（一个Studio会有独立的公网DNS！），这个“门户”对内接通了网络，对外提供登录入口（身份认证），在这样一个统一的环境里，建立的是一个一个的Workspace；Workspace可视作一个独立的Jupyter Server，它的核心配置是attach一个EMR集群（EMR on EC2 or EMR on EKS）。一个Workspace相当于一个EMR集群的Gateway或Client。

2. 网络配置

由于EMR Studio需要联通到EMR集群，所以网络配置必须正确。在官方文档中，对网络部分有这样几处需要注意的地方：

2.1 必须是在私有子网中的EMR集群才可以被EMR Studio连接吗？

在EMR Studio的官方文档中，数次提到：EMR集群必须位于私有子网中：

经过测试可以确认：并非如此，公有子网中的EMR集群一样可以attach到EMR Studio的Workspace中去。

2.2 关于网络安全组：DefaultEngineSecurityGroup 和 DefaultWorkspaceSecurityGroupGit

在创建EMR Studio时，如果在“Security and access”一节选择了“Default security group”，则EMR Studio会自动创建两个网络安全组：

• DefaultEngineSecurityGroup：这个安全组是将要赋给被attach的EMR集群的Master节点上的，它只有一个inbound规则：允许外部访问内部的18888端口
• DefaultWorkspaceSecurityGroupGit：这个安全组是将要赋给Workspace的，它有两个outbound规则：允许向外部的18888和443端口发出请求

两个安全组，一个（DefaultEngineSecurityGroup）作用于集群主节点，一个（DefaultWorkspaceSecurityGroupGit）作用于集群的客户端（Workspace），通信端口是18888，前者允许进，后者允许出，这样：Worspace和EMR集群的网络就打通了，走的是18888端口。

至于Workspace的outbound 443端口，是用于连接外部Git Repo的，例如Github，基本都是https协议，所以要开443端口。

补充一个细节：只有在Workspace里执行attach操作时，EMR集群的主节点才会被追加到DefaultEngineSecurityGroup安全组中，当EMR集群被dettach时，也会自动移除主节的efaultEngineSecurityGroup安全组。下图即为一个被attach到Workspace的EMR集群的安全组配置：

2.3 18888端口

如上所述，18888端口是Workspace和EMR集群之间通信的唯一接口，在个端口是开在EMR主节点上的，其所属的进程是nginx，而这个nginx只是一个反向代理，它将各种请求转发给了EMR上对应的各项服务，这一点，从nginx的反向代理配置中即可知晓：

2.4 无法访问Github的解决方法

测试环境：VPC，3 AZ，3 Public Subnet + 3 Private Subnet

• 测试一

  在新建Workspace时，同时创建新的EMR集群情况下，可以访问外网Git（Github），其中，在选择新建EMR集群的子网时，公有子网和私有子网均可；新建后，attach本子网以及其他子网中的其他EMR集群，都可以访问外网Git（Github）

• 测试二

  在新建Workspace时，选择一个已存在的EMR集群，无法访问外网Git（Github）；挂载其他集群尝试，依然无法访问外网Git（Github）

• 测试三

  在新建Workspace时，不选择挂载任何集群，进入后，可以访问外网Git（Github）；之后挂载任意集群，依然可以访问外网Git（Github）

结论：就目前看（2023年2月），EMR Studio在新建Workspace时如果选择attach一个已有的EMR集群，则建成后Workspace无法访问外网Git（Github），这可能是一个Bug。而只要在新建Workspace时不选择attach集群，进入后就可以访问外网Git（Github），可以检查代码之后，再attach集群。此外，如果在新建Workspace时选择同时新建一个集群的话，建成后也能正常访问外网Git（Github）！

3. 集成Windwos AD身份认证

4. 内置的Notebook Examples

参考项目：

https://github.com/aws-samples/emr-studio-notebook-examples

4.1 使用 SparkSQL 操作 Hudi 数据集

参考示例：

https://github.com/aws-samples/emr-studio-notebook-examples/blob/main/examples/query-hudi-0.9.0-dataset-with-spark-sql.ipynb

4.2 使用 PySpark 进行数据处理和分析，期间使用 Matplotlib 进行数据可视化

参考示例：

https://github.com/aws-samples/emr-studio-notebook-examples/blob/main/examples/install-notebook-scoped-libraries-at-runtime.ipynb

关键技术点：df.toPandas()

配套文章：

https://aws.amazon.com/cn/blogs/big-data/install-python-libraries-on-a-running-cluster-with-emr-notebooks/

4.3 使用 Pandas 进行数据处理和分析，期间使用 Matplotlib 进行数据可视化

参考示例：

https://github.com/aws-samples/emr-studio-notebook-examples/blob/main/examples/visualize-data-with-pandas-matplotlib.ipynb

注意：%pip install xxx仅限于将Python包安装于Master节点！

4.4 使用 PySpark 进行机器学习（基于Spark ML)

参考示例：

https://github.com/aws-samples/emr-studio-notebook-examples/blob/main/examples/machine-learning-with-pyspark-linear-regression.ipynb

5. EMR Studio的作业调度（与工作流引擎集成）

不管是step function还是airflow，都是通过notebook的API（Python or Cli）集成进工作流的。参考：

通过CLI触发Notebook：

https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-headless-cli.html

通过Python API触发Notebook：

https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-notebooks-headless-python.html

上述两种方式均可顺滑集成到Airflow中。

6. 安装自定义Kernel和库

EMR Studio的Workspace所以依赖的notebook基础设施就是EMR集群内置的notebook，所以，在EMR Studio的Workspace上安装自定义Kernel和库都是去Master节点上操作，操作方法与在EMR notebooks上安装自定义Kernel和库完全一样。

参考：

EMR Studio关于安装Kernel和库官方的文档

EMR Notebook关于安装Kernel和库官方的文档

7. EMR Studio 和 EMR on EKS 的集成

参考此文：

Configure Amazon EMR Studio and Amazon EKS to run notebooks with Amazon EMR on EKS

8. 完整的Workshop

EMR Studio Workshop

8. EMR Studio or Sagemaker Studio?

如果你的AI/ML程序是基于Spark Mlib / Spark ML编写的，那么EMR Studio无疑是最佳选择！
如果你的AI/ML程序依赖Tensorflow、Pytorch，Sagemaker可能更合适一些，至少在Sagemaker中有TF和Pytorch的镜像。