简明数据科学 第一部分:原则与过程

2006年,英国数学家Clive Humbly和Tesco Clubcard的建筑师创造了“数据是新石油”这句话。原话如下:

Data is the new oil. It’s valuable, but if unrefined it cannot be used. It has to be changed into gas, plastic, chemicals, etc. to create a valuable entity that drives profitable activity; so, must data be broken down, analyzed for it to have value.

iPhone革命,移动经济的增长以及大数据技术的进步创造了一场完美风暴。2012年,HBR发表了一篇文章,将数据科学家放在了新的高度上。数据科学家:21世纪最性感的工作这篇文章将这种“信心人类”称为数据黑客、分析师、传播者和值得信赖的顾问的混合体

如今,几乎每个企业都在强调数据驱动。而机器学习技术的不断进步,正在帮助着企业完成这个目标。在网络上,机器学习相关的资料非常多,但是都太过的技术性并且充斥着大量的高等数学公式等等,让大多数软件工程师难以理解。因此计划编写一系列的文章,使用更加易于理解的方式简化数据科学。

在本文中,将首先介绍数据科学中的基本原理,一般过程和问题类型,对数据科学有一个基本的了解。

数据科学是一个多学科领域。它是以下领域之间的交集:

  • 商业知识
  • 统计学习或称机器学习
  • 计算机编程

本系列文章的重点将是简化数据科学中机器学习方面,而在本文中将首先介绍数据科学中的原理、一般过程和问题的类型等。

关键原则(Key Principles)

Markdown

数据是战略资产:这个概念是一种组织思维。问题:“我们是否使用了我们正在收集和存储的所有数据资产?我们能够从中提取有意义的见解吗?”,相信这些问题的答案是:“没有”。基于云科技的公司本质上都是数据驱动的,将数据视为战略资产是他们的灵魂。然而这种观念对于大多数组织来说都是无效的。

系统的知识提取过程:需要有一个有条不紊的过程来提取数据中的隐藏的见解。这个过程应该有明确的阶段和明确的可交付成果。跨行业数据挖掘标准过程(CRISP-DM)就是这样一个过程。

沉浸在数据中:组织需要投资于对数据充满热情的人。将数据转化为洞察力不是炼金术,而且也没有炼金术士
。他们需要了解数据价值的传播者,并且需要具有数据素养和创造力的传道人。更加需要能够连接数据,技术和业务的人。

拥抱不确定性:数据科学并不是一颗银弹,也不是一颗水晶球。像报告和关键绩效指标一样,它是一个决策的辅助者。数据科学是一个工具但是并不仅限于此,而且数据科学也不是一个绝对的科学,它是一个概率的领域,管理者和决策者需要接受这个事实。他们需要在决策过程中体现出量化的不确定性。如果组织文化采用快速学习失败的方法,这种不确定性只能根深蒂固。只有组织选择一种实验文化,它才会兴旺发达。

BAB(Business-Analytics-Business)原则:这是最重要的原则。许多数据科学文献的重点是模型和算法,而这些大多都没有实际的商业实践背景。业务-分析-业务(BAB)是强调模型和算法在业务部分应用的原则。把它们放在商业环境中是至关重要的,定义业务问题,使用分析来解决该业务问题,并将输出集成到业务流程中。

过程(Process)

Markdown

从上述原则#2中可以看到,数据科学的过程对于实现数据科学至关重要,一个典型的数据科学项目可分为如下几个阶段:

1. 定义业务问题

阿尔伯特·爱因斯坦曾经引用过“凡事尽可能简洁,但不能太过简单”,而这句话也正是定义业务问题的核心。问题的表述需要事情的发展历程和所在场景,需要建立明确的成功标准。几乎在所有的企业中,业务团队总是繁忙无比,但是这并不意味着他们没有需要解决的挑战。头脑风暴会议、研讨会和访谈可以帮助揭开任何问题的面纱并提出可能的解决方案或者假设。而对于如何定义业务问题?可参考下例:

一家电信公司由于其客户群减少而导致其收入同比下降。面对这种情况,业务问题可能被定义为:

该公司需要通过瞄准新的细分市场和减少客户流失来扩大客户群。

2. 分解为机器学习任务

业务问题一旦定义好之后,就应该分解为机器学习任务。例如上述的示例,如果该公司需要通过瞄准新的细分市场和减少客户流失来扩大客户群。该如何分解该业务问题为机器学习任务呢?下面是一种分解的示例:

  • 将顾客的流失减少x%。
  • 为有针对性的营销确定新的客户群。

3. 数据准备

一旦确定了业务问题并将其分解为机器学习问题,就需要开始深入研究数据了。对于数据的理解应该明确的针对当前问题,因为当前问题能够帮助制定合适的数据分析策略,并且要注意的是数据的来源、数据的质量以及数据的偏差等。

4. 探索性数据分析

“当宇航员进入宇宙时,他们是不知道宇宙中有什么的。”同样的,数据科学家在开始对数据进行分析时,对于数据中隐含的特征等也都是未知数,他们需要穿过数据的表象去探求和开发新的数据涵义。探索性数据分析(Exploratory data analysis,EDA)是一项令人兴奋的任务,可以更好地理解数据,调查数据中的细微差别,发现隐藏模式,开发新功能并制定建模策略。

5. 模型化

探索性数据分析之后,将进入建模阶段。这个阶段中,会根据特定的机器学习问题,选择不同的算法,而机器学习算法有很多,耳熟能详的有回归、决策树、随机森林等等。

6. 部署与评估

最后,部署开发的模型,并且建立持续的检测机制,观察他们在现实世界中的变现并据此进行校准和优化。

机器学习问题类型

Markdown

一般情况下,机器学习有两种类型:

监督学习

监督学习是一种机器学习任务,其中有一个明确的目标。从概念上讲,建模者将监督机器学习模型以实现特定目标。监督学习可以进一步分为两类:

回归

回归是机器学习任务中的主力,被用来估计或预测一个数值变量。例如下面两个问题:

  • 下季度的潜在收入估计是多少?
  • 明年我可以关闭多少项交易?

分类

