我々はどのようにしてGoogle Kubernetes Engine (GKE)上にDatabricksを構築したのか
Why and How We Built Databricks for GCP on the Google Kubernetes Engine (GKE) – The Databricks Blogの翻訳です。
对于多云环境中的数据、分析和人工智能，采用容器化方法。
Databricks on Google Cloud Platform (GCP)のリリースは、真のマルチクラウドである統合データ、分析、AIプラットフォームに向けた大きなマイルストーンでした。Databricks on GCPはジョイントで開発されたサービスであり、お使いのすべてのデータをシンプルかつオープンなレイクハウスプラットフォームに格納できるようにし、これはGoogle’s Kubernetes Engine (GKE)上で稼働している標準コンテナをベースとしています。
Databricks on GCPをリリースした際のフィードバックは「とりあえず動いたね！」というものでした。しかし、あなた方の何人かは、DatabricksとKubernetesに関する深い質問をしました。このため、GKEを採用した理由や学び、キーとなる実装の詳細を共有することを決断しました。
为什么选择Google Kubernetes Engine？
开放源代码的软件和容器。
Databricksにおいては、我々が我々であり続けるためのコアとしてオープンソースがあり、これが、我々はApache Spark™、MLflow、Delta Lake、Delta Sharingのようなメジャーなオープンソースプロジェクトを作成し、貢献し続けている理由となっています。また、企業としてコミュニティに還元しており、オープンソースを日々活用しています。
我们多年来一直在使用容器。例如，在MLflow中，用户可以将机器学习（ML）模型构建为Docker镜像，将其存储在容器注册表中，并从注册表中部署和执行模型。
別の例はDatabricksノートブックです。バージョン管理されたコンテナイメージは、複数のSpark、Python、Scalaバージョンのサポートをシンプルにし、コンテナはソフトウェア開発におけるより高速なイテレーションと、より安定したプロダクションシステムを実現します。
Kubernetes和超大规模
我々はKubernetesのようなコンテナオーケストレーションシステムは自身の課題を抱えていることに気づいています。Kubernetesの背後にあるコンセプトと豊富な機能は、経験と知識が豊富なデータエンジニアリングチームを必要とします。
しかし、Databricksではここ数年においてコンテナ上での構築に成功し、オープンソースソフトウェアを作成することで、超大規模な環境に成長しました。我々のお客様は、1日あたり数百万のインスタンスを起動しており、月あたり数十万のデータサイエンティストをサポートしています。
安全性和简洁性
我々にとって最も重要なことは、データエンジニアやデータサイエンティストに新機能を迅速に提供することです。Databricks on GCPを設計した際、我々のエンジニアリングチームはセキュリティとスケーラビリティ要件を充足するためのベストな選択肢を探索しました。我々のゴールは、実装をシンプルにし、低レベルのインフラストラクチャや依存関係やインスタンスのライフサイクルへのフォーカスを削減することでした。我々のエンジニアはKubernetesを用いることで、インフラストラクチャのロジックとセキュリティをドライブするためにオープンソースコミュニティからの強力なモーメンタムを活用することができました。
GKE和其他Google Cloud服务
我々は必要とされるオペレーション上の専門性と、プロダクションにおいて大規模な上流のKubernetesを稼働させることによって得られるメリットの間を重点的に評価し、最終的にはセルフマネージのKubernetesクラスターを使わないことにしました。
代わりにGKEを選択した主要な理由は、新たなKubernetesバージョンが迅速に取り込まれることと、Googleのインフラストラクチャセキュリティに対する高い優先度でした。KubernetesのオリジナルクリエーターであるGoogleのGKEは、市場において最も先進的なマネージドKubernetesサービスです。
一方で、Google Cloud Storage、Google BigQuery、Google Lookerのような全ての主要なGCPクラウドサービスとDatabricksはインテグレーションされています。我々の実装はGKE上で稼働しています。
Google Kubernetes Engine上のDatabricks
分散システムをコントロールプレーンとデータプレーンを分割することは、よく知られたデザインパターンです。コントロールプレーンのタスクは、顧客の設定を管理しサーブすることです。多くの場合より大規模なデータプレーンは顧客のリクエストを実行する目的です。
Databricks on GCPは同じパターンに従っています。Databricksがオペレーションするコントロールプレーンが、顧客のGCPアカウントのデータプレーンを作成、管理、監視します。データプレーンには、お使いのSparkクラスターのドライバーノード、エグゼキューターノードが含まれます。
GKE集群、命名空间、自定义资源定义
GKE集群和节点池。
GKEクラスターは、ワークスペース規模で稼働する信頼サービス専用のシステムノードプールによってブートストラップされます。Databricksクラスターを起動する際、ユーザーはエグゼキューターノードの数と、ドライバーノードとエグゼキューターノードのマシンタイプを指定します。コントロールプレーンの一部であるクラスターマネージャーは、これらのマシンタイプのそれぞれのGKEノードプールを作成・管理します。多くの場合、ドライバーとエグゼキューターノードば異なるマシンタイプで動作し、これらは別のノードプールから提供されます。
命名空间
Kubernetesはスコープのある名前(すなわち名前)を伴うバーチャルクラスターを作成するための名前空間を提供します。個々のDatabricksクラスターは、単一のGKEクラスターにおいてKubernetes名前空間を通じて互いが分離されており、単一のDatabricksワークスペースには、数百のDatabricksクラスターを含めることができます。GPCのネットワークポリシーが同じGKEクラスター内のDatabricksクラスターネットワークを分離し、セキュリティをさらに改善します。Databricksクラスター内のノードは、同じクラスター内の他のノードとのみコミュニケーションできます(あるいは、インターネットや他のパブリックGCPサービスにアクセスするためにNATゲートウェイを使用します)。
自定义资源定义
Kubernetes被彻底设计为能够使用Kubernetes自定义资源定义（CRD）进行定制化和扩展自身API的功能。对于工作空间中的所有集群，将Databricks运行时（DBR）部署为Kubernetes CRD。
节点池、Pod、Sidecar
Sparkドライバーとエグゼキューターは、Kubernetes podノードセレクターによって指定される対応ノードプールのノードの中で稼働するKubernetes podsとしてデプロイされます。一つのGKEノードは排他的にドライバーpodあるいはエグゼキューターpodによって使用されます。クラスターの名前空間は、Kubernetesのメモリーリクエストとリミットによって設定されます。
それぞれのKubernetesノードにおいては、Databricksはドライバーやエグゼキューターコンテナーとともに幾つかの信頼デーモンコンテナも動作させます。これらのデーモンはノードのデータアクセスとログ収集を行う信頼サイドカーサービスです。ドライバー、エグゼキューターコンテナは、制限されたインタフェースを通じて同じpodのデーモンコンテナのみとインタラクションすることができます。
常见问题（FAQ）
Q: Databricksが提供するGKEクラスターに自分のpodをデプロイできますか？
Databricks GKEクラスターにアクセスすることはできません。最大限のセキュリティによって制限され、リソース使用を最小化するように設定されています。
Q: 自分のカスタムGKEクラスターにDatabricksをデプロイできますか？
現時点ではサポートしていません。
Q: kubectlでDatabricks GKEクラスターにアクセスできますか？
GKEクラスターのデータプレーンはお客様のアカウントで稼働していますが、デフォルトのアクセス制限とファイアウォール設定が許可されないアクセスを防御しています。
Q: GKE上のDatabricksは他のクラウドはVM上のDatabricksよりも(クラスター起動時間などが)速いですか？
こちらに対する回答は多くの要素に依存するので、ご自身で計測することをお勧めします。Databricksのマルチクラウドのオファリングのメリットの一つは、このようなテストをクイックに行えるということです。我々の初期のテストでは、大規模の同時実行ワーカー、コールドスタートアップにおいては他のクラウドと比較してGKEの方が高速でした。同等のローカルSSDを持つインスタンスが特定のSparkワークロードを実行した際、他のクラウドの同等の計算リソース(コア、メモリー、ディスク)と比較して若干高速でした。
为什么不为每个Databricks集群使用一个GKE集群？
効率性のためです。Databricksクラスターは頻繁に作成され、それらのいくつか(短時間のジョブなど)は短寿命です。
问题：启动100个节点的集群需要多长时间？
100ノード以上の大規模クラスターであっても、起動は並列で実行されるので、起動時間はクラスターサイズに依存しません。ご自身の設定を用いて自分で起動時間を計測することをお勧めします。
Q: 为了成本效益，如何最优化分配pod到节点上？我想将一些Spark执行器pod分配到更大的节点上。
Podsはそれぞれの用途(ドライバー、ワーカーノード)に応じてDatabricksによって最適に設定されます。
问题：我可以将自己的VPC带入到GKE集群中吗？
如果您对本功能感兴趣，请联系Databricks的账户经理以获取路线图。
Q: 単一のGKEクラスターでDatabricksが複数のDatabricksクラスターを実行しても安全ですか？
DatabricksクラスターはKubernetes名前空間とGCPネットワークポリシーを用いて、それぞれが完全に分離されています。コストを削減し、プロビジョンを高速にするために、同じDatabricksワークスペースのDatabricksクラスターのみがGKEクラスターを共有します。複数のワークスペースをお持ちであれば、それぞれにGKEクラスターが稼働することになります。
Q: 単にVMを使うのと比較して、GKEには追加のネットワークオーバーヘッドはありませんか？
GCPにおける初期のテストにおいて、us-west2/1におけるn1-standard-4でのiperf3ベンチマークは、9 Gpbs以上という素晴らしいpod間スループットを示しました。通常、GCPはインターネットに対して高いスループットと低いレーテンシーを示します。
Q: Databricksが完全にコンテナ化されているのであれば、(自分のローカルのKubernetesクラスターなどで)自分で使用するためにDatabricksイメージをプルすることはできませんか？
目前Databricks尚未支援此功能。
问：在使用GCP上的Databricks时，只能使用特定区域中的一个可用区吗？GKE上的节点分配是如何工作的？
GKE集群将使用区域内的所有可用区。
Q: Databricks on GCPにはどのような機能が含まれていますか？
最新の情報に関してはこちらのリンクをチェックしてください。
我对Silviu Tofan作为作者提供的有价值的输入和支持表示感激之情。
Databricks 免费试用
Databricks 免费试用
