数据采集

0 前言近年来，物联网技术正以指数级的速度日渐成熟，并耳濡目染的扭转着人们的生存。依据国际数据公司IDC的预测预计，到2025年，将有416亿台联网的IoT设施或“物”，生成79.4 ZB的数据。同时IDC中国钻研数据显示，2020年寰球物联网收入达到6904.7亿美元，其中中国市场占比23.6%。IDC预测，到2025年寰球物联网市场将达到1.1万亿美元，年均复合增长11.4%，其中中国市场占比将晋升到25.9%，物联网市场规模寰球第一。 阿里云企业物联网平台是基于阿里云的基础架构，提供设施接入、设施治理、监控运维、数据流转、数据管理、解决剖析等物联网构建能力，帮助企业在数字化转型时领有更残缺的生产资料。而对于第一步设施如何疾速上云并且实现寰球就近接入尤其重要，上面笔者将具体介绍阿里云物联网平台的设施散发服务是如何实现设施寰球疾速就近接入的。 1 名词解释物联网平台：是阿里云的一个物联网治理平台，为设施提供安全可靠的连贯通信能力和治理能力，反对设施数据采集上云，规定引擎流转数据和云端数据下发设施端。 Alink通信协议：Alink协定是阿里云物联网平台的通信协议，该协定使设施与云端领有上下行指令承受与下发的能力，并且为设施端与云端提供上下行通信的信道。 设施三元组：每台设施领有productKey(产品标识)，pruductSecret(产品秘钥)，deviceName(设施名称标识)，deviceSecret(设施秘钥)，productKey和deviceName惟一标识一台设施，即一个产品下能够有多台设施。咱们通常称productKey、deviceName和deviceSecret为设施的三元组信息。 设施接入点：设施连云须要指定接入点，接入点蕴含实例id信息${instanceId}.mqtt.iothub.aliyuncs.com 实例：物联网平台的产品模式，用户以实例的模式购买，能够分为独享实例(独享的计算资源)和公共实例(和其它租户共享的计算资源) Bootstrap：设施疏导服务 IHV(Independent Hardware Vendor)：独立硬件开发商 ISV(Independent Software Vendors)：独立软件开发商 SI(Service Integrator)：服务集成商 2 以后面临的问题物联网平台的设施散发服务要解决什么问题？先来看如下两个典型的业务场景： 场景一用户软硬拆散，IHV须要将设施交付给SI/ISV治理：IHV对设施进行建模和开发，并线下量产设施；ISV/SI在阿里云物联网平台批量生成设施三元组信息；ISV/SI线下向IHV购买设施，同时把本人实例下创立的三元组信息和设施接入接入点信息提供给IHV；IHV用上一步骤的三元组和实例信息烧录设施，并交付设施给ISV/SI；ISV/SI集成软件并部署应用设施。以后的场景存在的问题： 因为设施开发者和设施使用者(ISV/SI)在不同的实例下，而设施接入又要烧录指标的实例id接入点，导致设施开发者无奈提前备货提前将三元组和连接点信息进行烧录，须要用户下单后能力拿到设施真正要接入的实例信息；因为设施要交付给最终的使用者(ISV/SI)所在的实例进行治理，所以设施使用者须要在本人的实例内生成设施三元组并提供实例id信息给设施开发者烧录，最终设施数据能力在所在实例进行治理，操作繁琐；场景二厂商是软硬一体的开发者，能够本人开发设施并集成软件。厂商在本人的实例内生成的设施三元组信息，同时产线烧录三元组信息和实例接入点信息，而后将设施卖给C类用户，设施可能被用户带到不同的国家进行应用。以后的场景也存在一些问题：厂商的三元组信息是在指定的实例下生成的，也就是这一批设施烧录的是一个固定的实例接入点，如果用户把设施带到不同的国家，那么设施只能接入烧录的指定接入点，无奈就近抉择机房，就会导致设施和云端通信提早减少；因为设施会被用户带到不同的国家应用，然而设施连贯的始终是一个实例的数据中心，所以也可能存在数据合规问题；3 如何解决这些问题形象一下咱们要解决的三个问题：解决设施跨实例跨region跨租户的归属：因为物联网的简单场景，设施的开发者和使用者往往不是同一个用户，须要提供一种形式解决跨实例跨region的设施归属问题； 设施能够提前烧录备货：无需在设施出厂时对不同region和不同实例的连贯信息进行硬编码，设施对立烧录寰球对立接入点信息即可(无region信息)，解决设施提前备货； 设施能够寰球就近低延时的接入：因为设施可能被用户带到任意region，心愿设施能够连贯到就近region的阿里云物联网平台的用户实例下，防止数据合规和连贯指定烧录实例接入点造成的高延时问题。 针对于以上三个问题，阿里云物联网平台提出了设施散发的概念：物联网平台通过设施散发实现设施跨地区、跨实例或跨账号的散发。散发后，云端下发新的连贯地址给设施，设施本地固化收到的信息之后，间接连贯新的地址，免去二次烧录设施信息。设施散发次要解决的就是两个问题：设施的寰球接入，设施的归属关系。 先来看一下设施散发服务的整体架构：物联网平台在寰球8个region部有核心机房，设施散发服务整体上是分为两个阶段的： 配置阶段：用户通过凋谢接口或者控制台对要散发的设施进行信息配置；接入阶段：设施通过Bootstrap疏导服务上云，触发配置，实现接入；上面将具体看一下上述提出的三个问题是如何解决的：1.设施跨实例跨region跨租户的归属问题而设施散发服务的第一个工作就是买通了阿里云外部的所有网络环境，对用户只裸露实例间的操作屏蔽底层简单的网络和隔离策略。对于跨账号的操作，散发服务采纳短信鉴权，并买通了国内站和国内站间账号的操作，用户只须要关怀要散发到哪个账号下的哪个实例即可。网络买通后就是如何在这个链路上实现数据高牢靠的传输，因为跨region和跨库的数据拜访可能会遭逢网络抖动或中间件拜访超时等异样流；针对这些问题，零碎除了有异样主动重试策略外还在业务上做了跨库的事务回滚，最大水平上保障业务数据的一致性。 因为设施数据的散发操作都是采纳长工作进行解决，所以为了避免服务器宕机或者重启导致的工作中断，零碎内置了故障转移机制，来保障工作肯定会走到状态机终态，其外围思路就是采纳心跳包和单机定时检测(quartz)来实现服务器的故障转移。下图演示了server1接管申请并，如果呈现故障，是如何转移到server2当中的。2.设施提前烧录备货问题因为上云须要指定实例的接入点，所以对于设施不确定交由给哪个企业实例用户连贯哪个企业实例的场景就没有方法提前烧录接入点，提前备货。 所以对于设施端通过烧录的global域名能够去核心环境申请散发服务，设施通过申请散发核心的bootstrap服务，该服务会返回设施疏导信息，蕴含设施真正要接入的物联网平台实例的接入点信息，设施拿到指标接入点通过mqtt直连即可连贯到指标用户的实例即可。 思考设施还可能产生重配的状况，即设施曾经连贯在指标实例，然而用户在控制台重新配置了设施的指标实例接入点，这时候如果设施曾经连云处于在线状态，服务端会推送一条mqtt音讯给设施，通知设施的接入信息发生变化请从新连贯。如果设施不在线用户重配后，设施建连依然走上面的流程仍旧能够连贯到指标实例。         3.设施寰球就近低延时的接入问题对于散发设施的接入策略服务端提供两种：指定地区和就近接入。这两种有各自的应用场景，对于指定地区策略如果用户明确设施要散发到哪个实例下应用能够抉择指定地区策略，设施能够抉择配置到指定实例进行接入，典型的场景是设施开发商在本人的实例下量产设施，而后将设施散发到渠道商的实例下，设施的指标实例是固定的，而且心愿只连贯在固定的实例下。 对于就近接入策略，例如设施厂商是软硬一体的，在指定的实例开发并量产了设施，然而设施售卖到C端用户手中会被用户带到寰球任意region应用，这时设施厂商能够在物联网平台反对的每一个region购买一个实例，并配置就近接入策略，这样设施在挪动到特定region申请bootstrap服务的时候，散发服务会依据设施的进口ip信息，动静的将设施身份散发到就近region用户的实例下进行连贯。 设施只须要烧录一个寰球域名iot-auth-global.aliyuncs.com，在解决了就近接入的同时，散发服务配置了ADNS智能域名解析。实现了寰球就近低延时接入指标实例。 4 产品个性1.万级设施能够实现跨账号、跨实例、跨region在阿里云各物联网平台任意的散发；同时平台对散发的设施提供了多种数据高牢靠的保障策略；2.提供多种散发策略，满足不同业务场景的需要；3.设施bootstrap服务接入无额定鉴权，简化了设施接入流程；4.一次配置，设施就能够实现低延时的寰球就近接入； 5 接入文档1.性能应用文档2.云端开发指南3.设施端开发指南 物联网平台产品介绍详情：https://www.aliyun.com/product/iot/iot_instc_public_cn 阿里云物联网平台客户交换群

背景GPS定位器是内置了GPS模块和挪动通信模块的终端，用来将GPS模块取得的定位数据通过挪动通信模块传至Internet上的一台服务器上，从而能够实现在电脑或手机上查问终端地位。 GPS定位器可用于儿童和老人的行踪掌控，公路巡检，贵重货物跟踪，追踪与勤务差遣，私人侦探工具，集体财物跟踪，宠物跟踪，野生动物追踪，货运业，汽车防盗，自行车防盗，电动车防盗，摩托车防盗，银行运钞车，公务车治理等。 传统定位器计划定位器设施启动后，基于TCP/IP协定和云端的业务服务器建设连贯，而后通过校时指令来同步时钟，之后定时发送心跳包来放弃TCP长连贯，GPS数据变动超过阈值时，主动上报以后坐标的经纬度值，设施电量变动信息也会定时上报到云端，以便优化GPS数据采集规定。 云端服务器也能够推送配置信息和控制指令到定位器设施，以扭转定位器行为模式。 定位器业务上云随着云计算厂商布局物联网场景技术产品，基于MQTT协定的全托管的IoT云服务逐步成为70%中小企业做物联网业务的首选计划。从TCP协定迁徙到MQTT协定的计划也逐步成熟，以实现存量设施低成本的疾速迁徙上云，缩小设施端和业务零碎的革新，极大的晋升整体安全性，稳定性，大大降低业务时延，借助云上动静有限扩容能力承载海量规模增长。 当咱们把设施连贯迁徙到阿里云IoT物联网平台之后，从新梳理业务链路，会发现IoT物联网服务承载了沉重的和设施交互的工作，云上的业务服务器压力变得小了很多。 身份认证定位器设施和IoT物联网平台基于MQTT协定通信，TCP报文调整为MQTT的CONNECT/CONNACK报文，此时业务服务器不须要做身份校验工作，IoT物联网平台会把设施上线/离线音讯通过规定引擎实时推送到业务服务器。 时钟同步企业基于TCP搭建的时钟同步服务也能够下线了，IoT物联网平台提供了残缺的NTP服务，解决嵌入式设施资源受限，端上没有准确工夫戳的问题。具体文档 https://help.aliyun.com/docum... 心跳MQTT协定自身约定了PINGREQ/PINGRESP的心跳机制，此时也不须要业务服务器染指，IoT物联网平台会响应设施心跳行为。 双向音讯通信基于MQTT协定通信是须要约定topic和payload，为了缩小业务零碎改变，咱们减少两个Topic定义，消息报文构造体放弃不变。 设施上报业务数据后，通过规定引擎配置，咱们把上行的Topic：/{pk}/{dn}/user/up中的payload数据实时流转到业务零碎，数据格式不变；业务零碎推送配置信息或指令时，IoT物联网平台封装到上行的Topic：/{pk}/{dn}/user/up中的payload里，设施接管到的业务数据格式不变。 迁徙实战创立产品，定义通信Topic创立服务端订阅生产组 配置规定引擎设施上报数据流转到服务端订阅生产组 抉择生产组，并携带Tag信息到业务零碎 设施启动，上报数据后，在业务服务端收到数据 控制台查看生产组状况 日志服务 【往期回顾】1.自建MQTT集群迁徙阿里云IoT平台2.IoT时代：WiFi配网技术分析3.微信小程序和IoT智能家居实际4.IoT云端通用数据解析脚本实际 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

随着传感器和通信技术的一直倒退，物联网行业方兴未艾，业务链路波及数据采集，通信连贯，数据存储，数据可视化，洞察，口头决策。但，在施行过程中，碎片化的设施端通信连贯难题往往就妨碍了我的项目落地过程。 明天，本文总结不同设施场景的连贯上云计划，供大家参考。资源丰盛类设施 高性能硬件的倒退，很多智能设施带有残缺的Linux、Android、Arduino等操作系统，在操作系统层面，解决了不同通信模块的差别，硬件端的应用程序只须要集成云平台的IoT SDK，或者集成开源MQTT SDK即可和云端建设长连贯通信链路。资源受限类设施 物联网场景中有很大占比设施是资源受限的，运行ROTS零碎，甚至无操作系统，采纳MCU+通信模组的形式，实现设施数据近程采集。市面上蜂窝模组(NB-IoT/2G/3G/4G)供应商较多，比方移远通信、芯讯通、合宙、无方科技、广和通、日海智能、高新兴等，而各家的 AT 指令也各不相同，为设施端利用程序开发带来了很大难度。 依据模组集成度不同又细分一下几种场景计划： 本地通信类设施 物联网场景中还有大量设施仅具备本地局域通信能力，比方蓝牙设施，ZigBee设施，LoRa设施，Modbus设施，而不具备互联网接入协定栈反对，此时须要借助DTU/网关设施，代理子设施把本地协定转换成MQTT协定，从而实现数据采集上云。 本地零碎整体上云 在工业，商业综合体等场景中，本地往往有一套成熟的零碎，实现了设施数据的集中采集，因为团体业务对立治理的诉求，须要把各地数据采集上云。 面对这种场景，能够通过自有系统集成泛化SDK通过HTTP/2协定，在不革新设施前提下，高效的实现海量数据疾速上云。 物联网平台产品介绍详情：https://www.aliyun.com/produc... 阿里云物联网平台客户交换群

简介：覃立辉在 5.21 Flink CDC Meetup 的分享。 本文整顿自顺丰大数据研发工程师覃立辉在 5月 21 日 Flink CDC Meetup 的演讲。次要内容包含： 顺丰数据集成背景Flink CDC 实际问题与优化将来布局点击查看直播回放 & 演讲PDF 一、顺丰数据集成背景 顺丰是快递物流服务提供商，主营业务蕴含了时效快递、经济快递、同城配送以及冷链运输等。 运输流程背地须要一系列零碎的反对，比方订单管理系统、智慧物业零碎、以及很多中转场、汽车或飞机上的很多传感器，都会产生大量数据。如果须要对这些数据进行数据分析，那么数据集成是其中很重要的一步。 顺丰的数据集成经验了几年的倒退，次要分为两块，一块是离线数据集成，一块是实时数据集成。离线数据集成以 DataX 为主，本文次要介绍实时数据集成计划。 2017 年，基于 Jstorm + Canal 的形式实现了第一个版本的实时数据集成计划。然而此计划存在诸多问题，比方无奈保证数据的一致性、吞吐率较低、难以保护。 2019 年，随着 Flink 社区的一直倒退，它补齐了很多重要个性，因而基于 Flink + Canal 的形式实现了第二个版本的实时数据集成计划。然而此计划仍然不够完满，经验了外部调研与实际，2022 年初，咱们全面转向 Flink CDC 。 上图为 Flink + Canal 的实时数据入湖架构。 Flink 启动之后，首先读取以后的 Binlog 信息，标记为 StartOffset ，通过 select 形式将全量数据采集上来，发往上游 Kafka。全量采集结束之后，再从 startOffset 采集增量的日志信息，发往 Kafka。最终 Kafka 的数据由 Spark 生产后写往 Hudi。 然而此架构存在以下三个问题： 全量与增量数据存在反复：因为采集过程中不会进行锁表，如果在全量采集过程中有数据变更，并且采集到了这些数据，那么这些数据会与 Binlog 中的数据存在反复；须要上游进行 Upsert 或 Merge 写入能力剔除反复的数据，确保数据的最终一致性；须要两套计算引擎，再加上音讯队列 Kafka 能力将数据写入到数据湖 Hudi 中，过程波及组件多、链路长，且耗费资源大。基于以上问题，咱们整顿出了数据集成的外围需要： ...

