这才是大数据的正确打开方式
摘要:如何将各种大数据技术栈整合在一起,发挥出大数据技术的最大价值成为业界都在关注的问题。
最近,随着健康码的流行,大数据又重回大众的视野。作为新基建产业的原油,数据逐步迈向信息产业的核心。不过随着数据量级的不断扩大,从数据仓库到数据湖再到仓湖一体,如何将各种大数据技术栈整合在一起,发挥出大数据技术的最大价值成为业界都在关注的问题。
越来越大的数据,想说爱你不容易
权威的咨询机构 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 日的数据恢复整个事件持续了一周多的时间。
对微盟这样体量的电商来说,损失无疑是巨大的,股市市值的蒸发是一方面,更重要的是科技公司从本质上是经营数据的公司,而数据丢失事件与银行金库被盗事件从某种程度来说是同样性质的事件,都会对当事公司的声誉造成极大的影响。造成这个问题的本质还是由于数据治理水平,只有将数据按照重要性把数据分类,并分别制订治理策略,才能在真正有用的数据丢失时找到最切实可行的应对办法,眉毛胡子一把抓难以真正降本提效。
按照笔者的观察,目前从治理角度,可以将数据分为以下三种类型:
l 应用数据:也就是交易类应用所产生的数据。为了满足业务需要构建业务 IT 系统,随着 IT 业务系统的不断运行,大量应用数据就产生了,这些数据经过 ETL 加工进入数据仓库,进行再处理,供业务应用。这些数据都是单一的关系型数据,数据量级是 GB 的。
l 用户行为数据:随着互联网和电商的快速发展,大量人的操作行为和使用行为产生的数据,像谷歌、脸书等大数据互联公司,都记录人的形成产生的数据。上网行为、浏览行为、购买行为、评论行为、刷微博,做抖音等都可以产生大量数据。这些数据不再是单一的结构化数据,出现了大量文档、音频和视频数据,数据量级是 TB 级的。
l 硬件日志数据:进入万物互联的时代,大量机器传感器,IoT 设备都会产生大量数据。这些设备 7*24 小时产生数据,数据格式也是多种多样,有的是日志数据,有的是时序数据,有的是网格数据等等,数据量级是 PB 的。
从数据治理角度上讲,上述数据的备份需求是不同的,如果混到一起,那快速恢复业务根本无从谈起。而从数据使用的角度上讲,随着海量的行为及日志类数据的出现,数据的价值必然要从数据治理的角度去要价值。
针对行为及日志等重要性等级不高的数据,一般采用异地磁带备份的方式,使用温备乃至冷备的试进行,不过从目前情况看不少企业尤其是创业型企业,都没有百年老店的观念,在初创时期对于这方面考虑和规划还不够,规划没做好,将来必然会对企业发展有负面影响。
这又就引出第三座大山 - 灾备规划:但也经常被公司管理人员所忽略,大多数初创公司不会提前规划灾备体系,公司上规模之后再进行灾备建设又是 mission impossible。一般来说两地三中心中的生产与同城中心是双活的可以快速接管业务,异地中心数据延迟同步,以应对一些删库删表类的误操作。正如刚刚所说 Hadoop 与数据湖两套体系中的开源组件兼容性很差,能让两者协同工作已属不易,再补充建设灾备节点难上加难。
一般来说目前比较流行的灾备体系是两地三中心的架构,也就是至少在两个地域建设三个数据中心,其中:
l 主中心:正常情况下全面提供业务服务
l 同城中心:一般与主中心处在同一省份,主中心使用同步复制的方式来向同城灾备中心传输数据,保证同城中心数据复本为最新,随时可以接管业务,以保证 RTO 的指标。但是同城中心无法应对此类删库事件。
l 异地中心:一般使用延时异步复制(延时时间一般为 30 分钟左右)的方式向异地灾备中心传输数据,其中同步复制的好处是一旦主中心被人工破坏,那么不会立刻涉及异地中心。以保证 RPO 的指标。
总结灾备体系的最佳实践就是两地三中心;同城保证业务连续性,优先负责用户体验;异地保证数据连续性,确保企业生存底线。上云后的灾备规划也一定要纳入设计范围,一旦没有提前的规划,后续的补齐填坑的工作非常麻烦。
云原生打开大数据未来的正确方式
从上面三座大山可以看出,大数据最终用户的最佳选择就是在云平台上找到大数据的一栈式解决方案,屏蔽底层组件的差别,才能提高效率,低成本运维,因此可以说与云计算无缝对接的云原生技术肯定会是未来的方向。
而华为云云原生大数据以其容器化集成及全栈大数据云平台的两大特性,很好解决了大数据技术在实际落地中的特点,我们用“大数据的操作系统”来定义华为云的云原生大数据会更加直观贴切:
容器化集成:基于 Mesos 的资源管理,支持 Marathon 和 Kubernetes 的容器编排框架,采用云原生架构的数据平台。底层是对容器化的支持,以及对 Hadoop、Spark、Kafka、Tensorflow、Hive 等这些大数据开源组件的容器化发布,这就是打地基。
华为云通过开源的 Docker、K8S、Mesos 等技术,对主流的 Hadoop、Hive、Spark、Kafka 等多种大数据技术组件进行了容器化集成,实现大数据应用与底层运行环境之间的解耦,推出了应用云平台(PaaS)与容器大数据平台。也就是说华为云的用户不用再过度关心底层开源组件的运维了,可以更加专注于自身的业务。
全栈大数据云:在大数据开源组件容器化的基础上,华为云还把数据开发平台统一集成,推出了数据湖治理中心 DGC(Data Lake Govenance Center),包括数据采集、数据规范、数据开发、数据服务、数据治理、数据可视化等多项工具。数据集成开发平台与应用云平台(PaaS)与容器大数据平台打包交付。 并已经服务了能源、教育、医疗健康、物联网、金融等领域的数十家客户,据笔者掌握的信息,华为云的客户复购率近 100%。
更进一步,华为云最近还推出了一套帮助政企构建数据体系的数据使能DAYU服务,结合华为数字化转型实践和 30 多年在 ICT 基础设施领域积累的技术,携手行业合作伙伴,为客户提供一站式数据全生命周期管理解决方案,打造“全域、服务化、资产化、智能、安全”的数据体系,释放数据价值。
展望未来,云原生大数据技术还可以充分利用 AI 技术降本增效:
l 利用人工智能将冷热数据分层分离,让计算和存储资源充分利用,有效降低数据管理成本。
l 通过分析系统运行状态和日志数据信息,利用人工智能建模,来实现动态系统参数调整和系统优化,显著降低系统数据管理者的运维成本。
l 利用机器学习技术帮助系统建立更加准确高效的在线预警与实时监测系统,来实现智能化的运维管控和资源调配,帮助系统管理人员将更多的时间和精力集中在更重要的系统任务上。
版权声明: 本文为 InfoQ 作者【华为云开发者社区】的原创文章。
原文链接:【http://xie.infoq.cn/article/7f45799d59e026df99e2cd916】。文章转载请联系作者。
评论