聚合数据

默认情况下，Map阶段结束后，相同Key的数据分发到一个reduce，当同一key数据量过大时就产生数据倾斜了。并不是所有的聚合操作都必要在Reduce端完成，很多聚合操作都可以先在Map端进行部分聚合，最后在Reduce端得出最终结果 开启Map端聚合参数设置 是否在Map端进行聚合，默认为True： hive.map.aggr = true 在Map端进行聚合操作的条目数目： hive.groupby.mapaggr.checkinterval = 100000 有数据倾斜的时候进行负载均衡（默认是false）： hive.groupby.skewindata = true 当选项设定为 true，生成的查询计划会有两个MR Job。第一个MR Job中，Map的输出结果会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同Key的数据有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MR Job再根据预处理的数据结果按照Key分布到Reduce中（这个过程可以保证相同Key的数据分布到同一个Reduce中），最后完成最终的聚合操作 来源： https://www.cnblogs.com/xiangyuguan/p/11411603.html

搭建集群： SPARK_WORKER-CORES : 当计算机是32核双线程的时候，需要指定SPARK_WORKER_CORES的个数为64个 SPARK_WORKER_MEMORY : 任务提交： ./spark-submit --master node:port --executor-cores --class ..jar xxx --executor-cores: 指定每个executor使用的core 的数量 --executor-memory: 指定每个executor最多使用的内存 --total-executor-cores: standalone 集群中 spark application 所使用的总的core --num-executor ： 在yarn 中为 spark application 启动的executor --Driver-cores: driver使用的core --Driver-memory： driver使用的内存 以上的参数是在spark-submit 提交任务的时候指定的，也可以在spark-defaults.xml中进行配置 spark 并行度调优： (一般在做测试的时候使用) sc.textFile(xx,minnum) sc.parallelize(seq,num) sc.makeRDD(seq,num) sc

图形 概述 随着大量的监控数据被采集到Zabbix中，如果用户可以以可视化的表现形式来查看发生了什么事情，那么和仅仅只有数字的表现形式比起来则更加轻松。 以下是进行图形设置的地方。图形可以一目了然地掌握数据的流向并关联问题，发现某件事情开始，或在某件事情可能变成问题事件时进行报告。 Zabbix为用户提供了如下几种图形： 监控项数据的内置简单图形simple graphs; 可能创建更发杂的自定义图形custmomised graphs; 在最新数据中，可以利用特定图形ad-hoc graphs快速访问几个监控项的数据比较 1 简单图形 Overview Zabbix提供了简单图形，用来可视化显示监控项采集到的数据。 对于用户而言，并不需要进行配置就可以查看简单图形。这是由Zabbix免费提供的。 通过 Monitoring → Latest data 点击各自监控项的图形链接，就可以展示图形。 时间段选择器 注意图形上方的时间段选择器。它允许你可以轻松选择所需的时间段。 时间段选择器中的滑动快可以来回拖动，以及缩放，使之更有效地改变展示的时间段。左侧的链接允许选择一些常用的预定义时间段（在滑动区域的上方），并点击时间段的链接来回移动（滑动区域的下方）。通过右侧的时间链接，点击可以弹出日历设置特定的开始/结束时间。 在右下角的 fixed/dynamic 链接具有以下效果:

聚合器是一种 AWS Config 资源类型，用于从以下内容收集 AWS Config 配置和合规性数据： 多个账户和多个区域。 单个账户和多个区域。 AWS Organizations 中的组织和该组织中的所有账户。 使用聚合器查看在 AWS Config 中记录的资源配置和合规性数据。 有关概念的更多信息，请参阅“概念”主题中的 多账户多区域数据聚合 部分。 要从源账户和区域收集您的 AWS Config 数据，请从以下操作开始： 添加聚合器以从多个账户和区域聚合 AWS Config 配置和合规性数据。 授权聚合器账户收集 AWS Config 配置和合规性数据。当源账户是单个账户时，需要授权。如果要聚合的源账户是 AWS Organizations 的一部分，则不需要授权。 在聚合视图中监控规则和账户的合规性数据。 区域支持 目前，多账户多区域数据聚合在以下区域中受支持： 区域名称 区域 终端节点 协议 亚太地区（孟买） ap-south-1 config.ap-south-1.amazonaws.com HTTPS 亚太区域（首尔） ap-northeast-2 config.ap-northeast-2.amazonaws.com HTTPS 亚太区域（新加坡） ap-southeast-1 config.ap-southeast-1.amazonaws.com

