我领导着一个与电动汽车制造商合作的大数据团队,我已经尝试了市场上可用的OLAP工具。阅读下面的内容,了解我认为您需要了解的关于这些工具的内容,包括许多OLAP工具的优缺点以及我在OLAP方面的经验。
讨论的OLAP工具:
- Apache Druid (and Apache Kylin)
- TiDB
- ClickHouse
- Apache Doris
Apache Druid(和Apache Kylin)
早在2017年,在市场上寻找OLAP工具就像在非洲大草原上寻找一棵树一样——只有少数。当我们抬头扫视地平线时,我们的目光停留在阿帕奇·德鲁伊和阿帕奇·凯林身上。我们之所以选择Druid,是因为我们已经对它很熟悉了,而Kylin尽管在预计算中具有令人印象深刻的高查询效率,但也有一些缺点。
Kylin的缺点:
- Kylin最好的存储引擎是HBase,但引入HBase会带来新的操作和维护负担。
- Kylin预先计算了维度和度量,但它带来的维度爆炸给存储带来了巨大压力。
至于Apache Druid,它使用了列式存储,支持实时和离线数据接收,并提供了快速查询。
另一方面,Druid:
- 不使用JDBC等标准协议,因此对初学者不友好。
- 对Joins的支持率很低。
- 精确重复数据消除可能较慢,从而降低性能。
- 由于许多组件需要各种安装方法和依赖关系,因此需要大量的维护工作。
- 在数据接收方面,Hadoop集成和JAR包的依赖性需要更改。
TiDB公司
2019年,我们尝试了TiDB。长话短说,以下是它的优点和缺点:
优点:
- 它是一个OLTP+OLAP数据库,支持简单的更新。
- 它具有我们需要的功能,包括聚合和细分查询、度量计算和仪表板。
- 它支持标准SQL,因此很容易掌握。
- 它不需要太多的维护。
缺点:
- TiFlash依赖OLTP这一事实可能会给存储带来更大的压力。作为一个非独立的OLAP,其分析处理能力并不理想。
- 它的性能因场景而异。
ClickHouse与Apache Doris之争
我们对ClickHouse和Apache Doris进行了研究。ClickHouse出色的独立性能给我们留下了深刻印象,但当我们发现:
- 当涉及到多表联接时,它并没有给我们想要的东西,这对我们来说是一个重要的用法。
- 它的并发性相对较低。
- 这可能会带来高昂的运营和维护成本。
另一方面,Apache Doris在我们的需求列表中勾选了很多框:
- 它支持高并发查询,这是我们最关心的问题。
- 它能够同时进行实时和离线数据处理。
- 它同时支持聚合查询和细分查询。
- 它的Unique模型(Doris中的一种数据模型,确保了唯一的密钥)支持更新。
- 它可以通过Materialized View大大加快查询速度。
- 它与MySQL协议兼容,因此在开发和采用方面几乎没有问题。
- 它的查询性能令人满意。
- 它只需要简单的运维。
总之,Apache Doris似乎是Apache Druid+TiDB的理想替代品。
我们的OLAP实践经验
以下是一张图表,向您展示数据是如何在我们的OLAP系统中流动的:
数据源
我们将来自业务系统、事件跟踪、设备和车辆的数据汇集到我们的大数据平台中。
数据导入
我们为我们的业务数据启用CDC。这些数据中的任何更改都将转换为数据流并存储在Kafka中,为流计算做好准备。对于只能批量导入的数据,它将直接进入我们的分布式存储。
数据处理
我们采用了Lambda架构,而不是集成、流式处理和批处理。我们的业务现状决定了我们的实时和离线数据来自不同的环节。特别地:
- 有些数据是以流的形式出现的。
- 有些数据可以存储在流中,而有些历史数据则不会存储在卡夫卡中;
- 某些场景需要高数据精度。为了实现这一点,我们有一个离线管道,可以重新计算和刷新所有相关数据。
数据仓库
我们没有使用Flink/Spark Doris连接器,而是使用Routine Load方法将数据从Flink传输到Doris,并使用Broker Load将数据从Spark传输到Dors。Flink和Spark批量生成的数据将备份到Hive,以便在其他场景中使用。这是我们提高数据效率的方法。
数据服务
在数据服务方面,我们通过数据源注册和灵活配置实现了API的自动生成,因此我们可以通过API管理流量和权限。与K8s无服务器解决方案相结合,整个过程非常有效。
数据应用程序
在数据应用层,我们有两种类型的场景:
- 面向用户的场景,如仪表板和指标。
- 面向车辆的场景,将车辆数据收集到Apache Doris中进行进一步处理。即使在聚合之后,我们仍然有以亿为单位的数据大小,但总体计算性能达到了标准。
我们的CDP实践
与大多数公司一样,我们建立了自己的客户数据平台(CDP):
通常,CDP由几个模块组成:
- 标签:积木,显然;(我们有基本标签和客户行为标签。我们也可以根据需要定义其他标签。)
- 分组:根据标签将客户分组。
- 见解:每个客户群体的特点。
- 联系:联系客户的方式,包括短信、电话、应用程序通知和即时消息。
- 效果分析:关于CDP如何运行的反馈。
我们希望在CDP中实现实时+离线集成、快速分组、快速聚合、多表联接和联合查询。以下是它们的操作方法:
实时+离线
我们有实时标签和离线标签,我们需要将它们放在一起。此外,同一数据上的列可能会以不同的频率更新。一些基本标签(关于客户身份)应该实时更新,而其他标签(年龄、性别)可以每天更新。我们希望将客户的所有原子标签放在一个表中,因为这样可以带来最少的维护成本,并且在添加自定义标签时可以大大减少所需的表的数量。
那么我们如何实现这一点呢?
我们使用Apache Doris的Routine Load方法更新实时数据,使用Broker Load方法批量导入离线数据。我们还使用这两种方法分别更新同一表中的不同列。
快速分组
基本上,分组就是将某一组标签组合起来,找到重叠的数据。这可能很复杂。Doris通过SIMD优化帮助加快了这一过程。
快速聚合
我们需要更新所有标签,重新计算客户群体的分布,并每天分析影响。这样的处理需要快速而整洁。因此,我们根据时间将数据划分为平板电脑,这样就可以减少数据传输,加快计算速度。在计算客户组的分布时,我们在每个节点预聚合数据,然后收集它们进行进一步聚合。此外,Doris的矢量化执行引擎是一个真正的性能加速器。
多表联接
由于我们的基础数据存储在多个数据表中,当CDP用户自定义他们需要的标签时,他们需要进行多表联接。吸引我们使用ApacheDoris的一个重要因素是它有前途的多表联接功能。
联合查询
目前,我们将Apache Doris与TiDB结合使用。关于客户接触的记录将被放入TiDB中,关于信用点和代金券的数据也将在TiDB中处理,因为它是一个更好的OLTP工具。对于更复杂的分析,例如监控客户运营的有效性,我们需要整合有关任务执行和目标群体的信息。这就是我们在Doris和TiDB之间进行联合查询的时候。
结论
这是我们从Apache Druid、TiDB和Apache Doris的旅程(中间是对ClickHouse的简短介绍)。我们研究了它们的性能、SQL语义、系统兼容性和维护成本,最终得出了我们现在的OLAP体系结构。如果你和我们有同样的担忧,这可能是你的参考。
最新内容
- 29 minutes 27 seconds ago
- 33 minutes 49 seconds ago
- 3 days ago
- 3 days 14 hours ago
- 5 days ago
- 5 days 19 hours ago
- 5 days 19 hours ago
- 5 days 19 hours ago
- 5 days 19 hours ago
- 5 days 19 hours ago