社区小助手_个人页

EMR Spark relational cache可以简单理解为基于Spark的物化视图，支持把视图数据放在内存中或是HDFS OSS上，用户可以通过relational cache加速查询，或是基于此构建MOLAP平台。ignite应该主要是基于内存的实时计算引擎。

很不错的问题。我知道的就是 relational cache 是基于 Spark 来做的，Spark 上直接用，不需要另外一堆服务。Ignite 自己是一套跟 Spark 可以对等的服务。

2.0开始，shuffle的时候已经默认为 kryo 序列化了

你说某级别是隔离级别吗？隔离级别越高，并发性能越弱。对于 hive spark sql 这种并发很小的情况，支持多种隔离级别意义不是很大。

平台化，让我执行完sql以后，获取输出的表或分区，对碎片文件进行合并，合并完以后任务才算执行完。最开始我们是通过质量分数强制用户自己去合并，用户很麻烦，换了这样的就解决了用户合并文件的问题。

平台化可以这么做。缺点就是用户量上来之后有并发可能问题。但是也没有什么更好的办法，都是 trade off

碎片文件比较多的时候比较花费时间。用户可以设置参数，关闭合并，避免影响下游任务运行。等表不被使用了某个时间点用户自己去合并。

可以用livy来提交spark-cluster的application，然后客户提交给livy，这块我们也做了一些工作

可以异步合并，小文件想解决还是合并，落地前合并，处理后合并。在write后repartition一下就可以设置文件数量，在你预估一个分区或处理文件的大小时可以把数量做成参数，比上blockSize生成一个合理的数字。也可以在落地后合并，这样不影响落地的效率不过两种方法都行，落地后就比如shuffle默认200个，那么就有200个小文件，那么可以在不使用这份数据的时候进行离线的合并，合并的方法有很多，基本上就是读出来再写进去，有几个点要注意：把合并后的文件放进原目录中前要删除之前读出来的那些文件避免数据重复，但不能全部删除，合并生成大文件过程中是否有其他程序写入新文件，文件中是否有tmp、success，文件存储格式要统一。

你是问关于 delta 的小文件，还是 spark sql 自己的一些小文件？还是什么？sparksql目前应该没有这个功能，我们这边可以看一下需求

如果是 hive 的事务表，hive 有合并小文件的功能。spark 方面开源是没有的。spark sql 开启事务之后，delete update 都会产生小文件。处理思路是一样的，定期合并。备注：开源 spark 没有事务支持。emr spark 的事务支持目前还比较薄弱。如果大家有需求，欢迎提出。

sparksql生成的数据小文件真的多，咱们可以通过元数据库，获取每个表下面每个分区下面的数据大小和文件个数，看看是要合并小文件还是要拆分大文件，然后sparksql读出来，然后再写进去，设置一下partition number

你们是用 spark streaming 处理数据最后实时写为 parquet 文件，然后推荐系统会用这些实时处理的数据，是这样的吧？（是的，需求是这样）那推荐系统怎么用这些数据，具体是用什么工具知道吗？（实时读取hdfs文件，spark ML）
了解了。看到你们这个主要还是 spark 的技术栈，应用场景是 data pipeline。databricks 前一段时间开源的 delta 正是解决这一类场景。

你的函数是 (string,string){string+string}, 它就执行string+string

jar 不匹配

hadoop core 吧，自己去搜搜， 配置文件这个类的再哪个jar里

10亿数据查询，就是你基本的查询方式是啥，10亿也没多少，你放es里，也能做到秒级；有指定key查询，放hbase能做到毫秒

放es里最省事~

配的是host 还是 ip呢？换成ip就好了，host有异常的时候，没有清理文件

onBatchComplete里面不可以调用ssc.stop，不然岂不是一个batch做完的时候，整个作业就被关掉了。ssc.stop在所有的listener里面都不应该调用