100亿小数据实时计算平台

2017年6月,开始数据分析的职业生涯,作为架构师,建立起一套基于.Net/.Net Core的小数据实时处理计算平台,这里记录学习过程中的点点滴滴!

数据分析的核心,可以理解为:Select xxx From table Where yyy Group By zzz

小数据计算平台的定位:

  1. 数据量在1000万行到100亿行之间,传统关系型数据库算起来吃力,且类似项目不是特别多,Hadoop搭起来难以收回成本
  2. 资源投入有限,基于传统项目之上的轻量级数据分析,一般只能有1~2台服务器,Hadoop最好能有8台以上服务器
  3. 门槛低,普通软件工程师容易上手做数据分析,并参与开发配套的业务系统,大数据开发工程师需要会很多(Hadoop、MapReduce、HDFS、Hive、HBase、Spark、Zookeeper、Sqoop)
  4. 实时内存计算,C#/Java/Go+Redis/MongoDB,轻松做到0.5~5分钟实时处理,大多数大数据开发工程师只熟悉 Hadoop+Hive,擅长T+1离线计算,对实时计算Spark+HBASE熟悉的不多

题外:其实大家平时借助消息队列(Kafaka/RocketMQ)异步处理的统计,本身就属于实时计算数据分析的一种!

该平台的目标并非替代Hadoop,而是对中小型数据分析提供一种轻量级选择。

实际上我们大部门就有完整的Hadoop大数据平台,我们的许多模块,都跟Hive、HBase、Kafka等有大量的数据交互

未来的日子里,会根据后面的小数据平台配套,把相关技术慢慢写下来。

文章目录:

借助Redis做秒杀和限流的思考

大数据分析中Redis怎么做到220万ops

每天4亿行SQLite订单大数据测试(源码)

小数据计算平台配套:

  1. 关系型数据库,数据来源以及计算结果存储,推荐MySql,批量插入5000~50000tps
  2. Redis,原始数据源预热,中间计算数据临时存储,结果数据缓冲队列,选Linux/Windows多实例部署,单实例性能8w~10wops
  3. 计算节点,核心数据分析应用,从数据库或Redis或微服务读取原始数据和基础数据,根据业务规则进行计算,统计结果直接落库或借助Redis异步落库
  4. 调度系统,时间片调度算法,对数据进行切片处理,多实例多线程并行计算,错误或超时重试机制。计算节点上跑的分析应用依赖于调度系统
  5. 服务节点,频繁且反复读取的小数据(1000万~100亿)预热进入Redis,大量部署微服务,封装各种数据访问,10万以下数据直接缓存到进程内存
  6. 微服务注册中心,每个服务至少部署2个节点(可用性、负载均衡),大量服务需要管理起来,伸缩扩容
  7. 配置中心,数据分析应用和微服务的大量伸缩部署,需要有配置中心把数据库配置等各种配置管理起来
  8. 监控中心,监控重要计算节点和服务节点,通过微信/短信/钉钉等工具报告紧急情况,或每天提供数据简报

实际使用根据需要进行调整,如果数据分析项目不多,后面的辅助性配套可以不要。

关于博客,10多年来断断续续也写了不少博文,我写的博客有个特点,都是经过深思熟虑并且在网络上很少能找到相关内容的知识点。

关于工作,公司财报提到2018年第二季度包裹量21.16亿件,公司名和具体工作内容不方便讨论,还请大家见谅和监督!

本文答疑:QQ群1600800,2018-08-12 20:00:00

End.

原文地址:https://www.cnblogs.com/nnhy/p/Data.html

时间: 2024-10-07 18:00:25

100亿小数据实时计算平台的相关文章

实时计算平台

实时计算平台中的弹性集群资源管理 本文系微博运维数据平台(DIP)在实时计算平台的研发过程中集群资源管理方面的一些经验总结和运用,主要关注以下几个问题: 异构资源如何整合? 实时计算应用之间的物理资源如何隔离? 集群资源利用率如何提高? 集群运维成本如何降低? 1. 背景 这是我们初期的一个实时计算架构,大致划分为三个部分: (1)日志收集: 使用Rsynlog.Flume.Scribe汇聚各个业务方发送过来的日志数据:如果条件允许,业务方也可以直接将数据写入Kafka. (2)日志传输: 使用

实时计算平台中的弹性集群资源管理

本文系微博运维数据平台(DIP)在实时计算平台的研发过程中集群资源管理方面的一些经验总结和运用,主要关注以下几个问题: 异构资源如何整合? 实时计算应用之间的物理资源如何隔离? 集群资源利用率如何提高? 集群运维成本如何降低? 1. 背景 这是我们初期的一个实时计算架构,大致划分为三个部分: (1)日志收集: 使用Rsynlog.Flume.Scribe汇聚各个业务方发送过来的日志数据:如果条件允许,业务方也可以直接将数据写入Kafka. (2)日志传输: 使用Kafka作为日志收集组件与实时应

