.jpeg)
2014年，马云提出，“人类正从IT时代走向DT时代”。如果说在IT时代是以自我控制、自我管理为主，那么到了DT (Data Technology)时代，则是以服务大众、激发生产力为主。以互联网(或者物联网)、云计算、大数据和人工智能为代表的新技术革命正在渗透至各行各业，悄悄地改变着我们的生活。
在DT时代，人们比以往任何时候更能收集到更丰富的数据。IDC的报告显示：预计到2020年，全球数据总量将超过40ZB (相当于40万亿GB)，这一数据量是2011年的22倍!正在呈“爆炸式”增长的数据，其潜在的巨大价值有待发掘。数据作为一种新的能源，正在发生聚变，变革着我们的生产和生活，催生了当下大数据行业发展热火朝天的盛景。
但是如果不能对这些数据进行有序、有结构地分类组织和存储，如果不能有效利用并发掘它，继而产生价值，那么它同时也成为一场“灾难”。无序、无结构的数据犹如堆积如山的垃圾，给企业带来的是令人昨舌的高额成本。
同时，日益丰富的业态，也带来了各种各样、纷繁复杂的数据需求。如何有效地满足来自员工、客户和企业管理自身的多样化数据需求，提高他们对数据使用的满意度，是数据服务和数据产品需要面对的挑战。
如何建设高效的数据模型和体系，使数据易用，避免重复建设和数据不一致，保证数据的规范性；如何有效管理和控制日益增长的存储和计算消耗；如何保证数据服务的稳定，保证其性能；如何设计有效的数据产品高效赋能于外部客户和内部员工，这些给大数据系统的建设提出了更多复杂的要求。
企业组织在经历多年的信息化建设后，散落于各异构系统的数据每天都在增加，随着移动互联网、物联网的蓬勃发展，采集数据的渠道和设备越来越多，数据采集作为大数据系统体系的第一环尤为重要。因此三点一四建立了一套标准的数据采集体系方案，致力全面、高性能、规范地完成海量数据的采集、并将其传输到大数据平台。
腾空数据采集系统的日志采集体系方案包括两大体系：在线采集和离线采集。在线采集是指Web端日志采集、App端日志采集、小程序日志采集、H5日志采集、HTTP API日志采集方案。离线采集是指服务器日志采集、文本数据采集、数据库同步方案。
本文对Web端日志采集、App端日志采集两个方面的技术方案详细说明。
腾空采集系统
腾空数据采集系统是三点一四推出的大数据采集系统级产品。腾空使命是为中小型企业用户提供数据采集、传输、清洗、计算等数据上云一站式端到端的综合解决方案。
腾空采集系统以助力企业全面触网，实现智能化数据决策为使命，提供DT时代的大数据基础服务。
- 通过实时/离线数据采集，快速构建数据仓库和数据中心，帮助中小企业低成本实现数据创新和数据决策。
- 中小企业构建PB级数据仓库，实现异构环境大规模数据集成，对数据进行资产化管理。
- 智能化的监控，保障数据安全和稳定。
采集方案
1. Web端日志采集
Web网站产品日志采集可以分为两大类：
（1）页面浏览日志采集。顾名思义，页面浏览日志是指当一个页面被浏览器加载呈现时采集的日志。此类日志是最基础的互联网日志，也是目前所有互联网产品的两大基本指标：页面浏览量（Page View，PV）和访客数（UniqueVisitors，UV）的统计基础。页面浏览日志是目前成熟度和完备度最高，同时也是最具挑战性的日志采集任务，我们将重点讲述此类日志的采集。
（2）页面交互日志采集。当页面加载和渲染完成之后，用户可以在页面上执行各类操作。随着互联网前端技术的不断发展，用户可以浏览器内与网页进行的互动已经丰富到只有想不到没有做不到的程度，互动设计都要求采集用户的互动行为数据，以便通过量化获知用户的兴趣点或者体验优化点。交互日志采集就是为此类业务场景而生的。
1.1 页面浏览日志采集流程
网站页面是互联网服务的基本载体，即使在如今传统互联网形态逐渐让位于移动互联网的背景下，HTML页面依旧是最普遍的业务形态，对于以网页为基本展现形式的互联网产品和服务，衡量其业务水平的基本指标是网页浏览量（PV）和访客数（UV）。为此，我们需要采集页面被浏览加载展现的记录，这是最原始的互联网日志采集需求，也是一切互联网数据分析得改展开的基础和前提。
目前典型的网页访问过程是以浏览器器请求、服务器响应并返回所请求的内容这种模式进行的，浏览器和服务器之间的通信普遍遵守HTTP协议。浏览器发起的请求被称为HTTP请求，服务器的返回则被称为HTTP响应。
我们以访问百度首页（www.baidu.com）为例，一次典型的页面访问过程描述如下图所示。
一次网页请求过程
（1）用户在浏览器内点击百度首页（或在地址栏中输入www.baidu.com并回车）。
（2）浏览器向百度服务器发起HTTP请求。按照HTTP协议，一个标准的HTTP请求由三个部分组成。
- 请求行——包括请求方法、所请求资源的URL以及HTTP协议版本号。
- 请求报头——请求报头是浏览器在请求时服务器提交的附加信息。
- 请求正文——这一部分是可选的，一般HTTP请求的正文都是空的，可以忽略。
（3）服务器接收并解析请求。服务器端的业务处理模块按业务逻辑处理本次请求并按照HTTP协议规定的格式，将处理结果以HTTP响应形式发回浏览器。与HTTP请求相对应，一个标准的HTTP响应也由三部分构成。
- 状态行——状态行标识了服务器对于此次HTTP请求的处理结果。如代表成功响应的200和代表所请求的资源在服务器端没有找到的404。
- 响应报头——服务器在执行响应时，同样可以附加一些数据项，这些数据项将在浏览器端被读取和使用。
- 响应正文——和请求正文一样，这一部分在协议中也被定义为可选部分，但对于大多数HTTP响应而言，这一部分都是非空的，浏览器请求的文档、图片、脚本等，其实就是被包装在正文内返回浏览器的。
（4）浏览器接收到服务器的响应内容，并将其按照文档规范展现给用户，从而完成一一次请求。
上面描述了一次典型的网页浏览过程，如果需要记录这次浏览行为，则采集日志的动作必然是附加在上述四个步骤中的某一环节内完成的。在第一步和第二步，用户的请求尚未抵达服务器，而直到第三步完成，我们也只能认为服务器处理了请求，不能保证浏览器能够正确地解析和渲染页面，尚不能确保用户已确实打开页面，因此在前三步是无法采集用户的浏览日志的。那么采集日志的动作，需要在第四步，也就是浏览器开始解析文档时才能进行。根据前文所述，可以很自然地得出在这一模式下最直接的日志采集思路：在HTML文档内的适当位置增加一个日志采集节点，当浏览器解析到这个节点时，将自动触发一个特定的HTTP请求到日志采集服务器。如此一来，当日志采集服务器接收到这个请求时，就可以确定浏览器已经成功地接收和打开了页面。这就是目前几乎所有互联网网站页面浏览日志采集的基本原理，而业界的各类网页日志采集的解决方案只是在实施的细节、自动采集内容的广度以及部署的便利性上有所不同。
目前腾空采用的页面浏览日志采集方案的流程框架如下图所示。
页面浏览日志采集方案流程框架
在上图所示的页面浏览日志采集过程中，所涉及的日志相关的几个主要过程简单介绍如下:
（1）客户端日志采集。日志采集工作一般由一小段被植人页面HTML文档内的Javascript脚本来执行。采集脚本被浏览器加载解析后执行，在执行时采集当前页面参数、浏览行为的上下文信息以及一些运行环境信息。在HTML文档内植人日志采集脚本的动作可以由业务服务器在响应业务请求时动态执行，也可以在开发页面时由开发人员手动植入。在腾空中，这两种方式均有采用，其中前一种方式的占比较高，这一点与业界的普遍状况有所不同。上图中的第三、四步描述了腾空业务服务器端植入日志采集脚本的过程。
（2）客户端日志发送。采集脚本执行时，会向日志服务器发起一个日志请求，以将采集到的数据发送到日志服务器。在大多数情况下，采集完成之后会立即执行发送；但在个别场景下，日志采集之后可能会经过一段时间的延迟才被发出。日志采集和发送模块一般会集成在同一个JavaScript脚本文件内，且通过互联网浏览器必然支持的HTTP协议与日志服务器通信，采集到的日志信息一般以URL参数形式放在HTTP日志请求的请求行内。
（3）服务器端日志收集。日志服务器接收到客户端发来的日志请求后，一般会立即向浏览器发回一个请求成功的响应，以免对页面的正常加载造成影响;同时，日志服务器的日志收集模块会将日志请求内容写人一个日志缓冲区内，完成此条浏览日志的收集。
（4）服务器端日志解析存档。服务器接收到的浏览日志进入缓冲区后，会被一段专门的日志处理程序顺序读出并按照约定的日志处理逻辑解析。由日志采集脚本记录在日志请求行内的参数，将在这个环节被解析（有时候伴随着转义和解码）出来，转存人标准的日志文件中并注人实时消息通道内供其他后端程序读取和进一-步加工处理。
经过采集——发送——收集——解析存档四个步骤，我们将一次页面浏览日志成功地记录下来。可见，除了采集代码在某些场合下需要手动的人之外，整个过程基本都是依照HTML规范和HTTP协议自动进行的，这种依赖协议和规范自动运行的采集机制最大限度地减少了人工干预的扰动，进而保证了日志的准确性。
腾空的页面浏览日志采集框架，不仅指定了上述的采集技术方案，同时也规定了PV日志的采集标准规范，其中规定了PV日志应采集和可采集的数据项，并对数据格式做了规定。这些格式化日志，为后续的日志加工和计算得以顺利开展打下了基础。
1.2 页面交互日志采集流程
PV日志的采集解决了页面流量和流量来源统计的问题，但随着互联网业务的发展，仅了解用户到访过的页面和访问路径，已经远远不能满足用户细分研究的需求。在很多场合下，需要了解用户在访问某个页 满足用户细分研究的需求。在很多场合下， 人焦点的 移动变化(代表用户面时具体的互动行为特征，比如鼠标或输入焦点的移动变化、对某些页面交互的反应等。因为这些行为往往并不触发浏览器加载新页面，所以无法通过常规的PV日志采集方法来收集。
因为终端类型、页面内容、交互方式和用 户实际行为的千变万化不可预估，交互日志的采集和PV日志的采集不同，无法规定统一的采集内容。例如，活动页面的游戏交互和购物车页面的功能交互两者相比，所需记录的行为类型、行为数据以及数据的结构化程度都截然不同，呈现出高度自定义的业务特征。与之相适应，在腾空的日志采集实践中，交互日志的采集是以技术服务的形式呈现的。
具体而言，交互日志采集是一个开放的基于HTTP协议的日志服务，需要采集交互日志的业务，经过如下步骤即可将自助采集的交互日志发送到日志服务器。
（1）业务方在交互日志采集的元数据管理界面依次注册需要采集交互日志的业务，具体的业务场景以及场景下的具体交互采集点，在注册完成之后，系统将生成与之对应的交互日志采集代码模板。
（2）业务方将交互日志采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定。
（3）当用户在页面上产生指定行为时，采集代码和正常的业务互动响应代码一起被触发和执行。
（4）采集代码在采集动作完成后将对应的日志通过HTTP协议发送到日志服务器，日志服务器接收到日志后，对于保存在HTTP请求参数部分的自定义数据，即用户上传的数据，原则上不做解析处理，只做简单的转储。
经过上述步骤采集到的日志服务器的业务随后可被业务方按需自行解析处理，并可与正常的PV日志做关联运算。
2. App端日志采集
众所周知，日志采集多是为了进行后续的数据分析。移动端的数据采集，一是为了服务于开发者，协助开发者分析各类设备信息；二是为了帮助各APP更好地了解自己的用户，了解用户在APP上的各类行为，帮助各应用不断进行优化，提升用户体验。
无线客户端的日志采集采用采集SDK来完成，在三点一四腾空系统中，多使用名为TengKong的SDK来进行无线客户端的日志采集。无线客户端的日志采集和浏览器的日志采集方式有所不同，移动端的日志采集根据不同的用户行为分成不同的事件，“事件”为无线客户端日志行为的最小单位。基于常规的分析，TengKong（TK）把事件分成了几类，常用的包括页面事件（同前述的页面浏览）和控件点击事件（同前述的页面交互）等。
对事件进行分类的原因，除了不同事件的日志触发时机、日志内容和实现方式有差异之外，另一方面是为了更好地完成数据分析。在常见的业务分析中，往往较多地涉及某类事件，而非全部事件；故为了降低后续处理的复杂性，对事件进行分类尤为重要。要更好地进行日志数据分析，涉及很多方面的内容，如需要处理Hybrid应用，实现H5和Native日志的统一；又如识别设备，保证同一设备上各应用获取到的设备信息是唯一的。除此之外，对于采集到的数据如何上传，以及后续又如何合理处理等，每个过程都值得我们进行深入的研究和探索。
2.1 页面事件
从实现方法上说，日志采集SDK对于不同事件的实现，大致是类似的；只是对于通用的用户行为，抽象出来一些通用的接口方法。我们把常用的行为类别单独列出来，作为单独的事件来处理，如本节要讲的页面事件（页面浏览行为）。每条页面事件日志记录三类信息：①设备及用户的基本信息；②被访问页面的信息，这里主要是一些业务参数（如商品详情页的商品ID、所属的店铺等）；③访问基本路径（如页面来源、来源的来源等），用于还原用户完整的访问行为。
对于页面事件，不同的SDK有不同的实现，有些采集SDK选择在页面创建时即发送日志。结合业务分析，TK提供了页面事件的无痕埋点，即无须开发者进行任何编码即可实现。本处主要讲一下手动模式的埋点。TK提供了两个接口，分别在页面展现和页面退出时调用。当进入App页面时，调用页面展现的接口，该接口会记录页面进人时的一些状态信息，但此时不发送日志，当从该页面离开时，调用页面退出的接口，该接口会发送日志。除了基础的两个接口外，还提供了添加页面扩展信息的接口；在页面离开前，使用该接口提供的方法给页面添加相关参数。
显然，上述三个接口方法必须配合使用，即页面展现和页面退出方法必须成对使用，而页面扩展信息的接口必须在使用页面展现和页面退出方法的前提下使用。再来说说，为什么不在页面进人时就发送日志，而是在页面离开时才发送日志呢？可以思考一下：基于浏览器的日志采集，在每次页面进人时就实现采集日志的发送，每个页面停留时长的计算一直困扰着分析师；而无线客户端的日志采集，在页面离开时发送日志，此时页面停留时长就是天然自带的准确值了。
上述三个方法是采集SDK提供的页面事件采集的基础方法；除此之外，为了平衡采集、计算和分析的成本，在部分场景下我们选择采集更多的信息来减少计算及分析的成本。于是，TK提供了透传参数功能。所谓透传参数，即把当前页面的某些信息，传递到下一个页面甚至下下一个页面的日志中。举个例子，在手机商城类App，先搜索“篮球鞋”，然后点从返回的列表中点击某个商品进入详情页。如果需要分析“篮球鞋”这个关键词的来源搜索词，此时就需要把“篮球鞋”这个关键词带入到搜索列表页面日志、商品详情页日志中，这样一来，分析搜索词的效果就显而易见了。
2.2 控件点击及其他事件
为了和基于浏览器客户端的日志采集做比较，我们暂且把除了页面事件外的各类事件放到一起来说明。
和浏览器客户端的日志采集一样，交互日志的采集无法规定统一的采集内容，交互类的行为呈现出高度自定义的业务特征。与之相适应，在腾空采集系统的实践中，将交互日志采集从页面事件采集中剥离出来，这就是控件点击事件和其他事件。
先来说说控件点击事件。控件点击事件比页面事件要简单得多，首先，它和页面事件一样，记录了基本的设备信息、用户信息；其次，它记录了控件所在页面名称、控件名称、控件的业务参数等。由于控件点击事件的逻辑简单得多，就是操作页面上的某个控件，因此只需把相关基础信息告诉采集SDK即可。
再来说说其他事件。所谓其他事件，就是用户可以根据业务场景需求，使用自定义事件来采集相关信息。从某种程度上说，它几乎能满足用户的所有需求，包括页面事件和控件点击事件，只是若采用通用的页面事件埋点方法，TK会帮助实现一些额外的功能（如上个页面的信息）。TK提供了一个自定义埋点类，其包括：
1. 事件名称；
2. 事件时长；
3. 事件所携带的属性；
4. 事件对应的页面。
当然，具体实现什么功能，需要带哪些内容，各个采集SDK可以自行决定。
除了上述这些需要应用开发者触发的日志采集接口方法外，TK还提供了一些默认的日志采集方法，比如可以自动捕获应用崩溃，并且产生一条日志记录崩溃相关信息。类似的日志采集方法还有很多，比如应用的退出、页面的前后台切换等。诸如一些和业务信息不是非常相关，但又对分析起很大作用的日志采集，就完全没有必要让应用开发者去触发埋点了。
2.3 特殊场景
上述场景均为一个行为产生一条日志，如一次浏览、一次点击等。如此用来处理普通的业务是足够的，但对于某些场景下巨大的业务体量来说，为了平衡日志大小，减小流量消耗、采集服务器压力、网络传输压力等，采集SDK提供了聚合功能，对某些场景如曝光或一些性能技术类日志，我们提倡在客户端对这类日志进行适当聚合，以减少对日志采集服务器端的请求，适当减小日志大小。总体思路就是每个曝光的元素一般都属于一个面面，利用页面的生命周期来实现适当的聚合及确定发送时机。拿曝光日志来举例，若一个商品的一次曝光就对应一条日志的话，那么在搜索结果页的一次滚屏浏览过程中将产生几十条甚至上百条日志，从下游使用及分析的角度来说，其实只是想知道哪些内容被曝光，此时为了平衡业务需求及减少全链路资源消耗，采集SDK提供了本地聚合功能，在客户端对这类日志进行聚合，上传聚合后的日志到采集服务器即可。同时对于一些只需要计数，而不需要知道具体内容的场景，如需要分析某些接口的调用次数，此功能就更加凸显出其作用了。
区别于浏览器的页面访问，在无线客户端用户的访问行为路径存在明显的回退行为（如点击回退按钮、各种滑屏等），在进行业务分析时，回退同样作为特殊场景而存在。例如，在商城首页——女装分类——女装店铺A——回退到女装分类——女装店铺B。在这个访问路径中，若只是按照普通的路径来处理，则会认为第二次浏览的女装分类来源为店铺A，就会把女装分类的一次浏览效果记为女装店铺A带来的。
倘若这样处理，就会发现类似的活动承接页其来源有一大部分均为各类详情页（店铺详情页/商品详情页），这必然干扰到分析。所以针对这种场景，我们做了特殊的设计，利用页面的生命周期，识别页面的复用，配合栈的深度来识别是否是回退行为。
2.4 H5&Native日志统一
简单来说，APP分为两种:一种是纯Native APP；一种是既有Native，又有H5页面嵌人的APP，即HybridAPP。当前，纯NativeAPP已经非常少了，一般都是Hybrid APP。Native 页面采用采集SDK进行日志采集，H5页面一般采用基于浏览器的页面日志采集方式进行采集。在当前的实践中，由于采集方式的不同，采集到的内容及采集服务器均分离开。若需要进行完整的数据分析，就需要将两类日志在数据处理时进行关联，而就算不考虑处理成本，在很多情况下，Native和H5互跳，即使关联也无法还原用户路径，数据丢失严重。对于产品经理以及运营、管理、数据分析人员而言，在不同的终端采用不同的方案采集日志，以不同的算法来做日志统计，忍受多端之间的数据隔离，并对由此导致的多样数据口径进行整理分析和解释，已经是越来越不能容忍的切身之痛。考虑到后续日志数据处理的便捷性、计算成本、数据的合理性及准确性，我们需要对Native和H5日志进行统一处理。
要想实现Native和H5日志的统一处理，就需要对Hybrid 日志有统一的方案。简单的思路就是首先将两类日志进行归一。用什么方式把两类日志归一呢？是把Native日志向H5日志归，还是把H5日志归到Native日志呢？其实两条路均可以实现，没有绝对的答案。选择时可以自行斟酌，在腾空系统中，分别考虑两条路的优缺点，考虑到两种日志采集方式的特点以及关注点，我们选择Native部署采集SDK的方式。
原因有二：一是采用采集SDK可以采集到更多的设备相关数据，这在移动端的数据分析中尤为重要；二是采集SDK处理日志，会先在本地缓存，而后借机上传，在网络状况不佳时延迟上报，保证数据不丢失。基于这两点，我们选择将H5日志归到Native日志。
具体的流程如下：
（1）H5页面浏览和页面交互的数据，在执行时通过加载日志采集的JavaScript脚本，采集当前页面参数，包括浏览行为的上下文信息以及一些运行环境信息。在APP中打开H5页面和在浏览器中的处理完全一样，在前端页面的开发中无须做任何特殊的处理，只需在页面开发时手动植人日志采集的JavaScript脚本即可。
（2）在浏览器日志采集的JavaScript脚本中实现将所采集的数据打包到一个对象中，然后调用WebView框架的JSBridge接口，调用移动客户端对应的接口方法，将埋点数据对象当作参数传入。
（3）移动客户端日志采集SDK，封装提供接口，实现将传入的内容转换成移动客户端日志格式。采集SDK会根据日志类别来识别是页面浏览事件，还是控件点击事件，然后调用内部相应的接口进行处理，将埋点数据转换成移动客户端日志的统一格式。而后就同移动客户端的日志处理一样，先记录到本地日志缓存中，择机上传。通过日志类别的识别来做不同的日志格式转换，这样，未来如果要实现新的事件类别，比如自定义事件，就不需要改动WebView层的接口，只需改动JavaScript的部分内容及移动客户端日志采集SDK中对应的实现即可。
基于这种统一的方案，为后续构建完整的用户行为路径还原树打下了基础。当然，此方案也有其局限性，必须要浏览器采集JavaScript、WebView、客户端采集SDK的配合。而往往很多时候业务并不希望做任何调整，更多的是希望减少依赖，所以在这方面我们需要寻求新的突破。
2.5 设备标识
所有互联网产品的两大基本指标是页面浏览量（Page View，PV）和访客数（Unique Visitors，UV）。关于UV，对于登录用户，可以使用用户ID来进行唯一标识，但是很多日志行为并不要求用户登录，这就导致在很多情况下采集上来的日志都没有用户ID。PC端般使用Cookie信息来作为设备的唯一信息，对于APP来说，我们就要想办法获取到能够唯一标识 设备的信息。
历史上，MEI、IMSI、MAC、苹果禁用之前的UDID, 曾经都可以用，如果它们之中有一个是靠谱的话，那么设备唯一标识就简单了。但事实上，随着用户的自我保护意识加强以及各系统升级，很多基本的设备信息获取都不再那么容易。苹果UDID禁用，IDFA、IMEI、 IMSI做了权限控制，Android新系统也对设备信息的获取做了权限控制。
对于只有单APP的公司来说，设备唯标识不是需要攻克的难题，但对于拥有众多APP的公司来说，设备唯一标识就显得尤为重要。
腾空系统使用基于Open UUID方案的TKUID唯一标识设备。
2.6 日志传输
在上面的章节中大概讲述了如何从无线客户端采集日志，本节将简单介绍一下无线客户端日志的上传、压缩及传输的特殊性。
无线客户端日志的上传，不是产生一条日志上传一条，而是无线客户端产生日志后，先存储在客户端本地，然后再伺机上传。所谓伺机，就需要有数据分析的支持，如在启动后、使用过程中、切换到后台时这些场景下分别多久触发一次上传动作。当然单纯地靠间隔时间来决定上传动作是不够的，还需要考虑日志的大小及合理性（如单条日志超大，很可能就是错误日志）。另外，还需要考虑上传时网络的耗时，来决定是否要调整上传机制。
客户端数据上传时是向服务器发送POST请求，服务器端处理上传请求，对请求进行相关校验，将数据追加到本地文件中进行存储，存储方式使用Nginx 的access_ log, access _log的切分维度为天，即当天接收的日志存储到当天的日志文件中。考虑到后续的数据处理，以及特殊时期不同日志的保障级别，还对日志进行了分流。比如腾空系统的TKProcessor（无线日志服务器端处理程序），根据应用及事件类型对每日高达数亿的日志进行了分流。分流的好处显而易见，高并发访问时，日常数亿的日志可能冲高到数十亿，此时服务器及后续的数据计算压力就非常大了；而对于重要的数据计算来说，很可能只需要页面事件及控件点击事件即可，此时就可以适当地释放其他类型日志的资源来处理更重要的页面事件及控件点击事件。
从客户端用户行为，到日志采集服务器的日志，整个日志采集的过程就结束了。
那么日志采集服务器的日志怎么给到下游呢？方法有很多，腾空系统主要使用消息队列来实现从日志采集服务器到数据计算的。简单来讲，就是消息队列服务部署到日志采集服务器上进行消息的收集，而后续的应用可以是实时的应用实时来订阅消息队列收集到的消息，进行实时计算，也可以是离线的应用定时来获取消息，完成离线的计算。
图片来源于站酷海洛
本文有部分内容参考节选自阿里巴巴《大数据之路》一书。