今天，大数据、数据科学、机器学习分析不再只是热词，已经真实地渗透于生活方方面面。根据福布斯，到2025年，全球每年将会有 175 泽字节的数据产生。Kyligence的诞生为企业带来了极速的大数据分析体验 。 当企业要对大规模的数据进一步进行更为复杂的分析如对销售额进行预测时，传统的分析工具就捉襟见肘了 。 这篇文章将以基于Spark的分布式机器学习平台 Databricks为例，为您提供一套从以 Kyligence 为数据源到分布式数据分析平台的高效无缝的解决方案。 对企业未来销量进行预测是一个很普遍的分析需求。分析师需要先以不同的时间粒度如日或月，或者是其他维度粒度如地区，商品等聚合数据，然后按不同的算法预测聚合后的数据。相类似的预测、分析场景还有很多，如运维数据的异常值检测，金融数据的反欺诈识别，销售数据的用户画像等。在数据被深入挖掘之前，都需按维度列或时间戳聚合数据。然而想顺滑地聚合如此海量的数据，并且深入挖掘数据并不简单。 对海量数据进行挖掘的难点 聚合大量数据，复杂度高，所耗时间长 当数据量呈规模式增加时，即使是执行一条简单的筛选查询也会消耗很多时间，并且查询语句复杂度越大，执行语句所花时间就会越长。因此，数据科学家稍调整筛选条件，就会重新陷入等待中。 分析维度的粒度很难随意变动 由于高额的查询成本，数据科学家们会更倾向于聚合有潜在关联的数据维度

