在不久前的《数据云场景指南》线上直播中，“数据云操作系统”正式发布：向下封装复杂性，向上提供易用性，帮助企业应对多云、多引擎、多主体、多应用等多变挑战。

然而，“数据云操作系统”和数据仓库、数据平台究竟有何异同？和我们所熟知的“操作系统”有啥关系？开发者们又如何评价数据云操作系统？

在直播的圆桌对话环节，我们邀请了数据云操作系统的2位“客户”——GrowingIO联合创始人叶玎玎、奇点云资深数据架构专家证道，共同分享数据云操作系统的真实体验。

他们说：

· 横向对比PC操作系统、超大规模通用计算操作系统、手机操作系统，数据云操作系统与它们有相似的共同特征，例如统一提供经封装的底层能力、分布式、APP生态等。

· 纵向对比历代数据技术栈演进，数据云操作系统最大的革新在于“分层”。

· 基于数据云操作系统内核，分析云一次性获得了多云、多引擎等数据及资源处理能力，并彻底告别过去的“必须推倒重构”、“应用开发因底层迭代而被迫停滞”的困境。

· 在绝大多数企业，技术元数据、业务元数据的管理是割裂的，数据云操作系统帮助企业把数据资产统一管理起来，提供数据服务，对于中大型企业提效更为明显。

本期嘉宾

· 地雷：奇点云CTO，近20年数据领域研发和产品经验，原MaxCompute大数据引擎和算法平台初代PD之一。

· 叶玎玎：GrowingIO联合创始人，国内最早一批增长黑客践行者，网易用户搜索引擎核心开发者，XRuby Core Committer。

· 证道：奇点云资深数据架构专家，18年数据行业从业经验，9年老甲方、9年老乙方，完整经历大数据技术的迭代演进。

· 何夕：奇点云资深战略咨询专家，浙江大学社会硕士生导师，本期圆桌主持人。

辨析

大数据平台也谈操作系统

是不是“新瓶装旧酒”？

地雷：从最早的数据仓库、数据平台，以及有个阶段叫“数据中台”，到现在的数据云，这些概念的演进是有延续性的。因为这些做的都是数据领域的事情，所以一定要围绕数据全生命周期展开各种主题，例如元数据、数据安全、数据治理等等会“传承”下来，也就是“旧”的部分。

那“操作系统”新在哪里？最突出的是“分层”。

在传统的逻辑下，围绕数据展开的建设是烟囱式的，例如我要做一个数据应用、报表、算法等等，满足具体业务场景的需求。而现在（操作系统）抽象出了一层中间层，解耦底层资源和上层应用，由它应对底层的复杂性和多样性，横向地给上层的各种应用提供能力。从这个层面来说，是“新”的认知。

Snowflake、Databricks等业内领先的企业也采用了同样的思想，认为（底层的资源和技术支持）就应该平台化，他们的平台和上层应用是各司其职的。

同时，这种演变其实在计算机领域已经发生过了，其他类型的操作系统也是这样演变出来的。

何夕：作为老IT和老DT，既做过甲方又做过乙方，既是数据架构师又是资深的数据开发者，证道你怎么看地雷所说的“数据云操作系统”？

证道：先从大家日常工作中会遇到的三类操作系统来看：

第一类，PC（个人电脑）的操作系统，它可能是苹果的（MacOS）、Windows的。这些操作系统需要管驱动、网络、安全、账户权限、计算资源等等。数据云操作系统同样需要履行存算资源管理、账号管理、安全等等职责。

第二类，阿里云飞天（Apsara）这样的操作系统，它是商业化的超大规模通用计算操作系统。它是分布式的，能够一次管理很大的集群，包括其底下各种各样的计算资源，解决包括双十一在内的各种商业化场景。数据云操作系统同样需要具备“可大可小”的能力，商业化地支持数据业务场景。

第三类，大家最熟悉的手机的操作系统，例如iOS、Android、华为的Harmony等等。手机操作系统的应用非常多，这些应用底层需要共享、调用手机的资源，包括摄像头这类硬件，也包括日程、通讯录这类数据。手机操作系统需要建立应用（App）生态，数据云操作系统也同样，企业会在上面构建大量应用，例如用户的、风控的、供应链的、财务管控的等等。

所以对比大家熟悉的操作系统，会发现数据云操作系统有比较多共通之处。

我们再纵向看，数据库这类产品如何演进：

第一代，关系型数据库，例如Oracle、DB2、SQLServer等。它的优势在于能够确保AICD（即原子性、隔离性、一致性、耐久性），从而保证数据的一致性和系统本身的可靠性，在OLTP场景应用广泛。

