导语 | OLAP（On-Line Analytical Processing），是数据仓库系统的主要应用形式，帮助分析人员多角度分析数据，挖掘数据价值。本文基于QQ音乐海量大数据实时分析场景，通过QQ音乐与腾讯云EMR产品深度合作的案例解读，还原一个不一样的大数据云端解决方案。
一、背景介绍
QQ音乐是腾讯音乐旗下一款领先的音乐流媒体产品，平台打造了“听、看、玩”的立体泛音乐娱乐生态圈，为累计注册数在8亿以上的用户提供多元化音乐生活体验，畅享平台上超过3000万首歌曲的海量曲库。优质服务的背后，是每天万亿级新增音乐内容和行为数据，PB数据量级的数据计算服务。
海量的数据意味着更高标准的数据分析业务，对于离线分析的时效、实时与近实时的即席实时交互分析，提出了更高的要求。如何通过用户行为以及音乐内容标签数据，深入洞察用户需求，来优化泛音乐内容创作分享生态，为亿万用户带来更优质的音乐体验？是对QQ音乐大数据团队的巨大挑战以及机遇。
腾讯云弹性 MapReduce（EMR），结合云技术和社区开源技术，提供安全、低成本、高可靠、可弹性伸缩的云端泛Hadoop服务。EMR助力构建企业的大数据平台架构，适用于HBase在线业务，数据仓库，实时流式计算等大数据场景。
QQ音乐大数据团队基于业务需求，搭建和优化基于ClickHouse的OLAP实时大数据分析平台，并与腾讯云EMR团队深入场景合作，共建大数据云端解决方案。下文将通过案例解读，深入解析QQ音乐大数据团队OLAP系统架构演进之路，不断发掘音乐数据背后的价值。
二、大数据分析的挑战
早些年在传统离线数仓阶段，QQ音乐使用Hive作为大数据分析的主要工具，对TB至PB级的数据进行分析，但存在着以下的可提升点：
1. 时效性低
对于音乐服务来说，实时下钻和分析PV、UV，用户圈层、歌曲的种类、DAU等数据，分析结果的价值取决于时效性。核心日报与统计报表场景下，基于Hive的离线分析仅能满足T+1的时效，对于实时日报和分析的需求越来越强烈。
2. 易用性低
基于Hive离线数据分析平台，对于产品、运营、市场人员具有较高的技术门槛，无法满足自助的实时交互式分析需求；开发在上报和提取分析数据时，无法实时获取和验证结果，查询和分析日志经常需要几个小时。
3. 流程效率低
数据分析需求，需由数据分析团队完成，经过排期、沟通、建模、分析、可视化等流程步骤，所需时间以周计算，落地可能达数周，分析结果不及时，影响和拖慢了决策进度。
为了应对以上问题，提升流程效率，提高数据分析处理的时效性和易用性，数据的即席分析和数据可视化能力支撑需要优化和提升，让问题秒级有响应，分析更深入，数据分析更高效。
三、QQ音乐大数据架构技术演进
QQ音乐大数据团队基于ClickHouse+Superset等基础组件，结合腾讯云EMR产品的云端能力，搭建起高可用、低延迟的实时OLAP分析计算可视化平台。
集群日均新增万亿数据，规模达到上万核CPU，PB级数据量。整体实现秒级的实时数据分析、提取、下钻、监控数据基础服务，大大提高了大数据分析与处理的工作效率。
通过OLAP分析平台，极大降低了探索数据的门槛，做到全民BI，全民数据服务，实现了实时PV、UV、营收、用户圈层、热门歌曲等各类指标高效分析，全链路数据秒级分析定位，加强数据上报规范，形成一个良好的正循环。
1. ClickHouse介绍
ClickHouse由俄罗斯第一大搜索引擎Yandex发布，是一个基于列的，面向OLAP的开源轻量级数据库管理系统，能够使用SQL查询实时生成分析数据报告，适合PB数据量级的实时大数据分析。
在场景适用和性能方面，ClickHouse在OLAP的众多组件中有较为突出的优势。
（1）场景适用方面
ClickHouse主要为OLAP应用场景的数据仓库，以库表的方式存储数据，可简单、高效地分析数据，结合Superset以可视化的方式输出分析数据图表。
（2）性能方面
ClickHouse有着卓越的实时分析能力。以性能表现突出的单表为例，使用单表100G，3亿行数据，集群规模8核20G*3，简单的查询在毫秒级完成，复杂查询秒级，查询速度较Presto、SparkSQL提升3-6倍，较Hive提升30-100倍。
对比Presto、Impala、Hawq、Greenplum，ClickHouse以其分布式计算、多核计算、向量化执行与SIMD、代码生成技术以及列式存储等特性，实现了超高速的查询，凸显了更优越的性能。
2. ClickHouse架构系统技术攻克点
面对上万核集群规模、PB级的数据量，经过QQ音乐大数据团队和腾讯云EMR双方技术团队无数次技术架构升级优化，性能优化，逐步形成高可用、高性能、高安全的OLAP计算分析平台。
（1）基于SSD盘的ZooKeeper
ClickHouse依赖于ZooKeeper实现分布式系统的协调工作，在ClickHouse并发写入量较大时，ZooKeeper对元数据存储处理不及时，会导致ClickHouse副本间同步出现延迟，降低集群整体性能。
解决方案：采用SSD盘的ZooKeeper大幅提高IO的性能，在表个数小于100，数据量级在TB级别时，也可采用HDD盘，其他情况都建议采用SSD盘。
（2）数据写入一致性
数据在写入ClickHouse失败重试后内容出现重复，导致了不同系统，如Hive离线数仓中分析结果，与ClickHouse集群中运算结果不一致。
解决方案：基于统一全局的负载均衡调度策略，完成数据失败后仍然可写入同一Shard，实现数据幂等写入，从而保证在ClickHouse中数据一致性。
（3）实时离线数据写入
ClickHouse数据主要来自实时流水上报数据和离线数据中间分析结果数据，如何在架构中完成上万亿基本数据的高效安全写入，是一个巨大的挑战。
解决方案：基于Tube消息队列，完成统一数据的分发消费，基于上述的一致性策略实现数据幂同步，做到实时和离线数据的高效写入。
（4）表分区数优化
部分离线数据仓库采用按小时落地分区，如果采用原始的小时分区更新同步，会造成ClickHouse中Select查询打开大量文件及文件描述符，进而导致性能低下。
解决方案：ClickHouse官方也建议，表分区的数量建议不超过10000，上述的数据同步架构完成小时分区转换为天分区，同时程序中完成数据幂等消费。
（5）读/写分离架构
频繁的写动作，会消耗大量CPU/内存/网卡资源，后台合并线程得不到有效资源，降低Merge Parts速度，MergeTree构建不及时，进而影响读取效率，导致集群性能降低。
解决方案：ClickHouse临时节点预先完成数据分区文件构建，动态加载到线上服务集群，缓解ClickHouse在大量并发写场景下的性能问题，实现高效的读/写分离架构，具体步骤和架构如下：
a）利用K8S的弹性构建部署能力，构建临时ClickHouse节点，数据写入该节点完成数据的Merge、排序等构建工作；
b）构建完成数据按MergeTree结构关联至正式业务集群。
当然对一些小数据量的同步写入，可采用10000条以上批量的写入。 
（6）跨表查询本地化
在ClickHouse集群中跨表进行Select查询时，采用Global IN/Global Join语句性能较为低下。分析原因，是在此类操作会生成临时表，并跨设备同步该表，导致查询速度慢。
解决方案：采用一致性hash，将相同主键数据写入同一个数据分片，在本地local表完成跨表联合查询，数据均来自于本地存储，从而提高查询速度。
这种优化方案也有一定的潜在问题，目前ClickHouse尚不提供数据的Reshard能力，当Shard所存储主键数据量持续增加，达到磁盘容量上限需要分拆时，目前只能根据原始数据再次重建CK集群，有较高的成本。
3. 基于Superset的自助数据分析可视化平台
Apache Superset(孵化)是一个现代的、企业级的商业智能Web应用程序，为业务提供处理PB级数据的高性能的OLAP在线数据分析服务，提供丰富的数据可视化集，支持包括ClickHouse、Spark、Hive等多个组件的接口。
QQ音乐大数据团队结合自身业务特点丰富完善功能，结合腾讯云EMR云端弹性能力，深入参与Superset开源共建：
https://github.com/apache/incubator-superset
ClickHouse在实时分析领域拥有诸多优势，在OLAP分析场景下，搭配在数据可视化领域表现抢眼的Superset组件，在对QQ音乐业务指标概览以及二维变量分析中，提供丰富的数据可视化集以供数据分析处理。
当前Superset上万个图表中，超60%由产品、研发、运营、研究员、财务等非数据人员创建，做到全民数据分析，数据平民化。
猜你喜欢
1、即将发布的 Flink 1.11 新特性：流批一体的 Hive 数仓
3、基于 Apache Druid 的实时分析平台在爱奇艺的实践
4、Spark 3.0 自适应查询优化介绍，在运行时加速 Spark SQL 的执行性能
过往记忆大数据微信群，请添加微信：fangzhen0219,备注【进群】