正如 LinkedIn 数据团队所述，自从十年前采用 Apache Hadoop 以来，包括 LinkedIn 在内的许多公司都经历了指数级的数据增长。随着自助数据创作工具和发布平台的激增，不同的团队已经创建和共享数据集以快速满足业务需求。虽然使用自助服务工具和平台是各种团队释放数据价值的一种可扩展且灵活的方式，但它引入了多个问题。
自助服务不是免费的，而且会带来挑战。
- 1）多个相似的数据集经常导致结果不一致和资源浪费，
- 2) 缺乏数据质量和可靠性标准使得在长长的潜在匹配列表中很难找到值得信赖的数据集，以及
- 3）数据集之间复杂且不必要的依赖关系导致可维护性差且难以维护。
LinkedIn 写了它如何构建“超级表”[这是语义层的另一个名称吗？] 解决一些挑战。
在这篇文章中，我们提出了一种通过超级表解决这些问题的独特方法。Super Tables 是一项公司计划，用于定义、构建和共享具有正式所有权和承诺的高质量数据产品。在以下部分中，我们将介绍 Super Table 是什么、为什么需要 Super Table 以及它的设计原则。我们还简要介绍了生产中的两个超级表，以及在此过程中学到的经验教训。
什么是超级表？
超级表 (ST) 是针对常见和高效分析用例优化的实体或事件的预先计算、 非规范化和一致整合的属性和见解。ST 具有明确定义的服务水平协议 (SLA)，并简化了数据发现和下游数据处理。此外，ST 附带关键用例所需的企业级承诺。这些承诺包括高数据质量和可用性（即，用户可以依赖 ST）、灾难恢复、适当的文档、维护和治理。自从引入 Super Table 概念以来，已经构建了两个 Super Tables 并投入生产：JOBS 和 Ad Event。我们将在后面的部分提供更多详细信息。
我们在 Super Tables 中的工作正好符合 LinkedIn 的数据网格计划：
- 数据即产品是主要原则之一，超级表旨在开发具有正式所有权和承诺的高质量数据产品。
- 每个 Super Table 封装的实体/事件由域（可能是虚拟团队）拥有/管理——这是数据网格中的一个关键概念。
- 实体/事件的标准化以及 SLA 和合同承诺的建立提高了不同领域数据产品的互操作性。
为什么我们需要超级表？有什么好处？
在 LinkedIn，我们在当前数据生态系统中面临着多方面的挑战，其中许多挑战源于数据采集和数据集创作的爆炸式增长。以下是一些最关键和最常见的：
- 可发现性：分析所需的数据是从许多真实来源 (SOT) 数据集以及直接从其上游来源（Apache Kafka 主题、在线数据库、外部和派生数据集）中发现和使用的。随着许多相似数据集（通常由不同团队拥有）的激增，找到正确的数据集变得更加困难。
- 可靠性：随着数据创作的民主化，数据在许多类似的数据集中被复制，这些数据集定义松散且变化不定，数据质量和新鲜度承诺。在多个下游用例中跨这些数据集执行计算成本高的连接。其中一些数据集在团队之间共享所有权，每个团队可能拥有计算逻辑的不同部分。这会导致对任何数据问题的理解和故障排除效率低下。
- 变更管理：对数据集或其来源的更改通常是在没有咨询甚至通知所有下游消费者的情况下进行的，有时会导致部署中断的更改。这会影响业务连续性，并导致排查和解决问题的工作浪费。
Super Tables 计划旨在缓解这些挑战，如图 1 所示。我们的目标是仅构建少量企业级 Super Tables，供许多下游用户使用。每个域可能只有很少的被用户高度利用的超级表。通过将数百个 SOT 合并到这几个 Super Tables 中，大量的 SOT 最终将被弃用和淘汰。
增加可发现性
- 为业务实体或事件（即在域中）拥有一个或两个超级表可以更轻松地探索和使用数据以进行数据分析。它最大限度地减少了数据重复并缩短了查找正确数据的时间。
增强可靠性和可用性
- 超级表通过预先计算的相关业务实体或事件的连接实现，以整合下游分析通常需要的数据。这消除了在许多下游用例中执行此类连接的需要，从而导致更简单、性能更高的下游流和更好的资源利用率。
- Super Tables 通过主动数据质量检查（结构、语义和差异）和查询当前和历史数据质量检查结果的编程方式提供和发布关于可用性和可支持性的 SLA 承诺。
改进变更管理
- Super Tables 具有明确定义的变更管理和沟通治理策略以及承诺的变更速度（例如，每月部署变更）。上游数据生产者和下游消费者（跨团队/领域）都参与了 ST 变更的治理。
得到教训
从设计和实施超级表中，我们学到了许多宝贵的经验。首先，我们了解到了解用例和使用模式对于确定使用超级表的主要好处至关重要。在构建新的超级表之前，重要的是要环顾四周，看看已经有哪些类似的表。有时，加强现有表比从头开始构建表更好。在权衡这两个选项时，要考虑的因素包括现有表格的质量、覆盖范围、支持和使用。
接下来，我们了解到，在构建超级表时，重要的是要识别这些语义逻辑及其所有者，以确保它是正确的，并了解它会随着时间的推移如何演变。数据转换包括结构逻辑（例如，表连接、去重和数据类型转换）和语义逻辑（例如，基于浏览历史预测未来购买可能性的方法）。语义逻辑通常由具有深厚领域知识的特定团队拥有。如果没有适当的沟通和协作，语义逻辑将难以维护和过时。更好的解决方案是将语义逻辑分离到不同的层（例如 构建在 ST 之上的Dali Views ），并由具有领域知识的团队管理。
使用 Super Table SLA，SLA 越严格，您对问题的容忍度就越低。这意味着实施防御性数据加载、安全数据转换、铁定警报和升级以及运行时数据质量检查等机制。对于较软的 SLA，您可以容忍失败、分类并解决问题。使用严格的 SLA，有时您无法容忍单个故障。
另一个教训是，在一个强调隐私的时代，数据不准确可能会产生灾难性的级联效应，降低成本是最重要的，减少冗余数据集是最接近灵丹妙药的事情。通常，最好对齐超级表来满足不同的用例并确保满足所有要求，而不是为了速度而容忍重复。同样，将多个相似的数据集（针对不同的用例）整合到一个超级表中也非常关键。
最后，在 ST 发布之后，关键任务之一是将传统 SOT 的用户迁移到新的 ST。迁移越早完成，可以为其他任务释放的资源就越多。
详细点击标题