从“数据孤岛”到统一数据体系，明源云DataOps实践探索之路 | 卓越技术团队访谈录

“数据”是新的生产要素已成为共识，而要挖掘数据价值，就绕不过数据管理。在数据管理层面，近几年业界有一个相关概念受到广泛关注——DataOps。

DataOps 的概念自首次被提出至今已有 8 年，并在 2018 年被 Gartner 纳入数据管理技术成熟度曲线。从实施上看，当下 DataOps 仍处在发展初期，鲜少企业或团队能据此真正沉淀一套方法论或技术产品的体系。不过，随着越来越多的企业开启 DataOps 实践，相信令人“雾里看花”的 DataOps 方法体系也会逐渐明朗起来。

明源云是其中一个探索者，过去 25 年，明源云的数字化服务主要聚焦在住宅开发领域。随着房地产行业从过去的红利时代急转进入混沌时代，不少企业开始纷纷布局存量市场，并注重精细化管理，明源云的下一步业务战略正是沿着不动产的产业数字化方向扩展。不动产企业的发展战略趋向多元化，对于经营决策、运营服务等的需求越来越迫切，同时，明源云意识到，在企业经营管理战略上，如果数据不能保证及时和准确，数字化价值则会大打折扣。为此，过去几年在业务发展路径和客户数字化诉求的驱动下，明源云持续结合 DataOps 实践、探索数据治理体系的落地。近期我们与明源云天际·PaaS 平台数据云事业部产品负责人梅容进行了一次交流，以进一步了解明源云 DataOps 的实践过程、从中收获的经验和认知。

关于 DataOps，一个常见的基本问题是，DataOps 和 DevOps 有什么关系和区别？

2021 年，Gartner 发布的“十大数据和分析技术趋势”中有一项是“XOps”，Gartner 研究总监孙鑫对此解读道：

现在的分析和 AI 解决方案没有跟上日益增长的实践的多样性，其原因在于应用当中的 DevOps 的最佳实践的多个 Ops 学科，大家可以看到的有 DataOps、ModelOps 以及 DevOps，造成了市场的混乱，所以 Gartner 把它叫做 XOps。

无论是什么 Ops，它的目标都是利用 DevOps 的最佳实践去实现效率和规模经济，并确保可靠性、可重用性和可重复性，同时减少技术和流程的重复，从而实现自动化。

同样地，明源云的 DataOps 实践也是基于 Devops 衍生而来。“将 DevOps 中使用的 CI/CD 理念应用于 DataOps，实现数据横纵链路上的自动化和自主管理。”梅容表示，DataOps 是数据管理的工具化和自动化的方法体系，将数据的需求设计、研发实现、发布运行、交付运维等关键流程自动化，从而提高对业务场景的价值，其同样需要将标准、流程、机制、组织和技术融合落地。

今天，企业在构建数据资产的过程中离不开数据治理，但在梅容团队看来，数据治理是方法论，它能指导大家怎么去把数据治理得准确和稳定，但它没有办法负责数据运行时的及时、稳定和准确。因此其引入的 DataOps 会更偏向“运行态”，并在数据应用的整个流程体系进行探索和实践。

2017 年，某个头部地产客户的数据治理和 BI 项目让明源云意识到一个迫切待解的问题：如何保证持续稳定的数据质量？

当时，团队在快速兑现了该客户预期的数据指标体系和管理看板后，在交付过程中却经常收到来自用户的反馈——数据错误影响业务使用。

团队在排查问题后发现是数据在定期清洗过程中，经常出现数据质量问题，其中既有来自业务的影响，如：数据来源的业务系统不规范的更新表结构；数据口径不一致，同一个指标数据在不同的业务系统有不同的表述；数据填报不规范等。

也有技术问题带来的影响，如 ETL 过程中某字段变更导致数据加工出错，数据处理引擎突发数据变更峰值造成链路阻塞，系统服务出现异常导致调度任务执行失败等。

当时的 BI 产品只能检测到系统里面的数据有没有出问题，其清洗和运行服务是不是正常，但是没有办法覆盖到数据产生端的异常问题。在这样的背景下，团队提出了“全链路的数据巡检监控和预警”机制。它可以回溯到数据产生的业务源、在工具里面对数据进行加工的清洗过程，再回溯到 BI 里面，把每一端的巡检来串联起来，通过 OLTP 逻辑去判断最后呈现的数据是否准确。

但巡检事后预警机制，并不能根本性地解决事前发生的问题。于是团队又开始进一步探索，怎么能够保障它不出问题？这相当于要在“事前”的数据研发侧做探索。

前面提到，数据质量问题频出与业务端的影响有关，这里涉及一个常发生的情况是：开发人员经常改“口径”。究其原因，和管理层经常需要从不同维度去看数据有关，一旦管理层提出了基于某个指标的新的看数据的维度，开发人员可能又得重新去开发一次。

