苏宁人工智能研发中心智能创意平台架构成长之路 (一)-- 长篇开篇 https://www.cnblogs.com/laoqing/p/11326132.html 我们接着第一篇继续.
(这是第二篇大数据架构篇, 成长之路序列会包含多篇, 笔者作为这个平台的架构兼技术经理, 充分讲述其中的迭代心酸之路以及中间遇到的问题和解决方案)
声明: 文章不涉及公司内部技术资料的外泄, 涉及的图片都是重画的简易架构图, 主要通过架构的演进, 讲述分享技术的迭代之路和过程.
在第二轮迭代完成后, 第三轮迭代中, 我们就开始做平台的数据分析了, 这里我们以工作台数据分析为例, 讲解平台如何采用大数据的方式来进行数据分析.
工作台中, 需要做数据分析, 比如平台合成出来的 banner 图被用户的点击次数, banner 图合成出来后, 被用户下载的数据, 工作台中的 PV/UV 情况等.
在此轮设计中, 我们直接用的大数据解决方案, 并没有在一开始使用关系型数据来做这样的数据分析统计, 架构方案如下, 我们选用了 Druid 来做数据存储, 以 OLAP 的方式来做数据分析, Druid.io(以下简称 Druid) 是面向海量数据的, 用于实时查询与分析的 OLAP 存储系统. Druid 的四大关键特性总结如下:
1), 亚秒级的 OLAP 查询分析, Druid 采用了列式存储, 倒排索引, 位图索引等关键技术, 能够在亚秒级别内完成海量数据的过滤, 聚合以及多维分析等操作.
2), 实时流数据分析, 区别于传统分析型数据库采用的批量导入数据进行分析的方式, Druid 提供了实时流数据分析, 采用 LSM(Long structure merge)-Tree 结构使 Druid 拥有极高的实时写入性能; 同时实现了实时数据在亚秒级内的可视化.
3), 丰富的数据分析功能. 针对不同用户群体, Druid 提供了友好的可视化界面, 类 SQL 查询语言以及 REST 查询接口
4), 高可用性与高可拓展性. Druid 采用分布式, SN(share-nothing) 架构, 管理类节点可配置 HA, 工作节点功能单一, 不相互依赖, 这些特性都使得 Druid 集群在管理, 容错, 灾备, 扩容等方面变得十分简单.
关于 druid 的介绍, 可以参考 https://www.jianshu.com/p/0a614455a964 这篇文章.
1, 在页面中, 我们用采集插件做了数据埋点采集, 数据采集通过数据采集服务丢入到 kafka 中.
2, 我们在 druid 中设计了两张表, 数据的粒度精确到分钟时间段, 也就是有分钟表和小时表两张. 分钟表数据量可能会比较大, 所以我们只会保留 1 个月内的分钟表数据, 小时表的数据会长期保存.
3, 在 kafka 中, 我们创建了两个消费组, 一个用于小时消费处理, 一个用于分钟消费处理.
4, 在平台设计时, 每张 banner 图都有一个唯一的 bannerId 和 url, 在数据聚合处理操作时, bannerId 就成了唯一的标志, 按照 bannerId 进行分钟级的聚合处理和小时级的聚合处理.
5, 小时级的聚合处理也可以考虑使用 hive, 处理的方案如下, 由于分钟表的数据会保存 1 个月, 所以 1 个月内的查询其实都是直接查询分钟表, 1 个月以外的数据才会查询小时表. 所以尽管此种方案可能会存在数据采集延迟的情况, 但是也不会延迟 1 个月之久, 所以可以通过定时任务来处理, 定时任务可以在第二天处理前一天的数据.
6, 数据报表在查询时, 就可以按照 1 个月以内查询分钟表, 1 个月以外的查询小时表.
上面讲的工作台中数据分析的场景, 另外我们还有接口合成 banner 图的数据也是需要分析. 在第二轮迭代时, 接口请求合成的 banner 图的结果数据我们同时入了 hbase 和 MySQL 两张表, 上文中已经说过入 hbase 中的数据是供用户做接口合成结果查询的. 入 MySQL 中当时是准备用作数据分析的 (因为第二轮时, 调用量还不够大, 所以那个时候还未采用大数据方案), 如下图
在第三轮的接口迭代中, 我们将架构进行了优化, 以适应每天千万级的接口合成调用, 不然 MySQL 数据库会成为最终的瓶颈, 如下图
我们将入 MySQL 的那份数据改成写到 kafka 中, 然后 kafka 的数据可以做实时分析, 也可以将 kafka 的数据进入到 hive 中做离线分析.
来源: https://www.cnblogs.com/laoqing/p/11327403.html