Kafka

一、 kafka的存储机制 kafka通过topic来分主题存放数据，主题内有分区，分区可以有多个副本，分区的内部还细分为若干个segment。 所谓的分区其实就是在kafka对应存储目录下创建的文件夹，文件夹的名字是主题名加上分区编号，编号从0开始。 1、 segment 所谓的segment其实就是在分区对应的文件夹下产生的文件。 一个分区会被划分成大小相等的若干segment，这样一方面保证了分区的数据被划分到多个文件中保证不会产生体积过大的文件；另一方面可以基于这些segment文件进行历史数据的删除，提高效率。 一个segment又由一个.log和一个.index文件组成。 1． .log .log文件为数据文件用来存放数据分段数据。 2． .index .index为索引文件保存对对应的.log文件的索引信息。 在.index文件中，保存了对对应.log文件的索引信息，通过查找.index文件可以获知每个存储在当前segment中的offset在.log文件中的开始位置，而每条日志有其固定格式，保存了包括offset编号、日志长度、key的长度等相关信息，通过这个固定格式中的数据可以确定出当前offset的结束位置，从而对数据进行读取。 3． 命名规则 这两个文件的命名规则为： partition全局的第一个segment从0开始

一、 kafka的存储机制 kafka通过topic来分主题存放数据，主题内有分区，分区可以有多个副本，分区的内部还细分为若干个segment。 所谓的分区其实就是在kafka对应存储目录下创建的文件夹，文件夹的名字是主题名加上分区编号，编号从0开始。 1、 segment 所谓的segment其实就是在分区对应的文件夹下产生的文件。 一个分区会被划分成大小相等的若干segment，这样一方面保证了分区的数据被划分到多个文件中保证不会产生体积过大的文件；另一方面可以基于这些segment文件进行历史数据的删除，提高效率。 一个segment又由一个.log和一个.index文件组成。 1． .log .log文件为数据文件用来存放数据分段数据。 2． .index .index为索引文件保存对对应的.log文件的索引信息。 在.index文件中，保存了对对应.log文件的索引信息，通过查找.index文件可以获知每个存储在当前segment中的offset在.log文件中的开始位置，而每条日志有其固定格式，保存了包括offset编号、日志长度、key的长度等相关信息，通过这个固定格式中的数据可以确定出当前offset的结束位置，从而对数据进行读取。 3． 命名规则 这两个文件的命名规则为： partition全局的第一个segment从0开始

一、概述 　　 为了提升集群的HA，Kafka从0.8版本开始引入了副本（Replica）机制，增加副本机制后，每个副本可以有多个副本，针对每个分区，都会从副本集（Assigned Replica，AR）中，选取一个副本作为Leader副本，所有读写请求都由Leader副本处理，其余的副本被称为Follwer副本，其会从Leader副本拉取消息更新到本地。因此，Follower更像是Leader的热备。 　　一般情况下，同一个分区的多个副本会被均匀的分配到集群中的不同Broker上，当leader副本所在机器出现故障后会重新选举出新的leader实现故障转移。（针对副本如何分配以避免单台机器上leader过多导致集群负载均衡不均及多副本在同一机器上等问题，不再本文的讨论范围内，感兴趣的小伙伴，可以参考下kafka-reassign-partitions脚本）。 二、关键术语 副本：kafka对消息的冗余存储以提升容灾能力，以分区为单位。 Leader副本：每个分区都有多个副本，针对每个分区，都有一个唯一的一个Leader副本，负责该分区的读写请求处理。 Follower副本：从Leader副本拉取数据，作为Leader副本的热备。 AR：（Assigned Replica）副本集合（Leader+Follower的总和） ISR：（In-Sync Replica）同步副本集合

