我想了解更多关于如何将NoSQL数据库集成到以关系模型为中心的架构(根据Data Vault 2.0标准构建)。有谁知道我可以在哪里自学这个主题。Dan Lindstedt 的最新书中目前没有此内容!
我已经从头到尾阅读了数据保险库书,但我仍在尝试解决与如何填充链接表(如何获取所有哈希值)相关的特定问题。来自 scalefree:大规模并行处理的博客,它展示了可以以完全并行的方式加载卫星和集线器,但它没有涉及与链接表相关的很多细节。
链接需要散列键,因此以某种方式来自多个表的“业务键”来建立关系,这就是他们所做的,他们记录集线器之间的关系。没有很好的解释或深入解释在填充这些链接表时如何检索相关实体的业务键。
对于像“客户”这样的特定表,集线器和卫星很容易:只需将业务密钥转换为哈希并并行加载它们。
但是来自 OLTP 的客户详细信息表或事务表需要某种联接来查找客户的业务键或查找事务中的所有相关实体(产品、客户、商店等),因为这些表通常不会将(所有)业务键存储为表中的属性。
如果我假设登台是增量加载和截断的,那么登台不一定要加载所有实体才能在那里执行连接。如何解决这个困境并创建一个有效的设计?
本质上,为 OLTP 系统的所有外键关系生成哈希的最佳实践是什么?
我是Data Vault的新手,所以请原谅我的无知。我目前正在使用 Data Vault 2.0 并行加速和建模原始 Data Vault。我的假设很少,需要帮助来验证它们。
1) 各个集线器建模为:
a) 产品(保存 pk-Product_Hkey、BK、元数据),
b)客户(持有pk-Customer_Hkey,BK,元数据),
c) 存储(保存 pk-Store_Hkey、BK、元数据)。现在,涉及所有上述业务对象的销售交易应建模为链接表
d) 链接表 - Sales_Link(保存 pk-Sales_Hkey、Sales Txn ID、Product_Hkey(fk)、Customer_Hkey(fk)、Store_Hkey(fk)、元数据)和 Satellite 需要关联到保存有关链接的一些描述性数据的链接表。上述方法有效吗?
我对上述链接表的基本原理是因为我认为销售 Txn ID 是非 BK,因此销售 Txn 必须托管在链接中而不是中心中。
2)运营数据有不同类型的客户。(零售、专业)。所有客户(与类型无关)都应在一个中心进行建模,并且应通过对与客户中心相关的不同卫星(一个用于零售,一个用于专业)进行建模来区分客户类型。以上有效吗?
我研究过在线技术论坛,但得到了相互矛盾的理论,所以我将其发布在这里。
这里没有适用的代码
考虑以下两个 DWH 架构:
带有原始数据库的 DWH,层:
DWH 与 Persistent Staging Area(称为 PSA 或 HDA),层数:
与 PSA 概念相比,原始数据保险库概念有什么好处吗?在我看来,Data Vault 建模在 ETL 方面增加了不必要的复杂性,并且在性能方面也较慢。
很难找到一个真正好的答案,有什么想法吗?
谢谢!
我们正在构建一个Data Vault (2.0)模型来捕获 SalesForce 数据。与许多其他源一样,源中的记录被软删除。当我们将数据获取到数据模型时,我们不想过滤任何数据,也不想捕获目标系统中已删除的记录。搜索了处理数据仓库模型中已删除记录的最佳实践,但没有成功。有人可以在这里说明一下吗?我们是否应该添加IsDeleted标志Hub或Satellite考虑模型的未来扩展以及要遵循的最佳设计实践。此外,此处的任何参考材料链接都会有很大帮助。谢谢。
我有一个关于硬规则(rawVault)和软规则(业务规则)的问题。
\n\n我的例子是一个源系统有一个名为 Pets 的非规范化表,其中 Pets 包含猫、狗和鸟,它们通过类型代码进行区分(1 \xe2\x80\x93 cat,2 \xe2\x80\x93 dogs, 3 \xe2\x80\x93 鸟)。
\n\n我的问题是关于将数据加载到 Rawvault 与 Business Vault 时的硬规则与软规则。加载Pets表时,您可以在rawvault中创建h_cat、h_dog和h_bird集线器,并根据类型代码1过滤源表pets到h_cat,类型代码2到h_dog,类型代码3到h_bird吗?这是硬规则还是软规则?
\n\n或者
\n\n当基于类型代码过滤数据时,我们是否应该在 rawvault 中创建 h_pet 中心,使数据尽可能接近源,在 Businessvault 中创建 h_cat、h_dog 和 h_bird,因为这将被归类为软规则?
\n在建模数据仓库时,我们是否应该支持Data Vault而不是Dimensional建模?这两者之间的主要区别是什么?
在数据保险库2.0中,一个哈希值用于处理业务密钥,并将此哈希值用作表的主键。链接表也使用哈希主键创建关系。
我的问题是散列基本上是随机的,查询优化器无法应用任何良好的估计,因为统计信息(当然)不适用于随机分布的数据。
因此,查询优化器在要经常排序的地方使用了奇怪的计划(因为它认为只有4行可以排序)。由于我肯定不是第一个处理sql server中的数据保险库的人,因此它如何可修复?
当查询优化器使用索引查找或联接运算符时,它会完全错过行估计,因此会选择荒谬的计划。
我必须使用连接提示和查询提示(例如(FORCE ORDER))来修饰它们,以从中获得任何好处。
常见的处理方法是什么?
如果以下三个唯一属性来自 3NF 模型中的 SalesOrderHeader 表,那么哪一个将是 SalesOrderHeader Hub 的理想业务键:
我正在将数据加载到雪花数据仓库建模数据库中。当行的字段被更新时,模型的工作方式如下:
current_timestamp()。我merge在 JavaScript 过程中使用 Snowflake 中的命令来执行此操作:
var observarion_query = "MERGE INTO HUB_OBSERVATION AS OBS "+
"USING (SELECT DATE(T.$"+OBSERVATION_DATE+", 'DD/MM/YYYY') AS OBS_DATE, T.$"+LOCATIONS+", T.$"+SUBMISSION_TIME+" FROM "+FILE_FULL_PATH+"(FILE_FORMAT=>"+FILE_FORMAT_NAME+") T) ST "+
"ON md5(CONCAT(ST.OBS_DATE, CONCAT('CAMP', CONCAT(ST.$"+LOCATION_POSITION+", ST.$"+SUBMISSION_TIME+")))) = OBS.OBSERVATION_DATE_LOCATION_HASH_KEY "+
"WHEN MATCHED THEN UPDATE SET OBS.LOAD_END_DT = CURRENT_TIMESTAMP() "+
"WHEN NOT MATCHED THEN "+
"INSERT (OBSERVATION_DATE_LOCATION_HASH_KEY, LOAD_DT, LOAD_END_DT, RECORD_SRC, OBSERVATION_DATE, LOCATION_NAME) "+
"VALUES (md5(CONCAT(ST.OBS_DATE, CONCAT('CAMP', CONCAT(ST.$"+LOCATION_POSITION+", ST.$"+SUBMISSION_TIME+")))), current_timestamp(), NULL, 'ONA', ST.OBS_DATE, CONCAT('CAMP', ST.$"+LOCATION_POSITION+")) ";
Run Code Online (Sandbox Code Playgroud)
问题在于WHEN MATCHED THEN …
data-vault ×10
database ×2
sql ×2
etl ×1
hash ×1
join ×1
merge ×1
mongodb ×1
nosql ×1
primary-key ×1
random ×1
snowflake-cloud-data-platform ×1
sql-server ×1