激活数据价值，探究DataOps下的数据架构及其实践丨DTVision开发治理篇

据中国信通院发布，2012 年到 2021 年 10 年间，我国数字经济规模由 12 万亿元增长到 45.5 万亿元，在整个 GDP 中的比重由 21.6% 提升至 39.8%。顺应时代发展新趋势，“数据” 成为新的生产要素已是毋庸置疑的共识。

如果说数据中台的崛起代表着企业数字化转型从流程驱动走向数据驱动，从数字化走向智能化。那么 DataOps，则是实现数据中台的一个优秀的理念或方法论。

DataOps 的概念早在 2014 年即由 Lenny Liebmann 提出，2018 年 DataOps 正式被纳入 Gartner 的数据管理技术成熟度曲线当中，标志着 DataOps 正式被业界所接纳并推广起来。虽然目前在国内仍处于发展初期，但是 DataOps 的热度逐年上升，在可预见的未来 2-5 年内将得到更加广泛的实践应用。

袋鼠云便是其中的一位探索者。作为全链路数字化技术与服务提供商的袋鼠云，从创立以来便一直深耕大数据领域。伴随着各行各业加速数智化转型的步伐逐年加快，对于数据治理、数据管理等方面的许多问题也逐渐显露。

为此，在技术进步和客户数字转型需求的驱动下，袋鼠云打造的一站式大数据开发与治理平台 —— 数栈 DTinsight，基于 DataOps 理念开展数据价值化流程，实现了数据全生命周期的质量监管和数据开发流程规范，为数据治理保驾护航。

响应变化

DataOps 的核心理念之一就是及时响应需求端的变化。下面是一张很典型的企业数据架构图：

数据从左侧的源系统流入，中间环节是各类数据处理的工具，例如数据湖、数据仓库或数据集市、AI 分析等，数据经过清洗、加工、汇总统计、数据治理等过程，最终通过 BI、定制化报表、API 等工具服务于各类需求方。

file

企业内的数据架构师或管理者，在定义平台架构时，一般主要考虑生产环境下的极致的性能、延迟、负载管理等问题，很多计算引擎 / 数据库都精于此道。但这种架构并没有体现出「响应快速变化」的能力：

这就像是设计一条公路，在设计时只考虑了正常情况下的通行能力，并没有考虑事故、堵车、暴雨等各种临时变化，在「上线」之后发现每日疲于应对，并没有提升太多通行能力（比如只有 2 个车道的隧道，一个小的剐蹭事故就可能把整条隧道堵住）。企业内的数据平台也会遇到类似的情况，企业内的数据工作者，每天甚至每个小时都要响应这种变化，有时一个简单的 SQL 变更上线甚至可能要花几天的时间。

在设计阶段考虑各种变化，可以更灵活、更稳定的响应，下面是 DataOps 视角下的数据架构。

DataOps 视角下的数据架构

数据架构师在建设伊始就提出如下一些敏捷性的标准，例如：

・任务从完成开发到发布生产，需要在 1 小时内完成，且对生产环境无影响

・在发布至生产环境前，及时发现数据错误

・重大变更，在 1 天内完成

同时需要考虑一些环境的问题，包括：

・必需维护独立的开发、测试和生产环境，但要在一定程度上保证其一致性，至少是元数据的一致性

・可以人工编排，或自动化的实现数据的测试、质量监控以及部署至生产环境

当架构师开始思考数据质量、快速发布、数据的实时监控等问题时，企业就向 DataOps 迈进了一步。

DataOps 架构的分解与实践

讲完了 DataOps 视角下的数据架构，接下来来讲讲 DataOps 架构的分解与实践。DataOps 具体实践可以分解为如下几个关键点：

file

多环境的管理

DataOps 的第一步从「环境管理」开始，一般是指独立的开发、测试和生产环境，每个环境下都可以支持任务的编排、监控和自动化测试。

数栈目前可支持同时对接多套环境，只要网络相通，即可实现一套数栈对多个不同环境的统一对接和统一管理。数栈是通过 Console 中的「集群」概念来进行不同环境的区分，不同的集群可灵活对接各类不同的计算引擎，例如各类开源或发行版 Hadoop、星环 Inceptor、Greenplum、OceanBase，甚至 MySQL、Oracle 等传统的关系型数据库，如下图所示：

file

任务发布

承接上个步骤的多环境管理，在实际开发过程中，需要进行多个环境之间的任务发布，假设存在开发、测试、生产环境，则需要在多个环境之间进行级联形式的发布，如下图所示：

file

在这种多环境发布的情况下，数栈可支持三种方式进行发布管理：

● 一键发布

当各个环境网络相通，可使用一套平台对接各个环境，实现「一键发布」。一键发布过程中，仅有一定权限的用户才可以执行发布动作，提升生产环境稳定性。与此同时，可自动替换一些关键的环境信息，例如同步任务中的数据源连接参数、不同环境下的算力配置等。一键发布比较适合 SaaS 或内部云平台的管理方式。

● 导入 / 导出式发布

在目前国内接触的绝大多数场景中，客户为了实现更高的安全等级，生产环境会采用严格的物理隔离。这种场景可以采用导入导出的方式实现任务的跨环境发布，用户可手动将新增、变更或删除的任务导入至下游环境。

● Devops 发布

某些客户可能已经采购或自研了公司级的线上发布工具，此时需要数栈定制化的对接其接口，将相关变更信息由第三方 CI 工具（例如 Jekins）代为执行发布。

file

代码的版本管理

每次进行跨环境的发布时，需要记录每次发布代码的版本，便于后期排查问题。在实际场景中，经常需要进行不同版本间的代码对比、版本回退等操作。

数栈除了支持对代码内容进行对比之外，还支持对任务相关的更多信息进行对比，包括任务调度周期的配置、任务执行参数、环境参数等，并可以「一键回退」至指定的版本。

file

访问与权限管理

在企业内的多个环境中，一般对生产环境的要求最高，对开发和测试环境相对宽松。在这种情况下，即需要管理用户在不同环境下的认证或访问信息。实际上为了开发和测试方便，且没有敏感数据，在这 2 个环节，一般是普通用户都有全部的数据权限，并可以访问各种工具，但在生产环境中，用户肯定只有自己权限范围内的数据权限。

根据引擎的不同，数栈可支持多种数据权限管理方式，包括：

● Hadoop 引擎

以 Kerberos 为基础的认证安全 + 以 Ranger/LDAP 为基础的数据安全。可以支持库、表、字段级别的数据权限控制。同时可支持数据脱敏。

file

● JDBC 类引擎

部分场景中，客户可能并未采用 Hadoop 来建设数据平台，而是采用一些 JDBC 类的数据库（例如 TiDB、Doris、Greenplum），而数栈本身并不管理 JDBC 数据库的权限，而是采用账号绑定的方式来控制，以此区分不同账号的权限，例如：

・数栈 A 账号，绑定数据库 root 账号

・数栈 B 账号，绑定数据库 admin 账号

● 任务编排、测试与监控

在发布上线至生产后，数栈可将上述各个环节串连起来，用户从开发阶段可以一键发布至测试环境，经测试环境验证后，观察任务实例、数据产出的运行情况，运行无误后可发布至生产环境。

写在最后的话

DataOps 是一种最佳实践的理念，但目前在国内还处于比较早期的阶段，数栈在这方面有过一些实践经验，但还有不少可以优化的内容，比如数据质量的规则也需要跨环境发布、任务代码、任务模板的导出需要支持更多的任务类型等等，期待未来行业内有更多的 DataOps 的最佳实践能产生。