今年夏天，我在Databricks做集群团队的软件工程实习生。作为实习项目的一部分，我设计并实现了集群范围的init脚本，提高了可伸缩性和易用性。在这个博客中，我将讨论集群范围的init脚本的各种好处，接着是我在Databricks的实习经历，以及它对我个人和职业发展的影响。群集范围的初始化脚本Init脚本是在Spark驱动程序或worker JVM启动之前，在每个集群节点启动期间运行的shell脚本。Databricks客户将init脚本用于各种用途，例如安装自定义库、启动后台进程或应用企业安全策略。这些新脚本比以前的脚本提供了一些改进，而以前的脚本现在已被弃用。初始化脚本现在是集群配置的一部分过去，客户最大的痛点之一是集群的init脚本不是集群配置的一部分，也没有出现在用户界面中。因此，将init脚本应用于集群是不直观的，编辑或克隆集群不会保留init脚本配置。集群范围的init脚本解决了这个问题，方法是在集群配置页面的UI中包含一个"init脚本"面板，并向公共API添加一个"init_scripts"字段。这也允许init脚本利用集群访问控制。curl-n-xpost-H'内容类型：application/json'-d'{"cluster_id"："1202-211320-brick1"，"群集日志配置"：{"dbfs"：{"destination"："dbfs:/cluster日志"}},"初始化脚本"：[{"dbfs"：{"destination"："dbfs:/databricks//postgresql-安装.sh"}} ]}'https:///api/2.0/clusters/edit初始化脚本现在适用于作业集群以前的init脚本依赖于将脚本存储在具有集群名称的文件夹中。这可以防止它们在作业集群中使用，因为集群名称是动态生成的。由于集群范围的init脚本是集群配置的一部分，因此它们也可以应用于作业集群，通过UI和API具有相同的接口。初始化脚本的环境变量Init脚本现在提供对此处列出的某些环境变量的访问。这降低了许多init脚本的复杂性，这些脚本需要访问诸如节点是驱动程序还是执行器以及集群id等信息。初始化脚本的访问控制用户现在可以为他们的init脚本提供DBFS或S3路径，这些脚本可以存储在任意位置。使用S3时，IAM角色可用于为init脚本提供访问控制，防止恶意或错误地访问/更改init脚本。在这里阅读更多关于如何设置的详细信息。简化的日志记录集群范围的init脚本的日志现在与集群日志传递更加一致，并且可以在与集群的驱动程序和执行器日志相同的根文件夹中找到。其他群集事件Init脚本现在公开了两个新的集群事件：Init_Scripts_STARTED和Init_Scripts_FINISHED。这些工具可以帮助用户确定init脚本执行的持续时间，并进一步明确给定时刻集群的状态。结论在这个项目中，我接触到了设计、实现和测试面向客户的特性的过程。我学习了如何编写健壮的、可维护的代码和评估执行语义。我记得我的分布式系统教授曾说过，一个好的设计可以在数量级上简化工程设计工作，从而产生更短、更干净的代码，从而减少出现错误的可能性。然而，我从未想过，在一个行业环境中，这一点会在几个月后被带回家。我发现Databricks的工程师非常乐于助人，他们有不断学习和提高的愿望，还有耐心去教。领导层对员工非常开放，并不断寻求反馈，即使是实习生。实习计划也有许多有趣的活动，以及一些教育活动，让我们了解公司的其他领域（例如，销售、现场工程、客户成功）。最后，我要感谢集群团队在我整个项目中给予的鼓励和支持。这是对我的经理Ihor Leshko的特别赞扬，他总是在需要的时候出现在那里，Mike Lin彻底改变了我从事前端工程的方式，我的导师陈浩刚（Haogang Chen）教给我宝贵的技术技能，使我能够从编写简单、工作的代码到构建健壮、生产就绪的系统。免费试用Databricks。今天就开始吧