背景：做科研须要根底数据，其中一部分只能到网上爬取。工作：获取360图书馆外面某一个用户下有价值的医案数据，并保留到access数据库中，至于为何用access数据库，是因为前期查看、导出数据不便。 1 数据库表用pyodbc驱动连贯数据库。其官网文档在：http://mkleehammer.github.io/pyodbc/外面的文档比拟具体，间接用官网举荐代码就能够。留神，最初cusr.execute(sql) 后别忘了须要conn.commit()提交。过后还遇到一个问题：零碎装置的是绿色版office2016，odbc数据源中没有access的驱动（通过cmd中运行odbcad32调出数据源窗口查看），起初折腾又给装置了一个office2013，又去搞激活，各种杂事一通，真浪费时间，有时候想想，国人的软件之路真须要致力啊。 2 爬取页面内容这部分很久前就爬取过相似的单页文档，比较简单，不过须要依据每个页面的特色进行提取。 3 列表获取因为要爬取的栏目有1000多个页面内容，所有放在多个页面中，每个页面默认出现10条记录。如何获取这个url的列表是要害内容。参考了：https://www.cnblogs.com/cokefentas/p/14731920.html这位仁兄把思路过程形容的很分明，只须要依照思路，依据以后的内容进行剖析就能够了。认为因为本人前端弄的少，尤其是js这部分不是很熟，于是把这部分在浏览器的调试模式下再现了一遍，的确最初失去的sign是截然不同的。注意事项：python中之心js代码，用到了execjs模型，须要如下装置：pip install PyExecJS而后再运行如下语句：print(execjs.get().name)如果后果是：JScript，阐明用的Windows模型的js编译环境，须要装置node.js。解决办法：装置nodejs，下载地址：https://nodejs.org/zh-cn/down...默认装置，默认配置环境变量即可敞开PyCharm再次执行上述execjs.get().name命令，发现曾经变为 Node.js (V8)然而，又遇到了新的问题，在调试模式中保留的js文件，起初用记事本关上，再复制了生成sign的那段JavaScript代码保留，这时候在文件头带了一个非凡标记字符\ufeff，导致总是编码报错：这个解决办法有多种：第一，能够参考https://blog.csdn.net/u011045...这篇文章，用notepad++关上后，再以无bom头的模式保留。第二，能够把读取文件的编码格局由utf-8，改为utf-8-sig。 utf-8与utf-8-sig两种编码格局的区别:As UTF-8 is an 8-bit encoding no BOM is required and anyU+FEFF character in the decoded Unicode string (even if it’s the firstcharacter) is treated as a ZERO WIDTH NO-BREAK SPACE. UTF-8以字节为编码单元，它的字节程序在所有零碎中都是一様的，没有字节序的问题，也因而它实际上并不需要BOM(“ByteOrder Mark”)。然而UTF-8 with BOM即utf-8-sig须要提供BOM。 对于 \ufeff 的一些材料（引自维基百科）： 字节程序标记（英语：byte-order mark，BOM）是位于码点U+FEFF的对立码字符的名称。当以UTF-16或UTF-32来将UCS/对立码字符所组成的字符串编码时，这个字符被用来标示其字节序。它常被用来当做标示文件是以UTF-8、UTF-16或UTF-32编码的记号。 4 ip被封在爬取到34页（每一页10条）的时候，ip被封了，拜访不了360doc。其实还是做了延时，然而header没有更换，不晓得其判断的机理是怎么样的，目前来看是单位工夫内的拜访次数超过，也有可能是header设置不合理。别人对于爬虫冲破封禁的办法：https://www.cnblogs.com/junro...https://cloud.tencent.com/dev... 没有方法，只能把每一页设置为50条，在调试模式中拿到json数据，手工去构建url_list。

简介：本篇实际将以某家国内教育机构为例，为大家具体介绍云原生架构下日志服务数据预处理以及对应的解决方案和最佳实际操作手册，不便用户疾速对号入座，解决云原生架构下的常见日志难题。 中转最佳实际：【https://bp.aliyun.com/detail/207】 观看视频：【https://yqh.aliyun.com/live/detail/23950】 阿里云最佳实际目前已笼罩23类罕用场景，有200多篇最佳实际，这其中波及110款以上阿里云产品的最佳应用场景。目前，最佳实际已胜利帮忙大量客户实现自助上云。 分享人 解决方案架构师-七凌日志服务产品经理-谷奈本篇实际将从3个局部为大家介绍云原生架构下日志服务数据预处理，心愿能够让大家对其有更深刻的理解，并能够将其利用到我的项目中，达到降本提效的目标。本文次要内容分为以下三个方面： 最佳实际计划解说外围产品能力介绍基于场景的demo演示一、最佳实际计划解说1. 云原生下的数据加工云原生的定义各种各样，有来自CNCF社区的“微服务+容器+继续交付+DevOps”，也有来自不同云厂商的说法“生于云，长于云”。比方咱们经常听到的云原生数据库、云原生大数据、云原生容器、云原生中间件、云原生平安等等概念，这都是在云上能够获取到的服务化云原生产品，是传统线下没有的服务，可能在线上获取极致的弹性。这里，咱们提到的数据加工，它是阿里云提供的云原生日志服务SLS所具备的能力之一。我置信大家都十分相熟日志服务的数据存储、数据查问能力，而对于它提供的数据加工和告警告诉，可能不太理解。SLS内置的数据加工能力，可能将各类日志解决为结构化数据，具备全托管、实时、高吞吐的特点。它面向日志剖析畛域，提供十分丰盛的算子、反对开箱即用的场景化UDF（比方Syslog、非标准json、accessLog解析等等）。同时与阿里云的大数据产品（OSS、MC、EMR、ADB等）以及开源生态(Flink、Spark)进行了深度集成，升高了数据分析的门槛。 2. 云原生数据加工的典型能力下图所示为数据加工服务的几个典型能力，包含数据复制、过滤、转换，富化、补漏、决裂等。整体优势简略来说能够演绎为以下四点： 开箱即用，免运维凋谢灵便，反对200+DSL稳固牢靠能做到秒级提早 3. 云原生数据加工的典型利用场景以向寰球提供分布式在线教育的某家国内教育机构为例，为大家介绍几个典型利用场景，供大家参考和借鉴。 典型场景一：跨地区、跨账号的数据会集 假如该在线教育的次要用户集中在美国硅谷和中国上海两地，为了更好的为用户提供个性化服务，零碎会通过多端（Android/IOS/Web）进行收集用户行为日志和设施元数据（端设施的信息、软件版本）。出于网络就近准则和稳定性思考，美国硅谷的客户端日志都上传到美国硅谷region，中国上海的客户端日志都都上传到中国上海region，为了方面客服核心或者运维团队进行集中查问和治理，会将两地的数据通过数据加工汇聚到一起。正如下图下层所示，将跨账号跨区域的服务日志和操作日志通过数据加工汇聚到了一起。值得注意的是，跨地区数据会集，默认会走公网，稳定性无奈保障，所以举荐采纳DCDN的形式进行寰球减速。 典型场景二：数据对立的采集，按业务散发，进行数据的归类 该客户的业务零碎部署在阿里云容器服务ACK上，系统日志通过DaemonSet形式采集到Logstore。便于后续业务剖析的目标，须要通过日志服务SLS将不同Service的日志散发到不同的Logstore，而后各个团队再进行进一步剖析。比方，运维团队更关怀5XX服务端报错；业务团队更在乎2XX失常的业务日志。正如下图上层所示： 典型场景三：数据内容富化（join维表） 日常工作中，客服核心的工作人员尝尝须要通过检索账号ID的形式，疾速获取该用户相干的挪动端操作记录，然而挪动端的数据和用户账号信息别离采集与寄存的，无奈间接进行关联。所以零碎层面上，须要将多端日志与维表（例如用户信息Mysql表）进行字段join,为原日志信息增加更多维度信息供剖析或者问题解答。 典型场景四：数据投递/归档、入湖剖析以及监控告警 经营部门心愿对于用户行为数据进行进一步的离线剖析，须要将数据归档到OSS便于后续应用，比方通过DLA进行进一步的数据挖掘。然而因为不同客户端日志格局不对立，须要应用日志服务进行数据规整后再做投递，便于后续剖析。比方，将挪动端上报的json格局进行开展，做格式化的规整，而后将规整后的数据投递到OSS后，再应用DLA进行剖析。并且在这个过程中，咱们能够对加工工作的提早状况进行监控，当加工工作延迟时间超过所设置的阈值后，触发告警，执行相干口头策略。比方依据延迟时间的长短，设置不同的告警重大水平，并设置对应的告警模式： 重大为短信告警，中等为邮箱告警。告诉到相应的运维人员，并且通过设置降噪策略，能够对相似告警进行归并，防止告警风暴的影响。其实上面这幅架构图也是这篇最佳实际的架构示意图，外面包含了计划波及到的外围组件，后续将通过云速搭CADT进行一键部署，实现根底资源的创立。 4. 应用云原生数据加工计划的劣势通过这篇最佳实际，咱们能够晓得如何进行数据规整、如何进行数据富化、数据散发/汇聚、如何做监控告警的配置。 二、外围产品能力介绍什么是SLS？SLS这个产品用一句话形容即SLS是云原生观测剖析平台，为LOG/METRIC/TRACE等数据提供大规模、低成本、实时平台化服务。可能一站式提供数据采集、加工、剖析、告警可视化与投递性能，可能全面晋升研发、运维、经营和平安等场景的数字化剖析能力。艰深一点说的话，相干日志数据包含log日志、trace日志、metric日志都能够通过SLS采集之后，在SLS外面通过加工剖析等解决，最终利用到客户的业务场景里，次要场景包含：业务监控、异样诊断、网络分析、利用监控、增长黑客等。 SLS是从阿里云飞天监控零碎中孵化的产品，是一款阿里自研，在阿里内外部失去宽泛应用的《日志+监控数据平台》，同时经验了团体多年双十一和内部客户新春红包的考验，是国内私有云TOP1的日志剖析产品。 SLS的利用场景SLS作为一款日志产品，有着凋谢的产品理念和丰盛的生态穿插。对目前用户数据比拟大的云产品业务日志，以及审计日志，均可接入到SLS。同时SLS与大数据产品的投递和生产的性能，有很强的的解决方案组合能力。那么接下来咱们就细看下SLS次要的利用场景，作为日志平台、业务监控、数据管道是目前应用最多的三个场景。 日志平台 日志平台比拟好了解，只有是有肯定规模的用户，就必定会有业务运维和零碎运维的需要，也就衍生了日志平台的需要。在SLS产品化之前，大部分用户都是应用开源的服务进行组合，比拟支流的比方ELK的应用，而日志服务相比于这些自建的平台，在免运维、低成本、功能丰富等方面的劣势是自建零碎所无法比拟的。 业务监控 业务监控和智能运维其实也是运维畛域通用场景的需要，SLS领有秒级解决十亿级数据的剖析能力，同时能够满足各种异构数据提取、聚合、可视化需要。同时另外联合咱们的告警以及AI异样检测能力，能够帮忙客户疾速搭建起来一套欠缺的监控告警零碎，最初联合日志服务提供的异样巡检、时序预测、根因剖析等能力，可能帮忙用户进步问题发现以及剖析定位效率。数据管道 因为SLS具备极强的对立数据采集的能力，目前曾经反对40+种数据源的接入，同时数据加工能力通过灵便的ETL可能对数据进行荡涤富化，最终通过投递生产的性能，与支流流式及离线平台大数据分析平台对接。因而作为数据管道在大数据等解决方案中应用也是次要的场景之一。SLS的次要性能性能包含数据采集、数据加工、查问剖析、业务监控、日志审计、投递与生产。 日志采集 日志采集是SLS的一个外围性能，是帮忙客户进行日志存储剖析等的前提，在日志采集这一方面,SLS基本上是往极致的思路上在做。无论是LOG/TRACE/METRIC的日志，用户的服务器与利用日志，挪动端的数据日志，IoT设施的日志，阿里云的各个云产品日志，还是其余场景，只有是满足标准协议的传输的日志，都能够通过SLS的采集平台进行对立采集。 数据加工 实现了数据采集的工作之后，多样化的数据在投入使用之前，往往须要进行格局规整的工作，这时候就须要应用到数据加工的性能。SLS提供的数据加工是一款开箱即用的性能，反对数据过滤、转化、富化、决裂等解决。为了实现这样的能力，数据加工提供了200+的内置函数，400+的Grok,丰盛的文本处理，搜寻算子，能够通过简略的代码自在编排组合操作，实现所须要的的数据加工能力。 同时数据加工具备的秒级解决性能，大吞吐性能和程度拓展能力能够保障客户工作的牢靠执行。 查问剖析 通过数据加工，客户能够将原始的日志加工成结构化的数据，接下去就能够做查问和剖析。SLS的查问剖析提供了关键词、规范的SQL92\ALOPS函数等多种多样的查问形式，反对面向文本+结构化数据实时查问剖析，异样巡检与智能剖析，同时SLS领有极致的查问性能，十亿数据可能在秒级进行返回。 业务监控 通过这些剖析后失去的查问的数据，就能够应用SLS的可视化能力，造成报表不便二次查问。一次SQL长期应用，所见即所得。同时SLS反对下钻剖析和上卷剖析，客户能够依据理论的业务需要设置对应的报表组合。另外SLS反对灵便的告警策略，反对多数据源的联结告警监控，也反对通过归并、克制、静默等智能设置无效升高告警风暴，以便于可能将真正无效有价值的数据告诉到用户，不便用户随时随地掌握业务动向。 日志审计 日志审计次要应答客户的平安需要，可能帮忙客户疾速接入审计数据，以合乎等保/网安法/GDPR协定，同时与第三方SOC残缺对接，能够对数据进行二次应用。目前日志审计已笼罩所有日志相干产品日志自动化采集，能够实现跨多主账号、主动实时发现新资源并实时采集。咱们在日志审计中内置了近百个CIS、最佳实际等场景监控规定，能够一键开启，及时发现不合规的行为。 投递性能 投递性能是在当客户有数据归档或者简单数据分析需要时，能够从日志服务投递（和生产对应的日志）到第三方服务。目前曾经对接了支流流计算引擎和数据仓库存储。生产性能是指用户的ECS\容器、挪动端、开源软件、JS等数据，通过采集接入到SLS后，能够通过SDK/API来自定义生产组，从SLS实时生产数据。 三、基于场景的demo演示本最佳实际采纳云速搭CADT对须要应用的资源进行部署，它是一款为上云利用提供自助式云架构治理的产品，显著地升高利用云上治理的难度和工夫老本。本产品提供大量预制的利用架构模板，同时也反对自助拖拽形式定义利用云上架构，反对大量阿里云服务的配置和治理，能够不便地对云上架构计划的老本、部署、运维、回收进行全生命周期的治理。上面简略演示下架构部署环境的搭建过程。 登录云速搭CADT控制台。单击新建 > 官网模板库新建。 在搜寻框中搜寻“云原生架构下日志服务数据预处理”，找到指标模板，单击基于计划新建。 零碎基于模板生成利用架构图： 双击OSS，须要重命名，保障全局惟一，其余资源配置依据理论状况批改。 实现配置后，单击右上角的保留，设置利用名称，并单击确认。 接着单击部署利用。 ...