第二代，数据仓库，是在关系型数据库基础上发展起来的。相较第一代，能提供高性能的查询和分析功能，主要用于OLAP场景。

但前两代的基础设施都会遇到一个问题：当你数据量特别多的时候，无法通过扩展节点来获得线性的性能增加，例如节点数达到了之前的10倍，但性能可能只有之前的3倍。

后来就出现了分布式大数据平台，具备更好的扩展性、容错性以及性能，提供更灵活的数据模型和查询语言。现在我们说数据云操作系统就是基于分布式大数据平台建立的，但它在这上面继续做了迭代，来解决企业遇到的更多新问题，例如多云、多引擎、多硬件等等。

实践

底层架构迭代提效89%

数据云操作系统为应用开发改变了什么？

叶玎玎：过去八年的时间里，GrowingIO的产品（以增长分析，即UBA为例）底层架构确实像今天讨论的主题一样，“拥抱复杂多变”。尤其是私有化部署的客户，客户环境（例如数据库、数据质量的影响等等）具有多变性，就要求我们产品底层架构做好准备。

回到GrowingIO本身的经历，技术底座经历了四次迭代，前三次分别为了满足SaaS场景（以高并发为特征，支撑DAU上亿、日均处理事件数3000亿），服务OP场景（以稳定性要求高为特征，降低客户的运维成本及复杂度），以及更高效的查询和开发场景，分别在不同时期，采用了不同的引擎。这其中每一轮引擎的迭代，基本上都需要12~18个月，其中包括10个月左右的研发及6个月左右的测试和迁移。

这个替换的过程非常漫长，而且每次要变更，团队就不得不停下很多工作，来专攻底层迭代。

目前分析云产品的底层是第四代，切换到了SimbaOS Kernel（数据云操作系统内核），也就是内置了数据云的核心能力。而这一次升级，大约只花了2~3个月左右的时间。

这一次迭代其实并不是引擎的替换，而可以理解为把底层资源、引擎等等各种技术的复杂性都交给OS来解决。让OS封装好底层的能力，提供给上层应用，作为上层应用开发就会很简单。

这本质上解耦了平台层和应用层，一次性获得了SimbaOS Kernel多云、多引擎等数据处理能力，后续需要采用更多其他引擎时，可以由OS来完成，而不是一轮又一轮地推倒重构；另一方面应用的迭代也不会因为底层变化而被迫停滞。

何夕：我听到两个很关键的数字，过去“18个月”，现在“2个月”。

其实不止是GrowingIO分析云产品全面切换为SimbaOS Kernel底座，数据云平台DataSimba R4系列以来也升级为OS的架构。那证道从数据开发的角度来看，在客户现场的体验如何？客户的评价怎么样？

证道：如果是小的数据应用场景，其实怎么开发都行，差别不大。但对于中大型的数据团队，使用数据云操作系统来开发，效率提升是很明显的。

举一个例子，一家有多业态的大型集团公司，每个子公司和业务部门有自己的指标计算逻辑，有自己的信息系统和数据系统。因为历史原因，这些系统加起来可能多达几十套。那就会面临很严重的问题：

其一，信息系统的元数据怎么管理？信息系统和数据系统之间，表结构和模型映射关系怎么管理？以及数据系统内部的数据模型和数据任务调度怎么管理？在99.9%的企业，这三者的管理都是割裂的——信息系统管自己的元数据，字段映射规则在ETL工具里管，指标标签的任务调度在数据系统里管，也就因此无法给企业的CIO/CTO和数据团队提供全局的数据资产管理的能力。

其二，不止是前面说的技术元数据，还有业务元数据。不同子公司、不同业务线，指标、标签的口径往往是有差异的，例如财务口径的“成本”和销售部门的“成本”可能就不一样，A品牌和B品牌的“高价值”也不一样。在过去的数仓，比较难实现多样化的业务元数据管理。而数据云操作系统就做到了把技术元数据和业务元数据一体化管理。

地雷：我再补充一个数据安全的例子。过去客户的数据安全负责人很痛苦，作为“防守方”，要“防”的东西太多了——系统都是一个一个烟囱式建立的，那脱敏加密、异常发现都要一个一个系统去建，策略要逐个系统去同步，数据安全进展很慢。举个例子，身份证号要加密，在每个系统都要做加密，数据血缘的上下游只要有一个环节漏了，就可能从这个环节泄露出去，其他地方都白做了。

所以我们今年基于SimbaOS Kernel（数据云操作系统内核）对数据安全产品DataBlack做了升级，有了“平台型”的安全能力，能支持全域全场景。比如要加一个脱敏加密的算法，或对全局数据更新数据分类分级的标准，通过DataBlack就能够把策略打通到上层所有的应用中。这是今年客户侧反响特别好的场景。