这部分主要讲一下用的过程中不太明白的概念啥的，主要参考 官网 和 OpenTSDB使用总结 1. downSample重采样 有时候每秒打一个点，展示这么多数据会显得很乱，通常也不需要这样精确的数据。可以使用降精度的方式将一段时间的数据点聚合后当作一个数据点，比如将每个小时的数据聚合为1个数据点，这样就会只显示168个数据点，如果查询的话可以根据时间范围选定降精度的粒度。 1 public static String getDownSampler(long start, long end) { 2 String downSampler; 3 if (end - start < 24 * 60 * 60 * 1000L) { // 一天 4 downSampler = 1m-avg; 5 } else if (end - start < 604800000) { // 一周 6 downSampler = 5m-avg; 7 } else { 8 downSampler = 30m-avg; 9 } 10 return downSampler; 11 } 2. aggregator aggregator在降精度downsample和多条时间线聚合时使用，通过算子将多个数据点汇聚成一个数据点，比如avg、sum。 来源： https://www.cnblogs.com

机器学习的模型训练越来越自动化，但特征工程还是一个漫长的手动过程，依赖于专业的领域知识，直觉和数据处理。而特征选取恰恰是机器学习重要的先期步骤，虽然不如模型训练那样能产生直接可用的结果。本文作者将使用Python的featuretools库进行自动化特征工程的示例。 机器学习越来越多地从手动设计模型转变为使用H20，TPOT和auto-sklearn等工具来自动优化的渠道。这些库以及随机搜索等方法旨在通过查找数据集的最优模型来简化模型选择和转变机器学习的部分，几乎不需要人工干预。然而，特征工程几乎完全是人工，这无疑是机器学习管道中更有价值的方面。 特征工程也称为特征创建，是从现有数据构建新特征以训练机器学习模型的过程。这个步骤可能比实际应用的模型更重要，因为机器学习算法只从我们提供的数据中学习，然而创建与任务相关的特征绝对是至关重要的。 通常，特征工程是一个漫长的手动过程，依赖于专业的领域知识，直觉和数据处理。这个过程可能非常繁琐，而且最终的特征将受到人类主观性和时间的限制。自动化特征工程旨在通过从数据集中自动创建许多候选特征来帮助数据科学家，并从中可以选择最佳特征用于训练。 在本文中，我们将使用Python 的featuretools库进行自动化特征工程的示例。我们将使用示例数据集来演示基础知识。 Python资源共享群：484031800 _Engineering.ipynb

前言 今天是个开心的日子，又是周末，可以轻轻松松的写写文章了。去年，我写了ENode 1.0版本，那时我也写了一个 分析系列 。经过了大半年的时间，我对第一个版本做了很多架构上的改进，最重要的就是让ENode实现了分布式，通过新增一个分布式消息队列 EQueue 来实现。之所以要设计一个分布式的消息队列是因为在enode 1.0版本中，某个特定的消息队列只能被某个特定的消费者消费。这样就会导致一个问题，就是如果这个消费者挂了，那这个消费者对应的消息队列就不能自动被其他消费者消费了。这个问题会直接导致系统不可用。而ENode 2.0中，就不会有这个问题了，因为消息队列被设计为独立的，被消费者所共享的；一个消息队列可以被多个消费者集群消费或广播消费，如果一个消费者挂了，那其他的消费者会自动顶上。这里具体的细节，我会在后面详细介绍。 ENode框架简介 框架名称：ENode 框架特色： DDD+CQRS + EDA + Event Sourcing + In Memory 设计目标：让程序员只关注业务代码、高性能、分布式、可水平扩展 开源地址： https://github.com/tangxuehua/enode 基于enode实现的一个完成案例，一个论坛： https://github.com/tangxuehua/forum nuget包Id：ENode

目录 Elastic Search Docker中安装ElasticSearch Elastic Search API得使用 创建Index: 修改Index Mapping: 修改Index Settings: 创建Index模板: 单条件查询: [query->term] 多条件查询: [query->bool->must->term] 对查询结果进行折叠去重一个字段: [collapse] 对查询结果进行折叠去重两个字段: [collapse->inner_hits->collapse] 对查询结果进行聚合实现Group BY: [aggerations] 对查询结果进行聚合最大值/最小值: [aggs->min/max] 对查询结果进行聚合时，需要使用其他数据: [aggs->top_hits] 在查询Payload中写逻辑运算: [script] 在更新Payload中写逻辑运算: [script] 依据查询条件进行更新 依据查询条件进行删除 简单得分页查询：[from size] 复杂得分页查询：[scroll] 多条插入数据：[_bulk] 重新索引：[reindex] 查看所有index：[_cat/indices/] 设置Cluster：[_cluster] 删除所有生成的Scroll 已知文档Id情况下存在更新，不存在插入数据[update] 提高 ES效率

参考链接：https://blog.csdn.net/u010454030/article/details/71762838 ES group分组聚合的坑 原来知道Elasticsearch在分组聚合时有一些坑但没有细究，今天又看了遍顺便做个笔记和大家分享一下。 我们都知道Elasticsearch是一个分布式的搜索引擎，每个索引都可以有多个分片，用来将一份大索引的数据切分成多个小的物理索引，解决单个索引数据量过大导致的性能问题，另外每个shard还可以配置多个副本，来保证高可靠以及更好的抗并发的能力。 将一个索引切分成多个shard，大多数时候是没有问题的，但是在es里面如果索引被切分成多个shard，在使用group进行聚合时，可能会出现问题，这个在官网文档里，描述也非常清楚 https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html#_shard_size_3 下面就针对官网的例子，描述下，group count如果有多个shard可能会出现的问题 假设我们现在，我们有一份商品的索引数据，它有3个shard，每个shard的数据如下所示： 现在我们的需求是，按商品分组求top5的商品，es收到这个请求后