背景家喻户晓，简直没有一个开发者可能做到开发时100%没有Bug，那么一旦咱们的产品出了问题，疾速定位问题是迫切需要做的事。好在咱们在Web场景中Js运行出现异常不会导致JS引擎解体，最多只会终止以后执行的工作。而后逐级上抛谬误，相似冒泡事件，在遇到最近的一层catch时进行上抛，如果两头都没有错误处理的catch时，直至window对象完结。那么明天就与大家一起探讨一下咱们在Web场景中的异样谬误数据如何收集以及如何上报。 谬误类型想要获取到绝对残缺的异样谬误数据，先要理解在Web中常见的异样谬误都有哪些。 Js执行谬误日常执行中次要有同步谬误、语法错误、一般异步工作谬误、Promise工作谬误、async工作谬误5种常见的异样谬误。 资源加载谬误次要有图片、script、css、font等资源的加载谬误问题。 谬误捕捉try…catch作为一个优良的程序员，首先咱们能想到的肯定是 try…catch，那么咱们间接上代码：因为资源加载标签必定不能在代码块中执行，因而资源加载谬误必定无奈捕捉。 基于上图后果，咱们能够小结一下try…catch的解决能力： 能捕捉包裹体内的同步执行谬误。不能捕捉语法错误。不能捕捉异步工作谬误。不能捕捉Promise工作谬误。不能捕捉资源加载谬误。window.onerror咱们浏览器在window对象上还自带了一个onerror的办法须要额定留神：跨域脚本加载谬误只有一个“Script error”，并不能获取到错误信息。能够通过在<script>标签上增加“crossorigin”属性来解决这个问题。 基于上图后果，咱们再小结一下window.onerror的解决能力： 能捕捉所有同步执行谬误。不能捕捉语法错误。能捕捉一般异步工作谬误。不能捕捉Promise工作谬误。不能捕捉async工作谬误。不能捕捉资源加载谬误。window.addEventListener(‘error’)在Web页面上咱们能够监听绝大多数事件，当然也包含谬误事件，咱们从字面意思上浅了解咱们能够认为与onerror差不多，然而实际上它们俩的体现还是有一点区别，这里咱们给出addEventListener额定能捕捉的谬误，其余与onerror基本一致：这里要额定留神的是：如果是在js代码中new Image() 后加载呈现的谬误是无奈捕捉的。 相比window.onerror，通过window.addEventListener的形式咱们能够捕捉资源加载的谬误。 window.addEventListener(‘unhandledrejection’)方才咱们介绍了3种常见的谬误捕捉形式，但都不能捕捉Promise工作的谬误，这里有人会说了，Promise不是能够本人catch吗？是的，然而我置信大多数状况下咱们的开发同学可能并不会为每一个Promise写一个catch，或者可能呈现漏写的状况。Js为咱们筹备了一个“兜底计划”: unhandledrejection事件监听。它会在Promise 被reject（抛错）且没有被catch的时候触发。上面上例子： 当然如果咱们将没有catch的Promise放在async中去执行，unhandledrejection事件监听也能捕捉到。所以async工作谬误unhandledrejection事件监听也是能够反对捕捉的。 题外话：咱们能够看到这个事件的名称叫做unhandledrejection，作为一个英语词法敏锐的程序员，霎时想到，有没有叫handledrejection的事件呢，如果有，咱们是不是能够猜想作用刚好是相同呢？还真有！并且正如咱们所猜想的，它是在Promise的reject做了解决（catch）后触发！这里咱们就不开展议论，有趣味的同学能够钻研一下。 回归正题，咱们通过这么多例子测试了4种捕捉谬误的形式，总结失去下表：那么咱们察看这个表格，首先能够看到语法错误，4种形式都不能捕捉，然而咱们个别认为语法错误不应该在执行阶段才发现，在咱们的编译以及测试环节就能够查看出，所以咱们不思考将其捕捉。那么其余的异样谬误咱们发现通过 addEventListener('onerror') + addEventListener('unhandledrejection') 的形式恰好可能笼罩5种异样谬误的捕捉，一起来实现一下： 把Promise及async工作中的谬误捕捉后用同步的逻辑抛出即可让onerror精确捕捉到。 如此，咱们就能够将咱们Web中大部分的异样问题进行精确捕捉。 接下来咱们看看如何将谬误问题上报至咱们的服务器进行汇总。 数据上报XMLHttpRequest咱们想要将数据传回服务器，最通用的形式当然就是ajax申请，通过浏览器的XMLHttpRequest（这里咱们不探讨IE）的send办法，发送post申请数据给服务端，这里咱们不再给出实现。 其毛病也很显著： 有严格的跨域限度、携带cookie问题。上报申请可能会阻塞业务。申请容易失落（被浏览器强制cancel）。Image因为浏览器对资源文件的区别对待，为了解决下面的几个问题，咱们能够通过创立一个1x1大小的图片进行异步加载的形式来上报。图片人造可跨域，又能兼容所有的浏览器，而js和css等其余资源文件则可能呈现平安拦挡和跨域加载问题。 但因为是一个get申请，上报的数据量在不同的浏览器下下限不统一（2kb-8kb），这就可能呈现超出长度限度而无奈上报残缺数据的状况。因而，图片上报也是一个“不平安”的形式。 SendBeacon这个办法天生就是为了数据统计而设计的，它解决了XMLHttpRequest和图片上报的绝大部分弊病：没有跨域问题、不阻塞业务，甚至能在页面unload阶段持续发送数据，完满地解决了一般申请在unload阶段被cancel导致丢数据的问题，惟一的问题就是IE并不反对。 调用形式也非常简单，相似咱们发送post申请： 这里须要留神的是，sendBeacon并不像XMLHttpRequest一样能够间接指定Content-Type，且不反对application/json等常见格局。data的数据类型必须是 ArrayBufferView 或 Blob, DOMString 或者 FormData 类型的。这里给出Blob类型的示例。 小结基于以上3种上报形式，咱们能够根本总结出，上报数据倡议优先应用sendBeacon的形式，不反对的浏览器（例如IE）则降级应用图片上报，尽量避免间接应用XMLHttpRequest进行上报。 结语目前你尽管GrowingIO Web SDK当初并没有对这些异样谬误做残缺的收集（因为咱们的产品重点不在这），然而咱们有须要的用户能够本人实现谬误捕捉的逻辑并应用SDK的埋点办法进行上报。 另外，咱们正在Web SDK上进行架构演进且行将实现，创新性地提供了客户自定义插件的能力！后续您能够尝试通过SDK提供的插件能力，自行开发一个谬误收集的插件（甚至是性能采集插件），配合SDK原有性能就能实现业务经营数据和开发所需的谬误、性能数据的采集！敬请期待！ 以上就是咱们明天为大家分享的Web利用Js异样谬误收集的内容。 参考文献： *https://developer.mozilla.org... https://developer.mozilla.org... https://developer.mozilla.org... https://developer.mozilla.org... https://developer.mozilla.org...*

简介：数据集成是简略高效的数据同步平台，致力于提供具备弱小的数据预处理能力、丰盛的异构数据源之间数据高速稳固的同步能力，为数据中台的建设打好松软的数据基座。-更少数智化转型、数据中台内容请退出阿里云数据中台交换群以及官网微信（文末扫描二维码） -阿里云数据中台官网 https://dp.alibaba.com/index 数据中台是当下大数据畛域最前沿的数据建设体系, 它并不是从零开始, 无中生有的。数据中台是传统的数据仓库的一种降级, 是数据采集、建设、治理与应用的一整套体系。                Dataphin是一个构建数据中台的弱小工具, 数据集成是Dataphin的组成部分，负责数据“采”、“建”、“管”“用”中的采集局部。数据集成是简略高效的数据同步平台，致力于提供具备弱小的数据预处理能力、丰盛的异构数据源之间数据高速稳固的同步能力，为数据中台的建设打好松软的数据基座。 (__Dataphin__：面向各行各业大数据建设、治理及利用诉求，一站式提供从数据接入到数据生产全链路的智能数据构建与治理的大数据能力，包含产品、技术和方法论等，助力打造规范对立、死记硬背、资产化、服务化、闭环自优化的智能数据体系，以驱动翻新。__具体理解：https://dp.alibaba.com/product/dataphin) 数据集成定位数据集成是数据中台建设中最根底的工作，将不同零碎的数据互相买通，实现数据自在离线或实时流动。 面对各行各业对大数据越来越多的利用，对数据集成也有了更多的诉求。包含：_可能简略高效的配置大量数据表的同步工作；可能集成多种异构数据源；可能实现对数据源的数据进行轻度预处理；可能实现数据同步工作的调优（例如容错，限速，并发）_等。Dataphin的数据集成模块次要面向企业数据开发人员，以组件利落拽的模式，帮忙企业高效构建大数据流通管道，从而将各种烟囱状态的数据汇聚到数据中台。 数据集成能力数据集成旨在为用户构建简略高效、安全可靠的数据同步平台： 反对通过整库迁徙（疾速生成批量同步工作）和一键生成指标表的形式，进步数据集成的效率。反对流程和转换组件，实现数据源的数据预处理（例如荡涤、转换、字段脱敏、计算、合并、散发、过滤等）能力。反对丰盛的异构数据源，实现数据源之间数据高速稳固的同步能力。反对Dev-Prod和Basic的开发模式，您能够依据业务场景进行灵便抉择开发模式。反对将Dataphin中创立的逻辑表疾速地同步到指标库。用户可自定义零碎尚未反对的数据源组件，以满足不同业务场景数据同步的需要。 数据集成场景关注要点 - 易用性用户进行数据中台建设时，须要集成的表的数量往往很多，须要进行大量反复的繁琐配置工作。 Dataphin的数据集成通过高效的拖拽式操作，自动化一键主动建表、组件复制和整体管道配置复制，批量化的整库迁徙等操作可大大提高零碎的易用性及操作效率。 Dataphin的数据集成的画布数据的输出、转换、输入组件、采集工作流、采集工作等可视化性能，使管理员直观的把握数据采集状况。 Dataphin的数据集成在工作搭建过程中反对同步工作试运行、度量查看、数据预览，不便用户进行数据集成工作的调试。 - 多源异构的数据同步能力在企业信息化建设过程中，因为各业务零碎建设和施行数据管理系统的阶段性、技术性以及其它经济和人为因素等因素影响，导致企业在倒退过程中积攒了大量采纳不同存储形式的业务数据，包含采纳的数据管理系统也大不相同，从简略的文件数据库到简单的网络数据库，它们形成了企业的异构数据源。 在数据中台的建设中，须要反对各种异构数据源的数据集成，Dataphin的数据集成可反对30+种数据源的反对，同时可自定义数据源进行灵便接入。 - 数据预处理、同步配置能力在数据集成过程中，起源端数据会有轻度预处理诉求，比方敏感数据加密、数据过滤、分库分表数据合并、追 加字等。也会有各式各样同步配置诉求，如容错，限速，并发，同步过程调试等。 Dataphin的数据集成反对数据荡涤转换能力，提供字段计算、合并、散发、过滤、字段脱敏等组件或函数，反对容错配置、并发配置、限速配置等。 以上就是Dataphin的外围性能数据集成的介绍, 心愿能帮忙您更好地应用Dataphin数据集成性能。 理解产品更多内容能够戳入：https://dp.alibaba.com/product/dataphin 数据中台是企业数智化的必经之路，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。 目前正通过阿里云对外输入系列解决方案，包含通用数据中台解决方案、批发数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案、政务数据中台解决方案等细分场景。 其中阿里云数据中台产品矩阵是以Dataphin为基座，以Quick系列为业务场景化切入，包含： - Dataphin，一站式、智能化的数据构建及治理平台；- Quick BI，随时随地 智能决策；- Quick Audience，全方位洞察、全域营销、智能增长；- Quick A+， 跨多端全域利用体验剖析及洞察的一站式数据化经营平台；- Quick Stock， 智能货品经营平台；- Quick Decision，智能决策平台；官方站点： 数据中台官网 https://dp.alibaba.com 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：阿里巴巴数据中台的解决方案是在引入数据安全等级打标的根底上，实现数据智能审批，通过可信模型构建和危险量化，让智能流程代替繁琐人工。以Dataphin为例，作为阿里巴巴团体数据治理方法论基于外部实际的产品化输入，它能够为企业提供一站式数据采、建、管、用全生命周期治理的能力，以助力企业显著晋升数据治理程度，构建品质牢靠、生产便捷、生产平安经济的企业级数据中台。-更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 和关注官网微信公总号（文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index 往年正值三年倒退布局的收官之年，包含银行、证券、保险在内的金融机构的数字化转型的紧要性进一步凸显。 阿里巴巴云上数据中台负责人王赛在明天举办的2021阿里云金融数据智能峰会上走漏，阿里巴巴数据中台建设的教训，或者能够给金融企业数智化转型带去一些借鉴。 阿里巴巴云上数据中台负责人 王赛 阿里巴巴数据中台建设的6道教训　2015年，阿里巴巴正式提出数据中台策略，这也是数据中台这一概念在国内首次亮相——但在更早之前，阿里巴巴其实就有动作。 王赛示意，早在2011年，阿里巴巴就从新梳理并重建了外部数据团队，以“业务版块+剖析维度”为架构构建数据中心。2013年，对立的数据服务中间件OneService正式诞生，通过深度加工后的数据能够由OneService为前端各业务提供对立的数据服务。 在他看来，阿里巴巴数据中台建设绝不是一簇而就，而是面对阿里巴巴团体外部简单场景以及多样需要，必须实现的一条数智转型通路。 这些场景和需要能够演绎为六大类，别离是:数据品质与平安、数据价值、产品工具积淀、老本管控、组织与经营、品质与考核。 数据品质与平安次要集中于四方面，首先是一致性，面对同一份数据，各个业务的定义口径不统一，这为前期开发、剖析、利用带来极大困扰，因而数据中台首先要解决的就是指标标准化定义，并在此基础上实现代码总动化构建和数据后果产出；其次，是数据资产深度问题，通过数据深度交融与买通，数据中台可能为业务一线员工提供全方位的市场信息，并进行价值评估；再次，是保障数据及时性，通过数据运维基线治理和挪动办公协同，数据中台可能保障业务部门及时获取多维过程及后果数据，即使是在挪动办公场景，也能保障可实时查看相干数据；最初，是聚焦数据流通平安，外围要解决数据安全审批权限定义和在保障数据安全的根底上较少审批工作量两项问题，阿里巴巴数据中台的解决方案是在引入数据安全等级打标的根底上，实现数据智能审批，通过可信模型构建和危险量化，让智能流程代替繁琐人工。 另一方面，数据价值次要体现在通过数据赋能，帮忙平台增长、商家成长和员工提效。 值得注意的是，阿里巴巴数据中台建设的过程当中衍生出十分丰盛的产品矩阵，用以应答繁冗的业务场景和个性化的岗位需要，如针对双11场景的媒体大屏、面向管理层决策的剖析类数据产品等等。 同时，踊跃建设数据人才培养体系，成立“数据委员会”让各业务数据岗位员工能够造成高效联动与信赖，并凝炼、流传迷信无效地数据文化。 而在整个数据中台建设的过程中，王赛强调，“咱们还提炼出数据中台价值地显性化表白，从用户价值与体验、资产积淀、经营等多方位视角，来重复验证KPI、人员及估算地设定，这是一个动线过程。” 通过阿里云全面输入数据中台能力　阿里巴巴数据中台在历经多年外部实际后，于2018年正式通过阿里云全面对外开放数据中台能力，迄今已在金融、批发、政务、互联网等行业胜利落地。 阿里云新金融&互联网事业部总经理刘伟光早前在承受媒体采访时示意，对企业来说，阿里云数据中台具备两大独有劣势，“首先是工具的丰富性，阿里云数据中台产品汇合了市面上所有的工具，从工具层面，从数据处理层面，到下层利用层面，到数据的应用层面，到BI层面，到决策层面，能够说八面玲珑。” 阿里云新金融&互联网事业部总经理 刘伟光 目前，阿里云数据中台曾经造成以Dataphin、Quick BI、Quick Audience等产品为主的外围产品矩阵。 以Dataphin为例，作为阿里巴巴团体数据治理方法论基于外部实际的产品化输入，它能够为企业提供一站式数据采、建、管、用全生命周期治理的能力，以助力企业显著晋升数据治理程度，构建品质牢靠、生产便捷、生产平安经济的企业级数据中台。 同时，Dataphin提供多种计算引擎反对及可拓展的凋谢能力，能够适应各行各业的平台技术架构和个性化诉求。 聚焦金融行业，作为数字化起步较早的行业，银行、证券、保险等行业数据平台的建设周期和历史不比互联网行业工夫短，对于数据应用积攒了肯定的教训，然而仍旧难以避免数智转型地阵痛。 外围体现在数据规范问题、数据品质问题、需要相应问题、老本资源问题四方面: 数据规范问题:烟囱式开发及部分业务服务撑持，导致指标同名不同口径问题频发；历史上不同业务零碎逐渐迭代上线，雷同对象属性编码不统一等问题突出； 数据品质问题:反复建设导致工作链简短、工作繁多，计算资源缓和，数据时效性不好；口径梳理定义的文档积淀到开发代码实现之间存在脱节，数据准确性保障危险高； 需要响应问题:烟囱式开发周期长、效率低，面向利用的服务化有余，导致业务响应速度慢，业务不称心的同时技术又感觉没有积淀与成长；既懂业务又懂数据的人才有余，需要了解到开发实现波及大量沟通，服务效率较差； 老本资源问题:烟囱式开发的反复建设节约技术资源；上线难下线更难，源零碎或业务变更不能及时反映到数据上，加之数据不规范，研发保护难上加难的同时，大量无用计算和存储造成资源节约。 这也和阿里巴巴数据中台建设期间所面临的难点不约而同。 阿里巴巴通过实践经验提出的数据治理方法论，可能帮忙企业捋清了数据全生命周期的治理思路，更将其植入到产品Dataphin（智能数据构建与治理）中，通过阿里云为企业提供服务。 正因如此，Dataphin除了大数据处理全链路波及到的数据集成、开发、公布、调度、运维能力，同时还将为企业提供数据标准定义、逻辑模型定义、代码自动化生成、数据主题式服务能力，高效地实现好数据的构建。 也正是基于Dataphin产品的能力，财通证券买通既有多个零碎数据，实现数据及时接入及规范对立，整合加工解决后，基于市场状态实现包含“金融属性”“产品类型”等在内的300多个数据标签。 数禾科技也在长达7个月的共创共建后，实现传统数仓体系地重构降级，对立数据资产治理平台，同时借助我的项目全面梳理了公司外围业务流程，将所有的业务过程及背地对应的数据串联起来，对立一套信息系统，每个业务过程在信息化平台都能看到具体的数仓表、指标、指标以后的值、环比同比等信息，一旦这些指标出现异常，就能够疾速自动化归因，定位问题环节，创新性建设了数据经营模式。 数禾科技大数据负责人万鹏说道:“阿里云数据中台自带One Service数据接口服务，之前咱们自研的数据平台，面向线上业务提供数据接口的链路太长太简单，目前通过阿里云数据中台产品Dataphin构建数据输入输出的链路既通顺又迅速，产品自身自带集成通道。” ...