顾名思义,分类模型是将某些东西进行分类,用在离散型变量。分类模型经常用于所有类型的应用程序。分类模型的几个例子是:

  • 垃圾邮件过滤是分类模型的流行实现。在这里,每个传入的电子邮件根据特定的特征被分类为垃圾邮件或非垃圾邮件。
  • 流失预测是分类模型的另一个重要应用。在电信公司广泛使用的流失模型来分类给定的客户是否会流失(即停止使用服务)。

无监督学习

无监督学习是一类没有目标的机器学习任务。由于无监督学习没有任何明确的目标,他们所产生的结果可能有时难以解释。有很多类型的无监督学习任务。几个关键的是:

  • 聚类(Clustering):聚类是将类似的东西组合在一起的过程。客户细分使用聚类方法。
  • 关联(Association):关联是一种查找频繁匹配的产品的方法。零售市场分析使用关联法将产品捆绑在一起。
  • 链接预测(Link Prediction):链接预测用于查找数据项之间的连接。 Facebook,亚马逊和Netflix采用的推荐引擎大量使用链接预测算法来分别向我们推荐朋友,物品和电影。
  • 数据简化(Data Reduction):数据简化方法用于简化从很多特征到几个特征的数据集。它需要一个具有许多属性的大型数据集,并找到用较少属性来表达它们的方法。

机器学习任务到模型到算法

一旦将业务问题分解为机器学习任务,一个或多个算法就可以解决给定的机器学习任务。通常,模型是在多种算法上进行训练的,选择提供最佳结果的算法或一组算法进行部署。

Azure机器学习有超过30种预建算法可用于训练机器学习模型。

Markdown

结语

数据科学是一个广泛且令人兴奋的领域,而且是一门艺术和科学。这篇文章仅仅是冰山一角。如果“不知道”是什么,那么“如何”将是徒劳的。在随后的文章中,我们将探讨机器学习的“方式方法”。敬请期待!

Markdown

TalkingData发布2018年最新战略布局,探索发展新路径

Markdown

今天,TalkingData在北京举办了以“始于初心,重塑未来”为主题的产品及战略发布会,正式宣布了2018年最新战略布局,以“开放、连接、安全、智能”为核心,着力探索中国大数据行业的发展新路径。

Markdown

TalkingData创始人兼CEO 崔晓波

在国家战略政策利好下,大数据的理念普及已完成,更大的困难在于如何真正从数据中形成智能,提升商业决策与人类生活,这也是所有大数据企业共同面临的挑战。TalkingData创始人兼CEO崔晓波在发布会上强调,数据的核心不是拥有而是连接,TalkingData将突破传统的数据源公司、数据软件公司、咨询公司模式,探索创新发展路径,以“数据智能服务商”为定位,基于开放连接的理念构建整合数据产业链各方资源的平台生态,这样才能集产业之力,真正实现“数据改变企业决策、数据改善人类生活”——TalkingData自成立以来一直坚守的初心和愿景。

为此,TalkingData从战略层面对平台能力进行了全面升级,以SmartDP数据智能平台和SDMK数据智能市场作为双核心驱动,在安全合规的前提下,一方面接入各渠道数据源,打破各企业间的数据孤岛;另一方面基于强大的平台能力,为各方开放提供面向业务场景的数据智能应用与服务。

Markdown

SDMK数据智能市场

安全合规是TalkingData非常重视的基础。目前,TalkingData按照国内法规、甚至GDPR的要求,将数据安全作为全局考量,纳入所有业务和产品的设计与落地中,并在数据保护技术方面持续进行大量探索和实践。

崔晓波表示,“开放、连接、安全、智能”将成为TalkingData继续领跑行业的差异化优势与竞争力。

零售、营销、金融和智慧城市是TalkingData重点聚焦的数据智能应用领域。此次发布会上,TalkingData同时公开了针对这四大领域的重量级产品。

TalkingData特别邀请到腾讯云大数据应用产品总经理聂晶,正式介绍了TalkingData联手腾讯云发布的面向线下品牌商的数据智能产品——智选。智选有机整合了海量数据与机器学习技术,旨在解决实体门店的选址、商圈经营等场景问题,为智慧零售及多元化线下产业提供帮助。

Markdown

腾讯云大数据应用产品总经理 聂晶

此外,杭州决对信息科技有限公司CEO冯江也受邀在此次发布会介绍了旗下大数据风控、资产交易咨询、零售信贷业务咨询等产品,分享如何与TalkingData联手运用金融科技解决行业数字化转型所面临的痛点,助力行业链条发展。

Markdown

杭州决对信息科技有限公司CEO 冯江

基于与国家统计局在人口统计方面长期合作所积累的经验,TalkingData此次正式推出了以准确、动态、及时、多维度为优势的移动大数据人口统计应用——“统计魔方”。同时,以TalkingData Brand Growth品牌广告价值分析平台为代表的TalkingData营销领域产品和数据服务,也在此次发布会上宣布了重要升级。

Markdown

统计魔方

这是TalkingData成立以来的首次战略发布会,也凸显了此次全新战略布局的里程碑意义。TalkingData希望更多与合作伙伴携起手来,共建开放连接的数据产业生态,让大数据真正对人类有所裨益

关于TalkingData

TalkingData 成立于2011年,是国内领先的第三方数据智能服务商。借助以SmartDP为核心的数据智能应用生态为企业赋能,帮助企业逐步实现以数据为驱动力的数字化转型。

Markdown

TalkingData-2018年4月移动游戏Benchmark

2018年4月移动游戏Benchmark解读:

付费率:2018年4月,移动游戏用户的付费率在Android和iOS平台处于平稳状态,其中,动作类移动游戏的付费率在Android平台环比增长1.3%,在iOS平台则环比持平;

用户活跃度:2018年4月,大多数类型移动游戏的用户活跃度在Android和iOS平台保持平稳,其中,iOS平台策略类移动游戏的周活跃率环比增长8.0%,月活跃率则环比下降2.9%;

用户留存率:2018年4月,Android和iOS平台移动游戏用户的一日玩家比例整体与上月持平,次日留存率和7日留存率出现微幅波动。其中,iOS平台模拟类移动游戏的一日玩家比例相比上月有所增长,其次日留存率和7日留存率则分别环比下降1.0%和1.8%;

使用时长&次数:2018年4月,大多数类型移动游戏用户的日均游戏次数和平均每次游戏时长环比微降。其中,棋牌类移动游戏在Android平台的日均游戏次数与上月持平,平均每次游戏时长环比下降2.5%。

