苏宁数据仓库应对数据爆发式增长的技术演进
|
2. 两大表关联，其中表中关键key值存在部分键值数据非常大，导致数据倾斜
出现数据倾斜还是需要先分析key值数据分布情况确认解决方案。 实时数据处理1)数据重复 在实时数据处理过程中，不论使用storm、sparkstreaming、flink，因为在保证大数据大吞吐计算情况下，往往较难保证数据事务，在环境或者计算出现异常情况下，容易出现某个批次部分数据重复计算，在很多数据业务分析往往是无法接受的，对需要准确性统计的计算场景，缓存每次计算结束的列表，每次计算前根据已计算列表验证当前数据是否已经计算过，对计算过的数据跳过本次计算，这样程序异常或者重启，重新读取kafka数据会跳过已经计算完成的数据。对用户流量类大数据量做到精确统计消耗成本太高，可以根据实际业务需要选择对应方案。 2)双数据流关联 多数情况，在实时指标分析过程中，指标和维度往往能通过一个数据源来分析计算得出，在某些场景下，指标对应维度会对应不同的数据源，这时候就需要将两个数据源根据业务ID关联起来，然而两个实时数据流可能会出现1.两个数据流数据不同步，2.数据采集可能存在一定的数据丢失，导致可能部分pv再等待另外一个流永远都等不到。 以流量PV指标举例，分析维度包含：城市、页面类型、供应商等，其中流量访问日志里面包含PV_ID、城市、页面类型等信息，流量库存日志包含PV_ID、供应商等信息，pv数指标对应维度分表对应两个数据源中，在离线计算中join直接解决，在实时计算过程中又怎么关联呢? 首先需要分析两个数据流哪个是主数据流，所有的统计数据以主流为基础，保证主流数据不丢失，部分场景也可能两个流合并作为主数据流; 其次需要对两个数据流设定一定的缓存，对未关联上的数据先记录到缓存中，等待另外数据流做关联操作，缓存需要有持久化机制，保证系统出现问题或者程序重启缓存不会丢失; 再次设置缓存时长，由于包括数据丢失等可能情况会导致数据无法关联情况，此时需要根据业务定义缓存时长，对超过时长还未关联到的数据根据业务做对应处理。 在实际实时模型设计尽可能减少双流关联的计算场景，一方面双流关联开发较复杂，另外一方面双流关联相比单流数据准确性存在下降的可能性，在上举例中，可以通过上游采集系统在访问流添加供应商等维度，由一个数据流支撑对应指标和维度，双流在采集端容易做业务合并的尽可能在采集端做业务合并。 大促计算保障电商行业，大促业务量是日常业务量的很多倍，暴增的数据量对计算平台各环节都会带来较大的挑战。 离线计算，1.数据暴增首先带来的是底层平台HDFS计算压力，需要根据预估业务量扩容平台计算能力;2.数据暴增容易带来数据倾斜问题，例如大促爆款商品等呈现分化数据会导致数据分布严重不均匀，需要打散数据，有效利用平台资源分散计算，缩短计算时间;3.提前分析核心业务线，识别关键路径，对关键路径中慢节点做拆分优化，提高计算并行能力，缩短关键路径时间。在大促保障期间，通过计算倾斜的优化和关键路径的拆分优化，有效提前整体出数时间。 实时计算：1.根据预估业务量扩容实时计算storm、spark streaming、flink等平台资源;2.在流处理业务中，根据业务数据量、业务重要程度对业务计算做拆分，避免集群内业务互相影响，对storm需要根据业务做集群拆分，尽可能将数据量大非核心业务拆分单独集群，避免集群内非核心业务抢占核心业务资源3.合理利用数据缓存有效提高实时计算能力;4.对适合在客户端采集实现的业务，由采集来实现，减轻大数据平台计算压力，也能通过数据采集优化有效避免部分业务的双流关联，提高实时计算效率和准确度。 名词解释：
作者：彭虎，苏宁易购IT总部大数据中心技术副总监，12年IT从业经验，专长大数据hive、storm、spark等数据计算技术，对数据建模、数据计算、多维分析有着专业认知和研究，致力于数据仓库探索研究、数据质量分析、数据计算保障。 【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】 【编辑推荐】
点赞 0 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
