大数据业务开发 问题现象 客户使用ClickHouse,系统表产生的日志过大,一次性删除会耗费较长时间,客户可以添加定期删除策略,即添加TTL。 处理步骤 在ClickHouse客户端给TTL的系统表执行如下语句: alter table system.表名 modify TTL eventdate + INTERVAL 保留天数 day; 注意 该语句只是配置运行SQL节点的系统表的TTL,若所有节点都需要配置,则需要到每个节点上都执行该语句,但不建议使用on cluster语句,避免ClickHouse一直运行下去。 上述语句建议在低峰期运行,由于数据量较大,这个操作可能会比较慢。 SparkSQL访问Hive分区表启动Job前耗时较长如何处理? 问题背景 使用SparkSql访问Hive的一个数据存放于OBS的一个分区表,但是运行速度却很慢,并且会大量调用OBS的查询接口。 SQL样例: select a,b,c from test where bxxx 原因分析 按照设定,任务应该只扫描bxxx的分区,但是查看任务日志可以发现,实际上任务却扫描了所有的分区再来计算bxxx的数据,因此任务计算的很慢。并且因为需要扫描所有文件,会有大量的OBS请求发送。 MRS默认开启基于分区统计信息的执行计划优化,相当于自动执行Analyze Table(默认开启的设置方法为spark.sql.statistics.fallBackToHdfstrue,可通过配置为false关闭)。开启后,SQL执行过程中会扫描表的分区统计信息,并作为执行计划中的代价估算,例如对于代价评估中识别的小表,会广播小表放在内存中广播到各个节点上,进行join操作,大大节省shuffle时间。 此开关对于Join场景有较大的性能优化,但是会带来OBS调用量的增加。