随着 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 的成熟产品。如果我们能胜出，不仅能大幅降低成本，还能让客户拥有自己的知识产权。
这将是属于我们的价值。
希望在不远的将来，能迎来好消息。。。