简介：零根底入门大数据开发治理，上手DataWorks 10大模块DataWorks官网入门电子书出版啦，零根底入门大数据开发治理，全面理解DataWorks十大功能模块，疾速上手DataWorks外围性能。 下载地址： https://developer.aliyun.com/topic/download?id=7940 数据的“麻利制作”，DataWorks一站式数据开发治理范式演进： https://developer.aliyun.com/article/785814 DataWorks数据集成-大数据高低云的外围枢纽： https://developer.aliyun.com/article/785819 DataWorks数据建模 - 一揽子数据模型治理解决方案： https://developer.aliyun.com/article/785845 数据开发（DataStudio）降本提效的外围利器： https://developer.aliyun.com/article/785851 DataWorks运维核心与挪动版介绍： https://developer.aliyun.com/article/785858 DataWorks数据分析模块： https://developer.aliyun.com/article/785860 DataWorks数据品质介绍及实际： https://developer.aliyun.com/article/785867 DataWorks数据安全能力模块介绍及最佳实际： https://developer.aliyun.com/article/785890 DataWorks数据服务介绍及最佳实际： https://developer.aliyun.com/article/785895 DataWorks迁徙助手介绍及最佳实际： https://developer.aliyun.com/article/785897 DataWorks数据治理介绍及实际： https://developer.aliyun.com/article/785904 往期热门电子书下载： 《大数据&AI的16种可能，2020阿里云客户最佳实际合集》 https://developer.aliyun.com/article/772449 《阿里巴巴大数据及AI实战》 https://developer.aliyun.com/topic/download?spm=a2c6h.14210656.J\_2581178420.3.3ced1549Cwh3F5&id=38 《领军行业大数据及AI实战》 https://developer.aliyun.com/topic/download?spm=a2c6h.14210656.J\_2581178420.4.3ced1549Cwh3F5&id=31 《大数据工程师必读手册》 https://developer.aliyun.com/topic/download?spm=a2c6h.14210656.J\_2581178420.5.3ced1549Cwh3F5&id=29 《Apache Flink 十大技术难点实战》 https://developer.aliyun.com/topic/download?spm=a2c6h.14210656.J\_2581178420.2.3ced1549Cwh3F5&id=34 《Apache Flink 年度最佳实际》 https://developer.aliyun.com/topic/download?spm=a2c6h.14210656.J\_2581178420.1.3ced1549Cwh3F5&id=33 《实时数仓Hologres技术入门一本通》 https://developer.aliyun.com/article/778742 《阿里云实时数仓Hologres最佳实际合集》 https://developer.aliyun.com/article/779488 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：7月16日，以“原生平安二倍速：全面融入基础设施”为主题的阿里云原生安全线上专题流动收官，诠释由云而生的能力如何解决数字经济时代的平安新挑战，让高等级平安作为一种基础设施，成为数字业务倒退的“助推器”。原生安全线上发布会：https://yqh.aliyun.com/live/openbigdata 7月16日，以“原生平安二倍速：全面融入基础设施”为主题的阿里云原生安全线上专题流动收官，诠释由云而生的能力如何解决数字经济时代的平安新挑战，让高等级平安作为一种基础设施，成为数字业务倒退的“助推器”。 基础设施即平安，原生免疫解决实质问题企业数字化转型带来的间接变动是IT架构及业务状态的扭转，为了满足业务对网络及性能等方面要求而产生的分布式架构，导致业务被“散布”到不同的物理地位，传统的平安边界隐没；同时，业务因数字化而变得更加灵便，新利用、新服务能够疾速上线或迭代，而平安防护却无奈疾速跟进。 McAfee公布的一份对于 2020 年第二季度网络威逼演变与相干网络犯罪活动剖析报告显示，在跟踪时间段内，恶意软件新样本总数增长了 11.5%，每分钟会呈现 419 个新威逼。 Freebuf公布的Balbix《2020企业平安态势情况报告》调研报告显示，超过40%的组织须要24小时甚至更长的工夫来辨认易受攻击的零碎，这使得他们简直不可能阻止疾速流传的勒索或恶意软件的感化暴发。 寰球出名网络安全公司 Mandiant 的一份报告则证实了这一点，2020年，勒索软件受益组织减少了422%。 面对越来越简单的业务逻辑及越来越高级的攻打手法，传统碎片化“外围防护”式平安解决方案在数字时代新的平安挑战背后，如同隔靴搔痒，无奈解决最实质的平安问题。 云底层基础设施的变动给平安带来了全新扭转。 碎片化的平安能力，通过融入人造一体的云基础设施，变成系统性、可全局联动的原生免疫系统，将简单的平安问题化约成极简与智能的原生防护，实现基础设施即平安。 在直播流动中，阿里云智能平安资深总监欧阳欣公布了阿里云的原生平安能力体系，通过将平安能力全面融入基础设施，实现平安成果质的扭转。以应急响应为例，基于云上全局威逼检测与全网协同进攻，云上均匀应急响应工夫能够缩短到1小时，远远少于行业24小时的平均水平，这能够在绝对量值上升高威逼给企业带来的损失。 阿里云始终在推动这套云的原生免疫系统一直“成长”，并以平安服务化的模式提供，客户能够按需调用，按量付费，以构建更加合乎本身业务需要的平安体系。 三道防线，原生免疫有机作战以人体免疫系统的三道防线来类比：第一道防线 皮肤级防护，阻挡病原体侵入人体，并有杀菌作用。 云平台基础设施本身的平安能力就像人体的第一道防线，为云上企业提供了最根本的平安防护。企业上云后除了不须要关注最底层的防火防电、固件平安等物理硬件安全之外，阿里云还提供了三层递进式原生平安能力： 1.云上立体化平安计算环境，基于可信计算和秘密计算技术，以不可篡改的芯片级硬件安全为起始点，保障整个云上计算环境平安可信； 2.数据默认加密，所有云上数据默认落盘加密，并提供字段级加密能力，云平台爱护客户密钥的主密钥默认每日轮转，使得破解成为不可能； 3.全网继续狐疑动静验证，通过微隔离实现实例级别的网络隔离，通过身份认证、权限动静治理、网络准入等形式打造零信赖的平安云环境。 第二道防线 吞噬细胞，这是人类在进化过程中逐步建设起来的人造进攻性能，特点是人原生自带，对多种病原体都有进攻作用。 阿里云的云基础设施也是如此，云产品自诞生即具备默认平安基因。目前阿里云的10条产品线50款产品曾经具备522项外围平安能力，客户上云享受到的是具备平安基因的云服务。 同时，从云而生的平安产品会跟ECS、云存储、数据库、云网络等云产品服务深度集成，客户上云开明云产品服务的那一刻即可同时抉择开启更高等级的平安防护能力，将平安能力有限贴近客户业务边缘，比方应用CDN服务，即可启用Web利用防火墙，在边缘节点，通过频次管制、机器流量治理等能力，抵挡常见的CC攻打和爬虫刷量攻打，使得业务减速与平安兼顾。 第三道防线 免疫器官和免疫细胞，针对出世后更加简单的病原体逐步建设起来的先天进攻性能。 面对愈发简单和智能的平安危险，阿里云联合云基础设施的人造劣势，为客户提供了笼罩六大外围畛域61个能力项的整体平安解决方案，帮忙客户构建云上纵深进攻体系。 与外挂式平安最大的不同点在于，从云而生的平安能力与云基础设施深度交融，人造具备云的劣势，性能弹性伸缩，API化主动部署、灵便运维，全局对立管控；云端丰盛的威逼情报与平安产品能力联动，全网协同进攻，且禁受过云的大规模实际和验证。 先天成长的原生高等级平安能力能够解决很多线下难以解决的简单且高级的攻打危险，是云特有的的原生免疫力。 云即信赖云原生平安的进化，在一直放大信赖老本，让基础设施自身成为更加高可用、高安全等级的可信计算环境。 阿里云的原生平安能力取得多家权威机构认可，而且国内惟一整体平安能力取得Gartner、Forrester、IDC认可全满贯。 在越来越简单的数字商业时代，简略是消解简单的最佳门路，平安理念与计划因为云的呈现正在在被化约。正如阿里云智能平安事业部总经理肖力所说，咱们心愿在越来越简单中，为客户提供越来越简略的抉择。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：Forrester 最新数据流剖析报告：阿里云入选强劲表现者象限日前，权威咨询机构 Forrester 公布了 2021 Q2 寰球数据流剖析报告，阿里云凭借当先的实时计算产品、开发者友好度和大规模实际，挺进该报告的“强劲表现者”象限，刷新了国内公司在数据流计算畛域的最好问题。 Forrester 是寰球最权威的IT征询评测机构之一，本次针对入选的 14 家国内最重要的数据流剖析服务商，从产品、策略、市场体现三个维度，12 个规范 20 多项评估细则进行了深入研究剖析和评分。与此前相比，本次报告的评测规范更为严苛。 Forrester 分析师认为，阿里云旗下的 Ververica 在性能、剖析和部署选项方面具备当先劣势，合乎强劲表现者（Strong Performers）象限的评估规范。 数据流剖析又被称作“跳舞的大数据”，基于数据流剖析衍生进去的实时计算曾经成为寰球最受欢迎的技术之一。通过实时计算，企业可实时把握当下正在产生的事，比方工厂设施的物联网设施能实时剖析数据、进步生产良品率；物流派送平台能第一工夫下单，把商品及时送到消费者手中；导航软件时刻紧随出行轨迹，不再错过转弯口…… 作为国内最早布局实时计算技术方向的企业之一，早在 2016 年阿里巴巴就曾经开始大规模上线应用实时计算产品。本次入选强劲表现者象限的 Ververica 就是阿里巴巴旗下的数据智能商业公司，其研发的Flink平台是寰球最受欢迎的实时计算平台之一。 基于 Flink 的开源社区 Apache Flink 也是寰球大数据畛域最沉闷的社区之一，领有超过 20W 开发者关注，在 Github 上 star 的数量和 Flink 贡献者的数量每年以 30% 以上的速度增长。 目前，阿里云实时计算已在金融行业，在线教育、互联网交易等行业大规模利用，包含每年天猫 “双11” 的实时大屏，可实时展现各个维度的数据并及时领导电商平台经营。 某互联网保险公司就基于阿里云实时计算 Flink 构建了实时数仓，将其利用场景分为三类: 营销流动、实时大屏及反欺诈。平台提供的低延时、低资源耗费、高效率、高精准度等能力，满足了业务高实时性的需要。且该公司也充分利用 Flink 平台的个性，丰盛输入输出接口，保证数据品质。 阿里云实时计算负责人王峰示意，“ Flink 将会在核心技术研发、产品化、生态建设上继续加大投入，普惠更多云上用户，并帮忙客户进一步放慢实时化过程，在企业数字化转型的浪潮中建设外围竞争力。” 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：CDN是通过在寰球范畴内分布式地部署边缘服务器将各类互联网内容缓存到凑近用户的边缘服务器上，从而升高用户拜访时延并大幅缩小穿梭互联网核心网的流量。互联网业务应用CDN曾经成为一种必然的抉择。企业边缘利用面临的挑战CDN是通过在寰球范畴内分布式地部署边缘服务器将各类互联网内容缓存到凑近用户的边缘服务器上，从而升高用户拜访时延并大幅缩小穿梭互联网核心网的流量。互联网业务应用CDN曾经成为一种必然的抉择。传统网站防护基本上都是爱护源站，客户购买防火墙、WAF等产品就能够爱护本人外围业务的内容不被歹意窃取。但传统防护形式并不能齐全满足业务流量通过CDN散发的场景： 部署地位在源站前，次要为了爱护源站。在CDN架构中，页面根本都缓存在CDN上，爬虫能够间接从CDN上间接爬走用户敏感业务数据。辨认伎俩次要依附在用户页面中嵌入JS，这种形式实质上批改了用户的页面，有很强的侵入性，并且只能适配web业务，针对api业务不失效。处理伎俩个别通过频次管制，对高频的IP等特色进行限度，这种形式容易被绕过，当初爬虫根本都会采纳IP代理池的形式，随机批改申请的header字端，这样很难找到特色进行频次管制。CDN以后承接了主站大量业务，也必然要保障业务浏览和交易体验，避免内容不被歹意窃取。越来越多的业务数据缓存在CDN的边缘服务器上，边缘平安的权重越来越高。而基于边缘云的机器流量治理应运而生，应答CDN边缘安全隐患，实现用户利用数据安全爱护。 边缘云的机器流量治理的实现及劣势基于CDN边缘节点的机器流量治理剖析及解决流程如下图所示： 互联网拜访个别分为用户失常，商业搜索引擎拜访，歹意爬虫拜访等，机器流量治理通过在边缘提取申请报文特色，基于报文特色辨认申请类型，在边缘阻断歹意爬虫拜访，爱护CDN上缓存资源不被歹意爬取。 机器流量治理的劣势如下： 基于CDN边缘网络架构实现机器流量治理能力，通过申请报文特色辨认域名的申请类型，辨别是失常的申请还是歹意的机器申请，帮忙用户治理本人的申请，阻断歹意申请。通过辨认域名的申请类型，实时标记出申请的报文类型，十分直观的展现出以后的业务申请中的报文类型，客户能够直观的感知到本人的网站的拜访类型散布状况，针对异样的报文类型进行处理。通过处理报文类型而不是处理IP，只有歹意申请的报文类型不变，攻击者随机头部字段或者应用秒拨代理IP池都无奈绕过。机器流量治理理论后果验证在双11业务场景，机器流量治理针对拜访主站详情页的全副流量做辨认，并对 Bot 流量进行细化分类。外围策略是放行搜索引擎等正规商业爬虫，限度或拦挡歹意爬虫。 通过剖析详情页的流量以及申请的行为特色，剖析出近40%的申请都是歹意拜访。在双11前，通过开启了处理策略，胜利帮忙主站某业务拦挡了超过70%的爬虫流量。下图为开启处理前后的流量比照状况，蓝线为未开启处理策略是的流量趋势，绿线为开启处理策略后的流量趋势，拦挡成果非常明显，并且不影响理论业务运行。 双11当日，基本上申请的拜访特色没有变动，最终拦挡数亿次歹意申请、上百万歹意IP及数千万歹意爬取商品ID。 CDN机器流量治理承当更多主站业务的防护，并且发现局部爬取主站内容的申请能够透过防护策略，即爬取的申请行为产生了变动。通过对线上突增qps剖析，定位出变异爬虫次要应用的是IE的浏览器引擎，源IP大量应用秒拨代理IP，具备显著的商业爬虫特色。经上报，疾速造成了应急预案，疾速对异样类型进行处理。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：数据中台是传统的数据仓库的一种降级, 是数据采集、建设、治理与应用的一整套体系，Dataphin是一个构建数据中台的弱小工具, 外围劣势是在数据的建设与治理上引入了阿里巴巴多年来数据中台建设积淀出的OneModel方法论。前言数据中台是当下大数据畛域最前沿的数据建设体系, 它并不是从零开始, 无中生有的。数据中台是传统的数据仓库的一种降级, 是数据采集、建设、治理与应用的一整套体系。Dataphin是一个构建数据中台的弱小工具, 外围劣势是在数据的建设与治理上引入了阿里巴巴多年来数据中台建设积淀出的OneModel方法论(OneData体系的组成部分之一)。本篇主讲Dataphin外围性能布局的设计理念。 OneModelOneModel将数据中台的建设分成四层: 主题域建模：在数据中台, 主题对应一个宏观的剖析畛域, 比方销售剖析就是剖析"销售"这个主题. 分割较为严密的主题的汇合就是主题域. 每一个行业都能够拆分为有多个(十个左右不等)主题域组成的主题域模型。概念建模：在主题域的根底上, 每个主题域内减少了实体以及实体之间的关系。逻辑建模：在概念模型的根底上, 减少每个实体的属性以及属性的束缚。业务剖析建模：行业中重要的以及罕用的分析方法与剖析视角. 在逻辑模型根底上, 将业务剖析问题转换为Dataphin特有的派生指标, 并进一步提炼出原子指标和业务限定。 布局OneModel四层中的主题域建模和概念建模由Dataphin的布局性能来承载实现。OneModel的四层不针对企业级数据中台, 而是围绕单个独立业务来开展的, 多个独立业务通过公共的维度来实现企业级数据中台。因而, Dataphin的布局性能还包含独立业务的划分, 即业务板块的划分。布局并不会影响数据的准确性与产出时效, 而是一个重要的面向数据(资产)治理的性能, 会影响数据的查找, 了解与权限管控等多方面。 业务板块企业的规模有大有小, 业务复杂度和跨度也不同, 数据反映业务, 所以每个企业的数据中台也是不同的。数据中台建设的第一步是做布局, 布局的第一步是全盘梳理企业的业务架构, 将业务划分为一个个独立业务, 在Dataphin外面就是业务板块的划分。 业务板块的划分总准则是, 高内聚, 低耦合, 具体的流程如下: 考查企业的所有的业务流程, 如果两个业务流程之间存在上下游的关系, 或者有独特的业务对象, 那么他们就应该被放到同一个业务板块。比方, 洽购流程(洽购单)完结后, 个别会有物流(企业的进货物流)这个流程. 物流是依赖洽购的, 同时货品是两个流程独特的业务对象, 因而, 洽购和物流就该当属于同一个业务板块. 将范畴扩充, 列举出每个业务流程的上下游和业务对象, 间接或者间接的连贯在一起的业务流程该当属于同一个业务板块. 举例: 批发业务中, 洽购->洽购物流->仓储->销售发货, 营销->销售->履约->售后等, 有的有上下游的关系, 有的能够通过货品连贯到一起, 他们就属于”批发”这一业务板块。反之, 如果两个业务流程之间不存在任何间接或者间接的上下游关系, 也没有间接或者间接独特的业务对象, 他们就不该当被放在同一个业务板块。举例: 同一个企业下, 可能有批发和地产. 地产业务中, 拿地->设计->开发->销售等流程与批发的业务流程之间不存在上下游的关系, 也没法通过某个业务对象连接到一起, 该当别离创立“批发”“地产”两个业务板块。值得注意的是, 某些业务对象是企业级共用的, 比方, 公司的员工, 行政地理区划(没错, 这个也属于业务对象) 等, 这些会将整个公司的所有的业务流程连贯到一个微小的繁多网络中。因而, 先要辨认出这些企业级的业务对象, 对于只通过这些业务对象连接在一起(而没有上下游关系)的业务流程, 须要剪断这种连贯, 将他们归属到不同的业务板块。 ...

