在不久前的《数据云场景指南》线上直播中,“数据云操作系统”正式发布:向下封装复杂性,向上提供易用性,帮助企业应对多云、多引擎、多主体、多应用等多变挑战。
然而,“数据云操作系统”和数据仓库、数据平台究竟有何异同?和我们所熟知的“操作系统”有啥关系?开发者们又如何评价数据云操作系统?
在直播的圆桌对话环节,我们邀请了数据云操作系统的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就能够把策略打通到上层所有的应用中。这是今年客户侧反响特别好的场景。
评论