精华内容
下载资源
问答
  • 总第391篇2020年 第14篇美团自研的 OCTO 数据中心(简称 Watt)日均处理万亿数据量,该系统具备较好的扩展能力及实时性,千台实例集群周运维成本低于10分钟。本文将详细阐述...

    美团自研的 OCTO 数据中心(简称 Watt)日均处理万亿级数据量,该系统具备较好的扩展能力及实时性,千台实例集群周运维成本低于10分钟。

    本文将详细阐述 Watt 计算引擎的演进历程及架构设计,同时详细介绍其全面提升计算能力、吞吐能力、降低运维成本所采用的各项技术方案。希望能给大家一些启发或者帮助。

    一、OCTO数据中心简介

    1.1 系统介绍

    1.1.1 OCTO系统介绍

    OCTO 是美团标准化的服务治理基础设施,目前几乎覆盖公司所有业务的治理与运营。OCTO 提供了服务注册发现、数据治理、负载均衡、容错、灰度发布等治理功能,致力于提升研发效率,降低运维成本,并提升应用的稳定性。OCTO 最新演进动态细节可参考《美团下一代服务治理系统 OCTO2.0 的探索与实践》一文。

    1.1.2 OCTO数据中心业务介绍

    OCTO 数据中心为业务提供了立体化的数字驱动服务治理能力,提供了多维度的精确时延 TP(Top Percent,分位数,最高支持6个9)、QPS、成功率等一系列核心指标,粒度方面支持秒级、分钟级、小时级、天级,检索维度支持多种复杂查询(如指定调用端 IP + 服务端各接口的指标,指定主机 + 接口的指标等)。这些功能有效地帮助开发人员在复杂的分布式调用关系拓扑内出现异常时,能快速定位到问题,也有助于研发人员全方位掌控系统的稳定性状况。

    目前 Watt 承载日均超万亿条数据的10余个维度精确准实时统计。而伴随着数据量的迅猛增长,其整个系统架构也经历了全面的技术演进。

    1.1.3 OCTO原架构介绍

    OCTO计算引擎在重构之前,也面临诸多的问题,其原始架构设计如下:

    1. 采集层:每个业务应用实例部署一个采集代理,代理通过将采集数据用批量 RPC 的方式发送给路由节点。

    2. 路由层:每个路由节点随机收到各服务的数据后,将同一服务的所有数据,用类似 IP 直连的方式通过 RPC 发送到计算层的同一个计算节点。同服务数据汇总到同计算节点才能进行特定服务各个维度的聚合计算。

    3. 计算层:每个计算节点采用 Akka 模型,节点同时负责分钟、小时、天粒度的数据计算集。每个计算集里面又有10个子计算 actor,每个子计算 actor 对应的是一个维度。采用“先计算指标,再存储数据”的准实时模式。

    4. 存储层:准实时数据使用 HBase 存储,元数据及较大数据采用 KV 存储(美团内部系统Cellar)及 MySQL 存储。

    1.2 问题、目标与挑战

    1.2.1 原架构面临的问题

    1. 计算节点有状态,异常无法自动化迁移。计算层部署的每个节点平均负责200+服务的统计。一个节点 OOM 或宕机时,其管理的200个服务的数据会丢失或波动,报警等依托数据的治理功能也会异常。此外计算节点 OOM 时也不宜自动迁移受影响的服务,需人工介入处理(异常的原因可能是计算节点无法承载涌入的数据量,简单的迁移易引发“雪崩”),每周投入的运维时间近20小时。

    2. 系统不支持水平扩展。计算节点的压力由其管理的服务调用量、服务内维度复杂度等因素决定。大体量的服务需单独分配高配机器,业务数据膨胀计算节点能力不匹配时,只能替换更高性能的机器。

    3. 系统整体稳定性不高。数据传输采用 RPC,单计算节点响应慢时,易拖垮所有路由层的节点并引发系统“雪崩”。

    4. 热点及数据倾斜明显,策略管理复杂。按服务划分热点明显,存在一个服务数据量比整个计算节点200个服务总数多的情况,部分机器的 CPU 利用率不到10%,部分利用率在90%+。改变路由策略易引发新的热点机器,大体量服务数据增长时需要纵向扩容解决。旧架构时人工维护160余个大服务到计算节点的映射关系供路由层使用。

    旧架构日承载数据量约3000亿,受上述缺陷影响,系统会频繁出现告警丢失、误告警、数据不准、数据延迟几小时、服务发布后10分钟后才能看到流量等多种问题。此外,数据体量大的服务也不支持部分二级维度的数据统计。

    1.2.2 新架构设计的目标

    基于上述问题总结与分析,我们新架构整体的目标如下:

    1. 高吞吐、高度扩展能力。具备20倍+的水平扩展能力,支持日10万亿数据的处理能力。

    2. 数据高度精确。解决节点宕机后自愈、解决数据丢失问题。

    3. 高可靠、高可用。无计算单点,所有计算节点无状态;1/3计算节点宕机无影响;具备削峰能力。

    4. 延时低。秒级指标延迟TP99<10s;分钟指标延迟TP99<2min。

    1.2.3 新架构面临的挑战

    在日计算量万亿级别的体量下,实现上述挑战如下:

    1. 数据倾斜明显的海量数据,数据指标的维度多、指标多、时间窗口多,服务间体量差异达百万倍。

    2. TP分位数长尾数据是衡量系统稳定性最核心的指标,所有数据要求非采样拟合,实现多维度下精确的分布式TP数据。

    3. 架构具备高稳定性,1/3节点宕机不需人工介入。

    4. 每年数据膨胀至2.4倍+,计算能力及吞吐能力必须支持水平扩展。

    5. TP 数据是衡量服务最核心的指标之一,但在万亿规模下,精确的准实时多维度分布式 TP 数据是一个难题,原因详细解释下:

    常规的拆分计算后聚合是无法计算精确TP数据的,如将一个服务按 IP(一般按 IP 划分数据比较均匀)划分到3个子计算节点计算后汇总,会面临如下问题:

    • 假设计算得出 IP1 的 TP99 是100ms、QPS 为50;IP2 的 TP99 是10ms、QPS 为50;IP3 的 TP99 是1ms,QPS为50。那么该服务整体 TP99 是(100ms x 50 + 10ms x 50 + 1ms x 50)/ (50 + 50 + 50) = 37ms吗?并非如此,该服务的真实 TP99 可能是 100ms,在没有全量样本情况下无法保证准确的TP值。

    • 假设不需要服务全局精确的时延 TP 数据,也不可以忽略该问题。按上述方式拆分并合并后,服务按接口维度计算的 TP 数据也失去了准确性。进一步说,只要不包含 IP 查询条件的所有 TP 数据都失真了。分位数这类必须建立在全局样本之上才能有正确计算的统计值。

    二、计算引擎技术设计解析

    2.1 方案选型

    大数据计算应用往往基于实时或离线计算技术体系建设,但Flink、Spark、OLAP等技术栈在日超万亿级别量级下,支持复杂维度的准实时精确 TP 计算,对资源的消耗非常较大,总结如下:

    2.2 系统设计思路

    1. 解决稳定性问题,思路是(1)将计算节点无状态化(2)基于心跳机制自动剔除异常节点并由新节点承载任务(3)消息队列削峰。

    2. 解决海量数据计算问题,思路是(1)在线&离线计算隔离,两者的公共子计算前置只计算一次(2)高并发高吞吐能力设计(3)理论无上限的水平扩展能力设计。

    3. 解决热点问题,思路是(1)优化计算量分配算法,如均衡 Hash(2)理论无上限的水平扩展能力设计。

    4. 解决水平扩展问题,思路(1)是将单节点无法承载的计算模式改为局部分布式子计算并汇总,但这种方式可能会对数据准确性造成较大影响,数据统计领域精确的分布式分位数才是最难问题,另外多维条件组织对分布式改造也相当不利。(备注:其中在1.2.3第五条有详细的解释)

    5. 解决海量数据分布式多维精确 TP 计算,采用局部分布式计算,然后基于拓扑树组织数据计算流,在前置的计算结果精度不丢失的前提下,多阶段逐级降维得到所有的计算结果。

    2.3 技术方案详细解析

    2.3.1 数据流解析

    系统根据待统计的维度构建了一棵递推拓扑树,如下图所示。其中黄色的部分代表消息队列(每个矩形代表一个 topic),绿色部分代表一个计算子集群(消费前置 topic 多个 partition,统计自己负责维度的数据指标并存储,同时聚合压缩向后继续发)。除“原始采集数据 topic 外”,其他 topic 和 consumer 所在维度对应数据的检索条件(如标红二级 topic :主机+接口,代表同时指定主机和接口的指标查询数据),红色箭头代表数据流向。

    拓扑树形结构的各个子集群所对应的维度标识集合,必为其父计算集群对应维度标识集合的真子集(如下图最上面链路,“主机+接口+远程服务”3个维度一定包含“主机+接口”两个维度。“主机+接口”两个维度包含“主机”维度)。集群间数据传输,采用批量聚合压缩后在消息队列媒介上通信完成,在计算过程中实现降维。

    2.3.2 计算模式解析

    下面详细介绍数据拓扑树中分布式子集群的计算模式:

    首先,维度值相同的所有数据会在本层级集群内落到同一计算节点。每个计算子集群中的各计算节点,从消息队列消费得到数据并按自身维度进行聚合(前置集群已经按当前集群维度指定分发,所以聚合率很高),得到若干计数卡表(计数卡表即指定维度的时延、错误数等指标与具体计数的映射 Map)。

    其次,将聚合后的计数卡表与现有的相同维度合并计算,并在时间窗口存储指标。

    若计算集群有后续的子计算集群,则基于后继集群的目标维度,根据目标维度属性做散列计算,并将相同散列码的计数卡表聚合压缩后发到后继 partition。

    离线的天级计算复用了三级维度、二级维度的多项结果,各环节前面计算的结果为后面多个计算集群复用,任何一个服务的数据都是在分布式计算。此外,整个计算过程中维护着技术卡表的映射关系,对于 TP 数据来说就是精确计算的,不会失真。

    整个计算过程中,前置计算结果会被多个直接及间接后续子计算复用(如三级聚合计算对二级和一级都是有效的),在很大程度上减少了计算量。

    2.3.3 关键技术总结

    1. 高吞吐 & 扩展性关键设计

    • 去计算热点:组织多级散列数据流,逐级降维。

    • 降计算量:前置子计算结果复用,分布式多路归并。

    • 降网络IO,磁盘IO:优化 PB 序列化算法,自管理 MQ 批量。

    • 去存储热点:消除 HBase Rowkey 热点。

    • 无锁处理:自研线程分桶的流批处理模型,全局无锁。

    • 全环节水平扩展:计算、传输、存储均水平扩展。

    2. 系统高可靠、低运维、数据准确性高于5个9关键设计

    • 无状态化 + 快速自愈:节点无状态化,宕机秒级感知自愈。

    • 异常实时感知:异常节点通过心跳摘除,异常数据迁移回溯。

    • 故障隔离容灾:各维度独立隔离故障范围;多机房容灾。

    • 逐级降维过程中数据不失真,精确的 TP 计算模式。

    3. 提升实时性关键设计

    • 流式拓扑模型,分布式子计算结果复用,计算量逐级递减。

    • 无锁处理:自研线程分桶的流批处理模型,全局无锁。

    • 异常实时监测自愈:计算节点异常时迅速 Rebalance,及时自愈。

    • 秒级计算流独立,内存存储。

    三、优化效果

    1. 目前日均处理数据量超万亿,系统可支撑日10万亿+量级并具备良好的扩展能力;秒峰值可处理5亿+数据;单服务日吞吐上限提升1000倍+,单服务可以支撑5000亿数据计算。

    2. 最大时延从4小时+降低到2min-,秒级指标时延 TP99 达到 6s;平均时延从4.7分+降低到1.5分-,秒级指标平均时延6s。

    3. 上线后集群未发生雪崩,同时宕机1/3实例2秒内自动化自愈。

    4. 支持多维度的准实时精确 TP 计算,最高支持到 TP 6个9;支持所有服务所有维度统计。

    5. 千余节点集群运维投入从周20小时+降低至10分以下。

    四、总结

    本文提供了一种日均超万亿规模下多维度精确 TP 计算的准实时数据计算引擎方案,适用于在超大规模数字化治理体系建设中,解决扩展性、实时性、精确性、稳定性、运维成本等问题。美团基础研发平台欢迎业界同行一起交流、探讨。

    五、作者简介

    继东,业祥,成达,张昀,均来自美团基础架构服务治理团队,研发工程师。

    ----------  END  ----------

    招聘信息

    美团基础架构团队诚招高级、资深技术专家,Base 北京、上海。我们致力于建设美团全公司统一的高并发高性能分布式基础架构平台,涵盖数据库、分布式监控、服务治理、高性能通信、消息中间件、基础存储、容器化、集群调度等基础架构主要的技术领域。欢迎有兴趣的同学投送简历到 tech@meituan.com(邮件标题注明:美团基础架构团队)。

    也许你还想看

    美团下一代服务治理系统 OCTO2.0 的探索与实践

    美团大规模微服务通信框架及治理体系OCTO核心组件开源

    美团容器平台架构及容器技术实践

    展开全文
  • Matt Abrams表示,AddThis仅仅了1.5KB内存的内存就计算了十亿个不同的对象,这与他们所使用计算方法分不开的。 AddThis(前身为Clearspring)的数据分析副总监Matt Abrams在High Scalabili
    摘要:AddThis的数据分析副总监Matt Abrams在High Scalability上发表了一篇文章,介绍了他们公司如何应对大数据。Matt Abrams表示,AddThis仅仅用了1.5KB内存的内存就计算了十亿个不同的对象,这与他们所使用的计算方法分不开的。

    AddThis(前身为Clearspring)的数据分析副总监Matt AbramsHigh Scalability上发表了一篇文章,介绍了他们公司如何应对大数据。在这篇文章中,AddThis仅仅用了1.5KB内存的内存就计算了十亿个不同的对象,Matt Abrams主要向我们详解了他们公司在处理过程中使用的方法。

    以下为文章全文:

    在AddThis,我们喜欢统计数据。对一组中不同元素(也称为“基数”)的数量进行计数,当其数量很大时,这是一个挑战。

    为了更好地理解确定的大型成套基数的挑战,让我们想象一下,在你的日志中有一个16个字符的ID,并且你想计算不同ID的数量。这里有一个例子:

    4f67bfc603106cb2

    16个字符需要用128位来表示。6万5千个ID将需要1MB的空间。我们每天收到30多亿个事件,每个事件都有一个ID。这些ID需要3840亿位或45GB的存储。而这仅仅是ID字段需要的空间!为了得到我们日常活动中的ID基数,我们可以采取一个简单的方法。最简单的想法是使用内存中的哈希集合,其中包含在输入文件中看到的独特的ID列表。即使我们假设3条记录中有1个是唯一的,哈希集合仍需要119GB的RAM,不包括Java需要在内存中存储对象的开销。你需要一台配备几百GB内存的机器来计算不同的元素,并且这只是计算一天的独特ID的成本。如果我们想要数周或数月的数据,这个问题只会变得更加困难。我们身边当然不会有一台配备几百GB内存的空闲机器,所以我们需要一个更好的解决方案。

    解决这一问题的常见办法是使用位图。位图可以用来快速、准确地获取一个给定的输入的基数。位图的基本思路是使用哈希函数映射数据集到一个位字段,在位字段里输入的独特元素映射到该字段中的一个位。这产生零碰撞,并减少需要计算每个独特元素到1位的空间。虽然位图大大减少了对空间的要求,但当基数是非常高或你对非常多的不同的组进行计数时,它们仍然有问题。例如,如果我们想要使用位图计数十亿,你将需要十亿位,或需要每个约120 MB的计数器。稀疏的位图可以被压缩,以获得更多的空间效率,但也并不总是有帮助的。

    幸运的是,基数估计是一个热门的研究领域。我们已经利用这项研究提供了一个开源实现的基数估计、集员资格检测和top-k算法。

    为了了解算法占用的空间与精确度之间的关系,我们用三种不同的计算方法在所有莎士比亚的作品计数了不同单词的数量(90万)。请注意,我们的输入数据集有额外的数据,所以基数高于这个问题答案的标准参考。我们使用的三种技术是:Java HashSet、Linear Probabilistic Counter以及一个Hyper LogLog Counter。这里是结果:

    该表显示,我们只使用512字节的空间就可以进行计数,并且误差在3%以内。相比之下,HashMap的计数准确度最高,但需要近10MB的空间,你可以很容易地看到为什么基数估计量是有用的。在实际应用中精度并不是很重要的,这是事实,在大多数网络规模和网络计算的情况下,用概率计数器可能会节省巨大的空间,这是真的。

    线性概率计数器

    线性概率计数器是高效的空间,并且允许实现者指定所需的精度水平。该算法在注重空间效率时是很有用的,但你需要能够控制你结果里的误差。该算法运行需要两步:第一步,在内存中分配一个初始化为都为0的位图,随后哈希函数被应用于输入数据中的每个条目,哈希函数的结果将映射条目到位图的一个位上,该位设置为1;第二步算法对空位的数量进行计算,并使用这个数字输入到下面的公式来获得估计。

    n=-m ln Vn

    在方程中,m是位图的大小,n是空位和映射的大小的比率。需要重点注意的是原始位图的大小,可以远小于预期的最大基数。小多少取决于你能忍受多少错误的结果。因为位图的大小、m,小于不同元素的总数,将会有碰撞。这些碰撞都可以节省空间,但同时也造成了错误的估计。所以通过控制原始映射的大小,我们可以估算碰撞的次数,因此我们将在最终结果中看到误差量。

    Hyper LogLog

    顾名思义,Hyper LogLog计数器的特点是,你仅需要使用loglog(Nmax)+一个常数那么多位就可以对Nmax进行计数。如线性计数器的Hyper LogLog计数器使设计人员能够指定所需的精度公差,在Hyper LogLog的情况下,这是通过定义所需的相对标准偏差和你期望要计数的最大基数。大部分计数通过一个输入数据流、M,并应用一个哈希函数设置h(M)来工作。这将产生一个S = h(M) of {0,1}^∞字符串的可观测结果。通过分割成m子字符串的哈希输入流,并为每个子数据保持m的观测值扩展了Hyper LogLog。使用额外的观测值的平均值,产生一个计数器,其精度提高为m的大小增长,只需要一个在输入集的每个元素上恒定要执行的操作数目。其结果是,这个计数器可以仅使用1.5 kb的空间计算精度为2%的十亿个截然不同的项。与执行 HashSet所需的120 兆字节进行比较,这种算法的效率变得很明显。

    合并分布式计数器

    我们已经证明了使用上面描述的计数器我们可以估算大集合的基数。但是,如果你的原始输入数据集不适合于单台机器,你能做些什么?这正是我们在AddThis所面临的问题。我们的数据分散在数百台服务器上,并且每个服务器只包含整个数据集子集的一部分。这就是事实,我们可以合并一组分布式计数器的内容,这是至关重要的。这个想法有点令人费解,但如果你花费一些时间去思考这个概念,就会发现其与基本的基数估计值相比并没有太大的不同。因为计数器代表映射中的位作为基数,我们可以采取两个兼容计数器并将其位合并到单一的地图。这个算法已经处理碰撞,所以我们可以得到一个基数估计所需的精密,即使我们从来没有把所有的输入数据到一台机器。这是非常有用的,节省了我们在网络中移动数据的大量时间和精力。

    总结

    希望这篇文章能帮助你更好地理解这个概念和概率计数器的应用。如果估计大集合的基数是一个问题,而你又碰巧使用一个基于JVM的语言,那么你应该使用stream-lib项目——它提供了其他几个流处理工具以及上文所述的算法的实现。(文/王旭东 审校/仲浩)

    本文来自:High Scalability

    展开全文
  • 组合查询为条件组合查询,在很场景下都有使用。购物网站中通过勾选类别、价格、销售量范围等属性来对所有的商品进行筛选,筛选出满足客户需要的商品,这是一种典型的组合查询。在小数据量的情况下,后台通过简单...

    1 概述

    组合查询为多条件组合查询,在很多场景下都有使用。购物网站中通过勾选类别、价格、销售量范围等属性来对所有的商品进行筛选,筛选出满足客户需要的商品,这是一种典型的组合查询。在小数据量的情况下,后台通过简单的sql语句便能够快速过滤出需要的数据,但随着数据量的增加,继续使用sql语句,查询效率会直线下降。当数据量达到一定的量级,服务器将会不堪重负甚至面临挂掉的危险,并且大数据量的存储也成为了一个问题。本文将讨论在亿级数据的情况下,多条件组合查询秒级响应的解决方案。

    2 方案思考

    2.1 数据存储

    假定每条数据有10个字段,每个字段的大小为4Byte,共有1亿条数据。通过传统的关系型数据库mysql,使用JDBC批处理和事务混合的方式对数据进行插入,插入一亿数据大约需要半小时,字段可能会出现为空的情况,导致冗余。针对海量数据的存储,现如今使用较多的是HBase。使用HBase的好处有三:其一,它是非关系型数据库,字段为空的值只在逻辑上存在,在空间上不存在,因此解决了冗余的问题;其二,它是面向列的数据库,能够通过简单的API调用对字段进行横向扩展;其三,它是分布式数据库,表的RowKey 按照字典排序,Region按照RowKey设置split point进行shard,通过这种方式实现全局、分布式索引,通过RowKey索引数据能够在毫秒级返回。Hbase插入数据可以调用批量插入或者通过MR程序插入,实测在批量提交数据条数设置为1000,开10个线程的情况下,插入一亿数据大约需要10分钟。若需要加速插入速度,可以通过增加批量提交数、调整线程数或者使用MR程序进行Hbase的写入。Hbase本身是分布式数据库,数据存储可以存储在多个节点上,使用Zookeeper统一管理,提供数据备份和故障恢复的功能。因此使用Hbase作为数据仓库,对结构化数据进行存储。

    2.2 数据查询

    Hbase中的数据查询只有两种方式:一是使用get 'tablename', 'rowkey‘’直接通过rowkey进行查询,亿级数据的查询结果可以在毫秒内返回;二是设置过滤器对全表进行Scan扫描,该查询方式在海量数据的情况下耗时十分长,当然也和服务器的性能有关。我们的需求是秒级响应,如果使用全表扫描方式,数据量达到万级或者十万级就无法实现实时响应了,要进行这样的查询,往往是要通过类似Hive、Pig等系统进行全表的MapReduce计算,这种方式既浪费了机器的计算资源,又因高延迟使得应用黯然失色。因此我们考虑使用rowKey对数据进行查询,如果我们使用rowKey对全表进行多条件组合查询,这将对rowKey的设置要求十分高,面向业务而言这对程序员十分不友好,因此我们需要通过建立二级索引的方式,按索引的种类扫描各自独立的单索引表,最后将扫描结果merge,得到目标rowKey。HBase有原生的建立二级索引的方式,即使用HBase的coprocessor协处理器,可以根据业务进行灵活的设置,但较为复杂,本文讨论使用一种业务模式较为固定,但更加简单直接的方式创建索引——Solr。Solr是一个独立的企业级搜索应用服务器,是Apache Lucene项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成,以及富文本(如Word、PDF)的处理。Solr是高度可扩展的,并提供了分布式搜索和索引复制。我们可以直接使用Solr这一组件,通过修改配置文件以实现相关的业务需求。通过批量建立索引的方式对HBase中的一亿条数据的10个字段构建索引,耗时为3383s,约为1小时。具体代码如下:

    public class ThreadsCreateIndexWork {
        private static Logger logger = LoggerFactory.getLogger(ThreadsCreateIndexWork.class);
        public static void main(String[] args) throws IOException, SolrServerException {
            if(args.length < 3) {
                logger.info("[tableName  |  queueSize  |  threadCount]");
                logger.info("e.g.| test1 20000 20");
            }
            String tableName = args[0];
            String queueSize = args[1];
            String threadCount = args[2];
    
            long start = System.currentTimeMillis();
    
            final Configuration conf;
            Properties prop = PropertiesReaderUtils.getProperties("conf/path.properties");
            String server = prop.getProperty("solr.server");
            SolrServer solrServer = new ConcurrentUpdateSolrServer(server, Integer.parseInt(queueSize), Integer.parseInt(threadCount));
    
            conf = HBaseConfiguration.create();
            HTable table = new HTable(conf, tableName); // 这里指定HBase表名称
            Scan scan = new Scan();
            scan.addFamily(Bytes.toBytes("people")); // 这里指定HBase表的列族
            scan.setCaching(500);
            scan.setCacheBlocks(false);
            ResultScanner ss = table.getScanner(scan);
    
            try {
                for (Result r : ss) {
                    SolrInputDocument solrDoc = new SolrInputDocument();
                    solrDoc.addField("rowkey", new String(r.getRow()));
                    for (KeyValue kv : r.raw()) {
                        String fieldName = new String(kv.getQualifier());
                        String fieldValue = new String(kv.getValue());
                        if (fieldName.equalsIgnoreCase("upperClothing")
                                || fieldName.equalsIgnoreCase("lowerClothing")
                                || fieldName.equalsIgnoreCase("coatStyle")
                                || fieldName.equalsIgnoreCase("trousersStyle")
                                || fieldName.equalsIgnoreCase("sex")
                                || fieldName.equalsIgnoreCase("age")
                                || fieldName.equalsIgnoreCase("angle")
                                || fieldName.equalsIgnoreCase("bag")
                                || fieldName.equalsIgnoreCase("umbrella")
                                || fieldName.equalsIgnoreCase("featureType")){
                            solrDoc.addField(fieldName, fieldValue);
                        }
                    }
                    solrServer.add(solrDoc);
                }
                ss.close();
                table.close();
            } catch (IOException e) {
            } finally {
                ss.close();
                table.close();
            }
    
            long time = System.currentTimeMillis() - start;
            logger.info("---------- create index with thread use time " + String.valueOf(time));
        }
    }
    

    ConcurrentUpdateSolrServer类可以使用多线程向SolrCloud的多个节点发送http请求,queueSize为队列大小,即往Solr中一次性批量add的数据数目,threadCount为开启的线程数,可以根据服务器性能的不同进行自定义,以提高构建索引的速度。笔者对1000w条数据进行参数调整测试,得到如下结果:

    queueSize threadNum Time (s)
    10000 20 274
    20000 20 250
    20000 30 255
    20000 40 254
    30000 20 255

    因此测试中选用的参数为queueSize:20000threadNum:20,索引构建速度为4w/s,还尝试通过修改scan.setCaching(500);的大小来提高构建速度,但是发现该缓存大小对构建速度的影响可以忽略不计,应该是索引构建速度低于HBase的Scan速度,因此暂时没有必要对HBase的Scan操作进行加速。Solr对构建索引的服务进行了上层封装,提供一个web服务的接口,可以直接通过可视化界面对结果进行查询。

    3 解决方案

    在这里插入图片描述
    综上,针对亿级数据多条件组合查询,给出的解决方案是使用HBase+Solr的方式,CDH将HBase和Solr都以组件的方式提供出来,可以使用CDH平台对HBase和Solr进行统一的管理。Hbase用于存储海量数据,Solr使用SolrCloud模式进行部署,提供索引构建和查询。索引的创建可以通过接口离线批量创建,也可以使用HBase Indexer连接HBase和Solr,提供自动化索引构建,CDH平台也集成了Hbase Indexer(Lily HBase Indexer)这一组件,具体的整合方法见 Solr+Hbase+Hbase Indexer查询方案流程整合

    4 方案测试

    笔者将一亿条包含10个字段的数据开启10个线程插入Hbase中,然后使用Solr对10个字段构建了索引,在Solr的可视化界面进行查询,查询结果如下图所示。
    查询全部数据
    组合查询1
    组合查询2
    其中,QTime为响应时间,q为查询语句,wt为请求格式(设置请求格式为xml响应速度更快),numFound为找到符合查询条件的数据条数,docs为返回的数据也就是rowKey。可以看到,组合查询都能够在秒级响应返回响应rowKey,而通过rowKey在HBase中返回该条数据的所有字段可以在毫秒级响应,如下图所示:
    在这里插入图片描述
    至此,可以证明,亿级数据多条件组合查询使用HBase+Solr的解决方案能够满足秒级响应的需求。具体流程操作可参考Solr+Hbase+Hbase Indexer查询方案流程整合

    展开全文
  • mysql尝试一下1.7亿数据

    千次阅读 2018-11-24 13:20:03
    是我在大三下学期做过的一次实训课程。 选题的数据来源是,同济大学2011数学建模夏令营试题的数据。 实验报告的位置:https://download.csdn.net/download/qq_35640964/10804674 整个操作大概是消耗了一...

    这个是我在大三下学期做过的一次实训课程。

    选题的数据来源是,同济大学2011数学建模夏令营试题的数据。

     

    实验报告的位置:https://download.csdn.net/download/qq_35640964/10804674

     

    整个操作大概是消耗了一天的时间。似乎是早上10点半那会儿开始的,然后晚上6点多结束的。具体记不清了,但是肯定用了一天的时间。

    系统是我的本地电脑,加上大一买的1快钱的腾讯云服务器。1核1G1M的服务器。美滋滋。现在已经停止了,但是我还能续费。美滋滋

    本地电脑提供插入操作。远程只有一个mysql。

     

    我用Java写了个文件读取和数据写入的代码。然后用了Spring Boot,这样子我就可以直接在浏览器写个调用函数然后做操作了。

    因为数据量超大,所以错误还是有不少的。后来检查了一下,其实很简单,因为给出数据就有一些事有问题的。比如坐标是负数,或者一堆8,一堆9的那种。这真是个数据筛选然后偷懒的好办法呀!

     

    总共有这么多条记录。这条记录查询的速度还是蛮快的,和查询几百条的感觉差不多。

     

    想到了一些减少数据量的方法:

    处理速度,有点子长了。单条数据比较的时候很伤。3-6分钟处理一下。真不好玩

    每次减少的量,还是对处理时间有影响的!说明在删除操作上的消耗是要超过比较操作的。

    2万多条的删除和1千万多条的输出,程序是1分钟半的样子?千万级的数据还是不错的么看来

     

    那么接下来就是作死操作了。

    这是百度的话。你信吗?我那时候反正是信了!

    (补:评论有人说是因为经纬度计算需要结果转换才可以,经纬度的计算是60进制的,如果想要正常使用,就必须保证原始数据的经纬度的进制也一直,引以为戒! )

     

    然后:

    显然,没有看错!

    我删除了1.5亿多条数据。。。。。。。

    我反复确认了N多次,我应该是没有输错的!

     

    骚操作结束后。。。600多万条数据。。。

     

    找到了一张图,我用了8.3个小时完成的操作。。。

    所有数据存入Mysql之后,Mysql好像是占用了22个G的空间。

    后来还是按照筛选出来的数据进行了操作了。

    后来操作发现,之前的索引好像还在的样子,每次操作都是需要三分钟。于是我在原来表的基础上新建了一个数据表。

    然后操作就很快了。丝滑的感觉。就是不一样!

    原来的表。当然是选择 truncate 了。

    数据处理过程就没必要赘述了。就是K-Means聚类。挺简单的。

     

    展开全文
  • 但是在32位的机器上,每float类型占4字节,1亿个浮点数就要占用400MB的存储空间,对于一些可用内存小于400M的计算机而言,很显然是不能一次将全部数据读入内存进行排序的。其实即使内存能够满足要求(我机器内存...
  • 现在有一非常庞大的数据,假设全是 int 类型。现在我给你一数,你需要告诉我它是否存在其中(尽量高效)。 需求其实很清晰,只是要判断一个数据是否存在即可。但这里有一比较重要的前提:非常庞大的数据。   ...
  • 公司对合作商家提供一付费级产品,这商业产品背后涉及到数百人的研发团队协作开发,包括各种业务系统来提供很强大的业务功能,同时在整个平台中包含了一至关重要的核心数据产品,这个数据产品的定位是全方位...
  • 任何关于算法、编程、AI行业知识或博客内容的问题,可以随时扫码关注公众号「图灵的猫」,加入”学习小组“,沙雕博主在线答疑~此外,公众号内还有更AI、算法、编程和大数据知识分享,以及免费的SSR节点和学习资料...
  • “本文聊一下笔者几年前所带的团队负责的多个项目中的其中一项目来聊聊一个亿级流量系统架构演进的过程。 一、背景引入 首先简单介绍一下项目背景,公司对合作商家提供一付费级产品,这商业产品背后...
  •  控制上游文件数每天7000,每文件大小小于256M,50亿条+,orc格式。查看每文件的stripe数,500左右,查询命令: hdfs fsck viewfs://hadoop/nn01/warehouse/…….db/……/partition_date=2017-11-11/...
  • 前两天面试3面学长问我的这问题(想说TEG的3面试学长都是好和蔼,希望能完成最后一面,各方面原因造成我无比想去鹅场的心已经按捺不住了),这问题还是建立最小堆比较好一些。  先拿10000数建堆,然后一次...
  • Apache Flink 在快手万亿数据的应用实践总结

    千次阅读 多人点赞 2019-07-17 15:07:35
    作者:董亭亭 整理:蒋晓峰 作者介绍:董亭亭,快手大数据架构实时计算引擎团队负责人。...本次的分享包括以下三部分: 介绍 Flink 在快手的应用场景以及目前规模; 介绍 Flink 在落地过程的技术演进过程...
  • 大规模IM在线用户的计算数据存储方案
  • 顺为资本在创始合伙人雷军及许达来的带领下成功领投了51Talk、丁香园、爱奇艺、一起作业等超级公司有近20家...就在今天,3月9日,家居云设计平台酷家乐宣布完成1亿美元D轮融资!该轮融资由顺为资本领投、淡马锡旗下P
  • 腾讯千亿节点相似度计算

    千次阅读 2014-11-26 08:51:41
    TDW千台Spark千亿节点对相似度计算 2014-11-16分类:TDW  相似度计算在信息检索、数据挖掘等领域有着广泛的应用,是目前推荐引擎中的重要组成部分。随着互联网用户数目和内容的爆炸性增长,对大...
  • 不少HPC专家所指出,要在尽量压缩时间周期的前提下合理实现百亿亿计算性能目标无疑是一项颇为严峻的挑战,仅仅依靠对现有技术及方案进行改进还不足以将理想变为现实。 自全球高性能计算(简称HPC)市场首次...
  • 计算机如何区分指令和数据(一)

    万次阅读 多人点赞 2019-09-03 09:44:27
    要了解指令和数据是什么?在计算机中有什么作用?以及它们怎样存储?才能回答如何区分它们以及为何要区分。首先我们要搬出冯诺依曼计算机体系架构,因为它回答了...3.指令和数据二进制表示。 4.指令由操作码和...
  • 数据倾斜是大数据领域绕不开的拦路虎,当你所需处理的数据量到达了上亿甚至是千亿条的时候,数据倾斜将是横在你面前一道巨大的坎。 迈的过去,将会海阔天空!迈不过去,就要做好准备:很可能有几周甚至几月都要...
  • Jindo 是阿里云基于 Apache Spark / Apache Hadoop 在云上定制的分布式计算和存储引擎。 Jindo 原是阿里云 开源大数据团队的内部研发代号, 取自筋斗(云)的谐音,Jindo 在开源基础上做了大量优化和扩展, 深度集成和...
  • imi在虎扑上亿数据迁移实践

    千次阅读 2021-02-02 23:36:20
    需要ES等一类的搜索引擎,进行维度的分词查询,现阶段适用按天分表,不能满足跨天的长时间查询,如何以最快的速度完成数据迁移,将数据库中的数据迁移到ES中,是需要评估的一重要技术点 2.根本问题: ...
  • 计算数据结构篇 - 哈希算法 (Hash)

    万次阅读 多人点赞 2020-01-21 14:02:00
    计算数据结构篇 - 哈希算法 (Hash) 哈希算法的定义和原理非常简单,基本上一句话就可以概括了。将任意长度的二进制值串映射为固定长度的二进制值串,这映射的规则就是哈希算法,而通过原始数据映射之后得到的二...
  • 1T数据到底有大?

    千次阅读 2018-04-18 18:09:04
    一英里不是个很的距离,一立方英里相对于地球也不会让人觉得是个很大的空间。然后我说,这个空间内能装下全世界所有人,你会不会觉到很惊讶?不过这话不是我说的,是美国作家房龙在一本书里写...似乎T不是个多大的...
  • **数据正在重新塑造人类生活的方方面面,IDC Research统计2019年大数据和分析市场的销售收入约为1870亿美元。跨机构、跨行业的数据融合、联合分析和建模的需求日趋增加。但由于数据本身可复制,易传播,一经分享无法...
  • 对于32位的计算机而言,只有2G的内存(2的三十一次方),而十亿大概是2的32次方。因此,不能将其直接放到内存中进行处理。 一byte有八位,我们可以开辟长度为2的29次方的byte数组,利用位映射原理,将要处理的数...
  • 如何从10亿数据中快速判断是否存在某一元素

    千次阅读 多人点赞 2021-02-26 11:02:49
    如何从10亿数据中快速判断是否存在某一元素 前言 缓存雪崩 解决方案 缓存击穿 解决方案 缓存穿透 解决方案 布隆过滤器(Bloom Filter) 什么是布隆过滤器 位图(Bitmap) 哈希碰撞 布隆过滤器的 2 大特点 fpp 布隆...
  • 在大量的数据记录中,依据某可排序的记录属性(一般为数字类型),找出最大的前 N 记录,称为 TopN 问题。这是一常常遇到的问题,也是一比较简单的算法问题,却很少能有人能写出最优化的 topn 算法。本文对...
  • <br />今天看到一篇赖永浩大牛的博客,由一道笔试题目...   题目:从1亿个整数中找出最大的一万。   赖永浩的解法: 基本思想是维持一数组记录当前最大的一万数,每来一新数
  • QQ号数字范围从0到十亿,即[0, 1000000000),且最多给你10亿个QQ号,这些QQ号放在1多个文本文件中,格式是每行一QQ号。 请读者先独立思考一下该怎样解决。 ——————————————————————...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 103,086
精华内容 41,234
关键字:

计算1亿个数据用多长时间