写点什么

传统数仓如何转型大数据

用户头像
数据社
关注
发布于: 2020 年 12 月 24 日

大家好,前几天建了一个数据仓库方向的小群,收集了大家的一些问题,其中有个问题,一哥很想去谈一谈——现在做传统数仓,如何快速转到大数据数据呢?其实一哥知道的很多同事都是从传统数据仓库转到大数据的,今天就结合身边的同事经历来一起分享一下。

一、数据仓库

数据仓库:数据仓库系统的主要应用主要是OLAP(On-Line Analytical Processing),支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。也就是说,数据仓库汇总有可能有很多维度数据的统计分析结果,取百家之长(各个数据源的数据),成就自己的一方天地(规划各种业务域的模型,指标)。可以参考之前的文章《面试!什么是数据仓库?

二、传统数据仓库开发



传统的数据仓库用Oracle的居多,多半是单机或者一个双机环境运行。本身硬件,系统都容易形成单点故障。慢慢发展,应该会开始通过存储形成容灾的一个环境。

我了解的传统的数据开发一般分为3个岗位:数据工程师、ETL工程师、数据仓库架构师,大多数人属于前两者。

数据工程师:根据业务人员提交的逻辑来编写“存储过程”,他们能够很轻松的编写上千行的复杂逻辑SQL。在编写SQL多年经验中,掌握了各种关联查询、聚合查询、窗口函数,甚至还可以用SQL自己编写一些Function,最终组合成了存储过程。

ETL工程师:传统数据仓库只有在大型企业中一般才会有,比如电信、银行、保险等行业。他们都会采购一些ETL工具,比如Informatica或者和第三方共建ETL工具,比如和华为、亚信等。这些ETL工具功能非常强大。ETL工程师可以通过在平台上拖拉拽的形式进行数据加工处理,同时ETL平台的组件还可以支撑一些脚本的上传,所以ETL工程师结合数据工程师开发的复杂存储过程,在平台上进行加工设计,最终形成一个个定时任务。然后他们还负责每天监控这些定时任务的状态,对于重要部门的ETL人员还经常会熬夜值班监控。

数据仓库架构师:数据仓库是依靠规范来有序进行的,架构师就是来建立这些规范的,包括数据仓库的分层、模型命名、指标命名、ETL任务命名、ETL任务编排规范、存储过程开发规范等等,最终形成《XX数据仓库建设规范》,然后数据工程师和ETL工程师按照规范进行任务开发。如果遇到重大业务变更,比如主数据变更,需要和数据仓库架构师评审后修改完善。

三、大数据开发



现在的大数据架构多了一些东西,比如数据采集Flume、消息对垒kafka、计算引擎MR、Spark以及实时计算框架,这些都是以前传统数据仓库架构下没有的。

Flume

Flume是一种分布式、高可靠和高可用的服务,用于高效地收集、聚合和移动大量日志数据。它有一个简单而灵活的基于流数据流的体系结构。它具有可调的可靠性机制、故障转移和恢复机制,具有强大的容错能力。它使用一个简单的可扩展数据模型,允许在线分析应用程序。Flume的设计宗旨是向Hadoop集群批量导入基于事件的海量数据。系统中最核心的角色是agent,Flume采集系统就是由一个个agent所连接起来形成。每一个agent相当于一个数据传递员,内部有三个组件:

source: 采集源,用于跟数据源对接,以获取数据

sink:传送数据的目的地,用于往下一级agent或者最终存储系统传递数据

channel:agent内部的数据传输通道,用于从source传输数据到sink

详细配置参考:《日志收集组件—Flume、Logstash、Filebeat对比

kafka

Kafka是最初由Linkedin公司开发,是一个分布式、分区的、多副本的、多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/nginx日志、访问日志,消息服务等等,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

主要应用场景是:日志收集系统和消息系统。

Kafka主要设计目标如下:

  • 提供消息持久化能力,即使对TB级以上数据也能保证常数时间的访问性能。

  • 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。

  • 支持Kafka Server间的消息分区,及分布式消费,同时保证每个partition内的消息顺序传输。

  • 同时支持离线数据处理和实时数据处理。

  • Scale out:支持在线水平扩展

