作者：陈荣耀 阿里云全球技术服务团队
一、背景&挑战
数字化时代，企业希望借助数字化的技术能力来提升企业的经营能力，从最终业务目标上来看，一般分三类：
1. 增加收入：基于经营数据的智能分析来提升产品竞争力，更快速的产出产品创新；
2. 降低成本：通过对资源的盘点分析，性能的优化，降低资源成本，通过企业内建立管理制度和标准，降低人力管理成本；
3. 减少损失：一种是基于数字的反馈，不断的优化用户体验，减少客户流失，另一种是通过采集全域的数据并加以分析，降低生产链路的故障风险。
为了帮助企业实现这些业务目标，衍生出了许多新技术，云厂商往往也会向客户介绍各种高精尖技术和解决方案。但现实是，很多企业在数字化转型的过程中会感觉到效果并不明显，或者说企业并没有“用好数”，这里面的问题点在哪？个人觉得有以下几个主要挑战：
1.1 组织文化
做数字化转型，首先需要组织层面启动数据驱动的文化建设，并明确定义出可数字度量的业务目标。企业的业务决策需要依赖于数字，需要不断提升组织中人员的数字素养，需要让组织中的各类人员具备基础的大数据知识、数据分析知识、统计知识，具备通过数据向其他人传达信息的能力。
1.2 技术鸿沟
创建完整的数据链路需要许多软件和硬件结合起来，架构师必须全面了解数据生命周期各个角色，各个阶段的需求，但现实是往往人们更关注于拼图的一部分，而忽视其他部分。比如大型企业由于数据体量较大，往往更关注于大数据的处理技术，如何构建数据中台，如何加快查询速度，如何降低资源成本，但对于数据科学家们如何更快获取数据，如何更好地管控权限，更快地产出业务价值等等存在缺失，而中小企业往往更关注数据科学家需要的分析软件，但对于数据管道缺少投资，这使得许多分析工作局限在个人计算机上。另一方面，大部分的项目会引入多家公司，多种数据产品，不同产品之间必然存在数据和服务的隔离，如何更好地利用好各方的能力，打破技术之间的鸿沟是每个企业都要面对的痛点问题。
1.3 知识鸿沟
企业中围绕数据有很多的角色，各个角色之间存在较大的知识鸿沟。比如对于数据科学家，他们擅长从数据中挖掘价值、创建模型，但将模型投入生产的经验往往不足，比如代码的版本控制、测试、文档等等，缺少端到端的技能来生产数据产品并获得反馈，而对于数据工程师，他们比较擅长数据管道的搭建，但对于数据如何被使用，如何产出最终的业务价值往往不太清晰，因此在数据工程师和数据科学家之间往往会出现一些分歧。
1.4 数据连续性
技术能力需要考虑时间这样一个重要变量，特别是对于数据技术，解决当下的数据问题相对简单，想要数据持续的产出业务价值就需要大量的工程工作和组织保障，需要量身定制适合于业务的数据域CI/CD能力，需要持续性地对数据进行治理，需要对数据安全和合规进行持续性检测，需要具备全链路的可观测能力，保障数据服务的连续性并持续优化资源成本。
1.5 小结
企业想要“用好数”只制定长期的战略并依赖于产品的技术能力是远远不够的，亟需一种战术指导思想，指导企业如何围绕数据链路，从全局的视角去保障数字化战略的落地，提升组织的数字素养，打破技术和知识的鸿沟，优化数据架构，保障数据服务的连续性。
二、DataOps理念
2.1 起源
为了解决上述问题和挑战，DataOps理念应运而生，DataOps的概念在2014年由Lenny Liebmann提出，在《3 reasons why DataOps is essential for big data success》这篇文章中，Lenny提出DataOps是优化数据科学和运营团队之间协作的一些实践集。经过多年的发展，2018年Gartner将其纳入到数据管理的技术成熟度曲线，标志着DataOps正式被业界所接纳并推广起来。
在最新的Gartner: Hype Cycle for Data Management, 2022报告中，DataOps的概念已经进入第二阶段的“过热期”，2021年的时候DataOps还属于第一阶段的“创新萌芽期”。
业界各厂商对于DataOps有着不同的理解：
-
IBM：IBM将DataOps定义为 DataOps 是人员、流程和技术的有机结合，用于快速向数据公民提供可信的高质量数据。
-
Gartner：DataOps是一种协作性的数据管理实践，专注于改善整个组织的数据管理者和消费者之间的沟通、整合和数据流的自动化。
DataOps is an agile and collaborative data management practice focused on improving the communication, integration, automation, observability and operations of data flows between data managers and data consumers.The goal is operational excellence in data delivery.
-
Wikipedia：DataOps是一套实践、流程和技术，它将综合的、面向流程的数据观点与敏捷软件工程中的自动化和方法相结合，以提高质量、速度和协作，促进数据分析领域的持续改进文化。
-
中国信通院：数据研发运营一体化（DataOps）是一种面向数据全生命周期，以价值最大化为目标的最佳实践。聚焦于协同从数据需求输入到交付物输出的全过程。明确研发运营目的，细化实施步骤，在价值运营、系统工具、组织模式、安全风险管理的支撑下，实现数据研发运营的一体化、敏捷化、精益化、自动化、智能化、价值显性化理念。
DataOps业界目前尚缺少统一的、细化的定义和实践，本文将结合个人近期的学习，谈下个人的看法。希望可以抛砖引玉，让大家对DataOps有个初步认识。
2.2 目标
首先DataOps的Ops是很容易被混淆的一个概念：
-
☒ 错误：Ops在当前语境下并不是运维的意思也不是操作的意思，DataOps在当前语境下不是指基于数据挖掘和分析后去运维业务系统或PAAS平台。
-
☑ 正确：Ops指的是运营，DataOps指的是对数据的运营，即如何让数据为业务发挥更大的价值。
DataOps的目标个人觉得可以这样定义：更快速的交付更高质量数据
具体来说：
-
建设组织文化：重视数据文化的建设，为企业定制如何用数的组织设计建议，帮助企业明确数据战略的业务目标，提供提升组织人员数字素养的培训课程。
-
填补技术鸿沟：聚焦数据的流向，而不是单项技术或组织功能，定义出完整的数据技术大图，提供各个数据模块的咨询服务，横向去连接各个数据产品和服务，为企业制定最优的“用好数”技术方案，填补技术鸿沟。
-
填补知识鸿沟：基于数据技术大图，明确定义出组织内各个数据角色需要的知识地图，提供数据链路上各类数据标准和规章制度的建议，为组织培养“T”形人才，填补人员的知识鸿沟。对于数据科学家而言，可以更直观了解到数据管道是如何搭建的，如何自助取数，对于数据工程师，可以更清晰了解数据的用途，这对于他们如何优化数据管道，如何讲清楚管道价值有较大的帮助，也能让工程师和科学家之间互相理解，提升组织协同效率。对于企业管理者而言，高效的数据流有利于更快发掘数据的业务价值。
-
保障数据连续性：提供如何保障数据生产链路，提升研发效率，降低数据风险的标准，实践和技术方案。宣扬系统性思维（精益思维和敏捷协作），从全局优化整体系统，定制适合的数据产品研发策略。
系统思维的重点是理解一个系统的组成部分如何相互关联，如何随着时间的推移而工作，如何与其他系统互动，以确定模式，解决问题并提高业绩。敏捷思维和精益思维是系统思维的典型子集。敏捷思维旨在使系统更容易适应不确定性，而精益思维则是致力于将浪费从系统重剔除。 ---《DataOps实践手册》第五章 构建反馈和度量
从目标来看，DataOps是一个很大范畴的理念，技术只是其中一部分，核心是帮助企业围绕“用好数”，聚焦数据链路，构建完整的组织和数据能力。
2.3 DataOps和DevOps的关系
DataOps的概念本身是从DevOps借鉴过来的，最核心的差异点就是面向的对象不同，DevOps的理念是为了更快的交付软件，而DataOps的理念是为了更快的交付数据。
DevOps改变了软件部署的速度和规模，使得代码可以随时处于可以发布到生产中的状态，为了实现这个目标，DevOps定义了一系列宣言和价值观，业界也沉淀了大量的敏捷能力，比如CI/CD的研运能力、敏捷框架、度量体系、自动化测试等能力。和软件开发一样，数据类的产品也是需要对业务的变化进行快速的反馈，因此DataOps的概念也被提出来。
DataOps的许多原则和概念都是从DevOps中衍生出来，不过DataOps更关注于数据的交付，比如针对软件的交付是不会强调数据管道（ETL/ELT）的搭建和维护，数据质量的持续性治理，数据层的可观测性监测，数据分析层的优化和展现等等。
两者关系大致如下，参考链接What the Ops are you talking about?
DevOps面向的角色主要是软件的研发、测试、运维等角色，DataOps面向的角色在前者之上还有数据分析师、数据科学家、数据开发、BI分析师等等，涉及的部门更多，技术栈更多，组织间协同的成本也更高，从这个角度来看，DataOps面临的挑战更大。
有些企业把DataOps笼统的定义为数据域的CI/CD能力或是数据管道（数据集成/ETL/ELT等等），我觉得是不准确的，就像DevOps并不是只定义一个CI/CD能力一样，DevOps核心还是敏捷的开发理念，技术是服务于理念的，是一种上下的支撑关系。同理，DataOps在数据域技术能力之上，更需要的是如何指导组织“用好数”的方法/标准/制度/实践等等。
2.4 DataOps原则&宣言
DataOps的原则借鉴了DevOps，基于数据的特性，进行了一些修改，官方链接：
1. 个人与互动重于流程与工具：强调团队间的协作，提倡面对面的沟通，这点和敏捷宣言一致。
2. 可用的分析重于详尽的文件：提倡分析即代码，这意味着需要有较好的版本管理，CI/CD，可重用环境等能力，这对数据的基建要求还是很高的。
3. 与客户合作重于合约协商：希望和客户建立一个合作关系，而不仅仅只是雇佣关系，DataOps的落地强依赖客户组织的协同，对数据链路持续性的优化，和客户之间其实是一种能力互补。个人觉得未来数据域的合同条款，商务流程也可能会发生变化。
4. 实验、迭代以及回应重于大量的前期设计：借鉴了软件MVP版本迭代的模式，引入敏捷的思想进行数据研发。
5. 跨部门的营运所有权重于独立的责任：传统企业内数据是一个个的孤岛，每个部门掌管自己的那一部分数据权限，DataOps的核心在于让数据更快的流动，因此提倡在保障安全的前提下，通过流程和机制的优化让数据的权限控制更加灵活。
宣言共有18条，对原则进行了一定程度的拆分细化，感兴趣可以看下。
2.5 DataOps架构师画像
企业为了加快软件的研发效率往往会有DevOps架构师这样的角色，但当前还没有明确定义DataOps架构师这样的角色，个人觉得DataOps架构师需要具备以下能力：
1. 精通DevOps理论；
2. 精通DataOps理论；
3. 熟练掌握各类数据产品，某几个数据领域需要有较深入的研究，T型人才；
4. 对数据流有较深入研究，具备敏捷和精益的思维，具备从全局优化数据链路的技术沉淀；
5. 可以帮助企业制定数据战略，明确业务目标，有一定行业经验，有帮助多个企业落地DataOps的实践经验。
2.6 DataOps评测
之前有幸参加信通院组织的某大型银行的DataOps能力成熟度评测，这是国内首次明确定义出DataOps的成熟度模型并进行正式评测，详情请参考链接，下图列了数据集成这个模块的部分评测条款：
可以看到，除了技术能力，DataOps重视制度、规范、标准的制定，重视技术的培训，重视数据链路上不同环节之间数据的互通，交互的联动等等，从全局的视角去提升数据的使用效率，即更快速的交付更高质量数据。
三、DataOps核心技术能力
前文介绍了DataOps的理念，要解决的问题和目标，本章重点聚焦在前文提到的DataOps数据技术大图。
强调：数据技术能力并非DataOps的全部，它是支撑DataOps理念的重要组成部分
企业的数据链路很长，涉及的技术栈也非常多，下图列了一些数据域的技术（地址链接，根据最近的一些调研，实际的复杂度会比下图还高很多）。
无论是填补技术鸿沟还是知识鸿沟，最关键的一点是需要聚焦数据链路，定义出最核心的数据能力，将零散的数据能力整合连接在一起，业界有很多组织或个人整理了一些数据链路的架构图，筛选了两个：
Diving into DataOps: The Underbelly of Modern Data Pipelines
3.1 DataOps数据能力大图
在上文一些前辈的基础上，我们对DataOps数据能力做了一些细化，尝试更清楚的定义出数据链路里核心的技术能力，希望可以更好的将我们自研的以及业界一些好用的数据工具有序组合在一起，建立索引，便于企业或个人更快速的找到并学习自己需要的技术能力。
围绕中间最核心的数据流向，整体分成三个部分：数据研发（图中上半部分），数据管理（图中下半部分），数据应用（图中右侧）：
1. 数据研发：取好数
数据研发聚焦数据的开发者，对这类角色而言，我认为最重要的痛点是如何高效的获取数据。
在一个项目中往往最头疼的就是如何清洗和搬迁数据，数据进入大数据平台后如何降低建模成本，如何更低成本的拿到自己想要的数据。因此我们将整个研发流程分成数据集成、数据建模、数据开发三个大类，每个大类中又定义了各自的核心能力。
以大家最为熟悉数据迁移为例，阿里云上不同的产品都会有各自配套的一些数据迁移能力，但在项目里经常会遇到不支持的一些数据源，这时候我们往往会临时写一些脚本去做支持，如果研发力量充足可能会定制一些工具，如果我们能有一个平台集中去管理这类工具，那自然可以降低研发成本。更进一步，如果可以将数据迁移领域业界一些好用的工具，新的迁移技术、实践案例、数据迁移的标准&制度都能体现出来，甚至如果客户有需要，还可以将我们的迁移能力集成到客户内部的系统里，这肯定是提升了客户“用数”的能力。另外，通过DataOps大图的指引，用户会知道迁移的下一步需要去验证数据和业务的一致性，在这个步骤内，又会有相关的工具能力和行业实践推荐，以此类推，最终从整个数据链路上为用户提供技术能力支撑。
2. 数据管理：管好数
数据管理主要面向数据的管理者和开发者，重点是去保障高质量的数据供给，这里面分了两块，一块是以敏捷的思想去管理数据的生产，实现敏捷的数据交付，一块是通过建立并维护可靠的数据服务，保障用户可以持续获得高质量的数据。元数据服务、数据质量、数据可靠性这些概念经常有相关讨论，暂不赘述，本文重点提一下数据域的CI/CD能力。
一提到CI/CD大家肯定都会想到DevOps：代码版本管理、流水线打包、发布管理等等，其实在数据研发管理的领域也是需要类似的CI/CD能力的，比如我们的内部的数据产品研发时就遇到过以下问题：
-
版本升级时遇到工作流不适配：新旧工作流中table_id、column_id的拼接规则不一致。
-
有时候表模型不适配，导致导入任务、加工任务、导出任务失败。公共层、应用层因为字段缺失或者字段类型对不上而报错。
而这类问题往往都是出在研发管理上：
1. 代码版本缺乏控制：
a.DDL版本依托于人工上传git管理，但很多时候都维护在本地。无法做到在开发工具上传。
b.DDL版本收版后，因为临时业务需求或者前期探查不全面等问题，需要临时增加一些新的字段、修改字段类型，修改DDL后(繁杂且琐碎)，往往会忘记同步到文档和Git仓库。
2. 工作流版本缺乏控制：
a.目前是只有一套最新版本的开发环境工作流，区分不出旧版本工作流。
b.加工逻辑变动频繁。
3.烟囱式开发：大量重复的计算加工，无法设置变量，写函数等。
数据产品项目中涉及到各种数据源，获取方式、指标定义、数据处理逻辑等各类信息的复杂度已经完全不亚于常规的软件系统。不借助优秀的工程实践，仅仅靠项目规范把控会很容易积累起数据产品的技术债，效率低下且难以持续。业界也已经有一些成功的技术实践，比如DBT，除了提供ELT的能力之外，还提供了数据域的部署&集成能力。我们目前在试点使用中，待有进一步实践后再分享。
3. 数据应用：用好数
数据应用主要面向的是数据的使用者：数据分析师，数据科学家，新的数据工作者（非技术人员），比如各个业务线的运营人员，企业管理者，甚至最终用户。通过打造更加简单易用的数据应用，结合配套的培训管理制度，组织设计，最终希望实现“全民数据科学家”（Citizen Data Scientist），加速企业决策和创新。
这块的产品比较多，差异性较大，业务价值的出口也是集中在这块，往往也需要结合行业属性进行定开，将数据域技术和行业经验结合才能比较好的落地，本文暂不展开。
3.2 数据能力实践：Modern Data Stack
业界最近又有一个新的概念叫Modern Data Stack，我理解其实就是将数据域的各种能力根据业务场景的实际需要分层组装在一起（stack）打包输出, 如下图：
在我们内部之前也做了类似的尝试，不过没有这么高大上的名称，我们制定了一些工具的建设标准，可将我们沉淀的工具结合业务场景打包输出去解决一线的问题，工具之间可以互相集成：
主要分成两个应用场景：
-
交付工具：面向交付提效，将工具的技术能力嵌入到业务交付的SOP(标准操作流程)中，为不同的业务域定制自己的交付工作台，提升交付的标准化率，降低一线人员的操作门槛，提升交付质量。
-
数据产品：面向外部客户售卖，将工具能力集成到产品中，降低产品的研发成本，通过产品的打磨，也提升了工具的成熟度。
四、总结
我们作为研发团队支撑了阿里云GTS内大部分数据域项目的交付，包含数据上云、数据库、大数据、数据中台等等，过程中沉淀了大量工具，为了方便工具的管理和使用，我们建立了 “星轨工具中心”进行工具的统一纳管，但工具功能比较零散，总是处于补业务窟窿的状态，显得“东一榔头西一棒”，缺少主线将工具能力串联在一起，技术缺少“牵引”，这在过去给我们带来很多困扰。
在不断的摸索中，我们发现，我们沉淀的工具大部分都是围绕数据链路，去弥补产研和项目需求的GAP，去帮助用户更高效的使用我们数据域的云产品，这和DataOps提倡的聚焦数据链路，从全局提效很匹配。另一方面，我们过去更偏向于建设单点技术能力解决问题，缺少理论的支撑，而DataOps在理论和实践层给了我们很多启发，让我们从全局角度去思考如何构建技术深度，建立行业影响力，如何将技术更好地和业务场景结合，提供整套的解决方案，思考方式从解决问题转向从业务角度去定义清楚问题和度量标准，帮助客户更快地获得高质量的数据，为企业构建更Modern的数据架构。
接下来我们团队会针对定义出的DataOps技术能力大图，每个模块组织同学进行深入调研，整理相关的工具能力和项目实践，形成DataOps的知识库。我们也在和信通院深度合作，一起建设DataOps白皮书，为DataOps在业界的发展贡献一部分力量，欢迎大家一起参与讨论和交流。
最后，数据域相关的内容较多，感谢李林洋、杨阳、王磊、郭晨瑞、庞兴华、何强、乐攀、陈旭等同学的建议和指导。
转载：https://blog.csdn.net/AlibabaTech1024/article/details/128655605