数据整合方案

iloveyoujia 2013-12-05 04:04:14

加精

数据库是异构的，分布到全国各省。想要一个有效的整合方案。做数据的大集中。
数据特点：
1、数据量大，一天400T左右（网络使用专线）
2、数据要传明细；（如果数据不集中明细，有什么让应用能实时访问省级数据）
3、应用做分析的时候，能实时访问到各省数据。

不知道什么样的产品或者技术能支撑？如果是程序是否可靠，需要在省里面部署什么样的程序？
如果是数据库什么样的数据库可以支持？数据库联邦是否可靠？

国内外有没有类似的Case?

...全文

2235 43 打赏收藏转发到动态举报

写回复

43 条回复

切换为时间正序

请发表友善的回复…

发表回复

江南雪_158 2015-10-28

打赏
举报

回复

期待高人指点

wangsufu77 2013-12-24

打赏
举报

回复

六公子 2013-12-20

打赏
举报

回复

就没见楼主分享啊！400T的数据缺失挺海量的！

copy_paste 2013-12-20

打赏
举报

回复

我估计那明细表的结构，是很简单一种，类似操作，或终端类的定时数据类似：objectID(对象ID), time（发生时间), data1, data2, data3... 然后目地是：各地WEB操作人员或用户会进行查看该明细或汇总或以此明细的增值数据。

jiebozhang 2013-12-17

打赏
举报

回复

不会是12306吧顶一下

人鱼传说 2013-12-16

打赏
举报

回复

这么大的数据量，在这里解决不了，还是请专业的公司来做吧

ricetendto2 2013-12-13

打赏
举报

回复

膜拜，一天400T,顿时亚历山大，做个标记，未来可能会用到

xxfvba 2013-12-13

打赏
举报

回复

400T啊，我一开始还以为是400G呢，400G感觉就很大了，期待高人。

Mr_Nice 2013-12-13

打赏
举报

回复

中国有23个省，4直辖市，282个地级市，374个县级市 lz每天的数据这么大，可否在更小的级别进行局部统计，然后将统计结果上传汇总至一处，再进行更深的挖掘统计。这样可以将负荷压在底端，不至于太大。省级区分 400TB/23≈17.4TB 依然还是有点儿大，不过已然数据统计小了一个数量级如果更加细分 17.4TB/省内各市，假设有20个市，就可以收敛到800GB左右，这个级别的数据量，Oracle，SQL Server，Mysql等就可以支持同理，从数据的起点来源作为分析点，可以将数据量缩小到最小的数量级，从而减少统计的压力。 lz第3个需求，实际是明细的查询，（网络使用专线）的情况下，通过修改查询指向，就可以满足lz需求。另外一个小小的疑问，400TB每天*365≈14.2PB级别的数据量据不完全统计，NASA EOS对地观测系统三年数据：1PB，lz这个应用系统采集数据的能力之强大，叹为观止啊....

蛇图腾 2013-12-13

打赏
举报

回复

楼主是在什么大国企还是政府部门啊

句号先生123 2013-12-12

打赏
举报

回复

我是来看看怎么回事的

mbugaifc 2013-12-11

打赏
举报

回复

mtazrael 2013-12-11

打赏
举报

回复

数据库异构没有关系，给他们设定统一的协议和规约让他们给中心数据中心发送数据就行了，不过这样中心数据中心压力就大了很多。专线这个数据量的确可以满足，就是IO的读写压力蛋疼。是否有冗余数据，是否应该先从数据上看看。再考虑技术方案，如果确定必须400T每天，那在考虑具体部署方式吧

lene3 2013-12-11

打赏
举报

回复

这帖子推荐了，只是更多的人来看，凑个热闹，至于楼主最后咋解决的，也都不知道。

君子之风-- 2013-12-10

打赏
举报

回复

拜读了。

zark 2013-12-10

打赏
举报

回复

见识了。。。

飞啊子 2013-12-10

打赏
举报

回复

等大牛。

liuhuili23 2013-12-10

打赏
举报

回复

一个服务器要处理这么大数据量，是够牛，干吗不从服务器部署上考虑

nnbuchicao 2013-12-10

打赏
举报

回复

可能是某处经费，不差钱

guguda2008 2013-12-09

打赏
举报

回复

一天完成400T的传输？搞笑吧，你打算用存储设备存呢？各地明细数据自己做汇总后再传到总部作分析，不要直接传明细数据。过期的明细数据直接删掉，不然你有多少钱也够不上买存储的钱。

加载更多回复（15）

一、项目名称：S2316S411H436 项目原型：Struts2.3.16 + Spring4.1.1 + Hibernate4.3.6 + Quartz2.2.1 二、项目目的：整合使用最新版本的三大框架（即Struts2、Spring4和Hibernate4），搭建项目架构原型。项目架构原型：Struts2.3.16 + Spring4.1.1 + Hibernate4.3.6 + Quartz2.2.1。此外，还有：Quartz、JUnit4、Log4j、SLF4J、Ehcache、Gson等这些库或框架，也全部使用最新版本。三、项目特色： 1、同时使用了Struts2、Spring4、Hibernate4、Quartz、JUnit4、Log4j、SLF4J、Ehcache、Gson等库或框架，搭建一个最基本的项目原型。 2、 Spring配置提供了多种可选整合方案：详见applicationContext.xml的配置（1）提供支持三种数据源方案：C3P0、DBCP、JNDI，三选一，请注释或删除其他方案（2）提取四种Hibernate整合方案：四选一，请注释或删除其他方案（3）提供两种声明式事务管理器方案：二选一，请注释或删除其他方案

数据整合方案是数据整合的研究重点，目前实际应用中已经形成了一些较为成熟的案例，主要有基于数据仓库的整合方案、基于中间件的整合方案、基于Web Services的整合方案、基于虚拟数据库的整合方案。随着数据整合技术的发展，数据整合逐渐从单一的技术模式向流程、规则、方法等的综合模式演进，产生了多种综合类型数据整合方案，这之中较有影响的为主数据管理方案。多数据库整合方案多数据库整合方案

文章目录说明需求分析方案架构数据安全安全要求安全模块数据应用dremio部署（Hadoop on yarn模式）个人博客说明本文着重于针对数据整合案例进行总结描述，选取部分数据ETL及平台应用中面临的问题及经验进行介绍，未对完整平台功能及流程进行展开描述。以下总结均来源于自身过往经验。特别的，融合数据安全模块及DaaS服务建议进行简要描述。需求分析数据量：每天千亿级别数据格式：以RDB...

一、增量与全量同步的合并问题：传统数据同步方式为周期全量数据同步，但随着业务发展数据量的急剧增加，周期全量同步的效率太低了。解决方案：每个周期只同步增量数据，然后与上一个同步周期获取的全量数据进行合并，获取最新版本的全量数据。传统数据整合方案：merge 方式（update + insert ）；当前大数据平台不支持 update 操作，而采用：全外连接（full outer join） + 数据全覆盖重新加载（insert overwrite）；（即如日调度，则将当天的增量数据和前一天的全

本人从事软件开发工作已十多年了，目前基于个人所接触到的项目或应用，针对物联网平台、大数据平台、人工智能应用、微服务架构、云计算平台等几个大方面，从数据采集、数据传输、数据解析、数据存储、数据计算、数据挖掘、数据分析、数据展示等几个角度或流程，阐述如何让数据产生价值并变现，并结合时下最流行先进的技术，通过整体架构设计和解读做一分析。云计算、大数据、物联网、移动互联网、人工智能是时下最流行和前沿的...

27,579

社区成员

68,558

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章