单表千亿电信大数据场景，使用Spark+CarbonData替换Impala案例

【背景介绍】

国内某移动局点使用Impala组件处理电信业务详单，天天处理约100TB左右详单，详单表记录天天大于百亿级别，在使用impala过程当中存在如下问题:

1. 详单采用Parquet格式存储，数据表使用时间+MSISDN号码作分区，使用Impala查询，利用不上分区的查询场景，则查询性能比较差。
2. 在使用Impala过程当中，遇到不少性能问题(好比catalog元数据膨胀致使元数据同步慢等)，并发查询性能差等。
3. Impala属于MPP架构，只能作到百节点级，通常并发查询个数达到20左右时，整个系统的吞吐已经达到满负荷状态，在扩容节点也提高不了吞吐量。
4. 资源不能经过YARN统一资源管理调度，因此Hadoop集群没法实现Impala、Spark、Hive等组件的动态资源共享。给第三方开放详单查询能力也没法作到资源隔离。

【解决方案】

针对上面的一系列问题，移动局点客户要求咱们给出相应的解决方案，咱们大数据团队针对上面的问题进行分析，而且作技术选型，在这个过程当中，咱们以这个移动局点的几个典型业务场景做为输入，分别对Spark+CarbonData、Impala2.六、HAWQ、Greenplum、SybaseIQ进行原型验证，性能调优，针对咱们的业务场景优化CarbonData的数据加载性能，查询性能并贡献给CarbonData开源社区，最终咱们选择了Spark+CarbonData的方案，这个也是典型的SQL On Hadoop的方案，也间接印证了传统数据仓库往SQL on Hadoop上迁移的趋势。参考社区官网资料，结合咱们验证测试和理解：CarbonData是大数据Hadoop生态高性能数据存储方案，尤为在数据量较大的状况下加速明显，与Spark进行了深度集成，兼容了Spark生态全部功能（SQL,ML，DataFrame等），Spark+CarbonData适合一份数据知足多种业务场景的需求，它包含以下能力：

1. 存储：行、列式文件存储，列存储相似于Parquet、ORC，行存储相似Avro。支持针对话单、日志、流水等数据的多种索引结构。
2. 计算：与Spark计算引擎深度集成和优化；支持与Presto, Flink, Hive等引擎对接；
3. 接口：
   1. API：兼容DataFrame, MLlib, Pyspark等原生API接口；
   2. SQL：兼容Spark语法基础，同时支持CarbonSQL语法扩展（更新删除，索引，预汇聚表等）。
4. 数据管理：
   1. 支持增量数据入库，数据批次管理(老化管理)
   2. 支持数据更新，删除
   3. 支持与Kafka对接，准实时入库

       详细的关键技术介绍以及使用，请上官网阅读查看文档https://carbondata.apache.org/  

【技术选型介绍】

这里补充介绍下为何选取SQL on Hadoop技术做为最终的解决方案。

接触过大数据的人都知道，大数据有个5V特征，从传统互联网数据到移动互联网数据，再到如今很热门的IoT，实际上随着每一次业界的进步，数据量而言都会出现两到三个数量级的增加。并且如今的数据增加呈现出的是一个加速增加的趋势，因此如今提出了一个包括移动互联网以及物联网在内的互联网大数据的5大特征：Volume、 Velocity、Variety、Value、Veracity。随着数据量的增加传统的数据仓库遇到的挑战愈来愈多。

传统数据仓库面临的挑战:

同时数据体系也在不断的进化

• 存储方式的进化：离线、近线 -> 所有在线

• 存储架构的进化：集中式存储 -> 分布式存储

• 存储模型的进化：固定结构 -> 灵活结构.

数据处理模式的进化

• 固定模型固定算法 -> 灵活模型灵活算法

数据处理类型的进化

• 结构化集中单源计算 -> 多结构化分布式多源计算

数据处理架构的进化

• 数据库静态处理 -> 数据实时/流式/海量处理

针对上述的变化数据库之父Kimball提出了一个观点：

   Kimball的核心观点：

  hadoop改变了传统数仓库的数据处理机制，传统数据库的一个处理单元在hadoop中解耦成三层：

• 存储层：HDFS

• 元数据层：Hcatalog

• 查询层：Hive、Impala、Spark SQL

Schema on Read给了用户更多的选择：

• 数据以原始格式导入存储层

• 经过元数据层来管理目标数据结构

• 由查询层来决定何时提取数据

• 用户在长期探索和熟悉数据以后，能够采起Schema on Write模式固化中间表，提升查询性能

