考虑到大多数人都是对 AI 和大数据感兴趣，这次系列分享，除了病毒样本分类议题外，会特意简化安全领域的相关知识，比如不会说网站渗透是怎么做的、APT 攻击模型包含几阶段等等，而把重点放在大数据平台建设的主要技术点上，也就是和其他行业大数据平台的共性上。

但共性并不代表所有平台具体技术选型会完全一样，具体业务需求、性能方面要达到的硬指标等，直接决定哪些技术方案可行或不可行。举个极端例子，很多客户自认为的大数据平台建设需求其实是伪需求，数据并没有大到需要 NoSQL 或者 Spark，常规的 MySQL 数据库集群就足够支持客户要的全部 OLAP 场景。并不是大数据平台就一定比非大数据平台各方面都有优势。

怎么挑选最适合的大数据技术是本次分享的一个主题，因为时间限制，会忽略很多技术细节，最后的参考页我会列出更详细的参考书籍。后续分享我们会从在三个不同细分领域的具体实践方法来把这个主题梳理得更清楚。

典型的一个企业数据分析平台

大家先来看下一个典型的大数据分析平台层次架构是怎样：

1.最底下是数据收集层，典型大数据平台的数据来源多种多样，比如日志、文本、网络流、甚至视频、声音等等。除了数据量大、速度高外、这些数据的一个重要特征是非结构化，也就是不能齐整地转换成传统数据库的表。某些数据经过处理后数据可视化平台，能转成结构化形式存入常规数据库；如果实在不能结构化，就只能使用非传统数据库来存储，比如输入一句话在海量文本中查找，这种只能靠文档数据库。数据收集层会耗费系统开发非常多的精力，我们的经验是多达 30%-50%。但除非采视频这种很特别的数据，这部分相对技术难点低，而工作量巨大，脏活累活多，因为每种数据源可能对应几种采集和解析逻辑，尤其解析逻辑常常现场需要修改。很多业务系统运维人员都未必清楚目前运维日志的格式含义。

我们的经验是：先堆人力，支持好常见的数据源，然后解析模块允许使用脚本语言，现场对数据源解析方法做修改。

数据进行结构化时往往会把原始数据映射到预定义好的一组字典，比如定义好 HTTP 访问日志必须有源 IP、域名、URL 等字段，才方便顶层业务程序做通用的分析逻辑，而不是每次部署时要根据字段名改分析逻辑。对我们这种卖业务层给客户的厂家，这一步是必须的。但这种把 schema 先固定后分析的缺点也很明显，用户一旦发现 schema 错误或者有缺陷，更换成本很高。如果是临时起意的分析场景，应该尽量避免这步。比如使用 Spark SQL，临时根据一步步分析结果来定义 schema。

2.数据采集后进入存储与通用分析层，两者耦合度很高。存储层是技术选型最复杂的组件，后面会重点谈。先说分析，分析有两大类场景 – 交互式离线分析 和 实时流分析 – 实现机制截然不同，但最近也有把两个二合一的新框架趋势，比如 Apache Beam。两场景可以简单粗暴地以实时性来分：前者延迟秒级以上，后者亚秒级。分析层基本都是选用开源软件，目前看起来 Apache Spark，在 2.x 推出结构化流处理 Structured Streaming 后，有大一统趋势。

3.最上是和实践业务对应的业务应用层。大家听到的对大数据平台分析的分享往往不谈这层，因为这层和下面两层会分属于不同部门开发。但我们因为商业模式的原因，会给客户提供整个全三层的平台。我们的经验是这层常常决定整个项目的成败，因为任何系统都是给客户使用得好才能产生价值，而一般的客户是不会通过编程来使用整个平台，尤其是领导，可见的永远是可视化层。不过这次时间限制，不会具体谈可视化这个大议题。后面看是否需要专门安排瀚思的 UED 团队来分析大数据分析的专门可视化设计。

企业数据分析平台核心组件

总结下一般分析平台包含这几大组件：

数据采集组件：采集端混合多种技术，ETL 逻辑多，目前没有普遍满足需求的采集端开源实现（Elasticsearch 带的各种 Beats 算做得很好的），需要各种自行开发。采集后标配都走 Kafka 进存储组件或者处理平台。

数据存储组件：技术选型最复杂，一般采用 NoSQL 满足大数据要求。有可能混合多种 NoSQL。也可以不用数据库，直接依赖处理平台的数据持久化功能（文件、Parquet 等）。