简介：2021年6月9日，亚太内容散发大会暨CDN峰会在北京举办，阿里云边缘云网络高级技术专家张毅萍受邀参会，分享了阿里云在构建边缘云全站减速网络体系的实际，基于边缘云节点撑持各种利用协定的分层传输减速，为差异化的企业应用提供广覆盖的网络减速根底服务。2021年6月9日，亚太内容散发大会暨CDN峰会在北京举办，阿里云边缘云网络高级技术专家张毅萍受邀参会，分享了阿里云在构建边缘云全站减速网络体系的实际，基于边缘云节点撑持各种利用协定的分层传输减速，为差异化的企业应用提供广覆盖的网络减速根底服务。 张毅萍认为：速度是互联网业务中广受关注的业务指标，速度产生价值。视频与互动交互的场景下，速度对应的视频秒开率、播放卡顿率、视频清晰度、交互时延间接影响用户体验和留存；金融与电商交易场景下，每笔交易的申请响应速度以及成功率关系高价值业务运行；全站业务对接场景下，一站式减速对接可大幅晋升了业务对接效率是要害。 从内容减速到全站减速 全站减速是从内容减速降级而来。内容减速次要是动态内容的减速，例如视频点播、文件下载。CDN通过大量节点晋升用户申请效率和带宽的承载能力，基于缓存实现减速。除了视频点播、文件下载、动态网页这类可较长时间缓存的业务，大量对实时性业务呈现，须要更加依赖真正的网络减速而非就近动态缓存带来的体验减速，例如网络游戏、金融交易、实时音视频通信等。 基于边缘云节点的对立选路调度是要害 选路调度的实质是在差异化的客户业务/场景/资源，实现全局的性能/老本最优。资源即节点、网络，单个节点蕴含CPU算力、内存容量、存储IO、网络IO等；业务是长视频、短视频、下载、直播、金融交易、边缘渲染等等；场景包含缓存内容（耗费存储容量/IO、网络IO）、动静内容（耗费网络IO、CPU算力）、流量计算（耗费CPU算力、内存容量）； 选路调度能够了解为就是一种实时动静求解的过程，保障服务质量的前提下，尽可能把每种类型的资源都可能平均的耗费，尤其是边缘云节点CPU算力资源的无效利用。 智能协定栈是晋升服务质量的根底 联合业务、场景、环境差别匹配更适宜的传输协定栈，能够放大不同资源的服务差异性。在协定栈优化的场景中，划分为末端链路、两头链路、回源链路。 1）末端链路 面向终端，充分利用终端环境的数据差别，驱动匹配出最适配的传输算法。终端拜访时的网络环境、业务类型、工夫等方面的差别体现不同服务质量，传输协定匹配是最无效的优化品质的伎俩，同时还可能优化网络老本。 2）两头链路和回源链路 大规模的链路收敛，谋求传输品质和稳定性最优，容许就义局部老本，反抗公网传输的稳定和烦扰，实现链路容灾。 全链路诊断是实现故障疾速定位和疾速复原的基石 从业务视角疾速检测和定位异样点，晋升异样复原速度、晋升运维效率，可分为两类检测： 1）被动检测 包含TCP的打标数据统计，从七层业务切入，基于业务层Request/Response维度的打标跟踪，七层转四层时依据七层业务打标执行包染色，两头链路各类网关的染色包统计上报，到最初基于统计数据进行异样点诊断。 2）被动探测 借助大量的终端反馈最终用户视角的服务质量，通过自有的千级节点的精细化互相探测，联动异样自动化处理，此外还能够借助第三方播测平台来取得第三方视角的服务质量评定。 最终，将原来三/四/七层独立的品质检测降级为三/四/七层贯通关联，造成全站减速全链路品质的全局视角。 打造体系化的平安防护能力 在谈及网络安全时，最先想到的就是DDoS之类的流量攻打，这作为根本能力必定是须要具备的，是属于资源型的能力，单节点没有几百G的带宽储备，很难造成无效的抗D能力。阿里云具备足够防流量攻打的资源池。 张毅萍指出：除了资源侧防护，还须要构建安防体系，尤其是针对动静内容的平安防护，动静减速内容具备申请带宽小、业务价值大的特点，相比最根本的暴力流量攻打，针对动静内容，更多的是爬虫治理、业务防刷等性能。例如，电商网站的各种价格、下单等都是大量的动静内容数据，会面对爬虫、刷单等状况比拟多，须要做的防护也更多是针对这些来做的。通过建设起一套残缺的安防数据分析体系，与客户在业务层面做深度单干，独特定义什么样的动静申请是失常的，什么样的是异样的，以及不同业务的异样的申请都有哪些特色，如何应答能力尽可能进步安防能力的同时升高误伤概率； 平安防护体系的建设须要依附攻防积攒下来的技术和策略，而这才是最有价值的。 网络减速的外围能力也是打造边缘云体系的根底。在各个边缘利用场景下，底层网络的减速、多云之间的互联互通，能够帮忙构建边缘云生态，接口标准化、跨网络的协同、跨云的业务部署，给下层业务提供更广大、通用的基础设施能力。 演讲最初，张毅萍表白面向未来倒退认识：在边缘云生态的倒退中，零散的根底资源交付会越来越难以执行，场景利用解决方案式交付会是支流方向，凋谢单干共赢必将是主旋律，期待增强产业单干，共创边缘云生态。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：数禾通过构建本身的数据中台，买通以往独立建设的IT零碎，使得各方数据汇聚联通，最终造成一个弱小的数据决策引擎，岂但让消费者失去称心的服务体验，同时大幅升高平台方的经营老本。-更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 和关注官网微信公总号（文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index 淘宝开店入门10法、店铺经营必看20条、老手疾速把握的30项准则……各类电商经营文档布满了行将毕业的大学生刘浩的电脑桌面。 刘浩老家是浙西山区的一个小村子，从村头走到村尾拢共才42户人家，因为整个山区都被竹林笼罩，所以家家户户都世代承继了一门编竹条的手艺，从竹席、菜篮、箩筐，再到各种工艺小玩意儿，一应俱全。今年镇上常有人挨家挨户地来收成品，视物件大小现场定价，5元-30元是广泛行情，但刘浩晓得，这些货色在城里卖出，往往都是50元的起跳价。 和其余毕业生不同，刘浩心田始终有个小小的守业梦。 “为什么不能自己开一家淘宝店帮村里人卖货？” 只是，开店还须要有一笔20000元左右的启动资金，然而父母却并不反对刘浩的想法，在他们看来，大学生毕业后就该留在大城市找一份安稳工作。 好在现在的互联网金融服务倒退得愈发标准便捷，面向集体的小额贷款申请并不像过来那么简单，通过正规金融机构提供的助贷服务，当天下午，刘浩就从银行拿到了所需的贷款，开始了本人的守业之路。 用数据技术推动金融服务全面降级 得益于数字化在金融行业地全面落地，以及金融机构更加常态且正规化的助贷服务，越来越多的普通人可能像刘浩一样，享受到便当的信用贷款服务。 在数禾科技大数据负责人万鹏看来，现在的金融机构可能通过深度联合数据技术，扭转从前金融行业人工信审的低效状态，重塑银行与借款人间的双向服务通路。 数禾科技大数据负责人 万鹏 “一方面，咱们为银行挖掘新的需要群体，并提供包含信用评分在内的后期服务，极大缓解银行审核压力；另一方面，咱们在洞察借款人的需要上，可能为其匹配最合适的银行，使其能在最短的工夫内失去最优质的信用贷款。” 2015年，数禾科技正式成立，围绕消费信贷业务，为持牌金融机构和有贷款需要的消费者提供金融技术服务。 “咱们在人工智能、大数据等畛域投入了大量研发资源，心愿可能施展数字化、自动化、智能化的金融技术劣势，为更大基数的群体提供最优的金融服务，践行金融普惠。”万鹏说道，据理解，截至2021年5月，数禾科技曾经和超过70家银行等金融机构建设单干，笼罩超过8000万注册用户。 数据中台加持 让可见的数据流动在业务中 助贷服务作为数禾科技的主营业务之一，实质上是解决资金与互联网用户两者之间的信息不匹配问题，数禾通过数字化伎俩充沛洞察消费者信贷需要，为金融机构筛选精准有资质的贷款用户同时，为用户提供更便捷优质金融服务。 而这一服务模式的背地，数据正在成为贯通需求方和服务方之间最高效的连接桥梁。 对数禾来说，尽管凭借技术深耕生产金融畛域多年，但如何把业务流程中所产生的数据更高效地反哺业务，数禾还须要一套更欠缺的数据方法论和产品工具撑持。 这时候，阿里云数据中台进入了数禾视线。 因为非常看重数据资产对助贷业务的弱小撑持能力，2020年7月，数禾科技与阿里云正式建设单干，启动数据中台我的项目，万鹏作为大数据部门负责人，牵头数据中台我的项目建设的发展，以此帮忙数禾在数字化降级2.0策略大背景下，锁定数据能力劣势。 在数字化策略1.0阶段，数禾构建了实用的底层数据系统和业务利用零碎，但很多时候业务提出的数据需要往往以一对一的模式予以解决，不仅响应速度滞后，还导致烟囱状零碎林立。随着数据的量级增大，传统的数仓建设思路无奈高效地撑持企业数字化需要，数禾的管理层意识到解决数据孤岛问题，买通各个系统以及组织之间的协同，开释公司的共享能力和创新能力是数字化策略获得突破性停顿的要害动作。 之所以抉择阿里云数据中台作为数字化策略的底层技术撑持，万鹏提到了两个次要起因： “阿里巴巴最早提出数据中台概念，对中台认知最粗浅、解决方案最全面，派驻到现场的专家也都有丰盛的实战经验。” 阿里云数据中台的方法论体系也是数禾非常看重的能力之一。阿里云数据中台基于One Data方法论，通过Dataphin产品造成数据采集、治理、资产治理等能力矩阵，使得数据中台我的项目能在企业疾速落地。 万鹏提到：“阿里云数据中台自带One Service数据接口服务，之前咱们自研的数据平台，面向线上业务提供数据接口的链路太长太简单，目前通过阿里云数据中台产品Dataphin构建数据输入输出的链路既通顺又迅速，产品自身自带集成通道。” 通过7个月的共创共建，数禾的大数据团队把传统数仓体系进行重构降级，对立了数据资产治理平台，同时借助我的项目全面梳理了公司外围业务流程，将所有的业务过程及背地对应的数据串联起来，对立一套信息系统，每个业务过程在信息化平台都能看到具体的数仓表、指标、指标以后的值、环比同比等信息，一旦这些指标出现异常，就能够疾速自动化归因，定位问题环节，创新性建设了数据经营模式。 回顾数禾创建初期的数字化建设工作，万鹏示意：“过来5年，咱们更关注公司经营过程中产生了什么数据，哪些业务流程是能够数字化的，以及数据合规问题。往后看5年，数据量会越来越大，传统的数仓建设思路不再能撑持企业存数、管数、用数的需要，咱们须要一套更先进的数据工具和方法论，来解决咱们与消费者之间的信息不对称问题，打消了解偏差，通过数据来还原和预测用户的行为和想法。 “ 面向10亿互联网群体的普惠金融 当下的助贷需要旺盛，场景泛滥，单纯依附人工无奈保障借贷人能够及时享受到所需的金融服务。举例来说，当一个用户，他从社交平台、短视频平台、线下电梯广告等媒介渠道看到了借贷讯息，于是点击进入网页进行了相干信息的浏览，并在一段时间后在线提交了贷款申请。 面对这样一个用户，数禾应该如何为他提供所需的助贷服务？ 这里的“匹配”其实蕴含了十分多的维度判断，比方授信额度、核准率、放款速度等等。每个用户的理论贷款需要各不相同，无奈通过对立的服务内容来满足非标化的贷款需要，而这所有都须要数据来撑持后续一系列的经营决策，造成个性化的助贷服务模式。 数禾通过构建本身的数据中台，买通以往独立建设的IT零碎，使得各方数据汇聚联通，最终造成一个弱小的数据决策引擎，岂但让消费者失去称心的服务体验，同时大幅升高平台方的经营老本。 数据中台对于风控场景的增益也是不容忽视的。 行业倒退初期，风控伎俩繁多，获客集中于征信名单及企业获客。尔后，线上获客逐渐成为支流的渠道，风控伎俩从抵押物担保变为大数据建模，客户边界一直外拓，行业迎来高速倒退的时机背地，是对借款客户精准授信与危险定价的更高要求。 当更多的借款人涌入平台，危险老本是否可控是助贷平台须要思考的问题。只有在贷前审批环节精准评估，在核准率大幅晋升的同时，放弃危险程度根本稳固且信用核验老本降落，助贷平台能力拿到更可观的经营利润。 “切换到中台模式后，咱们不仅做到了数据融通，同时通过数据治理伎俩推动了数据标准化和资产化。这一系列动作强化了基于数据资产的智能风控模式，基于数据中台的对立模型、对立数据服务，新构建的风控模型可能接入数据品种越丰盛，就能把前期坏账率、中介欺诈率等危险指标降至最低。如中介模型能够对申请用户进行疑似金融中介监测，准确度能够做到超80%。“ 在数字化策略2.0阶段，数禾在本来信息化的根底上，依靠数据中台实现数智化降级。比拟直观的体现就是将经营动作尽可能做到全自动化或者半自动化。如技术层面，建设本人的策略及执行零碎；产品层面，提供更数字化、智能化的产品；服务层面，通过呼叫核心、智能机器人、智能知识库、智能质检、智能客服等让用户感触到数字化转型带来的便捷；风控层面，一直加深精细化经营，欠缺风控模型…… 从零碎层面，数据决策引擎和业务执行零碎实现解耦。数据决策引擎接入一系列业务执行零碎，以数据中台为外围实现数据分析、智能决策，而后造成操作指令作为输入，下发给决策指挥系统，从而让业务执行零碎逐渐实现从“人+零碎”到“机器人+零碎”的自动化、智能化流程降级，逐渐升高对人工决策的依赖。 这样做带来的益处，是随着中台我的项目的逐步推进，企业能够进行数字化成熟度自查，将脱漏的或者非标准化的业务流程通过调研梳理和对立建模进行标准定义，并在企业层面达到共识。企业的经营流程和要害指标通过数据串联起来，造成看板，管理层能够通过数据驱动疾速定位业务流程中哪个环节出问题，高效发现经营异动，并造成相应的经营策略或者管理策略调整。 数据中台的构建非一日之功，数禾科技的数字化2.0策略也还在继续推动。而如何在将来构建一套更残缺的“数智化体系”，是当下每一个数据从业者和企业治理都要去思考的命题。数据中台的继续经营，外围在于数据资产的建设、治理以及经营，数禾科技将会继续实际和提炼数据中台经营的最佳实际，在充沛开掘数据价值的同时，驱动业务高速倒退。   相干产品：智能数据构建与治理Dataphin 数据中台是企业数智化的必经之路，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。 目前正通过阿里云对外输入系列解决方案，包含通用数据中台解决方案、批发数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案、政务数据中台解决方案等细分场景。 其中阿里云数据中台产品矩阵是以Dataphin为基座，以Quick系列为业务场景化切入，包含： - Dataphin，一站式、智能化的数据构建及治理平台；- Quick BI，随时随地 智能决策；- Quick Audience，全方位洞察、全域营销、智能增长；- Quick A+， 跨多端全域利用体验剖析及洞察的一站式数据化经营平台；- Quick Stock， 智能货品经营平台；- Quick Decision，智能决策平台；官方站点： ...

