阿里封神-大数据处理技术漫谈

简介: 以前一篇博客,从宏观描述了云梯1当时整体生态,年底了,笔者再梳理下软件栈,主要以开源软件为主,闭源不谈。大数据发展至今,开源软件层出不穷,也去解决了不同的问题,笔者试图去弄清楚这些,分门别类,后面也可以参照下。由于笔者知识面有限,难免会出现一些偏颇,不全,不正确,还请指正。后面也会有很多新的软件出现

以前一篇博客,从宏观描述了云梯1当时整体生态,年底了,笔者再梳理下软件栈,主要以开源软件为主,闭源不谈。大数据发展至今,开源软件层出不穷,也去解决了不同的问题,笔者试图去弄清楚这些,分门别类,后面也可以参照下。由于笔者知识面有限,难免会出现一些偏颇,不全,不正确,还请指正。后面也会有很多新的软件出现,一段时间后,软件栈也会变化的。

典型架构

Classic_architecture

很多的场景都是如上的,有web(包括无线、以前CS的模式、现在的BS模式等)、DB、cache、数据分析我就用了Hadoop了(代名词,或者泛指数据仓库了),另外就是一些传感器之类的,数据通道(有的简单如:jdbc等,有的比较复杂,保序不丢等),其中也简单列了一些中间件的软件。这张图组成了一家公司的基本架构形式,其中每个点都是一个领域。每个点、每条边、有成千上万的同学在奉献。其中DB、Hadoop一般沉淀了数据,包含了大部分的计算。

大数据软件栈

bigdatasystem
从软件栈上看,笔者简单列出了一些主流的软件,当然每层的软件肯定不仅仅这些。还有上一层是开发者平台,再上是BI,应用,此点就属于sass层,很多公司在此层创业,笔者没有列出。其中分布式计算这层软件最多,有两句话:业务数据化,就是业务系统的数据沉淀在大数据平台;还有数据业务化,也就是体现数据的价值,需要各种各样的计算引擎了。另外:从部署来看,大数据基础软件上云,虚拟化应该是一个趋势。存储、计算分离,分开部署是否是一个趋势呢? 随着网络带宽的提速及成本的降低,在一些场景下简化了复杂性,也未尝不是一种尝试。deploy层解决大数据的部署问题,更加弹性的添加释放资源,包括资源的隔离,跟Resourcemanager层有点类似;storge format数据存储的格式,列式存数为主;distributeFileSystem提供分布式文件的存储能力, 其实可以是如:亚马逊的S3,或者阿里的OSS;Resourcemanager提供大数据操作系统,可以把不同的engine调度起来,包括怎么做隔离等;distribute engine百花齐放,为不同场景提供了很多解决方案,一般应用系统会使用多个engine的,甚至也可以包括DB,如果下层的Resourcemanager做的足够优秀;script层一般降低使用大数据的成本,包括sql、pig等方式,这层是有表的概念的,我们可以跟存储结合起来,提供一个全局的元数据中心;data exchange提供不同系统之间数据流转的能力。

数据量与处理时间

time_datasize
在以时间、数据量的坐标抽上列出目前引擎大致擅长处理数据的坐标,应该还需要加上数据复杂度、成本等维度,才能更好的体现侧重点。没有哪个软件能解决所有的问题,能解决问题也是在一个范围内,即使是spark、flink等。目前存在有意思的事情是:greenplum类似的MPP引擎想处理大数据的需求,hadoop等被定位为大数据的引擎也想解决小数据的问题(列式存储、或者也加入一些索引)。图中右上角的想往左边靠,减少延迟,图中左下角的想往上面靠,增大能处理的数据量。

场景

scene
笔者没有想到更好的方式组织此图,只能如此画出,每个领域或者场景内,又会细分出很多的子场景。

