写在前面的话
数栈从「产品代号」到「自有专利技术产品品牌」，从只有离线+实时2个模块，演变成现在的8个模块，在产品设计方面曾经遇到过不少问题，本文主要分析了数栈产品演变过程中的一些全局性的问题与解决方式，有助于理解产品背后的设计理念。
数栈的1.0版本，由离线开发+实时开发2个模块耦合在一起，还谈不上模块解耦。在创建项目初始化时，需要连接Spark Thrift做元数据同步。但在几次POC时，发现部分客户只需要实时开发模块，而功能设计上又必须依赖离线的SparkThrift组件，这显然是不合理的。此为各模块解耦的起源。
在数栈进行2.0迭代时，除了离线与实时的解耦之外，还新增了数据质量、数据API等模块，在功能设计、导航设计上均采用了独立解耦的思路，为后续每个模块单独输出做好了铺垫。
在数栈的3.0及之前的版本，解耦一直是产品的主要方向，但在4.0版本中，我们也逐渐投入到了各模块的「打通」设计中，下面重点解释一下各产品之间的一些打通类的功能设计。
随着产品模块的逐渐增多，一些跨模块之间需要相互打通的需求也越来越强烈，例如数据源的重复配置、离线任务与质量校验的相互打通等，为了解决这些跨模块的问题，数栈在每个应用模块之外，增加了「基础能力层」的概念，「基础能力层」是实现公共模块或跨模块操作的中心。
从操作体验上，将重复性的功能合并统一，用户仅需一次配置即可各处引用，例如数据源中心、数据模型。
（1）统一数据源
在较早的版本中，每个独立应用都需要重复配置数据源，例如：同一个MySQL，如果作为BI查询的数据库，同时也有API调用，对用户来说，就需要在离线开发、实时开发和数据API这3个模块反复配置同样的连接信息，如果发生了host变更、用户名或密码的变更，也需要反复修改多次。另外，从内部的研发/测试资源投入上也存在反复投入的问题。
基于上述背景，数栈已在最近的版本中抽象形成统一的数据源中心，由管理员进行一次配置便可以授权给各个应用模块使用，降低了用户重复操作的成本。
（2）数据模型
数据模型是通过页面向导化的方式建立数仓中多张表之间的关联关系，并对这些模型进行统一的管理。数据模型可以应用在离线开发、智能标签和指标管理中，由于多个模块都依赖于此功能，因此将其抽象为统一的模块，类似数据源，已配置好的模型可以应用于平台其他模块。目前可将数据模型应用于智能标签和指标管理，未来会将其扩展到离线开发和实时开发模块中，用户可建立规范化的数据模型来建立离线数仓和实时数仓。
不仅要满足当前产品的场景和需求，更要为适配未来新增的模块充分预留空间，例如调度引擎、FlinkX的插件化设计，以及其他的诸多扩展性较强的功能设计。拿调度引擎来说，目前是离线、算法、标签、指标几个应用强依赖，但未来会产生新的模块，新的任务类型，均需要依赖于周期调度能力，要预留一些扩展性。
调度引擎
随着最近1、2年，产品模块的持续增加，尤其是智能标签、指标管理、算法开发等模块的快速发展，调度打通的需求也越来越强烈，主要体现在以下几种场景：
离线开发完成SQL加工后，输出原子标签表、原子指标表，需要触发下游标签任务、指标任务运行
在「强规则」模式下，离线开发完成SQL加工后，需触发质量校验任务，检查数据准确性，检查完毕后，触发离线开发的下游任务继续运行
在「弱规则」模式下，只触发质量校验运行，同时下游任务继续运行，不受质量校验结果的影响
算法开发完成数据挖掘后，需要将结果表同步到查询数据库中
上述几种场景，都可以归结为调度的打通，即整个数栈使用统一的调度引擎（DAGScheduleX），所有周期调度任务都可以便捷的建立上下游依赖关系。
对于公有云平台或统一的SaaS平台，血缘打通、功能权限、数据权限的全局统一并不复杂，但数栈将解耦作为一项基础前提，不同客户的产品售卖组合方式不同，有些是只要单独模块，有些是多个模块，在这个前提下，元数据的互通会带来较大的挑战。
为了解决这种元数据互通的问题，数栈单独建立了「业务中心」模块，将血缘关系、功能权限以及其他必要的通用。
（1）血缘关系
传统的血缘关系都集中在离线数仓领域，但随着实时数仓、标签加工、数据API的逐渐发展与完善，对数据进行「全链路」血缘跟踪的能力就显得愈发重要。例如：实时采集模块将MySQL Binlog数据一路写入Kafka，经FlinkSQL加工后写入MySQL结果表，另一路写入Hive表做备份，经离线加工后作为原子标签表，后经标签加工后产出衍生标签、组合标签，并输出标签API接口，可能形成下面的血缘关系：
目前平台已完成离线开发与数据资产模块的血缘关系打通，离线开发每天跑批的SQL，数据资产模块可自动完成血缘解析，并直观的呈现出离线开发过程中形成的血缘关系，后续版本中会逐渐补充其他模块的血缘关系。
（2）功能权限
在进行跨模块的依赖配置时（例如离线+质量校验），用户在数据质量中需关联一个离线任务，在进行关联配置时，需按照「租户→所属产品→所属项目→任务名称」来选择，用户只能配置自己有权限的任务作为上游。
这种跨模块的元数据交互，需要每个模块将基础的权限信息保存在统一的「业务中心」，每个产品之间都通过业务中心来解决跨模块的元数据查询问题。采用统一的业务中心，为每个模块都带来了较大的改造成本，但优点是一劳永逸，未来各个模块的类似需求都无需相互之间建立集成关系，而是通过业务中心来过渡。
除了上述几个点之外，基础能力层还有以下几个方面需完善：
体验一致：运维中心
随着调度引擎的统一，同时每个模块对周期调度的功能是雷同的，抽象为统一的「运维中心」，为各个模块提供体验一致的周期实例运维能力，也已经规划在下一步的Roadmap中。除离线外，标签、指标、算法等模块均需要基本的实例状态管理、日志查看、重跑、补数据等操作，基于需求的一致性，所以需要形成统一的运维中心，实现操作体验的统一，降低重复造轮子的出现。
统一的数据同步/数据传输
数栈已经在3.0版本已经完成了离线同步和实时同步的框架统一，由FlinkX来统一承担离线和实时的同步和采集。
当前的设计模式将离线同步和实时同步分别做在了离线开发和实时开发模块中，但也有不少的客户有交叉性的需求：
某客户需要同步大量的离线数据，但也需要同步少量的实时表
某客户主要使用算法模块，但需将其他各系统的数据同步到算法底层的Hadoop存储中
某客户使用Greenplum做数据仓库，同时需要智能标签模块，需要将Greenplum数据同步到智能标签模块的Hive表中
以上几种交叉场景较好的解决方式，是将数据同步单独拆分，可以与其他模块灵活组合输出，一方面实现轻量化的部署模式，另一方面是提升用户的使用体验。
从传统的解耦模式到目前的松耦合模式，数栈始终秉承着“让数据产生价值”这一核心理念，致力为行业伙伴和终端客户提供更加优质的数据处理方案，在使用体验、灵活性、扩展性和开放性等方面进行最优化设计，助推各行各业加快数智化转型升级。
【云原生数据中台】数栈“产品家族”进阶之路 
792
0