简介：Quick Audience产品是一款云原生面向消费者的营销产品，自诞生以来，经验了三个倒退阶段。每个阶段的转变，都与互联网环境和消费者行为的变迁有着极大的关联。 Quick Audience是云原生的面向消费者的营销平台，涵盖了从公域引流，到私域互动，到电商转化，再到会员治理全链路流程，包含了模型构建、洞察圈选、用户触达、开放平台等性能，它的每一步的转变，都与互联网环境和消费者行为变动有着极大的关联。 Quick Audience产品中转：https://www.aliyun.com/product/retailadvqa Quick Audience产品的诞生Quick Audience产品是一款云原生面向消费者的营销产品，自2017年阿里巴巴数据中台开启商业化之路后，在服务企业数据中台构建的过程中，发现很多企业在市场做营销时的一些问题。 营销流动开始之前，面对消费者的引流伎俩匮乏，在商超或者线下门店，仍会发现在以发传单的形式对行将到来的流动进行引流和宣传，效率低下且成果甚微。 有些企业没有对消费者资产进行任何的积淀，仅在CRM中留存一些客户资料。企业的消费者到底是谁，他们的画像是怎么的？所有都无从得悉。 而在营销流动进行的当下，企业能做的事件就更少了。零售商坊间流传着一种说法：围观营销流动就像看电影一样，一旦开始放映，就只能眼看着它完结，即便过程中察觉状况不妙，也不得不眼睁睁的承受无奈达成业绩的事实。 阿里巴巴以电商业务起家，在线上、线下的营销流动中有着丰盛的教训。面对平台商家以及更宽泛的客户遇到的营销问题，信心以落地产品的形式帮忙大家。 营销形式和链路具备肯定的普适性，阿里巴巴数据团队在2018年孵化出了Quick Audience产品，并将它定位为CDP——企业本人的消费者数据资产治理和经营平台。帮忙企业通过便捷的工具，积攒消费者资产。深度洞察自有消费者，清晰画像，实现精密、精准的消费者经营。 产品倒退紧扣消费者行为变迁Quick Audience诞生以来，经验了三个倒退阶段。每个阶段的转变，都与互联网环境和消费者行为的变迁有着极大的关联。 2018年底到2019年中，Quick Audience的聚焦解决的问题只有有三个： 1）如何帮忙消费者构建他们的消费者资产，外围是消费者标签； 2）如何更好的让企业理解本人的生产，外围是洞察剖析。通过标签透视剖析或配置化界面，疾速的构建RFM模型，实现散布剖析。通过配置疾速的构建AIPL模型，实现流转剖析等。 3）如何能够更灵便的圈选出指标人群，外围是圈选形式；能够用构建的用户模型圈人，也能够基于用户的行为圈人。同时还反对不同模式、不同人群包之间的交并圈选。 2019下半年到2020年初，这个阶段Quick Audience聚焦解决的问题是触达。 在实现了模型构建，洞察剖析，灵便圈选之后，便捷的触达消费者是下一阶段攻克的主题。于是Quick Audience除了用户营销和自动化营销的模块之外，扩大反对了巨量引擎、腾讯广告等通用广告平台。反对短信、邮件、微信、微博、Push等私域渠道，同时通过MA的工具，能够编排消费者的触达旅程，实现自动化的触达链路。 2020年疫情的暴发，将生产的工夫更多的线上化，碎片化。在疫情的冲击下，很多企业在经营上都遇到了极大的艰难，企业面向消费者的营销也逐步转到本人的私域进行经营，于是社交平台的粉丝互动、导购、社群经营需要逐步火爆。这个阶段Quick Audience重点围绕企业私域的粉丝社交、全域会员治理能力做了极大的补充，能够反对微信社交平台的粉丝治理、流动小程序、粉丝互动等。同时和全域CRM买通，做会员治理。此时的Quick Audience更加凋谢，模型、受众等通用能力造成OpenAPI，能够跟企业的营销平台互通，满足企业的个性化消费者经营诉求。 现有外围能力笼罩全营销流程至今，Quick Audience曾经涵盖了从公域引流、到私域互动，到电商转化，再到会员治理流程的全链路笼罩，产品的整体架构蕴含如下外围局部： 数据采集：通过数据同步，接口对接，以及日志采集等形式，疾速实现消费者资产的接入；模型构建：通过疾速的配置风湿实现，规范的标签模型、行为模型、FRM、AIPL等用户模型的构建；洞察圈选：通过画像，模型等剖析理解消费者，同时能够通过标签、行为、模型等疾速的圈选出受众；用户触达：通过广告投放、社交互动、全域会员等全渠道的消费者触达和互动，让咱们跟消费者更近；消费者触达旅程编排：通过丰盛的组件拖拽形式，实现消费者触达旅程的自动化执行；开放平台：能够通过调用Quick Audience的接口，实现同Quick Audience产品的疾速对接，反对不必场景的消费者经营；版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：浦东、闵行、宝山、嘉定是上海新能源汽车散布最多的4个区域；上海私用新能源车工作日均匀行驶里程40多公里……目前，上海市新能源汽车数据平台日采集信息曾经超过6.6亿条，平台数据采集量已超PB，为全市新能源汽车示范推广、政策制订、车辆剖析等提供无效决策依据。据介绍，该平台基于阿里云原生多模数据库Lindorm开发而成，领有高并发写入和实时检索剖析能力，可依据信息采集量的增长进行弹性扩大，数据存储老本非常低。浦东、闵行、宝山、嘉定是上海新能源汽车散布最多的4个区域；上海私用新能源车工作日均匀行驶里程40多公里……目前，上海市新能源汽车数据平台日采集信息曾经超过6.6亿条，平台数据采集量已超PB，为全市新能源汽车示范推广、政策制订、车辆剖析等提供无效决策依据。据介绍，该平台基于阿里云原生多模数据库Lindorm开发而成，领有高并发写入和实时检索剖析能力，可依据信息采集量的增长进行弹性扩大，数据存储老本非常低。 上海市新能源汽车数据平台由上海市新能源汽车公共数据采集与监测钻研核心负责建设并经营，是全国首个、上海市惟一的新能源汽车市级监管平台。截至2021年1月31日，上海市新能源汽车曾经接入新能源汽车41.8万辆，波及车企95家，品牌107个，车型777款，数据存储量冲破1个PB，数据规模持续处于寰球城市前列。 上海市新能源汽车数据平台每天都会对接入的新能源乘用车和商用车的出行里程、充电工夫等多维度数据进行采集，而随着不同品牌及型号车辆的接入量快速增长，数据品种和构造出现多样化，给平台的经营和保护提出了技术挑战，并且推高了老本。 为保障全上海的新能源车安稳地“跑”在这个平台上，上海市新能源汽车公共数据采集与监测钻研核心在要害数据库上选用了阿里云原生多模数据库Lindorm，利用后者的高并发写入、弹性扩大、实时检索剖析等能力，以及欠缺的数据通道保障，确保数据能实时同步至离线计算平台，保障了数据采集、加载、剖析、计算链路整体的稳固、高效，以及低成本。 上海市新能源汽车数据平台技术负责人王成名示意，阿里云Lindorm数据库的引入使得数据采集入库性能晋升3倍以上、老本升高20%以上；对于采集点及采集频率变更带来的流量突增也能够从容应对，很好地撑持了业务疾速倒退。 据理解, 阿里云原生多模数据库Lindorm反对海量数据的高性能、高吞吐、低成本存储与检索剖析，反对云原生存储计算拆散技术，具备极致弹性能力，历经了阿里巴巴经济体10多年磨难，撑持了淘宝、天猫、支付宝、菜鸟网络等外围业务。去年9月，Lindorm数据库正式对外提供服务，帮忙汽车、金融、工业物联网等畛域的客户依据业务规模弹性伸缩，匹配业务的快速增长。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：本文由知乎技术平台负责人孙晓光分享，次要介绍知乎 Flink 数据集成平台建设实际。内容如下： 1. 业务场景 ； 2. 历史设计 ； 3. 全面转向 Flink 后的设计 ； 4. 将来 Flink 利用场景的布局。 本文由知乎技术平台负责人孙晓光分享，次要介绍知乎 Flink 数据集成平台建设实际。内容如下： 业务场景历史设计全面转向 Flink 后的设计将来 Flink 利用场景的布局一、业务场景很快乐和大家分享近期知乎以 Flink 为根底，重构上一代数据集成平台过程中的一些播种。数据集成平台作为连贯各种异构数据的纽带，须要连贯多种多样的存储系统。而不同的技术栈和不同的业务场景会对数据集成系统提出不同的设计要求。 咱们首先来看一下在知乎外部数据集成的业务场景。同许多互联网公司类似，过来知乎的在线存储系统次要以 MySQL 和 Redis 为主，同时对于局部数据量级较大的业务也应用了 HBase。近年来随着技术的演进，咱们开始了从 MySQL 向 TiDB 的迁徙。与此相似，咱们也开始将 HBase 向基于 TiKV 技术栈研发的 Zetta 演进。在离线存储方面绝大多数的场景则是以 Hive 表来撑持的。 从在线存储到离线存储，期间有着十分强的数据同步需要。除此以外也存在着大量的流式数据，比方音讯零碎中的数据，咱们也心愿它可能同各种在线或离线存储系统买通。过来知乎次要应用 Kafka 撑持流式数据，近期也开始引入 Pulsar。这两套音讯零碎同存储系统之间的数据交换存在着较强的需要。 在知乎的业务场景和以后倒退状态下，数据集成工作在技术和流程治理上都存在着一些挑战。 首先从技术角度看，数据源多样化会对数据集成系统的连贯扩大能力提出较高的要求。而且下一代的存储系统在给业务带来更强能力的同时也开释了业务的压力，进而促使了数据量的减速收缩。数据量级上的快速增长对数据集成平台的吞吐和实时性都提出了更高的要求。当然作为数据相干的根底零碎，数据准确性则是最根底的要求，这块咱们也必须把它做好。另外从流程治理角度看，咱们须要了解并整合散落在不同业务团队的数据，做好治理并确保数据拜访的平安，所以整个数据整合的流程是绝对简单的。尽管平台化可能将简单的流程自动化起来，但数据集成工作所固有的高老本并不能齐全以平台化的形式打消。因而尽最大的可能晋升流程的可复用性和可管理性也是数据集成系统须要继续应答的挑战。 基于这两个方向上的挑战，咱们对数据集成平台的设计指标进行了布局。 从技术方向看，咱们须要反对知乎曾经投入使用和未来要推广应用的多种存储系统，具备将这些零碎中多样化的数据进行集成的能力。此外咱们还须要在满足高吞吐，低调度时延的前提下保障数据集成的可靠性和准确性。从流程方面看，能够通过整合各种外部存储系统的元数据以及调度零碎，复用现有零碎基础设施的能力，达到简化数据接入流程，升高用户接入老本的目标。咱们还心愿可能以平台化的形式为用户提供自助满足数据需要的伎俩，从而晋升数据集成工作的整体效率。从晋升工作可管理性的角度看，咱们还要保护好数据的血缘关系。让业务更好的去度量数据产出之间的关系，更无效的评估数据产出的业务价值，防止低质量和重复性的数据集成工作。最初咱们须要对所有工作提供系统化的监控和报警能力来保障数据产出的稳定性。 二、历史设计在知乎的第一代数据集成平台成型前，大量的工作散落在各个业务方本人保护的 crontab 或者自行搭建的各种调度零碎中。在这样的无治理状态下，各项集成工作的可靠性和数据品质都很难失去无效的保障。因而在这个阶段咱们要最迫切解决的是治理上的问题，让数据集成的流程可治理可监控。 因而，咱们整合了各种存储系统的元数据系统，让大家能够在对立的中央看到公司所有的数据资产。而后在调度核心对立治理这些数据的同步工作，由调度核心负责工作的依赖治理。同时调度核心对工作的要害指标进行监控并提供异样告警能力。在这个阶段咱们沿用了从前大家宽泛应用的 Sqoop 来实现 MySQL 和 Hive 之间数据的同步。且在平台建设前期，随着流数据同步需要的呈现，咱们又引入了 Flink 来同步 Kafka 数据到 HDFS。 ...

一、硬件环境1、海创Box智能网关 2、西门子PLC (ST20 S7-200) 二、产品连贯形式 三、产品配置海创Box智能采集网关 西门子PLC (ST20 S7-200) 配置好设施连贯ip 四、我的项目部署调试       关上海创-IIoT。本次教程须要用到如下节点，在左侧节点栏中拖拽出应用 定时器周期性触发输出工夫戳或者相应的字符 S7西门子用于读取S7西门子通信协议的设施数据 调试用于调试节点输入        配置相应节点后配置界面如下： 节点配置： 定时器设置成周期性触发，次要当触发流程应用，具体配置如下图 S7西门子设置如下配置，即可取到M区0.1的地址数据 调试在右侧调试窗口输入调试后果，无需配置 部署调试：        依照以上教程配置好流程后，点击部署，部署胜利后程序开始运行，就会在调试窗口输入相应的后果，调试后果如下：

增长关乎产品的存亡增长！增长！增长！业务增长是每一个创业者每天面临的最大问题。无论你的产品是APP，还是web，或者是小程序，只能不断的维持用户的增长，才能向资本市场讲出一个好故事，融资活下去。活到最后的产品，才有机会盈利。 为了获取用户的增长，可以投放广告，也可以内容营销、社交传播、销售地推，或者持续的专注于产品优化。无论哪一种方式，我们都面临这几个问题： 运营活动，覆盖了多少用户？多少用户，开始使用产品？多少用户付费？多少用户持续的活跃？下一步，我们应该把精力放在哪些方面？是持续运营？还是开发新功能？ 如果不能回答这些问题，无疑我们的运营活动或者开发就是盲人摸象，完全靠运气。为了解答这些问题，我们不妨关注一下growth hacking这种数据驱动的手段。 Growth Hacker的核心思想传统的市场营销策略，例如投放电视广告，覆盖了多少人，有多少人看过广告后进行了购买，多少人进行了复购，没有准确的数据进行衡量，只能依赖于资深专家根据经验判断。在互联网行业，每一个产品都是新的，前所未有的。每一个产品能不能存活，每一次运营的效果如何，没有多少经验可供借鉴，结果是不确定的。 GrowthHacking是兴起于硅谷的创业公司的marketing手段，旨在使用少量预算获得巨量增长。由于其极高的性价比和有效性，非常适合于创业公司，因而得到了广泛传播。 Growth Hacker的核心思想是通过数据指标，驱动运营决策，以及优化产品。Growthacker通过关注用户获取、用户转化、用户留存、用户推荐、盈利等核心的一系列指标，以及通过各种维度拆解，分析出下一步的增长决策。通过Growth Hacking，打造一个产品增长策略的闭环。 那么我们如何才能搭建出GrowthHacking架构，为自己的产品赋能呢？ GrowthHacking之架构Growth Hacking 包含了数据的采集、存储、分析、报表、A/B test等系统，首先我们来看，传统的解决方案，搭建出GrowthHacking有哪些痛点： 搭建运营体系的痛点搭建运营体系的过程中，常常面临以下问题： 缺少数据，数据散落在各个地方,有的是app数据，有的是web数据，有的是小程序数据，没有一个统一的架构来把数据采集到一个地方。缺少一个分析平台。传统的策略，需要运维团队帮助搭建hadoop集群，需要专门团队持久运维。离线跑报表，一晚上才能拿到一次结果，周期太长。手工跑一次，几个小时过去了，有什么新的想法，不能及时验证。严重影响运营效率。借助云服务搭建的GrowthHacking技术架构为了解决以上问题， 日志服务提供了日志采集、存储、交互分析、可视化的一整套基础设施，可以帮助用户快速搭建出来灵活易用的Growthing Hacking的技术架构，每天的工作只需要专注于运营分析即可。 Growth Hacking首先从数据采集开始，定义清楚要采集的日志内容、格式。把各个终端、服务器的日志集中采集到云端的日志服务。后续通过日志服务提供的SQL实时分析功能，交互式的分析。定义一些常规报表，每日打开报表自动计算最新结果，也可以定义报告，自动发送最新报表。全部功能参考用户手册 此外，除了日志数据的分析，还可以为用户定义一些标签，存储在rds中，通过rds和日志的联合分析，挖掘不同标签对应的指标。 日志服务有如下特点： 免运维：一次完成数据的埋点、数据接入，之后只需专注于运营分析即可，无需专门的运维团队。实时性：用SQL实时计算，秒级响应。快人一步得到分析结果。灵活性：任意调整SQL，实时获取结果，非常适合交互式分析。弹性：遇到运营活动，流量突然暴涨，动动手指快速扩容。性价比：市场上常见的分析类产品，多采用打包价格，限制使用量。日志服务按量付费，价格更低，功能更强大。借助于日志服务提供的这套数据采集、存储、分析的基础设施。运营者可以从繁重的数据准备工作重解脱出来，专注于使用SQL去分析数据，配置报表，验证运营想法。 开始搭建GrowthHacking系统具体而言，Growth Hacking的架构可以拆分如下： 数据收集 定义埋点的规范，定义要采集的事件内容、字段、格式。通过Android SDK,iOS SDK, Web tracking等手段在客户端埋点。存储 选择日志服务的region。定义每一种日志存储的Project & LogStore。分析 开启分析之路，定义常规报表，或者交互式分析。通过分析结果，调整运营策略，有针对性的优化产品。基于日志服务，可以完成Growth Hacking的分析策略： 定义北极星指标。拉新分析。留存分析。事件分析。漏斗分析。用户分群。A/B test。在日志服务中，可以通过定义一系列仪表盘，来沉淀数据分析的结果。接下来的几篇文章中，将依次介绍如何在日志服务实现上述几种策略。 总结本文主要介绍Growth Hacking的整体架构，之后将用一系列文章介绍step by step如何介入数据，如何分析数据。 本文作者：云雷 阅读原文 本文为云栖社区原创内容，未经允许不得转载。

