原来大家对于后端的认知就是 crud 连接数据库和写业务

[VoidChen]

不如先解决我一个问题吧：

我有个定时统计每 10 分钟出一个 orc 文件，因为数据量不够大，所以会有很多小文件放在 hdfs 上，要知道这样是很浪费资源的，所以现在要做一个合并，方案有 2 个：
       1、每 10 分钟抽取数据的时候，把上一次的文件读出来拼进去
       2、每日 0 点把所有 orc 读出来再合并
那么两种我都试过了，遇到一个问题，就是 spark 写进去的时候由于多个分区导致最后合并也没有移动数据，而是在各块硬盘上，如果要 repartation 就要移动数据，产生大量的网络 IO，要如何去解决这个问题？

[zhaishunqi]

照这么说,基本上 C 系语言就是 26 个字母加上 10 个数字还有下划线,运算符,标点空格回车嘛.

[mwiker]

既然要合并统计结果文件，为什么不直接按天对源数据统计？

[wysnylc]

数据先存数据库,每天统一生成一个 orc 文件如何

[SeaRecluse]

增量更新

[VoidChen]

@wysnylc 数据量一天在 2 亿左右，关系型数据库基本放不下。。或者说性能不好。。。

[VoidChen]

@mwiker 这批数据会有程序处理的，我保存起来是作为历史数据保存，并加以压缩

[mwiker]

@VoidChen 如果数据按时间均匀分布可以考虑缩短下统计间隔，保证计算速度和文件大小，非均匀的情况可以按读取到的数据量来区分间隔

[mwiker]

@VoidChen 统计结果如果量不大，可以把统计结果导出到数据库进行保存，这样可以避免小文件合并的问题

[cyspy]

Kafka 出小时级呢？两亿的量存 24 个文件完全可以接受

[VoidChen]

@cyspy 刚去算了一下，10 分钟也就 144 个文件，好像也能接受。。。因为真实数据得去现场才能试，现在拿测试数据所以搞出来的文件才比较小。。。

[libook]

你这都入数仓了，跟后端没啥关系。。。后端是相对于前端的，而前段是服务用户的，所以后端就是纯服务业务的，也就是 CRUD、if 和 for，没毛病，这也是为什么 Severless 技术会有市场。
没用过大数据框架，就不班门弄斧了，计算机界有个通用思路，串行转并行如果串行速率不够可以用缓存，存够一次并行信号的数量再发，那么可以试试 MongoDB 做缓存，流式清洗入仓，平均消费速率高于平均生产速率就可以，全 SSD 阵列容量不用多大，够削峰和容灾就可以，这样不需要那么多定时任务了，你可以看看这个方向适合不适合解决你的问题。
之所以推荐试试 MongoDB 主要是因为存数据灵活，也支持存文件（ GridFS ），你要是不用做业务纯用作缓存的话完全可以去掉日志、索引之类的功能提高写入效率，另外 MongoDB 官方宣传对大数据量场景做了优化，上亿条数据也是比较轻松的，你可以试试。

[wellking01]

用 hbase 存吧, hive 用 HBaseStorageHandler 也能读, 有两个好处:
1. 如果数据的合并周期改了, 不是 10 分钟了, 也能胜任
2. 如果数据需要去重合并了, hbase 天然支持

[chinvo]

点进来看到人并没有帮你解答问题的义务。多充电问题自然迎刃而解。

[iamstrong]

hbase ？

[VoidChen]

@libook MongoDB 我也用过哈哈哈，这算数据仓库的内容了？我一直对自己的定义都只是一个后台。。。

[VoidChen]

@wellking01 HBase 呢直接存进去不好查，这里的是源数据，还有一个天作业会每天 0 点读出来做处理，然后再入 hbase 的