热点:

    干货满满 你想知道的关于云集技术学社的重点都在这儿

      [  品牌资讯   ]   作者:十一

           云集技术学社,大数据技术原理和发展趋势解析

           7月8日,深信服大数据负责人Letian在信服云《云集技术学社》系列直播课上进行了《大数据技术原理和发展趋势解析》的分享,对Hadoop、流处理、内存计算、检索、消息队列、大数据OLAP等技术进行了详细分析。以下是他的分享内容简要,想要了解更多可以点击http://sangfor.bizconf.cn/live/watch/technology/?id=mn1x3enl观看直播回放。

           看点一:什么是Hadoop?经典的Hadoop技术能做什么?

           Hadoop是大数据的经典技术,是一个开源的可运行于大规模集群上的分布式文件系统和运行处理框架。Hadoop擅长于在廉价机器搭建的集群上进行海量数据(结构化与半结构化)的存储与离线处理。


    Hadoop的核心是HDFS、Mapreduce和YARN

           (1)HDFS

           HDFS是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统,能检测和应对硬件故障,用于在低成本的通用硬件上运行。HDFS简化了文件的一致性模型,通过主从式的数据存储方式,为分析程序提供高吞吐量的数据访问能力,适合带有大型数据集的分析应用。

           (2)MapReduce

           MapReduce是一种计算模型,分为"Map(映射)"和"Reduce(归约)"两个部分。基于MapReduce和HDFS,Hadoop的生态生长出了HIVE和Hbase。其中,HIVE定义了一种类似SQL的查询语言(HQL),将SQL“转化为”MapReduce的任务执行。HIVE的特点是非常稳定,极大的数据量都能计算出结果,例如,长达几个小时甚至几天的离线分析就很适合采用HIVE。

           (3)Hbase

           Hbase是一种基于HDFS的NOSQL,它有稀疏表存储、LSM、二级索引等功能特点,更适合高并发读写访问、实时读写访问,例如推荐画像的标签存储与访问、时空数据(如行车轨迹)、消息/订单(话费详单查询)等场景,很适合运用Hbase。

           (4)YARN

           YARN是一个资源管理和调度工具,当大数据生态中越来越多类型的计算组件和计算任务类型出现,YARN通过双层调度机制,可以帮助系统管理多种类型组件的计算任务,从而把集群中的计算资源都管理起来,提升资源利用率。比如,在用户提交一个mapreduce计算job之后,多个Map和Reduce的任务就是分别运行在YARN分配的资源容器中。

           看点二:近年来常用的大数据生态技术有哪些?

           (1)Spark

           Spark是基于RDD实现的分布式计算框架,输出和结果保存在内存中,不需要频繁读写HDFS,因此比mapreduce的数据处理效率高。Spark扩展了Mapreduce的原语,除了map和reduce类型的任务之外,还有groupby、union等原语任务。Spark因为是内存计算,适用于“相对近线的或离线”的数据查询(通过sparksql或者原生接口)和实时监控场景(通过SparkStreaming)。另外,内存计算的特点也特别适合迭代计算的场景,例如图计算、机器学习场景。

           (2)Flink

           Flink是开源流处理框架,与SparkStreaming的区别在于,Spark是微批(一小批)地处理数据,而Flink则可以一条一条地处理数据。在运行时,Flink对实时数据的处理也被分为原语任务(map、keyby等),并将所有的原语任务分布到不同节点上进行并行处理。Flink适用于完全实时的数据分析与机器学习应用场景,例如医疗集成平台的CDC、反欺诈、异常检测、基于规则的报警、业务流程监控等等。

           (3)ElasticSearch(ES)

           ES是一个基于Lucene的搜索引擎,无论在开源还是专有领域,Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。ES实现了Lucene的分布式化:可以扩展到上百台服务器,处理PB级数据。当下不少商品搜索、APP搜索、知识库搜索、日志检索、地理位置查询等,都是使用ES实现的。

           (4)Kafka

           Kafka是一个分布式、高吞吐量、高扩展性的消息队列系统。在数据需要“总线”来分发给不同的消费者,或者数据产生很快,如果数据消费不够快,需要暂存的场景下,可以提升系统的效率。

           看点三:超火的大数据数据仓库与OLAP有哪些关键组件及特性?

           大数据数据仓库的主要功能是对大量的数据做系统的分析整理,以便于各种分析方法如联机分析处理(OLAP)、数据挖掘(DataMining)能够顺利进行,并进而支持如决策支持系统(DSS)、实时分析和查询系统等。

           (1)Presto

           HDFS、S3、HIVE、KUDU、cassandra、mongoDB、ES、Mysql...越来越多的存储架构,而且各有特点,难以舍弃,那我们能不能用一个引擎统一做查询计算,而不用使用不同的API呢?多源异构分析引擎Presto/Trino就可以解决这个问题。Presto是一款内存计算型的引擎,适用于交互式分析场景,同时其开源社区的良好集成,支持底层数据来自多种异构数据源的交互式分析场景,比如工程师的交互式查询分析、业务人员的交互式查询分析、ETL等。在很多时候,Presto只连接HDFS,那么它就变成了一个OLAP引擎,在这个场景下,Presto最大特点是性能均衡。Presto单表查询仅次于clickhouse,多表join查询性能也很突出。但值得注意的是,Presto虽然比HIVE快,但到了PB级数据时,Presto没办法把所有数据放在内存中处理。所以,需要边读数据、边计算、边清内存。join的时候,可能产生大量的临时数据,反而比HIVE慢。

           (2)ClickHouse(CK)

           ClickHouse(CK)是一个真正的列式数据库管理系统,主要解决的是“大宽表”的多维分析问题。在很多数据仓库的分析中,报表、交互式分析针对的目标表常常是一个大宽表(列很多),那是否能够把大宽表的性能做极致呢?CK因此应运而生。CK的存储模型MergeTree是最基础的表引擎,提供主键索引、数据分区和数据采样等所有的基本能力。其他能力,比如replace、sum等构建在之上。目前,CK主要应用于BI报表、用户行为分析系统、监控系统、A/Btest等场景下。

           (3)kylin

           kylin是一个开源的、分布式的分析型数据仓库。查询分析有一些是常用的指标,那能不能将这些指标结果提前计算好,这样一来,交互式查询分析时只查询预先计算好的结果,以此来达到亚秒级响应呢?预计算技术kylin就能实现。但需要注意,预计算计算技术可能会引发维度爆炸。如果一个表有N个维度的话,那么可能会产生2的N次方个预计算结果(类似2的N次方个物化视图),如果计算方式很多的话,那会更多,导致严重膨胀,这时候需要从源头上解决爆炸问题,比较好的方法是分析用户行为,进而只对有必要的结果进行预计算。

           看点四:大数据生态中,计算和存储模型的总结!

           本期直播也总结了不同的计算模型的优劣势,包括从计算视角的scatter/gather、mapreduce、MPP模型分类,从资源共享视角的shareeverthing、sharedisk、sharenothing的存储计算模型分类。

           云集技术学社|主流大数据架构及适用场景

           7月22日,深信服大数据负责人Letian在信服云《云集技术学社》系列直播课上进行了《主流大数据架构及适用场景》的分享,对典型大数据的分析场景进行了总结,归纳了大数据新架构及适用应用场景,从大数据开发的视角来分析大数据开发过程以及如何简化开发。以下是他分享内容摘要,想要了解更多可以点击http://sangfor.bizconf.cn/live/watch/technology/?id=m471p65m&time=1628846273488观看直播回放。

           看点一:大数据分析典型应用场景

           对于大部分用户来说,对大数据只有一个模糊的概念,不了解特别具象化的应用场景。数据分析是大数据的核心场景,依据对于分析效率和方式的不同,基本上可以分为批处理、交互式分析、实时分析、分析预测、智能决策等场景。

           大数据分析的主要应用场景有五个

           一是离线分析场景,应用于用户需要贴合业务形成的报表中,常见的是对静态数据的批处理。离线分析场景往往需要对于海量数据处理几个小时甚至几天才能得到贴合业务需求的结果报表。

           二是交互式分析场景,应用于仪表盘或自助分析。它的特点是表与表之间的关联关系不确定,分析维度不确定,查询度量不确定,通过即席查询满足秒级~分钟级的分析需求。

           三是实时分析场景,通常应用在交易风险预警、实时反欺诈、交易特征分析中,它的特点是表与表之间的关联关系确定,分析维度不确定,查询度量不确定,通过数据立方(Cube)技术提前预设数据模型,满足从既定的多层次多维度的亚秒~秒级的分析需求。

           四是流处理场景,流处理是指对如传感器信号、日志、时空轨迹、网购、交易等连续的、没有边界的、快速随时间不断变化的数据项(又称“流式数据“)进行过滤、转化、复杂逻辑等操作,主要应用在公安缉查布控、套牌车分析、互联网实时推荐系统中。

           五是综合检索,即从海量的结构化、半/非结构化数据中快速抓取到符合要求的信息。通常应用在站内搜索引擎、知识库以及高并发精准查询等通过关键字检索快速获得信息的使用场景中。

           看点二:大数据新架构及适用场景

           信息技术的发展催生了大数据新架构的不断升级迭代与创新,在本次课程中,Letian介绍了不同类型的大数据新架构及适用场景。

           (1)存算分离

            基于IO与CPU(含内存)的诉求可能出现不对等情况,人们意识到Hadoop发明之初强调存算融合,利用局部性让计算跟着数据跑的局部性原理带来的硬件节省,不如存储和计算分别扩容带来的节省硬件收益。对于企业而言,可以实现计算和存储按需灵活扩容,降本增效。一般来说,数据量超过300TB,且大数据服务器总数量超过20台时,用户可以考虑采用存算分离架构。当分析时延要求极低且不具备缓存/RDMA能力时则不考虑采用存算分离架构。

           (2)Lambda架构

           Lambda架构是一个实时大数据处理框架,通过BatchLayer和SpeedLayer的分层设计来实现在一个系统内同时支持流处理和批处理。

           Lambda(λ)架构的数据流采用基于不可变日志的分布式消息系统Kafka,数据进入Kafka后,一部分进行批处理,一部分进行流处理。批处理通常使用MR或Spark进行BatchView的预计算,BatchView自身结果数据的存储采用HBase(查询大量的历史结果数据)。SpeedLayer(流处理)增量数据的处理可选用Flink,RealtimeView增量结果数据集为了满足实时更新的效率,选用Redis。Lambda架构满足了高容错、低延时和可扩展等实时数据处理需求。

           (3)批流融合

           除了Lambda架构这种批流分离的架构外,批流融合也是十分流行的架构。批流融合支持ACID的upsert、delete、insert等可以实现流处理和批处理一体,确保统一的原始视图(ODS),数据直接进入大数据数仓,计算口径统一。批流融合不再采用消息队列,其作用可以被流引擎部分替换,可以内部自动合并小文件,对上屏蔽小文件的处理复杂性,还可以让用户查询给定时间点的快照或回滚错误更新到之前正确的数据。

           (4)实时数仓

           据Gartner统计实时数据规模在未来三年内会达到25%,数据规模高速增长带来了强劲的数据分析需求,由此实时数仓应运而生,它可以进行内存级、细粒度的实时预计算。将cube的构建分为内存部分和磁盘部分,磁盘部分对应于传统的预计算,内存部分对应于实时场景。在实时预计算系统中,用户预先设置好需要在线分析的统计方法(度量及指标)。对实时产生的数据,实时数仓以极细的时间粒度(segment)进行计算和汇总;实时数仓收到用户查询请求(query)时,如果计算结果处于内存中(realtime-node)中,则直接从内存中获取结果。实时数仓广泛应用于用户画像分析、点击流分析、网络流量分析等场景中。

           (5)数据湖

           企业在持续发展,企业的数据也不断堆积,在数据存储层面上,“含金量”最高的数据已经存在数据库和数仓里,支撑着企业的运转。但是,企业希望把生产经营中的所有相关数据,历史的、实时的,在线的、离线的,内部的、外部的,结构化的、非结构化的,都能完整保存下来,方便未来“沙中淘金”。因此,数据湖诞生,它由数据存储架构、数据管理工具、数据探索和开发工具三要素构建。

           (6)湖仓一体方案

           数据湖起步成本很低,但随着数据体量增大,TCO成本会加速飙升,数仓则恰恰相反,前期建设要小心地处理数据,开支很大。一个后期成本高,一个前期成本高,对于既想修湖、又想建仓的用户来说,既然都是拿数据为业务服务,数据湖和数仓作为两大“数据集散地”,能不能彼此整合一下?于是数仓一体方案出现,让一套架构里面具备数据湖灵活性,兼有数据仓库的成长性。

           看点三:如何简化大数据的开发

           大数据的开发过程受工具及开发流程的影响,开发团队的使用门槛高,上手难度大。对于项目交付而言,一是大数据分析的定制需求多,需要专业团队才能交付;二是实施阶段问题多,全阶段都需要研发投入;三是项目成本中大数据占比高,验证阶段压力大。这三重问题使得项目交付的成本高。其次,大数据复杂的架构就意味着技术栈复杂,寻找复合型人才难度大,人力成本高。由此可见,大数据的开发亟需降本增效,那么如何简化大数据的开发,提高研发人员的开发效率呢? Letian给出了如下建议:

           一、通过外部工具将可视化展示内迁应用到大数据上。可视化是大数据分析的最后环节,针对离线分析场景可以通过配置SQL/SPL编写图/表的代码,或者选择预置的图或表模板实现从立方体到交叉表(中国式复杂报表)的展示。针对交互式分析场景可以通过敏捷BI(Tableau、Kibana-Lens)进行拖拽实时自动地生成图或表实现交互式分析可视化展示。

           二、通过数仓开发工具简化流程。数仓开发是大数据开发的主要场景,针对数仓开发可以通过工具或者可视化平台减少需要反复的过程。在数据进行清洗后,数仓可以进入可视化平台开发免除繁琐的代码编写,在原始数据中加载数据可以有可视化操作,通过拖拽构建数仓模型,从中提取指标并设置加速机制自动进行预计算,设置上线定时周期脚本让模型在固定时间关联、运行、验证。

           三、流计算开发工具。在流处理场景中,可以通过可视化工具进行辅助开发。通过可视化开发画布,进行数据来源配置、触发条件配置和数据目的配置,省去流计算中的代码编写。

           四、调度开发工具。大数据的开发需要不同代码的编写,各个代码之间可以通过可视化调度开发工具实现管理、调度和依赖关系的处置。

           云集技术学社:数据库概念、分类和未来

           8月5日,深信服首席算法技术专家章博在信服云《云集技术学社》系列直播课上进行了《数据库概念、分类和未来》的分享,对数据库基础概念、常见数据库种类和使用场景进行介绍,详细解释不同数据架构的优劣,破除常见误区。

           看点一:数据库是什么?

           数据库定义

           大家可能对数据库这个词都不陌生,我们最常说的数据库,也就是Database这个词,原则上它指的是按照一定格式存储数据的文件的组合,也就是说硬盘上的数据库的文件和数据,要按照某种特定的格式去组织,这个就是所谓的数据库。

           为了去使用数据库,我们一般需要一整套的数据库管理系统,也就是Database Management System(DBMS),即科学的对数据库文件进行组织、索引、查询、修改的一套管理软件,常见的数据库管理系统有MySQL、Oracle、SQLServer、DB2等。

           但是仅仅DBMS本身并不能提供各种各样的能力,我们还需要围绕DBMS去构造由硬件操作系统、数据库管理系统,乃至包括数据库管理员以及相关的机制配套组成的一整套数据库系统,才能顺利的执行工作。这一套系统一般称之为DatabaseSystem。

           与常见的数据管理软件Excel相比,数据库会管理一些更大量的数据,比如说千万行以上的甚至亿万行以上的数据。一般Excel是单人使用的,数据库是很多的用户同时使用,而且可以进行高并发的访问。此外,数据库也有更丰富更复杂的数据处理能力,在安全机制的保障上,Excel作为一个办公软件只能提供密码的基础管理能力,而数据库能够提供完整的安全机制,比如说像是权限的校验(表级别的、行级别的、列级别的权限控制),以及我们可以做一些数据备份来更好的保证数据的安全,这就是数据库管理系统一个主要的好处。

           数据库的四个重要概念

           (1)索引

           数据库经常有上百/千万条记录,单条查询会很慢,而索引的功能就像新华字典的前几页“索引”目录靠拼音或偏旁排序来查询字词,能大幅度提高查询速度。

           (2)事务

           数据库提供了一种机制,就是一件事,必须做完,如果中间出了差错,他会清理掉一切痕迹,回到最初状态,这对于保持数据的一致性和完整性有功不可没的作用。

           (3)联合查询

           一份数据通常解决不了实际问题。比如有两份数据,一份是《员工基本信息》,另一份是《工资表》,这个时候,要查询某某员工的工资,就要结合起来做“联合查询”。

           (4)SQL

           SQL就是用来操作数据库里数据的工具,类似吃饭时使用“筷子”获取食物。

           看点二:数据库的分类

           数据库可以分为三个维度来分类:第一个维度是按照模型分类,可以分为关系型和非关系型的数据库。第二个维度是根据数据库的使用场景进行分类,主要分为事务性OLTP和分析型OLAP两类。第三种是从数据库架构进行分类,可以分为单点数据库和数据库集群。

           按模型分类

           按照模型划分,一般把数据库分成关系型和非关系型两个类型。关系型模型由于其优秀的表达能力、严格的数学定义和良好的执行效率被广泛采用,而采用关系型模型组织数据的数据库就被称之为关系型数据库,如Oracle,MySQL等。关系型数据库也成为了现在最主流的数据库模型。

           而在一个关系型的数据模型上,提供的查询语言就是结构化查询语言(Structured Query Language)。这样的语言是整个数据库现在能蓬勃发展的一个关键所在,因为它是高级的非过程化的编程语言,比如常见的C语言或者Python编程语言,它都是所谓的过程化编程语言,当需要它做什么的时候,需要一步一步把过程的每一个阶段全部编写好,才能够顺利的进行。但SQL是一个高级的非过程化语言,只需要用户描述需要取得什么样的数据,具体的执行流程就由优化器由甚至系统自动去完成了。所以整个SQL语言的学习和使用非常简单,用户不需要了解具体的数据组织和处理的细节,也不需要去了解如何能让它高效的执行,所有的事情全部都是自动的。

           非关系型数据库是通过关系型以外的数据模型对数据进行组织的数据库,通常在特定场景下具有较高的性能和可扩展性。典型NoSQL数据库有:(1)键指数据库:Redis、Memcache——常用于缓存;(2)列族数据库:HBase,Cassandra——常用于Schema频繁变更的大宽表数据;(3)文档数据库:MongoDB—— 常用于存储JSON文件;(4)图数据库:Neo4j——常用于知识图谱等图数据组织。

           按场景分类

           数据库还可以按照不同场景进行分类,主要的两个场景是OLTP和OLAP。OLTP是比较常见的业务系统,比如银行的交易系统、零售交易系统、企业中的ERP系统、医疗的CASE系统等。这些数据库系统里面的数据基本上都是OLTP类型的,支持实时交易数据的存储、更新、共享。

           这类系统下,数据不断发生,不断更新,可能有很多人在同时去访问,因此需要的并发也比较高,每次更新都希望反馈的延迟非常低,比如说毫秒级的场景,就是OLTP的场景。

           OLAP与我们主要做数据分析和现在的所谓的大数据,也有很多的相似之处,比如BI系统或者说建设数据仓库,会把很多的历史数据汇聚过来,然后做一些综合的分析,希望从中提取一些数据规律,或者做一些数据挖掘。这一类的需求基本上对数据没有很大频繁的修改,但是一次要访问的数据量非常的大,所以不太看重系统的延期,但很看重数据库的吞吐。这样的场景其实就是OLAP场景下常见的数据库。

           按架构分类

           数据库也可以按照不同架构进行分类。常见的数据库是单节点的数据库,因为单节点可能有一些单点故障的问题。如果有更大的数据量的需求,单节点的数据库没有办法承载,或者需要更大的并发,而此时单点数据库也没有办法承载。这个时候在单节点基础上就发展了一系列的数据库集群架构。

           数据库集群架构主要分成三类模式,第一个需要更高的可用性,比如基于组成复制的数据库集群架构或者基于一致性协议的多活数据库集群。基于复制的数据库集群是最常用的多节点数据库架构,它能够消除单点故障,同时通过读写分离提升性能。基于一致性协议的多活数据库集群则是无需第三方仲裁,自维护的多活集群架构,它可以在多数派存活条件下可提供服务。

           第二个是很多时候在高可用的情况下,遇到面临单节点的数据库性能不够、并发不够的问题,这个时候就需要横向扩展技术。最经典的横向扩展技术就是基于Shared Disk的数据库集群,它是基于SharedDisk的共享存储,然后上面可能会有多个节点来共同执行数据库操作的OracleRAC 的经典架构。它的特点是存储计算分离,通过高速网络和分布式存储替换传统阵列来提升性能。

           但基于SharedDisk的数据库集群的扩展能力存在限制,难以扩展到百节点以上的超大规模集群,因此就有了基于Share-Nothing的数据库集群。它的每个节点独立,具有最强的扩展能力,可扩展至数百甚至数千节点规模。能支持超大规模并发的基于Share-Nothing数据库集群一般以更高和更不稳定的时延为代价,但是由于和SharedDisk并非完全互斥关系,Share-Nothing集群的每一个节点本身可以是一个SharedDisk 多活集群,从而可以结合两种架构的优势。

           OLTP场景下的Share-Nothing分布式数据库虽然数据是分布式存储和管理的但是单一 SQL语句的执行大多还是由单一节点执行。相对的,第三类架构就是在OLAP场景下我们需要更大的吞吐时,计算也需要多个节点进行分布式处理,这一架构被称之为MPP(Massively Parallel Processing)。

           看点三:数据库发展趋势

           李国良教授的《数据库发展趋势》中介绍,新一代的数据库其实有4个主要的发展方向,一是随着硬件的发展有更多的新的硬件技术被利用下来;二是随着数据模型的发展,会支撑更多的数据模型;三是Scalability进一步提升,最后还有Deployment的种类会变得更加的丰富。

           针对种类更加丰富的发展趋势,章博在此介绍了几个比较广泛认知的数据库。一个是现在常见的一个词叫做HTAP,就是既要有TP的特性,又要有AP的特性。在传统的架构下,一般通过ETL把TP的数据按照天或者周的周期去导入到一个AP的系统,用两个不同的系统去承载它,但是传统架构的时效性不足。当需要实时分析时,HTAP就派上用场了,HTAP通过复制或者在同一个引擎里同时做行列混合存储,既能支持实时的数据更新,又可以支持比较高的数据吞吐。但是HTAP系统不会用来去直接替代TP系统,一般来说它还是更偏向用于实时分析的补充。

           AI也是非常火热的一个词,在数据库领域的话就有两大的分支,一个是AI4DB,就是如何使用AI技术让数据库的可维护性变得更强。另外一个是DB4AI,DB4AI就是如何对AI的数据进行管理,通过一个很完善的数据库管理系统管理AI的数据,让AI的开发和迭代更有效。

           最后,这几年新的硬件技术发展得也非常的快,对整个数据库系统的优化起着非常大的效果。一个是利用IntelSPDK将NVMESSD性能发挥到极限,另一个是支持RDMA高速网络。

           本期回放链接:http://sangfor.bizconf.cn/live/watch/?id=oygey64o

    cloud.zol.com.cn true https://cloud.zol.com.cn/774/7746219.html report 19590    云集技术学社,大数据技术原理和发展趋势解析   7月8日,深信服大数据负责人Letian在信服云《云集技术学社》系列直播课上进行了《大数据技术原理和发展趋势解析》的分享,对Hadoop、流处理、内存计算、检索、消息队列、大数据OLAP等技...
    • 猜你喜欢
    • 最新
    • 精选
    • 相关
    推荐经销商
    投诉欺诈商家: 010-83417888-9185
    • 北京
    • 上海
    周关注排行榜
    • 产品
    • 品牌
    推荐问答
    提问
    0

    下载ZOL APP
    秒看最新热品

    内容纠错