世界是一个大数据问题。——麻省理工学院首席研究科学家安德鲁·麦卡菲你可以拥有没有信息的数据，但是你不能没有数据就有信息，而且企业被来自不同来源的数据淹没。作为一家多产品公司，我们在过去几年中实现了快速增长，我们每个月的产品数据量超过50 TB。我们的每一款软件产品都迎合了客户旅程的不同方面，我们知道我们不能在数据隐私和安全性上妥协。我们一直试图解决的最大挑战是解释这些数据并从中产生见解，同时确保数据始终是安全的。当然，我们的系统旨在确保我们在安全性、治理和法规遵从性方面保持最高标准。今天，在数据科学团队、机器学习团队、客户成功团队、产品团队和业务运营团队之间，我们有很多人根据可用数据解释、分析和构建模型。以前，只有IT部门可以访问数据，业务部门必须通过IT部门来访问任何数据。组织的其他业务团队必须通过各种繁琐的手动操作来生成任何类型的信息。一方面，有些团队对数据访问有着持续的需求，另一方面，在保持安全和隐私规范受到检查的情况下，如何让团队使用这些数据是一个持续的挑战。早些时候，如果团队需要任何重要的数据，他们必须得到安全许可。然后DevOps团队将对我们的数据库进行查询，最后，他们将获得所需的数据。我们想设计出有助于应对这一挑战的前瞻性解决方案。我们希望使数据民主化，使我们的组织在数据驱动的解决方案上发挥作用。主要步骤是建立一个平台，提供透明性，并使用户能够信任他们正在处理的数据。显然，现在的需要是建立一个数据湖。这启发了我们在Freshworks启动大数据计划。我们需要创建一个庞大的静态数据体，或整个行业都知道的数据湖。像其他人工湖一样，数据湖需要稳定的输入流和处理设备来处理数据。apachehadoop拥有我们所需的所有工具来接收、处理和丰富传入的数据。贝加尔湖——人工湖的建设每个团队都有自己独特的目标和优先事项。它们生成的数据存储在筒仓中。固定数据的存储库由单个组织单元控制，其他团队无法轻松访问。为了获得业务洞察力并在日常运营中做出数据驱动的决策，我们需要确保所有团队都可以访问这些信息。为了整合为特殊用途应用而构建的数据仓库，我们使用Cloudera作为AWS平台，构建了"Baikal"，一个可伸缩的数据存储库。Cloudera是企业版apachehadoop的提供者和支持者。它提供了一个统一的平台来存储、处理和分析大量用于大数据分析的数据。它也有助于找到从现有数据中获取价值的新方法。我们组建了一支由专业工程师组成的小团队，帮助我们加速并实现我们建设数据湖的目标。我们以世界上最大的淡水湖贝加尔湖命名我们的人工湖。我们把它设计成从我们所有产品中捕捉数据，跨越所有可能的格式，并以可查询的方式存储。我们开始使用分析和处理框架/库构建平台，比如apachehbase、Apache Hive、Apache Pig、Impala、apachespark和其他生态系统组件。我们的目标是操纵原始数据并获得真正的见解，而不是让它成为一个简单的查询和数据提取工具。我们希望我们的数据湖成为真正的企业数据中心。到达正确的站台当我们开始的时候，我们显然选择了使用Amazon EMR。然而，Amazon EMR已经摆脱了最初的"临时"工作负载。当我们需要长时间保留集群时，amazonemr并没有很好地工作。绑定到AWS堆栈意味着我们不能选择访问像Cloudera或Hortonworks这样的富Apache组件。我们也调查了第三方数据湖提供商。基于S3的数据湖很容易设置。数据保存在S3中，集群在EC2上旋转以查询数据。甚至spot实例也可以根据使用情况上下旋转。经过详细讨论，我们决定在内部构建数据湖。这将使我们能够构建一个完整的解决方案，它将满足我们的需求，遵守我们严格的安全标准，允许细粒度的访问控制，并具有正确的性能/成本特性。此外，它还将帮助我们发展内部的专业知识，以便利用这样一个大规模的系统。Cloudera给了我们一个开始工作的平台。从工程的角度来看，它给我们提供了与开源堆栈相同的代码，但有错误修复、修补程序以及与Kerberos和同一系列中其他堆栈的互操作性。Cloudera为我们提供了可预测的、一致的平台改进访问，以及良好的社区支持。资料准备我们制定了建设过程的基本原则，并制定了最终目标。整个过程要求我们收集从不同来源摄取的数据，对其进行处理，并以某种易于访问的形式存储。 数据摄取Freshworks的数据分布在RDS、S3和自定义数据源中。在贝加尔湖，我们利用现有的堆栈从这些源获取数据。除此之外，我们还编写了许多定制的数据管道（使用AWS和Cloudera堆栈）来定期移动数据。在一些情况下，我们编写了自定义连接器来接收数据并将其带到Hadoop分布式文件存储（HDFS）和apachehbase中的数据存储中。我们希望高效地创建具有容错性、可重复性和高可用性（HA）的精细数据处理工作负载。Sqoop是一个命令行接口应用程序，是从RDBMS摄取数据到Hadoop集群的最常用组件。临时区域或着陆区域被创建为中间存储区域。它用于提取、转换和加载（ETL）过程中的数据处理。最终的相关数据存储在集群中，集群由蜂箱或清管器组件消耗。数据处理由于我们面向不同的团队，所以有多种处理数据的方法。虽然有些团队需要快速的即时报告，但有些团队发现注册一份工作并将报告发送到他们的电子邮件中更为合适。我们使用像Oozie和Luigi这样的工具来帮助创建自定义工作流。其他一些团队利用apachespark实现批处理功能。Spark在我们的Hadoop集群中运行，它在Scala、Java和Python中都有API。通过使用YARN作为内存，使用物理磁盘来处理数据，它为我们的开发人员节省了时间和资源。虽然我们为批处理打开了Spark，但我们知道它也提供了流分析的结构。在Freshworks，我们有一个团队在Kafka中心平台上工作，我们希望利用同样的下游平台。我们的许多开发人员利用Apache开发人员的实时机器来构建流水线。数据存储当我们开始集群规模实验时，我们很清楚，我们不会继续进行短暂的集群。我们需要一个不同系列机器的组合来处理不同的工作负载。下面的图表描述了我们如何开始根据各种工作负载和类型对机器进行分类。我们选择了一个具有临时存储的EC2实例，因为它为HDFS提供了最高的吞吐量。从历史上看，它一直是大多数Hadoop用户的明确选择。为了便于使用，我们以配置单元表的形式存储数据。从RDBMS中提取的数据以与在源中相同的方式存储。为了选择正确的压缩格式（Snappy、gzip等），我们做了全面的测试，并在更高的压缩比和性能之间找到一个平衡点，同时还要考虑CPU的使用情况。我们还进行了多次测试，并多次更改存储格式以满足我们的需要。最终，我们发现像apacheparquet这样的列式存储在快速数据摄取和快速随机数据查找之间提供了非常好的灵活性。贝加尔湖生产集群HLA体系结构概述我们从一个非常简单的管道开始：一个带有Sqoop、Hive和Oozie的Hadoop堆栈，用于从RDS摄取数据。我们面临一些常见问题，比如处理多行列、重音字符和增量更新。考虑到在我们平台上运行的应用程序的种类，我们需要我们的数据与数据源同步。我们从改造现有的堆栈开始，并使用一个已知的用例来普及该平台。stack位于Tableau（可以连接到Hive）后面，作为可视化平台，可以方便地阅读图表、信息图和报告，展示了与BI工具集成的容易性。为了让更多的利益相关者参与进来并为数据的使用产生新的想法，我们从一个客户流失用例开始，以帮助我们的客户成功团队。我们注意到某些定期运行的报告是资源密集型的，可以作为一个良好的开端，帮助我们在整个组织中宣传系统及其功能。我们使用Hive和Pig脚本自动化流程，并帮助客户成功团队在每个月的第一天提交报告。这个堆栈开始自动化许多报告，并帮助整个组织理解这样一个项目的重要性。后来，我们得以将数据平台发布给我们最大的消费者机器学习团队。—–这是我们为什么要建立数据湖的两个部分的第一部分。我们想分享我们的故事，并与世界各地的工程师们展开讨论