共计 4377 个字符，预计需要花费 11 分钟才能阅读完成。
数字化运营基础在如今“双十一”不再是线上活动的代名词，而逐步变为一场线上线下同时进行的消费者盛宴。销售、运营、物流、生产商等都在开足马力在各大渠道备战，据统计：
消费者在期间被平均推送 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 埋点：在完成数据埋点后，我们可以在日志服务分析功能中，获得每个环节的点击数和转化数字，以衡量购买阶段的效果。
Web Tracking 链接：https://help.aliyun.com/docum… 服务端埋点链接：https://help.aliyun.com/docum…
数据采集挑战从上面例子来看，数据采集是数字化 IT 的基础。让我们来看一个典型的数据采集架构：
购买一批机器搭建网络服务器为服务器搭建负载均衡设备在网络服务器（例如 Nginx）模块中使用 Kafka 等中间件写入数据
该方案通过无状态设计解决了高可用，按需扩容等问题，也是众多厂商采用的方案，在理想状态下运行得非常好。但在现实过程中，往往会遇到如下挑战：
作为用户最终的目标是为了分析数据。但这些问题的存在，需要在业务、规模与增长上消耗大量人力、精力和物力，干了不一定干得好。
日志服务 LogHub 功能阿里云日志服务（Log Service，/ 原 SLS）是针对实时数据一站式服务，其中的 LogHub 模块就是专为数据采集定制的功能，该功能有如下特点：
30+ 实时采集手段
LogHub 提供 30+ 种开箱即用的数据采集手段，包括直接和云产品打通的日志、移动端、服务端、程序、SDK、网页、嵌入端等，以下我们分别介绍下最常用的四种与试用场景：
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 的更多内容参见目录：https://yq.aliyun.com/article…
目前针对不同的环境（例如网络服务器、ARM 设备、以及 RTOS 等设备）从大到小我们提供了 3 种方案：
在 X86 以及 ARM 设备测试场景中，C-Producer 系列 SDK 能在稳定服务情况下，极大优化性能和内存空间占用，胜任只有 4KB 运行内存的火火兔场景（Brick 版本）。
使用 C Producer 系列的客户有：百万日活的天猫精灵、小朋友们最爱的故事机火火兔、遍布全球的码牛、钉钉路由器、兼容多平台的视频播放器、实时传输帧图像的摄像头等。
这些智能 SDK 每天 DAU 超百万，遍布在全球各地的设备上，一天传输百 TB 数据。关于 C Producer Library 的细节可以参考这篇文章: 智能设备日志利器：嵌入式日志客户端（C Producer）发布。
服务端多地域支持
客户端问题解决了后，我们来看看服务端。LogHub 是阿里云化基础设施，在全球阿里云所有 Region 都有部署。确保无论业务在哪个 Region 开展，都可以选择就近的 Region。
例如欧盟、新加坡等国家有相关的法律约束数据不能出境，对于这类场景我们可以选择合适的数据中心来提供服务。对于同 Region 下 ECS、Docker 等服务，我们可以直接使用同 Region 服务进行处理，节省跨洋传输的成本。
全球加速网络
对全球化业务而言，用户可能分布在全球各地（例如游戏，App、物联网等场景），但在构建数仓业务的过程中，我们往往需要对数据进行集中化处理。例如一款移动 App 用户散布在全国各省市
将日志采集中心定在杭州，那对于西南（例如成都）用户而言，远程进行日志传输的延时和质量难以保障将日志采集中心定在成都，那对位于东部和东北用户又难以权衡，更不用说中国的三大运营商链路质量的影响
2018 年 6 月初 LogHub 联合 CDN 推出了一款全球自动上传加速方案：“基于阿里云 CDN 硬件资源，全球数据就近接入边缘节点，通过内部高速通道路由至 LogHub，大大降低网络延迟和抖动”。只需简单配置即可构建起快速、稳定的全球数据采集网络，任意 LogHub SDK 都可以通过 Global 域名获得自动加速的支持。
在我们测试 case 中，经过全球 7 个区域对比整体延时下降 50%，在中东，欧洲、澳洲和新加坡等效果明显。除了平均延时下降外，整体稳定性也有较大提升（参见最下图，几乎没有任何抖动）。确保如何在世界各地，只要访问一个统一域名，就能够高效、便捷将数据采集到期望 Region 内。
服务端弹性伸缩
在解决网络接入问题后，我们把问题聚焦在服务端流量这个问题上。熟悉 Kafka 都知道，通过 Partition 策略可以将服务端处理资源标准化：例如定义一个标准的单元 Partition 或 Shard（例如每个 Shard 固定 5MB/ S 写，10MB/ S 读）。当业务高峰期时，可以后台 Split Shard 以获取 2 倍的吞吐量。
这种方法看起来很工程化，但在使用过程中有两个难以绕开的现实问题：
业务无法预测：事先无法准确预估数据量，预设多少个 shard 才合适呢人的反应滞后：数据量随时会突增，人不一定能够及时处理，长时间超出服务端负载能力会有数据丢失风险 针对以上情况，LogHub 提供了全球首创 Shard 自动分裂功能：在用户开启该功能后，后台系统实时监控每个 shard 的流量，如果发现一个 shard 的写入在一段时间内，有连续出现超过 shard 处理能力的情况，会触发 shard 的自动分裂，时刻保障业务流量。
更多细节可以参考这篇文章: 支持 Shard 自动分裂
丰富上下游生态与场景支持
LogHub 也提供丰富上下游与生态对接，包括各种主流流计算、数据仓库等引擎支持：
采集端：Logstash、Beats、Log4J 等实时消费端（流计算）：Flink/Blink、Storm、Samza 等存储端（数仓）：Hadoop、Spark、Presto、Hive 等
通过 LogHub 与日志服务其他功能 + 产品组合，可以轻松支撑安全、运营、运维和研发对于数据处理的各种场景需求，更多可以参考学习路径 和 用户手册。
写在最后日志服务是阿里自产自用的产品，在双十一、双十二和新春红包期间承载阿里云 / 蚂蚁全站、阿里电商板块、云上几千商家数据链路，每日处理来自百万节点几十 PB 数据，峰值流量达到每秒百 GB，具备稳定、可靠、低成本，生态丰富等特性。
