维护Uber的大规模数据仓库的运营成本在ETL功能和存储方面。根据我们的经验，优化运营效率需要回答一个关键问题：维护成本取代实用程序的表格？一旦确定，我们就可以将这些桌子从仓库中偏离船，并将相关用例迁移到低成本的分析引擎，实现更高的整体效率。
和数据的之前要管理，回答上述问题对Uber至关重要。但是，事实证明这是一个有趣的数据科学问题，引起了更多考虑：
- 我们如何量化效用？定义实用程序有几个因素，例如给定表服务的查询数量以及访问给定表的不同用户的数量。
- 我们在哪里设定维护成本的门槛，以及如何衡量对公用事业的衡量？
- 测量效用时，我们如何在表之间合并直接和间接的依赖性？通常，所有桌子都是单个大型连接图的一部分，并且删除一个或几张桌子会破坏许多其他查询。有强大的网络效应使对几张表的孤立分析极为困难。在做出任何重大决定之前，我们必须考虑完整的图表。
为了解决我们的中心问题 - 确定哪些表应该从我们的中央数据仓库中脱掉哪些表，Uber的数据基础架构和数据科学团队联手解决了这一优化问题。
计算成本和实用程序
为了解决这个优化问题，我们将其分为两个部分。首先是运行查询的计算成本。由于有数百万个查询与我们的分析数据库有关，因此我们决定将查询分组为查询类。至少，查询类由使用相同表的查询组成，但可以通过其他条件进行进一步分类，例如所使用的运算符类型和所消耗的资源。
假设有问查询类。对于每个查询类问，我们还跟踪查询数量，l问，以及运行所有属于查询类的查询的总成本，v问。查询成本是根据查询使用的计算资源来计算的。因此，由于所有查询而引起的总计算成本可以表示为：
以上X问是二进制决策变量。X问= 1表示查询类应继续在给定数据库上执行。反过来，这意味着支持查询类所需的所有表还应在数据库中可用。
正式化优化问题的第二个方面是维护表的成本，其中包括存储和ETL成本。但是公用事业是另一个重要因素。理想情况下，桌子维护的成本应考虑到桌子的效用，即，如果表具有很高的公用事业，则应将其有效的维护成本视为低。我们使用表重量乘以表成本的表重量对实用程序进行建模。表重量是根据与给定表有关的每周活动用户计算的。
如下图1所示，我们利用逆Sigmoid模型来降低表用户数量增加的表格成本。此外，我们使用与Sigmoid函数相关的参数来控制斜率和函数在Y轴上交叉0.5的点。
因此，维护所有表的成本可以表示为：
以上wt是代表效用倒数的权重函数。dt是维护桌子的成本。yt是一个二进制决策变量，指示表是否分配给数据库。
数据库的总运营成本是其计算和维护成本的总和，如下所示：
为了识别应放外的表格，我们需要最大程度地减少受到以下四个约束的上述成本函数。这些约束是护栏，保留了我们用例的成本函数的实用性：
约束1和2强制执行决策变量X和y要二进制。X问= 1表示应将查询分配给数据库，否则将其迁移到数据库中。相似地，yt= 1表示该表t应保留，否则应放外。
约束3模拟查询之间的依赖关系（X）和桌子（y）。如果是查询问用用表A，B和C分配在数据库上运行，然后还应将关联的表（A，B和C）分配给数据库，即X问= 1然后yt= 1t在哪里mQT= 1。m问是一个二进制矩阵，可在查询和表之间提供依赖关系。mQT= 1表示查询问用途表t。
最后，需要约束4才能选择一个不会导致所有值零值的解决方案X问和yt。如果没有表格，运营成本将最小化或将其变为零，这对于我们的目的而言是不切实际的。为了避免这种情况，我们引入了查询保留标准，即应继续在给定数据库上执行的查询百分比。
降低运营成本
将成本函数最小化（换句话说，总运行数据库成本）受到这四个约束的约束，这为关键问题提供了答案：桌子维护成本取代了餐桌的哪一组表？
但是，适合该条件的表的结果列表取决于保留率的价值。为了最大化储蓄，如下图2所示，我们将查询保留率从50％更改为100％，并监视表维护成本的下降。即使以100％的保留率，我们也注意到，由于有一些不再使用的陈旧数据表，因此桌子维护成本下降到92％，并且优化解决方案正确识别了它们。
我们的数据库储蓄稳定在95％的保留率约为95％，其中桌子维护成本降至现有表维护成本的28％。
总而言之，将5％的选定查询从仓库分析引擎移至较低的昂贵选择，例如Presto或Apache Hive，使我们能够将一些选定的表的效用减少到零。这些表格在外部时，将数据库的表维护成本降低了72％。总体而言，这有可能使我们的数据库的运营成本降低近30％。
向前进
应用数据科学以优化我们的数据基础架构已显示出Uber的堆栈中的承诺，从我们找到一种方法部分复制Vertica群集到本文中讨论的数据库利用率分析。在此用例中使用数据科学，我们能够确定运营成本取代其效用的一组表，从而有助于运营效率低下。
此外，这种优化问题的形式化为考虑其他几个重要因素（例如查询的重要性和预期延迟的重要性）提供了机会。通过此过程进行工作，使我们能够测量运营效率低下，这是数据库管理员的另一个关键挑战。
但是，我们才刚刚开始。在Uber，机器学习（ML）和AI有可能重新设计我们如何设计更好的基础架构。随着我们业务的发展和发展，基础设施需要跟上。ML和AI可能是设计自适应和优化基础架构的关键。
如果您有兴趣在我们建立一个以数据驱动的平台来转移世界的平台时与我们一起工作，来加入我们的团队呢
