使用案例
CarbonData在各种分析工作中都很有用。这里记录了CarbonData被使用的一些最典型的使用情况。
CarbonData用于但不限于以下方面
银行
o 欺诈检测分析
o 风险状况分析
o 作为一个拉链表来更新客户的每日余额
电信
o 检测VIP客户的信号异常以提供更好的客户体验
o 分析GSM数据的MR,CHR记录,以确定特定时间段的塔台负荷,重新平衡塔台配置
o 分析访问站点、视频、屏幕尺寸、流媒体带宽、质量,以确定网络质量、路由配置。
网络/互联网
o 分析正在访问的页面或视频、服务器负载、流媒体质量、屏幕尺寸
智慧城市
o 车辆追踪分析
o 异常行为分析
这些用例可以大致分为以下几类。
- 全面扫描/详细/交互式查询
- 聚合/OLAP BI查询
- 实时输入(流)和查询
电信场景下的详细查询
场景
用户希望分析所有移动用户的CHR(呼叫历史记录)和MR(测量记录),以识别10秒内的服务故障。同时,用户希望在数据上运行机器学习模型,以公平地估计可能发生故障的原因和时间,并提前采取行动以满足VIP客户的SLA(服务水平协议)。
挑战
- 数据输入率可能会根据用户在某一特定时期的集中度而变化,因此需要更高的数据加载速度
- 集群需要得到很好的利用,并在各种应用程序之间共享集群,以更好地消耗和节省资源。
- 查询需要是交互式的,也就是说,查询获取的是小数据,需要在几秒钟内返回。
- 每隔几分钟就有数据加载到系统中。
解决方案
设置一个由YARN管理的Hadoop + Spark + CarbonData集群。
为CarbonData提出了以下配置(这些调整是在CarbonData引入SORT_COLUMNS参数之前提出的,使用该参数可以使排序顺序和模式顺序不同)。
将经常使用的列添加到表定义的左边。按照cardinality的递增顺序添加。有人建议将msisdn,imsi列放在模式的开头。在最新的CarbonData中,SORT_COLUMNS需要在开头配置msisdn,imsi。
在模式的右边添加时间戳列,因为它是自然增长的。
为查询和数据加载创建两个独立的YARN队列。
除此以外,建议在集群中配置以下CarbonData配置。
为何种场景提供服务 |
参数 |
价值 |
描述 |
数据加载 |
carbon.number.of.cores.while.loading |
12 |
更多的内核可以提高数据加载速度 |
数据加载 |
carbon.sort.size |
100000 |
每次排序的记录数。配置的记录数越多,内存占用就越大。 |
数据加载 |
table_blocksize |
256 |
为了在查询期间有效地安排多个任务 |
数据加载 |
carbon.sort.intermediate.files.limit |
100 |
由于核心数量较多,增加到100个。可以在后台进行合并,如果要合并的文件数量较少,排序线程将被闲置。 |
数据加载 |
carbon.use.local.dir |
YES |
yarn应用目录通常会在一个磁盘上。YARN会配置多个磁盘,作为临时磁盘或随机分配给应用。使用yarn temp目录将允许carbon使用多个磁盘并提高IO性能。 |
压缩 |
carbon.compaction.level.threshold |
6,6 |
由于频繁的小负荷,压缩更多的段会得到更好的查询结果 |
压缩 |
carbon.enable.auto.load.merge |
TRUE |
由于数据加载量小,自动压缩可以保持较少的段数,并且可以及时完成压缩。 |
压缩 |
carbon.number.of.cores.while.compacting |
4 |
更多的核心数量可以提高压实速度 |
压缩 |
carbon.major.compaction.size |
921600 |
将几个负载的总和合并为一个部分 |
已取得的成果
参数 |
结果 |
查询 |
< 3秒 |
数据加载速度 |
每个节点40MB/s |
并发查询性能(20次查询 |
< 10 秒 |
智慧城市情景下的详细查询
场景
用户希望分析某个时间段内人/车的运动和行为。这个输出数据需要与一个外部表连接,以提取人的详细信息。该查询将以不同的时间段作为过滤器来运行,以识别潜在的行为不匹配。
挑战
每天产生的数据是非常巨大的。数据需要每天多次加载,以适应进入的数据规模。
数据加载在6小时内完成一次。
解决方案
设置一个由YARN管理的Hadoop + Spark + CarbonData集群。
由于需要查询某一时间段的数据,建议将时间列放在模式的开头。
使用表块大小为512MB。
使用本地排序模式。
除此以外,建议在集群中配置以下CarbonData配置。
使用所有的列是无字典的,因为cardinality很高。
为何种场景提供服务 |
参数 |
价值 |
描述 |
数据加载 |
enable.unsafe.sort |
是的 |
在排序过程中产生的临时数据是巨大的,会导致GC瓶颈。使用不安全的方式可以减少对GC的压力 |
数据加载 |
enable.offheap.sort |
是的 |
在排序过程中产生的临时数据是巨大的,会导致GC瓶颈。使用offheap可以减少GC的压力。offheap可以通过java unsafe访问,因此enable.unsafe.sort需要为true。 |
数据加载 |
offheap.sort.chunk.size.in.mb |
128 |
为排序分配的内存大小。可以根据可用的内存来增加这个大小。 |
数据加载 |
carbon.number.of.cores.while.loading |
12 |
更高的内核可以提高数据加载速度 |
数据加载 |
carbon.sort.size |
100000 |
每次排序的记录数。配置更多的记录数将导致内存足迹的增加。 |
数据加载 |
table_blocksize |
512 |
为了在查询期间有效地安排多个任务。这个大小取决于数据情况。如果数据是这样的,过滤器会选择较少数量的小块来扫描,保持较高的数量效果很好。如果要扫描的小块数量较多,最好减少大小,因为可以并行安排更多的任务。 |
数据加载 |
carbon.sort.intermediate.files.limit |
100 |
由于核心数量较多,增加到100个。可以在后台进行合并,如果要合并的文件数量较少,排序线程将被闲置。 |
数据加载 |
carbon.use.local.dir |
是的 |
yarn应用目录通常会在一个磁盘上。YARN会配置多个磁盘,作为临时磁盘或随机分配给应用。使用yarn temp目录将允许carbon使用多个磁盘并提高IO性能。 |
数据加载 |
sort.inmemory.size.inmb |
92160 |
分配的内存用于做内存中的排序。当节点有更多的内存可用时,配置这个将在内存中保留更多的排序块,这样由于没有/非常少的IO,合并排序会更快。 |
压缩 |
carbon.major.compaction.size |
921600 |
将几个负载的总和合并为一个部分 |
压缩 |
carbon.number.of.cores.while.compacting |
12 |
更多的核心数量可以提高压实速度。数据大小是巨大的,压实需要使用更多的线程来加快进程。 |
压缩 |
carbon.enable.auto.load.merge |
失败 |
由于数据规模巨大,进行自动小规模压缩的过程成本很高。当集群负载较低时,执行手动压缩。 |
查询 |
carbon.enable.vector.reader |
真 |
为了更快地获取结果,支持火花矢量处理将加快查询速度 |
查询 |
enable.unsafe.in.query.processing |
真 |
需要扫描的数据是巨大的,这反过来又会产生更多短命的Java对象。这就造成了GC的压力。使用不安全和离堆将减少GC的开销。 |
查询 |
use.offheap.in.query.processing |
真 |
需要扫描的数据是巨大的,这反过来又会产生更多短命的Java对象。这导致了GC的压力。使用unsafe和offheap将减少GC的开销。offheap可以通过java unsafe访问,因此在查询处理中启用unsafe需要为true。 |
查询 |
enabled.unsafe.columnpage |
YES |
将列页保留在堆外内存中,这样由于java对象引起的内存开销就会减少,也会减少GC压力。 |
查询 |
carbon.unsafe.working.memory.in.mb |
10240 |
用于堆外操作的内存量,你可以根据数据大小增加这个内存量 |
已取得的成果
参数 |
结果 |
查询(时间段跨度为1段)。 |
< 10 秒 |
数据加载速度 |
每个节点45MB/s |
网络/互联网情况下的OLAP/BI查询
场景
一家互联网公司希望分析平均下载速度,在一个特定地区/区域使用的手机种类,正在使用的应用程序种类,什么样的视频在一个特定地区的趋势,使他们能够确定适当的视频分辨率大小,以加快传输速度,并进行更多的分析,以更好地服务客户。
挑战
由于数据被BI工具查询,所有的查询都包含group by,这意味着CarbonData需要返回更多的记录,因为限制不能被推送到carbondata层。
结果必须更快地返回,因为BI工具在获取数据之前不会做出反应,导致用户体验不佳。
数据的加载频率可能较低(一天内一次或两次),但原始数据量很大,这导致分组查询的运行速度较慢。
由于BI仪表盘的原因,并发的查询可以更多
目标
1. 聚合查询更快
2. 并发性高(支持并发查询的数量)。
解决方案
- 使用表块大小为128MB,以便剪枝更有效。
- 使用全局排序模式,以便将要获取的数据归为一组。
- 为聚合查询创建物化视图
- 减少Spark shuffle分区(在我们14个节点集群的配置中,它从默认的200个减少到35个)。
- 对于cardinality较高的列,启用本地字典,这样存储量较小,并且可以利用字典的好处进行扫描。
处理近乎实时的数据摄入情况
场景
需要支持存储不断到达的数据,并使其立即可供查询。
挑战
当数据摄取接近实时,并且数据需要立即可供查询时,通常的情况是以微型批次进行数据加载。但这导致产生许多小文件的问题。这带来了两个问题。
1. HDFS中的小文件处理是低效的
2. CarbonData的查询性能将受到影响,因为当过滤器是在非时间列上时,所有的小文件都必须被查询到。
CarbonData的查询性能将受到影响,因为当过滤器是在非时间列上时,所有的小文件都必须被查询到。
由于数据不断到达,为压实工作分配资源可能不可行。
目标
1. 当数据到达时,可以近乎实时地进行查询
2. CarbonData不存在小文件的问题
解决方案
- 使用CarbonData的流表支持
- 如果不担心查询性能稍慢,可将carbon.streaming.segment.max.size属性配置为更高的值(默认为1GB)。
- 将carbon.streaming.auto.handoff.enabled配置为true,以便在carbon.streaming.segment.max.size达到后,将segment转换为优化的格式供查询。
- 禁用自动压实,当集群不忙时,手动触发小压实,默认为4,3。
- 根据段的大小和创建段的频率,手动触发主要压实。
- 启用本地字典