彩票走势图

随着企业安全边界的扩大化模糊化、各类威胁新出速度越来越快、影响越来越广，视企业安全边界为静态、仍然依赖各种特征码技术的传统安全思路早已落后，无法实际解决安全问题。必须通过各种创新，整合、人工智能、可视化等领域的最新技术进展，安全产品才能解决目前和将来的企业安全难题。

但如何选择并整合各种技术是复杂系统工程，比常规企业安全软件开发需要考虑更多因素。本次分享中对大数据、、可视化的最新进展和应用案例做个总结，重点讨论大数据平台云部署运维、交互批处理与实时流处理的关系、有监督学习解决的安全问题和大数据可视化这四个细分领域。

以下：

大家晚上好，感谢大家参与这次分享！我们成立于三年前，按行业划分是一家安全公司。但和大家熟知的卖杀毒软件的传统安全公司很不一样，瀚思帮助各种中大型企业搭建安全大数据的分析平台，在平台上实时运行各种机器学习算法的安全分析策略，最终帮助企业定位各种安全问题。所以我们自认为也是一家大数据 +AI 公司。

我们常被人问到，为什么要选择这个“大数据 +AI+ 安全”这个对工程能力要求很高的混搭方向呢？

第一，当然是因为看好这个方向，我们认为这个方向是网络安全领域发展的大趋势。这个趋势虽然今天说起来显而易见，毕竟现在所有的新旧安全厂商都说自己有 AI 能力，但三年前，安全界大部分人都不清楚 AI 能具体解决哪些安全问题，套用 AI 界的热门话题词，也就是常说的不清楚“AI 怎么落地”，整个安全界也是在这几年内摸索前进才有了些共识。

那第二的原因更直接，那就是，我们以前做过这个方向，有信心有能力在这个方向上，比别的其他厂家做得更好。从 2004 年开始，我们就用 SVM 算法对病毒样本分类，然后在 Hadoop 刚兴起不久的 2008 年就开始基于 Hadoop 和 HBase 搭建大规模互联网网站安全分析平台。所以这个主题月的几个分享的议题也是结合大数据 +AI 落地上这几年的一些经验，和大家探讨下整个平台搭建成功的关键因素。

关于本月技术分享

考虑到大多数人都是对 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 是批处理的标配

在我看来有三点：

• 功能没有特别短板，能覆盖各种通用场景：交互 SQL、流计算、算法迭代、图计算。新的非开源版号称同时在 Amazon S3 上支持 OLAP + OLTP；图中就是 DataBricks 公布的大一统数据平台架构。
• SQL（SQL-92） 的兼容支持度；
• 公司／社区运营得非常好，看 Spark 支持多少种开发语言就知道，而且工程能力超强，新版本开发各种功能速度都很快。以前流处理受限于 micro-batch 架构，功能简单，时延大于 1 秒，受到 Flink 和 Storm 等阵营的冲击，很快就推出了号称吞吐量和时延都比 Flink 优良几倍，不过还没正式发布的的持续结构化流计算。

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

流处理平台的选择

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

• 市场出现时间很短，第一个开源版知名的流处理平台 Storm 2011 年才出来。
• 需求变化大，目前主要的高性能需求推动力来自物联网平台，对性能要求远超出一般企业的流处理需求，而这个潜在市场又出奇地大，导致将来流平台会往这市场倾斜，优先考虑性能。
• 不像交互式 SQL 分析，流处理很少是独立的一个使用场景，用户期望和批处理一体化，也就是统一分析平台。

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 基础流处理功能没问题，API 不如 Flink 那么完备，复杂功能需要额外开发，延迟和吞吐量仍然比 Flink 差，性能真要超过 Flink 估计得等 抛弃 microbatch 的 continuous processing 技术正式发布。另外有些限制，比如不能聚合后再聚合，直接不符合我们现在的业务场景。所以我们还是使用 Flink。后续分享会讨论技术细节。

