江苏龙网

  1. 首页 > 人文 > >

『阿里云云栖社区TB』万师傅使用云产品，上手简单、开箱即用、省去运维烦恼


整体架构
每当我在思考技术选型方案的时候 ， 翻翻阿里云的官网 ， 总能找到我想要的东西 。 于是 ， 我们的大数据体系就变成了这样 ， 如图：
『阿里云云栖社区TB』万师傅使用云产品，上手简单、开箱即用、省去运维烦恼
本文插图
离线2.1 选型原则
团队成员 ， 大都是Hive方向或是算法方向出身 。 为追求上手简单、专注数据的分析和挖掘、减少不必要的学习成本和费用成本 ， 使用了阿里云MaxCompute 。
2.2 数据采集
数据源共包含三类：
（1）关系型数据库中的数据；（2）服务器上的日志文件；（3）前端埋点日志；
采集方式如图：
『阿里云云栖社区TB』万师傅使用云产品，上手简单、开箱即用、省去运维烦恼
本文插图
关系型数据库中的数据 ， 使用dataworks中的“数据集成”功能 ， 定时离线同步到MaxCompute中；其他两类数据 ， 以及关系型数据库的Binlog ， 直接使用了万能的“日志服务SLS” 。 WebTracking支持直接收集HTML、H5、iOS和 Android的日志；Logtail支持收集服务器上的日志文件 ， 以及关系型数据库的Binlog 。 数据都收集过来之后 ， 再定时将数据投递到MaxCompute中；如上两个步骤 ， 完成了三类数据的收集 。 比业界常见的Flume+Kafka、Kettle、Logstash等方式 ， 上手更快、维护更简单 。
2.3 数据仓库
2.3.1 分层
『阿里云云栖社区TB』万师傅使用云产品，上手简单、开箱即用、省去运维烦恼
本文插图
【『阿里云云栖社区TB』万师傅使用云产品，上手简单、开箱即用、省去运维烦恼】
数据仓库的分层模型 ， 大体的思路和网上烂大街的数仓分层原则相似 ， 总体分ODS、DW、RPT三层 。 具体实践的过程中 ， 根据我们的实际情况 ， 慢慢形成了我们自己的风格 。
ODS层 ， 大部分是和数据源中的数据一模一样的 ， 也有极少部分经过了简单的ETL、或者只截取了与统计有关的字段 。 数据已采用了其他备份方式 ， 所以这里不再需要使用MaxCompute做冷备 。
DW层是最核心的数据仓库层 。 由于公司技术正在朝着微服务转型 ， 系统、数据库拆分得越来越细 ， 对数据的统计分析很不利 。 所以我们依靠数据仓库层 ， 将相关的数据放到一起 ， 便于上层的开发、更有利于日常的临时数据需求的快速响应 。 数据仓库层的数据结构 ， 不会随着微服务系统和数据的拆分而变化 ， 让系统拆分对于这套离线数据分析的影响终结在这一层 ， 不渗透到更上层 。
RPT层的具体做法 ， 市面上有很多种 。 根据我们的实际情况 ， 决定采用按业务划分的方式 。 曾经我们也尝试过按数据产品划分 ， 但是时间长了 ， 出现了几个严重的问题 。 首先 ， 不同数据产品中对于相同指标的定义混乱 ， 导致各个部门对于数据没有一个统一的概念 。 其次 ， 技术上的系统拆分的影响范围 ， 随着数据产品的增多而大面积扩大 ， 极易出现修改遗漏的现象 。
2.3.2 DATAWORKS
配套MaxCompute一起使用的Dataworks ， 是一个全能型的可视化工具 ， 集成了几乎一切我们使用MaxCompute时所需要配套的功能 ， 也解决了很多开源产品中无法解决的痛点 ， 例如：可视化调度、智能监控告警、数据权限控制等 。
实际使用时 ， 我们的数据在MaxCompute中的流转 ， 全部是通过MaxCompute SQL节点和机器学习节点进行的 。 定时依赖+调度依赖+跨周期依赖 ， 也让方案的设计变得更灵活 。
业务流程是按实际业务模块划分、没有按照数据产品划分 ， 这样可以解决“找任务难”、“不同团队对相同指标的定义不一致”等问题 。 当某个业务有变更时 ， 可以快速定位到需要配合修改的任务都有哪些 ， 有效地避免了遗漏 。
技术文档的同步更新一直是业界难以解决的痛点 ， 数据字典也不例外 。 按照业务模块划分了之后 ， 在新增指标时 ， 更容易发现是否已有相同或相似的指标 ， 即使数据字典更新不及时也不会有大影响 。


推荐阅读


上一篇：「cnBetaTB」Ubuntu Linux PC制造商System76推出多种木饰机箱面板选项

下一篇：「中国新闻网」粤餐饮业加快“触网” 半个月2.4万家入驻网上平台