数字IT基础-数据采集总线

摘要： 日志服务是阿里自产自用的产品，在双11、双十二和新春红包期间承载阿里云/蚂蚁全站、阿里电商板块、云上几千商家数据链路，每日处理来自百万节点几十PB数据，峰值流量达到每秒百GB， 具有稳定、可靠、低成本，生态丰富等特性。

数字化运营基础

在现在“双十一”再也不是线上活动的代名词，而逐步变为一场线上线下同时进行的消费者盛宴。销售、运营、物流、生产商等都在开足马力在各大渠道备战，据统计：

• 消费者在期间被平均推送200+活动消息
• 消费者会花几个小时比较、提早筛选本身中意产品
• 除了线上外，90%线下店铺都挂出针对双十一运营活动

双十一触客渠道也呈现多样化，例如：网络店铺、短信、邮件、微信公众帐号、派单与Kitty板、自提柜、智能设备（例如天猫精灵点单）、多媒体设备（例如电视或机顶盒购物）等。

面对如此多的渠道和销售方式，运营和销售如何有效掌控，并经过数字化方式进行运营是一项硬能力。让咱们来看几个例子：

例子1：新用户引流

互联网经典书籍《上瘾：构建习惯养成的产品》把用户获取过程分为4个阶段：触发、行动、奖励、投入。做为最开始的触发环节，给用户群发消息是最有效的手段之一。但如何衡量转化效果呢？

咱们能够在推广信息中作一个埋点，把用户点击短信带上关联信息，例如设计一个以下的URL，其中放入2个关键参数：

• t: 表明发送的批次编号，也能够做为渠道的标识
• m：表明发送的短信号码

html://mywebsite.com/new?t=1002&m=13860394XX复制代码

当用户点点击消息访问站点时，咱们在服务端访问日志中会自动记录对应信息:

202.168.1.209 - - [02/Feb/2016:17:44:13+0800] "GEThtml://mywebsite.com/new?t=1002&m=13860394XX HTTP/1.1" 200 209 - "Mozilla/5.0(Macintosh; Intel Mac OS X10_11_3) AppleWebKit/537.36(KHTML, like Gecko)Chrome/48.0.2564.97 Safari/537.36"复制代码

这样咱们就能得到推广效果和转化率：

例子2：线上购买意图捕捉

在获取客户后，下一步是让用户付诸于行动。用户在浏览商品时，会有页面的停留，阅读，比较和加入购物车等操做。能够借助Web Tracking和Serve端埋点来进行静态与动态数据采集。

在静态网页和浏览器埋点：

<img src=‘http://${project}.${sls-host}/logstores/${logstore}/track_ua.gif?APIVersion=0.6.0&key1=val1&key2=val2’/> 复制代码

经过JS埋点：

varlogger = new window.Tracker('cn-hangzhou.log.aliyuncs.com','ali-test-tracking','web-tracking');
logger.push('customer','zhangsan');
logger.push('product','iphone6s');
logger.push('price',5500);
logger.logger();复制代码

在完成数据埋点后，咱们能够在日志服务分析功能中，得到每一个环节的点击数和转化数字，以衡量购买阶段的效果。

Web Tracking连接：help.aliyun.com/document_de…
服务端埋点连接：help.aliyun.com/document_de…

数据采集挑战

从上面例子来看，数据采集是数字化IT的基础。让咱们来看一个典型的数据采集架构：

1. 购买一批机器搭建网络服务器
2. 为服务器搭建负载均衡设备
3. 在网络服务器（例如Nginx）模块中使用Kafka等中间件写入数据

该方案经过无状态设计解决了高可用，按需扩容等问题，也是众多厂商采用的方案，在理想状态下运行得很是好。但在现实过程当中，每每会遇到以下挑战：

步骤	模块	挑战	成本
端	协议封装与客户端开发	须要开发众多SDK，例如Android、IOS、嵌入式等	研发成本、运维
	客户端传输	面向网络不可用	断点续传功功能
	客户端传输	传输过程当中安全问题	HTTPS协议支持与证书
	客户端升级	客户端若是有Bug如何升级	运维成本
传输	网络质量差	网络质量差	购买昂贵专线
	地域与合规	用户数据不能出国，例如欧盟等协议	在全球建各数据中心
	网络选择	运营商速度、质量不一，质量差	购买第三方加速服务
