使用案例
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。
- 根据段的大小和创建段的频率，手动触发主要压实。
- 启用本地字典