交互批处理数据处理平台：一般都是 Spark，领先优势在扩大。

实时流数据处理平台：Spark Streaming/Structured Streaming、Storm/Heron、Flink 和新出的 Kafka Streams，其他选择少见。

基于规则 + 机器学习算法的分析层：Spark MLlib，或者追求高性能，用定制的小平台。

可视化分析呈现层：支持 Spark 上的各种 OLAP 自带的 BI 应用层，或者定制。

云部署、监控：YARN、Docker 等。或者云平台自带部署、监控功能。

设计数据（分析）平台的一般技术选择原则

真确定业务数据量大到常规数据库无法支撑，或者需要秒级实时分析，才需要开发大数据分析平台。技术选型最忌讳的是看大公司用啥就用啥，因为大数据技术目前没全面能解决所有场景的（虽然 Spark 在这个方向努力），都对目标场景互有取舍。比如 Flink 重点在流处理上，SQL 支持落后于 Spark。而 Spark MLlib 对 R 和 Python 开发的算法程序支持得好，代价是性能不如专门的分布式算法平台。更不用说一票 NoSQL 都往往对特定读写模式做优化，比如擅长 OLAP 就不能用来图分析等等。 如果没有极端场景需求，目前看来 Spark 2.x 上二次开发就能满足。当然需要额外定制开发数据采集层和可视化层。

对选型不确定，同时实在不及看各开源项目内部实行机制的话，尽快对最主要场景做性能测试帮助判断。各家自己发的性能测试报告都是挑对自己有利的场景，大数据软件一般只擅长特定一些场景，所以官方测试报告基本没参考价值。

存储组件的选择？

发这张老图不是为了恐吓有选择困难症的架构师。数据库是计算机科学内历史悠久的一个方向，加上市场需求巨大，导致有几大类各种细分方向。从初期 OLTP 场景，到 70 年代 OLAP 场景兴起，再到 2000 初因为 MPP 分布式架构不能扩展到几十台以上机器，不支持大数据场景，而诞生各种放弃传统关系型数据库 OLTP 一些约束的 NoSQL（Not Only SQL），再到大数据 OLAP、想结合传统关系型数据库 ACID 严谨性和 NoSQL 可扩展性的 NewSQL，每次转向都有很多新的设计选择，当然也有很多反复。并不总是转向后的方案就一定比原本的方案好。

SQL -> NoSQL

NoSQL 最初是为解决大数据下的扩展性问题，舍弃 CAP 中的一致性 Consistency，优先保证可用性 Availability，分区容忍性 Partition tolerance。当然实际测试很多对 P 保障完全也没有宣传地那么好。对一致性问题多采用最终一致性来延迟解决。当然最终具体怎么个一致法，不同业务逻辑有不同的做法。因为分析平台大多用 OLAP 场景，OLTP 场景下怎么做复杂 CAP 取舍和我们关系没那么大。

NoSQL 对大数据分析平台的直接影响在于支持非结构化数据支持，NoSQL 笼统可以分为 4 类：键值、文档、列存储 和 图数据库。文档和列存储数据库最为常用，键值数据库因为 API 接口比较原始形态、功能少，不常作为主力数据库。图数据库在特殊领域，比如反欺诈，有巨大的优势，但目前开源方案没有做得特别成熟的。我们自己 4 种都有用到（分别是 RocksDB、Elasticsearch、Cassandra、JanusGraph），因为安全场景特殊性，主要使用前两类。

NoSQL 阵营早期对外接口都不遵从 SQL 标准，有自己一套需要额外学习、互相之间不兼容的查询语法／API。除非自己的界面／可视化层做得完备，不方便推广给更大普通群体。

NewSQL 因为着力解决的问题，暂时和分析平台关系不大，这次跳过不谈。

数据处理基础技术演进

MapReduce 的论文发表在 2004 年，它的简单编程模型大大简化了大规模分布式数据处理的学习门槛，同时比以前复杂的分布式编程模型更容易在海量机器上运行（MPP 几十台提升到上千台）。加上又有 Google 的光环，开源版本 Hadoop 一出来后，很快成为业界大数据的标配。