服务端	扩容	流量上涨时，如何自动扩容	购买服务器、手动运维
	防攻击	采集服务器可能被DDOS	运维服务器
	认证	进行用户认证与管理	开发负责的认证与管理模块
	数据加工	数据到服务端后，增长来源IP、服务端时间等字段	服务端开发成本
	上下游对接	对接各类流计算、离线处理系统	硬件采购、程序开发与维护

做为用户最终的目标是为了分析数据。但这些问题的存在，须要在业务、规模与增加上消耗大量人力、精力和物力，干了不必定干得好。

日志服务LogHub功能

阿里云日志服务（Log Service，/原SLS）是针对实时数据一站式服务，其中的LogHub模块就是专为数据采集定制的功能，该功能有以下特色：

1. 30+实时采集手段

LogHub提供30+种开箱即用的数据采集手段，包括直接和云产品打通的日志、移动端、服务端、程序、SDK、网页、嵌入端等，如下咱们分别介绍下最经常使用的四种与试用场景：

方式	应用场景	当前规模	优点
Logtail	X86服务器采集	百万-千万	功能强
Android/IOS SDK	移动端数据采集、手机、POS机等	千万DAU	断点续传
C Producer Library	硬件资源受限的系统（如 IoT、嵌入式、RTOS等）	千万-亿级	资源消耗低
Web Tracking	网页静态数据采集	千万-亿级	轻量级，无验证

1.1 Logtail（部署量最大Agent）

Logtail安装在X86设备上，经过中央服务器进行管控，只需点点鼠标或API就可以在几秒钟内对百万机器下达数据采集指令。Logtail目前天天有几百万的运行实例，适配全部Linux版本、Window、Docker、K8S等环境；支持几十种数据源对接，关于Logtail功能能够参见介绍文档。

得益于阿里巴巴集团场景的不断锤炼，Logtail和开源Agent（例如Fluentd、Logstash、Beats）相比，性能、资源消耗、可靠性和多组合隔离等硬指标上较为领先。能够知足国内最大的直播网站、最大的教育类网站、最大的金融类网站的苛刻要求。和开源Agent主要差距在于日志格式的丰富性（当前Logtail版本已支持Logstash、Beats协议，既能够将这些开源插件无缝跑在Logtail之上）。

2018年Logtail针对Docker/K8S等场景作了很是多的适配工做，包括：

• 一条命令一个参数便可实现部署，资源自动初始化
• 支持CRD方式配置，支持K8S控制台、kubectl、kube api等，与K8S发布、部署无缝集成
• K8S RBAC鉴权，日志服务STS鉴权管理

能够自豪地说，Logtail方案是K8S下全部Agent中最全，最完整的之一，感兴趣能够参见LC3视角：Kubernetes下日志采集、存储与处理技术实践 ：

1.2 C Producer Library系列（面向嵌入式设备新秀）

​ 除X86机器外，咱们可能会面对各类更底层IoT/嵌入式设备。针对这种场景，LogHub推出C Producer Library系列SDK，该SDK能够定位是一个“轻量级Logtail”，虽没有Logtail实时配置管理机制，但具有除此以外70%功能，包括：

• 多租户概念：能够对多种日志（例如Metric，DebugLog，ErrorLog）进行优先级分级处理，同时配置多个客户端，每一个客户端可独立配置采集优先级、目的project/logstore等
• 支持上下文查询：同一个客户端产生的日志在同一上下文中，支持查看某条日志先后相关日志
• 并发发送，断点续传：支持缓存上线可设置，超过上限后日志写入失败
  专门为IoT准备功能：
• 本地调试：支持将日志内容输出到本地，并支持轮转、日志数、轮转大小设置
• 细粒度资源控制：支持针对不一样类型数据/日志设置不一样的缓存上线、聚合方式
• 日志压缩缓存：支持将未发送成功的数据压缩缓存，减小设备内存占用

关于C Producer Library的更多内容参见目录：yq.aliyun.com/articles/30…

目前针对不一样的环境（例如网络服务器、ARM设备、以及RTOS等设备）从大到小咱们提供了3种方案：

​ 在X86以及ARM设备测试场景中，C-Producer系列SDK能在稳定服务状况下，极大优化性能和内存空间占用，胜任只有4KB运行内存的火火兔场景（Brick版本）。