MarkdownMarkdownMarkdownMarkdownMarkdownMarkdownMarkdownMarkdownMarkdown

移动观象台

更多移动互联网的行业数据和报告请登录TalkingData移动观象台 http://mi.talkingdata.com/index.html

Markdown

Markdown

影儿时尚集团与TalkingData达成战略合作, 打造数字化会员运营闭环

近日,TalkingData正式宣布与影儿时尚集团达成战略合作,助力影儿时尚集团构建数字化会员运营闭环,迈出新零售转型的关键一步。签约仪式在深圳举办,TalkingData合伙人兼执行副总裁林逸飞与影儿时尚集团总裁俞淇纲分别作为代表出席并完成签约。

Markdown

Markdown

(签约仪式现场)

影儿时尚集团是一家以时尚行业为主导、跨行业发展的大型服装企业,面对移动互联网时代的消费市场巨变,旨在顺应新零售大趋势,加速企业的数字化转型。此次合作重点围绕帮助影儿时尚集团搭建OMO(Online-Merge-Offline)“可管理流量”和数字化运营平台体系展开,TalkingData将为影儿集团提供专业的数字化转型整体解决方案,从数据、到平台、再到咨询层面,驱动以数据的智能构建技术的智能、组织的智能和决策的智能,经过三大阶段,助力影儿时尚集团实现自身数字化运营能力稳步成长,获得效率和收益的双重提升。

Markdown

(活动现场)

通过后期持续合作,TalkingData希望从数字化产品设计、供应链优化、动态选址、数字化品宣四大方面出发,助力影儿时尚集团提升全链条效益,赋能影儿时尚集团中长期的发展。

签约仪式上,影儿时尚集团总裁俞淇纲提到,2018年是影儿时尚集团数字化转型闭环打造的关键年,数字化会员则是影儿品牌从实体店+互联网转型新零售的关键节点。服务顾客一直是影儿时尚集团“新零售”的目标,而数字化会员就是实现该目标的重中之重。通过TalkingData的数字化运营平台、建模能力、数据化会员运营、新媒体流量运营等能力的逐步赋能,将极大地帮助影儿时尚集团打造基于全渠道会员数据资产的会员运营能力。

Markdown

(影儿时尚集团总裁 俞淇纲)

TalkingData合伙人兼执行副总裁林逸飞表示,TalkingData基于自身大数据的生态能力与助力传统企业转型的丰富经验,提出了 D2D数字化转型方法论,即从“数字化”到“数字化”,构建以业务数字化为起点、以效益数字化为节点的数字化运营闭环,迭代上升,全面提升企业数字化能力。目前,TalkingData已经与服饰、餐饮、3C、连锁集团等零售行业的领导企业基于D2D方法论展开合作,稳步推进数字化转型。林逸飞强调,数字化赋能新零售的时代已经来临,TalkingData希望与更多零售企业合作,帮助零售企业构建可持续发展的能力,为零售行业的产业升级提供驱动力。

Markdown

(TalkingData合伙人兼执行副总裁 林逸飞)

关于TalkingData

TalkingData 成立于2011年,是国内领先的第三方数据智能服务商。借助以SmartDP为核心的数据智能应用生态为企业赋能,帮助企业逐步实现以数据为驱动力的数字化转型。

关于影儿时尚集团

影儿时尚集团自1996年成立以来,先后创建了YINER音儿、INSUN恩裳、PSALTER诗篇、Song of Song歌中歌、OBBLIGATO奥丽嘉朵和XII BASKET 十二篮六大品牌,成为一家集投资、研发、创意、营销、服务于一体、以时尚行业为主导、跨行业发展的大型服装企业,致力于将东、西方高雅文艺的精粹自然交融于服饰文化之中,以敏锐的时尚目光,将传统与现代艺术完美融合,抒写了中国时尚产业的新传奇。

Markdown

关于地理空间智能(Geospatial AI) 或 Geo.AI 你知多少?

Markdown

人工智能(Artificial Intelligence,AI)已经成为新技术革命下一阶段的热词,也成为未来产业的驱动力量。使用智能算法,数据分类和智能预测、分析,AI在很多领域将有一系列的工具来帮助解决问题。

将AI用于GIS这一具体的领域的分析、方法和解决方案,就叫地理空间智能(Geospatial AI), 或者简称为 Geo.AI.

地理空间智能(Geospatial AI)可以说是基于地理信息技术基础软件上面的机器学习。

地理空间智能(Geospatial AI)如何工作?

在简单的智能手机应用的帮助下,人们可以对周围环境条件进行实时的的反馈,如交通状况,高峰期、经历、评分等等。这些数据然后被收集、排序、分析,增强准确性和精度,因为成千上万的用户对数据库做出了贡献。

使用地理位置的这些方法不仅仅用于填补信息的空白,也可以用于对特定地理区域的高效解决方案决策提供帮助。比如,可以预测城市中哪个区域将会面临极度交通拥堵,采取何种疏导措施,车辆如何重新选择路线等等。

这也将使系统知道问题严重到何种程度,以及对问题进行定位。

地理空间智能(Geospatial AI)的不同应用

交通拥堵只是个例子,这是我们每天都要面对的一个问题。Geo.AI 可以用于很多的领域,包括很多使用位置和GIS的应用场合。出行共享公司、物流、农业、调查以及基础设施都是很好的应用的例子。

出行共享公司如Uber, Lyft等,可以从客户得到通用的反馈,处理数据从而发现车辆和司机的密度分布。

在物流和供应链,Geo.AI 可以连接运力和货物,填补差异,得到更精确的位置信息来安排物流,从而节省时间和成本。

建立在深度学习的项目能够同步操作在云上的多个主机,管理大量的数据存储和内存,用于解决这些问题。但是,几年前这些自动化的深度学习还被认为是不可能的,要么受限于成本,要么由于技术实现上的限制。同样地,Geo.AI能力随着被产业界更广泛地采用而增强,通过将地理和位置信息集成进来,AI将能够服务于更多的目的。