Ambari 2.7.3.0安装新组件和之前版本略有不同，本文将简述安装新组件的简单过程。 前提是大家已经安装好Ambari 2.7.3.0 这时候由于有一些组件没有添加，就需要安装新的组件。 首先我们登录到Ambari中。 然后选择左下角 Stack and Versions 在这个页面可以看到我们安装过的服务，我们选择superset Add Service添加服务 这里会显示之前安装的服务，之前安装的是修改不了的，我们选择next进行下一步 这里选择安装在哪台机器，可以根据机器的具体情况进行分配 这一步也是不用修改的： 设置一些属性，主要是密码，密码是必须设置的，设置完才能通过，其他的一些设置可以稍后修改 选择部署，开始进行安装部署 耐心等待安装： 可以点进去查看日志，分为正常的log和错误log，如果报错注意查看错误原因 等待安装成功，如果失败查看log进行解决 完成，提示重启组件 可以看到已经安装并启动成功了，可以进入查看 更多实时计算,Flink,Kafka等相关技术博文，欢迎关注实时流式计算 本文分享自微信公众号 - 实时流式计算（RealtimeBigdata）。 如有侵权，请联系 support@oschina.cn 删除。 本文参与“ OSC源创计划 ”，欢迎正在阅读的你也加入，一起分享。 来源： oschina 链接： https://my.oschina

01 前言 本文想再讨论一下关于领域、业务、业务模型、解决方案、BC、领域模型、微服务这些概念的含义和关系。 初衷是我发现现在DDD领域建模以及解决方案落地过程中，常常对这些概念理解不清楚或者有歧义，导致我们不知道如何运用这些概念来落地我们的软件。 先通过一个图来说明一下这些概念之间的关系，如下图所示 02 领域、业务、业务模型 · 领域，即问题域、问题空间，领域是一种边界、范围。 所以，一个领域代表了一个问题域的边界，也可以理解为是一个业务的边界。 · 领域边界越大，业务范围就越大，反之则相反。 通常我们大家交流都比较喜欢用业务这一词，比如这块业务，那块业务，业务的边界，我是一个业务开发人员（区分于我是一个中间件开发人员）。而领域一词，相对比较抽象，不是那么容易懂。 · 领域既然是一个边界，所以可以划分领域的大小。 即领域划分，划分出来的子领域简称子域，每个子域对应一个小的问题域和和小的业务；当然，不同的子域的重要性也是不同的，所以才有了核心子域、支撑子域的说法，这点显而易见。 · 每个业务都有一个对应的业务模型 （注意这个业务模型不是领域模型，而是一个业务概念的模型，领域模型下面会提到），这个业务模型设计的时候，完全不需要考虑任何软件设计的思想，比如对象的抽象、继承、存储、性能，等。 我们是从业务本身出发，分析业务边界范围内的各种业务概念，以及业务概念之间的关系

Superset 0.37，增加可视化插件，行级权限控制 使用Superset已经有一段时间，其良好的体验与丰富的图表功能节省了大量的时间。但是对于权限，自定义图表，图表下载，报警邮件一直没有很好的支持，大部分公司对于这些功能的实现还是需要大量的二次开发，费时费力。 近日Superset 0.37 正式发布，令人惊喜的是，新功能几乎都是大家期待已久的，而对于Superset的未来也更加的期待了。 下面简单介绍本次的一些主要的更新~ 距离Superset 0.36 的发布已经过了四个多月的时间，但superset的活跃程度一点没有减弱，GitHub的Star已经突破了30k，Superset已经成为数据可视化平台的不二选择。 可视化插件 0.37对Superset可视化代码进行了重构，开发人员现在可以引用图表API来构建自己的可视化插件，无需再去二次开发代码。 除了对现有图表类型（如数据透视表，饼图和过滤器框）进行的其他小改进和错误修复之外，此新体系结构还 使用户能够对数据进行更多处理 。 现在，可以使用任何可用的基于JavaScript的数据可视化库在Superset上创建自定义可视化插件，例如ECharts，AntV，HighCharts，VX，D3。 行级权限控制 构建新的可视化插件显然是很酷，但是对于要成为企业级的任何数据可视化应用程序，它在安全性上都必须坚如磐石。此次的0

