大数据技术体系

2020/12/28

1.基础技术

基础技术是大数据技术的基石,主要要考虑两个大的问题:怎么提高性能?以及怎么保证数据可靠性?

提升性能最主要的方式是数据分片,让每个分片独立的计算,需要查询的时候可以路由到指定的分片,这样可以发挥分布式的优势。

保证数据可靠性的方式就是将同一份数据存储多个副本,并且分布在不同的机器上,这样当一台机器出现故障甚至损坏,数据也可以从其他副本恢复,不过数据复制本身的实现非常的复杂,需要考虑如何复制以及如何保证复制的一致性、实时性、更新策略等各种问题,比如一致性则需要考虑到使用不同的一致性模型来实现。

当然除了上面的数据分片和可靠性之外,尽量将单机性能压缩要极致也是需要考虑的,这样就需要采用尽可能高效的数据结构和算法,实现单个节点效率的最大化,从而提升整个集群的性能。

2.数据采集

数据采集可以有日志系统采集、网络数据采集以及硬件设备数据采集等,对于日志系统的采集可以采用系统埋点发送日志的方式主动推送,也可以使用数据采集框架,比如:Flume,Logstash等;如果是网络数据,则优先采用公开的API调用来采集,如果没有API可能需要爬虫的方式来采集;设备数据采集主要针对一些带有传感器的物理设备,这种一般会有专门的SDK用于采集。

3.数据传输

数据传输可以分为:实时大规模的数据传输、定时批量的数据传输。

对于实时大规模的数据传输,采用的常见方式就是消息队列,例如: Kafka、RocketMQ等,主要用来实现应用解耦、异步以及流量削峰等应用,并且很容易实现高可用、高伸缩的架构。

对于定时批量的数据传输,也叫作数据同步,比如从原始数据(ODS)的数据库中,比如MySQL、Oracle等业务数据库,批量加载数据,然后同步到大数据的平台,比如数据仓库中,这中间可能涉及到大批量数据加载、数据的转换,数据的存储,可能需要借助一些批量计算的框架进行,同时需要考虑数据的准确、可靠等内容。

序列化:数据传输的基础就是数据序列化,需要将对象序列化为字节流才可以真正的在网络中进行通信,如何高效的序列化、反序列化、传输等都是需要考虑的性能点。

4.数据存储

大数据存储主要针对于:海量、异构、结构化和非结构化等数据提供高性能、高可靠的存储以及访问能力,一方面可以解决大数据量的存储和高吞吐的访问,另一方面要支撑大规模数据分析、计算的平台。

4.1 物理存储

对于物理计算机,最主要的是内置存储比如:CPU寄存器、L1/L2/L3 cache、RAM等,内置存储的速度非常快,但是容量非常小,并且有易失性,因此计算机都会将操作系统、程序、文件等保存到硬盘,需要使用时会加载到内存,硬盘这类存储就属于外挂存储,特点是容量大、断电不丢失,但是缺点是速度慢,外挂存储又分为:直连式存储(DAS)、网络化存储(FAS),直连式存储就是直接插到计算机上面的存储设备,比如常见的SSD,机械硬盘等,网络存储是通过网络的方式共享的存储,又可以分为:网络接入存储(NAS)、存储区域网络(SAN),比如iSCSI这种块设备存储就属于SAN的范畴。

针对不同场景,往往选择不同的分布式存储方案,常见的存储类型有:文件存储、块存储、对象存储这三类。

文件存储:比如上面说的NAS,另外还有NFS、SMB、FTP等服务都属于文件存储。

块存储:最简单的就是本地磁盘设备、磁盘阵列这些属于DAS,另外还有SAN,比如iSCSI等。

对象存储:物理存储中暂时没有对象存储。

4.2 分布式存储系统

常见的分布式存储系统有:HDFS、OpenStack Swift、Ceph、GlusterFS、Ozone等,其中比如HDFS、GlusterFS属于文件存储,Swift和Ozone就属于对象存储,Ceph则兼具3类存储的能力。

4.3 分布式数据库

除了分布式文件存储系统之外,很大的一部分就是数据库,有的数据库依赖外部的存储系统,但有的数据库本身具有存储功能,数据库最大的特点是本身具有对数据库检索和分析的能力,根据应用的场景不同,又可以进一步细分:

4.3.1 分布式关系型数据库

这类数据库可以非常好的弥补单机的关系数据库不足,同时分布式关系型数据库完全支持单机数据库的所有特性,并且提供的充分的水平扩展和容错能力,常见的分布式关系型数据库有:TiDB、Greenplum等,另外还有阿里云的PolarDB,这类数据库主要解决单机业务数据库的瓶颈问题,主要用在OLTP场景。

4.3.2 分析型数据库