权威详解 | 阿里新一代实时计算引擎 Blink,每秒支持数十亿次计算

王峰,淘宝花名"莫问",2006年毕业后即加入阿里巴巴集团,长期从事搜索和大数据基础技术研发工作,目前在计算平台事业部,负责实时计算北京研发团队. 在阿里巴巴的11年工作期间,持续专注大数据计算与存储技术领域,基于Hadoop开源生态打造的数据基础设施一直服务于搜索.推荐等阿里核心电商业务场景,最近一年带领团队对Apache Flink进行了大量架构改进.功能完善和性能提升,打造出了阿里新一代实时计算引擎: Blink.目前数千台规模的Blink生产集群已经开始在线支持搜索.推荐.广告

细细品味架构(第1期)_实时计算在点评

Hi,博友: 欢迎查阅<细细品味架构>系列,本系列将和我一起学习,并慢慢走近架构师的神秘世界. 本期目录: 1.本期内容... 3 1.1 版权申明... 3 1.2 内容详情... 3 1.2.1 实时计算在点评的使用场景... 3 1.2.2 实时计算在业界的使用场景... 4 1.2.3 点评如何构建实时计算平台... 5 1.2.4 Storm基础知识简单介绍... 6 1.2.5 如何保证业务运行可靠性... 8 1.2.5 Storm日常使用经验分享... 10 1.2.6 关于计

【方案】去哪儿网徐磊:如何利用开源技术构建日处理130亿+的实时日志平台?

转自:http://mp.weixin.qq.com/s?__biz=MzIzMzEzODYwOA==&mid=2665284466&idx=1&sn=2b06a529821734e36e26e642424f24fc&scene=2&srcid=0527p3qISp6dFqGg8iLIYgRF&from=timeline&isappinstalled=0#wechat_redirect [本文系互联网技术联盟(ITA1024)原创首发,转载或节选内容

打破摩尔定律:谷歌与腾讯的下一代计算平台选择是?

(上图为腾讯服务器平台架构师.天蝎计划3.0项目经理王伟) 谷歌技术架构高级副总裁Urs Hlzle曾在2015年4月对美国媒体表示,谷歌肯定将切换到下一代计算平台,这就是基于OpenPOWER开放芯片架构的服务器.而谷歌服务器与存储系统设计高级总监.OpenPOWER联盟首届主席Gordon McKean表示,已经越来越难从现有的X86服务器中"榨取"更好的性能了. 无独有偶,与谷歌研发下一代计算平台同样重量级的是中国互联网公司的天蝎计划.在2016年6月22日OpenPOWER中国

实时计算,流数据处理系统简介与简单分析

转自:http://www.csdn.net/article/2014-06-12/2820196-Storm 摘要:实时计算一般都是针对海量数据进行的,一般要求为秒级.实时计算主要分为两块:数据的实时入库.数据的实时计算.今天这篇文章详细介绍了实时计算,流数据处理系统简介与简单分析. 编者按:互联网领域的实时计算一般都是针对海量数据进行的,除了像非实时计算的需求(如计算结果准确)以外,实时计算最重要的一个需求是能够实时响应计算结果,一般要求为秒级.实时计算的今天,业界都没有一个准确的定义,什么

如何打造100亿SDK累计覆盖量的大数据系统

作为推送行业领导者,截止目前个推SDK累计安装覆盖量达100亿(含海外),接入应用超过43万,独立终端覆盖超过10亿 (含海外).个推系统每天会产生大量的日志和数据,面临许多数据处理方面的挑战. 首先数据存储方面,个推每天产生10TB以上的数据,并且累积数据已在PB级别.其次,作为推送技术服务商,个推有很多来自客户和公司各部门的数据分析和统计需求,例如:消息推送和数据报表.虽然部分数据分析工作是离线模式,但开源数据处理系统稳定性并不很高,保障数据分析服务的高可用性也是一个挑战.另外,推送业务并不

刘强东100亿投资湘潭的背后不只是商业

这两天被刘强东湘潭寻亲投资100亿的消息刷屏了吗?东哥100亿大手笔,千里寻亲不忘本,感恩回报社会.这一波操作溜!一.刘强东两轮签约,100亿投资湘潭据媒体报道,刘强东此次在湘潭共投资100个亿,进行了两轮签约.第一轮签约的是<湘潭市人民政府京东集团战略合作框架协议>,双方约定共同推动湘潭智慧物流配送体系建设.京东将在湘潭各区县建立城乡末端配送网络,加大新能源配送车辆.智能配送柜.无人机.无人车等物流设备设施投入,助力湘潭建立现代电子商务智慧物流体系:通过建设前置中转仓储等方式,与本地商家对接