海珠网站建设制作,响应式网站的服务,建立企业网站的目的和意义,wordpress更换回编辑器云栖号案例库#xff1a;【点击查看更多上云案例】 不知道怎么上云#xff1f;看云栖号案例库#xff0c;了解不同行业不同发展阶段的上云方案#xff0c;助力你上云决策#xff01; 整体架构
每当我在思考技术选型方案的时候#xff0c;翻翻阿里云的官网#xff0c;总… 云栖号案例库【点击查看更多上云案例】 不知道怎么上云看云栖号案例库了解不同行业不同发展阶段的上云方案助力你上云决策 整体架构
每当我在思考技术选型方案的时候翻翻阿里云的官网总能找到我想要的东西。于是我们的大数据体系就变成了这样如图 离线
2.1 选型原则
团队成员大都是Hive方向或是算法方向出身。为追求上手简单、专注数据的分析和挖掘、减少不必要的学习成本和费用成本使用了阿里云MaxCompute。
2.2 数据采集
数据源共包含三类
1关系型数据库中的数据 2服务器上的日志文件 3前端埋点日志
采集方式如图 关系型数据库中的数据使用dataworks中的“数据集成”功能定时离线同步到MaxCompute中 其他两类数据以及关系型数据库的Binlog直接使用了万能的“日志服务SLS”。WebTracking支持直接收集HTML、H5、iOS和 Android的日志Logtail支持收集服务器上的日志文件以及关系型数据库的Binlog。数据都收集过来之后再定时将数据投递到MaxCompute中 如上两个步骤完成了三类数据的收集。比业界常见的FlumeKafka、Kettle、Logstash等方式上手更快、维护更简单。
2.3 数据仓库
2.3.1 分层 数据仓库的分层模型大体的思路和网上烂大街的数仓分层原则相似总体分ODS、DW、RPT三层。具体实践的过程中根据我们的实际情况慢慢形成了我们自己的风格。
ODS层大部分是和数据源中的数据一模一样的也有极少部分经过了简单的ETL、或者只截取了与统计有关的字段。数据已采用了其他备份方式所以这里不再需要使用MaxCompute做冷备。
DW层是最核心的数据仓库层。由于公司技术正在朝着微服务转型系统、数据库拆分得越来越细对数据的统计分析很不利。所以我们依靠数据仓库层将相关的数据放到一起便于上层的开发、更有利于日常的临时数据需求的快速响应。数据仓库层的数据结构不会随着微服务系统和数据的拆分而变化让系统拆分对于这套离线数据分析的影响终结在这一层不渗透到更上层。
RPT层的具体做法市面上有很多种。根据我们的实际情况决定采用按业务划分的方式。曾经我们也尝试过按数据产品划分但是时间长了出现了几个严重的问题。首先不同数据产品中对于相同指标的定义混乱导致各个部门对于数据没有一个统一的概念。其次技术上的系统拆分的影响范围随着数据产品的增多而大面积扩大极易出现修改遗漏的现象。
2.3.2 DATAWORKS
配套MaxCompute一起使用的Dataworks是一个全能型的可视化工具集成了几乎一切我们使用MaxCompute时所需要配套的功能也解决了很多开源产品中无法解决的痛点例如可视化调度、智能监控告警、数据权限控制等。
实际使用时我们的数据在MaxCompute中的流转全部是通过MaxCompute SQL节点和机器学习节点进行的。定时依赖调度依赖跨周期依赖也让方案的设计变得更灵活。
业务流程是按实际业务模块划分、没有按照数据产品划分这样可以解决“找任务难”、“不同团队对相同指标的定义不一致”等问题。 当某个业务有变更时可以快速定位到需要配合修改的任务都有哪些有效地避免了遗漏。
技术文档的同步更新一直是业界难以解决的痛点数据字典也不例外。按照业务模块划分了之后有新增指标时更容易发现是否已有相同或相似的指标即使数据字典更新不及时也不会有大影响。
实时
3.1 选型原则
团队初始成员均为Java出身并且我们当前没有、未来也不准备拥有自己的Hadoop集群。综合考虑采用了阿里开源的JStorm作为核心的流式计算引擎同时也在尝试业界最新的Flink为未来做准备。至于没有使用阿里云商业版的“实时计算”完全是出于成本考虑在我们的场景下自建JStorm集群的成本会远低于使用“实时计算”。
与核心的流式计算引擎相配套的中间件及数据存储使用的全部都是阿里云的产品开箱即用、省去运维烦恼。
3.2 实践
3.2.1 消息队列
消息队列类的产品主要使用了“日志服务SLS”和“消息队列RocketMQ”两种。
“日志服务SLS”这款产品大于等于开源组合ELK不仅有日志采集、搜索引擎、分析展示还有消息队列、监控告警等功能价格也很合理。尤其这几个功能的组合可以轻松实现业务日志告警、nginx监控等等使用传统方式要开发很久的需求。如果单纯作为消息队列使用还可以关闭索引以节省费用。
“消息队列RocketMQ”的使用主要看中了“定时延时消息”这一功能可以实现很多定时延时任务的需求场景。
3.2.2 缓存
Redis不需要过多介绍。
3.2.3 数据库
阿里云包含了非常多的数据库类产品根据我们的实际需求主要使用了以下几款
1RDS for MYSQL与MYSQL一致不需要过多介绍 2PolarDb阿里云自研的云原生数据库与RDS价格一致。对于我们使用者来说它是一个可以支持更高读并发、单实例容量更大的MYSQL。可以帮助我们建立离线数据中心也解决了“所有数据库的查询都要先经过Redis缓存”的问题节省了少量Redis的费用 3TableStore这款产品的初衷应该是想要对标开源的HBase主要用于单一索引、庞大数据量、单条或小范围检索、高并发、低延时的查询场景。在单条查询时性能几乎可以媲美Redis而且也拥有TTL功能。被我们大量使用在用户画像、幂等校验等场景中 其他产品例如DRDS、AnalyticDb或MongoDb、Elasticsearch等由于目前的场景不需要所以没有投入使用。
数据展示
4.1 选型原则
前端产品的选型原则很简单由于我们的团队没有专门的前端开发所以只能选择阿里云的产品、或者免费的、可对接的开源产品。
4.2 实践
阿里云的可视化产品主要有两个QuickBI和DataV。我们都有使用。QuickBI主要用于日常的数据展示、分析帮助运营、产品等部门进行决策DataV主要用于“非交互式”的数据展示场景例如展会、大屏等。云栖号案例库【点击查看更多上云案例】 不知道怎么上云看云栖号案例库了解不同行业不同发展阶段的上云方案助力你上云决策 本文为阿里云原创内容未经允许不得转载。
云栖号 - 上云就看云栖号