大数据计算引擎

近几年出现了很多热门的开源社区,其中著名的有 Hadoop、Storm,以及后来的Spark、Flink,他们都有着各自专注的应用场景。Spark掀开了内存计算的先河,也以内存为赌注,赢得了内存计算的飞速发展。Spark的火热或多或少的掩盖了其他分布式计算的系统身影。不过目前Flink在阿里的力推之下,也逐渐占领着实时处理的市场。其实大数据的计算引擎分成了三代:

  • 第一代计算引擎

无疑就是Hadoop承载的 MapReduce。这里大家应该都不会对MapReduce陌生,它将计算分为两个阶段,分别为 Map 和 Reduce。对于上层应用来说,就不得不想方设法去拆分算法,甚至于不得不在上层应用实现多个 Job 的串联,以完成一个完整的算法,例如迭代计算。MR每次计算都会和HDFS交互,和磁盘交互意味着产生更多的IO,也就会更慢。由于这样的弊端,催生了支持 DAG 框架和基于内存计算的产生。

  • 第二代计算引擎

Spark的特点主要是 Job 内部的 DAG 支持(不跨越 Job),同时支持基于内存的计算。这样的话每次计算到中间步报错了,就不会再从头开始计算一遍,而是接着上一个成功的状态,同时中间计算结果数据也可以放在内存中,大大提高了计算速度。另外,Spark还支持了实时计算,满足了大家维护一套集群,既可以搞离线计算也可以搞实时计算。

  • 第三代计算引擎

促进了上层应用快速发展,例如各种迭代计算的性能以及对流计算和 SQL 等的支持。Flink开始崭露头角。这应该主要表现在 Flink 对流计算的支持,以及更一步的实时性上面。当然 Flink 也可以支持 Batch 的任务,以及 DAG 的运算。

四、转型



有了传统数据仓库转型大数据是一个好的开端,但是路并不会那么顺利,也许并没有你想想的那么快速。从身边的同事来看,大家都是经历了很多项目经验之后,才真正转型成功的。

首先,作为传统的数据仓库工程师,你已经对SQL掌握的非常熟练,这是你的优势。可以看到,现在所有的大数据计算引擎都在支持着SQL,从最早的Hive到现在的Flink。他们大多和标准SQL语法近似,很快能够快速掌握,现在很多离线数据仓库还是建立在Hive之上,从这一点上,你能很快开发HiveSQL脚本。你可以把之前数据仓库架构的那一套方法论拿过啦借鉴,数据仓库这东西建了几十年,还是最初的那几套方法,足够了。只是你会遇到很大的数据量问题,要根据实际情况进行合理的分层,合理的使用临时表。但是,既然你选择了转型,相信你并不只是满足换个环境写SQL吧。所以你要学习Hadoop、学习Spark,身边曾有一个同事从传统数仓转大数据后,就是换个环境写SQL,写了两年了还不知道HDFS常用命令,不知道Spark的计算原理,每次SQL调优的时候,都去问平台开发的同事,怎么修改参数。所以趁着你还在转型的兴头上,学一下这方面的知识。如果之前没有java开发经验,那不建议你学习MR,直接上手Spark吧,python也很好用的,使用pyspark能够解决很多SQL解决不了的问题。

另外,学一学kafka吧,离线数仓搞完了,不想搞实时数仓吗?现在物联网行业,每天有几亿数据上传到平台,每条消息有几千个字段,我们无法选择传统的数据库进行存储。网关直接转发数据到kafka,然后存储到HDFS和HBase。其他行业也一样,电商。搜索,每天那么多人访问,访问数据也都是消息缓存的方式发送到HDFS落地分析的。

最后,推荐两本书吧,帮助你快速转型成功——《阿里大数据之路》、《大数据日知录》 



发布于: 2020 年 12 月 24 日阅读数: 16
用户头像

数据社

关注

微信公众号:数据社 2018.04.26 加入

专注大数据架构,数据仓库,MPP数据库分享,微信公众号数据社

评论

发布
暂无评论
传统数仓如何转型大数据