Flink容错数 据流概念 有状态的函数和操作需要存储计算相关的数据，这使得状态成为复杂计算的关键。在 Flink 中的每一种函数和操作都可以成为有状态的。为了达到很好的容错，Flink 的容错机制持续的记录分布式的数据流的快照。这些快照是非常轻量化的，因此高频的记录快照并不会影响性能。当进程由于机器，网络甚至是软件异常而失败的时候，Flink 会停止数据流。系统重启操作同时将他们恢复到最近的快照点。输入流也会被设置到记录快照点那个时间点，通俗点说就是一条记录不会存在于快照中同时还在数据流中等待被处理。 问题1:哪些函数是有状态的？ 问题2:为什快照是非常轻量化的？ 问题3:快照如何设置异步的？ 问题4:如何在配置中设置多个快照 问题5:快照支持哪几种方式，如何配置 问题6:Checkpoint和Snapshots如何使用 Checkpointing Flink 容错机制的核心就是，记录分布式的数据流和状态的一致性快照。通过这些快照，系统可以从失败中恢复回来 屏障Barriers Flink分布式快照的一个核心元素是流屏障。这些屏障被注入到数据流中，并将记录作为数据流的一部分。障碍永远不会超过记录，它们严格按照顺序流动。一个屏障将数据流中的记录分隔为进入当前快照的记录集和进入下一个快照的记录集。每个屏障都携带快照的ID，快照将快照的记录推到它前面。屏障不会中断流，因此非常轻

Apache Flink提供了一种容错机制，可以持续恢复数据流应用程序的状态。该机制确保即使出现故障，程序的状态最终也会反映来自数据流的每条记录(只有一次)。 从容错和消息处理的语义上(at least once, exactly once)，Flink引入了state和checkpoint。 state 一般指一个具体的task/operator的状态。而 checkpoint 则表示了一个Flink Job，在一个特定时刻的一份全局状态快照，即包含了所有task/operator的状态。 Flink通过定期地做checkpoint来实现容错和恢复，容错机制连续绘制了分布式流数据流的快照。对于小状态的流应用程序，这些快照非常轻量级并且可以经常绘制，而不会对性能产生太大的影响。流应用程序的状态存储在一个可配置的地方(例如主节点或HDFS)。 如果出现程序故障(由于机器、网络或软件故障)，Flink将停止分布式流数据流。然后系统重新启动操作符并将其重新设置为最新成功的检查点。输入流被重置到状态快照的点。默认情况下，检查点是禁用的。 要使此机制实现其全部的保证，数据流源(如消息队列或代理)需要能够将流倒回到其定义的最近点。Apache Kafka可以做到，而Flink的Kafka连接器可以利用这些。 因为Flink通过分布式检查点实现快照，我们使用快照和检查点互换。

使用消息队列是提高系统性能的第二黄金法则。 1、消息队列使用场景 一般稍微大点的系统都会用到消息队列，之前项目中用过的主要有ActiveMQ和kafka。使用消息队列的最终目的是通讯，本质是解耦生产者消费者依赖，一般用在异步处理、解耦、错峰、流量控制等场景。 Java消息队列 2、消息队列模型push vs pull push模型最大问题是慢消费，即消费者速度如果比生产者速度慢很多，会导致消息在broker的堆积，如果这些消息是有用无法丢弃的就会一直在broker端保存，并且broker会不断的给消费者推送消息，消费者reject或error后可能会来回推送。而pull模式，消费者可以按需消费，不用担心自己处理不了的信息来骚扰自己，broker堆积消息也会相对简单，无需记录每一个要发送消息的状态，只需要维护所有消息的队列和偏移量就可以了。由于主动权在消费方，消费方无法准确地决定何时去拉取最新的消息。如果一次pull取到消息了还可以继续去pull，如果没有pull取到则需要等待一段时间重新pull。 pull模式最大的问题是消息延迟和忙等。业界较成熟的做法是从短时间开始（不会对broker有太大负担），然后指数级增长等待。比如开始等5ms，然后10ms，然后20ms，然后40ms……直到有消息到来，然后再回到5ms。 3、如何保证消息不丢失（可靠投递，最终一致性），不重复或有序性？

1. 架构图 　　 　　一个Kafka集群中包含若干个Broker(消息实例)，Kafka支持Broker横向扩展，Broker越多，吞吐量越大，同时也包含了若干个Producer(可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等）和若干个Consumer(消费者)以及一个zookeeper集群，Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。 2. Topic和Partition 　　 　　Topic：是一个逻辑的概念，它可以认为类似于其他中间件中queue的概念，作为一组消息的一个集合，跟其他的消息中间件一样，每个消息的发送或者是消费都必须要指定Topic，表明将消息存在哪个Topic中。一个Topic可以接受多个Producer发送的消息和被多个Consumer消费。 　　Partition：了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件，同意Topic下不同分区包含的消息是不同的