快手的OLAP平台诞生的时间不长，在2018年4月份之前，一些多维分析的需求还是采用预定义指标加上离线计算的方案。然而，这种方案有很多缺点，首先指标预定义是非常固定的，另外因为采用离线计算，实用性也很差。在今年4月份上线Druid OLAP分析引擎，加上Superset数据可视化平台，解决了不少业务的痛点。5月，Druid平台升级到了当时社区最新的0.12的版本，在升级过程中解决了时区、文件加载性能等问题。7月，Druid平台每天的录入消息数已经突破1000亿，用户配置的可视化图表也超过1000个。7月份之后平台进入了一个快速发展的阶段，Druid在查询性能和稳定性方面都出现了很多的问题，我们做了非常多的改进。9月，上线了Druid探针系统、时序和维度物化视图功能、Indexing Service细颗粒资源分配等，另外在资源调度层面也做了大量优化工作。截至今年11月，OLAP平台每天摄入消息的数据量峰值已经超过5000亿，用户配置的可视化图表数已经突破1万。 半年来OLAP平台发展速度非常快，得益于基于Druid的高可用架构设计，以及团队伙伴的努力，整个OLAP平台上线至今未出现中型或大型的故障，服务很稳定。 快手OLAP平台共有150台物理服务器，接入的数据源超过2000个，每天录入的消息数量在5000亿左右，索引的数据存量约400TB。每天查询次数峰值1000万，这个量是非常大的，但是有很多在程序里触发API的调用，人为触发的比例较小。整体上平均查询时延为50毫秒，P90为100毫秒左右，P99为500毫秒到1秒。可视化方面，积累的用户看板数有八百多个，图表数超过1万。 在快手的多媒体质量分析业务中，公司利用全国多家CDN厂商的服务，涉及数百个域名，每天上报的CDN质量监控数据高达数十亿。为了确保主站APP用户的良好体验，CDN质量团队必须实时分析和调度CDN监控数据，并对调度效果进行实时监测。此外，快速定位和解决CDN质量问题也是一项多维分析任务，OLAP技术在这方面能够提供有效的支持。 另一个关键业务场景是A/B测试。快手已经实施了约1000个A/B实验，需要对比数千个A/B指标，每天有数百亿的数据流入A/B测试平台。对A/B测试指标的分析是一个典型的多维分析过程，而OLAP平台需要满足每天几十万次查询调用的需求，查询时延需控制在毫秒级。 在选择OLAP平台时，对公司多个业务团队的需求进行了调研。总结来看，以下几个需求关注度较高：超大数据规模的支持、查询时延（毫秒到秒级）、数据实时性、高并发查询和平台稳定性等。除此之外，还有一些相对权重较低的需求，如数据Schema的灵活变更、精确去重功能以及SQU接口的支持等。 根据用户调研结果，我们对比了目前常用的OLAP技术。 首先，Hive/SparkSQL在数据仓库领域应用广泛，但由于查询时延难以达到毫秒级要求，且为离线计算，数据时效性较差。 其次，ES系统功能强大，在中等数据规模场景下能够满足需求，但在万亿和更大数据规模的场景下，数据的写入性能和查询性能都面临较大挑战。 Kylin和Druid功能相似，考虑到Druid采用OLAP架构，数据时效性相对较好，数据的变更也更为灵活，因此最终选择了Druid作为OLAP平台的查询引擎。 Druid 系统架构图展示了其核心组件，包括主节点 Coordinator 和 Overlord、负责数据索引的 Middle Manager、提供历史数据查询服务的历史节点，以及作为查询接入点的 Broker。此外，Druid 还涉及对元数据的存储，如选择 MySQL 数据库。在生成索引文件时，Middle Manager 会将索引文件发布到共享的 HDFS 系统中。 Druid 之所以查询性能出色，主要得益于以下五个技术点：
数据预聚合：Druid 将一行数据消息分为三个部分：时间戳列、维度列以及指标列。当数据录入系统时，按照一定周期进行预先聚合，从而根据全维度聚合出要计算的指标，即索引内容。所有后续查询都基于这些预聚合的结果进行二次查询，显著提高了查询效率。
Bitmap 索引：Bitmap 索引旨在加快有条件过滤查询的场景。在生成索引文件时，对每个列的每个取值生成对应的 Bitmap 集合。例如，如果性别为 Male，则 Gender = ‘Male’ 的 Bitmap 为“1001”，代表第 1 行和第 4 行的性别为 Male。通过这种方式，可以快速定位到符合特定条件的数据，极大地提升了查询速度。 在快手的OLAP平台架构中，Druid模块扮演着至关重要的角色。它不仅支持从Kafka实时导入数据，还具备批量从HDFS或HIVE系统进行离线导入的功能。此外，Druid提供了丰富的查询API接口，这些接口除了默认的Restful接口外，还包括Python、Java和Go等编程语言的第三方实现API接口。值得一提的是，自Hive 2.2版本起，通过StorageHandler实现了对Druid的支持，使得可以通过Hive SQL查询Druid中的数据。快手内部也在使用这一功能，但需要解决时区问题、数据源维度和指标的大小写敏感问题，以及实现默认的limit和时间范围选择等功能。 Druid在快手的使用经验以及一些主要改进点： 快手的OLAP平台架构图显示，中间部分是Druid自有的组件，数据通过Kafka实时摄入和从Hive数仓中批量导入。此外，我们还配套了完善的Metric系统、探针系统和Druid数据源管理系统等。 面对万亿甚至几十万亿数据规模的场景，OLAP平台在使用过程中也面临诸多挑战。为了提升查询速度、提高资源利用率、简化数据管理流程并确保集群的稳定性，我们进行了针对性的改进和优化。 首先，在稳定性方面，我们实施了多种资源隔离部署方案，并在接入层通过代理实现Broker的高可用和负载均衡。在Historical数据存储层，我们进行了两个层面的数据划分：一是数据的冷热分离，热数据存储在SSD的机器上，当热数据变成冷数据后会自动迁移到HDD机器上。考虑到SSD的成本较高，我们可以将一个副本放在SSD上，另一个副本放到HDD机器上，并通过设置SSD副本的权重来平衡大部分请求落在SSD上的情况。当SSD机器出现故障时，请求才会发送到HDD上，这样可以显著节约成本。 在快手的数据处理系统中，为了优化查询性能，特别是在面对大规模数据和复杂查询场景时，采取了多种策略。首先，针对冷热数据分离的需求，快手不仅实现了数据的物理隔离，还特别为特殊业务的数据源建立了索引，并将这些数据存储在专门的 Historical 机器上。这种做法确保了即使在大查询或高内存GC压力下，特殊业务的查询性能也不会受到显著影响。 在应对大规模数据场景下的查询性能加速方面，快手实施了多项优化措施。其中，物化视图是一个重要的技术手段。快手设计了两个层面的物化视图：维度层面的物化视图和时序层面的物化视图。 维度层面的物化视图旨在通过预先聚合特定维度来减少查询过程中的数据访问量。例如，如果发现某个数据源中group1和group2中的三个维度经常同时出现，而其他四个维度的查询频率较低，快手会对这些维度建立预聚合索引。当新的查询请求到来时，系统会根据请求中的维度集合判断是否需要访问原始的聚合索引，从而避免不必要的数据读取，显著提升查询性能。 时序物化视图则解决了在大跨度时间范围内的查询问题。假设有一个数据源的聚合级别为分钟级，但用户需要查询最近三个月的数据，传统的处理方式需要扫描过去三个月的所有分钟级别索引文件并进行一次聚合计算。为了解决这个问题，快手在分钟级别的索引上新增了小时级别的物化索引。这样，当接收到查询请求时，如果查询的粒度要求是天级别或更高，系统会自动将查询请求路由到小时级别的物化索引上，从而进一步提升查询效率。 通过这些优化措施，快手不仅提升了特定情况下的查询性能，也为应对更复杂的查询需求提供了有力支持。 在讨论 Druid 元数据存储系统的性能优化时，我们关注了三个关键方面：Overlord 与 MySQL 之间的交互、Coordinator 与 MySQL 之间的交互以及 Segment 文件加载过程的优化。这些改进显著提高了系统的查询效率和资源利用率。 首先，针对 Overlord 与 MySQL 之间的交互问题，我们通过针对性地对 Segments 表增加索引，实现了性能瓶颈的显著缓解。优化后的查询时间从 10 秒多降至仅 1 秒，提升了超过 10 倍的效率。 其次，在 Coordinator 与 MySQL 之间的交互方面，我们通过改造成增量扫描的方式，将全量扫描的时间从原来的 1.7 分钟减少至大约 40 秒。进一步地，为增量扫描过程创建了专门的 MySQL 索引，使得扫描耗时进一步缩短至约 30 毫秒，整体性能提升显著。 最后，对于 Segment 文件加载过程的优化，我们实现了 Coordinator 扫描与匹配规则的并行化加速，并针对细节进行了改进。这一优化使得集群中几百万量的 Segment 文件协调一遍的耗时从原来的 3 分钟降低至现在的 30 秒。 为了进一步提高资源利用率，我们对 Druid 集群的资源管理进行了优化。具体来说，我们引入了一个自动调节 Supervisor task count 的功能，根据当前消费 Kafka 时延的情况来动态调整任务数量，从而避免在业务高峰期出现数据延迟，同时在数据低峰期释放资源，有效提升了整个集群的利用率。 在探讨Druid平台的架构时，我们不得不提到Middler Manager的索引任务资源分配问题。Druid为每个Middler Manager分配一个固定的Slot数，但与Kafka索引任务相比，Hadoop索引任务实际上只是Hadoop客户端，仅负责提交任务，并不占用太多资源，这可能导致资源的浪费。针对这一问题的优化思路是将Middler Manager的任务调度配置从按照Slot数改为根据内存大小分配，我们将区分对待不同类型的任务，对于Kafka任务和Hadoop任务将默认不同的内存大小，同时用户在提交任务时也可以指定自己的任务内存大小，我们会进行最大值限制，以防止恶意提交。 此外，及时对Segment文件进行Compaction有助于提高查询性能并节省存储空间。目前，Druid在进行Compaction时会提交一个特殊的Compaction task，串行扫描Segment文件进行合并，性能较差。对此，我们实施了一个并行化方案，即通过提交一个Hadoop任务，在Hadoop集群上并行扫描Segment信息并进行Compaction，性能提升显著。 在平台易用性方面，我们也进行了大量工作。平台运营过程中，每天需要接入许多数据源，在平台上线初期，管理员可以参与完成，但随着业务的快速发展，工作量大幅增加。数据源接入后，还需要修改数据源的维度和指标定义，这些都需要系统化的解决。 除此之外，用户对Druid平台或自己的数据理解不够深入，对业务的分析需求场景也不够明确，在接入数据源时往往会导入大量的维度和指标信息，这带来了隐患：维度越多，聚合效果越差，甚至有些高基维严重影响数据聚合的效果和查询性能。 针对这些问题，我们设计了两套工具，分别是Druid数据源管理系统和Druid探针系统。 数据源管理系统是一个Web管理工具，它允许用户在平台上完成数据源的接入、查看和管理。该平台提供的信息包括维度和指标信息、Kafka消费速率以及Lag等关键指标。图示显示了indexing task列表信息，系统具备权限管理功能，只有数据源负责人可以修改数据源的维度和指标配置。 indexing task详情页面展示了除了基础信息外，还包括Kafka消费速率等数据，帮助用户排查并解决负责的数据源问题。新建和编辑页面设计简洁，用户只需点击即可获取Kafka信息，系统自动填充时间戳列格式，并预先解析并提供建议。 数据源列表信息清晰显示了数据量、Segment文件平均大小、维度和指标信息。对于通过离线任务导入的数据源，系统能自动关联到相应的定时导入任务，方便快速定位。 Druid探针系统主要解决以下问题：
分析数据源查询热度，管理员可了解哪些数据源是查询的大客户，并对冷数据源或僵尸数据源进行下线处理，避免资源浪费。
对单个数据源内部的维度和指标进行查询热度分析，识别经常被查询的维度和不常被查询的冷维度或指标，特别是高基维维度，及时通知用户进行优化。 接下来讨论OLAP平台的数据可视化工作。我们采用开源的Superset方案作为强大的数据分析和可视化工具。Superset与Druid深度集成，提供交互式、高效且功能丰富的数据可视化图表。 截至目前，我们的 Superset 已经积累了上万个图表，用户在使用 Superset 过程中也遇到很多问题，针对这些问题我们对 Superset 同样做了大量的改造。包括数据的同步、权限管理、报警功能、产品设计的一些交互改进等。
重点改进点介绍
支持多 time shift
Superset 对多 time shift 的支持是一大亮点。所谓的 time shift 就是可以在一张图里面同时绘制出当前值与前一天同比和环比的指标对比。这里展示的是当前这一天与前一天，以及上周同天指标对比情况，用户可以加任意多的其他日期的指标对比到同一张图里面。除了这种时序线图之外，我们对其他图表也做了大量 time shift 支持。
联动刷新功能
在 Superset 同一个看板里面多个图表，当鼠标滑动窗口进行滑行的时候能够联动刷新的功能，对于需要进行多表关联分析的用户来说，这还是比较实用的。
自定义报警功能
Superset 的报警功能设计参考了 Grafana，允许用户在平台上自定义一些报警维度、指标、检查周期、报警级别等。
总结：快手对 Druid 的改进
在性能提升方面，我们进行了时序和维度两个层面的物化视图以及元数据方面的交互优化。在资源管理层面，实现了 Supervisor indexing task 的自动伸缩、Middler Manager 细粒度资源分配以及并行 Compaction。在稳定性层面，设计了 Broker 和 Historical 的隔离部署。在平台易用性层面，自研了数据源的管理系统、数据探针系统，并引入 Superset 数据可视化平台。
未来工作计划分享
最后，我想分享一下未来快手 OLAP 平台的一些工作计划。首先，我们会引入一些新型的 OLAP 技术，比如 Clickhouse。其次，我们在考虑 OLAP 与 Adhoc, 以及例行报表的整合，希望 OLAP 技术能够在离线数据分析方面也有更大的发挥空间。第三，从数据的流入到数据的可视化提供一站式的服务，降低技术人员和非技术人员的使用门槛。第四，希望平台能够从技术输出向产品化、服务化的方向去演进。