Python 数据仓库ETL在维度中缓慢更改主键？

我有一个可用的MySQL数据仓库，它被组织成星型模式，我正在使用Talend Open Studio for data Integration 5.1创建ETL过程。我希望这个过程每天运行一次。我估计其中一个维度表（dimUser）将有大约200万条记录和23列

我在Talend中创建了一个小的测试ETL过程，该过程可以正常工作，但是考虑到每天可能需要更新的数据量，当前的性能将不会降低它。ETL过程需要四分钟来更新或向dimUser插入1000条记录。如果我假设记录数与更新或插入时间之间存在线性关系，那么ETL不可能在3-4小时内完成（我希望如此），更不用说一天了

因为我不熟悉Java，所以我将ETL作为Python脚本编写，并遇到了同样的问题。尽管如此，我还是发现，如果只插入，过程会快得多。我很确定，瓶颈是由UPDATE语句造成的

dimUser中的主键是一个自动递增的整数。我的朋友建议我放弃这个主键，用一个多字段主键（在我的例子中是2-3个字段）替换它

在我将测试数据从我的仓库中取出并更改模式之前，有人能提供与此相关的建议或指南吗

数据仓库的设计

ETL过程

让一个ETL过程每天插入或更新几百万条记录是多么现实啊

我朋友的建议会有很大帮助吗

如果你需要任何进一步的信息，请告诉我，我会发布的

更新-其他信息：

mysql> describe dimUser;
Field                        Type                Null Key Default            Extra
user_key                     int(10) unsigned    NO   PRI NULL               auto_increment
id_A                         int(10) unsigned    NO       NULL
id_B                         int(10) unsigned    NO       NULL
field_4                      tinyint(4) unsigned NO       0
field_5                      varchar(50)         YES      NULL
city                         varchar(50)         YES      NULL
state                        varchar(2)          YES      NULL
country                      varchar(50)         YES      NULL
zip_code                     varchar(10)         NO       99999
field_10                     tinyint(1)          NO       0
field_11                     tinyint(1)          NO       0
field_12                     tinyint(1)          NO       0
field_13                     tinyint(1)          NO       1
field_14                     tinyint(1)          NO       0
field_15                     tinyint(1)          NO       0
field_16                     tinyint(1)          NO       0
field_17                     tinyint(1)          NO       1
field_18                     tinyint(1)          NO       0
field_19                     tinyint(1)          NO       0
field_20                     tinyint(1)          NO       0
create_date                  datetime            NO       2012-01-01 00:00:00
last_update                  datetime            NO       2012-01-01 00:00:00
run_id                       int(10) unsigned    NO       999

我使用了代理密钥，因为我读到这是一个很好的实践。因为，从业务的角度来看，我希望了解潜在的欺诈活动（例如，200天内，一个用户与X州关联，然后第二天他们与Y州关联——他们可能已经移动，或者他们的帐户可能已经被泄露），所以这就是为什么要保留地理数据的原因。字段id_B可能有几个与之相关联的id_a的不同值，但我感兴趣的是了解不同的（id_a，id_B）元组。在这个信息的上下文中，我的朋友建议像（id_A，id_B，zip_code）这样的东西作为主键

---

对于绝大多数的日常ETL流程（>80%），我只希望更新现有记录的以下字段：field_10-field_14、last_update和run_id（此字段是我的ETL日志表的外键，用于ETL审计目的）。

以下是我对您的问题的看法

1） 仓库设计：

阅读拉尔夫·金博尔的书：数据仓库工具包

维度表中有一组列，它们的名称毫无意义。应为列指定具有业务含义的名称，而不是字段_5。数据仓库便于业务和报告人员查询

我在这里没有看到任何事实表。了解用户维度的用途在其设计中很重要

2） ETL过程

您是否确定了ETL过程中的瓶颈所在？是从源读取数据、转换数据还是写入数据库？您可能以40000行/秒的速度写入，但如果您只能以1000行/秒的速度从XML数据源中读取数据，那么您不会走得很远

您是否考虑过先将更改的记录加载到数据库中的stage表中，而不进行任何转换，然后使用SQL来转换和更新数据？通常，您会发现数据库中的性能比将工作转移给ETL工具要好

3） 如果硬件能够处理的话，每天更新几百万条记录是非常现实的。我认为重要的是要了解，如果您只打算使用类型1维度，在该维度中，您只需覆盖更改（在这种情况下，删除更改行，然后插入，可能比更新/else/insert更好）

如果你保留了一个2型维度的变化历史，你可能想考虑雪花你想要跟踪的字段在一个单独的微小维度上改变。当您有一个非常大的“客户”维度时，Kimball将讨论此技术。然后，您将使用定期快照事实表，该表允许您跟踪用户随时间的变化

---

4） 对于数据仓库环境，您的朋友建议从自然业务密钥中创建主键不是一个好主意。我们创建一个整数代理键，以便将其包含在事实表中，以保持其精简，因为它们将比维度表大几个数量级。

如果将主键更改为在更新过程中可能会更改的内容，则每次更新索引时都需要重新计算索引，这将更慢。一个中等大小的表只需要4分钟就可以更新100行，这似乎很奇怪，可能是脚本而不是模式有问题。您是否尝试过直接在sql和脚本中对更新进行基准测试？您是如何每天获得数百万的更新的？您的密钥很好，加载时是否使用密钥管道？你在dimUSer上的业务重点是什么？@Damir:200万的价值来自历史观察数据。什么是关键管道？一定要读金宝的书。这都是纯香草的。@N韦斯特：谢谢你的回答，尽管我认为你从我的帖子中获取的信息有点太过字面。上面列出的一些字段具有通用名称，因为我在一个商业环境中工作，不希望发布可能识别我为哪个雇主工作的信息。另外，虽然我确实征求了和数据仓库设计相关的答案，但我从未想过会收到关于字段命名实践的回复。同样，我也有事实表，但我认为没有必要这样做