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