最近，我对大数据处理的整体流程有了新的理解。过去总觉得大数据由于其非结构化、异构的特点，清洗、抽取、处理等环节总显得混乱且无从下手。
而这次项目的目标，是挑战 Databricks。所谓“挑战”，其实是尝试用一系列开源工具，拼装出一个开源版本的 Databricks。因此，我们采用了 Spark 为核心计算引擎，能复用 Databricks 开源组件的尽量复用，没有的就找对应的替代方案。
最终确定的技术栈如下：
- Spark：Apache Spark（开源版本）
- Unity Catalog：UC 的开源替代方案
- Delta Lake：Delta Lake（开源版本）
- Notebook：JupyterHub / Jupyter Notebook
- Workflows：Apache Airflow
- MLflow：MLflow（开源版本）
虽然组件选型已经明确，但真正将这些“积木”拼装在一起远比想象中复杂（这让我理解了为什么 AWS 的大数据工具要叫 “Glue”）。
我们面临两个核心挑战：
多个开源组件的集成（OSS整合）
挑战之一是如何统一认证体系，另一个则是如何在多个组件之间实现数据的通用传递。
我们采用 OAuth 作为统一认证方案，将本系统与 Jupyter、UC、Airflow 串联了起来，包括用户信息的同步、服务之间的 token 传递等机制。同时，组件间的数据共享通过 Kubernetes 的 PVC（基于 EFS）实现，比如 Jupyter 的 Notebook、Airflow 的 DAG、Spark 的认证文件等，都通过共享存储打通。
Spark 集群资源的动态调度（动态 Spark 资源）
我们结合了 Spark on Kubernetes 的两种运行模式：
- Client 模式：主要用于 Jupyter Notebook 的交互式开发，Spark Driver 运行在 Jupyter 的 Pod 中，按需启动和释放资源。
- Cluster 模式（通过 Spark Operator）：主要用于 Airflow 的批处理任务（如 PySpark DAG），Driver 和 Executor 全部托管在 K8s 上，实现更彻底的资源自动化管理。
通过认证整合和共享文件系统的精心设计，目前各个开源组件已经可以较为顺畅地协同工作。虽然整体能力还无法与原生 Databricks 相比，但一个 OSS 版本的 Databricks 雏形已经初具规模。
如果 PoC 阶段能够获得正面的用户反馈，或许真的可以推动我们正式启动一个更完整、更强健的开源替代方案。