数据在Freshworks的产品设计中起着关键作用。在我们关于如何构建数据湖贝加尔湖的系列文章的第一部分中，我们介绍了如何设计和构建贝加尔湖，以及如何开放我们的各种数据，使其从一个内聚层访问。在这篇文章中，我们将深入研究我们在数据湖上构建的内容。数据摄取-增量策略当我们从数据摄取开始时，我们一直保持简单。我们使用Sqoop、Hive构建了一个管道，并使用Oozie对其进行了调度。通过微调Sqoop（使用映射器）、管理列中的多行数据、处理重复项和国际字符，我们做了大量的性能优化。随着平台使用量的增加，物联网工程师，对刷新的需求也越来越频繁，对增量数据的需求也随之增加。我们想出了以下策略来解决这个问题。增量更新策略Hadoop并不是用来处理更新和删除的，但我们的重点是使用配置单元工具集中的标准SQL来实现这一点。下面的过程展示了我们是如何做到的。Sqoop阶段：在这个阶段，我们只从所有碎片中提取通过使用updated_at列而更改的数据。（Freshworks数据因其规模庞大而被分成碎片）配置单元阶段：在这个阶段，我们将数据移动到一个临时表中，并执行重复数据消除检查（一种双重检查，以避免在迁移和重新平衡期间出现任何重复数据）。配置单元调节阶段：更新记录：Staging Table（例如Staging A）：这个表包含新记录和更新的记录现有表（例如B）：它包含旧数据。最终（刷新）表：从B获取数据并将其添加到A（不包括A中存在的数据，因为它们包含相同的ID，但包含旧记录）。删除记录：每周一次，我们对贝加尔湖的数据（来自RDS）进行一次彻底刷新，以确保所有安全策略都得到遵守数据安全我们的主要目标是确保我们遵守安全政策。我们实现了数据发现和分类，以确定应用程序级别的IT安全需求。我们使用activedirectory（AD）实现静态数据加密和身份验证。我们设计了一个细粒度的、基于角色的策略。Baikal由Cloudera提供支持，它支持Kerberos进行身份验证，物联网网关，Apache Sentry进行授权。身份验证Hadoop借助Kerberos支持企业级认证系统。Hadoop生态系统的几个组件聚合在一起使用Kerberos身份验证，并在activedirectory中管理和存储凭据。首先，我们在AWS中设置了简单的AD，并将所有EC2实例与AD集成在一起。我们根据Freshworks的组织结构创建了组，最后在Cloudera中启用了Kerberos。这确保了如果没有Kerberos会话，就无法访问系统中的任何服务或执行任何操作。授权使用Apache Sentry（对于配置单元、Impala和Search等服务）和HDFS访问控制列表强制执行策略。基于在一个简单的AD中创建的组，这些组在与AD集成时会自动同步到EC2实例。今天，我们不仅将Sentry用于Hive、Impala和HDFS，还使用Kafka（限制对主题和消费者组的访问）和Solr集合。数据探索建立数据湖的主要原因之一是为了确保数据探索的便利性。正是出于同样的原因，我们以人们最熟悉的形式提供了数据。我们保持了与RDS中相同的模式，并开始评估编辑器，使最终用户的自助查询更简单。自助服务门户刚开始的时候，我们只有五个人。我们面临的挑战性任务是推动采用率，以及满足每个团队的需求。我们希望在数据平台上实现一个自助门户。我们希望为我们的内部团队提供一个基于角色的、安全的、经过身份验证的数据访问，而不会对我们的团队造成依赖。Hue（在Cloudera中是现成的）是一个完美的web应用，我们用apachesentry定义了具有细粒度安全访问的数据库。在某些情况下，一些组只需要访问数据库中的特定表。apachesentry允许我们限制到列级别，而安全性是决定选择Cloudera而不是基于amazons3的datalake方法的因素。配置单元编辑器可供用户查询数据。Oozie工作流编辑器为用户开放，用于定义工作流和调度作业。我们举办了一些有针对性的会议和研讨会来帮助船上团队。用户采用率随着数据流的增加而增加。我们还必须对色调代码进行大量更改，以使其满足我们的需求。它需要在身份验证模块中进行一些修复，以支持Google授权登录，然后将用户记录与广告用户记录链接起来，因为它们是用于授权的记录。使用黑斑羚进行数据探索对于非工程团队的性能优化和易用性，解释MapReduce的操作方式以及它们与在MySQL中运行查询有多大的不同，这是一种过激的做法。黑斑羚是一个更好的选择。它有一个与MapReduce不同的执行引擎，可以缓存类似的查询，自助免费建站，从而使速度提高600%。Hadoop需要一个专门的数据管道来探索数据，并在那里运行数据。最初，优化配置单元查询主要集中在分区和bucketing等技术上。在对Hadoop进行了大量的性能优化之后，我们推出了Impala。我们用zlib将配置单元表存储格式更改为Parquet和compression type为Snappy。新格式大大增加了文件的大小，因此同一查询所需的容器数量也增加了，但它减少了解压缩数据所需的CPU周期。贝加尔湖作为平台贝加尔湖是作为一种服务而建立的。按照它的设置，机器学习团队成员开始编写自己的Spark流，以微批量方式处理数据，以运行他们的算法并在其上构建模型。基于Spark的Kafka流处理apachespark是Cloudera的一个捆绑包，它帮助我们进行大规模的数据处理，并支持不同的编程语言和框架。Spark基于轻量级但功能强大的API，还支持内存处理、流处理、图形处理和机器学习。我们设置了一个下游的Kafka（捆绑在Cloudera中），它使用集中Kafka服务的数据。这个集中的Kafka服务处理来自所有Freshworks产品的数据，我们希望使我们的工程团队能够实时处理数据。下游Kafka中可用的流数据已准备好由Spark处理，我们还将这些数据存储在HBase中，以供我们使用的各种分析和报告工具使用。日志分析我们需要实时的应用程序日志来调试和分析流。日志摄取是使用Flume、morfline和Solr（Cloudera Search）完成的。这些不仅被我们的DevOps团队使用，也被我们的支持团队使用。我们每天需要对将近1TB的数据运行服务器日志分析。为此，我们构建了一个包含apacheflume、Solr和Hue的管道来获得结果。我们的分析显示，只有30天的数据被用于实时需求，怎么做淘客，而其余的数据主要用于审计跟踪。apacheflume代理推送的数据，安装在所有应用服务器上，使用morfline在Solr中解析、丰富（针对地理空间需求）和索引。对于一个多租户系统，我们必须从CPU使用率到内存存储量调整许多参数。幸运的是，Cloudera附带了CGroups（静态资源分配），它帮助我们更好地管理集群资源。我们还微调Flume，Solr，以处理接近80000条消息/秒。报告我们使用Oozie来定义和安排报告工作流。我们使用配置单元查询，并在Beeswax配置单元编辑器中测试后插入到Oozie工作流中。这有助于我们在不接触命令行的情况下提取数据。工作流包含一个操作（通常发送电子邮件），该操作将用户查询的数据作为CSV文件发送给用户。或者，企业信息化应用系统，可以在HDFS、HBase和S3中以不同的文件格式存储浓缩/聚合数据（非PII）。有些甚至被推到BI工具中进行进一步的分析处理。作战情报对日志中的非结构化数据进行解析、处理和充实。然后它们以蜂箱表的形式存储。我们的DevOps团队密切关注性能，因为糟糕的性能会对业务和用户产生负面影响。除了使用这个系统来跟踪事件和调试问题外，DevOps团队是这个平台最早的采用者之一。他们还生成并发送各种组件的95%和90%响应时间的报告，称为"快感度量"给产品团队。这些报告用于为自动基线、行为学习和优化应用程序流提供全面的基础。BI工具业务和功能被广泛使用。仪表盘由数据湖的数据驱动。为了实现高级分析，我们帮助团队构建多维数据集（跨维度预先汇总）并生成他们选择的仪表盘。例如，在Sisense中，我们使用Kerberos保护的Hive JDBC连接器集成产品。在任何情况下，权限都由哨兵负责。我们还使团队能够从Hue编辑器编写和运行自己的Oozie作业。这样，可以访问nateroapi的团队就可以使用Oozie协调器来推送数据。我们对未来的展望从一开始，我们的工程领导团队就在我们的工作场所宣传数据驱动的决策和解决方案。我们，Freshworks的数据湖团队，立志要把贝加尔湖打造成一个真正民主化数据访问的平台，并帮助每个te