一、数据平台与云原生的架构关系
1. 云原生诞生场景
云计算兴起之后，以 Docker 为代表的容器浪潮，席卷业界，以 DevOps 和标准化交付而广受青睐。在此背景下，Google 创造性地提出了云原生的概念，并发布了开源编排工具 Kubernetes，从统一部署和标准化的角度切入，其后更成立了 CNCF 基金会。今天我们已经看到云原生数据库、云原生大数据、云原生容器、云原生中间件、云原生安全等等概念，这都是在云上可以随意获取的服务化云原生产品，是传统线下没有的服务，有助于获得性能和成本上的加强，这就是云原生。
使用云原生可以屏蔽底层各类软硬件的差异性、地域的隔离型，提供了强大的弹性扩容，运维，监控等功能。
注：图片来自infoq的主题分享
2.数据平台为什么要长在云上
数据平台可以作为上层服务独立存在。但是随着业界数据的快速膨胀，大数据处理能力已经逐渐变成了一种基础平台能力，并且由于数据平台底层依赖大量的云原生大数据组件，例如 spark，flink，kafka，hbase 等，单个组件作为服务都不能提供解决方案。数据平台可以完全整合这些组件，将数据平台作为云原生服务的一种，则可以更加便捷、快速的部署以提供通用大数据解决方案。
3.云上的数据平台该如何摆放自己位置
3.1 OpenShift的思考
Openshift 的产品架构，是在 k8s 核心模块之上，划分出 4 大服务平台：
（1）平台服务：提供了服务治理基本能力，例如：service mesh 为创建部署的服务提供发现、负载均衡、服务对服务身份验证、故障恢复、指标和监控的服务网络给予了便捷的方法。服务网格还提供更复杂的操作功能，其中包括 A/B 测试、canary 发行版本、速率限制、访问控制以及端到端验证。通过构建 CI/CD 的 pipeline 实现从代码编译、创建镜像、部署服务等完整流程。同时提供了日志管理，资源管理等相关运维层面的能力。
（2）应用服务：主要提供了构建云原生服务应用的能力和不同编程语言和运行环境的能力，用于将应用部署为云原生服务。
（3）数据服务：提供了数据存储、集成、准备、分析、AI 应用的单体基础能力。
（4）开发者服务：提供了开发者使用能力，例如提供 jupyter、客户端、合理的插件拓展，可以让用户直接使用平台提供的工具进行产品的开发。
3.2挑战与机遇
在 Erda 的实践中，也尝试过这种最简架构，但是在平台功能丰富之后遇到了一些挑战和困难：
（1）数据平台直接对接 k8s 服务，平台开发者既需关心平台功能开发、还需掌握k8s底层接口内容，对团队成员的技能要求非常高，团队扩容遇到阻碍。
（2）数据平台需要支持的计算任务内容复杂、多变，比如：有普通的 k8s job 类型任务，也需要有基于云原生的 flink，spark 等计算任务，对底层的调度模型有多种调度需求，增加了快速拓展调度方式难度。
（3）上层包含多平台对接底层 k8s 核心服务，比如：CI/CD 流程、权限、网管、监控等公用模块需要在各个平台中单独开发及适配，重复造车形成资源浪费。
为了解决这些问题，Erda 在 k8s 核心服务之上，开发了独立的异构调度层，统一的对接 k8s 的原生能力，对上层提供格式一致的入口；在调度器的上层再开发独立组件，开发统一的 CI/CD 组件，对上层提供统一的流水线构建逻辑；使数据平台开发者能够专注在数据功能平台的开发，对 k8s 的服务调用采取统一封装的组件。
二、云原生架构下，数据平台边界在何处？
1.对数据平台的期许
云原生数据平台依托核心的 k8s 底座，那数据平台到底该提供什么样的能力？
在 OpenShift 中，我们看到的思想是，提供丰富全面的数据节点：
集成层提供多种存储 DB 的接入节点
存储层依托核心的 ceph 等存储器
计算层封装开源计算 action
服务层可以对接主流的查询引擎
数据平台在其中仅提供封装的 action，支持一个一个的独立功能块，在功能块之上，第三方 isv 服务商可以利用这些能力做二次开发，以提供对外数据平台的服务。
Erda 的解决方案是：
数据平台应该是包含数据集成、数据开发、数据治理、数据湖等全流程的综合性平台。可以“一揽子”的满足数据获取、数据计算、数据管理的需求。
我们也有类似数据 action 的思想，但用户无需关心具体的 addon 镜像，只需专注业务过程，所有 action 的调度都在后台自动转化运行。
底层存储：缓存层和存储层，缓存层屏蔽了底层具体组件，可以横向拓展文件存储，列式存储，关系型存储。
数据集成：可插件化拓展支持的集成源结构，实现即可拓展又与平台功能深度融合。
元数据中心：在开源组件的基础之上，实现元数据的同步、查询、管理。
任务调度：依托底层统一的调度器，支持调度到不同的计算引擎，不同的集群环境，能够实现流批一体的调度。
数据开发：包含支持实时/离线任务的开发的平台，用户仅需关心业务逻辑，无需关心任务的打包、调度和执行，在页面即可实现全程监控。
数据治理：实现对平台数据质量、数据资产、数据地图的汇总展示。
数据应用：基于数据平台的产出结果对接各种上层应用。
2.数据如何来
数据集成，是数据平台的基础。一切后续流程的开展都需要将数据先纳入平台中。
在 OpenShift 的方案中，集成主要是利用平台的 ceph 组件，从外部将数据导入，集成的实现重点都放在了数据的存储上，解决的都是用户如何将数据存下来的问题。
我们不禁产生了思考：
数据集成仅仅这么简单？
数据进入平台后如何保证数据安全？
如果切换增量全量抽取数据，将如何管理？
如何实现离线/实时同时支持？
Erda 在结合服务客户的过程，总结研究出的集成组件架构如下：
数据集成应该包含：异构数据源的管理、异构数据同步、数据安全保证、增量/全量、实时/离线多维度的管控、良好的可拓展性、可插件化支持数据源增加等。
3.数据如何动
OpenShift 中，对数据的分析流程是如此定义的：数据串行从 kafka 到数据湖，从计算算子到分析库，从分析库到数据分析引擎，完成一个数据分析目标。
实际数据开发过程中，为了模型复用，任务关系可能更加复杂多变、相互依赖又分层构建。
在数据流动的过程中，重点要解决复杂的依赖关系，尤其是其中某些节点出现失败、异常的时候，能够快速定位影响范围，找出上下游所有的节点进行补救措施。
4.数据如何管
数据除了开发、调度，还涉及数据应该如何管理。
在 OpenShift 的设计中未曾考虑过这个问题。
数据平台存有几千/几万个模型时，如果没有管理，平台将会混乱无序，想要快速定位模型，理清楚平台的数据资产将是非常困难的事情。
在 Erda 的实践中，开发了独立的元数据管理组件，可在图数据库的基础上提供数据同步、元数据管理、结构转换等核心功能，方便全平台的资产、血缘统一管理
5.数据如何用
数据结果汇总之后，将可以利用 k8s 的网关核心能力，配置服务调用规则，动态生成数据调用接口。通过界面操作即可完成数据的对外服务和管理。
结语
从阿拉伯数字诞生开始，数字作为现实世界的量化介质而存在，流淌在软件构建的虚拟世界里。在软件构建的虚拟世界里面，数据有了现实的业务含义，且更快速、更真实、更有效的反映现实世界的进程，通过数据这个介质，业务人员可以从一线现场中解放出来，极大地节省了获取信息的成本。同时，数据凭借着其大量、多样、高效、获取成本低的特征能够更容易的挖掘业务进程的过去、现在和未来。
所以数据能够提供给业务的价值包括：
更好的挖掘过去：当前，Erda 已经在零售行业、新锐品牌、地产等行业有了大量的事件案例，构建了一套能够服务企业多阶段多目标的指标库，且贯穿从底层数据模型处理规则、指标展现样式、问题探寻路径、业务策略指导全流程。
更好的反映现在：数据对于现在的意义在于更快的响应。现在 Erda 的数据平台已经有了一套支持实时反馈的计算框架，支撑实时业务场景。
更好的指导未来：得益于 Erda 的产品技术优势和广阔的客户覆盖面，现在Erda 也拥有多元化的算法场景，更好的帮企业更清晰的看到未来的人货场结构，更明晰进销存的相互的反馈，帮助企业构建稳定的柔性供应链予以支撑。
Erda 想要做的正是给这些不断进化的功能优化以最易于扩展的空间，为企业降本增效，一切为了更好的用户体验！
欢迎从我们的官网 erda.cloud 了解更多关于 Erda Cloud 产品的最新资讯。也欢迎关注我们的 Github repo，我们的代码已经全部开源，点击【阅读原文】即可参与，期待你的 star ~~~
END
想象中运行代码VS实际中运行代码
关注视频号“OSC开源社区”