前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >为什么说数据管理的下一步是DataOps

为什么说数据管理的下一步是DataOps

作者头像
深度学习与Python
发布2021-10-13 14:43:17
4720
发布2021-10-13 14:43:17
举报
文章被收录于专栏:深度学习与python

作者 | 彭锋

策划 | 褚杏娟

根据信通院数据,2019 年,我国数据产量总规模为 3.9ZB,同比增加 29.3%,占全球数据总产量(42 ZB)的 9.3%。而 IDC 中国预测,2025 年中国大数据产生量有望增长至 48.6 ZB,这已经超过了 2019 年全球数据量的水平。这对大数据行业来说,既是机遇,也是挑战。

越来越大的数据量,加上数据敏感和脆弱等的特点,数据治理一直都是一个困扰企业发展的问题。有开发者表示,每个人都在谈论数据治理,却没有人真正知道该怎么办。为此,InfoQ 采访智领云联合创始人和 CEO 彭锋博士 ,一起聊聊数据治理和大数据行业里的那些事儿。

数据治理有哪些难点

Q:在现在的企业数据治理上存在哪些痛点? 为什么会出现这些问题,以及当前情况下是怎么解决的?

A:数据治理和数据开发一直都是困扰着企业的难题。Google 最近发了一篇文章表示,虽然 Google 在 AI 算法上非常厉害,但如果大家都只想搞算法,没人想去搞数据,那算法是没有用的。比如进来个脏数据,算法一点用都没有。但搞数据的工作,大家都认为很“脏”、很费神,算法更高大上。

数据的治理和数据质量非常重要,整个数据开发流程也非常重要。算法是最后让数据产生价值的很重要的一部分,但是如果没有前面的准备工作,那么数据质量和数据开发效率就无法保证,后面算法也发挥不了作用。很多公司,包括 Google、Twitter 和 Facebook,他们的算法之所以有那么大的作用,就是因为他们数据的基础架构做得好,所以他们才能保证算法的有效性。

那么这个难度在哪呢?现在,数据管理、治理工具和数据治理体系暂时还没有一个成形的体系,所有公司的数据质量、数据开发工具基本都是拿开源组件自己临时搭建。

整个数据的测试流程中,大家很少听说数据有 CI/CD,数据有没有 CI/CD?数据的 ETL 程序有没有 CI/CD?数据开发完了在哪测试?能不能在生产数据上测试呢?如果程序是对的,那数据改变后我的程序语义还能够保证它的正确性吗?企业在实际生产时,这些问题都是在大规模使用数据时会经常碰到。由于数据的使用,大家觉得大数据好像搞了很多年,但其实到现在大数据的基础才逐渐成熟,大家也才意识到,数据组织后的数据质量是更重要的。

所以,我觉得现在正是将数据质量、数据治理和整个数据开发体系的工具提到前台的好时机。以前数据基础还没有成熟,提这个可能有点早,但现在越来越多的企业,特别是头部企业发现了这个问题。

硅谷的很多公司,包括在国内的头部公司,他们早就遇到了这些问题,他们自己内部肯定是有解决方案的。产品化的事情也有人在做,大家现在看到的开源工具里像 Spark、Kafka 都很成熟,做得都很好。但是,像 DataOps 这种跟企业的底层数据情况和数据的基础架构紧密相关的工具比较少,DataOps 工具刚刚出现,现在也才获得大家的关注。

什么是 DataOps

Q:现在越来越多的技术和厂商都在产品中会提到 DataOps,但是可能目前大家对 DataOps 定义还没有很统一的定义。那么,到底什么是 DataOps?为什么它现在会被很多企业青睐?

