实时计算应用及技术选型

1. 实时计算在公司的用处

公司内已经采用 MR 与 spark 之类的技术，做离线计算，为什么用实时计算？

• 离线的伤痛就是数据出的太慢

• 有对实时数据要求高的场景

实时计算技术选型

Spark streaming、 Struct streaming、Storm、JStorm（阿里）、Kafka Streaming、Flink 技术栈这么多，到底选哪个？

• 公司员工的技术基础

• 流行

• 技术复用

• 场景

如果对延迟要求不高的情况下，可以使用 Spark Streaming，它拥有丰富的高级 API，使用简单，并且 Spark 生态也比较成熟，吞吐量大，部署简单，社区活跃度较高，从 GitHub 的 star 数量也可以看得出来现在公司用 Spark 还是居多的，并且在新版本还引入了 Structured Streaming，这也会让 Spark 的体系更加完善。

如果对延迟性要求非常高的话，可以使用当下最火的流处理框架 Flink，采用原生的流处理系统，保证了低延迟性，在 API 和容错性方面做的也比较完善，使用和部署相对来说也是比较简单的，加上国内阿里贡献的 Blink，相信接下来 Flink 的功能将会更加完善，发展也会更加好，社区问题的响应速度也是非常快的，另外还有专门的钉钉大群和中文列表供大家提问，每周还会有专家进行直播讲解和答疑。

2. 项目实施环境

2.1 数据

• 目前已经存在订单数据，业务系统会将订单写入到 mysql

• 流量日志数据（访问日志）

2.2 硬件

• 4 台物理服务器

• 服务配置

2.3 人员

• 4 人

2.4 时间

• 一个月左右

• 阶段

3. 需求分析

3.1 项目需求

• 目前已经有前端可视化项目，公司需要大屏用于展示订单数据与用户访问数据

3.2 数据来源

3.2.1 PV/UV 数据来源

• 来自于页面埋点数据，将用户访问数据发送到 web 服务器

• web 服务器直接将该部分数据写入到 kafka 的 click_log topic 中

3.2.2 销售金额与订单量数据来源

• 订单数据来源于 mysql

• 订单数据来自 binlog 日志，通过 canal 实时将数据写入到 kafka 的 order 的 topic 中

4. 常见的软件工程模型

4.1 瀑布模型

• 在一些银行、政府、等传统行业系统中，该模式应用较多

特点

1. 上一项开发活动其成果作为本次活动的输入

2. 给出本次活动的工作成果，作为输出传给下一项开发活动

3. 对本次活动的实施工作成果进行评审

使用范围

1. 用户需求很清楚，在开发过程中变化较少

2. 开发人员对业务很熟悉

3. 用户的使用环境较稳定；

4. 开发工作对用户参与的要求很低。

优点

1. 人员职责明确、具体，有利于大型软件开发过程中人员的组织、管理

2. 实施步骤清晰、有序，有利于软件开发方法和工具的研究，保障大型项目质量/效率

缺点

1. 开发过程一般不能逆转，否则代价太大

2. 实际的项目开发很难严格按该模型进行

3. 客户很难清楚地给出所有的需求

4. 软件实际情况必须到项目开发的后期才能看到，这要求客户有足够的耐心

4.2 原型

• 优点

• 缺点

4.3 敏捷开发

介绍

• 以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发

• 把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成

• 在开发过程中软件一直处于可使用状态

优点

• 敏捷确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品

• 注重市场快速反应能力，也即具体应对能力，客户前期满意度高

缺点

• 敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累

• 需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题

5. 实现方案

5.1 JAVA 方式实现

• 一些中小企业当中，由于数据量较小（比如核心总量小于 20 万条），可通过 Java 程序定时查询 mysql 实现

• 比较简单，但是粗暴实用

• 仅仅需要对 mysql 做一些优化即可，比如增加索引、分库分表、读写分离

5.2 通过 flink 方案实现

• 数据量特别大、无法直接通过 mysql 查询完成，有时候根本查询不动

• 要求实时性高，比如阿里巴巴双十一监控大屏，要求延迟不超过 1 秒

5.3 实时数仓项目架构