总之,在商业应用方面, 地理空间智能(Geospatial AI)将持续地增强规划、资源分配和决策支持能力,预测需求和供应,确认其最低、最高的边界,倍增供应链的效率,优化服务的提供。地理空间智能(Geospatial AI)的未来简直是无穷无尽。

Markdown

活动回顾|《数驱•营销闭环 助力品牌增长》全国巡演上海站

Markdown

沙龙中,认真聆听的同学们

6月21日,TalkingData在上海成功举办了《数驱·营销闭环 助力品牌增长》全国巡演第四站营销主题的线下沙龙。在本次沙龙中,我们诚意邀请到TalkingData数据分析高级总监 王鹏加和信息科技副总裁 Jimmy Liang上海联通大数据高级项目经理 山峰眸事网CTO 曹文炯,为大家分享营销案例和经验。现在,我们一起回顾下在本次沙龙中嘉宾们分享了哪些营销干货。

01《数据助力营销 闭环驱动增长》

Markdown

分享人:王鹏 TalkingData数据分析高级总监

TalkingData数据分析高级总监 王鹏把本次分享内容分为4个模块:1.势:数据洞察行业趋势;2.道:厘清营销模式流程;3.术:数据构建营销策略;4.器:产品助力营销闭环。

我们在本篇中带大家主要回顾第1-2部分。

1、势:数据洞察行业趋势

趋势一:使用习惯逐渐固化,竞争从流量转型运营;趋势二:数字营销推广作弊态势持续激增;趋势三:信息流广告独占鳌头,地位难以撼动;趋势四:HTML5 WebApp推广进入爆发阶段;趋势五:线上线下全面融合,或成为下一个营销增长点;趋势六:数字营销走向数据营销;

2、道:厘清营销模式流程

王鹏表示行业关注和需要解决的问题为以下三个方面:

①流量质量是广告主关注焦点

流量反欺诈、流量层过滤、私有交易流量使投放更加精准,而且使流量得到保证,解决数字营销中“流量”这个关键性问题;

②数据为数字营销提供基础

数字营销离不开「数据」,利用数据对受众静态属性、动态属性、各种行为习惯的分析,使精准营销成为可能;

③闭环营销让效果持续提升

通过对用户广告行为的持续学习,实现效果的不断优化,利用机器的试错、总结、学习,逐步完成迭代式优化,基于效果投相似效果。

02《构建开放的大数据营销生态圈》

 

Markdown

分享人:Jimmy Liang 加和信息科技副总裁

Jimmy认为目前在整个数据行业里,数据并不少,而是非常多。即使这样,很多广告主还是面临“看见很多数据,但它们是割裂的,数据数量很大,但没办法流动起来”这样的一个问题。在本次分享中jimmy表示此前通过清晰的数据,可以更好的掌握营销。但在互联网时代,很多原有的评估指标变得不太确定。根据与客户交流、沟通和多年从业经验,Jimmy总结出品牌需要更开放、更灵活和更安全的智能营销解决方案。

在沙龙现场,Jimmy还为现场同学分享了,通过人群标签筛选、目标人群设定、累积选择,如何在欧锦赛期间推广一款男性眼霜的案例:

①数据策略:定向目标人群-熬夜、球迷、差旅、爱美;深夜开启/使用特定App;

②标签定制:采用TalkingData定制化标签服务,找到熬夜黑眼圈一族、时下看球一族、差旅疲惫一族;和爱美保养一族,基于设备使用时间(晚间)、Lbs地理位置、等APP个性化行为,进行标签定制;

③技术关键点:多维度的DMP数据。

03《中国联通大数据助力品牌增长》

Markdown

分享人:山峰 上海联通大数据高级项目经理

在本次沙龙分享中,山峰表示通讯运营商与互联网公司对比,互联网数据受限于本身的数据基因,运营商的数据也许更有代表性和竞争力。

1、互联网数据:
  • 数据局部性,互联网公司的数据是相互割裂的,淘宝只有阿里系的数据,没有百度搜索的数据;
  • 数据封闭性,很少有互联网公司愿意开放自己的数据,开放更多的是商业模式层面和应用层面;
  • 数据割裂性,互联网的数据整合困难,同时注册的个人账号也是短期的,不稳定的;
  • 数据全面性,互联网公司的数据受限于自身的业务,其数据的范围和深度都是有限的。
2、运营商数据:
  • 运营商是数据管道,任何个人、企业的上网和通话的行为都流淌在运营商的管道里,移动运营商拥有个人、企业的上网和通话行为、位置记录,上网记录等数据,数据规模优势明显;
  • 运营商以号码为唯一的ID来整合各类数据,因业务属性的特殊性,刻画客户数据完整是运行商得天独厚的优势一般企业难以企及,而且还有终端ID作为移动通信网天生的业务属性而存在;
  • 运营商数据解决移动互联网时代最为关注的三个问题,我是谁,我在哪里,我在干什么,这是很多企业的数据难以比拟的。运营商承担着相当大的社会责任,数据不分享,不外流,数据安全得到保障。
04《大数据人工智能平台驱动商业价值》

Markdown

分享人:曹文炯 眸事网CTO

曹文炯在本次分享中,就企业如何最大化发挥DMP价值阐述了以下观点,企业自建DMP是基于消费升级带来的用户精细化运营的必然趋势;企业自有DMP的运维核心需可追溯、全流程、可触达;全流程整合业务-产品-用户矩阵,才能最大化发挥企业DMP的价值。在沙龙现场,曹文炯还为现场同学分享了多个教育案例。

《数驱·营销闭环 助力品牌增长》全国巡演第五站将在7月份登陆北京,请大家关注TalkingData微信公众号,关于北京站活动的最新动态!

Markdown

TalkingData联合MIT探索数据共享新范式

Markdown

近日,TalkingData已与麻省理工学院连接科学研究所达成合作,作为唯一一家中国合作企业参与前瞻性框架OPAL的技术研发,共同探索保护数据安全前提下的数据共享新范式。

麻省理工学院连接科学研究所(MIT Connection Science),致力于通过跨学科的研究,提供对人类行为的突破性洞察并推动改善生活的创新科技,为以科技为中介的人际网络带来变革。OPAL(Open Algorithms,开放算法)理念由麻省理工学院教授阿莱克斯·彭特兰(Alex Pentland)首先提出。彭特兰教授是美国国家科学院院士、麻省理工学院连接科学研究所与人类动力学实验室主任,被誉为“可穿戴设备之父”,在人脸识别、GPS定位技术等领域也被广泛地认为是领导者。

