大数据

exactly-once 恰好一次。消息有且仅会被传输一次 即使producer重试发送消息，消息也会保证最多一次地传递给最终consumer。该语义是最理想的，但也难以实现，这是因为它

ClickHouse 非常亲和且具有自己的个性 支持完备的SQL操作 列式存储与数据压缩 向量化执行引擎 关系型模型(与传统数据库类似) 丰富的表引擎 并行处理 在线查询 数据分片

在 Flink 的后台任务管理中，可以看到 Flink 的哪个算子和 task 出现了反压； 资源调优和算子调优： 资源调优即对作业中的 Operator 并发数（Parallelism）

根据我们业务对维表数据关联的时效性要求，有以下几种解决方案：1、实时查询维表 2、预加载全量数据 3、LRU 缓存(最近最少使用的数据则被淘汰) 4、将维表消息广播出去

flink数据倾斜的表现： 任务节点频繁出现反压，增加并行度也不能解决问题 部分节点出现OOM异常，是因为大量的数据集中在某个节点上，导致该节点内存被爆，任务失败重启

Flink的窗口机制是其底层核心之一，也是高效流处理的关键。Flink窗口分配的基类是WindowAssigner抽象类，下面的类图示出了Flink能够提供的所有窗口类型。

基本类型划分 在Flink中，按照基本类型，对State做了以下两类的划分： Keyed State，和Key有关的状态类型，它只能被基于KeyedStream之上的操作，方法所使用。

1.开发者模式     在idea中运行Flink程序的方式就是开发模式。 2.local-cluster模式     Flink中的Local-cluster(本地集群)模式,单节点运行

基于 Hive 的离线数仓往往是企业大数据生产系统中不可缺少的一环。Hive 数仓有很高的成熟度和稳定性，但由于它是离线的，延时很大。

Omega架构我们暂且称之为混合数仓。在谈我们的解法的时候，必须要先提ECS的设计模式。 简单的说，Entity、Component、System分别代表了三类模型。

对于实时数仓而言，Lmabda架构有很明显的不足，首先同时维护两套系统，资源占用率高，其次这两套系统的数据处理逻辑相同，代码重复开发。 能否有一种架构，只需要维护一套系统，就可以同时完成流

Lambda架构是由Storm的作者Nathan Marz提出的一个实时大数据处理框架。Marz在Twitter工作期间开发了著名的实时大数据处理框架Storm

Hive 大表和小表的关联 优先选择将小表放在内存中。 小表不足以放到内存中，可以通过bucket-map-join(不清楚的话看底部文章)来实现，效果很明显。

什么是 CDC CDC,Change Data Capture,变更数据获取的简称，使用CDC我们可以从数据库中获取已提交的更改并将这些更改发送到下游，供下游使用。

Flink 1.1.0：第一次引入 SQL 模块，并且提供 TableAPI，当然，这时候的功能还非常有限。Flink 1.3.0：在 Streaming SQL 上支持了

1，如果预聚合不影响最终结果，可以使用conbine，提前对数据聚合，减少数据量。使用combinner合并,combinner是在map阶段,reduce之前的一个中间阶段

（1）设计理念 　　1、Spark的技术理念是使用微批来模拟流的计算,基于Micro-batch,数据流以时间为单位被切分为一个个批次,通过分布式数据集RDD进行批量处理,是一种伪实时。

Watermark 介绍 Watermark 本质是时间戳，与业务数据一样无差别地传递下去，目的是衡量事件时间的进度（通知 Flink 触发事件时间相关的操作，例如窗口）。

核心流程 FlinkYarnSessionCli 启动的过程中首先会检查Yarn上有没有足够的资源去启动所需要的container，如果有，则上传一些flink的jar和配置文件到HDFS

Flink通过实现两阶段提交和状态保存来实现端到端的一致性语义。不知道事务的同学可以先看下： 分布式事务有哪些解决方案？ Flink 的两阶段提交思路： 我们从 Flink 程序启动到消费