这是一个创建于 2184 天前的主题，其中的信息可能已经有所发展或是发生改变。
不如先解决我一个问题吧：
我有个定时统计每 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