提示的错误信息如下： [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (attach-javadocs) on project codebank: MavenReportException: Error while creating archive: Unable to find javadoc command: The environment variable JAVA_HOME is not correctly set. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException 如下图：     问题和解决 上面的提示已经比较清楚了。 你没有在你的环境变量中设置 JAVA_HOME 需要按照上面的设置一个环境变量。 如果你使用的是 IEDA 的话，你需要重启的 IDEA 环境。 如果你使用的是命令行工具的话，你也需要退出后重启。 然后再次进行编译，应该就能解决上面的问题了。   https://www.ossez.com/t/maven-java-home-is-not-correctly-set/13679

tuningConfig 的配置是可选的，如果你不在这里对这个参数进行配置的话，Druid 将会使用默认的配置来替代。   5-Best-Practices-for-Proactive-Database-V21500×700 15.5 KB   字段（Field） 类型（Type） 描述（Description） 是否必须（Required） type String 索引任务类型， 总是 kafka。 Y maxRowsInMemory Integer 在持久化之前在内存中聚合的最大行数。该数值为聚合之后的行数，所以它不等于原始输入事件的行数，而是事件被聚合后的行数。 通常用来管理所需的 JVM 堆内存。 使用 maxRowsInMemory * (2 + maxPendingPersists) 来当做索引任务的最大堆内存。通常用户不需要设置这个值，但是也需要根据数据的特点来决定，如果行的字节数较短，用户可能不想在内存中存储一百万行，应该设置这个值。 N（默认=1000000） maxBytesInMemory Long 在持久化之前在内存中聚合的最大字节数。这是基于对内存使用量的粗略估计，而不是实际使用量。通常这是在内部计算的，用户不需要设置它。 索引任务的最大内存使用量是 maxRowsInMemory * (2 + maxPendingPersists) N（默认=最大JVM内存的 1/6） maxRowsPerSegment Integer 聚合到一个段中的行数，该数值为聚合后的数值。 当 maxRowsPerSegment 或者 maxTotalRows 有一个值命中的时候，则触发 handoff（数据存盘后传到深度存储）， 该动作也会按照每 intermediateHandoffPeriod 时间间隔发生一次。 N（默认=5000000） maxTotalRows Long 所有段的聚合后的行数，该值为聚合后的行数。当 maxRowsPerSegment 或者 maxTotalRows 有一个值命中的时候，则触发handoff（数据落盘后传到深度存储）， 该动作也会按照每 intermediateHandoffPeriod 时间间隔发生一次。 N（默认=unlimited) intermediatePersistPeriod ISO8601 Period 确定触发持续化存储的周期 N（默认= PT10M） maxPendingPersists Integer 正在等待但启动的持久化过程的最大数量。 如果新的持久化任务超过了此限制，则在当前运行的持久化完成之前，摄取将被阻止。索引任务的最大内存使用量是 maxRowsInMemory * (2 + maxPendingPersists) 否（默认为0，意味着一个持久化可以与摄取同时运行，而没有一个可以进入队列） indexSpec Object 调整数据被如何索引。详情可以见 IndexSpec 页面中的内容 N indexSpecForIntermediatePersists 定义要在索引时用于中间持久化临时段的段存储格式选项。这可用于禁用中间段上的维度/度量压缩，以减少最终合并所需的内存。但是，在中间段上禁用压缩可能会增加页缓存的使用，而在它们被合并到发布的最终段之前使用它们，有关可能的值。详情可以见 IndexSpec 页面中的内容。 N（默认= 与 indexSpec 相同） reportParseExceptions Boolean 已经丢弃（DEPRECATED）。如果为true，则在解析期间遇到的异常即停止摄取；如果为false，则将跳过不可解析的行和字段。将 reportParseExceptions 设置为 true 将覆盖maxParseExceptions 和 maxSavedParseExceptions 的现有配置，将maxParseExceptions 设置为 0 并将 maxSavedParseExceptions 限制为不超过1。 N（默认=false） handoffConditionTimeout Long 段切换（持久化）可以等待的毫秒数（超时时间）。 该值要被设置为大于0的数，设置为0意味着将会一直等待不超时。 N（默认=0） resetOffsetAutomatically Boolean 控制当Druid需要读取Kafka中不可用的消息时的行为，比如当发生了 OffsetOutOfRangeException 异常时。 如果为false，则异常将抛出，这将导致任务失败并停止接收。如果发生这种情况，则需要手动干预来纠正这种情况；可能使用 重置 Supervisor API 。此模式对于生产非常有用，因为它将使您意识到摄取的问题。如果为true，Druid将根据 useEarliestOffset 属性的值（true 为 earliest ，false 为 latest ）自动重置为Kafka中可用的较早或最新偏移量。请注意，这可能导致数据在您不知情的情况下被丢弃 （如果useEarliestOffset 为 false ）或 重复 （如果 useEarliestOffset 为 true ）。消息将被记录下来，以标识已发生重置，但摄取将继续。这种模式对于非生产环境非常有用，因为它将使Druid尝试自动从问题中恢复，即使这些问题会导致数据被安静删除或重复。该特性与Kafka的 auto.offset.reset 消费者属性很相似 N（默认=false） workerThreads Integer supervisor 用于为工作任务处理 请求/相应（requests/responses）异步操作的线程数。 N（默认=min(10, taskCount)） chatThreads Integer 与索引任务的会话线程数。 N（默认=10, taskCount * replicas)） chatRetries Integer 在任务没有响应之前，将重试对索引任务的HTTP请求的次数 N（默认=8） httpTimeout ISO8601 Period 索引任务的 HTTP 响应超时的时间。 N（默认=PT10S） shutdownTimeout ISO8601 Period supervisor 尝试无故障的停掉一个任务的超时时间。 N（默认=PT80S） offsetFetchPeriod ISO8601 Period supervisor 查询 Kafka 和索引任务以获取当前偏移和计算滞后的频率。 N（默认=PT30S，min == PT5S） segmentWriteOutMediumFactory Object 创建段时要使用的段写入介质。更多信息见下文。 N （默认不指定，使用来源于 druid.peon.defaultSegmentWriteOutMediumFactory.type 的值） intermediateHandoffPeriod ISO8601 Period 段发生切换的频率。当 maxRowsPerSegment 或者 maxTotalRows 有一个值命中的时候，则触发handoff（数据存盘后传到深度存储）， 该动作也会按照每 intermediateHandoffPeriod 时间间隔发生一次。 N（默认=P2147483647D） logParseExceptions Boolean 如果为 true，则在发生解析异常时记录错误消息，其中包含有关发生错误的行的信息。 N（默认=false） maxParseExceptions Integer 任务停止接收之前可发生的最大分析异常数。如果设置了 reportParseExceptions ，则该值会被重写。 N（默认=unlimited) maxSavedParseExceptions Integer 当出现解析异常时，Druid可以跟踪最新的解析异常。"maxSavedParseExceptions"决定将保存多少个异常实例。这些保存的异常将在 任务完成报告 中的任务完成后可用。如果设置了reportParseExceptions ，则该值会被重写。 N（默认=0)   https://www.ossez.com/t/druid-kafka-tuningconfig/13672