分析型数据库主要面向OLAP(分析应用)的数据库,可以对数据进行在线的复杂分析、即席查询等挖掘类型的业务,是数据库领域中很大的一个分支,比较流行的分析数据库有:Kylin、Druid、Clickhouse、Vertica、Doris,另外还有阿里云的AnalyticDB。

4.3.3 搜索引擎

搜索引擎可以支持海量数据的精确和全文检索等,并且提供分布式、高性能、高可用的搜索分析系统,常见的搜索引擎平台有:ElasticSearch、Solr,其中ElasticSearch应用比较多。

4.3.4 文档数据库

文档型数据库是NoSQL中的一个重要分支,主要用来存储、索引面向文档类型的数据或半结构化数据,目前业界比较流行的文档型数据库有:MongoDB、CouchDB、ArangoDB(文档模型)。

4.3.5 列式存储数据库

列式数据库是以列为存储架构进行数据存储的数据库,主要用于批量数据处理和查询,适合大批量数据的联机事务和统计分析等,常见的列式数据库有:Phoenix、Cassandra、Hbase、Kudu、ScyllaDB等,其实上面分析型数据库也有一些是列式存储的架构,并不是孤立的,只是应用场景不大相同。

4.3.6 图数据库

图数据库也属于NoSQL,是将图形理论应用到实体和关系信息存储当中,图数据库主要实现的就是图这种数据结构的存储、查询、图算法等,要素就是顶点和边,有些图数据库也可以处理键值对,图数据库就是解决复杂关系的计算和存储问题,常见的图数据库有:Neo4J、ArangoDB、OrientDB等。

4.3.7 键值数据库

这个是最简单也是应用最多的数据库,常见的键值数据库性能都特别高,比如:Redis、Memcached、rocksdb、leveldb、TiKV、腾讯的Tendis。

5.数据计算

5.1 流式计算(Streaming compute)

流式计算是利用分布式的思想和方法,对海量源源不断的“流”式数据进行实时处理,流式计算更加强调计算的对象是数据流和低时延,流式数据其实就是一种不断增长,无限的数据集。流式计算我们有时候又叫做实时计算,其实并不完全一样,共同点是流式计算和实时计算都要求低延时,但是从对象来说流式计算的对象是无限流,但是实时计算的对象不一定是数据流,有可能是批量数据,交互式查询等各种形式。

常见的流式计算框架有:Flink、Spark Streaming、Storm、Kafka streams,其中目前flink的社区最为活跃,支持流批一体,功能强大,是流计算框架的首选,如果是spark生态可以使用spark streaming。

5.2 批量计算(Batch compute)

批量计算是对已经存储好的静态数据进行大规模批处理的计算,批量计算强调的是规模大、并行化、时延相对高,计算是主动以任务或作业形式发起的,批量计算我们有时候又叫做离线计算,其实同样不等价,离线计算更多的是强调计算的特征是非实时,包括计算和生成结果等都是非实时的,而批量计算重点是任务的输入是批量的数据集,数据的生成和读取是非绑定的,各自环节可以单独完成,如果硬件水平非常好,那么批量计算同样可以做到时延非常低。

常见的批量计算框架有:MapReduce、Hive、Spark等,目前Spark由于内存计算的特性应用比较活跃。


其实从上面看,数据处理有两大门派,分别是:流式计算和批量计算,这两个概念是基于技术或者数据类型本身的概念,而实时计算和离线计算更多的是根据需要,强调时延的高低,内容反馈的及时性,其中并不涉及到数据本身的规模。因此流式计算和批量计算更多的是在大数据分析场景,而实时计算和离线计算更多的是通用的计算场景。

5.3 即席查询(Ad Hoc)

即席查询就是用户可以根据业务的需求,非常灵活的选择查询的条件,系统根据条件进行快速的查询和分析并返回结果,即席查询的分析模式兼具了良好的时效性和灵活性,是对流式计算和批量计算的一种很好的补充,和批量计算比起来,即席查询更加便捷,具有交互式,因此我们也常把即席查询叫做交互式分析。

常见的即席查询框架有:Impala、Presto、Drill等。

5.4 图计算

图计算是一种针对特殊数据结构 - 图数据的计算类型,数据本身一般是以大规模图或网络的形式呈现的,比如社交网络、病毒传播途径、路网数据等,经常会转换成图这种模型后进行计算分析,图数据非常好的表达的数据之前的关联性,要处理巨大的图数据,也需要大规模的集群采取并行方式计算。

常见的图计算框架:Google Pregel、Spark GraphX、GraphChi、Apache Giraph等,另外图数据库也承担了很多图计算的功能,这里的图计算框架往往是仅仅对于输入进行计算,而不强调具体的存储。



其实数据存储部分的数据库和数据计算也有很多共同的部分,甚至是可交换的,同样数据计算重点强调的是计算本身,而很多分析型的数据库本身就具有比较强的计算能力,比如Druid、Clickhouse、Impala、Presto、SparkSQL这些引擎本身都可以实现大规模的计算和分析,通常虽细分的领域不同,但在架构设计中往往是你中有我我中有你。

