在这种情况下，更倾向于选择第二种方案：300亿数据，5个字段，有删改需求。原因如下：

1. 数据规模控制： 第一种方案虽然有更多的字段，但是字段数目较多并且后期可能要添加字段，这可能导致数据结构更为复杂，维护和管理成本会增加。相比之下，第二种方案的字段数目较少，更容易维护和管理。

2. 性能考量： 虽然两种方案的字段*行数结果相同，但是在实际操作中，第二种方案的数据量更大，可能需要更大的存储空间和计算资源。但是，ClickHouse作为一个面向OLAP场景的数据库，在处理亿级数据量时表现较好，相对来说更适合处理第二种方案中规模更大的数据量。

3. 需求变更： 考虑到后期可能会有字段的添加、删改需求，第一种方案需要频繁修改表结构，而第二种方案只需在原来的基础上进行数据的更新，对于数据库的维护和更新会更为方便。

总的来说，综合考虑数据规模、维护成本、性能等因素，第二种方案更适合在ClickHouse集群中实现。