“从数据模型的角度来讲，这种需求场景往往只要在数据多维模型上增加维度或者调整已有指标的计算逻辑就可以解决。数据是衡量业务过程和管理结果的，和业务模型是一一映射关系。我们在研发过程中会做 DDD 领域建模，但却忽略了数据建模过程。等到要使用数据时，例如输出业务报表或者跨业务间数据指标查询时，才会考虑给数据团队提需求，此时再介入设计，识别到业务开发问题的变更成本较高，往往就埋下了技术债务，在数据治理过程中进行纠偏，处理成本和效果都不太好。”梅容指出，这一点反映出团队原先在开发前置环节的数据建模有所欠缺。

所有业务模型是相对稳定的，映射到数据模型也是一样。为了考虑功能和服务的可复用性，会进行应用业务建模，相对应的数据模型也要同步设计。业务应用研发和数据资产构建不应该是上下游关系，而应该是并行关系，通过业务建模和数据建模可以相互咬合来验证设计的合理性。

因此，为了在事前避免引入数据质量隐患，梅容团队认为第一要点是要保障数据开发人员可以基于业务建模的思路去映射完成数据模型设计，定义数据逻辑规范，然后再去切入开发过程。

这个思路类似于现在常见的应用开发流程，产品经理会去基于领域建模、基于领域的实体、对象、事件去做通用模型的设计，设计完之后，由研发人员基于这个设计去完成代码实现，去满足事件、对象以及事件对象的交互过程。

参照上述思路，团队把数据研发的过程分成了两段——先数据建模后开发。“通过我们对业务过程的分析，去定义这个业务过程中它涉及到的维度、事实，建立多维模型。”等建好了之后，开发的同学才接着做。规范在前，开发在后，它能按照业务语言和需求保持一致性，也能约束开发实现的严谨性，从而预防业务源头端引入的质量问题。

“先建模，再开发”是在事前解决问题的第一类举措，团队提出的第二类举措则是在明源的体系里统一数据体系，实现“实时运维、有的治理”的数据工具。

明源云的业务系统和很多企业一样是“烟囱式建设”，每个业务系统各有各的数据服务中心。各数据服务中心的数仓构建过程、规范、标准、清洗的脚本和清洗的语句都不一样，导致严重的“数据孤岛”问题。

团队认为，要解决这个问题，要以统一数据体系为基础。为此，明源云建立了 5 个“1”的数据工具标准：

1. 统一数据架构标准。所引用的大数据引擎、数据开发工具必须统一，这样才能保证开发脚本 SQL 语句是一样的，从而约束每个业务员出来的数据的一致性。

2. 统一基础数据标准。将各业务系统的组织、项目、人员、客户、供应商等高度共享的数据进行统一采集管理与分发，实现基础数据实体 ID 统一，为支撑企业数据资产沉淀做好铺垫。

3. 统一数据资产标准，即上文提到的先建模再开发，要求每一个业务板块都按照这种模式去把其数据进行规范化的治理，形成多维模型、指标模型和标签模型等数据资产，并基于模型的应用场景封装，提供标准的查询服务 API。

4. 统一数据分析标准。数据分析师可以直接应用数据资产模型的查询服务，不用进行繁琐的数据准备，大大减少了 SQL 开发，从而保证数据口径的一致性。

5. 统一数据开放标准。面向业务数据消费场景提供统一数据共享工具，打造除 BI 外的智能流程引擎、自动化营销引擎、预警简讯等一系列智能数据产品。

通过 5 个“1”，把数据的产生端、数据的生产端、数据的消费端和数据的开放端都统一，明源的业务体系里的数据才能完成标准化。

在数字化转型中，企业对于数据安全和数据资产的价值要求越来越高，不论是业务系统内置的数据中心，还是明源为企业提供数据治理服务和构建数据资产中心，都要求能够私有化，部署在国资云或者自建机房环境。团队利用 Kubernetes 容器应用集群化管理，能够对引擎中间件、平台服务等以应用组合包方式，进行一键部署和统一运维。整套系统云端和私有化的部署交付在 30 分钟内完成，并具备自动化资源调度，动态扩容等能力。

数据工具的统一应用，解决了数据管理流程化的落地性。在数据生产和消费链路中，仍然会有技术侧或者人为引入的异常。还需要在数据流程中通过巡检、运维机制的在线化保证，以规则的确定性应对结果的不确定。

明源云数据运维的基本原则如下：

• 业务规则穿插在设计中完成，设计即标准。不增加用户的工作量，自动形成数据质量知识库沉淀。

• 监控先建立全局视角，分主次、优先级和处理时效。对重要场景的数据终端和基线做高优先级兑现，避免无效信息爆炸。

• 建立业务和技术双视角的责任模式，自动定位根因指向确定的排错解决方。尊重人性，谁利害相关，谁主责解决，避免靠人线下推进导致的多方拉扯情况。

通过以上原则，在工具产品中落地了全链路巡检机制，拉通业务数据库和业务应用场景，形成从数据发生、数据采集、数据处理、数据服务、数据查询和数据呈现等关键环节的规则巡检，并基于分级规则预警和推送优化建议。对运行态的风险、异常实时可知，保障数据稳定、准确和及时性。