使用C Producer系列的客户有： 百万日活的天猫精灵、小朋友们最爱的故事机火火兔、 遍及全球的码牛、钉钉路由器、 兼容多平台的视频播放器、 实时传输帧图像的摄像头等。

这些智能SDK天天DAU超百万，遍及在全球各地的设备上，一天传输百TB数据。关于C Producer Library 的细节能够参考这篇文章: 智能设备日志利器：嵌入式日志客户端（C Producer）发布。

2. 服务端多地域支持

​ 客户端问题解决了后，咱们来看看服务端。LogHub 是阿里云化基础设施，在全球阿里云全部Region都有部署。确保不管业务在哪一个Region开展，均可以选择就近的Region。

例如欧盟、新加坡等国家有相关的法律约束数据不能出境，对于这类场景咱们能够选择合适的数据中心来提供服务。对于同Region下ECS、Docker等服务，咱们能够直接使用同Region服务进行处理，节省跨洋传输的成本。

3. 全球加速网络

​ 对全球化业务而言，用户可能分布在全球各地（例如游戏，App、物联网等场景），但在构建数仓业务的过程当中，咱们每每须要对数据进行集中化处理。例如一款移动App用户散布在全国各省市

• 将日志采集中心定在杭州，那对于西南（例如成都）用户而言，远程进行日志传输的延时和质量难以保障
• 将日志采集中心定在成都，那对位于东部和东北用户又难以权衡，更不用说中国的三大运营商链路质量的影响

​ 2018年6月初LogHub 联合 CDN 推出了一款全球自动上传加速方案：“基于阿里云CDN硬件资源，全球数据就近接入边缘节点，经过内部高速通道路由至LogHub，大大下降网络延迟和抖动 ”。只需简单配置便可构建起快速、稳定的全球数据采集网络，任意LogHub SDK均可以经过Global域名得到自动加速的支持。

​
在咱们测试case中，通过全球7个区域对比总体延时降低50%，在中东，欧洲、澳洲和新加坡等效果明显。除了平均延时降低外，总体稳定性也有较大提高（参见最下图，几乎没有任何抖动）。确保如何在世界各地，只要访问一个统一域名，就可以高效、便捷将数据采集到指望Region内。

4. 服务端弹性伸缩

​ 在解决网络接入问题后，咱们把问题聚焦在服务端流量这个问题上。熟悉Kafka都知道，经过Partition策略能够将服务端处理资源标准化：例如定义一个标准的单元Partition或Shard（例如每一个Shard固定5MB/S写，10MB/S读）。当业务高峰期时，能够后台Split Shard以获取2倍的吞吐量。

这种方法看起来很工程化，但在使用过程当中有两个难以绕开的现实问题：

• 业务没法预测：事先没法准确预估数据量，预设多少个shard才合适呢
• 人的反应滞后：数据量随时会突增，人不必定可以及时处理，长时间超出服务端负载能力会有数据丢失风险

​ 针对以上状况，LogHub提供了全球独创Shard自动分裂功能：在用户开启该功能后，后台系统实时监控每一个shard的流量，若是发现一个shard的写入在一段时间内，有连续出现超过shard处理能力的状况，会触发shard的自动分裂，时刻保障业务流量。

更多细节能够参考这篇文章: 支持Shard自动分裂

5. 丰富上下游生态与场景支持

LogHub也提供丰富上下游与生态对接，包括各类主流流计算、数据仓库等引擎支持：

• 采集端：Logstash、Beats、Log4J等
• 实时消费端（流计算）：Flink/Blink、Storm、Samza等
• 存储端（数仓）：Hadoop、Spark、Presto、Hive等

经过LogHub与日志服务其余功能+产品组合，能够轻松支撑安全、运营、运维和研发对于数据处理的各类场景需求，更多能够参考学习路径 和 用户手册。

写在最后

日志服务是阿里自产自用的产品，在双11、双十二和新春红包期间承载阿里云/蚂蚁全站、阿里电商板块、云上几千商家数据链路，每日处理来自百万节点几十PB数据，峰值流量达到每秒百GB， 具有稳定、可靠、低成本，生态丰富等特性。
阿里云官网上提供同款产品，只要5分钟即可开通并开启数字化IT之旅，欢迎试用。