⼤数据架构
⼤数据架构，如下图：
1、通过ETL⼯具将数据源抽取到HDFS存储；
2、通过Hive清洗、处理和计算原始数据；
3、Hive清洗处理后的结果，如果是⾯向海量数据随机查询场景的可存⼊Hbase; 4、数据应⽤从HBase查询数据；
⼤数据架构实例1，如下图：
聚醚类消泡剂⼤数据架构实例2，如下图：
⼤数据架构实例3，如下图：
⼤数据架构实例4，如下图：
⼤数据架构实例5：
⼤数据架构实例6：
⼀、场景
1.数据源主要为 Mysql，希望实时同步 Mysql 数据到⼤数据集中（肯定是越快越好）。
2⽬前每⽇ 20 亿数据，可预见的⼀段时间后的规模是 100 亿每⽇以上。
管道内衬
3.能快速地查到最新的数据，这⾥包含两部分含义：从 Mysql 到⼤数据集的速度快、从⼤数据集中查询的速度要快。
⼆、⽅案选型
遇到这个场景的时候，根据经验我们主要考虑下⾯两个点：数据抽取引擎和存储引擎。
数据抽取引擎
这⾥我们主要考虑两种⽅案：
1.Sqoop 定时抽取 Mysql 数据到 HDFS 中，可以每天全量抽取⼀份，也可以隔段时间就抽取⼀份变更的数据。
2.Canal 监听 Mysql 的 binlog ⽇志，相当于是 Mysql 有⼀条数据久变动，我们就抽取⼀条数据过来。
优缺点的对⽐也很明显：
1.Sqoop 相对⽐较通⽤⼀些，不管是 Mysql 还是 PostgreSql都可以⽤，⽽且很成熟。但是实时性较差，每次相当于是启动⼀个 MR 的任务。
2.Canal 速度很快，但是只能监听 Mysql 的⽇志。
存储引擎
存储引擎主要考虑 HDFS、Hbase 和 ES。
⼀般情况下，HDFS 我们尽量都会保存⼀份。主要纠结的就是 Hbase 和 ES。本来最初是想⽤ Hbase
来作为实时查询的，但是由于考虑到会有实时检索的需求，就暂定为ES
三、⽅案设计
最终，我们使⽤了下⾯的⽅案。
1.使⽤ Canal 来实时监听 Mysql 的数据变动
2.使⽤ Kafka 作为消息中间件，主要是为了屏蔽数据源的各种变动。⽐如以后即使⽤ Flume 了，我们架构也不⽤⼤变
3.数据落地，有⼀份都会落地 HDFS，这⾥使⽤ Spark Streaming，算是准实时落地，⽽且⽅便加⼊处理逻辑。在 落地 ES 的时候可以使⽤ Spark Streaming，也可以使⽤ Logstach，这个影响不⼤
Hive和Hbase
Hive主要解决海量数据的清洗、处理和计算的问题。严格来说Hive不是数据库，它通过元数据来描述
Hdfs上的结构化⽂本数据，就是定义⼀张表来描述HDFS上的结构化⽂本，包括各列数据名称、数据类型等，⽅便处理数据。当前很多SQL ON Hadoop的计算引擎均⽤的是hive元数据，如Spark SQL、Impala。
Hive会将SQL翻译为Mapreduce来处理数据，适⽤于离线的批量数据计算，但仅限于查和分析，⽽不是更新、增加和删除。它的底层是MapReduce，MapReduce在实时计算上性能很差。它的做法是把数据⽂件加载进来作为⼀个hive内部表或者外部表，让你觉得你的sql操作的是传统的表。但Hive使⽤load data操作的时候，不管是外部表还是内部表，如果源数据存在于HDFS层，都是数据的移动，即源数据从HDFS存储路径移动到Hive数据仓库默认路径。
Hadoop是hive和hbase的基础，hive依赖hadoop，⽽hbase仅依赖hadoop的hdfs模块。
Hive适⽤于离线数据的分析，操作的是通⽤格式的（如通⽤的⽇志⽂件）、被hadoop管理的数据⽂件，它⽀持类sql，⽐编写MapReduce 的java代码来的更加⽅便，它的定位是数据仓库，存储和分析历史数据
hbase适⽤于实时计算，采⽤列式结构的nosql，操作的是⾃⼰⽣成的特殊格式的HFile、被hadoop管理的数据⽂件，它的定位是数据库，或者叫DBMS
Hive可以直接操作hdfs中的⽂件作为它的表的数据，也可以使⽤hbase数据库作为它的表.
8ggggHbase主要⽤于海量明细数据（⼗亿、百亿）的随机实时查询的问题，如⽇志明细、交易清单、轨迹⾏为等。
Hbase基于hdfs实现对分布式数据⽂件的管理，⽐如增删改查。也就是说，hbase只是利⽤hadoop的hdfs帮助其管理数据的持久化⽂件（HFile），它跟MapReduce没任何关系。hbase的优势在于实时计算，所有实时数据都直接存⼊hbase中，客户端通过API直接访问hbase，实现实时计算。由于它使⽤的是nosql，或者说是列式结构，从⽽提⾼了查性能，使其能运⽤于⼤数据场景，这是它跟MapReduce的区别。
在Hbase中⽇志即数据，数据就是⽇志，他们是⼀体化的。为什么这么说了，因为Hbase的更新时插⼊⼀⾏，删除也是插⼊⼀⾏，然后打上删除标记，则不就是⽇志吗？
在Hbase中，有Memory Store，还有Store File，其实每个Memory Store和每个Store File就是对每个列族附加上⼀个B+树(有点像Oracle的索引组织表，数据和索引是⼀体化的)， 也就是图的下⾯是列族，上⾯是B+树，当进⾏数据的查询时，⾸先会在内存中memory store的B+树中查，如果不到，再到Store File中去。
如果的⾏的数据分散在好⼏个列族中，那怎么把⾏的数据全呢？那就需要好⼏个B+树，这样效率就⽐较低了。所以尽量让每次insert的⼀⾏的列族都是稀疏的，只在某⼀个列族上有值，其他列族没
有值，
⼀，索引不同造成⾏为的差异。Hbase只能建⽴⼀个主键索引，⽽且之后的数据查询也只能基于该索引进⾏简单的key-value查询；但是Oracle可以建⽴任意索引，也可以按照任意列进⾏数据查询。
⼆，Hbase适合⼤量插⼊同时⼜有读的情况，读⼀般为key-value查询⼤数据、⾼并发正合Hbase的胃⼝
三，Hbase的瓶颈是硬盘传输速度，Oracle的瓶颈是硬盘寻道时间。Hbase都是⼤量往硬盘上写数据（没有delete、update，都是insert），即使是读数据，也是优先MemStore，所以硬盘传输速度成为其瓶颈；⽽Oracle由于具有随机访问特性（select、update 等），所以硬盘寻道时间成为其瓶颈，⽽寻道时间主要由转速决定。
四，Hbase很适合寻按照时间排序top n的场景。Hbase数据都具有时间戳（Hbase默认就有时间戳）
五Hbase的优缺点：
1 列的可以动态增加，并且列为空就不存储数据，节省存储空间.
2 Hbase⾃动切分数据，使得数据存储⾃动具有⽔平scalability.
4 不能⽀持条件查询，只⽀持按照Row key来查询.
5 暂时不能⽀持Master server的故障切换，当Master宕机后，整个存储系统就会挂掉.
6另外，由于在Hbase中，同⼀个列⾥⾯数据格式⽐较接近，或者长度相近，从⽽可以对数据进⾏⼤幅度的压缩，结果就是节省了硬盘空间，也减少了IO。
1.数据类型，HBase只有简单的字符类型，所有的类型都是交由⽤户⾃⼰处理，它只保存字符串。⽽关系数据库有丰富的类型和存储⽅式。
2.数据操作：HBase只有很简单的插⼊、查询、删除、清空等操作，表和表之间是分离的，没有复杂的表和表之间的关系，⽽传统数据库通常有各式各样的函数和连接操作。
3.存储模式：HBase是基于列存储的，每个列族都由⼏个⽂件保存，不同的列族的⽂件时分离的。⽽传统的关系型数据库是基于表格结构和⾏模式保存的
4.数据维护，HBase的更新操作不应该叫更新，它实际上是插⼊了新的数据，⽽传统数据库是替换修改
5.可伸缩性，Hbase这类分布式数据库就是为了这个⽬的⽽开发出来的，所以它能够轻松增加或减少硬件的数量，并且对错误的兼容性⽐较⾼。⽽传统数据库通常需要增加中间层才能实现类似的功能
Flume和Kafka
Flume基于agent思路架构，设计了3个组件source、channel、sink。source⾯向各种形式的数据源提供数据源对接与数据采集功能，以event格式将数据发送给channel。channel提供数据缓冲能⼒，保证数据传输的事务性和安全性，channel接收source发送过来的event数据并缓冲起来，直到被sink消费掉为⽌。Sink对接各种形式的数据存储，把数据存储起来，或者再次对接source形成传递接⼒。 Flume通过内置种类丰富的source提供强⼤的数据源对接与数据采集能⼒，通过channel提供了微弱的数据缓冲能⼒，并保证数据传递的事务性与安全性，通过内置的，可以对流经数据进⾏过滤和屏蔽，具有微弱的计算能⼒。
Flume中event的相关概念：Flume的核⼼是把数据从数据源（source）收集过来，在将收集到的数据送到指定的⽬的地（sink）。为了保证输送的过程⼀定成功，在送到⽬的地（sink）之前，会先缓存数据（channel），待数据真正到达⽬的地（sink）后，Flume再删除⾃⼰缓存的数据。
在整个数据的传输的过程中，流动的是event，即事务保证是在event级别进⾏的。那么什么是event呢？
Event将传输的数据进⾏封装，是Flume传输数据的基本单位，如果是⽂本⽂件，通常是⼀⾏记录。Event也是事务的基本单位。Event从source，流向channel，再到sink，本⾝为⼀个字节数组，并可携带headers（头信息）信息。Event代表着⼀个数据的最⼩完整单元，从外部数据源来，向外部的⽬的地去。
免清洗助焊剂热流道系统Flume之所以这么神奇，是源于它⾃⾝的⼀个设计，这个设计就是agent。Agent本⾝是⼀个Java进程，运⾏在⽇志收集节点——所谓⽇志收集节点就是服务器节点。 Agent⾥⾯包含3个核⼼的组件：source、channel和sink，类似⽣产者、仓库、消费者的架构。
Source：source组件是专门⽤来收集数据的，可以处理各种类型、各种格式的⽇志数据，包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy、⾃定义。
Channel：source组件把数据收集来以后，临时存放在channel中，即channel组件在agent中是专门⽤来存放临时数据的——对采集到的数据进⾏简单的缓存，可以存放在memory、jdbc、file等等。
Sink：sink组件是⽤于把数据发送到⽬的地的组件，⽬的地包括hdfs、logger、avro、thrift、ipc、file、null、Hbase、solr、⾃定义。
Flume的核⼼就是⼀个agent，这个agent对外有两个进⾏交互的地⽅，⼀个是接受数据输⼊的source，⼀个是数据输出的sink，sink负责将数据发送到外部指定的⽬的地。source接收到数据之后，将数据发送给channel，chanel作为⼀个数据缓冲区会临时存放这些数据，随后sink会将channel中的数据发送到指定的地⽅，例如HDFS等。注意：只有在sink将channel中的数据成功发送出去之后，channel才会将临时数据进⾏删除，这种机制保证了数据传输的可靠性与安全性。
Kafka基于分布式⾼可⽤的borker提供强⼤的数据缓冲能⼒，producer对接数据源采集数据，并将数据发送到broker上，数据就在borker 上缓存下来（从这个⾓度看borker很像数据库），直到sink消费完数据为⽌。
Kafka基于分布式架构提供⾼容错功能，基于offset记录已经处理过的数据，消息写⼊topic有顺序，consumer记录⾃⼰的offset，topic 数据存储在分区上，分区有副本，分布在不同节点上.
Kafka提供consumer group概念。某些topic拥有数百万甚⾄数千万的消息量，如果仅仅靠单个消费者消费，那么消费速度会⾮常慢，所以我们需要使⽤消费组功能，同⼀个消费组的多个消费者就能分布到多个物理机器上以加速消费。每个消费者组都会有⼀个独⼀⽆⼆的消费者组id来标记⾃⼰。每⼀个消费者group可能有⼀个或者多个消费者，对于当前消费组来说，topic中每条数据只要被消费组内任何⼀个消费者消费⼀次，那么这条数据就可以认定被当前消费组消费成功。消费组有如下三个特征:
洗车管理系统1、每个消费组有⼀个或者多个消费者。
2、每个消费组拥有⼀个唯⼀性的标识id。
3、消费组在消费topic的时候，topic的每个partition只能分配给⼀个消费者。
Kafka的producer和consumer通常需要定制，所以对接各种数据源不灵活、不⽅便。
所以，在⽣产环境中，⼀般将Flume和Kafka搭配使⽤，Flume采集kafka缓冲，来完成实时流式的数据处理。
1、⽣产环境中，往往是读取⽇志进⾏分析，⽽这往往是多数据源的，如果Kafka构建多个⽣产者使⽤⽂件流的⽅式向主题写⼊数据再供消费者消费的话，⽆疑⾮常的不⽅便。
2、如果Flume直接对接实时计算框架，当数据采集速度⼤于数据处理速度，很容易发⽣数据堆积或者数据丢失，⽽kafka可以当做⼀个消息缓存队列，从⼴义上理解，把它当做⼀个数据库，可以存放⼀段时间的数据。
3、Kafka属于中间件，⼀个明显的优势就是使各层解耦，使得出错时不会⼲扰其他组件。
4、Kafka与Flume都可以通过配置保证数据不丢失。但是，Flume不会复制消息，因此即使使⽤可靠的⽂件渠道，当Flume进程宕机后，你就⽆法访问这些消息了（当然Flume进程重启，从磁盘上恢复之前状态后，可以继续对消息进⾏处理）。因此如果对 HA⾼可⽤性具有很⾼要求，我们建议Kafka； 另外Flume常⽤的场景是：直接将数据写⼊存储，如hadoop或habase中。Flume对HDFS/HBase具有更好的优化，同时它也集成了Hadoop安全组件。如果数据需要被多个应⽤程序处理，我们建议Kafka；如果数据主要是⽤于Hadoop，我们建议Flume；
另外如果希望将Kafka上的数据导⼊Hadoop，可以启动⼀个内置Kafka源与Hadoop槽的Flume进程。这样就不需要去实现⾃定义的消费者，同时还可以得到Flume对HDFS/HBase优化带来的好处。
Kafka为什么能做到⾼吞吐
Kafka虽然是基于磁盘做的数据存储，但却具有⾼性能、⾼吞吐、低延时的特点，其吞吐量动辄⼏万、⼏⼗上百万。Kafka是将消息记录持久化到本地磁盘中的，⼀般⼈会认为磁盘读写性能差，可能会对Kafka性能如何保证提出质疑。实际上不管是内存还是磁盘，快或慢关键在于寻址的⽅式，磁盘分为顺序读写与随机读写，内存也⼀样分为顺序读写与随机读写。基于磁盘的随机读写确实很慢，但磁盘的顺序读写性能却很⾼，⼀般⽽⾔要⾼出磁盘随机读写三个数量级，⼀些情况下磁盘顺序读写性能甚⾄要⾼于内存随机读写。
磁盘的顺序读写是磁盘使⽤模式中最有规律的，并且操作系统也对这种模式做了⼤量优化，Kafka就是使⽤了磁盘顺序读写来提升的性能。Kafka的message是不断追加到本地磁盘⽂件末尾的，⽽不是随机的写⼊，这使得Kafka写⼊吞吐量得到了显著提升 。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议