比如在中小型的灵活业务分析中,为了减少部署成本我们可以选择TiDB或Doris作为数据库,成本低、灵活性高、反馈快,非常方便的用于各类业务查询和分析;但针对大型业务中,就要求我们具备很强的调优能力对TiDB或Doris设计索引指标或根据业务对数据表拆分或调优来提高性能,随着业务的增大,比如到200亿以上级别的数据,而且数据维度特别高,并发也非常大的时候,就不适合继续使用TiDB或者Doris了,这时候可以选择:Druid、Clickhouse、Impala、Presto、Kylin、SparkSQL等平台,Presto相对于Impala查询SQL支持更好,灵活性更高,而且支持的数据源也更丰富,但是性能上要比Impala低一些,如果需要丰富的支持可以选择Presto,但是如果要求支持高并发,高性能的复杂SQL查询那么可以选择Impala,对于预先设计好的维度的查询可以选用Kylin,如果是对海量数据大宽表的聚合分析,当然首选Druid或Clickhouse,都可以实现很高的性能,但是并发支持不如Impala高,只是单次计算的响应时效非常好,如果是Hadoop生态可以选用Druid,其他情况可以选择Clickhouse,如果是大规模的批量分析,计算复杂但是时效性要求不太高的情况下,可以选用SparkSQL。当然上面这些选项只是一个大概的方向,具体还要做充分的调研、调试之后再做最终选型,选择最适合目前业务和未来一段时间增长需求的平台。

7.数据仓库

和数据库相比,数据仓库重点在于大规模数据的摄取、管理和分析,正常来说数据库的设计要求结构紧凑,尽量省空间,冗余尽量少,读写优化,查询尽量落在比较少的数据上而提高性能,适合高并发,频繁的查询下能快速响应,而数据仓库重点是表格结构大而全,设计简单,存储冗余而且松散,一般只是对批量数据读取做优化,而且支持单次复杂的查询,作用在大规模的历史数据上,因此单次分析时间较长,查询都是任务型的,不会特别频繁,所以数据仓库看起来和OLAP分析型数据库很像,但OLAP数据库仍然强调时效性和大量表设计的优化,这点和数据仓库不同,数据仓库看起来更像是摄取各类原始数据然后存储起来,提供其他二次分析数据源的地方,对企业来说是一个统一的数据管理中心,因此在数据仓库基础上又诞生出数据湖的概念。

常见的数据仓库有:Hive、Pig、Apache Hudi等,目前已经有企业基于Hudi构建自己的数据湖。

8.分布式协调系统

大规模分布式系统中各节点之间需要任务协调,才能有效实现分工,例如系统扩容添加节点,我们怎么从原集群中获取配置?当机器状态改变时,如何通知集群中其他节点?当master发生故障时,如果从其他备用节点选举新的master并完成故障切换?以上这些常见的分布式系统中的问题,都需要分布式协调系统来辅助完成,很多组件内置了分布式协调系统,也有很多组件使用第三方的分布式协调系统,但是本质上实现的目标都是类似的,分布式协调系统主要提供:统一命名服务,状态一致性服务,集群配置信息保存和管理等服务。

常见的第三方分布式协调系统有:zookeeper、Eureka、Consul,另外还可以使用Etcd,Redis等间接实现分布式协调。

9.集群资源管理和调度

资源管理主要应对的是多任务、多租户的情况,可以让计算更具弹性,给每个任务或者用户限定CPU、内存、网络等物理资源,实现资源隔离和多任务的调度。

除了常见的虚拟化或容器化的资源隔离方案外,常用的大数据系统资源管理系统有:Google Omega和Borg、Yarn、Mesos。

另外值得一提的是,3个著名的资源管理的平台:Omega,Borg,Kubernetes都是Google研发出来的,这3个容器管理系统,分别对应3个不同的工程师对应不同的体系,按照时间线依次为:Borg->Omega->Kubernetes,期间经过不断的改进和延伸,目前Kubernetes已经非常流行,Google在这方面一直是走在最前沿的。

除了集群资源调度的平台外,还有一些常见的监控界面系统,方便部署或运维,比如:Ambari、Cloudera Manager、Hue等。

10.工作流和任务管理引擎

目前随着业务不断复杂,大数据的任务量也不断增加,多个任务经常是同时执行并且需要有各种复杂的依赖关系,因此就会涉及到工作流管理的问题,首先对于工作流会抽象为有向无环图(DAG),然后依次将任务构建成DAG然后进行管理,对于开发人员说只需要关注某一个具体的任务即可,而不用考虑复杂的依赖关系。

常见的工作流管理平台有:Oozie、Azkaban、Airflow等。