Spark 作为算法分析／AI 平台

Gartner 2017 对各厂家的数据科学平台统计发现基本所有平台都原生支持 Spark。除了 Spark MLlib 本身底层 API 丰富，原生包含 ETL 库、分类、聚类、协同过滤、模型评测等算法外，和额外花大力气对算法工程师常用的 Python 和 R 做好支持分不开。虽然有天生架构缺陷，算子组合不能有环，算法常见必需的迭代机制要通过比如 P2P broadcast 机制来实现。Flink 虽然考虑了迭代场景，但因为工程实现，我们实际测试中总体而言不如 Spark。两者对于一般算法性能都可以，但复杂算法下，明显受限于迭代机制的同步／通讯成本、参数数量大小等，不如专有算法平台。

专有算法平台的性能优势

专门定制的平台肯定比通用平台在特别场景下有性能优势，比如 ACM DEBS Grand Challenge 流处理比赛这几年的第一名都是自行开发的流处理平台。算法平台上的优势差异更大，好几个都宣传速度高达 Spark MLlib 的百倍，当然这明显是挑场景宣传。

简单说 Spark 的主要局限在迭代和海量参数上，GPU 支持一年前已有。即使 Flink 通过把带反馈环的任务拓扑转换为有向无环图拓扑来原生支持迭代功能，但也只能支持简单迭代，做不到类似 MPI 框架的复杂迭代功能。另外机器学习中如果应用场景需要训练海量参数，而参数又大到无法放入机器内存的话，Spark 现在的参数共享机制无法工作。必须依赖第三方在 Spark 上实现的 Parameter Server。

类似 Tensorflow on Spark 这种方案，主要目的是借助 Spark API 降低编程门槛，性能或者稳定性未必胜过原生的分布式版本。比如有 Bug 把两 worker 分到一个 GPU core 上。

有监督算法 & 无监督算法

在大数据分析平台上运行的大部分算法属于有监督算法（分类等），少量属于无监督算法（聚类、或者异常检测）。常见的两类算法一般都是全量数据训练版本，并不支持增量训练。比如用户分类，输入数据得是过往 N 天所有用户的行为特征，一旦做好分类。新增了一天数据，训练得重新用 N+1 天数据开始一轮。

全量数据训练显而易见的缺陷就是慢，但对于有监督算法，可以借助前面所讲的 lambda 架构，有了 N 天数据训练后的模型，在新一天中，所有分类需求使用 N 天模型。等这天结束再开始 N+1 天数据训练出新模型。Spark 从 1.4 开始就支持工业界的 PMML 模型格式导出，模型导入可以借助第三方库比如 jpmml-spark。

无监督学习的典型应用场景，比如物联网领域、网络安全领域大量需要的异常检测，需要对算法做特殊改进以支持增量数据计算。全量计算速度跟不上，而 Lambda 架构损失实效性，两者都不适合流计算。

总结

我们快速过了遍瀚思在开发安全大数据分析平台前前后后涉及的主要技术点。重点放在各种大数据技术的来源和侧重上。因为大数据技术发展非常快，我们尽量做到技术总结符合最新发展状况。当然肯定有错误遗漏之处，非常欢迎大家指出。

简单说，我们的经验是如下几点：

• • 了解每种大数据技术的具体取舍，也就是需要了解技术发展的历史，和具体内部架构细节。
  • 具体化要支持的场景，然后才定技术选型。不要盲目照搬别人的选型方案，因为很大可能场景不同。
  • 根据非结构数据类型和读写模式来选择存储方案，因为大数据分析平台一般不需要 OLTP 交易功能。
  • 如无特殊场景需求，使用 Spark 2.x 作为通用平台。当然特殊场景有各种特殊方案，比如用 Flink 做实时数据分析，自己开发 Parameter Server 搭建推荐算法平台等等。

今天分享先到这，感谢大家！