现今,世界已全面走向数字化。人类行为数据能为改善社会和促进商业带来裨益,而数据共享可以将这一价值最大化,有效助力构建数据驱动的智慧社会。但如何能在保护数据安全和不滥用个人信息的前提下,释放数据的潜力和价值,是受到全世界关注的课题,也是TalkingData长期致力的方向。

OPAL框架则针对这一课题提出了极具前瞻性的解决方案。该框架摒弃了以往先转移数据再进行处理和分析的做法,改为利用分布式技术进行数据存储和运算,并在流程中都保持数据的加密状态,再将经过验证的算法前置到数据端,不移动数据而只提供安全的分析结果,实现在从数据中获得有价值的洞察的同时,有效保证数据安全与流程合规。

未来,OPAL还将继续探索运用机器学习技术提升精确度、通过去中心化存储和动态算法增强个人信息安全、借助区块链和虚拟货币等技术赋能数据市场等项目,既保障个人信息安全与企业数据资产安全,也为组织间的数据共享打造更为安全可信的环境。

TalkingData非常重视数据安全,也一直倡导培育良性发展的数据共享生态,与OPAL框架所持理念非常契合。目前,TalkingData已经积极参与到OPAL框架中,与麻省理工、英国帝国理工、世界银行、世界经济论坛、微软、埃森哲等世界知名组织与企业,共同对OPAL框架进行研发和优化,并取得了阶段性成果。随着更多合作企业及机构地加入和共同探索实践,TalkingData相信OPAL能为数据共享带来全新激励机制,为全球数据市场带来跨越式发展。

成立近7年来,TalkingData不仅专注于数据智能应用的研发和实践积累,同时也在积极推动大数据行业的技术演进。目前,TalkingData除了组建专业数据科学团队、设立前沿技术实验室并获得多项国家专利之外,还与多家国际顶尖学府与研究机构展开合作,将像OPAL这样的国际前沿技术引入高速发展的中国市场,与国内丰富的应用场景相结合,驱动新技术落地与行业进步。

Markdown

基于Spark、NoSQL的实时数据处理实践(下)

本文基于TalkingData 张学敏 在公司内部KOL的分享主题《基于Spark、NoSQL实时数据处理实践》的整理,同时也在DTCC大会上做了同主题的分享。

主要介绍了项目的技术选型、技术架构,重点介绍下项目面临的挑战和解决办法,还介绍了面对多维度、多值、多版本等业务场景时,使用Bitmap与HBase特性解决问题方法。

共分为上下两篇,本次发布下篇,上篇请点击查看

四、挑战和方案

Markdown

整体服务的稳定性取决于各个组件,大的原则就是故障告警,然后人工介入进行处理。其中Kafka相对还是比较稳定的,如果出了问题,我们可以切换到业务线的集群。无论是离线还是实时计算,资源的分配和管控都是个大难题。我们在17年将Yarn跑在了Docker上,这样可以按团队或者业务优先级分配集群资源,如果Yarn出了不可修复的故障,我们可以基于容器快速重建集群。如前面说到,ScyllaDB相对问题还是比较多的,所以我们所有使用到ScyllaDB地方都有自动降级到HBase的能力。HBase目前是一个集群,没做集群级别的热备,但我们将所有表的建表语句及HFile文件都做了备份,如果HBase出了不可恢复的故障,或者恢复时间会比较长的话,我们可以通过建表语句以及HFile文件快速的重建集群。

Markdown

容量预估也是件令人头疼的事,公司是按月采购服务器,申请量大了会受到大佬们的挑战也不会给批,申请量小了,服务就会受到影响。除了物理机资源受限外,像Kafka Tpoic的分区,HBase、ScyllaDB表的分区以及Spark CPU、内存等也需要考虑容量预估,因为数据流量是不确定的,如果前期设置的值都很大,而流量很小,就会造成物理资源的浪费,如果前期设置的值比较小,就有可能需要在流量变高时做调大的变更。所以,总体来讲, 我们的整体原则就是根据以往数据,凭借历史经验进行预估、设置。

Markdown

相信数据正确性、一致性是流处理中最棘手的问题之一了,当然难易程度也跟业务需求有关系,有些业务可以容忍数据丢失或者数据重复,这样的就相对好处理些,比较难的是数据要求不丢其不重复,即精确一次exactly-once,更难的是有些业务还要使用Window等函数进行复杂运算,此时要做到精确一次需要的成本可能会非常大,所以我觉得是没有银弹,需要根据实际业务及成本情况做取舍、定方案。

我们的业务场景相对比较简单,都只是对数据进行解析、转换、补充处理,然后入库。我们可以使用HBase version的特性去重,保证数据没有重复。怎么做到的呢?我们会对每条事件数据抽象出各种实体,每个实体都有唯一ID,然后我们用数据中的事件时间作为HBase version的值,这样,即使是同一条数据被重复处理,结果写入HBase多次,但由于都是同一ID下同样数据的同一version,所以对于HBase来讲还是同一条数据。

这样的话,数据计算阶段只需要保证至少处理数据一次即可。而无论是使用Spark的 receiver还是Direct消费模式都不难做到至少一次处理数据,receiver模式相对成本会高些,另外他的offset是通过Zookeeper管理,可能会因为两者之间的交互不能及时响应等情况而造成数据不一致。还有就是,他的内存问题会比较严重,因为他接收数据和处理数据是分开的,如果处理速度跟不上,就很容易出现数据淤积导致内存问题,所以建议使用direct模式,该模式是直接把kafka的partition映射到RDD里的partition,只有到了action才会去取数据,同时处理数据。

那么这种模式怎么保证数据至少被消费一次呢?checkpoint机制。checkpoint还是非常高效的,没有涉及到实际数据的存储,一般只有几十k大小,主要存储的是Kafka的Offset等信息。前面说到Spark Streaming是微批处理数据,他每个批次的大小是按时间来定的,比如1s、10s或者其他值,每个批次对应Spark Streaming的一个Job,在Job开始、结束异常等情况下都会触发checkpoint事件,如果有问题会根据checkpoint数据再重新执行Job。另外,我们也会周期性的探测并记录kafka offset位置与时间的关系,以及Streaming处理的offset位置和时间的关系,一方面是为了监控数据有没淤积,另一方面,即使checkpoint不能起作用的时候,也可以通过offset与时间的关系,推算出问题时间点offset的位置。

