万师傅使用云产品，上手简单、开箱即用、省去运维烦恼

云栖号案例库： 【点击查看更多上云案例】 不知道怎么上云？看云栖号案例库，了解不一样行业不一样发展阶段的上云方案，助力你上云决策！

总体架构

---

每当我在思考技术选型方案的时候，翻翻阿里云的官网，总能找到我想要的东西。因而，咱们的大数据体系就变成了这样，如图：

离线

---

2.1 选型原则

团队成员，大都是Hive方向或是算法方向出身。为追求上手简单、专一数据的分析和挖掘、减小没必要要的学习成本和费用成本，使用了阿里云MaxCompute。

2.2 数据采集

数据源共包含三类：

（1）关系型数据库中的数据； （2）服务器上的日志文件； （3）前端埋点日志；

采集方式如图：

关系型数据库中的数据，使用dataworks中的“数据集成”功能，定时离线同步到MaxCompute中； 其余两类数据，以及关系型数据库的Binlog，直接使用了万能的“日志服务SLS”。WebTracking支持直接收集HTML、H五、iOS和 Android的日志；Logtail支持收集服务器上的日志文件，以及关系型数据库的Binlog。数据都收集过来以后，再定时将数据投递到MaxCompute中； 如上两个步骤，完成了三类数据的收集。比业界常见的Flume+Kafka、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 数据库

阿里云包含了很是多的数据库类产品，根据咱们的实际需求，主要使用了如下几款：

（1）RDS for MYSQL，与MYSQL一致，不须要过多介绍； （2）PolarDb，阿里云自研的云原生数据库，与RDS价格一致。对于咱们使用者来讲，它是一个能够支持更高读并发、单实例容量更大的MYSQL。能够帮助咱们创建离线数据中心，也解决了“全部数据库的查询都要先通过Redis缓存”的问题，节省了少许Redis的费用； （3）TableStore，这款产品的初衷应该是想要对标开源的HBase，主要用于单一索引、庞大数据量、单条或小范围检索、高并发、低延时的查询场景。在单条查询时，性能几乎能够媲美Redis，并且也拥有TTL功能。被咱们大量使用在用户画像、幂等校验等场景中； 其余产品，例如DRDS、AnalyticDb，或MongoDb、Elasticsearch等，因为目前的场景不须要，因此没有投入使用。

数据展现

---

4.1 选型原则

前端产品的选型原则很简单，因为咱们的团队没有专门的前端开发，因此只能选择阿里云的产品、或者免费的、可对接的开源产品。

4.2 实践

• 阿里云的可视化产品主要有两个：QuickBI和DataV。咱们都有使用。
• QuickBI主要用于平常的数据展现、分析，帮助运营、产品等部门进行决策；
• DataV主要用于“非交互式”的数据展现场景，例如展会、大屏等。

云栖号案例库： 【点击查看更多上云案例】 不知道怎么上云？看云栖号案例库，了解不一样行业不一样发展阶段的上云方案，助力你上云决策！

上云就看云栖号：更多云资讯，上云案例，最佳实践，产品入门，访问：https://yqh.aliyun.com/

本文为阿里云原创内容，未经容许不得转载。