一文读懂数据云的「对象体系」

确切地说，有 6 个域、32 个对象

啥是「对象」？

在计算机科学的定义中

对象（Object）是面向对象编程的基本单位

是一种将数据和操作封装在一起的实体

它具有「属性」和「行为」

可以与其他对象进行交互和通信

对象最突出的特征

莫过于「封装」、「继承」、「多态」

有点抽象，举个栗子↓

类比到现实世界，一只电子狗可以是一个对象

它有品牌、颜色等属性

同时，也可以执行发出声音、奔跑等行为

那啥是「封装」？

对象把数据和操作封装在一起，形成独立实体

只对外界暴露所需的接口

比如，你只需要知道如何与电子狗交互

和它玩接飞盘的游戏

而不需要了解它内部的机械构造

啥是「继承」？

电子宠物可以被视为父类

上文我们说的电子狗，则是子类

如果再多个子类——电子猫咪，也没问题！

父类可以定义共享的属性和行为

例如颜色（属性）、发出声音（行为）

子类可以继承父类，并添加自己特定的属性和行为

例如，电子狗可以添加犬种（属性）

电子猫也可以添加躺下（行为）

并继承父类的「颜色」、「发出声音」

通过「继承」，子类可以复用父类的代码扩展或修改行为

通过「多态」，则能使用相同的方法处理不同类型的对象

从而简化代码、提高灵活性

例如，我创建了一个电子宠物的引用变量

它分别指向电子狗和电子猫

只要调用相同的方法「发出声音」

当引用指向电子狗时，它会汪汪

指向电子猫咪时，它会喵喵

看到这儿，你可能想说

道理我都懂

「面向对象编程」早在学校里学过了！

Unix 的「一切皆文件」

就是计算机史上最伟大的对象抽象（之一）

无论是读取、写入还是执行操作

都采用统一调用的指令

像访问文件一样简单、易于管理

这种设计哲学影响了一代又一代的操作系统

时至今日

精妙的抽象设计、简洁的接口操作

仍是程序优雅易用、用户友好的代名词

那「对象」和数据云究竟有什么关系？

众所周知，大数据体系非常复杂

向下看

数据源不仅涉及多个部门，还需要跨云

分析需求不仅需要批处理

还要劳烦流计算和图引擎通力协作

向上看

日新月异的业务在不断提出数据应用需求

每当搭建一个应用

就要从头开始搞定存算、数据源适配、权限体系等问题

各自建设，各成体系

不仅浪费时间重复投入

无意之间还产生了新的「数据应用烟囱」

每当这个时候

我就不由自主地怀念起

那个具有「封装」、「继承」、「多态」特性的「对象」

和采用对象体系设计的「操作系统」

没错！

奇点云数据云操作系统的核心设计思路

就采用了「对象体系」

Simba OS（数据云操作系统内核）

根据「资源抽象、接口统一」原则

把一系列复杂的数据业务对象

抽象为 6 个域、32 个对象

管你是多引擎、多依赖、多云

还是海量多源异构数据

统统在向下封装后

以标准简洁的 API，向上提供能力

从而简化数据模型与应用的研发

提升系统程序的可维护性、可复用性、可扩展性

举个栗子

「资产检索」调用了元数据域的「搜索」（Search）对象

大家常用的「分级多域」、「多租户」

则离不开空间域中的「工作空间」（Workspace）、「项目」（Project）等

3 个对象的巧妙配合

又如，数据安全引擎 DataBlack、指标工厂 SimbaMetric

都基于 Simba OS 完成开发

都能继承这 6 个域、32 个对象的属性和行为

也就是说

上层应用不需要逐一支持数据源

Simba OS 已经「支持 50 多种数据源」

上层应用不需要操心权限体系和身份验证

Simba OS 已经设置完毕

问题又来了

这个早在学校学过的编程范式有啥稀奇的？

你凭啥说这 6 个域 32 个对象就够了？

事实上，对象体系的设计挑战在于

对象的设计应符合需求，详尽、准确、极简

应构建合适的类层次和继承关系

避免层次结构的过度复杂或混乱

还要处理好对象之间的关系和依赖

管理好对象间的通信和信息传递

当然，也不能忘了性能优化和资源管理问题

基于对数据全链路各环节的理解

以及过去多年实践的数百个项目

我们方才抽象出了这 6 个域共 32 个对象

它们各自集成了强大的能力

又以标准、简洁的 API 向外提供

伴随最佳实践的不断发生

未来，可能还会抽象总结出新的对象

来满足数据领域涌现且具备共性的新需求

与此同时，我们保证现有对象均向前兼容

基于现有对象开发的数据应用

无需因平台的升级而做任何调整

以上，就是本 DataSimba 的「对象」

我们的终极目标是

开发者在数据云操作系统上

心无旁骛、优雅地开发数据应用 &模型