下面的表格主要对加载 Kafka 流数据的索引属性进行参数描述。     字段（Field） 类型（Type） 描述（Description） 是否必须（Required） bitmap Object 针对 bitmap indexes 使用的是压缩格式。应该是一个 JSON 对象，请参考 Bitmap types 来了解更多 N（默认=Roaring） dimensionCompression String 针对维度（dimension）列使用的压缩算法，请从 LZ4， LZF，或者 uncompressed 中选择。 N（默认= LZ4） metricCompression String 针对主要类型 metric 列使用的压缩算法，请从 LZ4， LZF，或者 uncompressed 中选择。 N（默认= LZ4） longEncoding String 类型为 long 的 metric 列和 维度（dimension）的编码格式。从 auto 或 long 中进行选择。auto 编码是根据列基数使用偏移量或查找表对值进行编码，并以可变大小存储它们。longs 将会按照，每个值 8 字节来进行存储。 N（默认= longs) https://www.ossez.com/t/druid-kafka-indexspec/13673

在使用 nvm 安装新的 nvm 版本之前，请确定你的操作系统中已经安装了 nvm。 安装的方法，请访页面：Windows 中 Node.js 中 nvm 的安装配置和使用 中的内容。 安装新版本 假设我们需要安装的新版本为 8.9.4，那么你需要执行命令 nvm install 8.9.4。     只需要等待一会就可以看到新的 nodejs 被安装成功了。 通过执行命令 nvm ls 来查看你的计算机中装了几个版本的 nodejs。     切换版本 对版本进行切换使用的命令为： nvm use 8.9.4 随后再可以使用 node -v 来查看当前系统中使用的 node 的版本。     至此，我们使用 nvm 对版本的安装和切换就已经完成了。   https://www.ossez.com/t/nvm-nodejs/13669

