k*******z
发帖数: 2368 | 1 比如讲，有这么两个数据库，一个是产品，OLTP的。一个是做报告用的，星形。每天晚
上有ETL把产品的新数据发布到星形报告数据库。
问题：产品数据库是24/7，而且数据量很大。ETL要把新数据（过去的24小时产生的）
冗余化，发布到报告数据库上，就要消耗差不多也是24个小时的时间或者更多。如何解
决/改善这种滞后的情况？可能的瓶颈在哪里？ |
B*****g
发帖数: 34098 | 2 你这个星行数据库是哪个？
【在 k*******z 的大作中提到】
: 比如讲，有这么两个数据库，一个是产品，OLTP的。一个是做报告用的，星形。每天晚
: 上有ETL把产品的新数据发布到星形报告数据库。
: 问题：产品数据库是24/7，而且数据量很大。ETL要把新数据（过去的24小时产生的）
: 冗余化，发布到报告数据库上，就要消耗差不多也是24个小时的时间或者更多。如何解
: 决/改善这种滞后的情况？可能的瓶颈在哪里？
|
y****w
发帖数: 3747 | 3 dbms? 数据抽取靠什么？etl工具？replication？找瓶颈与其我们猜不如你找下log，
看看每部分都花了多少时间。
你说得太概括，别人不好插手。
【在 k*******z 的大作中提到】
: 比如讲，有这么两个数据库，一个是产品，OLTP的。一个是做报告用的，星形。每天晚
: 上有ETL把产品的新数据发布到星形报告数据库。
: 问题：产品数据库是24/7，而且数据量很大。ETL要把新数据（过去的24小时产生的）
: 冗余化，发布到报告数据库上，就要消耗差不多也是24个小时的时间或者更多。如何解
: 决/改善这种滞后的情况？可能的瓶颈在哪里？
|
s**********0
发帖数: 266 | 4 如果一个ETL 处理之前一天数据要24小时或更多， 那这ETL设计绝对有问题。 查查你
的bottleneck在哪？ 我想一般来说光复制OLTP一天的raw data 不应该超过1小时， 剩
下的时间肯定都是花在data processing上了？
【在 k*******z 的大作中提到】
: 比如讲，有这么两个数据库，一个是产品，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 的大作中提到】
: 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 的大作中提到】
: 我只是举个例子让大家随便想。没有具体案例。
: 假如说，ETL不是用第三方工具，只是自己开发的SQL代码based on database link。
: 找log看时间应该就可以发现瓶颈。但是抽取24小时的数据不会比原系统插入更花时间
: 吗？再加上数据传输（比如，从欧洲拿到北美），再把这些数据插入到报告系统。不会
: 跟化时间吗？
|
k*******z
发帖数: 2368 | 8 然！讨论结束。
【在 y****w 的大作中提到】
: 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以后不打算玩了，呵呵，做后台没前台风光，没前途，已经放弃了 |
