以下内容来自腾讯工程师 wind
导语：大数据是个较宽泛的概念，一般包含四个主要特征：数据规模巨大，数据类型多样，数据价值密度低，数据处理速度要求高，传统技术已经不能高效的处理这么多数据。本文从数据采集， 存储、计算、分析几个方面为大家解析大数据相关的核心技术。
一，数据采集
大数据采集是指通过技术手段，将各个不同数据源的数据采集到数据计算平台的过程。数据采集是大数据处理的第一环，也是至关重要的一环，数据采集不过来或者采集不全，后续的环节就都无法进行。大数据采集一般分为四个步骤：
1.明确数据采集的目的和范围：需要确定采集数据的时间范围，业务范围，数据质量（可用性，准确性，及时性等），安全合规策略等。
2.制定采集的技术方案：需要根据不同的数据源和数据类型接合业务场景选择不同的采集技术
3.制定采集和处理流程：需要通过清洗，去重，格式化，合并等方式对数据进行处理，保障数据质量。
4.存储数据：将采集到的数据存储起来，一般根据数据量大小和业务场景，需要存储在hdfs，消息队列，OLAP引擎中
大数据采集技术主要分从日志及文件采集数据和从业务DB采集数据，根据数据采集的及时性又分离线采集和实时采集两种。目前使用最广泛的大数据采集框架有：Flume、Logstash，FileBeat，Sqoop，Datax，Canal， Debezium 等。
Flume：
Flume是一个高可用的、高可靠的、分布式的海量日志采集、聚合和传输的系统，支持在日志系统中定制各类数据发送方，用于收集数据，经过聚合后发送到存储系统中， 同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力
Flume的三大核心组件为 Source，Channel，Sink
Source：通过source组件可以指定让Flume读取哪里的数据，然后将数据传递给后面的channel，Flume内置支持读取很多种数据源，基于文件、基于目录、基于TCPUDP端口、基于HTTP、基于Kafka 的，Flume也支持自定义Source
Channel：接受Source发出的数据，可以把channel理解为一个临时存储数据的管道，Channel的类型有很多：内存、文件，内存+文件、JDBC等
Sink：从Channel中读取数据并存储到指定目的地，常用的sink组件有：Logger Sink： 用来将数据直接输出或者写入文件，HDFS Sink：用来将数据传输到HDFS中用于离线计算 Kafka Sink：用于将数据写入kafka中，用于实时计算
Logstash：
logstash可以将各种数据源收集到一个集中式存储中，以便进行实时监控、分析和报告。Logstash 支持多种数据输入方式，包括文件输入、TCP 输入、UDP 输入和 HTTP 输入等，并且具有灵活的数据处理能力，可以使用各种插件对数据进行过滤、转换和丰富。
Logstash 的核心组件包括输入、过滤器、输出和格式各样的插件。
输入：Logstash 支持各种输入选择，可以同时从众多常用来源捕捉事件。能够以连续的流式传输方式，轻松地从您的日志、指标、Web 应用、数据存储以及各种 AWS 服务采集数据
过滤器：数据从源传输到存储库的过程中，Logstash 筛选器能够解析各个事件，识别已命名的字段以构建结构，并将它们转换成通用格式，它能够动态地转换和解析数据，不受格式或复杂度的影响
输出：Logstash 提供了众多输出选择，可以将数据发送到所需的位置，并且能够灵活地解锁众多下游用例
插件：Logstash 采用可插拔框架，拥有 200 多个插件，可以将不同的输入选择、筛选器和输出选择混合搭配，同时 logstash也支持自己构建插件
FileBeat：
Filebeat 是使用 Golang 实现的轻量型日志采集器，用于从文件中、网络流量中或应用程序日志中收集数据，并将数据发送到相应的地方，FileBeat 的设计目标是简单易用、高效可靠、可扩展性强。它可以适应各种数据源，包括本机文件、网络流量、SSH 日志、应用程序日志等，并且支持多种数据输出方式，包括 Elasticsearch、Logstash、Kibana、MongoDB 等
fileBeat 的主要组件是 prospector 和harvester
prospector： prospector 的主要职责是管理 harvester 并找到所有要读取的文件来源。如果输入类型为日志，则查找器将查找路径匹配的所有文件，并为每个文件启动一个 harvester
harvester：harvester 的主要职责是读取单个文件的内容。读取每个文件，并将内容发送到 the output。 每个文件启动一个 harvester，harvester 负责打开和关闭文件
Sqoop
Sqoop（指sqoop2）是一款开源工具，主要用于在Hadoop（Hive）与传统的数据库（如MySQL、PostgreSQL等）之间进行数据传递。它可以将一个关系型数据库中的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导入到关系型数据库中，Sqoop使用MapReduce导入和导出数据，它的并发及容错能力较强
Sqoop 的主要组件有：Sqoop Client 和 Sqoop Server
Client：Client定义了用户使用Sqoop的方式，包括客户端命令行CLI和浏览器两种方式，浏览器允许用户直接通过Http方式完成Sqoop的管理和数据的导出
Server：server集中化管理Connector，以及rest api，web UI，并引入安全机制
Datax
DataX 是阿里云 DataWorks数据集成 的开源版本，在阿里巴巴集团内被广泛使用的离线数据同步工具/平台。DataX 实现了包括 MySQL、Oracle、OceanBase、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、Hologres、DRDS, databend 等各种异构数据源之间高效的数据同步功能。
Datax 主要包含 Reader，Writer，Framework 三个核心模块
Reader：Reader为数据采集模块，负责采集数据源的数据，将数据发送给Framework。
Writer： Writer为数据写入模块，负责不断向Framework取数据，并将数据写入到目的端。
Framework：Framework用于连接reader和writer，作为两者的数据传输通道，并处理缓冲，流控，并发，数据转换等核心技术问题。
Canal
Canal 是阿里巴巴开源的，主要用于MySQL binlog 增量订阅&消费组件的组件，其基本原理是：Canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议，MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )，canal 解析 binary log 对象(原始为 byte 流)
Debezium
Debezium 是一个开源的分布式平台，主要用于将数据库变更捕获并转换为事件流，从而使应用程序可以实时地获取这些变更。它支持多种类型的数据库，包括 MySQL，MongoDB，PostgreSQL，Oracle，SQL Server，Db2，Cassandra，Vitess
大数据采集技术比较多，需要根据具体的业务场景选择不同的技术，文件数据采集方面：如果数据来源多且复杂，可以优先考虑Flume，如果已经有ELK框架，则优先考虑 Logstash，如果本身只是很轻量的日志采集，可以使用filebeat ；数据库数据传输方面：如果数据源比较多，优先考虑datax，如果主要是mysql和hadoop之间传输，可以考虑更轻量的sqoop 。实时数据同步则可以考虑 Debezium ，如果本身有flink集群，也可以考虑直接用flinkCDC
二，数据存储
数据采集到之后，需要存入大数据平台中，一般是存在文件存储系统或消息队列中，用来做离线计算和实时计算，也可以先直接落到消息队列，再由消息队列转到文件系统中。
文件存储系统
HDFS
Hadoop 分布式文件系统（HDFS）是一种用于存储和处理大规模数据的高可靠性和高可用的分布式文件系统。HDFS 是 Hadoop 生态系统中的核心组件之一，它可以在多个节点上存储和管理数据。
Ceph
Ceph是一个开源的统一的分布式存储系统，是高性能的并行文件系统。Ceph的主要目标是设计成基于POSIX的没有单点故障的分布式文件系统，使数据能容错和无缝的复制Ceph提供三种存储方式分别是对象存储，块存储和文件系统。在虚拟化领域里，比较常用到的是Ceph的块设备存储。Ceph以其稳定、高可用、可扩展的特性，成为最热门的开源分布式存储系统。
Amazon S3
Amazon S3 是亚马逊提供的简单、无服务器、可扩展的对象存储服务。S3 提供高性能、高可用性、高扩展性的数据存储，被广泛应用于各种大数据应用中。
COS
COS（Cloud Object Storage）是由腾讯云推出的无目录层次结构、无数据格式限制，可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限，无需分区管理，适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
Apache Cassandra
Apache Cassandra 是一种分布式、可扩展、高性能、高可用的列式数据库，主要用于实时数据访问和在线应用。Cassandra 特别适合用于处理大量数据、读写操作以及应对硬件故障等问题。
GCS
GCS(Google Cloud Storage） 是谷歌提供的对象存储服务，它提供了高可用性、高性能和可扩展性，并且与谷歌云的其他服务紧密集成。
Microsoft Azure Blob Storage
Microsoft Azure Blob Storage 是微软提供的对象存储服务，它提供了高可用性、高性能和可扩展性，并且与 Azure 云服务紧密集成
Hdfs 是hadoop成员，它天生就是为支持大数据处理任务而设计的，它适用于存储数据，以便进行大规模的分布式计算和分析，目前主流的大数据存储中，HDFS也最为广泛；不过近年来，随着湖仓技术的发展，以S3为代表的各类对象存储异军突起，它的无限可扩展，低延时访问及多层的权限控制以及无缝兼容各类计算框架的特性越来越受到人们欢迎。
消息队列
Kafka
Apache Kafka 是一个开源的、高性能、高可用的分布式消息队列服务。单机写入TPS约在百万条/秒
plusa
Apache Pulsar 作为 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、跨区域复制、具有强一致性、高吞吐、低延迟及高可扩展性等流数据存储特性，
RocketMQ
阿里巴巴开源的分布式消息中间件，具有高吞吐量、低延迟、可靠性强等特点。单机吞吐量十万级，不过其消息堆积的处理能力很强，十亿量级的消息堆积基本不影响性能
RabbitMQ
RabbitMQ 是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，它支持的语言非常广泛
各消息队列的选择建议：
Kafka主要的特是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，使用与超大数据的收集业务；pulsar 比较新，参考了kafka的设计，比kafka更高的吞吐量和低延迟，支持了更多的topics，还提供了分层存储能力的能力； RocketMQ 主要服务于金融类产品，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务消峰，在大量交易涌入的时候，后端可能无法及时处理。RocketMQ经历了多次阿里双11的冲击，在稳定性上做得更好。 RabbitMQ 性能好时效性微秒级，社区活跃度比较高，管理界面十分方面， 数据量不是特别大的情况下可以优先选择。
三，数据计算
好了，数据采集进来存储起来了，接下来就要开始计算了，当前最核心的计算框架就是Spark和Flink 了。Spark主要用来做离线计算，Flink主要用来做实时数据计算
计算框架
Spark
Spark最初由加州伯克利大学（UC Berkeley）的AMP（Algorithms, Machines and People）实验室于2009年开发， 是一个快速的，通用的集群计算系统。它对 Java，Scala，Python 和 R 提供了的高层 API，并有一个经优化的支持通用执行图计算的引擎。具有 运行速度快，易用使用，通用性强，运行模式多样等特点；它还支持一组丰富的高级工具，包括用于 SQL 和结构化数据处理的 Spark SQL，用于机器学习的 MLlib，用于图计算的 GraphX 和 Spark Streaming。
Spark 主要有五个部分组成，包含：Spark Core，Spark SQL，Spark Streaming，Spark MLlib 和 Spark GraphX
Spark Core 中提供了 Spark 最基础与最核心的功能，包含Spark的基本功能，定义RDD的API、操作以及这两者上的动作，其他各个模块 都是在 Spark Core 的基础上进行扩展的。
Spark SQL 是 Spark 用来操作结构化数据的组件，提供sql与spark进行交互的API,每个数据库表被当做一个RDD，Spark SQL查询被转换为Spark操作。
Spark Streaming 是 Spark 平台上针对实时数据进行流式计算的组件，提供了丰富的处理数据流的 API。
Spark MLlib 是 Spark 提供的一个机器学习算法库。MLlib 不仅提供了模型评估、数据导入等额外的功能，还包含可扩展的学习算法，比如分类、回归等需要对大量数据集进行迭代的操作。
Spark GraphX 是 Spark 面向图计算提供的框架与算法库，提供了一系列控制图、并行图操作和计算的一组算法和工具的集合
Flink
Apache Flink 是一个在有界数据流和无界数据流上进行有状态计算分布式处理引擎和框架。Flink 设计旨在所有常见的集群环境中运行，以任意规模和内存级速度执行计算，其代码主要是由 Java 实现。Flink既可以处理有界的批量数据集，也可以处理无界的实时流数据，为批处理和流处理提供了统一编程模型。
Spark 认为数据都是由批组成的，离线数据是一个大批，实时数据是无数个小批，批处理的特点是有界、持久、大量，Spark 更多使用在离线场景
Flink认为数据都是由流组成的，离线数据是有界限的流，实时数据是一个没有界限的流，流处理的特点是无界、实时, 无需针对整个数据集执行操作，而是每条数据流过来后就立即处理，Flink更多使用在实时场景
由于实时和离线都有使用场景，一般统一业务需要部署两套架构，一套为实时架构，一套为离线架构，业界称为 Lambda架构 。Lambda架构 有两套引擎，两套代码，弊端太明显了，随着 流批一体技术理念的兴起，基于Flink加数据湖技术为基础的Kappa架构发展越来越迅猛，不过这里就不再深入讨论。
我们的计算任务不仅有单个计算逻辑，还要涉及到任务和任务之间的依赖关系 以及资源的合理化利用，因此，资源调度系统和任务调度系统也是非常重要的
资源调度
常见的资源调度系统有 YARN 和 Mesos
YARN：
Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。它不仅仅支持MapReduce程序，理论上支持各种计算程序；它不关心你干什么，只关心你要多少资源，在有的情况下给你，用完之后还我。yarn 默认支持三种调度策略：FIFO、CapacityScheduler、FairScheduler
YARN 的核心组件包括：ResourceManager 、NodeManager 、ApplicationMaster 、Container
ResourceManager是一个全局的资源管理器，负责整个系统的资源管理和分配。它由调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）组成，调度器将系统中的资源分配给正在运行的程序，不负责监控或跟踪应用的执行状态，不负责重启失败的任务。 应用程序管理器负责管理整个系统中所有应用程序。
NodeManager是每个节点上的资源和任务管理器， 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，它接收并处理来自AM的Container启动/停止等各种请求
ApplicationMaster负责与RM调度器协商以获取资源并进行分配，负责与NodeManager 进行通信已执行启动和停止等命令并监控任务的运行状态
Container 是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的，一个任务一个Container
Mesos：
Mesos是Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核。Mesos最初是由加州大学伯克利分校的AMPLab开发的，后在Twitter得到广泛使用，目前是Apache基金会的顶级项目。Mesos的主要目标是去帮助管理不同框架间的集群资源
Mesos 主要有master、slave，framework 和Executor组成
master：是整个系统的核心。主要负责管理各个Framework和Slave ，使用可插拔的分配模块或调度算法来分发资源供给至各种调度器，从而按照某资源分配策略slave上的资源分配给各个Framework；
Slave：接收来自Mesos Master的命令、管理本地节点上的各个Mesos Task，将CPU、内存、存储发送经Mesos Master，由Mesos Master的Allocator模块决定资源的具体分配，当调度器从主master接收资源供给后，在slave节点上启动一个或多个执行器，执行器负责运行framework的任务
Framework：负责外部的计算框架的接入，如Hadoop、Spark等。这些外部计算框架通过注册的方式接入Mesos，由Mesos进行分布式集群资源的分配；framework由调度器与执行器 组成，其中调度器和master紧密通信，接受master发送的offer并决定是不是要跑某个task，执行器负责执行任务
YARN更多的用在大数据平台中，它对上层计算框架的支持更好，也更轻量，而 Mesos则更多在资源的抽象和管理上做的更好，是一个更通用的资源管理系统
任务调度
任务调度方面比较流行的airflow，Oozie 和Azkaban
airflow：
Airflow是一个可编程，调度和监控的工作流平台，所谓工作流, 即工作流程模型, 如 ETL 就是一个标准的工作流, 一个任务先做什么再做什么最后做什么；airflow将一个具有上下级依赖关系的工作流，组装成一个有向无环图，并按照依赖依次执行。airflow提供了丰富的命令行工具用于系统管控，也提供了方便的web管理界面对任务运行状态进行实时监控和调度管理
airflow 主要包含webserver，scheduler，celery，flower 四个部分
webserver : 提供web端服务，并定时生成子进程去扫描对应的目录下的DAG，并更新数据库
scheduler : 是一个守护进程，它周期性地轮询任务的调度计划，以确定是否触发任务执行，它根据dags生成任务，并提交到消息中间件队列中 (redis或rabbitMq)
celery worker : 分布在不同的机器上，负责执行具体 的 DAG 任务。
flower : 监控worker进程的存活性，启动或关闭worker进程
Oozie：
一个基于工作流引擎的开源框架，由Cloudera公司贡献给Apache，提供对Hadoop MapReduce、Pig Jobs的任务调度与协调。Oozie需要部署到Java Servlet容器中运行。主要用于定时调度任务，多任务可以按照执行的逻辑顺序调度
Oozie主要包含 Workflow，Coordinator，Bundle Job 三个部分
Workflow：负责按顺序执行流程节点，支持fork，join，decision等
Coordinator：工作流的协调器，可以将多个工作流协调成一个工作流来进行处理，是对要进行的顺序化的workflow的抽象，定时触发一个workflow
Bundle Job：将一堆的coordinator进行汇总处理，是对一堆coordiantor的抽象，用来绑定多个coordinator或者多个workflow
Azkaban：
Azkaban是由Linkedin公司推出的一个批量工作流任务调度器，主要用于在一个工作流内以一个特定的顺序运行一组工作和流程，它的配置是通过简单的key:value对的方式，通过配置中的dependencies 来设置依赖关系。Azkaban使用job配置文件建立任务之间的依赖关系，并提供一个易于使用的web用户界面维护和跟踪你的工作流
Azkaban主要包含，Web Server，Executor Server 和关系型元数据库（mysql） 三个部分
WebServer：AzkabanWebServer是整个Azkaban工作流系统的主要管理者，它用户登录认证、负责project管理、认证，调度，定时执行工作流、跟踪工作流执行进度，监控等一系列任务。
ExecutorServer：负责具体的工作流和任务的提交和执行。
关系型元数据库 ：存储大部分执行流状态， 日志，执行计划之类的信息，WebServer和ExecutorServer都需要访问数据库。
azkaban 最为轻量，UI最为直观，使用起来也较简单，airflow 偏重，需要依赖一些第三方组件，并且需要写python语言来开发使用。oozie则更重，在灵活性及更复杂的工作流上也支持得更好
四，数据分析
到了这里，数据基本上就计算好了，接下里就要提供给运营，产品，数科等同学进行分析了，一般我们会通过各类olap分析引擎进行分析
OLAP分析引擎大多采用MPP（Massively Parallel Processing，大规模并行处理）架构 ，是一种分布式数据处理技术，能够通过将工作负载分散到多个节点上来提高数据处理性能，MPP架构具有 高效、可扩展、可靠、高性能的分布式计算架构，适用于大规模数据处理和分析场景，不过 MPP架构也存在 计算节点性能不均衡的问题
常见的olap分析引擎有 clickhouse，starRocks，Presto、Impala、Druid
Clickhouse：
ClickHouse是一种列式数据库管理系统，专门用于高性能数据分析和数据仓库应用，最初由俄罗斯搜索引擎公司Yandex开发，用于满足大规模数据分析和报告的需求，支持线性扩展，简单方便，高可靠性，支持数据统计分析各种场景，支持类SQL查询，异地复制部署，可支持十亿级别的数据计算。不过clickhouse 不支持事务，对update，delete 语句的性能较弱，数据类型偏少，并发也不太好
ClickHouse的核心组件主要有四个部分：Client、Server，Storage和System。
Client：Client是与用户交互的接口，用户可以通过各种客户端工具（如ClickHouse-CLI、ClickHouse-JDBC等）连接到ClickHouse服务器，并发送查询请求和接收查询结果。
Server：Server是ClickHouse的核心计算引擎，负责接收和处理客户端的查询请求。它包含了多个服务组件，如Query Parser、Query Optimizer、Query Executor等。
Storage：存储组件是ClickHouse的核心组件，负责数据的存储和管理。它包括 Table Engine（表引擎是存储组件的核心部分，负责数据的存储和检索）。ClickHouse提供了多种表引擎，如MergeTree、Log和TinyLog等，以支持不同的数据访问模式和查询需求
System ：系统组件包括了ClickHouse的运维和监控工具，以及管理集群和节点的功能
StarRocks：
StarRocks 是一款极速统一的Lakehouse产品，具备水平在线扩缩容，金融级高可用，兼容 MySQL 5.7 协议和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查询等重要特性。StarRocks 致力于在全场景 OLAP 业务上为用户提供统一的解决方案，适用于对性能，实时性，并发能力和灵活性有较高要求的各类应用场景。 能够支撑 PB 级别的数据量，拥有灵活的建模方式，可以通过向量化引擎、物化视图、位图索引、稀疏索引等优化手段构建极速统一的分析层数据存储系统，同时starRocks支持冷数据下沉的能力，可以将长时间不用的数据下沉到cos，iceberg等其他存储中，需要计算时再提取出来，很大程度上节省了数据的存储成本。
StarRocks 的架构非常简单，分为 FrontEnd 和BackEnd
FrontEnd 节点主要负责元数据的管理和客户端链接的管理，并且根据元数据信息进⾏ 查询的规划和查询的调度。从 MySQL 客户端发起的请求通过 FrontEnd 节点转化成分 布式的 AST，也就是我们所说的执⾏计划树，推送给对应的 BackEnd 节点。每⼀个 FrontEnd 节点都存储全量的元数据，通过类 Paxos 协议进⾏数据同步，这种多数派的 数据同步协议也保证了我们可以线上⽔平阔所容 FrontEnd 节点。
BackEnd 节点主要负责数据存储及 SQL 的计算⼯作。FrontEnd 节点按照⼀定的策略 将数据分配给对应的 BackEnd 节点。在执⾏ SQL 计算时，⼀条 SQL 语句⾸先会按照 具体的语义规划成逻辑执⾏单元，然后再按照数据的分布情况拆分成具体的物理执⾏ 单元在 BackEnd 中进⾏计算。BackEnd 节点是完全对等的，数据通过 Qurom 协议进 ⾏同步。BackEnd 节点同样也⽀持在线⽔平阔缩容。
Presto：
Presto是一个分布式的采用MPP架构的查询引擎，本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。Presto ，擅长对海量数据进行复杂的分析 ，它需要从其他数据源获取数据来进行运算分析，它可以连接多种数据源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等
Impala：
Impala本身不存储任何数据，直接使用内存进行计算，兼顾数据仓库，具有实时，批处理，多并发等优点，不过Impala对内存的要求比较大，Impala 只能读取本地的文本文件，不能读取二进制文件；
Impala 主要有 Impalad、 State Store、Catalogd 三个组件组成
Impalad :它负责接收客户端的查询请求 读写数据，并行执行查询，并返回结果
statestored：跟踪Impalad的健康状态及位置信息，并将集群健康信息同步给Impalad。 Impalad将其运行状况报告给Impala State存储守护程序， 在由于任何原因导致节点故障的情况下，Statestore将更新所有其他节点关于此故障，并且一旦此类通知可用于其他impalad，则其他Impala守护程序不会向受影响的节点分配任何进一步的查询
Catalogd：Catalogd负责从各外部表中获取元数据信息并同步给Impalad进程
Druid：
Druid是一个开源、分布式、面向列式存储的实时分析数据存储系统。它采用了列式存储、倒排索引、位图索引等关键技术；
能在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作，它还Druid提供了实时流数据分析，以及高效实时写入，它还提供了友好的可视化界面用来做查询分析
Druid 本身包含了五种节点 ：Realtime、Historical、Coordinator、Broker、Indexer
Realtime 实时节点是进行存储和查询实时数据的工作区，它也会响应Broker节点的查询请求并返回结果 。实时节点会定期地将数据建立成数据段移到历史节点中。
Historical 进行存储和查询的“历史”数据（非实时）的工作区，它会从深存储区(Deep Storage)中加载数据段(Data/Segments)，响应 Broker 节点的查询请求并返回结果。历史节点通常会在本机同步深存储区上的部分数据段，所以即使深存储区不可访问了，历史节点还是能查询到已经同步的数据段。
Coordinator 协调节点可以认为是Druid中的master，它通过Zookeeper管理历史节点和实时节点，且通过Mysql中的metadata管理数据段。
Broker节点负责响应外部的查询请求，通过查询Zookeeper将请求分别转发给历史节点和实时节点，最终合并并返回查询结果给外部， 由Broker节点通过zookeeper决定哪些历史节点和实时节点提供服务。
Indexer 索引节点负责数据导入，加载批次和实时数据到系统中，并可以修改存储到系统中的数据
olap引擎设计使用场景各有不同，Presto、Impala本身不存储数据，可以支持对接多种数据源，Impala 性能稍领先于 Presto，但是 Presto 在数据源支持上非常丰富；Druid 更多用于实时聚合数据；CK和SR更多用在实时的写入和分析上， CK适合于维度变化较少的拼宽表的场景，SR则在多表关联上更有优势；使用者需根据 数据量、性能、和灵活性三个方面进行综合考虑。
欢迎点赞分享，搜索关注【鹅厂架构师】公众号，一起探索更多业界领先产品技术。
文章来源于互联网:一文读懂大数据核心技术
