采访嘉宾｜梅容 ， 明源云天际·PaaS 平台数据云事业部产品负责人
“数据”是新的生产要素已成为共识，而要挖掘数据价值，就绕不过数据管理。在数据管理层面，近几年业界有一个相关概念受到广泛关注——DataOps。
DataOps 的概念自首次被提出至今已有 8 年，并在 2018 年被 Gartner 纳入数据管理技术成熟度曲线。从实施上看，当下>
明源云是其中一个探索者，过去 25 年，明源云的数字化服务主要聚焦在住宅开发领域。随着房地产行业从过去的红利时代急转进入混沌时代，不少企业开始纷纷布局存量市场，并注重精细化管理，明源云的下一步业务战略正是沿着不动产的产业数字化方向扩展。不动产企业的发展战略趋向多元化，对于经营决策、运营服务等的需求越来越迫切，同时，明源云意识到，在企业经营管理战略上，如果数据不能保证及时和准确，数字化价值则会大打折扣。为此， 过去几年在业务发展路径和客户数字化诉求的驱动下，明源云持续结合 top="1289">什么是>关于>
2021 年，Gartner 发布的“十大数据和分析技术趋势”中有一项是“XOps”，Gartner 研究总监孙鑫对此解读道：
同样地，明源云的>
今天，企业在构建数据资产的过程中离不开数据治理，但在梅容团队看来，数据治理是方法论，它能指导大家怎么去把数据治理得准确和稳定，但它没有办法负责数据运行时的及时、稳定和准确。因此其引入的 top="1843">DataOps 的探索与实践
2017 年，某个头部地产客户的数据治理和 BI 项目让明源云意识到一个迫切待解的问题：如何保证持续稳定的数据质量？
当时，团队在快速兑现了该客户预期的数据指标体系和管理看板后，
在
交付过程中却经常收到来自用户的反馈——数据错误影响业务使用。
也有技术问题带来的影响，如 ETL 过程中某字段变更导致数据加工出错，数据处理引擎突发数据变更峰值造成链路阻塞，系统服务出现异常导致调度任务执行失败等。
当时的 BI 产品只能检测到系统里面的数据有没有出问题，其清洗和运行服务是不是正常，但是没有办法覆盖到数据产生端的异常问题。在这样的背景下，团队提出了“全链路的数据巡检监控和预警”机制。它可以回溯到数据产生的业务源、在工具里面对数据进行加工的清洗过程，再回溯到 BI 里面，把每一端的巡检
来
串联起来，通过 OLTP 逻辑去判断最后呈现的数据是否准确。
但巡检事后预警机制，并不能根本性地解决事前发生的问题。于是团队又开始进一步探索，怎么能够保障它不出问题？这相当于要在“事前”的数据研发侧做探索。
数据建模
前面提到，数据质量问题频出与业务端的影响有关，这里涉及一个常发生的情况是：开发人员经常改“口径”。究其原因，和管理层经常需要从不同维度去看数据有关，一旦管理层提出了基于某个指标的新的看数据的维度，开发人员可能又得重新去开发一次。
“从数据模型的角度来讲，这种需求场景往往只要在数据多维模型上增加维度或者调整已有指标的计算逻辑就可以解决。数据是衡量业务过程和管理结果的，和业务模型是一一映射关系。我们在研发过程中会做 DDD 领域建模，但却忽略了数据建模过程。等到要使用数据时，例如输出业务报表或者跨业务间数据指标查询时，才会考虑给数据团队提需求，此时再介入设计，识别到业务开发问题的变更成本较高，往往就埋下了技术债务，在数据治理过程中进行纠偏，处理成本和效果都不太好。”梅容指出，这一点反映出团队原先在开发前置环节的数据建模有所欠缺。
所有业务模型是相对稳定的，映射到数据模型也是一样。为了考虑功能和服务的可复用性，会进行应用业务建模，相对应的数据模型也要同步设计。业务应用研发和数据资产构建不应该是上下游关系，而应该是并行关系，通过业务建模和数据建模可以相互咬合来验证设计的合理性。
因此，为了在事前避免引入数据质量隐患，梅容团队认为第一要点是要保障数据开发人员可以基于业务建模的思路去映射完成数据模型设计，定义数据逻辑规范，然后再去切入开发过程。
这个思路类似于现在常见的应用开发流程，产品经理会去基于领域建模、基于领域的实体、对象、事件去做通用模型的设计，设计完之后，由研发人员基于这个设计去完成代码实现，去满足事件、对象以及事件对象的交互过程。
参照上述思路，团队把数据研发的过程分成了两段——先数据建模后开发。“通过我们对业务过程的分析，去定义这个业务过程中它涉及到的维度、事实，建立多维模型。”等建好了之后，开发的同学才接着做。 规范在前，开发在后 ，它能按照业务语言和需求保持一致性，也能约束开发实现的严谨性，从而预防业务源头端引入的质量问题。
统一数据标准体系
“先建模，再开发”是在事前解决问题的第一类举措，团队提出的第二类举措则是在明源的体系里统一数据体系，实现“实时运维、有的治理”的数据工具。
明源云的业务系统和很多企业一样是“烟囱式建设”，每个业务系统各有各的数据服务中心。各数据服务中心的数仓构建过程、规范、标准、清洗的脚本和清洗的语句都不一样，导致严重的“数据孤岛”问题。
团队认为，要解决这个问题，要以统一数据体系为基础。为此，明源云建立了 5 个“1”的数据工具标准：
部署和运维
在数字化转型中，企业对于数据安全和数据资产的价值要求越来越高，不论是业务系统内置的数据中心，还是明源为企业提供数据治理服务和构建数据资产中心，都要求能够私有化，部署在国资云或者自建机房环境。团队利用 Kubernetes 容器应用集群化管理，能够对引擎中间件、平台服务等以应用组合包方式，进行一键部署和统一运维。整套系统云端和私有化的部署交付在 30 分钟内完成，并具备自动化资源调度，动态扩容等能力。
数据工具的统一应用，解决了数据管理流程化的落地性。在数据生产和消费链路中，仍然会有技术侧或者人为引入的异常。还需要在数据流程中通过巡检、运维机制的在线化保证， 以规则的确定性应对结果的不确定。
明源云数据运维的基本原则如下：
难题与挑战
技术架构选型和内部推行的阻力
明源云在>
据了解，一开始数据团队是基于公有云商业化的数据平台架构去做业务实践，后来发现在服务器上花了大量成本之余，也依然有很多解决不了的场景。因此，团队就坚定地选择了自建大数据底层架构的道路。
据梅容介绍，一开始先做离线架构的搭建，选用 Lambda 架构，由于明源云的 SaaS 服务报表的查询并发很高，查询场景多样化，因此前后有过不少技术选型尝试，例如在离线部分，尝试过 StarRocks、Presto、TiDB......
做实时计算框架也是，“当时行业流行数据湖，包括 SnowFlake、Databricks 等国际一流厂商都用数据湖的架构，当时我们还跟 AWS 的工程师去聊，想搭数据湖的架构，但像 Hudi 和 Iceberg 在前两年的时候都不太成熟，过去也是尝试过一段时间。最终从生产稳定性角度考虑没有选择数据湖，而是结合 B 端管理实际场景，采用 CDC+自研 SQL 计算框架的实时监听来满足业务人员查看实时明细报表的场景；采用 Flink 流计算模式来满足营销等业务，基于实时指标运营的场景。基于社区版 Flink 的自研，把各团队使用的商业版，以及 Kafka、Pulsar 等消息队列进行适配改造。最终统一了技术架构，同步演进。”
梅容表示，大数据的组件不像原来的关系型数据库那么成熟，行业也一直在发展，不断有厂商去做各种各样的尝试，明源云需要结合自己的业务场景去选择最适合自己的架构。
除了技术挑战，DataOps 实践面临的另一大挑战是在内部推行统一数据体系。“对于业务团队而言，虽然一些已有的数据基础设施存在一些问题，但也能基本满足业务快速迭代、快速创新的需求。但在这个人人都忙于兑现客户需求的过程中，怎么样‘对运行的飞机换引擎’，如何在契合业务快速发展对数据技术升级要求的机会下，既保留现有数据成果，又能够让大家快速应用我们的数据体系产品，以实现组织效率成本的最优化？”
“整个过程并非要大拆大建，把所有数据拉取过来进行集中式治理，而是以“分区治理、分区入湖”的模式展开。”梅容说到，“对于数据质量相对较好的业务团队，采用逆向建模方式，以结果映射的方式，对客户数据消费场景进行规范化和一致性的数据管理，以保证交付客户应用的准确性和稳定性；而对于要为客户提供数据资产价值创造的业务团队，和数据团队合作，按数据标准体系共建的方式，形成数据驱动业务价值的场景化数据中台解决方案，例如行业客户数据中台（CDP）、供应链协同平台（SDP）、企业一体化经营决策平台等。”
数据治理的效果如何显现
探索>
DataOps 在明源云的数据资产体系中也会应用在交付实施的方案中，用于支撑数据业务化产品的灵活交付，以及持续稳定、准确的运维保障。
但数据治理的效果很难显性化体现，难以让客户感知到成果。这也是明源云在落地>
从>“DataOps 的设计理念是以用户为中心，用确定性的工具来解决不确定性的业务变化。”那么，一般行业上怎么解决这类不确定性的问题？
梅容进一步总结道：“第一点是有规范，怎么样都在框架内，这样就不至于说各自发散收不回来。第二点是工具化，一定要有在线化的工具，可以按照其规范一步步执行。”
需要注意的是，现阶段也有>
谈及接下来明源云在>
电子书推荐
本文选自《中国卓越技术团队访谈录》（2022 年第二季），本期精选了微软 Edge、蚂蚁可信原生、明源云、文因互联、Babylon.js 等技术团队在技术落地、团队建设方面的实践经验及心得体会。本期电子书已经在 InfoQ 网站上线，大家可以扫描下图二维码下载，查看更多精彩内容。
《中国卓越技术团队访谈录》是 InfoQ 打造的重磅内容产品，以各个国内优秀企业的 IT 技术团队为线索策划系列采访，希望向外界传递杰出技术团队的做事方法 / 技术实践，让开发者了解他们的知识积累、技术演进、产品锤炼与团队文化等，并从中获得有价值的见解。
