了解ETL——一位创始工程师的个人账号

barikulislam015

工作的过程中，我们开始在数据架构方面遇到困难。在本文中，我想分享一些经验教训，希望它们对您自己的工程之旅有用。 Hired 最初是一个由单个 Postgres 数据库支持的 Ruby on Rails Web 应用程序。所有数据（客户记录、点击日志等……都存储在该数据库中）。整个团队由产品工程师组成，他们负责添加功能并且非常熟悉应用程序及其生成的数据。该团队规模也很小，因此当数据库需要更改或需要更新客户数据时，每个人都知道。 随着时间的推移，生意越来越大。工程团队进行了扩展，我们在架构中添加了一个真实副本只读从属数据库，以便我们可以在不影响客户体验的情况下运行分析查询……但这个简单的应用程序结构运行良好……一段时间。

在公司的发展过程中，有一个明显的时刻，这种简单的设置开始崩溃，吸取的教训值得分享。 当事情开始发生变化时 当我们开始添加团队时，我们使用的简单数据架构确实开始崩溃。 我们添 电子邮件营销列表 加的第一个团队是数据分析师团队。他们的任务是通过使用数据回答业务问题来帮助管理层做出决策。 它们的到来代表了对我们的 Postgres 生产数据库的新依赖。为了完成他们的工作，他们需要一个可靠的、不变的数据库，他们可以在此基础上构建他们的工作，但他们没有。 建立在生产数据库之上意味着 —> 每次工程团队需要更改数据库格式时，数据分析师的仪表板都会不断损坏。 即使仪表板没有损坏，它们也常常是错误的，因为它们基于表中的列，而这些列的含义随着产品的变化而改变。



查询通常很慢。生产数据库架构未针对分析查询进行优化。 我们很快添加了另一个数据依赖项——数据科学团队。事情变得更糟了。 数据科学家建立在生产数据库之上，因此…… 他们的模型不断出问题 模型质量通常不是很好，因为团队不清楚数据收集方式的怪癖 他们的转型需求大于分析师团队的需求，因此长时间运行的查询非常痛苦 显然必须采取一些措施，因此我们开始考虑构建更复杂的数据架构。 Integrate.ioIntegrate.io 现代数据团队的统一堆栈 与解决方案工程师一起获得个性化平台演示和 30 分钟问答环节 公司电子邮件地址 我们添加了一个数据仓库 我们尝试解决数据问题的第一件事是添加 RedShift。