随着数据在越来越多的企业中被应用，数据技术的发展可谓突飞猛进。不仅基于Hadoop的大数据生态在持续完善，我们也能看到很多新兴的分布式技术如潮水般涌现。以下是来自中国信通院《大数据白皮书（2020年）》整理的大数据技术体系图谱：
虽然数据技术发展飞快，但是对于做数据开发的我们，整个数据项目开发过程还是很痛苦。我们接触过的客户常常这样抱怨：
搞不懂数据怎么算出来的，反正很复杂…
数据库里面好几百个SQL，代码都很长…
经常延迟出数据，流水线总是出问题…
这是什么原因呢？我们发现这常常是由于团队的数据工程实践做得不够好。
要想能够规模化的实施企业数据项目开发，除了数据技术之外，数据工程实践也得跟上。
本系列文章尝试结合我们在多个客户的多个数据项目的实践，给大家分享一些行之有效的数据工程实践。
数据工程
首先，我们需要了解一下什么是数据工程？
我们一般理解的工程是以解决实际生活中的复杂问题为目标，通常是以团队为单位进行实施，综合利用各种科学知识及经验解决问题（参考wiki）。软件工程则是在软件开发领域的工程，它综合利用各类软件构建知识、技术工具及经验来构建复杂软件。
IEEE将软件工程定义为“将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中”。
数据工程是在数据开发这个特定的软件开发领域的软件工程，可以定义为综合利用各类软件构建知识、数据技术及工具、经验来构建复杂的数据产品。
数据技术和数据工程
数据技术和数据工程不同。如分布式存储技术、分布式计算技术、HTAP混合事务分析处理技术、OLAP技术等是典型的数据技术。这些技术一般会对应多种工具实现，如Hadoop对分布式存储和计算提供了基础实现、Apache Spark则关注在更通用的分布式计算、Hive基于Hadoop实现了分布式数据库、Clickhouse提供OLAP的一个实现等。数据技术一般关注在某一类场景，并为某一类问题提供解决方案。
如Data Mesh数据网格，Data Fabric数据编织，以及Thoughtworks雷达上提到的Declarative data pipeilne声明式数据流水线、Production data in test env测试环境中的生产数据（不推荐）等则是关注在数据工程领域（这里，我们把数据架构也纳入广义的数据工程范围）。也有一些专注于数据工程的工具。比如dbt，它对数据项目代码仓库结构，使用的语言及模板等给出了建议。比如Thoughtworks数据团队开源的Easy SQL，它基于SQL定义了一套方便进行工程化数据开发的ETL开发语言，并提供了相关的库和工具。数据工程更关注在数据开发过程，为团队协作、工作方式、代码维护和管理、软件运行和维护等方面提供（多基于经验的）建议。
对比两者，可以说，数据技术用于解决某个特定的数据计算或管理问题，而数据工程则综合利用各种不同的数据技术构建有业务价值的产品。
所以，不难发现，即便数据技术可以为数据开发赋能，但是没有数据工程的指导，也很难让我们更高效的交付数据项目。
数据技术更像武器，而数据工程则关注在如何打造一支有战斗力的军队。要想打胜仗，光有武器还不够，还需要打造一支训练有素且能征善战的军队。
数据工具与数据工程
数据工具是指可以拿来即用的解决某个数据问题的某个软件。它一般是某种数据工程思想或实践的支持软件（也可以是某种数据技术的实现）。比如上述dbt、EasySQL即为此类工具。
数据工程思想或实践也可以没有（或者暂时还没有）专门的支持工具（事实上大部分都没有），也可以有很多种不同的支持工具（比如上述声明式数据流水线就有很多中工具支持，如Airflow）。
数据开发领域的相关工具非常多，本系列文章不打算讨论具体的数据工具，而希望讨论一些行之有效的工作方法，即数据工程实践。
敏捷数据工程
敏捷软件开发方法已经成为应用软件开发的主流工程方法。有大量团队验证了敏捷方法中推荐的实践的有效性。
数据开发属于一个特定的软件开发领域，大部分的应用软件开发方法可适用于数据开发，敏捷软件开发方法自然也不例外。
那么，是不是直接将敏捷软件开发方法应用于数据开发就是敏捷数据工程呢？这里面还有几个容易引起争议的术语值得讨论。
敏捷软件开发与敏捷软件工程
我们常常说“敏捷软件开发”而不是“敏捷软件工程”（百度搜索“敏捷软件工程”只有不到100条结果，而搜索“敏捷软件开发”1000万条结果），这是为什么呢？难道敏捷软件开发并不算一套工程方法？
事实上，从英文搜索结果上看，如果我们搜索”Agile software development”，Google显示有约480万结果，搜索”Agile software engineering”有约140万结果。可见敏捷软件工程的说法也是符合业界认知的，不过相对少一些。
从Wiki上关于软件工程的定义来看，软件工程覆盖很广，核心内容包括了需求、设计、测试、维护、工程管理、开发过程、质量等。敏捷被放在了软件开发过程和方法学中讨论。并指出“敏捷软件开发被认为是软件工程的一个重要的发展”。所以，可以认为敏捷软件开发是软件工程方法的一种，这印证了上述“敏捷软件工程”的表述的合理性。
为什么“敏捷软件开发”的说法更常见？个人猜测这可能是由于：
-
《敏捷宣言》中明确用了”Agile software development”，即敏捷软件开发，这一表述方式，后续的讨论中多直接引用这一表述。
-
在“敏捷软件开发”最开始被提出之时，其主要针对的对象是传统的瀑布式软件开发方法。在当时，这种软件开发方法基本上等同于软件工程，而敏捷希望跟它撇清关系。
-
传统的软件工程方法来源于传统的广泛应用于建筑、工业制造等领域的工程方法，对于过程定义非常严格。而作为一个轻量级的方法，“敏捷软件开发”的表述可能更不容易让我们联想到重量级的工程过程。
事实上，作为一种软件开发领域的新的思潮，敏捷，已越来越多的覆盖了软件开发的各个方面。软件需求管理中的敏捷是用户故事方法，软件项目管理中的敏捷是Scrum，软件开发中的敏捷是极限编程、TDD、DDD、重构等方法，软件测试中的敏捷是敏捷软件测试、测试左移等方法，此外还有敏捷项目估算、敏捷建模等等。所以，我们可以从广义上定义敏捷软件工程，它是指将敏捷的思想用于软件工程。
敏捷数据工程
综合上面的讨论，本系列文章将敏捷数据工程定义为将敏捷软件开发的思想应用于数据开发过程得到的一系列工程方法的合集。
敏捷数据工程实践
数据工程内容非常广泛，包括数据需求分析、数仓设计、数据开发过程、数据测试、数据运维、数据项目管理等。本系列文章不打算体系化的介绍所有内容，而是希望挑选一些重要的实践方法做一些分享。
本系列文章将围绕两部分内容进行探讨：
- 将成熟的敏捷软件开发实践应用于数据开发过程，可以得到哪些有效的数据工程实践？
- 针对数据开发中那些常见的而应用软件开发较少碰到的问题，应用敏捷的思想可以获得哪些好的实践？
价值观与原则
本系列文章探讨的敏捷数据工程实践遵循敏捷宣言中提及的价值观及原则。重申如下。
价值观
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
尽管右项有其价值，我们更重视左项的价值。
原则
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
总结
本文介绍了敏捷数据工程相关的概念，后续文章将基于这些概念，对敏捷数据工程实践展开讨论。作为总结，可以用一张概念图来概括前面的内容。
