文章摘要
数据工程与软件工程正在融合,实时分析和AI功能的需求推动了数据基础设施与开发者体验(DX)的结合。优秀的DX应同时赋能软件开发者与数据工程师,借鉴现代Web开发的最佳实践,如Git原生、本地优先、代码化一切、CI/CD友好等。企业通过AI驱动的自动化加速业务洞察与运营,工程团队需以与应用代码相同的严谨性交付数据支持的功能。
文章总结
数据工程与软件工程正在融合
近年来,数据基础设施主要服务于分析师,数据仓库、数据湖和BI仪表盘等工具大多基于SQL和点击操作。然而,如今的分析不再仅限于报告或数据科学,实时数据已成为现代用户体验和AI应用的核心。SaaS应用通过在其用户体验中直接嵌入分析和AI功能,推动用户采用、参与和留存。企业则通过AI驱动的自动化加速业务决策,实现更快的洞察、预测和运营。
工程团队需要像交付其他应用代码一样,以同样的严谨性交付基于数据的功能。如果你来自软件工程领域,可能会从Postgres、MySQL或Mongo等事务型数据库入手。这些工具成熟且开发者体验良好,但它们是为事务处理而非分析设计的。随着数据量和查询复杂度的增加,查询速度变慢,仪表盘加载缓慢,AI聊天也变得迟钝。
如果你来自数据工程领域,可能会使用Snowflake、BigQuery或Databricks等托管分析平台。这些平台在批处理ETL和报告方面表现良好,但在需要实时性、并发性或亚秒级响应时则显得不足。此外,它们对开发者并不友好,缺乏真正的本地开发环境,迭代周期缓慢,无法适应现代软件开发生命周期。
因此,我们面临两个主要问题:用户体验(UX)和开发者体验(DX)。终端用户希望在大规模应用中实现亚秒级分析,而ClickHouse正是为此而生。ClickHouse在分析查询性能上表现卓越,比Postgres等事务型数据库快几个数量级,也比Snowflake或Databricks等云数据仓库更快且更具成本效益。这意味着你的应用可以拥有快速的仪表盘和实时响应的AI聊天功能。
开发者则需要像过去二十年来在Web开发中那样安全、高效的迭代环境。ClickHouse可以在任何规模下高效运行,从MB到PB级数据,适应从无服务器函数到本地容器再到数千台服务器集群的任何部署方式。这使得ClickHouse既适合本地优先的开发工作流,也适合大规模生产环境。然而,如何基于ClickHouse的强大功能和灵活性构建一个完整的、现代的、开源的开发者体验?MooseStack应运而生。
一个优秀的数据与分析开发者体验应同时服务于(1)采用软件开发最佳实践的数据工程师,和(2)涉足数据、分析和AI的软件工程师。它还应从推动现代Web开发体验的创新工具中汲取灵感,如Ruby on Rails、Next.js、TanStack和Supabase。
简而言之,一个优秀的数据与分析开发者体验应遵循以下核心原则:
- 基于Git的版本控制与治理
- 本地优先的开发
- 原生编程语言(非YAML)
- 基础设施样板代码的抽象
- 水平集成与模块化
- 开源原生
- AI助手原生
- 透明的迁移与集成的CI/CD
MooseStack通过提供TypeScript或Python应用开发工具包,帮助开发者在ClickHouse和其他开源数据基础设施上构建应用,实现了这些原则。它通过本地开发服务器、Git集成、类型安全的代码库和模块化设计,为开发者提供了一个高效、灵活的开发环境,使得数据工程与软件工程的融合更加顺畅。
评论总结
评论主要围绕数据工程与软件工程的关系、工具使用、以及行业现状展开,观点多样且存在分歧。
数据工程与软件工程的关系:
- 部分评论认为数据工程本质上是软件工程的一部分,强调两者不应有明显区分。例如,CalRobert指出:“Data engineering was software engineering from the very beginning.”(数据工程从一开始就是软件工程。)
- 另一部分评论则认为数据工程与软件工程正在趋同,但仍有区别。SrslyJosh质疑:“‘Data engineering and software engineering are converging’ says firm selling analytics products/services.”(“数据工程和软件工程正在趋同”是销售分析产品/服务的公司的说法。)
工具与最佳实践:
- 许多评论提到数据工程中缺乏软件工程的最佳实践,如CI/CD、版本控制等。zamalek批评道:“There’s a lot of doing things in notebooks and calling that production-ready.”(很多人用笔记本做事情,然后称之为生产就绪。)
- 也有评论认为数据工程可以遵循软件工程的标准,但需要合适的工具和语言。getnormality提出:“It’s not hard to do data engineering to the standards of software engineering.”(按照软件工程的标准进行数据工程并不难。)
行业现状与挑战:
- 一些评论指出数据工程师往往沦为“工具操作员”,缺乏真正的工程能力。botswana99描述:“Many data teams often find themselves as ‘tool jockeys’ instead of becoming true engineers.”(许多数据团队往往沦为“工具操作员”,而不是成为真正的工程师。)
- 也有评论提到数据工程师面临的职业困境,如缺乏自我尊重和信心。botswana99进一步指出:“The real question is not that DE and software engineering are converging. It’s why most DEs don’t have the self-respect and confidence to engineer systems.”(真正的问题不是数据工程和软件工程正在趋同,而是为什么大多数数据工程师没有自尊和信心来设计系统。)
语言与工具的选择:
- 部分评论对Python和SQL在数据工程中的使用提出质疑,认为它们存在局限性。jochem9指出:“Python is dynamically typed, which you can patch a bit with type hints, but it’s still easy to go to production with incompatible types.”(Python是动态类型的,虽然可以用类型提示修补,但仍然容易在生产中出现类型不兼容的问题。)
- 也有评论建议采用静态类型编译语言,如Rust或Go。jochem9提出:“For Python I would say that we should start adopting statically typed compiled languages.”(对于Python,我认为我们应该开始采用静态类型编译语言。)
总结来看,评论反映了数据工程领域的多样性和复杂性,既有对现状的批评,也有对未来发展的建议。