Airbnb正在为我们社区的数百万客人和主人提供服务。每一秒，他们都在Airbnb.com上的活动，例如搜索，预订和消息传递，都会产生大量数据，我们将其匿名化并用于改善社区在我们平台上的体验。
Airbnb的数据平台团队致力于利用这些数据来改善客户体验并优化Airbnb的业务。我们的使命是提供基础设施来收集，组织和处理大量数据（所有这些都以隐私安全的方式），并使Airbnb的各个组织能够从中获得必要的分析并从中做出数据知情决策。
公司内部公开和共享高级分析的主要方式是通过各种仪表板。很多人每天都使用这些仪表板来做出各种决定。仪表板还允许实时跟踪和监控我们业务和系统的各个方面。因此，这些仪表板的及时性对于Airbnb的日常运营至关重要。但是，我们面临三个挑战：
首先，在仓库中聚合数据需要很长时间，并在查询时使用Hive和Presto等系统为这些仪表板生成必要的数据。Hive / Presto必须读取所有数据并按需聚合，从而导致在查询时调用所有必要的计算。即使这些引擎用于预先计算聚合并存储它们，存储格式也不会针对分析查询所需的数据的重复切片和切割进行优化。
其次，系统需要可靠和可扩展。它正在为Airbnb的核心分析用例提供支持，因此任何停机都会对业务及其员工产生严重影响。此外，数据量，查询量和用户量也在不断增长，我们的分析系统应该能够应对不断增长的需求。
再次，我们需要一个与基于开源框架的数据基础架构完美集成的系统。例如，我们的大多数数据集都存储在Hadoop中，我们使用Kafka和Spark Streaming来处理我们的数据流。
这就是我们为什么要采用Druid的原因。
Druid的优点
快速查询时间
通过预定义的数据源和预先计算的聚合，Druid提供亚秒查询延迟。建立在Druid之上的仪表板明显快于在其他系统上构建的仪表板。与Hive和Presto相比，Druid可以快一个数量级。
提供可靠性和可伸缩性的架构
Druid的架构很好地分为不同的组成部分，用于注入、服务和整体协调。我们发现这种组件化架构对我们的工作负载来说是可靠和稳定的，并且它使我们能够根据需要轻松扩展系统。
Druid将数据存储分离到深度存储以便长期存储数据，同时在历史节点中临时缓存数据的架构对我们来说效果很好。将分析数据永久保存在S3中可以免费进行灾难恢复，并允许我们轻松管理群集硬件的升级和维护（例如，轻松切换节点类型以利用最新硬件）。
与开源框架集成
Druid还与主要基于Hadoop和Kafka的开源数据基础架构顺利集成：
1、Druid的API允许我们轻松地从Hadoop中提取数据以进行批量分析
2、Druid通过流处理引擎实现实时分析。Druid提供了一个流媒体客户端API，Tranquility，它与Samza或Storm等流媒体引擎集成，可以与任何其他基于JVM的流媒体引擎集成。在Airbnb，通过采用Tranquility客户端的Spark Streaming工作，将数据流传输到Druid进行实时分析。
3、Druid与Apache Superset很好地集成，Apache Superset是由Airbnb开发和开源的开源数据可视化系统。Superset是用户在Druid上编写和执行分析查询并可视化结果的界面。
Airbnb如何使用Druid：双群集配置
在Airbnb，两个Druid集群正在投入生产。两个独立的集群允许对不同用途的专用支持，即使单个Druid集群可以处理比我们需要的更多的数据源。我们总共有4个Broker节点，2个Overlord结点，2个Coordinator节点，8个 MiddleManager节点和40个Historical节点。此外，我们的集群由一个MySQL服务器和一个具有5个节点的ZooKeeper集群支持。与HDFS和Presto等其他服务集群相比，Druid集群相对较小且成本较低。
在两个Druid集群中，一个致力于集中的关键指标服务。为了服务Airbnb的所有仪表板，用户可以通过简单的YAML文件轻松定义他们的指标。用户可以在Superset上查看他们的仪表板和指标，而无需了解Druid的任何信息。
所有批处理作业都使用Airflow进行调度，从Hadoop集群中提取数据。
自助用户的所有实时和其他数据源都由其他德鲁伊集群处理。通过Spark Streaming + Tranquility客户端设置获取实时数据。
改善Airbnb的Druid用法
虽然Druid提供了许多强大的广泛适用的功能，以满足大多数企业，我们确实在Druid内部或之上实现功能，以更好地服务于我们的特殊用例。
即时应答Ad-hoc分析查询的框架
Airbnb拥有大量嵌入不同业务团队的数据科学家。他们每个人都可能有关于需要从数据中获得洞察力的业务的临时问题，这通常需要任意方式来聚合数据。
为了满足这一需求，我们在Druid之上构建了一个自助服务系统，允许各个团队轻松定义应用程序或服务生成的数据应如何聚合并作为Druid数据源公开。然后，数据科学家和分析师可以查询Druid来回答临时问题。
用户使用下面的配置定义其数据源。来自Kafka的实时数据和来自HDFS / S3的批量数据将根据配置文件被注入。
Druid通过5分钟的窗口聚合其实时数据，加上管道延迟1分钟。
来自Druid的实时流媒体使我们能够为用户提供许多复杂的功能。实时摄取的一个有趣的用例是异常检测。通过在Druid快速注入和汇总实时数据，我们可以非常快速地检测到生产中不符合预期模式的任何内容。
与Presto集成
除了最近版本的SQL查询支持外，Druid还有一个成熟的查询机制，使用JSON over HTTP RESTful API。但是，Druid的一个限制是它还不允许跨数据源查询（简单来说，是一个连接查询）。所有聚合查询都限于单个数据源。然而，在Airbnb中，我们确实有这样的场景，其中具有重叠维度的多个数据源需要连接在一起以用于某些查询。另一种方法是将所有数据保存在一个数据源中，由于各种原因（包括数据生成的节奏，数据来源不同（例如，不同的服务产生数据）等），这在我们的场景中不是最佳的。但是，对跨数据源查询的需求是真实的，并且最近成为一项硬性要求。
为了迎合这些情况，我们开发了一个基于Presto的内部解决方案。具体来说，我们为Druid引入了Presto连接器，可以通过单个数据源将查询推送到Druid，并且可以检索和连接数据以完成跨数据源查询的执行。实施细节仍在不断发展，超出了本文的范围。我们将在未来的单独帖子中提供更多详细信息。
改善回填性能
Druid查询比其他系统快得多的秘密是以注入为代价的。在可用于查询之前，需要首先从MapReduce作业中提取每个数据段。这非常适合作为一次写入多次读取模型，并且框架只需要每天注入新数据。
但是，当数据源的所有者想要重新设计它并重新生成历史数据时，就会出现问题。这意味着过去几年的数据需要重新注入Druid，以取代旧的数据。这需要一个非常大的注入作业和长时间运行的MapReduce任务，这使得它很昂贵，尤其是在重新注入过程中发生错误时。
一种可能的解决方案是将大量注入分成多个请求，以实现更好的可靠性。但是，查询结果将不一致，因为它将根据现有旧数据和新摄取数据的混合计算。随着用户需求和摄取框架功能的发展，回填作业实际上比我们预期的更频繁，使其性能成为一个需要改进的痛点。
为了解决这个问题，我们设计了一个解决方案，基本上保持所有新注入的段无效，直到显式激活。这使得提取框架能够将数据源分成具有可接受大小的较小间隔。然后，框架并行地注入这些间隔（与Yarn集群资源允许的并行）。由于新注入的数据仍处于非活动状态，因此当回填注入仍在进行中时，计算执行查询的结果时，这些段将隐藏在后台，并且不会混合不同版本的数据。当我们为数据源激活最新版本的段时，它将使用新版本刷新，而不会停机。拆分和刷新大大提高了回填性能，并且已经制作了用于运行的回填超过一天，现在在一小时内完成。
监测和操作
我们持续监控Druid的可靠服务和最佳性能。Druid强大且对节点故障具有弹性。大多数节点故障都是透明的，用户无法察觉。即使作为单点故障的角色（如Coordinator，Overlord甚至ZooKeeper）失败，Druid集群仍然能够为用户提供查询服务。但是，SLA出于对用户的尊重，任何服务中断都应及时或甚至在发生故障之前发现。
与其他集群一样，我们通过收集机器统计信息并在任何实例达到其容量或进入不良状态时发出警报来监控Druid集群中的每台机器。为了监控整体群集可用性，我们每隔30分钟将一段预警数据注入到Druid，并检查每个Broker节点的查询结果是否每5分钟与最新的注入数据匹配。可以在SLA内检测到服务中的任何降级，包括查询，注入或下游HDFS不稳定性。
Druid多年来一直在Airbnb运营，它是维护成本最低的系统之一。Druid的多角色设计使操作变得简单可靠。群集管理员可以根据监控指标调整群集配置并添加/删除节点。随着我们Druid集群中数据的增长，我们可以继续添加历史节点容量来缓存并轻松地提供大量数据。如果实时注入工作负载显示上升，我们可以相应地轻松添加中间管理器节点。同样，如果需要更多容量来处理查询，我们可以增加代理节点数。由于Druid的解耦架构，我们已经完成了一项大型操作，可以将新存储中的所有数据从HDFS迁移到S3，并重建新的集群，只需几分钟的停机时间。
挑战和未来的改进
虽然Druid在我们的数据平台架构中为我们提供了很好的服务，但随着我们在公司内部使用Druid的增长，存在新的挑战。
我们处理的问题之一是每天产生的需要加载到集群中的段文件数量的增长。段文件是Druid数据的基本存储单元，包含准备服务的预聚合数据。在Airbnb，我们遇到了一些场景，其中大量的数据源有时需要完全重新计算，导致大量的段文件需要一次加载到集群上。目前，Coordinator在一个线程中集中加载所注入的段。随着越来越多的段生成，Coordinator无法跟上，我们看到注入作业完成的时间与数据可用于查询的时间（协调器加载后）之间的延迟增加。有时延迟可能是几个小时。
通常的解决方案是尝试增加目标段大小，从而减少段数。但是，在我们的使用中，产生较大段的数据输入量（由Hadoop工作者运行摄取任务）是如此之高，以至于Hadoop作业运行太长时间处理该数据，并且由于各种原因很多次会失败。
我们目前正在探索各种解决方案，包括在注入之后以及在将其传递给协调器之前压缩段，以及不同的配置以增加段大小而不会在可能的情况下危害注入作业稳定性。
结论
Druid是一个专为可扩展性，可维护性和性能而设计的大数据分析引擎。其良好的因素架构可轻松管理和扩展Druid部署，其优化的存储格式可实现低延迟分析查询。目前，国外如Google、Facebook、Airbnb、Instgram、Amazon、Pinterest等，国内如阿里巴巴、小米、360、优酷、知乎、数极客等知名互联网公司都在使用Druid，发展势头如火如荼。相信在不久的将来，Druid将成为下一代OLAP实时分析引擎事实上的标准，让我们拭目以待吧！
本文由作者吴江林翻译并整理，转载请注明出处并保留此信息，谢谢！
原创文章，作者：Maggie-Hunter，如若转载，请注明出处：https://blog.ytso.com/190952.html