另外,官方也有关于exactly-once的方案,大的思路就是让批次操作幂等。具体做法,比如可以针对每个批次的partation数据产生一个UniqueID,只有当整个UniqueID相关数据都被完全计算才算成功,否则进行回滚。如果执行到重复的UniqueID,直接跳过该批次。 Markdown

在我们的项目中,影响Spark Streaming性能稳定性主要有三个方面。前面提到,我们Yarn是运行在Docker上的,另外,我们的计算(Yarn on Docker)和存储(HDFS的DataNode)是公用物理机资源的,因为Docker宿主盘如果挂载多盘,即与DataNode公用盘的话,管理成本会比较高,所以前期我们是挂载到系统盘的,大概600G左右。而Spark shuffle、作业日志等也会写盘,一些情况下会将盘写满,导致docker实例或者物理机故障,从而影响作业性能。我们现在的方案是,为Docker宿主盘采购了1T的SSD盘,一个是可以缓解该问题,一个是提高shffle读写性能。

第二个是慢节点问题,引发原因可能是数据不均衡,也有可能是该节点负责较高或者其他原因。可用的解决方案有,开启推测执行就,需要注意的是如果是非幂等操作,不可以使用,会引起不一致问题。如果是数据不均衡引起,可以将分区个数调大,一定程度上可以缓解。如果数据不均衡是数据key及分区分布算法引起,需要根据数据情况调整或者重写分区算法。针对慢节点问题,还也可以尝试使用spark的reblance算子,但这样会导致每批次整体时间都变长。

第三个问题是数据量突增,比如应用故障恢复后需要追赶数据,或者突然有了新的流量高峰等一些原因会导致Spark处理淤积,甚至故障,解决方案是使用Spark的控量及背压功能。Spark 可以通过参数配置每个批次每个partition消费的数据量,Direct模式使用saprk.streaming.kafka.maxRatePerPartition,Rceiver模式使用spark.streaming.receiver.maxRat。但这是个静态值,而数据流量是动态的,有时低有时高。如果这个值我们设置的高了,依然可能会引起计算延迟(数据不能在批次间隔时间内处理完),如果设置低了,会导致计算资源浪费,并且数据可能会在Kafka侧淤积。背压机制相对会灵活些,可使用spark.streaming.backpressure.enable配置控制是否开启,他会根据上一批次数据处理的情况确定下一批次数据的摄入量。但会有个特殊情况,作业启动后的第一个批次没有参考数据,Spark提供了另一个参数spark.streaming.backpressure.initialRate来控制背压第一次处理的数据量,但需要注意的是,Spark低版本时候这个参数只在receiver模式起作用。Direct模式就需要结合控量功能使用,比如可以设置控量值是“最优量”(计算批次内数据所用时间尽可能的接近但又一直低于批次调度间隔时间)的1到2倍,这样第一批次摄入的数据量是saprk.streaming.kafka.maxRatePerPartition的值,紧接着几批会因为第一批次处理延迟而依旧采用控量值为摄入量,直到第一个批次运算完,后续批次才会触发背压机制自动优化摄入量,但最大上限还是saprk.streaming.kafka.maxRatePerPartition的值。

虽然,我们期望流式处理是7*24模式运行的,但有时候也有需要去停止应用,比如,期间某个组件故障,或者是需要升级,或者需要变更数据处理逻辑。如果我们强制杀掉应用程序,很大概率会引起上边所说的不一致的问题,所以需要考虑优雅停止的方案。所谓优雅停止,也就是能够完整的执行完一个批次job,然后停止。

有两种方式,一种是向应用Driver发送Sigterm信号,一种是通过事件触发。第一种需要先设置stopGracefull 为true,然后找到drive所在的节点,登陆到节点上,执行kill命令,注意,一般使用流式处理时候都会设置应用重试提交次数,如果是多次,就需要要多次进行如上操作。并且后续每次停止都需要如此操作,所以相对比较麻烦。

第二种相对简单些,大的思路是定义触发事件,这个可行的方式比较多,比如使用标识文件,间隔去检测文件是否存在,还可以使用socket监听,或者使用restfull服务都可以,然后在需要的时候触发事件,注意,事件触发后一定要在独立线程调用ssc.stop,否则会产生死锁情况。Stop其中第一个true的含义是停止关联的SparkContext,第二个true,就是确定要执行gracefull stop。

下边是其他一些建议设置或者需要留意的参数,第一个参数是消费Kafka数据连接重试次数,在负责较高或者一些其他情况下,Kafka parttion会出现Lead不存在的异常,但大多时候有会很快恢复,默认是1,建议调高。第二、三的参数需要配合使用,第二个就是前面刚说的引用重试提交次数,默认是1、根据实际情况建议调高,但yarn有个限制,需要对应考虑调高。如果作业长时间运行,无论配置多大都会在某一时间点达到,所以第三个参数是Spark提供的让重试计数重置为0的时间间隔。第四个参数是应用程序可以容忍executor失败的最大数量,默认值是executor数量的2倍,也建议调高,与应用失败次数类似,最后一个是控制executor计数重置的时间间隔。当然,优化相关参数还有很多。 Markdown前面说HBase劣势时候提到他的维护成本较高,其中主要的就是这三个方面,一个是major compact,前面提到HBase是使用LSM模型,写数据是先写内存,然后刷写到磁盘,另一个就是HDFS不支持随机写入,所以HBase对数据的修改和删除都是对数据做标志,然后写入库,并不是真正的修改活删除原数据。这样的数据一直存在的话,一个是会影响查询性能,一个是存在无用存储,HBase的Major compact就是为了清理这些数据,当然也还会清理其他数据,比如如果设置了TTL的话,到期的数据也是在Major compact时候清理,还有就是历史版本数据,比如我们设置保留一个版本,那除了最新版本外的数据都会在执行Major compact的时候被清理。清理的时候就需要加载所有数据,所以会产生很大的磁盘、网络IO,一定程度上就会影响HBase的读写,甚至会引发客户端阻塞。我们的应对方案是,关闭compact自动执行,并调高触发上限,就是不让HBase自己控制Major compact的执行。我们还做了个工具,可以指定表、每个列族最小执行Major compact的文件个数,每个rs每次处理region个数等维度在集群相对空闲时间执行Major compact,并根据期望执行的时间调整以上维度参数控制整体执行时间。