nvm 的安装还是比较简单的，主要是需要完成下载安装和路径配置即可。 首先可以使用命令 nvm 来查看当前系统中有没有安装 nvm。 下载安装 可以访问下面的地址来找到最新的 nvm 的安装版本： Releases · coreybutler/nvm-windows · GitHub 需要下载的程序通常为：nvm-setup.zip     下载完成后双击运行进行安装。 安装过程 下面对安装的过程进行一些说明和配置。 同意许可协议 选择安装路径 在安装的时候，使用默认的安装路径就可以了。 选择 nodejs 的安装路径 一般来说，我们都会使用默认安装，在这里也不需要进行修改。 安装摘要 显示已有的 nodejs 安装 在这里将会提示你是否使用 nvm 对已安装的 nodejs 进行配置。 如果需要的话，选择 Yes，通常我们选择 Yes 就好。 安装进程 安装过程很快，通常一会就能安装好了。 安装完成 如果能够看到下面的图片，就说明安装已经完成了。 单击完成退出安装程序。 校验安装 重新打开一个控制台工具，在控制台工具中输入命令 nvm ls，如果能够看到当前的 nodejs 版本的话，则说明 nvm 已经配置好了。 通常来说你并不需要主动将 nvm 的可执行文件添加到 path 路径中，如果这里你还提示没有可以执行的命令的话，你需要尝试退出下你的控制台，再次启动。 如果还有问题的话，请查看下你的 nvm 可执行文件是不是在你的 PATH 路径中。     查看可用的 nodejs 版本 执行命令：nvm ls available 能够查看可用的 nvm 版本。     然后你可以通过选择可用的版本进行安装。 https://www.ossez.com/t/windows-node-js-nvm/13668

从字面上面就可以理解上面 2 个定义的不同。 如果要直接解释就是： Node.js：NodeJS 项目开发需要使用的解释器 npm：随着 Node.js 一同安装的包管理器（主要用来管理包）。 nvm：需要单独安装，主要对项目使用的 Node.js 解释器进行管理。 用土话说，因为有 P，所以管理包（Package），因为有 V，所以管理版本（V）。 但是 Node.js 又不自带版本管理器，因此需要一个其他的一个程序来管理，这个程序是需要安装的，这就是为什么 nvm 需要单独安装的原因了。 来源就是狗日的 Node.js 的版本迭代速度太快，加上 JS 使用的包管理器没有 maven 那么优雅，自然就会导致一套系统中部署不同的 Node.js 版本，更加讨厌的是各个版本直接还没有办法直接兼容。     那就需要开发人员不同的切换版本，nvm 就为了满足这个需求而存在的。   https://www.ossez.com/t/npm-nvm/13667

Kafka 索引服务（indexing service）支持 inputFormat 和 parser 来指定特定的数据格式。 inputFormat 是一个较新的参数，针对使用的 Kafka 索引服务，我们建议你对这个数据格式参数字段进行设置。 不幸的是，目前还不能支持所有在老的 parser 中能够支持的数据格式（Druid 将会在后续的版本中提供支持）。 目前 inputFormat 能够支持的数据格式包括有： csv， delimited， json。 如果你使用 parser 的话，你也可以阅读： avro_stream, protobuf, thrift 数据格式。     因为 Druid 的数据版本的更新，在老的环境下，如果使用 parser 能够处理更多的数格式。 如果通过配置文件来定义的话，在目前只能处理比较少的数据格式。 在我们的系统中，通常将数据格式定义为 JSON 格式，但是因为 JSON 的数据是不压缩的，通常会导致传输数据量增加很多。     如果你想使用 protobuf 的数据格式的话，能够在 Kafka 中传递更多的内容，protobuf 是压缩的数据传输，占用网络带宽更小。 在小型系统中可能不一定会有太大的问题，但是对于大型系统来说，如果传输量小 80% 的话，那占用网络带宽也会小很多，另外也能降低错误率。   https://www.ossez.com/t/druid-kafka/13666

