zoukankan      html  css  js  c++  java
  • CarbonData使用案例

    使用案例

    CarbonData在各种分析工作中都很有用。这里记录了CarbonData被使用的一些最典型的使用情况。

    CarbonData用于但不限于以下方面

    银行

    o 欺诈检测分析

    o 风险状况分析

    o 作为一个拉链表来更新客户的每日余额

    电信

    检测VIP客户的信号异常以提供更好的客户体验

    分析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。
    • 根据段的大小和创建段的频率,手动触发主要压实。
    • 启用本地字典
  • 相关阅读:
    In Java, how do I read/convert an InputStream to a String? Stack Overflow
    IFrame自动更改大小
    [置顶] 获取服务器上格式为JSON和XML两种格式的信息的小程序
    Qt VS MFC
    [技术分享]使用 UAG 发布 RemoteAPP
    linux2.6.32在mini2440开发板上移植(11)之配置USB外设
    MFC控件(2):Text_Edit_Control
    CentOS 6.4 安装 Oracle 10g2 备记
    sql lite 二个数据库之间的表进行复制
    变量和函数的定义和声明
  • 原文地址:https://www.cnblogs.com/lukairui/p/15304470.html
Copyright © 2011-2022 走看看