摘要：阿里云TSDB是阿里自研的一种高性能，低成本，稳定可靠的在线时序时空数据库产品。该产品统一了阿里巴巴集团90%以上的APM数据和事件型数据的存储和计算，并在广泛应用于外部的物联网，工业制造，电力，化工以及IT运维等行业。本文中，阿里云智能数据库产品事业部技术专家伊翼就为大家介绍了阿里云TSDB的种种黑科技。专家简介：伊翼（花名：老滚）。阿里云智能数据库产品事业部技术专家，主要从事TSDB核心引擎的研发工作。 直播回放 链接：https://yq.aliyun.com/live/1044 议题PPT下载，戳这里！ https://yq.aliyun.com/download/3563 本次分享的内容主要包括以下四个方面： 走进时序数据库认识阿里云TSDB阿里云TSDB技术内幕未来与展望一、走进时序数据库熟悉而又陌生的时序数据时序数据库本身是一个比较新的概念，直到5年前，DB-Engine才将时序数据库列为一个独立的分类。虽然时序数据库的概念比较新，但是时序数据却由来已久。从古至今，在我们的日常生活中，时序数据从未缺席。古代记录灾害与祥瑞出现时间的县志也能够发挥类似今天时序数据库的作用，帮助决策者指定相关的决策，地方官员可以根据县志中的记录判断是否需要进行祭祀，也可以决策是否需要向中央朝廷报告祥瑞以谋取升迁等，因此当时的县志也发挥了类似于OLAP的功能。但由于理念和技术的限制，当时所记录的时序数据信息是有限的，精度也是有限的。 技术发展到今天，时序数据所能记录的信息和精度都有了极大的提升。如下图所示的是杭州市空气监测时序数据片段。由此可以看出，时序数据有一些共同的特征，比如多样的指标值、比较稳定的采集频率以及任何一个数据点都有时间戳。在技术飞速发展的今天，时序数据的规模越来越大，增长速度也越来越快。因此，我们需要面对一些问题，比如面对如此大规模的时序数据，应该将其存放在哪里。 时序数据库的概念 在十几年前，时序数据只能选择存放在关系型数据库中，但是随着通信技术的发展，特别是互联网技术的发展，时序数据的增长速度呈现指数级别，使用关系型数据库来存储时序数据显然跟不上时代的节奏了，所以时序数据库应运而生。时序数据库就是一类专门为处理时间序列数据而设计并优化的数据库管理系统。 相较传统的关系型数据库，时序数据库的特点如下： 存储的任何一条数据记录都必然带一个时间戳 通常高频访问热数据 数据写入频率相对稳定，且远大于数据读取的频率 通常按照时间窗口查询数据 基本不提供单点数据的更新或删除功能 无需提供类似关系型数据库事务级别的数据强一致性 目前，使用时序数据库的行业应用越来越广泛。 电力行业：智能电表、电网、发电设备的集中监测 交通行业：实时路况，路口流量监测，卡口数据的采集与分析 石油石化：油井、运输管线、运输车队的实时监测 物流行业：车辆、集装箱的追踪监测 环境监测：天气、空气、水文、地质环境等监测 物联网：电梯、锅炉、机械、水表、气表等各种联网设备的数据采集、分析与检测 军工行业：军事装备的数据采集、存储与分析 制造业：生产过程管控，流程数据、供应链数据采集与分析 互联网：互联网应用的PV/UV数据，基础设施的性能监控 时序数据库的迅猛发展 由于时序数据库的适用性非常广泛，因此其在DB-Engine上的受关注度一直处于增长态势。面对这样的关注度增长态势，时序数据库技术的发展也作出了积极的响应。无论是在开源领域还是商用领域，都推出了大量的时序数据库产品，比如InfluxDB、OpenTSDB、TimescaleDB以及阿里云时序时空TSDB等。 二、认识阿里云TSDB阿里云时序时空TSDB架构 如下图所示的是阿里云时序时空TSDB的整体架构，从左到右依次是采集端、TSDB服务端以及靠近最终用户和开发者的实例端。在采集端，阿里云时序时空TSDB采用了边缘计算的解决方案，其可以应用在资源受限或者网络状况不稳定的场景下。采集端可以和服务端进行打通，服务端可以向边缘下发各种各样的规则，使得边缘端能够直接进行数据清洗和计算，这就实现了“边云一体化”。图中的中间部分是TSDB的服务端，它也分为几个组件，TS计算引擎主要负责预聚合、降精度以及持续查询，TSQL引擎主要负责处理SQL查询，此外还有一个基于已经训练好的模型算法库，提供各行业定制化解决方案的智能引擎。在这三个引擎下面就是TSDB的时序引擎。 接下来为大家介绍阿里云时序时空TSDB在功能层面的一些特性。 特性1：强力的数据模型支持 阿里云TSDB支持多样的数据模型，同时支持了多值模型和单值模型。举例而言，温度监控设备需要每间隔一段时间向数据库上报温度数据，其上报的数据中必然带有一个时间戳以及温度值，这样最基础的数据形式称之为单值模型。而如果上报的数据中不仅仅包含了一个时间戳和室内温度，还包含了室外温度以及空气湿度等，这样的数据就可以称之为多值模型。其实，时序数据库对于多值模型的支持并不是行业要求，因此即便是在开源领域，各种数据库对于多值模型的支持也不同。支持多值模型的好处在于可以提升数据的写入效率，另外一方面就是对于业务应用的开发者而言可以使得设计更加直观。 除了对于多值模型的支持之外，阿里云TSDB还支持多种的数据类型，不仅支持传统数据类型，还能够支持字符串类型数据，并且能够支持精确到毫秒的时间戳。 特性2：降采样&数据聚合 对于时序数据库而言，降采样和数据聚合也是非常重要的特性。依旧以温度采集为例，温度采集设备可能上报数据的频率非常高，比如每秒钟上传一次数据，但是在做数据查询的时候并不需要按照原始的数据采集频率进行分析和展示，因此就需要对于上报的数据进行降采样操作，比如将按秒采样的数据降采样为按小时或者按天进行分析和展示。 与之相对的，数据聚合在分析和展示中也非常重要。通常情况下，有很多个数据采集设备，不同设备每隔一段时间上报数据的时候就认为这些数据属于不同的时间序列，而随着设备的增多，必然使得时间序列变得非常多，而在做分析和查询的时候并不需要对多个时间序列进行分析，只需要将其进行汇总，比如使用汇总后的平均值进行分析。这种情况下就是对于一个数据的指标值按照时间维度将多个时间序列聚合成一条，这就是数据聚合。无论是降采样还是数据聚合，阿里云TSDB都提供了非常丰富的聚合算子，有了这样的能力，就可以仅凭借阿里云原生能力来满足各种复杂的查询分析场景。 特性3：SQL查询能力 由于时序数据库本身属于比较新的概念，为了降低开发人员以及数据分析人员使用时序数据库的门槛和学习成本，阿里云TSDB也提供了基于SQL的查询接口。有了SQL的查询接口，用户就可以非常方便地使用SQL来操作时序模型。而阿里云TSDB的SQL接口也基于时序场景进行了算法上的优化，可以将SQL中的过滤、聚合等操作全部下推到TSDB的内核中，这样就可以最优化的方式来处理时序数据的分析和查询。 特性4：内置对接Prometheus 在最新版的阿里云TSDB中，已经实现了内置对接Prometheus的能力。Prometheus是一个非常适用于监控Kubernetes集群的工具，但是其对于监控数据的存储能力比较薄弱，虽然社区也考虑到这一点并且提供了Prometheus Adapter的第三方组件来将Prometheus的数据对接到各种各样的数据源上，但是当数据链路中增加一个组件就意味着查询性能的降低。为了在阿里云TSDB对接Prometheus的同时保持较高的查询效率，TSDB内置了对接Prometheus的能力。经过测试，内置对接Prometheus的方式相对于经由Prometheus Adapter中转方式的查询性能要高很多。 特性5：边缘计算能力 阿里云TSDB的边缘端计算能力处于行业内的领先地位。因为在物联网应用和工业大数据的应用场景中，无法保证数据的采集端是实时在线的，这样的场景就是边缘计算的用武之地。考虑到用户数据的可用性，TSDB边缘端再设计的时候也采用了高可用架构。当网络状况恢复稳定的时候，边缘段会将数据同步给阿里云TSDB服务端，这样可以方便用户在服务端进行统一的数据分析和查询。 与其他时序数据库的功能对比 下图中的表格列出了目前主流的时序数据库在功能特性上的支持情况对比。 接下来为大家介绍几个阿里云TSDB实际的应用案例。 案例1: 某互联网餐饮系统研发企业 该企业在自己的解决方案中将阿里云TSDB整合了进去，利用阿里云TSDB高性能写入将整个链路中的所有时序数据以及业务指标全部写入了TSDB中，借助TSDB优越的查询性能以及将监控系统整合在一起，从而支持了对于整个解决方案中所有链路节点的实时监控，与此同时提高了系统的整体稳定性。 案例2:某直播平台运维监控APM 该直播平台原来的APM系统中将所有采集到的时序数据全部通过消息队列存储到OpenTSDB集群中，但是很快就发现OpenTSDB的写入存在瓶颈，而且OpenTSDB在时序索引方面天生存在薄弱点，因此在面向较为复杂的查询的时候，几乎处于不可用的状态。在经过比较之后，该直播平台选择使用阿里云TSDB来替换所有的OpenTSDB，并且加大了写入规模，从实际效果来看，阿里云TSDB达到了所期望的效果。 案例3: 阿里巴巴集团内部全业务对接 最后的一个案例是阿里巴巴集团内部的案例。从上图可以看出，无论是底层的资源调控、整体监控还是上层应用，阿里云TSDB已经覆盖了阿里集团内部的130余个线上业务。而在2018年双11大促期间，阿里云TSDB承接的来自于阿里集团内部的各个业务的时序数据，写入TPS峰值达到了4000万TPS，查询峰值达到了2万QPS，累计时间线数量超过了100亿。 三、阿里云TSDB技术内幕时序时空TSDB引擎的核心技术 阿里云时序时空TSDB引擎具有很多的核心技术，在本次分享中主要为大家介绍数据压缩、时序索引以及聚合引擎三个方面的核心技术。 数据压缩 时序数据的规模增长速度很快，而用户往往出于日后需要进行查询或者分析的考虑，希望所能够存储的时序数据越多越好。但是通常情况下，对于大规模时序数据的查询而言，往往非常困难。一方面需要满足用户对于查询的需求，另外一方面需要有效地降低用户存储的成本。针对于以上两方面的诉求，阿里云TSDB研发了一套数据压缩技术。下图中左侧是一张示意图，其每一行代表一个时间序列，其列代表数据点。在没有进行数据压缩的情况下，如果想要将其数据调整到毫秒级别，就会发现其列数会增加到360万，这样的数据量是非常可观的，所以必须要进行压缩。阿里云TSDB所采用的压缩思路借鉴了Facebook Gorilla的实现思路，会将时间戳和数据两块压缩成两个大数据块，对时间戳采用了delta-delta的压缩方法，而对于不同的数据类型则采用了相应的数据压缩算法。在压缩成两个大数据块基础之上，再对其进行通用的块压缩。经过两部分的压缩就使得数据压缩比达到15:1的效果。 如下图所示的是真实场景下的数据压缩效果。原始情况下数据大约6TB，一开始尝试最普通的块压缩，将数据压缩到了715G，但此时的数据压缩比不到10:1，而采用先进行时序压缩再追加一次块压缩后使得最终数据压缩为413G，压缩比达到了15:1。那么，追求如此之高的数据压缩比有什么好处呢？其实主要有两个好处，第一个好处就是能够帮助用户降低存储成本；另外一个好处就是因为数据压缩比很大，因此当在进行大范围的时序数据查询的时候，IO效率会非常高，在这个例子中可以将查询延时降低约50%。 时序索引 TSDB的整体查询流程非常简单，当用户指定了一个查询条件，阿里云TSDB首先会解析这个查询条件，同时做一定程度的优化。接下来会做两件事情，一件是将查询条件扔给时序索引模块，时序索引模块会根据查询条件计算命中的时间线数量以及相关信息，拿到时间线信息之后再将时间线集合扔给聚合索引，聚合索引再到底层存储上面获取相应的时间数据并进行降采样、聚合等操作。虽然这一过程看上去比较简单，但是却存在很多值得研究的点。 如下图所示的是时间线的生命周期，如果用户想要查询T2-T3时间范围内的数据，肯定不希望数据中包含T0-T2已经消亡或者说不再有新的数据进来的时间线，所以这部分也是时序索引可以进一步研究的地方。 ...