与compact相关的还有个叫Minor compact,前面说到,内存满了后会刷写磁盘,那么每次刷写磁盘都会产生新的文件,时间久了就可能会有很多小文件,HDFS的元数据就会变的很多,HDFS元数据在内存中管理,即使不会到NameNode内存大小瓶颈,但也会影响性能,所以Minor就是将这些小文件进行合并。

第二个可能会影响性能的就是region split,特别是存在数据热点时候,如果配置的region最大存储值又比较小,可能会产生递归分裂情况,就是刚分裂完的region还没完成正式上线,发现又需要做分裂,这样region就会长时间无法对外提供服务,影响HBase的使用,我们的应对方案是使用预分区建表,并根据实际数据情况设置split keys以及region存储最大值。

第三个就是MemStore flush,HBase的很多调优大多都是围绕内存,特别是在大量写的场景下,flush会严重影响HBase的性能,甚至引发故障,这个也没有银弹,需要大家根据实际数写入情况和物理机内存大小进行调优,调优参考的东西就是各种监控指标,比如flush queue大小、频次,磁盘、网络IO等,所以HBase的mectric监控尤其重要。

Markdown

HBase配置相关的建议也都是跟compact 、flush相关的,前两个分别是控制Major compact和Flush线程个数的,需要根据物理CPU和实际使用情况调整。第三个是控制HBase自动执行全局flush的周期时长的参数,默认是1个小时,建议设置为0关闭。第四个是控制HBase触发执行Flush的条件,就是单个region的下所有MemStore的大小的阈值。如果达到该值,就会准备对该region执行flush。第五个参数是当region的memstore达到多少倍时阻塞客户端的写入操作,目的是防止引发RegionServer OOM。

因为一个region下有可能有多个MemStore,即表有很多列族,而当执行flush时,有可能有些MemStore数据量占比很小,比如k级别,刷写的话也不会释放很多内存,却会产生很多小文件,这也是官方建议大家设计表时列族不要太多的原因,也是前边建议第二个参数设置为0的原因。而第六个参数,就可以控制region执行flush时MemStore的最小值,也就是小于这个值的MemStore不执行flush,具体值需要参考刷写的HFile的大小及实际列族个数和写入量调整。

HBase低版本时候读写缓存都使用堆内内存,所以需要根据业务场景配置读写缓存的占比,如果是读多写少场景,可以加大读缓存占比,反之,调高写缓存占比。但两者加和不能超过整个堆的80%。

第9个参数也是为了防止OOM的,括号里的是老版本的叫法,需要注意的是,在新老版本HBase中有不同的含义,假设配置的值是0.3,在老的版本中含义是,当RegionServer所有MemStore占用内存超过Heap的30%时会选择一些占用内存比较大的MemStore阻塞写并进行Flush;在新的版本中的含义是,当占用内存超过hbase.regionserver.global.memstore.size的30%时会选择一些占用内存比较大的MemStore阻塞写并进行Flush。这个差别还是比较大的,我们开始是按照老版本含义去设置,发现flush特别频繁,并且Hfile特别小。然后查官方文档才发现这个不同,这个大家一定要注意下,特别是使用过老版本HBase的同学。

Markdown

前面提到,我们有面向实体,多维度、多值、多版本存储、查询数据的需求,那我们在使用HBase存储上是怎么解决的呢?前面说HBase也有表的概念,所以,我们将不同实体的数据存放在不同的表中。还依上边说过的数据举例,数据中有imei和wifi两个维度,我们用HBase 的Column Family来区分。其中wifi维度有wifi1、wifi2两个值,我们将两个值做为HBase的列名,其中共涉及到5个时间戳,将他们做为HBase的version,为了节省空间和后边方便使用bitmap,我们将时间戳转换成了相对时间,以2016年一月一号,0时0分为起点,分钟为间隔。其中HBase的列值我们未进行赋值。

Markdown

前面提到,业务有在低成本提取某个实体历史所有信息的需求,如果查询时间窗口很大或者数据很密集等原因很容易会造成服务OOM。由于我们数据中的设备硬件信息、ID信息几乎是不变的,另外行为轨迹也比较固定,所以位置信息、wifi信息重合度也会比较高,所以,我们使用bitmap对数据进行了聚集。如图所以,我们通过离线计算将HBase中的数据进行转换,假如wifi1是我在公司连接的wifi,那么一天时间我都会使用同一个wifi,但可能数据会上报很多条,这样的话,以wifi1作为bitmap的标识key,wifi被捕获的相对时间1,2,3作为bitmap的位值,就会大大节省存储空间。算完后,再将数据转载进HBase共服务使用,表的schema和前边大体一样,只是version不在特殊赋值,并将bitmap转换为字节数组存为列值。

Markdown

前面提到,由于docker目前宿主盘使用一个,所以我们期望后期可以调整为多块盘。另外,由于不同项目对资源的需求不同,比如图计算需要较大内存的executor,所以后期会在生产存在多版本的image,目前平台没法进行多版本的管理。

虽然Spark Streaming UI上有一些监控信息,但有时候还是需要查看日志,或者查看JVM相关的监控信息,目前我们正在进行GraphiteSink监控指标梳理及数据接入工作。最后一个是关于HBase的,高版本的HBase 有region级别的replica,由于我们之前使用HBase场景都是离线计算装载数据,所以没法使用该功能,这个项目是实时写入,该功能可以提高HBase的可用性,所以后续我们会进行该功能的测试、上线的工作。

小程序UI组件库iView Weapp发布,开源、免费、分分钟上手!

TalkingData温馨提示:文末有彩蛋哟

过去的两年里,iView 开源项目已经帮助成千上万的开发者快速完成网站开发,大幅度提高了开发效率,成为 Vue.js 生态里重要的一部分。