A:DataOps 是从 DevOps 借鉴的一个理念。可以理解为 DataOps 是把 DevOps 的一些理念映射到了数据开发上,它们的很多观点是可以一一对应的,如开发及运维、云原生、微服务化、CI/CD,这些都可以在 DataOps 里找到,如果你的 DevOps 里没有这些概念,就要考虑下你的开发流程是不是符合最佳实践。但 DataOps 与 DevOps 也有区别。DataOps 是想处理数据,而在 DevOps 里是不需要处理数据的,它主要是做应用的开发,应用的 CI/CD、发布及运维。但就像刚才说的,DataOps 实际上属于一个比较早期的概念,大家对它的解读还是会有不一样。

在 DataOps 里面有很重要的一点,就是要处理数据的各种不可预知性。数据语义是一个难题,它没办法在 CI/CD 里被容易定义,不是没有办法,但很困难。之前大部分原生大数据组件开发时并没有考虑到这个规范。

DevOps 也经过了很长一段时间的演变,像 Git 逐渐成为规范,微服务基本上都是标准的组件。大数据组件体系架构特别多、选择特别多,发展也特别快,现在的 Spark、流数据,Flink,卡夫卡,底层基本上也是 K8S、Hadoop 和 Hdefs,这些基本上可以形成标准化。那么,现在就是做 DataOps 一个比较好的时候。

DataOps 的工作主要有五个方向。

第一个是任务调度。主要包括云原生调度、容器的调度,这跟 DevOps 是一样的。第二个是数据安全。数据安全以前基本不在 DataOps 的考虑范围,也不在数据开发的范围内,但现在数据安全很重要。第三个就是数据管理和数据门户。大家可能会说原数据管理不都好多年了,但以前的原数据管理主要是针对关系型数据库,关系型数据库对原数据的管理相对容易,只要到数据库里把原数据爬出来就可以。但现在有流数据、非结构化数据,还有 TaiDB 等,各种各样的原数据怎么样去管理?血缘管理更复杂了。之前是几个 SQL 之间的血缘管理,现在关系到各种各样的查询、各种各样的系统、数据门户跟 MapDatas 是一样的。第四是数据检测的可视化。DevOps 里有很多可监测到的指标,数据层面也一样。用多少资源、花多少时间、创造了多少价值,之前都是一个黑盒子,但 DataOps 的整个数据都是端到端的,相关指标可观测、可管理。第五就是集成开发。所有的工具必须是可集成的,不可能做一个工具负责血缘管理,再做一个工具负责调度。

我认为,DataOPS 里面必须具备这五个工具体系,如果你的 DataOps 体系里面缺了任何一个,我都觉得是不完善的。

Q:DataOps 如何做持续测试?

A:数据开发、数据程序的测试一直是老大难问题,甚至头部大厂整套流程做下来也是现在非常困难的。现在 DevOps 里有一个很有意思的观念,就是把集训资源的管理全部用 Code 来管理,大数据也一样。美国有一个很火的公司叫 DTB,它是要把所有的 ETL(数据仓储技术)流程做成代码管理,将 SQL 的所有转换变量化、代码化,将所有 ETL 程序间的关系、血缘全部用代码的形式来进行管理。可以说,不只 SQL 是代码,整个调度也都是代码。所以,DBT 的整个 ETL 程序可以被放到 Git 里面。用户可以在指定的 data source 的测试环境中可以测试,可以到 Data 生态环境中直接切换一个 Data source,将其变成生产环境,所以它允许支撑 ETL 流程的 CI/CD。将所有 ETL 程序之间的依赖全部代码化,这就是 DTB 的一个思路。

除了 ETL 之外,我们现在做的事就是把所有大数据组件里面的关系、程序全部代码化,这是未来的必然趋势。

DataOps 与云原生数据中台的关系

Q:DataOps 与云原生数据中台是什么样的关系?他们目前各自的发展情况如何?

A:国内数据中台也提了两三年了,有成功的案例也有失败的。我们在这方面也做了很多探索。我们的观点是,数据中台绝对要做,但 DataOps 是实现数据中台的一个最好的方法论和工具体系。

