聊聊OLAP架构

[rterror]

聊一聊几大互联网公司的大数据架构，主要侧重在计算引擎：字节、小红书、米哈游、腾讯、阿里、Uber（后面可能有增删）。 后文不区分 Doris和StarRocks、不区分PrestoDB和Trino。

[rterror]

小红书

主要参考链接

• 2021: https://xie.infoq.cn/article/8c207beaa3d4ffa4df84a0898

OLAP 在小红书的演进史

• 第一阶段 在 2017 年之前，数据少+业务简单->云服务， 数据 ETL、数仓模型到最后报表端展现，在 Redshift 中一站式完成。但随着业务复杂度不断提升，以及数据量的快速增长，这种模式很快遇到了瓶颈。主要有以下问题：
  • Redshift 无法在不影响线上查询性能的前提下弹性扩展，一旦涉及到扩容，就会涉及到数据重分布，从而影响集群的性能以及可用性。
  • ETL 任务严重影响集群可用性。在 Redshift 中同时进行 ETL 任务的时候，会大量抢占资源，从而影响数据分析的效率，导致查询超时甚至因为集群负载过大后整个集群崩溃不可用。
  • 没有良好的存算分离，数据存储容量存在瓶颈，无法满足随业务而快速增长的数据量存储需求。
• 第二阶段 弹性扩容+集群可用性+存算分离->Hadoop/Hive+Presto。Presto 天然和 Hive 共享元数据信息，且共同使用物理数据存储，即插即用。大量的对数仓表的灵活查询使用 Presto 完成。
• 第三阶段，实时性->ClickHouse，用来建设性能更强悍，响应时间更短的数据分析平台以满足实时性要求。
• 第四阶段，实时数仓、提供统一的数据接口（类似jdbc接口）、低延迟高并发的查询 -> 引入了 StarRocks。

OLAP 架构

结合前文分析和下图，小红书主要采用

• OLAP查询层：
  • Clickhouse，日志分析、宽表分析，单边性能卓越，可扩展性比较差
  • StarRocks，线上数据应用（HSAP），分布式计算支持得更好，但是sql语法支持不太完善
  • TiDB，ap和tp限制都比较多
• 批式ETL：Spark/Hive
• 流处理：Flink/Kafka

后续：小红书目前基于StarRocks+iceberg做流批一体存储（https://zhuanlan.zhihu.com/p/622514116 20230418），并且大数据架构并没有变化。