但 Hadoop 并不了解 MapReduce 在 Google 内部的任务运行特点，因为 Google 是把 MapReduce 和优先级更高的上线业务分析任务跑到同样集群上，大多数任务 MapReduce 可以随时被打断抢占，Google 内部统计执行时间超过 1 小时的 MapReduce 任务，5% 的概率会被中途打断，所以 MapReduce 会有很多看起来低性能资源浪费的设计。这种不重效率的架构设计结果是企业花大价钱部署好的大 Hadoop 集群，发现十几台机器跑的 MapReduce 任务还不如一台机器上稍微做优化的普通版本完成得快，而且 MapReduce 本身的功能过于简单，企业需要在上面再封装一层才方便使用。所以到今天其实 Hadoop 的部署很多只剩下资源调度和 HDFS 在用。

具体分析 MapReduce 编程模型为何慢有很多原因，其中重要一环是企业实际都是多个 MapReduce 任务串接才能完成一个业务分析，Hadoop 对串接好的工作流并不做优化，上一个 MapReduce 的输出写到硬盘上的 HDFS，下一个 MapReduce 再从硬盘读入数据，可想而知能有多慢。所以从 Flume 开始的大数据处理框架，都有基于整个工作流的编程模型和各种优化策略。比如没在执行迭代的时候，Spark 和 Flink 的工作流模型都是各种算子组合而成的有向无环图。算子也不仅限于 map 和 reduce，而是有各种各种操作，大大方便二次开发。

根据 Databricks 的统计，大部分公司使用批处理都是为了实现交互式查询，以前是使用 SQL 从数据库数据库里查结构化数据，而且通过 Spark SQL 查放在 HDFS 或者其他各种数据来源上的结构化／非结构化数据。所以 Spark 社区一直把 SQL 作为重点投入。

流处理平台来自用户期望对数据能有更实时的分析能力，当时基于 micro-batch 的 Spark 延迟至少在 1 秒以上，而且 API 对流分析非常不友好，比如缺乏流控、复杂窗口功能。Storm 算是第一个为大众所知的流处理平台。这块最近两年开始竞争激烈，除了 Flink 外，还有 Storm 的改版 Heron ，Kafka 的功能扩展版 Kafka Streams，新版已经支持流 SQL，Apache Beam 这种源于 Google Cloud Dataflow 定位更是要支持多平台，同时统一流处理和批处理的 API。

Databricks 官方目标是构建大一统（OLAP+OLTP+ 流处理）的平台，让客户抛弃目前怪异的 lamda 架构（独立的流处理和批处理平台组合）。目前看起来进展不错。类似的大一统开源版还有 SnappyData、Splice Machine，也都是基于 Spark。

常见 批处理 + 流处理 混合架构

这种 lambda 架构是常见的方案，也是目前各种技术成熟度下的权宜之计。非实时离线计算系统操作全量数据集、实时／准实时在线系统分析源源不断新增的数据集，也就是在线系统做增量分析。业务层会把双系统对用户隐藏起来，把分析结果显得是来自一个系统，当然业务系统也经常协调双系统会有各种分析结果不一致问题。

这也是我们以前采用的模式，预计随着流计算的成熟，大部分采用 lambda 结构的都会迁移到纯流式计算上，比如 Spark 结构化流处理。

为何 Spark 是批处理的标配

在我看来有三点：

所以一般没特殊场景需求，用 Spark 2.x 是最保险的选择。

流处理平台的选择

我们又再次面对众多选择，很多绝大部分还是没听说过的。这说明流处理平台还不像批处理平台一家（Spark）独大。这有几个原因：

Spark 流处理／结构化流处理目前的局限性

Spark 1.x 流处理一直被诟病是伪流处理，不像是 Storm 或者 Flink，从一开始就为流处理设计。举个最简单的例子，1.x 连事件时间都不支持，永远使用进流处理平台的时间为准，连流处理基本功能都不满足。

新引入的结构化流虽然底层还是 microbatch，但测试延迟和吞吐量表现都优于老版。从 API 乍看起来数据可视化平台，和 spark.mllib 变成 spark.ml 一样，都是 RDD 往 DataFrame API 迁移，但底层设计理念有很多变化，Spark 想通过结构化流处理让数据分析（比如以 SQL 为媒介）不再严格区分实时在线和非实时离线，也就是抛弃前面说的 lambda 架构，对持续到来的数据做到像是查询一张持续增长的表。为实现这个目标，Spark 加了很多流处理必须的功能，比如事件时间、流控、多种事件窗口等等。不过 10 月刚发布的 Spark 2.2 中，结构化流处理才变成 production quality，所以实际质量怎样待看。

目前看起来 Spark 2 基础流处理功能没问题

来源【首席数据官】，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！