这跟 DevOps 是一样的。一个业务系统可以使用 DevOps 方法来做,也可以使用传统方法去做,两种方法最后做成的业务系统可能都差不多,但这只是开始的时候差不多,后面的持续迭代、持续运维的时候,就能看出来 DevOOps 的优势了。数据中台也是一样,它是给大家提供一个数据开发和运营的底座,开始你可以用各种各样的方法去做一个数据平台,但是后续迭代和不断发展的时候,DataOps 就成为最合适的一种方法。DevOps 提倡的是赋能和自助,通过 CI/CD 持续发布,开发工程师自己来做运维测试,DataOps 也一样,也是提供工具让各个业务部门等数据使用者,能够在中台上拿到自己需要的功能。我们认为这是 DataOps 和数据中台的关系。

Q:企业如何去做云原生数据平台的改造?整个过程可能会面临哪些问题?

A:我觉得,现在云原生的数据中台还是一个比较有挑战性的课题,但也是个必然的趋势。很多企业的数据平台效率非常低,因为传统大数据平台使用的 Hadoop、卡夫卡等都不是在云原生的方式下开发,资源使用效率低、管理复杂,但云原生会大大降低整个系统的管理复杂度,提高系统的使用效率和运营效率。

这个过程中会面临的困难,主要是人才问题。这个技能的门槛比较高,需要研发既懂云原生又懂新技术,这样的人才缺口还是挺大的。但这也有个好处就是,云原生产品的标准化程度比较高,这样容易做出标准化的产品让大家使用。举个例子,以前装一个大数据平台需要直接面对底下的物理及虚拟机,但各种各样的配置,不同的操作系统、环境和网络,所有这些都得去管理。K8S 的出现就让大家不必再考虑所有的底层组件,只要跟云原生这个体系对接就可以了。这是一个很好的机会,所有的企业一定会看到,但这个过程肯定是需要时间的。

Q:您之前多次提到过“数据中台方法论”,这个方法论具体都包含哪些内容?

A:这个方法论的主要目的就是追求效率。我们国内很多客户的大数据平台的资源使用率大概都是 15%-20%,但 Twitter 的自然使用率一般能达到 50%-60%,而且还有各种各样的弹性扩展、自动容错等云原生功能。

了解这个之后,需要做到以下四点:

第一,选择合适的工具和平台。这个是基础,选不到合适的架构工具,也就不存在效率了,所以如何选择合适的平台工具很重要。

第二,要有一个完善的顶层架构设计。因为数据平台要把大家的数据接进来,与业务系统对接起来才能产生效果。DevOps 分布式的开发,集中式的管理,但这个集中式管理不是靠人,而是靠体系和工具。

第三,业务驱动。为了大数据而大数据一般成功不了,一定是可以解决业务问题的才能走到最后,解决不了业务问题的数据平台是伪命题。解决业务痛点之后,还要赋能业务。要把业务部门引入进来,不断使用这个数据平台,获得业务部门认可后这个东西才能走。

第四,要有价值衡量体系。如何量化产生的价值,很困难但是也很重要。我们一般要求决策方、业务方,技术方和数据平台等各方面职责明确,避免后面出现越来越多的问题。

DataOps 应用

Q:2018 年,高德纳把 DataOps 纳入了技术管理成熟体系曲线里面,DataOps 被正式接纳和推广。三年过去了,目前有什么成熟的应用案例出来吗?

A:DataOps 在云原生出来之前就有,但可能没有叫这个名字。头条、腾讯等大厂们都有自己的一套 DataOps 体系,Twitter 等硅谷公司也有,那为什么现在才提出来?因为这个东西要产品化。虽然大厂都有 DataOps 体系,但是将近一百人的数据团队,eBay 大概有三百多人,一般企业很难请得起这么多高薪的人才。

