Zillow产生大量数据！ 我们是美国1.1亿套房屋以及多户出租房屋的信息来源。 就摄取和存储而言，两者都需要大量数据。 Zillow还使用外部数据源，包括来自Google Analytics（分析）的Clickstream数据。 Zestimate团队在先前的博客文章中描述了他们如何使用数据作为事件流来加快Zestimates的计算。 这篇文章将详细介绍我们如何开发用于处理点击流数据的管道，克服规模问题以及如何构建可用于数据收集和处理的通用平台。
来自数据库的数据
Zillow最初成立时，我们使用了许多数据库来存储数据，并在前面使用了高速缓存以实现快速搜索和快速查找。 后来，我们将Amazon S3标准化为我们的数据湖提供商。
我们必须克服如何将数据库中的数据放入数据湖的挑战。 最初，我们转而使用自定义Sqoop作业直接从表中提取数据并将其放入S3。 这解决了将数据导入S3的直接问题，但同时也引发了一些问题。
首先，由于Sqoop作业是由数据科学/工程组织的开发人员编写的，他们不知道表的语义或它们如何适合产品。 而且他们必须不断地跟上模式的变化。
其次，导出的数据的模式紧跟数据库（DB）的模式，并且数据库模式不一定针对数据科学/机器学习应用程序进行了优化。
由于Sqoop导出作业每天运行，并且有时会影响面向现场站点的数据库，因此DBA必须创建这些数据库的特殊只读副本。 这需要更多的维护和开销。 这些数据库中的某些数据库无法轻松复制，这迫使我们不得不从一日的旧数据库快照中读取数据。
直接写入Data Lake
一些产品团队编写了将数据直接写入S3的代码。 尽管这使产品团队可以直接发送数据，但这也意味着无需执行架构。 有些团队写了Json，而有些团队写了文本文件或csv文件。 文件的结构由团队定义，并且不一致。 更改架构时，对于历史数据进行回填的时间没有一致的规则。
这还要求团队创建和管理自己的AWS资源。 如果他们直接写到S3，则需要创建适当的角色和凭据。 如果他们使用firehose写入S3，则除了凭据之外还必须创建一个firehose流。
最后，人们并不了解数据的治理和生命周期策略。 例如，如果数据包含PII，则应将其加密。 否则，原始数据和处理后的数据应具有不同的生命周期策略。 通常，当团队直接写信给S3时，他们并不了解这些策略。
数据流平台
为了解决以一致的形式将数据传输到数据湖的问题，我们开发了一种流媒体平台即服务。 我们的目标是将流处理作为服务平台构建和架构，以支持实时分析和机器学习应用程序。 该体系结构的主要原则如下：
建立流媒体基础架构
我们标准化了使用Streams将数据发送到数据湖的过程。 团队不了解流，相反，他们只是调用使用基础流发送数据的REST API。 通过从消费者那里提取底层技术，它使我们可以监视使用情况并根据需要扩展容量。 团队可以在不了解基础流技术的情况下发送事件和其他数据集。 团队无需担心流传输基础架构，而专注于数据分析。 我们使用持久路由表将消息路由到正确的目的地。
为每个应用程序创建单独的流
由于用户不再参与底层的流技术，因此他们可以直接请求资源并开始使用它们。 这使他们可以获取所需的尽可能多的流资源，并以所需的粒度使用它们。
生产者和消费者流分开
生产者流只能由基础结构团队访问以进行数据转换。 由于我们不知道访问流的客户端数量及其访问方式。 将消费者流与生产者流分开创建是安全的。 这将确保使用者可以连接而不会影响接收消息的能力。 这也使我们能够分别扩展消费者和生产者流，从而使我们能够维护我们为数据传输设置的严格的服务水平协议（SLA）。
支持将数据发送到Kafka
我们正在组织内部的Kafka集群，以支持更多的低延迟和高吞吐量的用例。 此外，我们添加了对发送到Kafka主题作为目的地之一的支持。 这与架构注册表紧密集成，以支持具有架构的消息并强制执行兼容性约束。
支持通用处理/归档方案
通常，当某人想要将数据发送到我们的系统时，他们也希望能够轻松查询它。 为了支持这一点，我们实现了"流处理即服务"范例，通过该范例，发送到我们系统的数据会自动存档到Hive表中，并且可以使用Mode或Tableau查询最终用户（分析师和业务用户）的数据。
数据目录和发现
随着我们的数据生产者和消费者的增长，需要进行分类，以便我们知道谁在以何种格式和架构生产数据。 我们还需要知道谁是消费者，以便进行数据治理，并能够就上游数据集的问题或更改向数据消费者发出警报。 为了支持这一点，我们实现了一个可搜索的数据目录，该目录存储了有关所有数据实体和相关上下文（包括数据沿袭）的当前元数据。 数据目录还用于标记具有特殊特征的数据集，例如个人身份（PI）数据和生命周期策略。
资料品质
需要检查流入系统的所有数据的质量。 这可能包括架构检查，数据完整性检查以及度量标准值检查。 我们实施了一项称为Luminaire的数据质量服务，该服务结合了启发式方法和模型来跟踪数据集的质量。 它使用时间序列模型的集合来确保数据流符合我们的预期，否则，它将向上游生产者发出警报。
当前用法
当前，我们有以下类型的数据流过该系统。
当前的挑战
静态基础架构工具
我们在Zillow大量使用terraform来创建基础结构。 这包括设置AWS资源（如运动和流水流），拆分EMR集群以处理数据等。使用terraform按需拆分资源对我们而言并不理想，尤其是因为资源请求来自外部团队，并且 由于我们的数据湖帐户具有共享性质，因此需要一些周转。
为了解决这个问题，我们正在缓慢地移动团队来使用Kafka主题，并且我们正在开发一个CICD管道，该管道可以自动创建主题并在架构注册表中注册Avro架构。 我们将在以后的博客文章中进一步描述此过程。
Kinesis客户生态系统
Kinesis流允许每个分片限制容量，并通过添加更多分片来缩放。 为了最大程度地利用分片容量，建议使用Kinesis Producer库（KPL）。 我们的初始部署使用KPL写入运动学流。 但是，我们发现这不能很好地扩展，因为我们的服务正在写入许多不同的流，并且KPL用于跟踪每个流的分片和每个分片的消息缓冲的开销导致我们的服务消耗了JVM堆资源，并且 死。 我们决定不花时间来进行更多的调整，而是决定编写自己的KPL兼容库，该库提供了KPL的某些功能。 换句话说，我们决定权衡利用运动流分片容量的效率低下，以改善服务稳定性。
另外，由于其他方面（例如Python）对KPL的支持还不够完善，因为它需要在侧面运行本地语言守护程序。 由于这些问题，我们认为迁移到Kafka将使我们能够提供分区的高利用率以及服务稳定性。
结论
通过创建数据流平台，我们使团队能够轻松地将数据发送到数据湖。 现在，他们可以请求资源，而无需联系AWS Account管理员。 将验证所有正在发送的数据的架构。 这将团队向数据湖发送数据的速度从数周提高到了几天。 它还使数据科学团队能够对我们的点击流数据获得新的见解，从而使个性化功能可以在房屋详细信息页面上显示"相关房屋"。
(本文翻译自feroze daud的文章《Building a Data Streaming Platform — How Zillow Sends Data to its Data Lake》，参考：https://medium.com/zillow-tech-hub/building-a-data-streaming-platform-how-zillow-sends-data-to-its-data-lake-821df8223ea2)