序号	基于RDBMS的数据处理模式	基于hadoop的数据处理模式
1	强一致性	最终一致性，处理效率高于数据精确度
2	数据必须进行转换，不然后续流程没法继续	数据能够不作转换，长期以原始格式存储
3	数据必须进行清洗、范式化	数据不建议进行清洗和范式化
4	数据基本上都保存在物理表中，文件方式访问效率低	数据大部分保存在文件中，物理表等同于结构化文件
5	元数据局限为字典表	元数据扩展为HCatalog服务
6	数据处理引擎只有SQL一种	开放式的数据处理引擎：SQL、NOSQL、Java API
7	数据加工过程彻底由IT人员掌控	数据工程师、数据科学家、数据分析人员均可以参与数据加工

SQL on Hadoop数据仓库技术

数据处理和分析

     • SQL on hadoop

     • Kudu+Impala、Spark、HAWQ、Presto、Hive等

• 数据建模和存储

           • Schema on Read

           • Avro & ORC & Parquet & CarbonData

• 流处理

           • Flume+Kafka+Spark Streaming

SQL-on-Hadoop技术的发展和成熟推进变革

通过上述的技术分析，最终咱们选择了SQL on Hadoop的技术做为咱们平台将来的数据仓库演进方向，这里确定有人问了，为何不选取MPPDB这种技术呢，这里咱们一样把SQL on Hadoop与MPPDB进行过对比分析（注Impala其实也是一种相似MPPDB的技术）：

对比项	SQL on Hadoop	MPPDB
容错性	支持细粒度容错,细粒度容错是指某个task失败会自动重试，不用从新提交整个查询	粗粒度容错，不能处理落后节点 (Straggler node)。粗粒度容错是指某个task执行失败将致使整个查询失败，而后系统从新提交整个查询来获取结果
扩展性	集群节点数量能够扩展到几百甚至上千个	很难扩展到100个节点以上，通常在50个节点左右(好比以前咱们使用Greenplum验证超过32台机器性能出现降低)
并发性	随着集群规模可用资源增长，并发数近线性增加	MPPDB针对查询会最大化利用资源，以提高查询性能，所以支撑的并发数较低，通常并发查询个数达到 20 左右时，整个系统的吞吐已经达到满负荷状态
查询时延	一、数据规模小于1PB，单表10亿记录级别，单个查询时延一般在10s左右 二、数据规模大于1PB，可经过增长集群资源，保证查询性能	一、数据规模小于1PB，单表10亿记录级别，单个查询MPP时延一般在秒计甚至毫秒级之内就能够返回查询结果 二、数据规模大于1PB，受架构限制，查询性能可能会出现急剧降低
数据共享	存储与计算分离，通用的存储格式能够支撑不一样的数据分析引擎，包括数据挖掘等	独有的MPPDB数据库的存储格式，没法直接供其余数据分析引擎使用

【方案实施效果】

   局点2018年9月底上线Spark+CarbonData替换Impala后运行至今，天天处理大于100TB的单据量，在业务高峰期，数据加载性能从以前impala的平均单台60MB/s到平台单台100MB/s的性能，在局点典型业务场景下，查询性能在20并发查询下，Spark+CarbonData的查询性能是Impala+parquet的2倍以上。

同时解决了如下问题：

1. Hadoop集群资源共享问题，Impala资源不能经过Yarn统一资源调度管理，Spark+CarbonData能经过Yarn统一资源调度管理，实现与其余如Spark，Hive等组件的动态资源共享。
2. Hadoop集群扩容问题，以前Impala只能使用百台机器，如今Spark+CarbonData能作到上千台节点集群规模。

实施过程当中注意项：

1. 数据加载使用CarbonData的local sort方式加载，为了不大集群产生过多小文件的问题，加载只指定少数机器上进行数据加载，另外对于每次加载数据量比较小的表能够指定表级别的compaction来合并加载过程当中产生的小文件。
2. 根据业务的查询特色，把常常查询过滤的字段设置为数据表的sort column属性(好比电信业务常常查询的用户号码等)，而且设置sort column的字段顺序先按照字段的查询频率由高到低排列，若是查询频率相差不大，则再按照字段distinct值由高到低排列，来提高查询性能。
3. 建立数据表设置的blocksize大小，单个表的数据文件block大小能够经过TABLEPROPERTIES进行定义，单位为MB，默认值为1024MB。这个根据实际数据表的每次加载的数据量，根据咱们实践经验：通常建议数据量小的表blocksize设置成256MB，数据量比较大的表blocksize设置成512MB。
4. 查询性能的调优，还能够结合业务查询的特色，对查询高频率的字段，建立bloomfilter等datamap来提高查询性能。
5. 还有一些Spark相关的参数设置，对于数据加载和查询，先结合SparkUI分析性能瓶颈点，在针对性的调整相关的参数，这里不一一介绍了，记住一点性能调优是个技术细活，参数调整要针对性的调整，一次调整只调相关的一个或者几个参数，在看效果，不生效就调整回去，切记千万不要一次性调整的参数过多。