可用的字段和配置信息，请参考表格。 需要注意的是配置的段的定义为为： ioConfig 字段（Field） 类型（Type） 描述（Description） 是否必须（Required） topic String 从 Kafka 中读取数据的 主题（topic）名。你必须要指定一个明确的 topic。例如 topic patterns 还不能被支持。 Y inputFormat Object inputFormat 被指定如何来解析处理数据。请参考 the below section 来了解更多如何指定 input format 的内容。 Y consumerProperties Map<String, Object> 传递给 Kafka 消费者的一组属性 map。这个必须包含有一个 bootstrap.servers 属性。这个属性的值为： <BROKER_1>:<PORT_1>,<BROKER_2>:<PORT_2>,... 这样的服务器列表。针对使用 SSL 的链接： keystore， truststore，key 可以使用字符串密码，或者使用 Password Provider 来进行提供。 Y pollTimeout Long Kafka 消费者拉取数据等待的时间。单位为：毫秒（milliseconds）The length of time to wait for the Kafka consumer to poll records, in N（默认=100）） replicas Integer 副本的数量， 1 意味着一个单一任务（无副本）。副本任务将始终分配给不同的 workers，以提供针对流程故障的恢复能力。 否（no）（默认值：1） taskCount Integer 在一个 replica set 集中最大 reading 的数量。这意味着读取任务的最大的数量将是 taskCount * replicas, 任务总数（reading + publishing）是大于这个数值的。请参考 Capacity Planning 中的内容。如果 taskCount > {numKafkaPartitions} 的话，总的 reading 任务数量将会小于 taskCount 。 N（默认=1）） taskDuration ISO8601 Period 任务停止读取数据并且将已经读取的数据发布为新段的时间周期 N（默认=PT1H） startDelay ISO8601 Period supervisor 开始管理任务之前的等待时间周期。 N（默认=PT1S） period ISO8601 Period supervisor 将要执行管理逻辑的时间周期间隔。请注意，supervisor 将会在一些特定的事件发生时进行执行（例如：任务成功终止，任务失败，任务达到了他们的 taskDuration）。因此这个值指定了在在 2 个事件之间进行执行的最大时间间隔周期。 N（默认=PT30S） useEarliestOffset Boolean 如果 supervisor 是第一次对数据源进行管理，supervisor 将会从 Kafka 中获得一系列的数据偏移量。这个标记位用于在 Kafka 中确定最早（earliest）或者最晚（latest）的偏移量。在通常使用的情况下，后续的任务将会从前一个段结束的标记位开始继续执行，因此这个参数只在 supervisor 第一次启动的时候需要。 否（no）（默认值： false） completionTimeout ISO8601 Period 声明发布任务为失败并终止它 之前等待的时间长度。如果设置得太低，则任务可能永远不会发布。任务的发布时刻大约在 taskDuration (任务持续)时间过后开始。 N（默认=PT30M） lateMessageRejectionStartDateTime ISO8601 DateTime 用来配置一个时间，当消息时间戳早于此日期时间的时候，消息被拒绝。例如我们将这个时间戳设置为 2016-01-01T11:00Z 然后 supervisor 在 2016-01-01T12:00Z 创建了一个任务，那么早于 2016-01-01T11:00Z 的消息将会被丢弃。这个设置有助于帮助避免并发（concurrency）问题。例如，如果你的数据流有延迟消息，并且你有多个需要在同一段上操作的管道（例如实时和夜间批处理摄取管道）。 N（默认=none） lateMessageRejectionPeriod ISO8601 Period 配置一个时间周期，当消息时间戳早于此周期的时候，消息被拒绝。例如，如果这个参数被设置为 PT1H 同时 supervisor 在 2016-01-01T12:00Z 创建了一个任务，那么所有早于 2016-01-01T11:00Z 的消息将会被丢弃。 个设置有助于帮助避免并发（concurrency）问题。例如，如果你的数据流有延迟消息，并且你有多个需要在同一段上操作的管道（例如实时和夜间批处理摄取管道）。请注意 lateMessageRejectionPeriod 或者 lateMessageRejectionStartDateTime 2 个参数只能指定一个，不能同时赋值。 N（默认=none） earlyMessageRejectionPeriod ISO8601 Period 用来配置一个时间周期，当消息时间戳晚于此周期的时候，消息被拒绝。例如，如果这个参数被设置为 PT1H，taskDuration 也被设置为 PT1H，然后 supervisor 在 2016-01-01T12:00Z 创建了一个任务，那么所有晚于 2016-01-01T14:00Z 的消息丢会被丢弃，这是因为任务的执行时间为 1 个小时，earlyMessageRejectionPeriod 参数的设置为 1 个小时，因此总计需要等候 2 个小时。 注意： 任务有时候的执行时间可能会超过任务 taskDuration 参数设定的值，例如，supervisor 被挂起的情况。如果设置 earlyMessageRejectionPeriod 参数过低的话，在任务的执行时间超过预期的话，将会有可能导致消息被意外丢弃。 N（默认=none） 如上面表格的配置信息，我们可以对 Kafka 中的配置进行一些调整来满足特定的项目消息需求。     如果你对需要调整的默认值不是非常了解和清楚的话，可以使用默认值，通常默认值不是最优的，但是可能是能够保障能正确工作的最低配置。   https://www.ossez.com/t/druid-kafka-kafkasupervisorioconfig/13665