明源云在 DataOps 上的探索与实践之路并非一帆风顺。技术层面，在大数据技术方案选型上一直在“踩坑”和“填坑”。

据了解，一开始数据团队是基于公有云商业化的数据平台架构去做业务实践，后来发现在服务器上花了大量成本之余，也依然有很多解决不了的场景。因此，团队就坚定地选择了自建大数据底层架构的道路。

据梅容介绍，一开始先做离线架构的搭建，选用 Lambda 架构，由于明源云的 SaaS 服务报表的查询并发很高，查询场景多样化，因此前后有过不少技术选型尝试，例如在离线部分，尝试过 StarRocks、Presto、TiDB......

梅容表示，大数据的组件不像原来的关系型数据库那么成熟，行业也一直在发展，不断有厂商去做各种各样的尝试，明源云需要结合自己的业务场景去选择最适合自己的架构。

除了技术挑战，DataOps 实践面临的另一大挑战是在内部推行统一数据体系。“对于业务团队而言，虽然一些已有的数据基础设施存在一些问题，但也能基本满足业务快速迭代、快速创新的需求。但在这个人人都忙于兑现客户需求的过程中，怎么样‘对运行的飞机换引擎’，如何在契合业务快速发展对数据技术升级要求的机会下，既保留现有数据成果，又能够让大家快速应用我们的数据体系产品，以实现组织效率成本的最优化？”

“整个过程并非要大拆大建，把所有数据拉取过来进行集中式治理，而是以“分区治理、分区入湖”的模式展开。”梅容说到，“对于数据质量相对较好的业务团队，采用逆向建模方式，以结果映射的方式，对客户数据消费场景进行规范化和一致性的数据管理，以保证交付客户应用的准确性和稳定性；而对于要为客户提供数据资产价值创造的业务团队，和数据团队合作，按数据标准体系共建的方式，形成数据驱动业务价值的场景化数据中台解决方案，例如行业客户数据中台（CDP）、供应链协同平台（SDP）、企业一体化经营决策平台等。”

探索 DataOps 也让明源云更坚定了一个目标：需要从用户视角，建立一套持续、稳定、可快速复制的面向交付的数据体系，也就是让数据资产对所有的利益相关者来说都是现成的、可访问的和价值最大化的。

DataOps 在明源云的数据资产体系中也会应用在交付实施的方案中，用于支撑数据业务化产品的灵活交付，以及持续稳定、准确的运维保障。

但数据治理的效果很难显性化体现，难以让客户感知到成果。这也是明源云在落地 DataOps 的过程中，遇到的主要挑战之一。为解决该问题，面向客户三类角色，团队把 DataOps 实施的成果可视化和价值化呈现：

1. 业务视角的数据资产全景图：实时看到按业务主题域构建的四类资产多维模型、指标、标签、API 服务资产等，穿透查看资产模型的生产链路，便于识别业务系统数据风险。

2. 价值视角的数据资产信息架构：包含面向高层决策的指标价值树和业务人员的指标目录，能够洞察业务发展趋势、异常变化、晴雨表现，分类管理高层和业务人员使用的指标体系。

3. 技术视角的数据地图：数仓分层的各类表清单，数据生产流程和血缘关系，体现拉通了哪些系统的数据，支撑了哪些业务场景的应用。

4. 运维视角的数据全链路巡检监控告警：基于终端用户（重点高层报表）数据消费场景，对数据采、建、用数据全链路进行自动化的巡检，主动及时地推送对数据应用的异常。

“DataOps 的设计理念是以用户为中心，用确定性的工具来解决不确定性的业务变化。”那么，一般行业上怎么解决这类不确定性的问题？

梅容进一步总结道：“第一点是有规范，怎么样都在框架内，这样就不至于说各自发散收不回来。第二点是工具化，一定要有在线化的工具，可以按照其规范一步步执行。”

需要注意的是，现阶段也有 DataOps 解决不了的问题，比如 DataOps 更多是方法论和一系列有效的工具集合，并没有业务知识的沉淀，即行业 Know-how 的开箱即用内容；缺乏发现和排除问题、自动修复能力；另外，DataOps 目前是基于项目实践经验的规则治理，应该加入更多自学习的能力，向 AIOps 演进。

谈及接下来明源云在 DataOps 的探索，梅容告诉我们，首先是数据体系落地，即明源云产研体系里的五层数据体系，先把它做实；其次是 AIops 数据准确性盘点，目前 DataOps 更多还是要靠人去维护规则标准，后续需要能根据数据趋势去预判数据的增减对于业务是否合理等等；第三是智能化的问题排查恢复，以及最佳实践的优化建议，即基于终端业务用户的数据消费场景，事前提供数据变更时的关联影响体系，事中提供告警并针对异常提供数据血缘、生产链路关系分析，事后提供数据质量巡检规则配置加强。

点个在看少个 bug 👇