数据架构_数据架构师 - CSDN
精华内容
参与话题
  • 数据架构规划

    千次阅读 2014-05-21 13:37:51
    架构师的角色中,沟通是要求有效果的必备技能与工具。换句话说,沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段。  架构师通常没有对为其项目工作的他人的直接管理权。他们的项目往往是跨部门的,...

    一.当前架构

        结合研发二部数据量最大的校讯通产品来描述,其他的产品在性能上出现瓶颈,可以向校讯通靠拢。

    数 据库整体架构:目前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度,横向采用了历史库+当前库的分库架构或者单一的当前库架构,其中历史库只作 为web平台读数据库,纵向结合了applications的memcache+Sybase ASE12.5传统永久磁盘化数据库架构。

    数据模型架构:原则上采用了一事一地的数据模型(3NF范式),为了性能考虑,一些大数据量表适当的引用了数据冗余,根据业务再结合采用了当前表+历史表的数据模型。

    以下就用图表来进行当前数据架构的说明:

    横向分库数据库架构图:

     数据架构规划


    纵向app layer+memcache layler+disk db layer图:

    数据架构规划

    其中web层指的是客户端浏览器层,逻辑上:app层指的是应用服务层,mc层指的是memcache的客户端层,ms层指的是memcache的服务层,db层指的是目前永久磁盘化的数据库层,当然在物理机器上可能app层跟mc层,ms层是重叠的部署在相同服务器上。


    数据模型架构图:

    数据架构规划

        其中以上数据模型中除了少数几张表外其他的都有历史表存在,当然有很多表是没在这个模型图中的,这部分是核心数据模型。这部分模型对象中也包括了一些冗余 性的设计,比如用户中有真实姓名,特别是不在这个模型内,由模型核心表产生的一些统计报表,为了查询的性能冗余了合理一些学校名称,地区名称等方面的设 计。

     

    二.劣势现象

    1.流水表性能瓶颈

        当前架构的性能瓶颈集中在流水表的访问上,最大流水表的记录量达到了超5亿级别,这是由于目前外网在用的sybase数据库系统版本,没有采取很好的关于 分区的技术。曾经有过把流水表进行物理水平分割,把不同月份的数据分割放在不同的物理表上的模型改造设想,碍于产生的应用程序修改工作量大,老旧数据迁移 的麻烦,再加上进行了从单库架构改造到分库架构后,数据库性能瓶颈就不是特别突出。所以模型改造这部分工作没展开。

    无 论是单库或是分库的模式,出现平台访问数据库的性能瓶颈依然集中在大流水表上,在访问高峰高并发量情况下,短信的流水表进程堵塞,数据库服务I/O ,CPU的资源耗费达到顶点,在服务器硬件环境不是特别理想情况下,出现了一定概率造成用户访问缓慢甚至觉得页面无法响应现象,造成了用户体念不良影响。

     

    2. 运营维护难点

        1)历史数据清理运维工作

        为了存储充分利用,为了性能的提升,需要定期进行不再使用的历史数据清理,

    由 于清理的数据量庞大,传统的数据清理方法根本不可能保证一个晚上有效清理完毕,确保平台第二天正常的运行。虽然目前已经实行了比较高效且可行的数据清理方 法,但是每次实行都需要晚上到通宵进行处理,使得数据清理的运维工作特别劳累,影响到运维人员第二天的正常出勤,间接就有可能影响到数据库的正常运维监 控,导致数据库问题出现。

        2)防止索引失效而进行的统计量更新运维工作

        由于流水表数据变动量大,容易导致流水表的索引失效,从而需要定期的进行索引甚至整表的统计量更新工作,统计量更新时间跟流水表的数据总量成正比关系,所 以导致统计量更新速度比较慢,不能确保在计划时间内,统计量更新的完全成功,而且目前外网安装的sybase12.5版本是最低一个的EBF版本,存在较 多BUG,在索引统计量更新过程中可能导致数据库出现病态,进而影响第二天数据库的正常运行。

     

    3.运维监控纰漏(此部分非架构原因引起)

        当前的数据库监控以及运维维护还存在一些纰漏,出现了多次数据库设备空间使用完毕,没有及时添加数据库设备空间导致数据库挂起问题,也多次出现了数据库日 志空间占满导致数据库挂起问题。此类问题还是比较明显,还有一类问题,不是整库挂起,而是部分业务表访问异常,运维可能监控不到,等用户访问到了这部分业 务功能不正常,由用户反馈到运维这边。

     

    4.运营统计报表在当前数据模型架构下重用性较低

        由于用户需求的渐进性,导致数据库统计报表在数据模型设计时没有站在至高点,随着用户需求的不断积累,数据库统计报表对象也跟着不断积累,发现目前存在比较大一部分的统计报表数据在不同数据库对象之间重复统计,没有充分发挥统计数据的重用性。

     

    5.没利用集群技术

        当前的数据库架构还没采用成熟的集群技术,集群技术并不单单指单一数据库系统的集群,可以混合集群,比如内存数据库跟传统永久磁盘化数据库系统集群。

     

    6.分库架构还可完善

        当前的分库架构还可以继续完善,引用成熟的数据库主从分离,读写分离技术。

     

    7.内存数据库技术还没充分利用

        当前的数据库架构虽然在前端使用了memcache技术,但是还可以继续完善使用内存数据库技术再结合异步写技术,使得架构相得益彰。

     

    8.适合海量数据高并发读写,高效率存储的非关系型数据库没充分利用

        当前的数据库架构还没采用正在兴起的NoSql,NewSql技术(目前部分外围系统采用了mongodb来做试验品,而这部分系统的数据量并不大,非关 系型数据库海量数据高并发访问的高效性优势没有体现出来,从而也没掌握真正的使用经验),当然这种数据库也有缺点,就是数据库事务一致性,数据库的写实时 性和读实时性,复杂的SQL查询,特别是多表关联查询是无法满足的。

     

    三.改进思路

        在第二部分的劣势现象中,总结了当前数据库架构以及数据模型架构的缺陷,缺陷还比较多,从另外一个角度也反映了公司产品数据库架构改进和提升的空间还比较大,将来随着不断的迭代改进,可以承受的业务量提升的空间也相应的比较大。

    下面就根据劣势现象进行针对性的阐述改进思路:

    1.流水表性能瓶颈改进

        Sybase12.5没有很好的解决大数据量表的性能问题,但是通过数据库转到Oracle后,充分利用Oracle分区表,分区索引的特性来提升流水表 的访问性能,逻辑上表仍然是一张完整的表,只是将表中的数据在物理上存放到多个表空间(物理文件上,这样查询数据时,不至于每次都扫描整张表。由于逻辑上 仍旧一表,使得应用程序不需要修改,也避免了这个劣势点描述的带来额外许多开发工作量的问题,但是效果几乎等同水平分割数据模型。

     

    2.大流水表运维难的改进

        1)历史数据清理运维工作

        在Oracel数库系统中,针对对大流水表每个月的数据进行分区,这样运维人员在清理历史月份的数据时候,只要通过TRUNCATE PARTITION、 DROP PARTITION的Oracle本身的分区维护命令轻松快速清理掉分区的数据(既指定月份的流水数据)

        2)防止索引失效而进行的统计量更新运维工作

        同样Oracle也有等同于sybase的统计量更新工作,在Oracle中通过对大流水表的分区工作后,进行统计量的更新工作同样就快捷简易,可以通过ANALYZE PARTITION的统计量分析维护命令可以轻松快速对指定分区的统计量进行更新。

     

    3.运维监控纰漏的改进

        主要分两个方面:a)数据库剩余空间方面的监控;b)数据库出错日志的监控。这两个监控虽然通过人为主动性的查看数据库相关信息可以监控到,但是总归还是 会有疏忽遗漏的时候,只是出问题几率高低之分。所以这里再加一道监控,就是通过数据库服务器端的监控程序主动发回有问题或者告警的信息给运维人员。这道监 控程序可以通过shell程序以及数据库程序,结合数据库日志以及剩余空间信息以短信或者邮件的方式发回给运维人员。在数据库剩余空间方面甚至可以通过数 据库本身阀值的设置,做到自动截取日志,自动添加设备。

     

    4.运营统计报表数据模型的改进

        由于原先一些报表模型存在着数据统计的重复性,在晚上定时task中既占用了任务列表的总时间,也对其他并行的task运行造成了一定的资源争用,影响了 数据库性能。所以在这里提出了一种类似蒲公英性质的模型,数据通过发散模式,即插即用到不同的运营统计报表中,势必需要改进当前接近一事一地的3范式模 型,把原先的数据模型拆散,从纵向和横向都接近最小粒度需求的数据模型。使得统计数据可以重复使用,不同的统计报表通过这些原子性的统计数据再组合成报表 所需要的数据,当然这里需要一个平衡,并不完全等同蒲公英模型的统计粒度越细越好,因为越细也代表着原始的统计数据量越大,一会影响原始统计的性能,二会 影响组合成报表的性能,三会占用更多的存储空间。这个平衡度需要掌控好。

     

    5.利用集群技术

        当然通过了前面4点的改进之后,数据库性能会比目前的架构提升一定的性能,至于集群技术就可以作为前面4点改进后的补充和扩展,如果在改进后,依然还存在 较大性能瓶颈情况下可以采用Oracle RAC技术。甚至采用基于内存数据库的分布式数据库架构的混合集群技术。比如在Oracle数据库及Web服务之间加一层 Ameoba 分布式数据库代 理结合内存数据库的架构,

     

    6.分库架构完善改进

        目前的数据库架构采用了分库方式,但是主库(当前库)的读写却是没有分离的,纵观淘宝的数据库架构演进历程,确是在某个历程碑点做到了很好的读写分离,应 用到DB的数据写入与查询从双向通行变成了单向通行,通行效率更高,大大避免了相互影响。“借道行驶”的情况不再出现。淘宝那个碑点做到了以下几点:

    1)写库为集中式的oracle环境,提供数据安全性保障。

    2)读库使用mysql, 采用数据分片,分库分表,每台mysql放少量的数据,单个数据分片内部采用mysql复制机制。

    3)读库的超大memory容量,起到了很好的cache作用,在内存中的数据查询性能远远高于在硬盘上的性能

    4)oracle到多台mysql按规则复制

    结合淘宝架构的思考,校讯通大流水也可以做到垂直分割到不同的服务器,也可以做到水品分割到不同的服务器,通过不同的服务器访问不同的流水表或者是不同范围数据的流水表,那提升性能是肯定的。不过也要平衡考虑到应用程序开发的简便性。

     

    7.内存数据库技术利用

        常见的内存数据库产品包括商业版和免费版两类。商业版如:Altibase,Timesten,Berkley DB等。他们在电信,金融,证券等高性能计算应用中运用较为广泛。商业版功能强大,然而,价格比较昂贵,不适合目前“廉价PC+免费软件”的架构搭建思 想。

    开源领域产品主要有H2,HsqlDB,Derby,BerkeleyDB 等。在混合集群架构中,内存数据库将承担OLTP的职责,因此除了读写性能外,功能的完备,事务等都需要作为优先评估的因素。

    盛传H2是一个开源的高性能内存数据库,可以通过整合 Ameoba 与 H2,夹在applications和传统db层之间来达到内存数据库层的架构部署。

    Ameoba 是分布式数据库代理,它与 MySQL 整合已经在阿里巴巴核心业务中成功运用。如果仅将数据库节点看作一个存储,MySQL Node 和 H2 Node 并无本质区别。JDBC驱动,DB切分,路由,皆由Ameoba 统一负责。

     

    8.非关系型数据库的使用

        外围的非核心数据,但是数据量又是比较大的的业务系统数据库可以采用非关系型数据库,这是由非关系型数据库的一些基本特性决定的。

    非关系型数据库有满足如下需求的优点特性:

    1)High performance - 对数据库高并发读写的需求 

    2)Huge Storage - 对海量数据的高效率存储和访问的需求

    3)High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

    但同时伴随不能满足以下需求的缺点:

    1)数据库事务一致性需求 

    2)数据库的写实时性和读实时性需求

    3)对复杂的SQL查询,特别是多表关联查询的需求

    正 是由于以上的优缺点也决定了,核心的需要保持一致性的数据,需要复杂关联的数据,需要实时访问的数据不要采用关系型数据库,如果通过ETL把关系型数据库 的流水数据冗余基本信息,组成可以直接查询的业务信息数据,导入到非关系型数据库后,那对海量流水数据的查询速度提升空间是很大的。其中代表型的非关系型 数据有Redis,Tokyo Cabinet,Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable, Riak,Tin, Flare, Lightcloud, KiokuDB,Scalaris, Kai,ThruDB等等非常之多。

     

    四.架构计划

        通过以上当前架构劣势以及改进思路的总结,改善的架构计划就比较清晰了,以下还是通过横向的整体数据库架构,纵向的整体数据库架构,以及数据模型的架构改进来做为新的架构计划。

    风险最小,改动工作量最小的架构就是改进思路中以第4点和第5点之间为分割线。这条分割线前的数据架构基本不需要变动,主要变动的就是数据模型架构中的流水表对象,以及数据库服务器后台添加监控以及智能处理的运维程序工具。

    主要改进的数据模型流水表对象如下图:

    数据架构规划

    同样进行分区的还有其他的一些大流水表,这里不一一详述,这些流水表从sybase进入oracle的分区表,在数据库转型升级过程中完成。

    还有一点就是关于数据库监控工具在架构中的部署,如下图所示:

    数据架构规划

    以上架构改进计划可以在一期中先完成。看运行效果状态,第5点之后的改进计划几乎就是架构的重构了,所以涉及的工作量更大,如果在第1,2,3,4点改进后数据库运行稳定,后续的改进,可以通过实验和应用结合逐步实施起来,作为应付更大型的业务应用技术储备。

        下面结合5,6,7,8点的改进思路做个架构规划,也就是分布式的内存与传统数据库结合的混合集群架构模式,再加上外围产品的非关系型数据库,如下图所示(服务器和db合为同个节点说明,否则图片篇幅占用过大):

     数据架构规划

        上面的架构图中,application(应用服务层),data cache层,disk db layer层已经实现,但是disk db Layer层的多数据库集群技术还没不能说正式实现,虽然分库技术有类似集群嫌疑,async write(异步写)听开发人员也已经涉及使用。那么此新架构图针对原架构的改进就是Memory DB Layer层以及类似Ameoba (可以使用其他的代理)分布式数据库代理还没实现。Memory DB Layer集群加上每个逻辑分区有两个内存库是为了其中一个内存数据库一旦崩溃,同一逻辑分区中的替补节点立即顶替工作,做到健壮的容错和 Failover机制。这个架构明显比校讯通当前在使用的架构要复杂很多,稳定性以及性能的提升都有待实际验证,虽然单单从架构上来讲融合了目前很多的技 术优点(集群,内存数据库等)。

    转自:http://blog.csdn.net/xujinyang/article/details/7103421

    展开全文
  • 一、系统架构 1、描述 2、示例图 二、软件架构 1、描述 2、示例图 三、总体架构 ...六、数据架构 1、描述 2、示例图 七、技术架构 1、描述 2、示例图 八、物理架


    一、系统架构

    1、描述
    2
    、示例图



    二、软件架构
    1
    、描述
    2
    、示例图



    三、总体架构
    1
    、描述
    2
    、示例图



    四、业务架构
    1
    、描述
    2
    、示例图



    五、应用架构
    1
    、描述
    2
    、示例图



    六、数据架构
    1
    、描述
    2
    、示例图



    七、技术架构
    1
    、描述
    2
    、示例图




    八、物理架构
    1
    、描述
    2
    、示例图

     



    展开全文
  • 常用的几种大数据架构剖析

    万次阅读 多人点赞 2018-08-31 17:11:32
    但是在类似于Hadoop系列的大数据分析系统大行其道之前,数据分析工作已经经历了长足的发展,尤其是以BI系统为主的数据分析,已经有了非常成熟和稳定的技术方案和生态系统,对于BI系统来说,大概的架构图如下:  ...

    大数据 架构

    数据分析工作虽然隐藏在业务系统背后,但是具有非常重要的作用,数据分析的结果对决策、业务发展有着举足轻重的作用。随着大数据技术的发展,数据挖掘、数据探索等专有名词曝光度越来越高,但是在类似于Hadoop系列的大数据分析系统大行其道之前,数据分析工作已经经历了长足的发展,尤其是以BI系统为主的数据分析,已经有了非常成熟和稳定的技术方案和生态系统,对于BI系统来说,大概的架构图如下: 


    可以看到在BI系统里面,核心的模块是Cube,Cube是一个更高层的业务模型抽象,在Cube之上可以进行多种操作,例如上钻、下钻、切片等操作。大部分BI系统都基于关系型数据库,关系型数据库使用SQL语句进行操作,但是SQL在多维操作和分析的表示能力上相对较弱,所以Cube有自己独有的查询语言MDX,MDX表达式具有更强的多维表现能力,所以以Cube为核心的分析系统基本占据着数据统计分析的半壁江山,大多数的数据库服务厂商直接提供了BI套装软件服务,轻易便可搭建出一套Olap分析系统。不过BI的问题也随着时间的推移逐渐显露出来: 

    • BI系统更多的以分析业务数据产生的密度高、价值高的结构化数据为主,对于非结构化和半结构化数据的处理非常乏力,例如图片,文本,音频的存储,分析。
    • 由于数据仓库为结构化存储,在数据从其他系统进入数据仓库这个东西,我们通常叫做ETL过程,ETL动作和业务进行了强绑定,通常需要一个专门的ETL团队去和业务做衔接,决定如何进行数据的清洗和转换。
    • 随着异构数据源的增加,例如如果存在视频,文本,图片等数据源,要解析数据内容进入数据仓库,则需要非常复杂等ETL程序,从而导致ETL变得过于庞大和臃肿。
    • 当数据量过大的时候,性能会成为瓶颈,在TB/PB级别的数据量上表现出明显的吃力。
    • 数据库的范式等约束规则,着力于解决数据冗余的问题,是为了保障数据的一致性,但是对于数据仓库来说,我们并不需要对数据做修改和一致性的保障,原则上来说数据仓库的原始数据都是只读的,所以这些约束反而会成为影响性能的因素。
    • ETL动作对数据的预先假设和处理,导致机器学习部分获取到的数据为假设后的数据,因此效果不理想。例如如果需要使用数据仓库进行异常数据的挖掘,则在数据入库经过ETL的时候就需要明确定义需要提取的特征数据,否则无法结构化入库,然而大多数情况是需要基于异构数据才能提取出特征。

    在一系列的问题下,以Hadoop体系为首的大数据分析平台逐渐表现出优异性,围绕Hadoop体系的生态圈也不断的变大,对于Hadoop系统来说,从根本上解决了传统数据仓库的瓶颈的问题,但是也带来一系列的问题: 

    • 从数据仓库升级到大数据架构,是不具备平滑演进的,基本等于推翻重做。
    • 大数据下的分布式存储强调数据的只读性质,所以类似于Hive,HDFS这些存储方式都不支持update,HDFS的write操作也不支持并行,这些特性导致其具有一定的局限性。

    基于大数据架构的数据分析平台侧重于从以下几个维度去解决传统数据仓库做数据分析面临的瓶颈: 

    • 分布式计算:分布式计算的思路是让多个节点并行计算,并且强调数据本地性,尽可能的减少数据的传输,例如Spark通过RDD的形式来表现数据的计算逻辑,可以在RDD上做一系列的优化,来减少数据的传输。
    • 分布式存储:所谓的分布式存储,指的是将一个大文件拆成N份,每一份独立的放到一台机器上,这里就涉及到文件的副本,分片,以及管理等操作,分布式存储主要优化的动作都在这一块。
    • 检索和存储的结合:在早期的大数据组件中,存储和计算相对比较单一,但是目前更多的方向是在存储上做更多的手脚,让查询和计算更加高效,对于计算来说高效不外乎就是查找数据快,读取数据快,所以目前的存储不单单的存储数据内容,同时会添加很多元信息,例如索引信息。像类似于parquet和carbondata都是这样的思想。

    总的来说,目前围绕Hadoop体系的大数据架构大概有以下几种: 

    传统大数据架构 


    ​之所以叫传统大数据架构,是因为其定位是为了解决传统BI的问题,简单来说,数据分析的业务没有发生任何变化,但是因为数据量、性能等问题导致系统无法正常使用,需要进行升级改造,那么此类架构便是为了解决这个问题。可以看到,其依然保留了ETL的动作,将数据经过ETL动作进入数据存储。 

    优点:简单,易懂,对于BI系统来说,基本思想没有发生变化,变化的仅仅是技术选型,用大数据架构替换掉BI的组件。 

    缺点:对于大数据来说,没有BI下如此完备的Cube架构,虽然目前有kylin,但是kylin的局限性非常明显,远远没有BI下的Cube的灵活度和稳定度,因此对业务支撑的灵活度不够,所以对于存在大量报表,或者复杂的钻取的场景,需要太多的手工定制化,同时该架构依旧以批处理为主,缺乏实时的支撑。 

    适用场景:数据分析需求依旧以BI场景为主,但是因为数据量、性能等问题无法满足日常使用。 

    流式架构 


    在传统大数据架构的基础上,流式架构非常激进,直接拔掉了批处理,数据全程以流的形式处理,所以在数据接入端没有了ETL,转而替换为数据通道。经过流处理加工后的数据,以消息的形式直接推送给了消费者。虽然有一个存储部分,但是该存储更多的以窗口的形式进行存储,所以该存储并非发生在数据湖,而是在外围系统。 

    优点:没有臃肿的ETL过程,数据的实效性非常高。 

    缺点:对于流式架构来说,不存在批处理,因此对于数据的重播和历史统计无法很好的支撑。对于离线分析仅仅支撑窗口之内的分析。 

    适用场景:预警,监控,对数据有有效期要求的情况。 

    Lambda架构 


    Lambda架构算是大数据系统里面举足轻重的架构,大多数架构基本都是Lambda架构或者基于其变种的架构。Lambda的数据通道分为两条分支:实时流和离线。实时流依照流式架构,保障了其实时性,而离线则以批处理方式为主,保障了最终一致性。什么意思呢?流式通道处理为保障实效性更多的以增量计算为主辅助参考,而批处理层则对数据进行全量运算,保障其最终的一致性,因此Lambda最外层有一个实时层和离线层合并的动作,此动作是Lambda里非常重要的一个动作,大概的合并思路如下: 


    优点:既有实时又有离线,对于数据分析场景涵盖的非常到位。 

    缺点:离线层和实时流虽然面临的场景不相同,但是其内部处理的逻辑却是相同,因此有大量荣誉和重复的模块存在。 

    适用场景:同时存在实时和离线需求的情况。 

    Kappa架构 


    ​ Kappa架构在Lambda 的基础上进行了优化,将实时和流部分进行了合并,将数据通道以消息队列进行替代。因此对于Kappa架构来说,依旧以流处理为主,但是数据却在数据湖层面进行了存储,当需要进行离线分析或者再次计算的时候,则将数据湖的数据再次经过消息队列重播一次则可。 

    优点:Kappa架构解决了Lambda架构里面的冗余部分,以数据可重播的超凡脱俗的思想进行了设计,整个架构非常简洁。 

    缺点:虽然Kappa架构看起来简洁,但是施难度相对较高,尤其是对于数据重播部分。 

    适用场景:和Lambda类似,改架构是针对Lambda的优化。 

    Unifield架构 


    ​以上的种种架构都围绕海量数据处理为主,Unifield架构则更激进,将机器学习和数据处理揉为一体,从核心上来说,Unifield依旧以Lambda为主,不过对其进行了改造,在流处理层新增了机器学习层。可以看到数据在经过数据通道进入数据湖后,新增了模型训练部分,并且将其在流式层进行使用。同时流式层不单使用模型,也包含着对模型的持续训练。 

    优点:Unifield架构提供了一套数据分析和机器学习结合的架构方案,非常好的解决了机器学习如何与数据平台进行结合的问题。 

    缺点:Unifield架构实施复杂度更高,对于机器学习架构来说,从软件包到硬件部署都和数据分析平台有着非常大的差别,因此在实施过程中的难度系数更高。 

    适用场景:有着大量数据需要分析,同时对机器学习方便又有着非常大的需求或者有规划。 

    总结 

    以上几种架构为目前数据处理领域使用比较多的几种架构,当然还有非常多其他架构,不过其思想都会或多或少的类似。数据领域和机器学习领域会持续发展,以上几种思想或许终究也会变得过时。

    展开全文
  • 五种大数据架构简介

    千次阅读 2019-05-10 15:38:05
    虽然处理数据所需的计算能力或存储容量早已超过一台计算机的上限,但这种计算类型的普遍性、规模,以及价值在最近几年才经历了大规模扩展。 本文将介绍大数据系统一个最基本的组件:处理框架。处理...

    来源: https://blog.csdn.net/wjandy0211/article/details/78802044

     

    大数据是收集、整理、处理大容量数据集,并从中获得见解所需的非传统战略和技术的总称。虽然处理数据所需的计算能力或存储容量早已超过一台计算机的上限,但这种计算类型的普遍性、规模,以及价值在最近几年才经历了大规模扩展。

    本文将介绍大数据系统一个最基本的组件:处理框架。处理框架负责对系统中的数据进行计算,例如处理从非易失存储中读取的数据,或处理刚刚摄入到系统中的数据。数据的计算则是指从大量单一数据点中提取信息和见解的过程。

    下文将介绍这些框架:

    · 仅批处理框架:

    Apache Hadoop

    · 仅流处理框架:

    Apache Storm

    Apache Samza

    · 混合框架:

    Apache Spark

    Apache Flink

    大数据处理框架是什么?

    处理框架和处理引擎负责对数据系统中的数据进行计算。虽然“引擎”和“框架”之间的区别没有什么权威的定义,但大部分时候可以将前者定义为实际负责处理数据操作的组件,后者则可定义为承担类似作用的一系列组件。

    例如Apache Hadoop可以看作一种以MapReduce作为默认处理引擎的处理框架。引擎和框架通常可以相互替换或同时使用。例如另一个框架Apache Spark可以纳入Hadoop并取代MapReduce。组件之间的这种互操作性是大数据系统灵活性如此之高的原因之一。

    虽然负责处理生命周期内这一阶段数据的系统通常都很复杂,但从广义层面来看它们的目标是非常一致的:通过对数据执行操作提高理解能力,揭示出数据蕴含的模式,并针对复杂互动获得见解。

    为了简化这些组件的讨论,我们会通过不同处理框架的设计意图,按照所处理的数据状态对其进行分类。一些系统可以用批处理方式处理数据,一些系统可以用流方式处理连续不断流入系统的数据。此外还有一些系统可以同时处理这两类数据。

    在深入介绍不同实现的指标和结论之前,首先需要对不同处理类型的概念进行一个简单的介绍。

    批处理系统

    批处理在大数据世界有着悠久的历史。批处理主要操作大容量静态数据集,并在计算过程完成后返回结果。

    批处理模式中使用的数据集通常符合下列特征…

    · 有界:批处理数据集代表数据的有限集合

    · 持久:数据通常始终存储在某种类型的持久存储位置中

    · 大量:批处理操作通常是处理极为海量数据集的唯一方法

    批处理非常适合需要访问全套记录才能完成的计算工作。例如在计算总数和平均数时,必须将数据集作为一个整体加以处理,而不能将其视作多条记录的集合。这些操作要求在计算进行过程中数据维持自己的状态。

    需要处理大量数据的任务通常最适合用批处理操作进行处理。无论直接从持久存储设备处理数据集,或首先将数据集载入内存,批处理系统在设计过程中就充分考虑了数据的量,可提供充足的处理资源。由于批处理在应对大量持久数据方面的表现极为出色,因此经常被用于对历史数据进行分析。

    大量数据的处理需要付出大量时间,因此批处理不适合对处理时间要求较高的场合。

    Apache Hadoop

    Apache Hadoop是一种专用于批处理的处理框架。Hadoop是首个在开源社区获得极大关注的大数据框架。基于谷歌有关海量数据处理所发表的多篇论文与经验的Hadoop重新实现了相关算法和组件堆栈,让大规模批处理技术变得更易用。

    新版Hadoop包含多个组件,即多个层,通过配合使用可处理批数据:

    · HDFS:HDFS是一种分布式文件系统层,可对集群节点间的存储和复制进行协调。HDFS确保了无法避免的节点故障发生后数据依然可用,可将其用作数据来源,可用于存储中间态的处理结果,并可存储计算的最终结果。

    · YARN:YARN是Yet Another Resource Negotiator(另一个资源管理器)的缩写,可充当Hadoop堆栈的集群协调组件。该组件负责协调并管理底层资源和调度作业的运行。通过充当集群资源的接口,YARN使得用户能在Hadoop集群中使用比以往的迭代方式运行更多类型的工作负载。

    · MapReduce:MapReduce是Hadoop的原生批处理引擎。

    批处理模式

    Hadoop的处理功能来自MapReduce引擎。MapReduce的处理技术符合使用键值对的map、shuffle、reduce算法要求。基本处理过程包括:

    · 从HDFS文件系统读取数据集

    · 将数据集拆分成小块并分配给所有可用节点

    · 针对每个节点上的数据子集进行计算(计算的中间态结果会重新写入HDFS)

    · 重新分配中间态结果并按照键进行分组

    · 通过对每个节点计算的结果进行汇总和组合对每个键的值进行“Reducing”

    · 将计算而来的最终结果重新写入 HDFS

    优势和局限

    由于这种方法严重依赖持久存储,每个任务需要多次执行读取和写入操作,因此速度相对较慢。但另一方面由于磁盘空间通常是服务器上最丰富的资源,这意味着MapReduce可以处理非常海量的数据集。同时也意味着相比其他类似技术,Hadoop的MapReduce通常可以在廉价硬件上运行,因为该技术并不需要将一切都存储在内存中。MapReduce具备极高的缩放潜力,生产环境中曾经出现过包含数万个节点的应用。

    MapReduce的学习曲线较为陡峭,虽然Hadoop生态系统的其他周边技术可以大幅降低这一问题的影响,但通过Hadoop集群快速实现某些应用时依然需要注意这个问题。

    围绕Hadoop已经形成了辽阔的生态系统,Hadoop集群本身也经常被用作其他软件的组成部件。很多其他处理框架和引擎通过与Hadoop集成也可以使用HDFS和YARN资源管理器。

    总结

    Apache Hadoop及其MapReduce处理引擎提供了一套久经考验的批处理模型,最适合处理对时间要求不高的非常大规模数据集。通过非常低成本的组件即可搭建完整功能的Hadoop集群,使得这一廉价且高效的处理技术可以灵活应用在很多案例中。与其他框架和引擎的兼容与集成能力使得Hadoop可以成为使用不同技术的多种工作负载处理平台的底层基础。

    流处理系统

    流处理系统会对随时进入系统的数据进行计算。相比批处理模式,这是一种截然不同的处理方式。流处理方式无需针对整个数据集执行操作,而是对通过系统传输的每个数据项执行操作。

    · 流处理中的数据集是“无边界”的,这就产生了几个重要的影响:

    · 完整数据集只能代表截至目前已经进入到系统中的数据总量。

    · 工作数据集也许更相关,在特定时间只能代表某个单一数据项。

    处理工作是基于事件的,除非明确停止否则没有“尽头”。处理结果立刻可用,并会随着新数据的抵达继续更新。

    流处理系统可以处理几乎无限量的数据,但同一时间只能处理一条(真正的流处理)或很少量(微批处理,Micro-batch Processing)数据,不同记录间只维持最少量的状态。虽然大部分系统提供了用于维持某些状态的方法,但流处理主要针对副作用更少,更加功能性的处理(Functional processing)进行优化。

    功能性操作主要侧重于状态或副作用有限的离散步骤。针对同一个数据执行同一个操作会或略其他因素产生相同的结果,此类处理非常适合流处理,因为不同项的状态通常是某些困难、限制,以及某些情况下不需要的结果的结合体。因此虽然某些类型的状态管理通常是可行的,但这些框架通常在不具备状态管理机制时更简单也更高效。

    此类处理非常适合某些类型的工作负载。有近实时处理需求的任务很适合使用流处理模式。分析、服务器或应用程序错误日志,以及其他基于时间的衡量指标是最适合的类型,因为对这些领域的数据变化做出响应对于业务职能来说是极为关键的。流处理很适合用来处理必须对变动或峰值做出响应,并且关注一段时间内变化趋势的数据。

    Apache Storm

    Apache Storm是一种侧重于极低延迟的流处理框架,也许是要求近实时处理的工作负载的最佳选择。该技术可处理非常大量的数据,通过比其他解决方案更低的延迟提供结果。

    流处理模式

    Storm的流处理可对框架中名为Topology(拓扑)的DAG(Directed Acyclic Graph,有向无环图)进行编排。这些拓扑描述了当数据片段进入系统后,需要对每个传入的片段执行的不同转换或步骤。

    拓扑包含:

    · Stream:普通的数据流,这是一种会持续抵达系统的无边界数据。

    · Spout:位于拓扑边缘的数据流来源,例如可以是API或查询等,从这里可以产生待处理的数据。

    · Bolt:Bolt代表需要消耗流数据,对其应用操作,并将结果以流的形式进行输出的处理步骤。Bolt需要与每个Spout建立连接,随后相互连接以组成所有必要的处理。在拓扑的尾部,可以使用最终的Bolt输出作为相互连接的其他系统的输入。

    Storm背后的想法是使用上述组件定义大量小型的离散操作,随后将多个组件组成所需拓扑。默认情况下Storm提供了“至少一次”的处理保证,这意味着可以确保每条消息至少可以被处理一次,但某些情况下如果遇到失败可能会处理多次。Storm无法确保可以按照特定顺序处理消息。

    为了实现严格的一次处理,即有状态处理,可以使用一种名为Trident的抽象。严格来说不使用Trident的Storm通常可称之为Core Storm。Trident会对Storm的处理能力产生极大影响,会增加延迟,为处理提供状态,使用微批模式代替逐项处理的纯粹流处理模式。

    为避免这些问题,通常建议Storm用户尽可能使用Core Storm。然而也要注意,Trident对内容严格的一次处理保证在某些情况下也比较有用,例如系统无法智能地处理重复消息时。如果需要在项之间维持状态,例如想要计算一个小时内有多少用户点击了某个链接,此时Trident将是你唯一的选择。尽管不能充分发挥框架与生俱来的优势,但Trident提高了Storm的灵活性。

    Trident拓扑包含:

    · 流批(Stream batch):这是指流数据的微批,可通过分块提供批处理语义。

    · 操作(Operation):是指可以对数据执行的批处理过程。

    优势和局限

    目前来说Storm可能是近实时处理领域的最佳解决方案。该技术可以用极低延迟处理数据,可用于希望获得最低延迟的工作负载。如果处理速度直接影响用户体验,例如需要将处理结果直接提供给访客打开的网站页面,此时Storm将会是一个很好的选择。

    Storm与Trident配合使得用户可以用微批代替纯粹的流处理。虽然借此用户可以获得更大灵活性打造更符合要求的工具,但同时这种做法会削弱该技术相比其他解决方案最大的优势。话虽如此,但多一种流处理方式总是好的。

    Core Storm无法保证消息的处理顺序。Core Storm为消息提供了“至少一次”的处理保证,这意味着可以保证每条消息都能被处理,但也可能发生重复。Trident提供了严格的一次处理保证,可以在不同批之间提供顺序处理,但无法在一个批内部实现顺序处理。

    在互操作性方面,Storm可与Hadoop的YARN资源管理器进行集成,因此可以很方便地融入现有Hadoop部署。除了支持大部分处理框架,Storm还可支持多种语言,为用户的拓扑定义提供了更多选择。

    总结

    对于延迟需求很高的纯粹的流处理工作负载,Storm可能是最适合的技术。该技术可以保证每条消息都被处理,可配合多种编程语言使用。由于Storm无法进行批处理,如果需要这些能力可能还需要使用其他软件。如果对严格的一次处理保证有比较高的要求,此时可考虑使用Trident。不过这种情况下其他流处理框架也许更适合。

    Apache Samza

    Apache Samza是一种与Apache Kafka消息系统紧密绑定的流处理框架。虽然Kafka可用于很多流处理系统,但按照设计,Samza可以更好地发挥Kafka独特的架构优势和保障。该技术可通过Kafka提供容错、缓冲,以及状态存储。

    Samza可使用YARN作为资源管理器。这意味着默认情况下需要具备Hadoop集群(至少具备HDFS和YARN),但同时也意味着Samza可以直接使用YARN丰富的内建功能。

    流处理模式

    Samza依赖Kafka的语义定义流的处理方式。Kafka在处理数据时涉及下列概念:

    · Topic(话题):进入Kafka系统的每个数据流可称之为一个话题。话题基本上是一种可供消耗方订阅的,由相关信息组成的数据流。

    · Partition(分区):为了将一个话题分散至多个节点,Kafka会将传入的消息划分为多个分区。分区的划分将基于键(Key)进行,这样可以保证包含同一个键的每条消息可以划分至同一个分区。分区的顺序可获得保证。

    · Broker(代理):组成Kafka集群的每个节点也叫做代理。

    · Producer(生成方):任何向Kafka话题写入数据的组件可以叫做生成方。生成方可提供将话题划分为分区所需的键。

    · Consumer(消耗方):任何从Kafka读取话题的组件可叫做消耗方。消耗方需要负责维持有关自己分支的信息,这样即可在失败后知道哪些记录已经被处理过了。

    由于Kafka相当于永恒不变的日志,Samza也需要处理永恒不变的数据流。这意味着任何转换创建的新数据流都可被其他组件所使用,而不会对最初的数据流产生影响。

    优势和局限

    乍看之下,Samza对Kafka类查询系统的依赖似乎是一种限制,然而这也可以为系统提供一些独特的保证和功能,这些内容也是其他流处理系统不具备的。

    例如Kafka已经提供了可以通过低延迟方式访问的数据存储副本,此外还可以为每个数据分区提供非常易用且低成本的多订阅者模型。所有输出内容,包括中间态的结果都可写入到Kafka,并可被下游步骤独立使用。

    这种对Kafka的紧密依赖在很多方面类似于MapReduce引擎对HDFS的依赖。虽然在批处理的每个计算之间对HDFS的依赖导致了一些严重的性能问题,但也避免了流处理遇到的很多其他问题。

    Samza与Kafka之间紧密的关系使得处理步骤本身可以非常松散地耦合在一起。无需事先协调,即可在输出的任何步骤中增加任意数量的订阅者,对于有多个团队需要访问类似数据的组织,这一特性非常有用。多个团队可以全部订阅进入系统的数据话题,或任意订阅其他团队对数据进行过某些处理后创建的话题。这一切并不会对数据库等负载密集型基础架构造成额外的压力。

    直接写入Kafka还可避免回压(Backpressure)问题。回压是指当负载峰值导致数据流入速度超过组件实时处理能力的情况,这种情况可能导致处理工作停顿并可能丢失数据。按照设计,Kafka可以将数据保存很长时间,这意味着组件可以在方便的时候继续进行处理,并可直接重启动而无需担心造成任何后果。

    Samza可以使用以本地键值存储方式实现的容错检查点系统存储数据。这样Samza即可获得“至少一次”的交付保障,但面对由于数据可能多次交付造成的失败,该技术无法对汇总后状态(例如计数)提供精确恢复。

    Samza提供的高级抽象使其在很多方面比Storm等系统提供的基元(Primitive)更易于配合使用。目前Samza只支持JVM语言,这意味着它在语言支持方面不如Storm灵活。

    总结

    对于已经具备或易于实现Hadoop和Kafka的环境,Apache Samza是流处理工作负载一个很好的选择。Samza本身很适合有多个团队需要使用(但相互之间并不一定紧密协调)不同处理阶段的多个数据流的组织。Samza可大幅简化很多流处理工作,可实现低延迟的性能。如果部署需求与当前系统不兼容,也许并不适合使用,但如果需要极低延迟的处理,或对严格的一次处理语义有较高需求,此时依然适合考虑。

    混合处理系统:批处理和流处理

    一些处理框架可同时处理批处理和流处理工作负载。这些框架可以用相同或相关的组件和API处理两种类型的数据,借此让不同的处理需求得以简化。

    如你所见,这一特性主要是由Spark和Flink实现的,下文将介绍这两种框架。实现这样的功能重点在于两种不同处理模式如何进行统一,以及要对固定和不固定数据集之间的关系进行何种假设。

    虽然侧重于某一种处理类型的项目会更好地满足具体用例的要求,但混合框架意在提供一种数据处理的通用解决方案。这种框架不仅可以提供处理数据所需的方法,而且提供了自己的集成项、库、工具,可胜任图形分析、机器学习、交互式查询等多种任务。

    Apache Spark

    Apache Spark是一种包含流处理能力的下一代批处理框架。与Hadoop的MapReduce引擎基于各种相同原则开发而来的Spark主要侧重于通过完善的内存计算和处理优化机制加快批处理工作负载的运行速度。

    Spark可作为独立集群部署(需要相应存储层的配合),或可与Hadoop集成并取代MapReduce引擎。

    批处理模式

    与MapReduce不同,Spark的数据处理工作全部在内存中进行,只在一开始将数据读入内存,以及将最终结果持久存储时需要与存储层交互。所有中间态的处理结果均存储在内存中。

    虽然内存中处理方式可大幅改善性能,Spark在处理与磁盘有关的任务时速度也有很大提升,因为通过提前对整个任务集进行分析可以实现更完善的整体式优化。为此Spark可创建代表所需执行的全部操作,需要操作的数据,以及操作和数据之间关系的Directed Acyclic Graph(有向无环图),即DAG,借此处理器可以对任务进行更智能的协调。

    为了实现内存中批计算,Spark会使用一种名为Resilient Distributed Dataset(弹性分布式数据集),即RDD的模型来处理数据。这是一种代表数据集,只位于内存中,永恒不变的结构。针对RDD执行的操作可生成新的RDD。每个RDD可通过世系(Lineage)回溯至父级RDD,并最终回溯至磁盘上的数据。Spark可通过RDD在无需将每个操作的结果写回磁盘的前提下实现容错。

    流处理模式

    流处理能力是由Spark Streaming实现的。Spark本身在设计上主要面向批处理工作负载,为了弥补引擎设计和流处理工作负载特征方面的差异,Spark实现了一种叫做微批(Micro-batch)*的概念。在具体策略方面该技术可以将数据流视作一系列非常小的“批”,借此即可通过批处理引擎的原生语义进行处理。

    Spark Streaming会以亚秒级增量对流进行缓冲,随后这些缓冲会作为小规模的固定数据集进行批处理。这种方式的实际效果非常好,但相比真正的流处理框架在性能方面依然存在不足。

    优势和局限

    使用Spark而非Hadoop MapReduce的主要原因是速度。在内存计算策略和先进的DAG调度等机制的帮助下,Spark可以用更快速度处理相同的数据集。

    Spark的另一个重要优势在于多样性。该产品可作为独立集群部署,或与现有Hadoop集群集成。该产品可运行批处理和流处理,运行一个集群即可处理不同类型的任务。

    除了引擎自身的能力外,围绕Spark还建立了包含各种库的生态系统,可为机器学习、交互式查询等任务提供更好的支持。相比MapReduce,Spark任务更是“众所周知”地易于编写,因此可大幅提高生产力。

    为流处理系统采用批处理的方法,需要对进入系统的数据进行缓冲。缓冲机制使得该技术可以处理非常大量的传入数据,提高整体吞吐率,但等待缓冲区清空也会导致延迟增高。这意味着Spark Streaming可能不适合处理对延迟有较高要求的工作负载。

    由于内存通常比磁盘空间更贵,因此相比基于磁盘的系统,Spark成本更高。然而处理速度的提升意味着可以更快速完成任务,在需要按照小时数为资源付费的环境中,这一特性通常可以抵消增加的成本。

    Spark内存计算这一设计的另一个后果是,如果部署在共享的集群中可能会遇到资源不足的问题。相比Hadoop MapReduce,Spark的资源消耗更大,可能会对需要在同一时间使用集群的其他任务产生影响。从本质来看,Spark更不适合与Hadoop堆栈的其他组件共存一处。

    总结

    Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。对于重视吞吐率而非延迟的工作负载,则比较适合使用Spark Streaming作为流处理解决方案。

    Apache Flink

    Apache Flink是一种可以处理批处理任务的流处理框架。该技术可将批处理数据视作具备有限边界的数据流,借此将批处理任务作为流处理的子集加以处理。为所有处理任务采取流处理为先的方法会产生一系列有趣的副作用。

    这种流处理为先的方法也叫做Kappa架构,与之相对的是更加被广为人知的Lambda架构(该架构中使用批处理作为主要处理方法,使用流作为补充并提供早期未经提炼的结果)。Kappa架构中会对一切进行流处理,借此对模型进行简化,而这一切是在最近流处理引擎逐渐成熟后才可行的。

    流处理模型

    Flink的流处理模型在处理传入数据时会将每一项视作真正的数据流。Flink提供的DataStream API可用于处理无尽的数据流。Flink可配合使用的基本组件包括:

    · Stream(流)是指在系统中流转的,永恒不变的无边界数据集

    · Operator(操作方)是指针对数据流执行操作以产生其他数据流的功能

    · Source(源)是指数据流进入系统的入口点

    · Sink(槽)是指数据流离开Flink系统后进入到的位置,槽可以是数据库或到其他系统的连接器

    为了在计算过程中遇到问题后能够恢复,流处理任务会在预定时间点创建快照。为了实现状态存储,Flink可配合多种状态后端系统使用,具体取决于所需实现的复杂度和持久性级别。

    此外Flink的流处理能力还可以理解“事件时间”这一概念,这是指事件实际发生的时间,此外该功能还可以处理会话。这意味着可以通过某种有趣的方式确保执行顺序和分组。

    批处理模型

    Flink的批处理模型在很大程度上仅仅是对流处理模型的扩展。此时模型不再从持续流中读取数据,而是从持久存储中以流的形式读取有边界的数据集。Flink会对这些处理模型使用完全相同的运行时。

    Flink可以对批处理工作负载实现一定的优化。例如由于批处理操作可通过持久存储加以支持,Flink可以不对批处理工作负载创建快照。数据依然可以恢复,但常规处理操作可以执行得更快。

    另一个优化是对批处理任务进行分解,这样即可在需要的时候调用不同阶段和组件。借此Flink可以与集群的其他用户更好地共存。对任务提前进行分析使得Flink可以查看需要执行的所有操作、数据集的大小,以及下游需要执行的操作步骤,借此实现进一步的优化。

    优势和局限

    Flink目前是处理框架领域一个独特的技术。虽然Spark也可以执行批处理和流处理,但Spark的流处理采取的微批架构使其无法适用于很多用例。Flink流处理为先的方法可提供低延迟,高吞吐率,近乎逐项处理的能力。

    Flink的很多组件是自行管理的。虽然这种做法较为罕见,但出于性能方面的原因,该技术可自行管理内存,无需依赖原生的Java垃圾回收机制。与Spark不同,待处理数据的特征发生变化后Flink无需手工优化和调整,并且该技术也可以自行处理数据分区和自动缓存等操作。

    Flink会通过多种方式对工作进行分许进而优化任务。这种分析在部分程度上类似于SQL查询规划器对关系型数据库所做的优化,可针对特定任务确定最高效的实现方法。该技术还支持多阶段并行执行,同时可将受阻任务的数据集合在一起。对于迭代式任务,出于性能方面的考虑,Flink会尝试在存储数据的节点上执行相应的计算任务。此外还可进行“增量迭代”,或仅对数据中有改动的部分进行迭代。

    在用户工具方面,Flink提供了基于Web的调度视图,借此可轻松管理任务并查看系统状态。用户也可以查看已提交任务的优化方案,借此了解任务最终是如何在集群中实现的。对于分析类任务,Flink提供了类似SQL的查询,图形化处理,以及机器学习库,此外还支持内存计算。

    Flink能很好地与其他组件配合使用。如果配合Hadoop 堆栈使用,该技术可以很好地融入整个环境,在任何时候都只占用必要的资源。该技术可轻松地与YARN、HDFS和Kafka 集成。在兼容包的帮助下,Flink还可以运行为其他处理框架,例如Hadoop和Storm编写的任务。

    目前Flink最大的局限之一在于这依然是一个非常“年幼”的项目。现实环境中该项目的大规模部署尚不如其他处理框架那么常见,对于Flink在缩放能力方面的局限目前也没有较为深入的研究。随着快速开发周期的推进和兼容包等功能的完善,当越来越多的组织开始尝试时,可能会出现越来越多的Flink部署。

    总结

    Flink提供了低延迟流处理,同时可支持传统的批处理任务。Flink也许最适合有极高流处理需求,并有少量批处理任务的组织。该技术可兼容原生Storm和Hadoop程序,可在YARN管理的集群上运行,因此可以很方便地进行评估。快速进展的开发工作使其值得被大家关注。

    结论

    大数据系统可使用多种处理技术。

    对于仅需要批处理的工作负载,如果对时间不敏感,比其他解决方案实现成本更低的Hadoop将会是一个好选择。

    对于仅需要流处理的工作负载,Storm可支持更广泛的语言并实现极低延迟的处理,但默认配置可能产生重复结果并且无法保证顺序。Samza与YARN和Kafka紧密集成可提供更大灵活性,更易用的多团队使用,以及更简单的复制和状态管理。

    对于混合型工作负载,Spark可提供高速批处理和微批处理模式的流处理。该技术的支持更完善,具备各种集成库和工具,可实现灵活的集成。Flink提供了真正的流处理并具备批处理能力,通过深度优化可运行针对其他平台编写的任务,提供低延迟的处理,但实际应用方面还为时过早。

    最适合的解决方案主要取决于待处理数据的状态,对处理所需时间的需求,以及希望得到的结果。具体是使用全功能解决方案或主要侧重于某种项目的解决方案,这个问题需要慎重权衡。随着逐渐成熟并被广泛接受,在评估任何新出现的创新型解决方案时都需要考虑类似的问题。

    展开全文
  • 一张图看明白金融数据架构

    千次阅读 2017-04-23 10:51:08
    金融机构将数据分为第一数据平面和第二数据平面,第一数据平面主要基于原有的金融IT平台,以交易为中心,支撑传统的金融数据处理与分析业务。第二数据平面则是以大数据平台为核心的信件数据平面,除妖处理金融数据...
  • 五个顶级的大数据架构

    千次阅读 2019-04-26 21:15:46
    自从像AWS这样的公共云产品开辟了大数据分析功能以来,小企业通过挖掘大量的数据做到只有大企业才能做到的事情,至今大约有10年时间。这些事情其中包括网络日志、客户购买记录等,并通过按使需付费的方式提供低成本...
  • 五种大数据处理架构

    万次阅读 多人点赞 2017-12-14 14:12:21
    大数据是收集、整理、处理大容量数据集,并从中获得见解所需的非传统战略和技术的总称。虽然处理数据所需的计算能力或存储容量早已超过一台计算机的上限,但这种计算类型的普遍性、规模,以及价值在最近几年才经历了...
  • 深度解密 5 类大数据架构及实现

    万次阅读 多人点赞 2020-04-25 17:40:58
    前几天读到白发川的一篇文章《对比解读五种主流大数据架构的数据分析能力》,文中详细总结了各类数据架构的应用以及原理。作为一名在数据仓库耕耘多年的技术人员,对于其中的一些技术细节还是破解兴趣的,所以随着...
  • 大数据架构设计用来处理对传统数据库系统而言太大或太复杂的数据的引入、处理和分析。组织进入大数据领域的门槛各不相同,具体取决于用户的权限及其工具的功能。对某些组织来说,大数据可能意味着数百个 GB 的数据,...
  • 微服务数据架构设计

    千次阅读 2018-03-19 12:42:30
    微服务开发中的数据架构设计前言微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和...
  • 一个运行了20多年的数据架构,必然有其合理性。也正是因为年代久远,存量过多,才导致举步维艰。在Cloud和5G时代,超密度网络集成和大数据洞察需求给电信供应商带来新的挑战,从数据仓库到数...
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...
  • 如何成为真正的数据架构

    千次阅读 2016-03-30 08:37:21
    1、为什么需要构建数据架构 数据标准不一致(列名相同数据类型不同、列明相同数据类型相同长度不一、列名没有统一标准识别困难、列名定义不统一类型不一致长度不相同、中文名称相同英文缩写不同或英文缩写相同...
  • 目录:一、航空业数据治理现状二、航空业大数据治理的三个发展趋势三、规划企业数据架构的两种模式四、规划企业数据架构的三个关键技术五、总结一、航空业数据治理现状目前航空行业数据治理已经逐步在开展起来,驱动...
  • 二、软件架构1、描述2、示例图三、总体架构1、描述2、示例图四、业务架构1、描述2、示例图五、应用架构1、描述2、示例图六、数据架构1、描述2、示例图七、技术架构1、描述2、示例图 八、物理架构 1、描述 2、示例...
  • 作者介绍刘庆会,主要负责普元大数据治理产品的实施,十年大型企业信息...声明:本文转自EAWorld(eaworld)公众号目录大纲:1、航空业数据治理现状2、航空业大数据治理的三个发展趋势3、规划企业数据架构的两种模式4
  • 微服务开发中的数据架构设计

    千次阅读 2018-03-18 23:08:04
    原文:微服务开发中的数据架构设计 关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术 【不要错过文末彩蛋】 前言 微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性...
  • 金蝶K/3 Cloud 开放数据架构模型

    千次阅读 2017-09-01 13:43:44
    金蝶K/3 CLOUD系统是一个开放性很强的ERP,给予了用户足够多的自定义...K/3 Cloud - 数据架构模型 - 基础 http://open.kingdee.com/k3cloud/PDM/BD.htm K/3 Cloud - 数据架构模型 - 财务 http://open.kingdee.
  • 在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜...
  • 从这篇文章开始偏实战,不同的架构(业务架构、应用架构、数据架构、技术架构),它们侧重点不一样,业务架构是 4 种架构之首,没有业务谈技术都是空谈。大部分书籍并没有深入讲如何去画业务架构图。 在这场 Chat 中...
1 2 3 4 5 ... 20
收藏数 1,216,150
精华内容 486,460
关键字:

数据架构