关闭。这个问题需要更加突出重点。它目前不接受答案。
**想改进这个问题吗?**通过编辑这篇文章更新这个问题,使它只关注一个问题。
三年前关门了。
改进这个问题
我们正在尝试构建一个bi系统,它将收集大量的数据,这些数据应该由其他组件处理。
我们决定用一个中间层来收集、存储和分发数据是个好主意。
数据由一大组日志消息表示。每个日志消息都有:
产品
动作类型
约会
负荷消息
系统细节:
平均:150万条信息/分钟
峰值:1500万条/分钟
平均消息大小为:700字节(约1.3tb/天)
我们有200种产品
我们有1100种动作类型
数据应每5分钟接收一次
消费者应用程序通常需要1-2-3个产品和1-2-3个动作类型(我们需要快速访问1个产品/1个动作类型)
我们原以为Kafka会做这项工作,但我们遇到了几个问题。
我们尝试为每个操作类型创建一个主题,并为每个产品创建一个分区。通过这样做,我们可以提取1个产品/1个动作类型来进行消费。
最初我们有一个“打开的文件太多”的问题,但是在我们更改了服务器配置以支持更多的文件之后,我们出现了内存不足错误(分配了12gb/节点)
此外,我们也有Kafka稳定的问题。在大量的主题中,Kafka往往僵持不下。
我们的问题:
Kafka适合我们的用例场景吗?它能支持这么多的主题/分区吗?
我们是否可以用另一种方式组织kafka中的数据以避免此问题,但仍然能够对1产品/1动作类型具有良好的访问速度?
你有没有推荐其他Kafka的替代品更适合这个?
1条答案
按热度按时间92dk7w1h1#
我发布这个答案,以便其他用户可以看到我们采用的解决方案。
由于kafka的局限性(大量的分区导致操作系统几乎达到最大打开文件数)和性能有些薄弱,我们决定使用apache commons、guava、trove等库来实现我们需要的性能,为我们的需求构建一个定制框架。
整个系统(分布式和可扩展)有3个主要部分:
etl(读取数据、处理数据并将其写入二进制文件)
框架核心(用于读取二进制文件和计算统计数据)
api(被许多系统用来获取要显示的数据)
作为旁注:我们尝试了其他解决方案,如hbase、storm等,但没有一个能满足我们的需要。