Infony — 一日清闲

分类： 技术

  • 3个月的项目胜利结束

    3个月的项目胜利结束

    随着 8 月的结束，数据分析平台的开发也进入了最后的收尾阶段。
    回顾整个历程：2 月提出构想，4 月正式立项，6 月启动开发，6 月底到 7 月初经历了最焦灼的不安，7 月底逐渐趋于稳定，8 月完成完善与优化，并协助客户搭建 Staging 环境。
    虽然整个开发周期只有短短三个月，却充满起伏与挑战。尤其在 6 月下旬时，甚至一度怀疑能否按时交付。但如今回过头来看，这段经历让我对大数据算是有了真正的入门理解，也更清晰地看到了那些大厂的数据平台究竟在做什么。

    平台本质：不是“造轮子”，而是“搭桥梁”

    严格来说，我们并没有重新发明一个“大数据处理平台”，而是为它构建了一个工具平台。
    毕竟，经过多年发展，大数据的核心处理框架早已成熟：

    • Spark：分布式计算的事实标准
    • Airflow：任务调度的事实标准
    • Jupyter：数据科学的事实标准

    这些能力毋庸置疑。但真正的难点在于——如何把它们融合起来，尤其是如何动态管理 Spark 集群资源的生命周期。这部分并不像想象中那么简单。
    好在团队的小伙伴们十分给力，一个又一个障碍被不断识别并解决，最终让系统跑通。

    技术之外：用户体验才是核心

    这个项目让我体会到：技术并不是产品的核心，用户体验才是。
    三个月内，我们依靠 Databricks 的开源生态与其他 OSS 拼凑出了一个“仿制版 Databricks”。站在开源的肩膀上，似乎一度觉得我们离世界顶尖产品不再遥远。
    但实际使用下来，差距依然巨大。尤其在用户体验上，我们与 Databricks 根本不在同一个量级。

    比如最初，我们想实现类似 Databricks 的 Job Schedule/Workflow，让用户像搭积木一样快速组合资源，轻松完成任务。但最终不得不妥协，只能用 Airflow DAG 的编程方式勉强支撑复杂流程，留下一块“遮羞布”。
    再比如多 OSS 的整合，我们最多也只能通过用户表同步来实现单点登录，让多个 UI 勉强可用，却无法真正做到统一界面下的完整管理。

    OSS 的拼接与未来的期待

    所以，从某种意义上说，我们做出来的只是一个碎片化、缺乏灵魂的产品。它能工作，但不优雅。
    尽管如此，我依然对接下来的结果抱有期待：客户将在未来几个月对比我们的 OSS 方案与 Databricks 的成熟产品。如果我们能胜出，不仅能大幅降低成本，还能让客户拥有自己的知识产权。

    这将是属于我们的价值。

    希望在不远的将来，能迎来好消息。。。

  • Big Data Analyzer Platform

    最近，我对大数据处理的整体流程有了新的理解。过去总觉得大数据由于其非结构化、异构的特点，清洗、抽取、处理等环节总显得混乱且无从下手。

    而这次项目的目标，是挑战 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 阶段能够获得正面的用户反馈，或许真的可以推动我们正式启动一个更完整、更强健的开源替代方案。