为什么 LinkedIn 改变了他们的数据分析技术堆栈 - Quastor


LinkedIn 之前使用Teradata 第三方专有平台进行数据分析技术堆栈,这种方法导致了扩展问题,并使系统难以发展,LinkedIn 转而使用开源软件和 Hadoop 生态系统。
Steven Chuang、Qinyu Yue、Aaravind Rao 和 Srihari Duddukuru 是 LinkedIn 的工程师。他们发表了一篇关于将 LinkedIn 的分析堆栈从专有平台转换为开源大数据技术的有趣博客文章。
这里是摘要:
在 LinkedIn 的早期阶段(2010 年代初),它们的增长速度非常快。为了跟上这种增长,他们在分析堆栈中利用了几个第三方专有平台 (3PP)。
使用这些专有平台比拼凑现成的产品要快得多。
LinkedIn 依靠 Informatica 和 Appworx 进行 ETL 到使用 Teradata 构建的数据仓库。
ETL代表提取、传输、加载。它是将数据从各种来源(不同的数据生产者)复制到单个目标系统(通常是数据仓库)中的过程,在该系统中可以更轻松地使用它。 
这个堆栈为 LinkedIn 服务了 6 年,但它有一些缺点:

  • 缺乏发展的自由——由于这个系统的封闭性,他们在创新的选择上受到限制。此外,与内部和开源系统的集成也是一个挑战。
  • 扩展困难- 由于 Informatica/Appworx 许可证的限制,数据管道开发仅限于一个小型中央团队。这日益成为LinkedIn快速增长的瓶颈。

这些缺点促使 LinkedIn 工程师在 Hadoop 上并行开发一个新的数据湖(数据湖允许您包含原始数据而无需对其进行结构化)。
您可以在此处了解 LinkedIn 如何将 Hadoop 分布式文件系统扩展到 1 EB 的数据。
但是,他们没有明确的过渡过程,这导致他们同时维护新系统和旧系统。
数据在技术堆栈之间复制,导致维护成本和复杂性增加了一倍。
 
从Teradata迁移出数据
为了解决这个问题,工程师决定使用 Hadoop 将所有数据集迁移到新的分析堆栈。
为了做到这一点,第一步是导出 LinkedIn 的数据沿袭。
数据沿袭是跟踪数据从数据源流向消费的过程,包括数据在此过程中经历的所有转换。
了解这一点将使工程师能够计划数据集迁移的顺序,识别零使用数据集(并删除它们以减少工作量)并跟踪新旧系统的使用情况。
您可以在全文中准确阅读 LinkedIn 如何处理数据沿袭过程。
在数据沿袭之后,工程师使用这些信息来计划主要的数据模型修订。
他们计划将 1424 个数据集合并到 450 个,有效地从迁移工作量中减少约 70% 的数据集。
他们还将 OLTP 工作负载生成的数据集转换为更适合业务分析工作负载的不同模型。
迁移是使用各种数据管道完成的,并说明了 LinkedIn 系统中的瓶颈。
瓶颈之一是Avro 文件格式的读取性能差。工程师迁移到ORC后,读取速度提高了约 10-1000 倍,压缩率提高了 25-50%。
数据传输后,如果手动完成旧系统上 1400 多个数据集的折旧,将是乏味且容易出错的,因此工程师还构建了一个自动化系统来处理此过程。
他们构建了一项服务来协调弃用,该服务将识别要删除的候选数据集(没有依赖关系且使用率低的数据集),然后向这些数据集的用户发送电子邮件,其中包含有关即将弃用的消息。
该服务还将通知 SRE 在宽限期后从遗留系统中锁定、存档和删除数据集。
 
Hadoop新系统
新生态系统的设计深受旧生态系统的影响,并解决了遗留技术堆栈的主要痛点。
  • 数据民主化- Hadoop 生态系统支持 LinkedIn 的其他团队开发和采用数据。以前,由于专有平台的许可限制,只有中央团队可以在旧系统上构建数据管道。
  • 通过开源项目实现技术开发的民主化——新技术堆栈的所有方面都可以通过开源或定制项目自由增强。
  • 技术堆栈的统一——同时运行 2 个技术堆栈显示了维护冗余系统的复杂性和成本。统一技术可以大大提高效率。

新的技术堆栈具有以下组件
  • Unified Metrics Pipeline - 开发人员提供 ETL 脚本来创建数据管道的统一平台。
  • Azkaban - 一个分布式工作流调度程序,用于管理 Hadoop 上的作业。
  • 数据集读取器 - 数据集存储在 Hadoop 分布式文件系统上,可以通过多种方式读取。
    • 它们可以被DALI读取,这是一种 API,开发用于允许 LinkedIn 工程师读取数据而无需担心它的存储介质、路径或格式。
    • 它们可以被各种仪表板和业务分析的临时查询读取。

有关 LinkedIn 的学习经验及其数据(和用户)迁移过程的更多详细信息,请阅读全文