k*******z 发帖数: 2368 | 1 比如讲,有这么两个数据库,一个是产品,OLTP的。一个是做报告用的,星形。每天晚
上有ETL把产品的新数据发布到星形报告数据库。
问题:产品数据库是24/7,而且数据量很大。ETL要把新数据(过去的24小时产生的)
冗余化,发布到报告数据库上,就要消耗差不多也是24个小时的时间或者更多。如何解
决/改善这种滞后的情况?可能的瓶颈在哪里? |
B*****g 发帖数: 34098 | 2 你这个星行数据库是哪个?
【在 k*******z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 比如讲,有这么两个数据库,一个是产品,OLTP的。一个是做报告用的,星形。每天晚 : 上有ETL把产品的新数据发布到星形报告数据库。 : 问题:产品数据库是24/7,而且数据量很大。ETL要把新数据(过去的24小时产生的) : 冗余化,发布到报告数据库上,就要消耗差不多也是24个小时的时间或者更多。如何解 : 决/改善这种滞后的情况?可能的瓶颈在哪里?
|
y****w 发帖数: 3747 | 3 dbms? 数据抽取靠什么?etl工具?replication?找瓶颈与其我们猜不如你找下log,
看看每部分都花了多少时间。
你说得太概括,别人不好插手。
【在 k*******z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 比如讲,有这么两个数据库,一个是产品,OLTP的。一个是做报告用的,星形。每天晚 : 上有ETL把产品的新数据发布到星形报告数据库。 : 问题:产品数据库是24/7,而且数据量很大。ETL要把新数据(过去的24小时产生的) : 冗余化,发布到报告数据库上,就要消耗差不多也是24个小时的时间或者更多。如何解 : 决/改善这种滞后的情况?可能的瓶颈在哪里?
|
s**********0 发帖数: 266 | 4 如果一个ETL 处理之前一天数据要24小时或更多, 那这ETL设计绝对有问题。 查查你
的bottleneck在哪? 我想一般来说光复制OLTP一天的raw data 不应该超过1小时, 剩
下的时间肯定都是花在data processing上了?
【在 k*******z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 比如讲,有这么两个数据库,一个是产品,OLTP的。一个是做报告用的,星形。每天晚 : 上有ETL把产品的新数据发布到星形报告数据库。 : 问题:产品数据库是24/7,而且数据量很大。ETL要把新数据(过去的24小时产生的) : 冗余化,发布到报告数据库上,就要消耗差不多也是24个小时的时间或者更多。如何解 : 决/改善这种滞后的情况?可能的瓶颈在哪里?
|
l******t 发帖数: 660 | 5 多大的数据量啊?是incremental load 还是full load? 我们处理10tb的data也就几个
小时完工了,一般的ETL都有专门的monitor工具run一下, 一般的bottleneck就是pull
data cross network, transformation, 还有index rebuild. 最有可能是pull data
cross network, 如果硬件条件还可以的话 |
k*******z 发帖数: 2368 | 6 我只是举个例子让大家随便想。没有具体案例。
假如说,ETL不是用第三方工具,只是自己开发的SQL代码based on database link。
找log看时间应该就可以发现瓶颈。但是抽取24小时的数据不会比原系统插入更花时间
吗?再加上数据传输(比如,从欧洲拿到北美),再把这些数据插入到报告系统。不会
跟化时间吗?
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : dbms? 数据抽取靠什么?etl工具?replication?找瓶颈与其我们猜不如你找下log, : 看看每部分都花了多少时间。 : 你说得太概括,别人不好插手。
|
y****w 发帖数: 3747 | 7 only ABSTRACT can answer ABSTRACT.
so the answer is: every part can be the bottleneck, the excuse can be
hardware, network, code, business logic, etc.
【在 k*******z 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我只是举个例子让大家随便想。没有具体案例。 : 假如说,ETL不是用第三方工具,只是自己开发的SQL代码based on database link。 : 找log看时间应该就可以发现瓶颈。但是抽取24小时的数据不会比原系统插入更花时间 : 吗?再加上数据传输(比如,从欧洲拿到北美),再把这些数据插入到报告系统。不会 : 跟化时间吗?
|
k*******z 发帖数: 2368 | 8 然!讨论结束。
【在 y****w 的大作中提到】![](/moin_static193/solenoid/img/up.png) : only ABSTRACT can answer ABSTRACT. : so the answer is: every part can be the bottleneck, the excuse can be : hardware, network, code, business logic, etc.
|
g***l 发帖数: 18555 | 9 SLOWLY CHANGE MULTIDIMENSION WIZARD |
z******4 发帖数: 4716 | 10 哇,好久都没做技术了,上一次大数据量已经是几年前的事情了,好怀念啊
确实是,每一个部分都有可能
例如,我以前做移动项目,每天CDR 5000万记录,我记得是加载到数据库40分钟,头疼
的不是加载,而是后期报表,每天要从1TB的CDR话单表中提取数据,比较耗时。后来直
接建立话单临时表,4点开始加载,8点所有报表刷新完毕。这个项目的麻烦是cube的增
量刷新,用的MS,很好
后来做银行,加载要要16个小时,因为不是architect,也不是etl leader,就没管。
头疼的是data mart fact table的刷新,因为业务逻辑复杂,一个简单的对公业务fact
table有时要3哥小时,懒得调优,因为客户接受
一般来说,大数据量哪里都会有瓶颈。最麻烦的是就是月末全量刷新
至于工具,随便了,你擅长那种,就用那种,C也可以。SQL也可以
DW以后不打算玩了,呵呵,做后台没前台风光,没前途,已经放弃了 |