多线程处理海量数据的解决方案

背景:

  近期发现系统数据有不准确的现象发生,究其原因是因为上有数据导致的,而由于上游有多个渠道组成,所以无法要求上游统一修复数据。所以只能自己想办法每天修复错误数据。

初步解决方案:

  1,从商城库存那边拿到所有SKU+库存的信息。

  2,通过拿到的SKU+库存信息,修复现有的数据。

遇到的问题:

  1,库存那边的数据是以SKU+仓库id+配送中心id为维度,但是我们这边需要的是SKU+ORG维度。

  2,全量库存数据有1.2个亿。

解决办法:

  1,先把库存的原始数据(SKU+仓库ID+配送中心id)数据落地。

  2,将原始数据清洗为SKU+ORG维度。

  3,将清洗好的数据中过滤掉,不需要的库存信息。

  4,开启多个多线程同时修复数据。

多线程部分:

  共同时开启4个线程(0、1、2、3),用SKU_ID对4取模

  也就是说:

  线程0处理的数据范围为:SKU_ID%4=0 的数据。

  线程1处理的数据范围为:SKU_ID%4=1 的数据。

  线程2处理的数据范围为:SKU_ID%4=2 的数据。

  线程3处理的数据范围为:SKU_ID%4=3 的数据。

每个线程,每次再分页处理数据,即可。经过尝试,1.2个亿的数据分4个线程大概半个小时,即可处理完。

时间: 2024-10-08 04:15:45

多线程处理海量数据的解决方案的相关文章

杉岩海量数据存储解决方案

随着大数据.云计算.物联网等新技术的发展,电信.互联网.政企等行业应用日新月异,数据呈爆炸式增长并成为战略性资源.全球数据量每年约30%的速度递增,2020年达到惊人的40ZB. 面对海量数据,传统存储面临诸多挑战,主要体现在以下方面. 成本高:传统存储硬件使用专有设备,通用性差,设备投资加上后期维护.升级扩容的成本非常高. 性能低:单节点I/O性能瓶颈无法逾越,容量和性能都不易扩展,难以支撑海量数据的高并发低时延场景. 可扩展性差:无法实现快速部署和弹性扩展. 除此之外,信息安全问题触及到国家

海量数据和高并发的解决方案

海量数据的解决方案 缓存和页面静态化 缓存可以使用map(ConcurrentHashMap)直接保存在内存中,或者使用缓存框架Ehcache,Memcache,Redis等.缓存最重要的是缓存的创建时间和失效机制.缓存应该把空值定义一个类型,防止查到空的缓存后频繁查找数据库查找值,缓存适用于实时性要求不高且不频繁变化的数据 页面静态化,将程序最后生成的页面保存起来,可以使用模板技术freemaker,velocity生成静态页面,也可以使用缓存服务器squid和nginx等 数据库优化 表结构

161219、大型网站应用之海量数据和高并发解决方案总结一二

一.网站应用背景 开发一个网站的应用程序,当用户规模比较小的时候,使用简单的:一台应用服务器+一台数据库服务器+一台文件服务器,这样的话完全可以解决一部分问题,也可以通过堆硬件的方式来提高网站应用的访问性能,当然,也要考虑成本的问题. 当问题的规模在经济条件下通过堆硬件的方式解决不了的时候,我们应该通过其他的思路去解决问题,互联网发展至今,已经提供了很多成熟的解决方案,但并不是都具有适用性,你把淘宝的技术全部都搬过来也不一定达到现在淘宝的水平,道理很简单. 当然,很多文章都在强调,一个网站的发展

大型网站应用之海量数据和高并发解决方案总结一二

一.网站应用背景 开发一个网站的应用程序,当用户规模比较小的时候,使用简单的:一台应用服务器+一台数据库服务器+一台文件服务器,这样的话完全可以解决一部分问题,也可以通过堆硬件的方式来提高网站应用的访问性能,当然,也要考虑成本的问题. 当问题的规模在经济条件下通过堆硬件的方式解决不了的时候,我们应该通过其他的思路去解决问题,互联网发展至今,已经提供了很多成熟的解决方案,但并不是都具有适用性,你把淘宝的技术全部都搬过来也不一定达到现在淘宝的水平,道理很简单. 当然,很多文章都在强调,一个网站的发展

[转]海量数据解决思路之Hash算法

一.概述 本文将粗略讲述一下Hash算法的概念特性,里边会结合分布式系统负载均衡实例对Hash的一致性做深入探讨.另外,探讨一下Hash算法在海量数据处理方案中的通用性.最后,从源代码出发,具体分析一下Hash算法在MapReduce框架的中的应用. 二.Hash算法 Hash可以通过散列函数将任意长度的输入变成固定长度的输出,也可以将不同的输入映射成为相同的相同的输出,而且这些输出范围也是可控制的,所以起到了很好的压缩映射和等价映射功能.这些特性被应用到了信息安全领域中加密算法,其中等价映射这

分布式文件系统介绍

 基础介绍 分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连,也就是集群文件系统,可以支持大数量的节点以及PB级的数据存储.  常见的分布式文件系统 GFS.HDFS.GridFS.mogileFS.TFS.fastDFS等. GFS(Google File System):google公司为了满足本公司需求而开发的基于linux的专有分布式文件系统.不过很可惜该系统并未开源 HDFS: Had

Redis之个人简单理解

1.什么是redis? 在过去的几年中,NoSQL数据库一度成为高并发.海量数据存储解决方案的代名词,与之相应的产品也呈现出雨后春笋般的生机.然而在众多产品中能够脱颖而出的却屈指可数,如Redis.MongoDB.BerkeleyDB和CouchDB等.由于每种产品所拥有的特征不同,因此它们的应用场景也存在着一定的差异,下面仅给出简单的说明:      1). BerkeleyDB是一种极为流行的开源嵌入式数据库,在更多情况下可用于存储引擎,比如BerkeleyDB在被Oracle收购之前曾作为

SQLite学习手册(目录)

Posted on 2012-03-09 07:36 Stephen_Liu 阅读(11956) 评论(22) 编辑 收藏 在实际的应用中,SQLite作为目前最为流行的开源嵌入式关系型数据库,在系统的架构设计中正在扮演着越来越为重要的角色.和很多其它嵌入式NoSQL数据库不同的是,SQLite支持很多关系型数据库的基本特征,这在数据移植.程序演示等应用中有着不可替代的优势.从官方文档中我们可以获悉到,SQLite支持的数据量和运行效率都是非常骄人的,因此在海量数据的解决方案中,SQLite可以

redis安装及redis数据类型

Redis介绍: 一.介绍 在过去的几年中,NoSQL数据库一度成为高并发.海量数据存储解决方案的代名词,与之相应的产品也呈现出雨后春笋般的生机.然而在众多产品中能够脱颖而出的却屈指可数,如Redis.MongoDB.BerkeleyDB和CouchDB等.由于每种产品所拥有的特征不同,因此它们的应用场景也存在着一定的差异,下面仅给出简单的说明: 1). BerkeleyDB是一种极为流行的开源嵌入式数据库,在更多情况下可用于存储引擎,比如BerkeleyDB在被Oracle收购之前曾作为MyS