摘要： 将在QCon上分享的《阿里PB级Kubernetes日志平台建设实践》整理出来，分享给大家。阿里PB级Kubernetes日志平台建设实践QCon是由InfoQ主办的综合性技术盛会，每年在伦敦、北京、纽约、圣保罗、上海、旧金山召开。有幸参加这次QCon10周年大会，作为分享嘉宾在刘宇老师的运维专场发表了《阿里PB级Kubernetes日志平台建设实践》，现将PPT和文字稿整理下来，希望和更多的爱好者分享。 计算形态的发展与日志系统的演进 在阿里的十多年中，日志系统伴随着计算形态的发展在不断演进，大致分为3个主要阶段： 在单机时代，几乎所有的应用都是单机部署，当服务压力增大时，只能切换更高规格的IBM小型机。日志作为应用系统的一部分，主要用作程序Debug，通常结合grep等Linux常见的文本命令进行分析。随着单机系统成为制约阿里业务发展的瓶颈，为了真正的Scale out，飞天项目启动：2009年开始了飞天的第一行代码，2013年飞天5K项目正式上线。在这个阶段各个业务开始了分布式改造，服务之间的调用也从本地变为分布式，为了更好的管理、调试、分析分布式应用，我们开发了Trace（分布式链路追踪）系统、各式各样的监控系统，这些系统的统一特点是将所有的日志（包括Metric等）进行集中化的存储。为了支持更快的开发、迭代效率，近年来我们开始了容器化改造，并开始了拥抱Kubernetes生态、业务全量上云、Serverless等工作。要实现这些改造，一个非常重要的部分是可观察性的工作，而日志是作为分析系统运行过程的最佳方式。在这阶段，日志无论从规模、种类都呈现爆炸式的增长，对日志进行数字化、智能化分析的需求也越来越高，因此统一的日志平台应运而生。日志平台的重要性与建设目标 日志不仅仅是服务器、容器、应用的Debug日志，也包括各类访问日志、中间件日志、用户点击、IoT/移动端日志、数据库Binlog等等。这些日志随着时效性的不同而应用在不同的场景： 准实时级别：这类日志主要用于准实时（秒级延迟）的线上监控、日志查看、运维数据支撑、问题诊断等场景，最近两年也出现了准实时的业务洞察，也是基于这类准实时的日志实现。小时/天级别：当数据积累到小时/天级别的时候，这时一些T+1的分析工作就可以开始了，例如用户留存分析、广告投放效果分析、反欺诈、运营监测、用户行为分析等。季度/年级别：在阿里，数据是我们最重要的资产，因此非常多的日志都是保存一年以上或永久保存，这类日志主要用于归档、审计、攻击溯源、业务走势分析、数据挖掘等。在阿里，几乎所有的业务角色都会涉及到各式各样的日志数据，为了支撑各类应用场景，我们开发了非常多的工具和功能：日志实时分析、链路追踪、监控、数据清洗、流计算、离线计算、BI系统、审计系统等等。其中很多系统都非常成熟，日志平台主要专注于智能分析、监控等实时的场景，其他功能通常打通的形式支持。 阿里日志平台现状 目前阿里的日志平台覆盖几乎所有的产品线和产品，同时我们的产品也在云上对外提供服务，已经服务了上万家的企业。每天写入流量16PB以上，对应日志行数40万亿+条，采集客户端200万，服务数千Kubernetes集群，是国内最大的日志平台之一。    为何选择自建                       日志系统存在了十多年，目前也有非常多的开源的方案，例如最典型的ELK(Elastic Search、Logstash、Kibana)，通常一个日志系统具备以下功能：日志收集/解析、查询与检索、日志分析、可视化/告警等，这些功能通过开源软件的组合都可以实现，但最终我们选择自建，主要有几下几点考虑： 数据规模：这些开源日志系统可以很好的支持小规模的场景，但很难支持阿里这种超大规模（PB级）的场景。资源消耗：我们拥有百万规模的服务器/容器，同时日志平台的集群规模也很大，我们需要减少对于采集以及平台自身的资源消耗。多租户隔离：开源软件搭建的系统大部分都不是为了多租户而设计的，当非常多的业务 / 系统使用日志平台时，很容易因为部分用户的大流量 / 不恰当使用而导致打爆整个集群。运维复杂度：在阿里内部有一套非常完整的服务部署和管理系统，基于内部组件实现会具备非常好的运维复杂度。高级分析需求：日志系统的功能几乎全部来源与对应的场景需求，有很多特殊场景的高级分析需求开源软件没办法很好的支持，例如：上下文、智能分析、日志类特殊分析函数等等。 Kubernetes日志平台建设难点围绕着Kubernetes场景的需求，日志平台建设的难点主要有以下几点： 日志采集：采集在Kubernetes中极其关键和复杂，主要因为Kubernetes是一个高度复杂的场景，K8s中有各式各样的子系统，上层业务支持各种语言和框架，同时日志采集需要尽可能的和Kubernetes系统打通，用K8的形式来完成数据采集。资源消耗：在K8s中，服务通常都会拆的很小，因此数据采集对于服务自身的资源消耗要尽可能的少。这里我们简单的做一个计算，假设有100W个服务实例，没个采集Agent减少1M的内存、1%的CPU开销，那整体会减少1TB的内存和10000个CPU核心。运维代价：运维一套日志平台的代价相当之大，因此我们不希望每个用户搭建一个Kubernetes集群时还需再运维一个独立的日志平台系统。因此日志平台一定是要SaaS化的，应用方/用户只需要简单的操作Web页面就能完成数据采集、分析的一整套流程。便捷使用：日志系统最核心的功能是问题排查，问题排查的速度直接决定了工作效率、损失大小，在K8s场景中，更需要一套高性能、智能分析的功能来帮助用户快速定位问题，同时提供一系列简单有效的可视化手段进行辅助。阿里PB级Kubernetes日志平台建设实践Kubernetes日志数据采集 无论是在ITOM还是在未来的AIOps场景中，日志获取都是其中必不可少的一个部分，数据源直接决定了后续应用的形态和功能。在十多年中，我们积累了一套物理机、虚拟机的日志采集经验，但在Kubernetes中不能完全适用，这里我们以问题的形式展开： 问题1：DaemonSet or Sidecar 日志最主要的采集工具是Agent，在Kubernetes场景下，通常会分为两种采集方式： DaemonSet方式：在K8S的每个node上部署日志agent，由agent采集所有容器的日志到服务端。Sidecar方式：一个POD中运行一个sidecar的日志agent容器，用于采集该POD主容器产生的日志。每种采集方式都有其对应的优缺点，这里简单总结如下： DaemonSet方式Sidecar方式采集日志类型标准输出+部分文件文件部署运维一般，需维护DaemonSet较高，每个需要采集日志的POD都需要部署sidecar容器日志分类存储一般，可通过容器/路径等映射每个POD可单独配置，灵活性高多租户隔离一般，只能通过配置间隔离强，通过容器进行隔离，可单独分配资源支持集群规模中小型规模，业务数最多支持百级别无限制资源占用较低，每个节点运行一个容器较高，每个POD运行一个容器查询便捷性较高，可进行自定义的查询、统计高，可根据业务特点进行定制可定制性低高，每个POD单独配置适用场景功能单一型的集群大型、混合型、PAAS型集群在阿里内部，对于大型的PAAS集群，主要使用Sidecar方式采集数据，相对隔离性、灵活性最好；而对与功能比较单一（部门内部/产品自建）的集群，基本都采用DaemonSet的方式，资源占用最低。 问题2：如何降低资源消耗 我们数据采集Agent使用的是自研的Logtail，Logtail用C++/Go编写，相对开源Agent在资源消耗上具有非常大的优势，但我们还一直在压榨数据采集的资源消耗，尤其在容器场景。通常，为了提高打日志和采集的性能，我们都使用本地SSD盘作为日志盘。这里我们可以做个简答的计算：假设每个容器挂载1GB的SSD盘，1个物理机运行40个容器，那每台物理机需要40GB的SSD作为日志存储，那5W物理机则会占用2PB的SSD盘。为了降低这部分资源消耗，我们和蚂蚁金服团队的同学们一起开发了FUSE的日志采集方式，使用FUSE（Filesystem in Userspace，用户态文件系统）虚拟化出日志盘，应用直接将日志写入到虚拟的日志盘中，最终数据将直接从内存中被Logtail采集到服务端。这种采集的好处有： 物理机无需为容器提供日志盘，真正实现日志无盘化。应用程序视角看到的还是普通的文件系统，无需做任何额外改造。数据采集绕过磁盘，直接从内存中将数据采集到服务端。所有的数据都存在服务端，服务端支持横向扩展，对于应用来说他们看到的日志盘具有无线存储空间。问题3：如何与Kubernetes无缝集成 Kubernetes一个非常大的突破是使用声明式的API来完成服务部署、集群管理等工作。但在K8s集群环境下，业务应用/服务/组件的持续集成和自动发布已经成为常态，使用控制台或SDK操作采集配置的方式很难与各类CI、编排框架集成，导致业务应用发布后用户只能通过控制台手动配置的方式部署与之对应的日志采集配置。因此我们基于Kubernetes的CRD（CustomResourceDefinition）扩展实现了采集配置的Operator，用户可以直接使用K8s API、Yaml、kubectl、Helm等方式直接配置采集方式，真正把日志采集融入到Kubernetes系统中，实现无缝集成。 问题4：如何管理百万级Logtail 对于人才管理有个经典的原则：10个人要用心良苦，100个人要杀伐果断，1000个人要甩手掌柜。而同样对于Logtail这款日志采集Agent的管理也是如此，这里我们分为3个主要过程： 百规模：在好几年前，Logtail刚开始部署时，也就在几百台物理机上运行，这个时期的Logtail和其他主流的Agent一样，主要完成数据采集的功能，主要流程为数据输入、处理、聚合、发送，这个时期的管理基本靠手，采集出现问题的时候人工登录机器去看问题。万规模：当越来越多的应用方接入，每台机器上可能会有多个应用方采集不同类型的数据，手动配置的接入过程也越来越难以维护。因此我们重点在多租户隔离以及中心化的配置管理，同时增加了很多控制相关的手段，比如限流、降级等。百万规模：当部署量打到百万级别的时候，异常发生已经成为常态，我们更需要的是靠一系列的监控、可靠性保证机制、自动化的运维管理工具，让这些机制、工具来自动完成Agent安装、监控、自恢复等一系列工作，真正做到甩手掌柜。Kubernetes日志平台架构 上图是阿里Kubernetes日志平台的整体架构，从底到上分为日志接入层、平台核心层以及方案整合层： 平台提供了非常多的手段用来接入各种类型的日志数据。不仅仅只有Kubernetes中的日志，同时还包括和Kubernetes业务相关的所有日志，例如移动端日志、Web端应用点击日志、IoT日志等等。所有数据支持主动Push、被动Agent采集，Agent不仅支持我们自研的Logtail，也支持使用开源Agent（Logstash、Fluentd、Filebeats等）。日志首先会到达平台提供的实时队列中，类似于Kafka的consumer group，我们提供实时数据订阅的功能，用户可以基于该功能实现ETL的相关需求。平台最核心的功能包括： 实时搜索：类似于搜索引擎的方式，支持从所有日志中根据关键词查找，支持超大规模（PB级）。实时分析：基于SQL92语法提供交互式的日志分析方法。机器学习：提供时序预测、时序聚类、根因分析、日志聚合等智能分析方法。流计算：对接各类流计算引擎，例如：Flink、Spark Stream、Storm等。离线分析：对接离线分析引擎，例如Hadoop、Max Compute等。基于全方位的数据源以及平台提供的核心功能，并结合Kubernetes日志特点以及应用场景，向上构建Kubernetes日志的通用解决方案，例如：审计日志、Ingress日志分析、ServiceMesh日志等等。同时对于有特定需求的应用方/用户，可直接基于平台提供的OpenAPI构建上层方案，例如Trace系统、性能分析系统等。下面我们从问题排查的角度来具体展开平台提供的核心功能。 PB级日志查询 排查问题的最佳手段是查日志，大部分人脑海中最先想到的是用 grep 命令查找日志中的一些关键错误信息， grep 是Linux程序员最受欢迎的命令之一，对于简单的问题排查场景也非常实用。如果应用部署在多台机器，那还会配合使用pgm、pssh等命令。然而这些命令对于Kubernetes这种动态、大规模的场景并不适用，主要问题有： 查询不够灵活，grep命令很难实现各种逻辑条件的组合。grep是针对纯文本的分析手段，很难将日志格式化成对应的类型，例如Long、Double甚至JSON类型。grep命令的前提条件是日志存储在磁盘上。而在Kubernetes中，应用的本地日志空间都很小，并且服务也会动态的迁移、伸缩，本地的数据源很可能会不存在。grep是典型的全量扫描方式，如果数据量在1GB以内，查询时间还可以接受，但当数据量上升到TB甚至PB时，必须依赖搜索引擎的技术才能工作。我们在2009年开始在飞天平台研发过程中，为够解决大规模（例如5000台）下的研发效率、问题诊断等问题，开始研支持超大规模的日志查询平台，其中最主要的目标是“快”，对于几十亿的数据也能够轻松在秒级完成。 日志上下文 当我们通过查询的方式定位到关键的日志后，需要分析当时系统的行为，并还原出当时的现场情况。而现场其实就是当时的日志上下文，例如： 一个错误，同一个日志文件中的前后数据一行LogAppender中输出，同一个进程顺序输出到日志模块前后顺序一次请求，同一个Session组合一次跨服务请求，同一个TraceId组合在Kubernetes的场景中，每个容器的标准输出（stdout）、文件都有对应的组合方式构成一个上下文分区，例如Namesapce+Pod+ContainerID+FileName/Stdout。为支持上下文，我们在采集协议中对每个最小区分单元会带上一个全局唯一并且单调递增的游标，这个游标对单机日志、Docker、K8S以及移动端SDK、Log4J/LogBack等输出中有不一样的形式。 为日志而生的分析引擎 ...

案例与解决方案汇总页：阿里云实时计算产品案例&解决方案汇总本文为您介绍实时计算在无线数据分析中的应用。阿里云实时计算可以为无线App的数据分析场景实时化助力，帮助您做到实时化分析手机AP的各项指标，包括App版本分布情况、Crash检测和等。阿里云移动数据分析 (Mobile Analytics，下面简称MAN) 是阿里云推出的一款移动App数据统计分析产品，提供通用的多维度用户行为分析，支持日志自主分析，助力移动开发者实现基于大数据技术的精细化运营、提升产品质量和体验、增强用户黏性。在流式处理部分，MAN采用阿里云实时计算作为底层的流式大数据分析引擎，为移动数据分析的客户提供一整套实时化的移动App分析报表服务。如下图。MAN目前在阿里云上用户数已经超过数百家。结合阿里云大数据平台（数加），未来MAN将会开放更多实时化、个性化，甚至自定义分析逻辑的无线分析功能给用户，可以极大拓展整个产品功能覆盖面。MAN现有全流程的数据流如下：数据采集开发者选择使用阿里云移动数据分析提供的SDK，将其内置到其App的应用安装包中。该SDK会针对不同手机操作系统提供数据采集组件，将用户手机数据、行为数据采集并录入MAN的后台系统，进行数据分析。数据上报MAN的后台提供了一整套SDK数据上报服务，将负责收集使用SDK的手机上报的数据信息。上报服务系统将进行简单去噪处理后投送到DataHub。说明 未来DataHub将直接提供手机端数据上报SDK，实际上MAN后台的上报服务环节可以完全省略(将去噪处理也可以移到实时计算处理)，进一步减少MAN的机器成本。实时计算阿里云实时计算将持续订阅上述DataHub的流式数据，持续读取并计算各类App指标，并立即将各时间段结果数据写入在线的RDS/OTS系统中。数据展现MAN提供一整套的运营指标体系，让开发者快速了解用户来自哪里，访问了哪些页面，停留了多长时间，用户终端及网络环境如何，应用程序卡顿或崩溃的实时反馈，其中Crash分析能精确到设备粒度，查看具体设备的详细Crash信息。 说明 以上数据采集自线下DEMO数据，不代表真实数据情况。本文作者：付空 阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要：很难找到一个特定的数据集来解决对应的机器学习问题，这是非常痛苦的。下面的网址列表不仅包含用于实验的大型数据集，还包含描述、使用示例等，在某些情况下还包含用于解决与该数据集相关的机器学习问题的算法代码。1 -Kaggle数据集网址：http：//www.kaggle.com/datasets 这是我最喜欢的数据集网站之一。每个数据集都有对应的一个小型社区，你可以在其中讨论数据、查找公共代码或在内核中创建自己的项目。该网站包含大量形状、大小、格式各异的真实数据集。你还可以看到与每个数据集相关的“内核”，其中许多不同的数据科学家提供了笔记来分析数据集。有时在某些特定的数据集中，你可以从笔记中找到相应的算法，解决预测问题。2 -亚马逊数据集网址：https：//registry.opendata.aws 该数据源包含多个不同领域的数据集，如：公共交通、生态资源、卫星图像等。它也有一个搜索框来帮助你找到你正在寻找的数据集，另外它还有数据集描述和使用示例，这是非常简单、实用的！3- UCI机器学习库：网址：https：//archive.ics.uci.edu/ml/datasets.html 这是加州大学信息与计算机科学学院的一个数据库，包含了100多个数据集。它根据机器学习问题的类型对数据集进行分类。你可以找到单变量、多变量、分类、回归或者是推荐系统的数据集。UCI的某些数据集已经更新完毕并准备使用。4-谷歌的数据集搜索引擎：网址：https：//toolbox.google.com/datasetsearch 在2018年末，谷歌做了他们最擅长的事情，推出了另一项伟大的服务。它是一个可以按名称搜索数据集的工具箱。谷歌的目标是统一成千上万个不同的数据集存储库，使这些数据能够被发现。5 -微软数据集：网址：https：//msropendata.com 2018年7月，微软与外部研究社区共同宣布推出“微软研究开放数据”。它在公共云中包含一个数据存储库，用于促进全球研究社区之间的协作。另外它还提供了一组在已发表的研究中使用的、经过整理的数据集。6-Awesome公共数据集：网址：https：//github.com/awesomedata/awesome-public-datasets 这是一个按照主题分类的，由社区公开维护的一系列数据集清单，比如生物学、经济学、教育学等。这里列出的大多数数据集都是免费的，但是在使用任何数据集之前，你应该检查相应的许可要求。7 -政府数据集：政府的相关数据集也很容易找到。许多国家为了提高知名度，向公众分享了各种数据集。例如：欧盟开放数据门户：欧洲政府数据集。新西兰政府数据集。印度政府数据集。8-计算机视觉数据集：网址：https：//www.visualdata.io 如果你从事图像处理、计算机视觉或者是深度学习，那么这应该是你的实验获取数据的重要来源之一。该数据集包含一些可以用来构建计算机视觉(CV)模型的大型数据集。你可以通过特定的CV主题查找特定的数据集，如语义分割、图像标题、图像生成，甚至可以通过解决方案(自动驾驶汽车数据集)查找特定的数据集。综上所述，从我所观察到的情况来看，越来越多的用于研究机器学习的各种数据集变得更容易获取，维护这些新数据集的社区，也将不断地发展，使计算机科学社区能够继续快速创新，为生活带来更多创造性的解决方案。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。