在 Supervisor 中可用的 Kafka 配置表如下： 字段（Field） 描述（Description） 是否必须（Required） type supervisor 的类型，总是 kafka 字符串。 Y dataSchema Kafka 索引服务在对数据进行导入的时候使用的数据 schema。请参考 dataSchema 页面来了解更多信息 Y ioConfig 一个 KafkaSupervisorIOConfig 对象。在这个对象中我们对 supervisor 和 索引任务（indexing task）使用 Kafka 的连接参数进行定义；对 I/O-related 进行相关设置。请参考本页面下半部分 KafkaSupervisorIOConfig 的内容。 Y tuningConfig 一个 KafkaSupervisorTuningConfig 对象。在这个配置对象中，我们对 supervisor 和 索引任务（indexing task）的性能进行设置。请参考本页面下半部分 KafkaSupervisorTuningConfig 的内容。 N 主要是用于对 Kafka 的消息的一些基本配置进行描述。     上图显示了一个配置的信息情况。   https://www.ossez.com/t/druid-kafka-supervisor/13664

Druid 的 Kafka 索引服务（Kafka indexing service）将会在 Overlord 上启动并配置 supervisors， supervisors 通过管理 Kafka 索引任务的创建和销毁的生命周期以便于从 Kafka 中载入数据。 这些索引任务使用Kafka自己的分区和偏移机制读取事件，因此能够保证只读取一次（exactly-once）。 supervisor 对索引任务的状态进行监控，以便于对任务进行扩展或切换，故障管理等操作。 这个服务是由 druid-kafka-indexing-service 这个 druid 核心扩展（详情请见 扩展列表提供的。 Kafka索引服务支持在 Kafka 0.11.x 中开始使用的事务主题。这些更改使 Druid 使用的 Kafka 消费者与旧的 Kafka brokers 不兼容。 在使用 Druid 从 Kafka中导入数据之前，请确保你的 Kafka 版本为 0.11.x 或更高版本。 如果你使用的是旧版本的 Kafka brokers，请参阅《 Kafka升级指南 》中的内容先进行升级。 教程 针对使用 Apache Kafka 数据导入中的参考文档，请访问 Loading from Apache Kafka 页面中的教程。 exactly-once 语义 从理论上来说，Exactly-once delivery是不可能的，它的代价太高无法实际应用到生产环境，包括业内的大牛Mathias Verroaes也这么认为，它是分布式系统中最难解决的唯二问题： 但现在，我并不认为引入 Exactly-once delivery 并且支持流处理是一个真正难以解决的问题。首先，让我们来概述下消息的精确提交语义。 消息语义概述 在分布式系统中，构成系统的任何节点都是被定义为可以彼此独立失败的。比如在 Kafka中，broker可能会crash，在producer推送数据至topic的过程中也可能会遇到网络问题。根据producer处理此类故障所采取的提交策略类型，我们可以获得不同的语义： at-least-once：如果producer收到来自Kafka broker的确认（ack）或者acks = all，则表示该消息已经写入到Kafka。但如果producer ack超时或收到错误，则可能会重试发送消息，客户端会认为该消息未写入Kafka。如果broker在发送Ack之前失败，但在消息成功写入Kafka之后，此重试将导致该消息被写入两次，因此消息会被不止一次地传递给最终consumer，这种策略可能导致重复的工作和不正确的结果。 at-most-once：如果在ack超时或返回错误时producer不重试，则该消息可能最终不会写入Kafka，因此不会传递给consumer。在大多数情况下，这样做是为了避免重复的可能性，业务上必须接收数据传递可能的丢失。 exactly-once：即使producer重试发送消息，消息也会保证最多一次地传递给最终consumer。该语义是最理想的，但也难以实现，这是因为它需要消息系统本身与生产和消费消息的应用程序进行协作。例如如果在消费消息成功后，将Kafka consumer的偏移量rollback，我们将会再次从该偏移量开始接收消息。这表明消息传递系统和客户端应用程序必须配合调整才能实现excactly-once。     exactly-once 语义是在 Kafka 0.11.x 中引入的，因此 Druid 要求导入的 Kafka 版本需要在 0.11.x 以上，以便于实现 exactly-once 语义。   https://www.ossez.com/t/druid-kafka-kafka/13663