我们在客户自己的基础架构运行软件上销售的客户赌注，而不是建立更传统的SaaS平台。 Redactics都是所有数据管理：主要是用PII去除测试和演示环境（包括ML，分析等）的数据管道，数据传递给利益相关者，数据库迁移/模式迁移，数据销毁，数据销毁等，我们简而言之，我们试图将自己定位为一种可靠的工具包，用于构建自动数据工作流程。我们是一家新公司，很想听听大家的消息，但是我会在这里停下来，这样就不会作为自我服务的推销！

我们认为将这家公司建立为SaaS平台将有许多技术缺点：将数据保险公司运送到云，性能，成本开销等方面的数据安全问题。像钟摆一样来回来回 - 例如，经典的大型机与薄客户问题。相对而言，没有多少公司采用托管设备的方法（尽管我们确实用云托管的API补充了当地的代理商），因此，谁知道，也许我们是朝着另一个方向摇摆的钟摆的一部分（供非常具体的使用案例）或只是我们的脑海！

空气流和库伯尼特的存在确实为我们做出了这一决定时的规模，很难想象没有这些技术就建立了这家公司。气流肯定可以水平扩展以管理数十亿个工作和工作量，但是我们对它的运行方式印象深刻，简约的资源足迹以及在非常适中的硬件上对我们的韧性。 2.x中调度程序的改进以及2.3中的动态任务映射功能是巨大的改进，后者允许我们的DAG远程管理云（稍后再详细介绍）。

我们认为可能有感兴趣的观众了解我们的策略对我们成功。

Kubernetes和Helm

我们是Helm的忠实拥护者，这是客户如何安装/引导我们的代理软件的关键要素。我们的仪表板既可以为客户构建工作流程配置，又是用于安装和更新代理软件的Helm install/升级命令。我们运行自己的ChartMuseum注册表，以便客户可以采用“如果不破产，不要修复它”的方法，将其版本固定，以便他们可以在闲暇时升级（和降级）。用户可以复制和粘贴的单个命令（以及一次Docker注册表和ChartMuseum身份验证步骤）确实非常适合我们构建交钥匙式设备的方法。

托管Kubernetes服务（EKS，GKE，AKS等）的受欢迎程度和普遍性是另一个重要因素，因此我们可以提供一个简单的配方（或Terraform计划），以为未使用Kubernetes的客户设置此基础架构。

数据库身份验证

如果您在下面使用了气流，您知道它包括对加密变量的支持，这是存储敏感信息（例如数据库密码）的合适方法。但是，Kubernetespeperator无法使用这些，因此需要将其作为秘密提供。我们创建了一个脚本来运行airflow connections delete和airflow connections add commands，以根据通过local values.yaml文件传递给helm的值来重新创建这些连接。这样，由于定义了新的输入源或旋转密码将应用于每个Helm升级命令，因此我们不必让我们的用户将密码输入Relectactics仪表板。换句话说，它们的连接信息是对Redactics仪表板生成的配置的本地增强，并且仪表板与“ Changemes”一起生成了一个模板配置文件，其中应提供身份验证信息，并通过更换其本地配置文件来替换其本地配置文件。这些“变化”及其真实价值。

Kubernetespererator，资源管理

因为我们正在安装在Kubernetes上，所以我们有利用Kubernetespeperator来进行一些工作流程，尤其是那些依赖依赖的工作流程。设置容器资源限制有助于我们忠于我们在非常简约的资源足迹中坚持的目标，即使数据集的大小不断增长。在并行运行步骤时，这特别有用，并且由于我们的工作流程中的步骤数是动态和上下文依赖性的，因此设置max_active_tasks DAG参数以确保您的资源在其分配的足迹中运行非常重要。否则，您的工作流程可能真的很慢，/或您可能会面临Pod驱逐。

我们将气流的头盔图设置为跳过安装Web服务器，因为我们使用on_failure_callback回调来读取文件系统中的日志并将其发送到我们的API，以使我们的Redactics Dashboard是客户接口的Redactics Dashboard，以便他们不使用。必须在我们的仪表板和气流Web服务器之间跳跃。我们将POD Exec命令发送到调度程序中的气流CLI，而不是用于手动启动工作流的REST API。我们的代理软件安装了一些不同的豆荚，但是唯一需要的气流吊舱是单个时间表。它也向我们的API发送了心跳，因此我们可以在仪表板上提供有关安装状态和健康的反馈。

动态任务映射

我们急于尝试使用AirFlow 2.3的Dynamic Task Mapping以及Taskflow API引入先验，因为没有这些功能，我们只能将预设的工作流程配置注入DAG，这意味着每当我们想更新工作流程配置时，这些DAG也不会必须进行更新，这意味着需要运行的另一个Helm升级命令。现在，我们的DAGS执行以下操作：

• 从我们仪表板的API中获取工作流程配置（我们可以控制用this Airflow variable刷新DAG的频率，或者使用REDIS/MOMEME CACHING降低负载
• 几个工作流程步骤具有KubernetesPodOperator命令，这些命令是基于这些工作流程配置动态生成的，从我们的API中获取了Python函数，例如以下内容：

@task(on_failure_callback=post_logs)
        def gen_table_resets(input_id, schema, **context):
            tables = []
            for input in wf_config["inputs"]:
                if input["id"] == input_id:
                    for table in initial_copies:
                        tables.append(table)
            if len(tables):
                return [["/scripts/table-resets.sh", dag_name, schema, ",".join(tables)]]
            else:
                return []

• 每个工作流程配置都有自己的DAG，因此可以独立跟踪此工作。上面的dag_name变量或唯一的配置ID。这样可以确保如果您使用多个数据库使用编辑器（正如我们希望您会的），那么一个工作流的问题是孤立的，不会影响其他工作流程。

报告

我们提到了利用on_failure_callback回调向我们的API报告问题，但是我们还利用on_success_callback回调来渲染进度条，并通过将其发送到我们的API中以在我们的仪表板中显示。

我们的CLI支持输出有关豆荚健康，拉链日志等的诊断信息。但是到目前为止，我们的客户还不需要此功能。我们建立了这一点，目的是必须与客户深入参与特定问题，但是使用Kubernetes的优势是，当客户已经熟悉它时，他们可以有些自给自足。例如，我们的代理支持被固定在特定节点上，这可以像将任何其他POD分配给节点的方式相同。

持续存储，并行任务

我们构建了一个open source streaming network file system，有点像带有HTTP接口的NAS，因此Pods可以轻松访问和共享文件，包括并行运行的任务同时使用。我们决定采用这种方法，而不是将文件运送到Amazon S3之类的，部分原因是，这种方法在我们的“使用基础架构”设备方法中更适合，而无需让客户导航创建与代理商一起使用的存储桶（并处理可能的数据隐私问题）。当然，性能是在这里评估我们的选项的另一个重要因素，为客户提供了不必开放任何出口网络的选择。我们写了another article关于这一点，以防万一您想了解更多信息，但这绝对是一个挑战，因为ReadWriteMany Kubernetes持久存储选项不是给出的。

气流平行支持运行任务，这是提高工作流程性能的好方法。

概括

气流通常是工作负载的绝佳选择，但即使是那些需要那种“气流”极简主义方法的选择。您唯一的挑战可能是某种共享文件系统。我没有理由想到为什么编辑性和托管气流设备一般也无法在VM上使用，前提是您可以提出一种简化安装和更新此软件的方法。

我们希望其中一些信息有用！请确保让我们知道...