写点什么

传统 BI 如何转大数据数仓

用户头像
数据社
关注
发布于: 2021 年 05 月 11 日
传统BI如何转大数据数仓

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


数据仓库


数据仓库:数据仓库系统的主要应用主要是 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 落地分析的。


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

发布于: 2021 年 05 月 11 日阅读数: 492
用户头像

数据社

关注

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

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

评论

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