现在 DataOps 火了是因为大家都需要,数据价值不是大厂独有的。但横梗在前的成本问题怎么解决?这就需要 DataOps 工具将数据价值开发平移化。为什么称为云原生的 DataOps?因为只有云原生技术统一了各种各样的硬件环境、开发环境、发布环境、运维流程等等之后,DataOps 才可以将聚焦在数据开发、数据监控、数据管理、原数据和数据安全上。

Q:您在 Twitter 的时候,一个主要职责就是让公司所有的人避免重复开发数据组件。这个需求是在一个什么样的背景下产生的?

A:这个就是很重要的不要重复造轮子的问题。重新造轮子会造成资源消耗,然后减慢开发速度。要避免不重新造轮子,那么就必须知道现在有什么“轮子”,但很多企业并不知道自己有什么“轮子”。DataOps 很重要的一点就是原数据管理,它的原数据管理比原来的要更广泛,它可以知道整个企业有什么样的数据功能。

更重要的是,企业重新造轮子,一旦两个轮子造得不一样,会把这个车开垮。我们原来做数据门户,就要求所有的业务部门和数据分析师必须做统一的接口,然后发现有两个部门就在重复造轮

Q:DataOps 会有开源生态吗?

A:目前是逐渐成熟的过程中,还没有成熟到大家都可以使用的端到端产品。

我们之前公众号有篇文章讲到,硅谷的大概十几家公司,每个公司都有自己的数据门户和产品,但是没有成熟的产品。今年 6 月份左右,Linking 将自己的数据门户产品开源了,也有人在做血缘管理,但都是这两年才起来的公司。这个生态在逐渐形成,但是远远没有到达成熟的阶段。

Q:现在,DataOps 还解决不了哪些问题?

A:我觉得,当前 DataOps 没办法解决业务价值的挖掘问题。DataOps 实际是降低了数据使用门槛,让更多的业务人员可以直接开发他们需要的数据并将这个开发成果给大家使用,这在以前必须要依赖数据科学家或者数据工程师。但是,如何把这些数据与业务结合起来、用数据去促进业务,这不是 DataOps 能回答的问题。我们只是赋能,但是真正怎么样让你的数据去促进企业的业务发展,那一定需要企业懂自己的业务。

数据行业人才缺乏

Q:企业在使用 DataOps 的时候,应该如何组建这样的一个团队呢?

A:DataOps 工具并不是要取代数据工程师、数据科学家,或者 DBA 和数据分析师,它让他们更有效率,我知道在座的不知道有多少是这个数据科学家,或者是数据工程师。

除了 DBA,数据行业一般有三个比较重要的角色:数据工程师,负责搭建数据平台;数据科学家,研究数据的潜在价值,用学习模型来形成用户画像、产品推荐或自动异常检测等;数据分析师,更多从业务角度做数据分析。但是最近出现了一种职业叫机器学习工程师,他们的任务是提高算法效率,把数据科学家们开发的模型以生态化的形式,更高效地完成。

Q:这些人对 DataOps 是什么态度呢?

A:他们当然欢迎。以前数据科学家和数据分析师发布任务时要依靠数据工程师帮他们写 ETL 任务,现在 DataOps 可以帮助他们自动完成。我们就是让大家可以睡个好觉,让每个人的聪明才智可以发挥在他最能发挥的地方,而不是整天吐槽后台、吐槽系统。

Q:数据管理这一类的岗位,人才供给情况怎样?

A:现在很缺,非常缺。这个行业需求本来就比较大,加上要做数字化转型,同时门槛比较高,进入这个行业基本不愁找不到工作。同时这个行业里,经验非常重要,越有经验越吃香。中国美国都一样,所有想做数据项目的第一个问题就是找不到人。

数据安全还是要靠规范

Q:中国和美国的大数据市场有哪些不同?

