这是一个创建于 2514 天前的主题，其中的信息可能已经有所发展或是发生改变。
不如先解决我一个问题吧：
我有个定时统计每 10 分钟出一个 orc 文件，因为数据量不够大，所以会有很多小文件放在 hdfs 上，要知道这样是很浪费资源的，所以现在要做一个合并，方案有 2 个：
1、每 10 分钟抽取数据的时候，把上一次的文件读出来拼进去
2、每日 0 点把所有 orc 读出来再合并
那么两种我都试过了，遇到一个问题，就是 spark 写进去的时候由于多个分区导致最后合并也没有移动数据，而是在各块硬盘上，如果要 repartation 就要移动数据，产生大量的网络 IO，要如何去解决这个问题？
 | 1 VoidChen OP |
 | 2 qingfengxm 2018-11-28 09:28:58 +08:00  1 hadoop archive 了解一下 |
| 3 VoidChen OP @qingfengxm 试试能不能用上，还要用 hive 来建外部表，看看能不能读出来  |
| 4 VoidChen OP @qingfengxm 本质上只是做了一个目录存放文件索引，文件并没有合并起来啊 |
| 5 VoidChen OP 168 点击只有一个回复，其实后端的水也是很深的啊，想想如果没有了框架，自己还会什么就知道了 |
 | 6 zander1024 2018-11-28 09:46:48 +08:00 因为我这种水平的就是 crud+业务。。。 没遇到什么难题 也觉得什么难题有前人经验 去搜资料就行 实在不行 跟运营说这个问题没法解决 换个需求吧 哈哈哈 |
 | 7 yhxx 2018-11-28 09:48:50 +08:00 难道不是吗 对前端的认知也就是 HTML+CSS 切页面啊 |
| 8 VoidChen OP @zander1024 没压力就自己学着玩呗，以后总的转架构吧，总要学一下分布式吧 |
| 9 VoidChen OP @yhxx 我前后端都做过啦，虽然是在大学的时候，另外舍友是个专业的前端，还有一个舍友是 PHP，毕业合租到现在，所以都各种都了解一点 |
 | 10 lfzyx 2018-11-28 09:51:45 +08:00 对测试的认知就是点点点啊，对运维的认知就是修电脑啊，对设计的认知就是切图啊 |
| 11 qingfengxm 2018-11-28 09:52:03 +08:00 1 要不然将 orc 文件数据搞到 kafaka 中，spark 从 kafka 中读数据 |
| 12 VoidChen OP @qingfengxm 就是从 kafka 里面读出来的。。存 orc 是为了方便重新读出来和做 hive 外部表 |
 | 14 lmw2616 2018-11-28 09:54:44 +08:00 学更多不也是为了更好的 crud 为业务服务吗 |
 | 15 sagaxu 2018-11-28 09:56:41 +08:00 via Android 1 以前没有所谓大数据设施的时候，通过 FTP 上传汇总，定期聚合处理，凑合着也能用，国内工业领域很多项目这么玩的 |
| 16 VoidChen OP 没有在划水，到处找资料，理想状态是能把各块数据尽可能地靠拢，保证每台机有一两块或者多块集合的大文件，这样就可以兼顾存储和方便后续并行计算，现在看看 spark 的 repartation 能不能智能地把新数据往已有的数据块靠拢 |
| 17 VoidChen OP @sagaxu 是啊，思路是一致的，多出来的就是考虑到分布式上去了，想象成多个 FTP 各自汇总各自的，然后弄成 N 个汇总文件在 N 台机子上 |
 | 19 wleexi 2018-11-28 10:01:40 +08:00 题目和正文有什么关系 |
 | 21 zhaishunqi 2018-11-28 10:14:24 +08:00 照这么说,基本上 C 系语言就是 26 个字母加上 10 个数字还有下划线,运算符,标点空格回车嘛. |
 | 22 mwiker 2018-11-28 10:20:32 +08:00 1 既然要合并统计结果文件，为什么不直接按天对源数据统计？ |
 | 23 wysnylc 2018-11-28 10:28:08 +08:00 1 数据先存数据库,每天统一生成一个 orc 文件如何 |
 | 24 SeaRecluse 2018-11-28 10:31:55 +08:00 增量更新 |
| 27 mwiker 2018-11-28 10:55:24 +08:00 1 @VoidChen 如果数据按时间均匀分布可以考虑缩短下统计间隔，保证计算速度和文件大小，非均匀的情况可以按读取到的数据量来区分间隔 |
 | 29 cyspy 2018-11-28 11:00:46 +08:00 1 Kafka 出小时级呢？两亿的量存 24 个文件完全可以接受 |
| 30 VoidChen OP @cyspy 刚去算了一下，10 分钟也就 144 个文件，好像也能接受。。。因为真实数据得去现场才能试，现在拿测试数据所以搞出来的文件才比较小。。。 |
 | 31 libook 2018-11-28 12:11:01 +08:00 你这都入数仓了，跟后端没啥关系。。。后端是相对于前端的，而前段是服务用户的，所以后端就是纯服务业务的，也就是 CRUD、if 和 for，没毛病，这也是为什么 Severless 技术会有市场。 没用过大数据框架，就不班门弄斧了，计算机界有个通用思路，串行转并行如果串行速率不够可以用缓存，存够一次并行信号的数量再发，那么可以试试 MongoDB 做缓存，流式清洗入仓，平均消费速率高于平均生产速率就可以，全 SSD 阵列容量不用多大，够削峰和容灾就可以，这样不需要那么多定时任务了，你可以看看这个方向适合不适合解决你的问题。 之所以推荐试试 MongoDB 主要是因为存数据灵活，也支持存文件（ GridFS ），你要是不用做业务纯用作缓存的话完全可以去掉日志、索引之类的功能提高写入效率，另外 MongoDB 官方宣传对大数据量场景做了优化，上亿条数据也是比较轻松的，你可以试试。 |
 | 32 wellking01 2018-11-28 12:45:51 +08:00 1 用 hbase 存吧, hive 用 HBaseStorageHandler 也能读, 有两个好处: 1. 如果数据的合并周期改了, 不是 10 分钟了, 也能胜任 2. 如果数据需要去重合并了, hbase 天然支持 |
 | 33 chinvo 2018-11-28 12:50:59 +08:00 via iPhone 点进来看到人并没有帮你解答问题的义务。多充电问题自然迎刃而解。 |
 | 34 iamstrong 2018-11-28 13:04:55 +08:00 via Android hbase ？ |
| 36 VoidChen OP @wellking01 HBase 呢直接存进去不好查，这里的是源数据，还有一个天作业会每天 0 点读出来做处理，然后再入 hbase 的 |
Select Language