Streaming流式数据处理将统治世界,是真的!

在数据处理领域,Streaming流式数据处理被越来越多的提及到,很多报道都提到Streaming将取代传统数据仓库(Data Warehouse)、数据湖(Data Lake)成为下一代数据处理的主要方式。针对流式数据处理方式出现的背景、特点、应用,本文基于Gwen Shapira在Goto论坛以及Neha Narkhede在InfoQ论坛的演讲内容进行了整理,希望能帮助让读者快速的了解流式数据处理。

传统的数据处理

在传统的数据处理方式中,主要通过数据库以及数据仓库这两种方式对数据进行储存的。数据库主要储存业务、操作数据,这些数据周期性(每天)的会被ETL(Extract, Tranform, Load)工具导入数据仓库。由于数据库和数据仓库的数据结构可能并不一致,在数据导入数据仓库之前,可能需要进行额外的数据集成工作。在完成了ETL后,储存在数据仓库内的结构化数据将支持BI等数据分析服务进行业务分析、报表等。

上述数据处理的方式以数据仓库、ETL为主。虽然数据仓库以及ETL已经出现多年,但是从实际的应用情况来看,数据仓库的数据覆盖率的普遍比较低。这个问题的主要原因:

  • 需要全局性的schema数据结构。

  • 在数据清洗以及的转换过程中,往往容易出现数据不兼容的问题,需要大量的手工干预,从而耗费大量的操作成本,而且处理效率低,速度慢。

  • ETL工具普遍基于批量的方式,实时性差。

由于ETL的实时性差,为了实现数据处理的实时性,后来出现了EAI (Enterprise Application Integration)方式。EAI方式主要基于ESB (Enterprise Service Bus)或者MQ来实现不同应用间的数据交换。EAI方式可以有效的处理小规模数据,但是无法对于大规模的数据(例如:日志、传感设备数据)进行有效的处理,例如:ESB容易因为单点故障而导致数据处理系统整体失效。

新的挑战

随着IT技术的发展、业务模式的不断演进,传统的数据处理模式也面临着新的挑战:

  • 基于单机服务器的数据库逐渐被分布式的数据服务所取代。传统的ETL处理方式无法有效地处理分布式的数据。

  • 除了传统关系型数据库的事务型数据,越来越多不同的数据形式需要被处理,例如:日志、传感器数据等。

  • 传统的批量数据处理方式无法满足业务对数据的实时处理的需求。

如果把上述挑战简化为对实时性以及伸缩性的需求,我们可以把传统的ETL以及EAI方式放在以下象限中。很显然,为了满足新的数据处理需求,我们需要一种数据处理方式即可以满足实时处理的需求,又可以进行有效的伸缩。

流式数据处理

在上述背景中,流式数据处理的方式被提出。其定位就是提供一种数据处理方式兼具数据处理实时性以及伸缩性。

流式数据处理对数据进行抽取、转换、储存等处理,向数据消费者提供唯一准确的数据;通过实时的、可伸缩的消息总线像神经中枢一样协调各系统进行交互。

流式数据处理有以下几个特点:

  • 能够处理大规模的、分布的、异构的数据。

  • 支持实时数据处理。而其核心是事件驱动的方式。

通过事件驱动,可以有效的解耦消息发布者(Publisher)以及消息消费者(Consumer)之间的强关联关系。如下图所示,Web App和Hapdoop间并不直接进行交互,而是通过Streaming Pltform进行解耦。

解耦的优势在上图中不容易被发现,但是在有多个消息发布者以及多个消息消费者的情况,通过流式数据作为处理中枢,可以避免重复建立系统间点到点的连接,简化错综复杂的依赖关系。例如:当有新的系统需要向hadoop导入数据,该系统只须发布事件,hadoop、其它数据消费者通过订阅即可获得数据,而不需与各系统间建立连接。

  • 提前处理数据,从而获得数据的提前适配性。

我们通过一个例子来进行解释。假设我们在运营一个电商系统,我们需要将商品的数据加载进数据仓库以生成相应的业务报表,但是在数据加载至数据仓库之前,我们需要将商品数据中的一些敏感信息清除掉。通过传统的ETL方式,通过“E”从数据源读取数据,通过“T”对数据进行清洗、消除敏感数据,通过“L”加载至数据仓库。

假设我们希望通过Cassandra为商品搭建推荐系统,那么我们需要重复上述的ETL过程为Cassandra加载数据。也就是说,同样的数据被重复执行了2次“E”以及2次“T”,由此产生了不必要的、大量的计算资源浪费。

流式数据处理可以有效的解决这个问题。流式数据处理只需要执行1次“E“,并将数据存放在数据队列中,数据的消费者只需要询问队列获得数据即可,而不需要反复地执行“E”。另一方面,在将数据存放在队列时,流式数据处理可以对数据进行消除敏感数据的操作,即“T“,数据消费者不需要再重复执行。

通过上例子,流式数据处理可以在数据消费者获取数据前,完成数据的ET处理。另外,基于不同的业务需求,数据消费者在“L”的过程中,可以对数据进行加工,从而使得数据可以适配不同的业务需求。

总结

流式数据处理解决了传统数据处理过程无法实现实时数据处理以及对大规模、异构数据支持不足的问题,通过事件驱动的方式,搭建消息中枢,连接各系统实现系统间数据的交互。

参考文献


pstrike 2018.06.15 于广州天河

【尊重版权:转载之前请先联系我】

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,504评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,434评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,089评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,378评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,472评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,506评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,519评论 3 413
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,292评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,738评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,022评论 2 329
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,194评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,873评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,536评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,162评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,413评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,075评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,080评论 2 352