A:我觉得现在的差别已经不大了。现在国内的新型企业很追求效率的追求,对先进的方法论也很认可,这个跟美国的公司基本上没有太多区别。虽然我也没有太多接触过美国的传统企业,但是美国传统企业接触这种理念其实也都比较缓慢。但国内新兴的企业、企业家们,都很认可数据价值,认可云原生理念,也认可专业的企业服务。

要说区别的话,主要还是体现在两边的商务模式上。在美国,数据工程师、数据科学家有很大的采购权,几万美元、十几万美元产品都是实际做事的人来采购。但在中国,采购的决定权是从上往下的。这也是为什么美国的开源比中国的更赚钱,开源打的就是中间这层真正使用的人,他们可以直接报告说需要这个开源公司来提供服务,上面一批就完了。但中国企业要申请个几十万的项目,就得从上往下批。

Q:国内市场发生了哪些变化?

A:以前大家做大数据好像是因为这个是一个风口,现在没人是为了大数据而大数据,大家都认可了大数据真的能够产生价值,没有人会怀疑大数据的价值。但是大家对大数据怎么落地还不是很清楚。所以,我觉得如何做出更好的工具降低门槛,更快地产生数据价值是现在企业面临的一个挑战。

这几年,因为大家对云原生技术的认可、对开源体系的拥抱,国内的技术生态比以前更加有活力。大家尤其认识到了开源对整个行业的推动作用,很多开源公司也取得了很好的成绩。我们虽然现在没有产品开源,但我们也有开源计划,希望能够为整个技术发展做一些贡献。

Q:去年的大数据蓝皮书也显示了一个数据,中国的数字经济指数在 G20 国家中排名第一,但安全指数排到了 14。据您的观察,目前国内在数据安全治理方面存在哪些问题?

A:数据安全费钱,不产生直接价值,一般企业都不愿意做这个事。比如要把几千台机器里面所有关系到用户私有信息的数据集全部找出来,这件事产生不了任何积极价值,但它是非常重要的。Twitter 上市的时候,我负责做数据合规时,整个团队花半年多的时间做数据治理,投入相当大。

这就一定需要用规范来要求企业数据必须合规,这也是行业发展到一定阶段需要处理的事情。数据不规范可能无法出国做生意,老百姓也就没有安全感。对 DataOps 来说,企业可以直接把合规的规则实现在 DataOps 体系里,让数据质量等工具帮助企业完成一些合规检查。但合规是与行业紧密相关的,比如银行的数据要合规,那么就会有专业团队把银监会合规的标准转换成 ETL 查询工具,再转成合规报告。所以,合规会纳入到 DataOps 这个体系里面来,但是需要专业的团队来做。

Q:最近发布的《数据安全法》对大数据企业有什么影响?企业如何加固数据安全?

A:我觉得是好事。所有的企业必须要注重自己的数据合规和数据使用方式。这对大数据企业来说是好事。

传统方式做数据合规管理比较困难。我们观察到,很多企业使用的 Hadoop 是不安全的,因为一旦用了安全的 Hadoop,还得用安全的卡夫卡、安全的 Spark 等,所有的组件都要是安全化的,那么管理的复杂度要高很多。企业在建设之前,就应该把数据安全、数据合规问题考虑进去,后面补课是比较困难的。

Q:大数据行业现在面临着哪些挑战?未来的发展形势如何?

A:大数据还是需要规范,需要一把手的认可和支持。现在很多企业的一把手知道数据的价值,但是不知道该招什么样的人,该怎么样去推进数据项目的落地,使其真正产生价值。国内现在对数据平台价值的衡量还是一个黑盒子,一个大数据平台到底产生了多少价值没有办法衡量。所以一把手的思路和对整个数据架构的规范体系建设,决定了很多大数据平台的发展。

未来是 AI 的世界,AI 的底层就是数据。不管是个人成长还是公司的成长、企业的成长,基本上都是数据驱动,数据驱动让生活更高效、生产更高效,放大个人价值。这是一个很值得投入的行业。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-10-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 InfoQ 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档