DB层不用去讲,每个网址必有一个DB的。NO-SQL产品就太多了,还分文档类型的,有读优写查、读差写优的等,其实也是DB。MPP其实也发展了很多年,比hadoop之类还要早,主要限制点就是扩展性、灵活性。greenplum开源后,此思潮又火了一把。search一直笔者认为是一个很有意思的产品,产品本身没有准确性的要求,是讲究准确率的。streaming是目前比较火的,特别是物联网、工业4.0的概念越来越火以后。graph也有相应的db,这里一般是分析型的,graph很多问题用ml也可以解决,或者认为其本身也是ml吧,场景比较多,一般就独立出来了。ml可以说现在也是热点之一,只要是数据创业公司,基本ml是其核心的,门槛也比较高。ETL个人感觉目前还是hive最适合的,能取得很高的吞吐,当然别的产品也可以跑的。 一些如GPU、量子计算、银河之类的就不讨论了。

spark、flink肯定是明星,他们能解决了好几个领域的问题。大数据的实时分析系统是否就是用MPP之类去实现,还是以一种更加杂揉的方式实现,目前我也不清楚。druid、kudu不知道放在哪里好,也许就是这种杂揉体,说不定会解决很多的问题,赢得市场。

说了这么多,是希望能成体系的梳理下现有的软件。每个软件做出来肯定是为了解决特定场景的问题,也会发挥一定的价值,万物有生有灭,也许下一代计算机的出现,如量子计算会颠覆现有的模式,到时候就是去HADOOP、超级计算机了,希望笔者还能看到。

版权声明

笔者微博:阿里封神 欢迎转载,但请保留原文地址

目录
相关文章
|
存储 缓存 文件存储
如何保证分布式文件系统的数据一致性
分布式文件系统需要向上层应用提供透明的客户端缓存,从而缓解网络延时现象,更好地支持客户端性能水平扩展,同时也降低对文件服务器的访问压力。当考虑客户端缓存的时候,由于在客户端上引入了多个本地数据副本(Replica),就相应地需要提供客户端对数据访问的全局数据一致性。
32689 78
如何保证分布式文件系统的数据一致性
|
前端开发 容器
HTML5+CSS3前端入门教程---从0开始通过一个商城实例手把手教你学习PC端和移动端页面开发第8章FlexBox布局(上)
HTML5+CSS3前端入门教程---从0开始通过一个商城实例手把手教你学习PC端和移动端页面开发第8章FlexBox布局
17740 19
|
设计模式 存储 监控
设计模式(C++版)
看懂UML类图和时序图30分钟学会UML类图设计原则单一职责原则定义:单一职责原则,所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变,那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。bad case:IPhone类承担了协议管理(Dial、HangUp)、数据传送(Chat)。good case:里式替换原则定义:里氏代换原则(Liskov 
36674 19
设计模式(C++版)
|
存储 编译器 C语言
抽丝剥茧C语言(初阶 下)(下)
抽丝剥茧C语言(初阶 下)
|
机器学习/深度学习 人工智能 自然语言处理
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
带你简单了解Chatgpt背后的秘密:大语言模型所需要条件(数据算法算力)以及其当前阶段的缺点局限性
24753 14
|
机器学习/深度学习 弹性计算 监控
重生之---我测阿里云U1实例(通用算力型)
阿里云产品全线降价的一力作,2023年4月阿里云推出新款通用算力型ECS云服务器Universal实例,该款服务器的真实表现如何?让我先测为敬!
36657 15
重生之---我测阿里云U1实例(通用算力型)
|
SQL 存储 弹性计算
Redis性能高30%,阿里云倚天ECS性能摸底和迁移实践
Redis在倚天ECS环境下与同规格的基于 x86 的 ECS 实例相比,Redis 部署在基于 Yitian 710 的 ECS 上可获得高达 30% 的吞吐量优势。成本方面基于倚天710的G8y实例售价比G7实例低23%,总性价比提高50%;按照相同算法,相对G8a,性价比为1.4倍左右。
|
存储 算法 Java
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的限流器RateLimiter功能服务
随着互联网的快速发展,越来越多的应用程序需要处理大量的请求。如果没有限制,这些请求可能会导致应用程序崩溃或变得不可用。因此,限流器是一种非常重要的技术,可以帮助应用程序控制请求的数量和速率,以保持稳定和可靠的运行。
29834 52
下一篇
开通oss服务