与此同时,我们也在思考,除了服务 PC Web,iView 还能提供什么。可能是 Mobile Web?但同类产品已经太过丰富,所以 iView 一直没有探索 Mobile 端。但是,我们注意到,微信小程序正在崛起,这将是移动端新的一种开发模式。

对于微信小程序,iView 团队并不陌生,在微信最早发布小程序时,TalkingData就上线了小程序统计分析服务(https://www.talkingdata.com/weApp/weApp.jsp)近期又推出了小程序推广检测服务

现在,微信对小程序越来越开放,提供的入口也越来越多,这让很多开发者投入到小程序的开发上。

经过一个月的探索,我们明确了能针对微信小程序开发提供怎样的服务。于是, iVew团队基于在UI组件方面的2年积累,推出了这套高质量的 UI 组件库——iView Weapp。相信 iView 的开发者也会喜欢。

GitHub地址:https://github.com/TalkingData/iview-weapp

开发文档:https://weapp.iviewui.com/

欢迎 Star 和 PR !

iView Weapp 是什么?

微信小程序提供了自定义组件的功能,这使得 iView Weapp 成为了可能。小程序已经提供了很多组件和 API,但它们过于基础,实际开发时仍需要一定的封装和 UI 调整。iView Weapp 提供了与 iView 一致的 UI 和尽可能相同的接口名称,大幅度降低了学习成本,使用起来如鱼得水。如果你是 iView 的核心用户,用起 iView Weapp 来甚至不用看文档!当然,我们对新用户也很友好,事无巨细的文档、友好的 API 和完整的示例,几分钟就可以上手啦。

iView Weapp 1.0 提供了 30 个组件,并会不断丰富:

Markdown

先睹为快

使用微信扫一扫,体验 iView Weapp 小程序组件示例:

(注:单击下图后长按即可识别。)

Markdown

当然,你也可以在微信开发者工具中查看:

# 从 GitHub 下载后,安装依赖

npm install

# 编译组件

npm run dev

然后,将 examples 目录在微信开发者工具中打开即可。

1.0 目前提供的都是基础组件,能够满足大部分常用的布局和交互。接下来,我们还会提供更为丰富的基础组件及典型业务组件,比如刮刮乐,旨在为小程序开发降低门槛,并带来出色的用户体验。

开源协议

iView Weapp 使用 MIT 开源协议,并 100% 开放源码。查看开源协议(https://github.com/TalkingData/iview-weapp/blob/master/LICENSE)。

这里是彩蛋

我们预计在本季度发布 iView 3.0 以及 5 款神秘新产品,届时会举办线下发布会并进行线上同步直播,敬请关注iView 官网。感谢大家长久以来对 iView 的支持,我们将持续维护,投入更多的人力和精力完善生态,让 iView 成为全球最好用的组件库!

硅谷线下 DTalk | AI在”移动优先”的互联网金融商业模式中的应用:关于两个“循环”的讲述

Markdown

一场高质量的分享会应该具备哪些特征?

一位在某个领域足够资深的演讲者,

就一个值得探讨的行业话题,

用一套逻辑严密的演讲框架,

在可以充分表达的2个小时里,

向近千位专业听众完整分享他的看法与见解。

这就是 DTalk。

DTalk是机器之心联合TalkingData共同推出的全球化精品海外活动品牌及演讲系列活动,专注于数据科学与人工智能领域的前沿技术、工程实践与应用落地。 DTalk旨在为相关业内人士、以及对行业感兴趣人士带来深度有价值的业界话题分享,并提供观点交流平台。DTalk将在北美多个科技重镇举办线下分享会,每期精选一个行业话题,邀请资深行业人士分享,并进行全球同步线上直播。

Dtalk 第一期主题

AI在”移动优先”的互联网金融商业模式中的应用

关于两个“循环”的讲述

活动简介

互联网时代下金融市场风起云涌,人工智能技术的助力使互联网金融更加加速了规模化的智能金融服务,并形成良性的商业循环。首期DTalks将着眼于互联网金融,并邀请到Acorns首席数据科学家种骥科先生,为大家深度解析互联网金融当下存在两类基本循环:获取用户与留存用户;并通过案例分析点出人工智能技术可以为互联网金融带来的六大机会。

嘉宾介绍

Markdown

种骥科 Acorns首席数据科学家

目前就职于Acorns任首席数据科学家,拥有多年互联网、大数据及金融创新经验。曾担任宜人贷首席数据科学家,美国Silver Lake 私募公司任Kraftwerk基金数据科学架构师,负责大数据技术应用,并应邀为白宫科技办公室参谋大数据技术产品设计。学术方面,种骥科先生曾于清华大学交叉信息研究院开设“量化金融信用与风控分析”研究生课程,并曾担任卡内基梅隆大学教授与博士生导师,开设高性能计算研究教学中心,任联席总监。

演讲概要

  1. 互联网金融背景简述
  2. 两个循环:“获取用户”与“留存用户”
  3. 人工智能带来的机会:六个机会
  • 数源创新
  • 精准转换
  • 废数利用
  • 盈利底蕴
  • 自我保护
  • 长期信任

活动流程

时间:美西时间 2018年6月21日 18:30 —20:30

  • 8:30 签到入场
  • 19:00 – 19:30 嘉宾分享
  • 19:30 – 20:00 炉边对话 Q&A

温馨提示:

活动举办的北京时间为

6月22日 上午9:30—11:30

地点:中关村硅谷创新中心(4500 Great America Pkwy, Santa Clara, CA 95054, USA)

Markdown

报名方式

点击即可报名参与现场活动,我们为到场听众准备了饮料小食,相聚硅谷,畅谈FinTech。

观看全球直播

方法一:扫描下方二维码添加微信TUD小助手(ID:TDU2018)进入DTalk 交流群;

Markdown

方法二:扫描下方二维码,填写Google报名表,进入Dtalk Slack群组。

Markdown

主办方介绍

Markdown

TalkingData 成立于2011年,是国内领先的第三方数据智能服务商。借助以SmartDP为核心的数据智能应用生态为企业赋能,帮助企业逐步实现以数据为驱动力的数字化转型。

Markdown

机器之心全球化子品牌旗下英文站 Synced Review (Medium:@Synced) 为全球读者提供机器智能领域领先的技术及行业动态报道,专业分析师报告等优质原创英文内容,举办海外活动,开展跨国产业服务。