最近,随着健康码的流行,大数据又重回大众的视野。作为新基建产业的原油,数据逐步迈向信息产业的核心。不过随着数据量级的不断扩大,从数据仓库到数据湖再到仓湖一体,如何将各种大数据技术栈整合在一起,发挥出大数据技术的最大价值成为业界都在关注的问题。
权威的咨询机构IDC对于大数据的定义是现有技术难以处理的数据。从历史来看,在谷歌提出大数据三驾马车的论文时,当时的关系型数据库技术的确难以处理大规模的数据。传统SQL在谷歌海量的查询记录面前,根本跑不出结果。
当前,科技企业要处理的数据量还在迅速增长,以笔者所在的银行为例,创新性的产品令银行要存储越来越多的数据,以开放银行和数字货币最为典型。比如开放银行产品推出之前,无论是柜台、ATM、网上银行还是手机银行,银行的交易都是由自身完全可控的设备或APP发起的,而开放银行产品无处不在、无时不在,要求银行必须要记录客户的行为数据,这也就使银行要处理更多更庞大的数据。同样的情况也出现在数字货币上,我国的央行数字货币(DCEP)一个最重要的属性就是离线钱包,这也就意味着DCEP必然要记录之前不会体现在银行账面上的现金交易信息,这也会将金融交易的数据量级再上台阶。
在诸多行业业务上云如火如荼的大背景下,从工业互联网及IoT的角度看,数据的量级不断创新高,从我了解到的情况,各大厂的数据量级正在以年化80%左右的速度增长,因此可以说大数据技依旧术方兴未艾,未来还有广阔的发展空间。
在梳理数据存储模型演进的历史后,明显可以发现,这是一个随着数据量级不断扩大,数据模型不断将传统特性退化掉的过程,在这个演化当中存储的效率不断提升。
从最早关系型数据库的视角看,数据库是工厂的车间,数据是原材料。车间为了进行原材料加工,有大量的操作设备,原材料随时会被重塑修改,不适合进行大量材料的储存场所。
关系型数据库在大量数据存储方面的短板直接催生了Hadoop等大数据技术的革命,从大数据的视角看,大数据自身就是储存仓库,而数据已经是加工完成的成品,没有被重塑修改回滚的需求。比如HDFS的实现中所有数据只能写入一次,无法修改,这其实是退化掉数据的特性,以换取海量数据的储存与查询性能。
而随着大数据应用的进一步拓展,业界发现价值密度更低的非结构化数据也有储存及挖掘的必要。比如客服的对话可能是语音、文字甚至是图像、视频,这都不是传统意义上数据库、数仓可以处理的结构化数据,因此用于储存非结构化的数据湖出现了,在数据湖中数据标准化、结构化的特性也退化了。
第一座大山是处理时效:在了解数据存储模型的演进过程后,我们可以看出关系型数据库、数据仓库与数据湖的底层构建模型并不相同,彼此兼容性不佳。这首先就会催生出数据处理的时效性问题,对于处理时效的要求可能是大数据工程师与产品经理之间永远无法达到的协议。
以笔者所在的银行为例,分析数据在交易核心数据库中跑批处理,再ODS抽取ETL分析到数仓,再进一步训练流式计算,最后再入湖,其时效最快也是T+1日,而且Hadoop和数据湖的开源生态中很多组件并不兼容,日常运维已捉襟见肘,想提速也无从下手,但业务对了转瞬即逝的营销机会又如此渴求,T+1分钟可能都会嫌慢。
如果还回答不出更细节、隐含的问题,比如非线性问题,还要把数据复制到SAS中做机器学习,再做统计的指标体系,去做进一步挖掘。数据要在这里搬动三次,复制三份冗余,还要管理数据一致性,每天数据中心运维的大量工作在做数据搬家。
第二座大山是数据治理: 现在,数据中心也开始要做一个融合性的计算框架。比如,现在AI要做online训练,淘宝推荐引擎,滴滴打车的路径动态规划都在做即时数据,这都需要很高的数据治理水平进行支撑。
数据治理作为摆在大数据工程师面前的一大痛点,去年初微盟发生了举世瞩目的删库事件,可以看到从2月23日删库中断事件,到3月1日的数据全面找回,再到3月3日的数据恢复整个事件持续了一周多的时间。
对微盟这样体量的电商来说,损失无疑是巨大的,股市市值的蒸发是一方面,更重要的是科技公司从本质上是经营数据的公司,而数据丢失事件与银行金库被盗事件从某种程度来说是同样性质的事件,都会对当事公司的声誉造成极大的影响。造成这个问题的本质还是由于数据治理水平,只有将数据按照重要性把数据分类,并分别制订治理策略,才能在真正有用的数据丢失时找到最切实可行的应对办法,眉毛胡子一把抓难以真正降本提效。
按照笔者的观察,目前从治理角度,可以将数据分为以下三种类型:
从数据治理角度上讲,上述数据的备份需求是不同的,如果混到一起,那快速恢复业务根本无从谈起。而从数据使用的角度上讲,随着海量的行为及日志类数据的出现,数据的价值必然要从数据治理的角度去要价值。
针对行为及日志等重要性等级不高的数据,一般采用异地磁带备份的方式,使用温备乃至冷备的试进行,不过从目前情况看不少企业尤其是创业型企业,都没有百年老店的观念,在初创时期对于这方面考虑和规划还不够,规划没做好,将来必然会对企业发展有负面影响。
这又就引出第三座大山 - 灾备规划:但也经常被公司管理人员所忽略,大多数初创公司不会提前规划灾备体系,公司上规模之后再进行灾备建设又是mission impossible。一般来说两地三中心中的生产与同城中心是双活的可以快速接管业务,异地中心数据延迟同步,以应对一些删库删表类的误操作。正如刚刚所说Hadoop与数据湖两套体系中的开源组件兼容性很差,能让两者协同工作已属不易,再补充建设灾备节点难上加难。
一般来说目前比较流行的灾备体系是两地三中心的架构,也就是至少在两个地域建设三个数据中心,其中:
总结灾备体系的最佳实践就是两地三中心;同城保证业务连续性,优先负责用户体验;异地保证数据连续性,确保企业生存底线。上云后的灾备规划也一定要纳入设计范围,一旦没有提前的规划,后续的补齐填坑的工作非常麻烦。
从上面三座大山可以看出,大数据最终用户的最佳选择就是在云平台上找到大数据的一栈式解决方案,屏蔽底层组件的差别,才能提高效率,低成本运维,因此可以说与云计算无缝对接的云原生技术肯定会是未来的方向。
而华为云云原生大数据以其容器化集成及全栈大数据云平台的两大特性,很好解决了大数据技术在实际落地中的特点,我们用“大数据的操作系统”来定义华为云的云原生大数据会更加直观贴切:
容器化集成:基于Mesos的资源管理,支持Marathon和Kubernetes的容器编排框架,采用云原生架构的数据平台。底层是对容器化的支持,以及对Hadoop、Spark、Kafka、Tensorflow、Hive等这些大数据开源组件的容器化发布,这就是打地基。
华为云通过开源的Docker、K8S、Mesos等技术,对主流的Hadoop、Hive、Spark、Kafka等多种大数据技术组件进行了容器化集成,实现大数据应用与底层运行环境之间的解耦,推出了应用云平台(PaaS)与容器大数据平台。也就是说华为云的用户不用再过度关心底层开源组件的运维了,可以更加专注于自身的业务。
全栈大数据云:在大数据开源组件容器化的基础上,华为云还把数据开发平台统一集成,推出了数据湖治理中心DGC(Data Lake Govenance Center,链接:https://www.huaweicloud.com/product/dayu.html),包括数据采集、数据规范、数据开发、数据服务、数据治理、数据可视化等多项工具。数据集成开发平台与应用云平台(PaaS)与容器大数据平台打包交付。 并已经服务了能源、教育、医疗健康、物联网、金融等领域的数十家客户,据笔者掌握的信息,华为云的客户复购率近100%。
更进一步,华为云最近还推出了一套帮助政企构建数据体系的数据使能DAYU服务(链接:https://www.huaweicloud.com/solution/dataenabling.html),结合华为数字化转型实践和30多年在ICT基础设施领域积累的技术,携手行业合作伙伴,为客户提供一站式数据全生命周期管理解决方案,打造“全域、服务化、资产化、智能、安全”的数据体系,释放数据价值。
展望未来,云原生大数据技术还可以充分利用AI技术降本增效:
点击关注,第一时间了解华为云新鲜技术~