:::: MENU ::::

TalkingData's Blog

现在开始,用数据说话。

Posts Categorized / Data

cialis erfaring cialis i norge hva er kamagra cialis efeitos secundarios cialis bula viagra effekt viagra norge viagra på nett viagra nettbutikk viagra infarmed levitra comprimidos cialis uten resept cialis pris levitra eller cialis kamagra gel comprar viagra farmacia
  • Jan 03 / 2018
  • 0
Data

锐眼洞察 | 数据仓库的过去和现在(翻译)

作者:Amber Lee Dennis 

原文:The Data Warehouse: From the Past to the Present

译者:TalkingData数据工程师 孙强

本译文禁止商用,转载请注明来源与译者!

“数据仓库之父”Bill Inmon将数据仓库(Data Warehouse,DW)定义为“支持管理决策过程的面向主题的、集成的、随时间变化且非易失性的数据集合”。在他的白皮书“现代数据架构”中,Inmon补充说,数据仓库代表“传统智慧”,现在是企业基础架构的标准组成部分。

数据挖掘教科书作者Han、Kamber和Pei在KDnuggets的数据科学家Matthew Mayo的一篇题为“大数据关键术语解读”的文章中引用了数据仓库的概念,他将数据仓库定义为一种数据存储架构,允许“企业管理人员系统地组织、理解和使用他们的数据来制定战略决策。“当然,数据仓库是许多现代企业中已知的架构。

数据仓库已经成功地用于多种不同的企业用例,尽管数据仓库也已经转变,但如果他们想要跟上当代企业数据管理不断变化的需求,就必须继续。

Bin Jiang在“Inmon的数据仓库定义仍然准确吗?”一文中 重新解释Inmon的数据仓库定义,称之为“一种基于基础架构的信息技术,用于组织定期整合、收集和准备数据,以便于分析”。

Oracle的数据仓库指南将数据仓库定义为关系数据库:“专为查询和分析,而不是交易处理。 它通常包含来自交易数据的历史数据,但可以包含来自其他来源的数据。 它将分析工作量与事务工作量分开,并使组织能够整合来自多个来源的数据。

Oracle的数据仓库指南以多种方式扩展了Inmon版的四个特点:

  • 面向主题:数据仓库旨在帮助分析数据。 例如,要了解有关公司销售数据的更多信息,可以构建专注于销售的仓库。 使用这个仓库,可以回答“谁是我们去年这个项目的最佳客户?”这样的问题。这种按主题定义数据仓库的能力(在这个例子中是以销售为主题),使得数据仓库以主题为导向。
  • 整合:整合与学科定位密切相关。 数据仓库必须将来自不同源的数据转换成一致的格式。必须解决诸如计量单位之间的冲突和不一致之类的问题。 当实现这一点时,才被认为是一体化的。
  • 非易失性:非易失性是指一旦进入仓库,数据不应该改变。 这是合乎逻辑的,因为仓库的目的是使人能够分析发生了什么。
  • 时间变量:为了发现业务趋势,分析师需要大量的数据。 这与在线事务处理(online transaction processing,OLTP)系统形成鲜明对比,在这种系统中,性能需求要求将历史数据转移到归档。 数据仓库关注随时间推移产生的变化,是时间变量一词的含义。

数据仓库结构

Oracle将数据仓库体系结构分解为三个简单的结构:基础层、具有分段区域的基础层、以及具有分段区域和数据集市的基础层。 基本结构中,操作系统和平面文件提供原始数据、存储数据以及元数据和摘要数据,最终用户可以访问它进行分析、报告和挖掘。 添加一个位于数据源和仓库之间的分段区域,为进入仓库之前要清理的数据提供了一个单独的位置。 Oracle表示有可能“为组织内的不同团体定制仓库架构。 可以通过添加数据集市来实现这一点,这些数据集市是针对特定业务领域而设计的系统。”例如,可以在仓库中为销售、库存和采购单独设置数据集市,终端用户可以从一个或所有部门数据集市访问数据。

数据仓库是如何搭建的?

Eckerson集团首席顾问Wayne Eckerson在一篇名为“构建数据仓库的四种方法”的文章中比较了创建数据仓库最常用的方法。

他说:“数据仓库管理人员需要了解这些方法,但是不要依赖这些方法。 “这些方法论形成了有关数据仓库最佳实践的争论,并构成了由咨询顾问开发方法论的基石。

Eckerson讨论的数据仓库的四种主要方法是:

自上而下法的主要特点:

  • 强调数据仓库。
  • 从设计数据仓库的企业模型开始。
  • 部署由临时区域、数据仓库和“依赖”数据集市组成的多层架构。
  • 暂存区是持久的。
  • 数据仓库是面向企业的;数据集市是功能特定的。
  • 数据仓库具有原子级数据;数据集市拥有摘要数据。
  • 数据仓库使用基于企业的规范化模型;数据集市使用主题特定的维度模型。
  • 用户可以查询数据仓库和数据集市。

自下而上法的主要特点:

  • 强调数据集市。
  • 从数据集市设计维度模型开始。
  • 使用由分段区和数据集市组成的“扁平”架构。
  • 暂存区在很大程度上是不持久的。
  • 数据集市包含原子数据和摘要数据。
  • 数据集市可以提供企业和功能特定的视图。
  • 数据集市由单个星型模式组成,按逻辑或物理部署。
  • 数据集市逐步部署,并使用一致的维度“集成”。

混合法的主要特点:

  • 强调数据仓库和数据集市;融合“自上而下法”和“自下而上法”。
  • 从同步设计企业和本地模型开始。
  • 花2-3周的时间创建一个高层次、规范化的企业模型;通过初始集市来充实模型。
  • 通过非永久性中转区域填充原子和摘要数据。
  • 模型作为一个或多个星型模式的集合。
  • 使用ETL工具填充数据集市,并在ETL工具和数据集市之间交换元数据。
  • 当用户需要在原子级上查看各个集市的视图时,在数据仓库后面填充数据仓库;实例化“充实”企业模型,并将原子数据移动到数据仓库。

联合法的主要特点:

  • 强调需要整合新的和现有的异构BI环境。
  • 由多个架构组成的架构。
  • 承认组织和系统发生变化的实际情况,导致难以实施正式的架构。
  • 合理使用任何可能的方式来实施或整合分析资源,以满足不断变化的需求或经营状况。
  • 鼓励组织尽可能分享维度、事实、规则、定义和数据。

通过理解这些不同的方法,Eckerson说,组织可以根据最佳实践模型的基础创建一个满足其独特需求的方法。

数据仓库:主题的变化

Bin Jiang在根据分类定义数据仓库变量中,基于四个变量和八个类来分类数据仓库。

第一按数据源端特征分类。 如果数据仓库只有一个源应用程序,那么将其视为“单一来源”,如果它不是单一来源,则将其归类为“多来源”。

第二是基于组织或前端分类。专用于组织一部分的数据仓库被认为是“部门数据仓库”,整个组织所使用的数据仓库被分类为“企业数据仓库”。

第三是基于时效性或新鲜度。 如果内容每隔一段时间更新一次,例如每天或每周更新一次,Jiang将其归类为“周期性数据仓库”。如果内容在生成或更改后很快更新,则将其归类为“实时性数据仓库”。

第四个分类是基于地理或地理位置。 如果仓库的主要数据对象在不同的地理位置进行存储和处理,则数据仓库被分类为“分布式”;如果所有的数据对象都保存在同一个位置,则数据仓库被分类为“集中式”。

数据仓库的演进

历史上,数据仓库已经发展到使用在进入数据仓库之前已被过滤的结构化重复数据。 Inmon说,近年来,由于使用了可以附加到非结构化数据并可以存储入数据仓库的上下文信息,数据仓库得以演进。 Inmon说:

 “之前,结构化的关系数据不能和非结构化文本数据混合匹配分析。 但随着情境化的出现,这些分析类型可以自然且容易的完成。”

在数据仓库中,诸如调研反馈、电子邮件和对话等非重复性数据的处理方式,与例如点击流、计量或机器或模拟处理这样重复出现的数据不同。Inmon说: “非重复性数据是由书面或口头文字产生的基于文本的数据”,进行阅读和重新格式化,更重要的是,现在可以进行语境化。 为了从数据仓库中使用的非重复数据中获得意义,必须具有所建立数据的上下文。

Inmon还表示:

“在很多情况下,非重复性数据的上下文比数据本身更重要。 无论如何,在建立上下文之前,非重复的数据不能用于决策。”

数据湖和数据仓库:相互排斥还是完美伙伴?

在“来自Gartner的警告:不要混淆数据湖与数据仓库”一文中,Gartner的研究总监Nick Heudecker认为,近年来数据湖已经出现在数据管理领域,但数据湖不一定能代替数据仓库。数据湖不是现有分析平台或基础架构的替代品,相反,其是对现有努力的补充,并帮助发现新的问题。他说,一旦发现这些问题,就会通过”优化“来获取答案。而优化可能意味着放弃数据湖,进入数据集市或数据仓库。

在“数据湖vs数据仓库的关键差异”一文中,SAS Institute新兴技术总监Tamara Dull概述了数据湖和数据仓库之间的一些主要差异。

  • 数据:数据仓库仅存储已建模/结构化的数据,而数据湖则不要求数据格式。 它将其存储为全结构化、半结构化和非结构化的。
  • 处理:在企业,将数据加载到数据仓库之前,首先需要对数据进行一些加工和结构化——即数据建模。 这就是所谓的写模式(schema-on-write)。 使用数据湖,只需按原样载入原始数据,然后当确定数据形状和结构的时候就是做好数据使用准备的时候。 这就是所谓的在读模式(schema-on-read)。 两种截然不同的方法。
  • 存储:像Hadoop这样的大数据技术的主要特点之一,是与数据仓库相比,存储数据的成本相对较低。 这主要有两个原因:首先,Hadoop是开源软件,所以许可证和社区支持是免费的。 其次,Hadoop被设计成安装在低成本的硬件上。
  • 敏捷性:根据定义,数据仓库是一个高度结构化的存储库。 改变结构在技术上并不困难,但考虑到所有与之相关的业务流程,这可能会非常耗时。 另一方面,数据湖没有数据仓库的结构化要求,这使开发人员和数据科学家能够轻松地配置和重新配置模型、查询和应用程序。
  • 安全:数据仓库技术已经存在了数十年,而大数据技术(数据湖的基础)相对较新。 因此,在数据仓库中保护数据的能力比保护数据湖中的数据要成熟得多。 但是,应该指出的是,现在大数据行业正在大力开展安全工作。一切只是时间问题。
  • 用户:长久以来,大家一直在呼吁BI和分析。数据仓库已建立并欢迎“每个人”来使用,但他们来吗? 平均而言,有20-25%的人使用。对于数据湖来说,是否有相同的需求? 数据湖是否也对每个人开放? 不,如果你够明智。 Tamara Dull说,数据湖在这个阶段更适合数据科学家。

数据仓库不断发展

Bill Inmon看到了数据仓库的巨大发展潜力并正在向前推进。 他认为:

基于事务的数据的经典分析处理是一如既往在数据仓库中完成的。 这没有什么改变。 但是现在可以对情境化数据进行分析,而且这种分析形式是全新的。 以前大多数组织都不能根据非结构化文本数据做出决策。现在有一种新的分析形式可能运用于数据仓库,这是混合分析。 混合分析是使用结构化事务数据和非结构化上下文数据的混合来完成分析。

他补充说:“还有许多其他形式的分析也是可能的。”这些形式包括预测和规划分析,以及各种机器学习技术和其他正在改变数据管理和分析方式的技术。 数据仓库一直是企业数据架构的主要组成部分,根据像Inmon这样的专家所讲,数据仓库在大数据和高级分析的新世界中拥有强大的未来。

数据仓库就像其他传统的数据管理工具一样, 在未来多年中,其重要性仍将是有效的数据管理的关键。

  • Dec 28 / 2017
  • 0
Data

锐眼洞察 | 2017年大数据分析市场调研报告(翻译)

作者:Dresner Advisory Services

原文:2017 Big Data Analytics Market Study

译者:TalkingData CTO 肖文峰

本译文禁止商用,转载请注明作者与来源!

译者导读:

这份报告是由Zoomdata赞助Dresner Advisory Services制作的大数据分析市场洞察。

从报告中可以大致看到,对于企业来说,大部分依然处于有数据、但是没有有效手段进行展示的阶段。“大数据”对于他们来说还是更加遥远的未来的事情。

亚太用户距离北美来说有一定差距,未来会使用的群体会更大一些,尚无计划使用大数据的更少一些,说明企业基础比较好,更容易接受新生事物,只不过需要有一定的过程。亚太地区的企业引入大数据会更加急迫一些。

IoT并非想象中那么受到追捧。数仓优化是对于企业已经投入的资产的优化。客户和社交分析依然具有持续的高需求。

这里只是翻译部分内容,详细报告请点击原文下载PDF版。


摘要:

  • 大数据采用率在2017年达到53%,高于2015年的17%。
  • 电信和金融服务是早期采用者(第19-24页)。
  • 行业对大数据的态度略有下降(第68页)。
  • 在亚太受访者的带领下,40%的非用户期望在未来两年内采用大数据(第25-30页)。
  • 在商业智能战略的技术和举措中,大数据分析在我们研究的33个主题领域中排名第20位(第18页)。
  • 数据仓库优化仍然是最大的数据使用案例。客户/社会分析和预测性维护是最有可能的用例。物联网大数据势头放缓(第31-36页)。
  • Spark是领先的大数据基础设施选择,其次是MapReduce和Yarn(第37-42页)。Spark、MapReduce和Yarn拥有最高水平的供应商支持(第69-70页)。
  • Spark SQL是大数据访问最流行的手段,其次是Hive和HDFS(第43-48页)。对于Hive / HiveQL,行业支持是最大的,其次是Spark SQL。行业大数据访问支持正在增加(第71-72页)。
  • 在大数据搜索机制中,ElasticSearch领导Apache Solr和Cloudera Search,尽管用户需求不大(第49-54页)。大数据搜索正在获得一些行业投资,但不是高优先级(第73-74页)。
  • 最流行的大数据分析/机器学习技术是Spark MLib,其次是scikit-learn(第55-60页)。行业对机器学习的投资正在显着增加,特别是Spark MLib(第75-76页)。
  • 在大数据分布中,Cloudera是最受欢迎的,其次是Hortonworks MAP/R和Amazon EMR。

对于BI最重要的措施和技术排名:

在被认为对商业智能具有战略意义的技术和举措中,大数据分析在我们目前研究的33个专题领域中排名第20(图5)。 这一排名与我们的2016年大数据分析市场研究相同。 我们应该补充说,2016年是提升大数据采用率和重要性的分水岭。 尽管我们仍然认为,不同组织的大数据收益差异很大,但是在过去的24个月中出现了更为广泛的势头。从本质上讲,我们也观察到大数据距离主流BI实践(如报告、仪表板和终端用户自助服务)的重要性依然很远。

00.png

在2017年的样本中,北美地区(55%)大数据采用率最高(图8)。亚太地区的受访者大部分标识“将来可能会使用大数据”。但是北美和EMEA地区(欧洲、中东、非洲)的受访者两分化也比较严重,也有很多标识“根本没有使用大数据的计划”。

01.png

就地区分布而言,在那些还没有采用大数据的国家中,北美地区受访者在本年度引入大数据的比例最大,同时明年之后引入的也同样最多。亚太受访者大多准备明年采用。

02.png

按行业来看,目前大数据的使用在电信方面是最大范围的,87%的受访者表示他们已经采用(图9)。同样令人印象深刻的是,76%的金融服务机构也已经采用了。相比之下,技术行业受访者中虽然61%已经采用,但是却也有20%并没有计划采用,分化比较严重。医疗保健受访者中只有不到60%的人使用大数据。高等教育目前使用大数据的可能性最小(25%),但是有67%的受访者未来可能会使用。

03.png

大数据用例

2017年最大的数据使用案例是数据仓库优化,对于大约70%的受访者来说,这被认为是“关键”或“非常重要”(图18)。“客户/社会分析”和“预测性维护”(2017年新增条目)是下一个最有可能的用例,至少对大多数受访者来说是“非常重要的”。 值得注意的是,大量讨论的IoT(大数据可能的用例)在我们的抽样中是最低优先级。

04.png

 

  • Dec 26 / 2017
  • 0
Data

锐眼洞察 | 在员工培训中利用大数据的4种方法(翻译)

作者:insideBIGDATA编辑部

原文:4 Ways to Use Big Data in Employee Training

译者:TalkingData 曾晓春

本译文禁止商用,转载请注明来源与译者!

大数据及其背后的技术已经成为推动现代企业发展的主要因素之一。一个IDG Research的研究发现,80%的大型企业和63%的小型企业正在使用或计划部署大数据解决方案。分析从公司各种活动中收集的信息,能够使公司作出更明智和及时的决策。

即使整合的数据量不断增加,如果不是快速分析和多种需求的结构,它也没有什么价值。数据科学家和更好的大数据工具的需求一直在增长,因为它包含了更多的业务功能。

其中之一就是员工培训。可以分析技能开发中产生的数据以提高培训效率。以下是一些大数据可以在培训过程中节省公司时间和资金。

确定培训需求

性能分析可以指出企业内部需要何种培训,包括特定的工作角色、团队或个人雇员需要进行的培训。然后,公司可以选择课程,以确定应涵盖的技能和主题,并找到最合适的培训计划。

有种各样可以使用的方法,例如教室布局、在线课程、小组研讨会或示范。您必须评估您的选择,以选择最适合您的员工能力,工作时间表和企业需求的培训。同时也需要购买或准备需要的材料以支撑教学需要的技巧和信息。这可以是印刷或数字文件、视觉辅助工具、技术和工具的混合。大数据可以指导你正确的购买。

个性化的方法

人力资源经理可以使用分析来定义员工能力的特定优势或劣势,并进行必要的调整。应该对每个培训计划进行监控,以确保培训过程和结果的有效性。这可能需要更个性化或更具创造性的技巧。

先进的教育技术可以让您对每个员工进行评估,并根据每个人的进展进行个性化的定制培训策略。大数据可以将每个受训者的测试分数与更大的数据集(如人口统计数据和测试历史)相结合,以确定哪些方法是有效的,以及哪些需要进行强化或再训练。持续评估将显示哪些培训模块对某些员工最有效。

不断的改进

通过对培训数据的分析,人力资源和高级管理人员可以不断改进培训计划。大数据可以更清楚地了解哪些模块有效,哪些主题难以学习,以及员工如何与提供给他们的材料和培训形式进行交互。通过访问基于云的分析工具,您可以实时查看更新,并在培训继续时调整您的方法。

远程员工也是如此。云为越来越多的移动劳动力提供了一个非常灵活的数据和服务解决方案。云计算使虚拟员工无需前往办公室即可获得企业培训的所有好处。

不断增长的学员表现和对不同科目的反馈数据将为提高培训效率提出建议。

未来的期望

我们会看到大数据和可持续实践将是未来的两大商业趋势。两者都促进流程的优化以获得更高的利润率。确保你的团队有足够的核心业务活动和不断变化的技术培训,帮助你的企业在未来保持盈利。

大数据还可以预测未来的发展趋势。在商业竞争开始之前,你将能够适应训练计划。21世纪的商业环境中,接受社会责任将会提高你的品牌和员工的积极性。消费者期望负责任的做法,而工人可以有信心提高职业技能。

培训员工参与可持续发展是关键的一步。通过在培训项目中利用大数据技术,您可以为您的员工提供新的机会,为您的公司带来更多可持续的利润。

结论

大数据和分析工具是现代企业必不可少的资产。当应用于改善培训计划时,员工的情绪会得到更大的改善,他们的技能会增加公司的利润。不断增长的数据将有助于提高结果的准确性,同时预测趋势和培训需求将创建更加灵活的业务模式。

有效地获取和构建培训操作中的数据,使您能够执行大数据分析,从而提高产出、质量和员工参与度。持续的改进使您有可能更快、更持续地提升员工技能,以满足云计算和远程工作人员等新的员工发展需求。

大数据使您能够预测市场和行业趋势,从而使公司内的员工可以获得所需的培训。作为个人或组织,团队将能够更加顺畅和高效地适应业务变化。

  • Dec 21 / 2017
  • 0
Data

锐眼发现 | 拒绝拍脑袋:如何科学的预估产品上线后的数据?

作者:木木(微信公众号「大白学堂」)

转载于:人人都是产品经理

数据会帮助你明确你的工作目标,优化资源配置,但数据的预估不能靠拍脑袋,需要有理有据。

你对自己正在做的工作能做到心里有底吗?一个产品上线后到底会取得什么样的结果,而且这个结果还是以数据的方式呈现,你能明确的说出来吗?很多时候做什么是比较容易的,怎么来评估做这个工作带来的价值反而没那么容易,这时候就涉及到了目标设定和数据预估。

怎么预估?是一个非常有挑战的事,有的人具体工作做的很好,但是涉及到数据就说不清楚了,很多工作多年的人也未必有这个意识和能力,但是只要你掌握了这个技能,将给你带来很多好处。

比如,如果你是创业者,预估的数据是你画大饼的基础,是对合作伙伴和投资人最好的说服工具,如果你是公司的领导,预估数据将帮助你配置与之匹配的研发,运营和推广资源,避免造成资源不足或闲置浪费的情况,如果你是产品经理,数据预估是你争取资源推动工作最好的帮手。

总之,数据会帮助你明确你的工作目标,优化资源配置,但数据的预估不能靠拍脑袋,需要有理有据,那这个数据怎么来?下面给大家分享一个思路:

1. 首先搞清楚你的用户是谁

预估数据前,要明确的知道你的用户是谁,这是数据预估的前提,如果连自己的用户都不清楚,数据预估也就无从谈起,那怎么明确你的目标用户呢?

第一步:

基于自己的经验和对市场的观察理解做一个定量的分析,对目标用户的范围有一个大概的认识,比如你要做视频直播,通过对市场上直播平台的使用及你的经验判断,你发现这个产品的目标用户群体是18~30岁之间的年轻人,这是一个简单的定量分析结果,让你对目标用户有了一个大概的轮廓;

第二步:

通过调查问卷等定性研究的手段,让人群的属性更具体,比如你发放了100分调查问卷,最后发现有80%的反馈者都是北方人,这说明北方的人更喜欢玩直播,这时候你的目标用户范围就缩小到了北方的年轻人;

第三步:

再对这里面的典型用户的模型进行分析,建立用户画像,比如你最后发现典型用户的画像是,性别女,年龄20岁,自由职业/无业,性格活泼开朗,擅长唱歌跳舞,这样的用户模型对应到实际的生活中,你就会发现非常符合艺术类院校学生的特征,这时候你的目标用户是谁也就非常清楚了!

备注:怎么做定量及定性分析,做用户画像,不是这篇文章的重点,这里就不展开说了。

2. 判断市场总的用户容量有多大?

当你把目标用户确定了,然后要看看这个市场的总人数有多少,比如你的目标用户是服务某个大学的学生,用户上限也就一两万人。

为什么要算总容量,因为这是你的产品理论上所能触大的用户上限,是产品的天花板,撑死了也就这么多了,当你配置资源的时候,这个总容量是你的前提,没有必要按照百万用户的标准配置服务一万人的资源。

3. 评估自己能力,看能触达多少人

在上面评估了整个市场的容量,接下来就要看看自己手里的牌,看看自己是否有能力占领整个市场,如果不能话,以自己的能力,到底能获取多少用户。

比如你的产品是面向考研人群的,理论上所有愿意考研的人群都是你的目标用户,但是你的公司只有10个人,市场费用也没多少,市场很大,但是你根本没有能力触达全国的人,正好你的公司在北京,所以你选择了北京要考研的人群作为你的服务对象,北京考研人群数量就是你能触达的用户数,上面的数据是理论上你能覆盖的用户人数,这一部分是你实际上能覆盖的用户数。

4. 根据运营推广策略,进行数据预估

在上面知道了我们在能力上能覆盖的用户,实际上在获取用户的时候,往往会制定一定的用户获取策略,筛选出让资源最大化的目标用户,对这些用户进行重点的运营和推广,比如微博要获取用户,并不是直接去拉用户,而是先拉明星,然后通过明星来拉粉丝,要获取一个学校里的学生用户,不会对所有人都一视同仁,而是会优先拉校园里面比较活跃的人,然后通过这些人去影响其它人,这些基于推广策略筛选后的目标用户数量,基本上就非常接近产品上线后的用户数。

通过上面4个步骤,我们知道了目标用户是谁,理论上最大的用户数,实际上能获取的最大用户数和根据实际的运用推广策略能获取的用户数,基本上整个产品预估的数据就都有了,下面给大家一个真实的案例,这是我以前服务过的一家公司,在当时是全国最大的社交网站,来看看在产品上线前是怎么预估数据的:

首先确定目标用户

这个产品是参考美国的社交巨头facebook,为大学生提交社交服务,目标用户是全国在校的大学生,人群的画像非常清楚。

其次判断这个市场的容量

通过每年教育部公布的数据很容易获取在校大学生的数量,每年新增的大学生六百多万,在校的大学生超过两千万,两千万用户是每年能获取的用户的最大上限。

然后我们再来评估能触达多少用户

这两千多万学生,分布在全国各地的大学,有像清华,北大这样的名校,也有偏僻的不知名的学校,虽然整体看起来地域跨度比较大,但是学生有一个特点,就是在单个学校中相对集中,作为创业团队,全部覆盖几乎不可能,而且团队成员都在北京,这时候推广目标基本上就可以从全国的大学,缩小到北京的大学了,怎么选择这几个大学,有几个标准,首先这些学校上网环境要好(这是在05年左右的时候,很多学校上网都不方便),其次,这些学校的学生进来后有示范带头作用(有逼格),最后是团队有能力在这个学校进行推广,可操作性强。

因为团队成员基本都是清华北大的,基于以上的筛选,将推广的学校锁定在了清华,北大两所学校。因为用户注册需要教育邮箱注册,这避免了非目标用户随意注册,这时候用户量基本已经可以有一个比较清楚的估计,就是这两所大学的在校人数,最多也就是六七万用户。

最后根据运营推广策略进行数据预估

在前面确定了学校,在推广的时候,要研究学校的学生,在这些学生中,有四分之一是即将毕业的大四学生,四分之二是大二和大三的,有四分之一是新入学的新生,对于新的产品,新生更容易被宣传和接受,而且他们会在学校里待更长的时间,所以在推广的时候,策略是对新生重点进行推广。

再看看自己能触达用户的渠道:学生会,社团,辅导员以及自己的地推团队,每个部分能触达和转化的用户大概有多少,如果按转化率十分一,时间期限按一个月来算,最后实际获取的用户可能在6千左右。

这时候基本上可以估算出,这个产品上线后,一个月用户量大概在6k~6w之间, 6k是最低的目标,打死也要完成的,超过了6k说明这个产品比预期想象的好,值得接着做了。

其实数据的预估,也是对自己目标的管理的一部分,不只是产品上线前要预估,在你做运营,推广,等任何一项工作前,都要对投入和产出进行预估,没个人都有自己预估数据的方法,上面的思路仅供参考,欢迎找我一起交流。

  • Dec 19 / 2017
  • 0
Data

锐眼发现 | 「Why-What-How」:数据分析的基本方法论

作者:陈新涛,公众号「ourStone」

转载于:人人都是产品经理

本文由 @陈新涛 原创发布于人人都是产品经理,版权属作者本人所有。

作者注:2017.12.3受「水滴互助」的朋友相邀,分享了个人在数据分析领域的一些基本方法论。数据产品以沉淀数据分析思路为基本点,这两个领域略有重合之处。在这里整理成文章分享给大家。


「Why-What-How」在讲解概念和执行上是个不错的思维模型
,这次依例按此框架来拆分「数据分析」。相信很多朋友已经有了较丰富的分析经验,这里权且从个人的角度进行梳理,以资参考。为了帮助大家更好地理解本文,先贴出一张思维脑图:

一、WHY:为什么要做数据分析

在目前讲解数据分析的文章里,大多数会忽略数据分析本身的目的。这会导致我们在执行时,会出现动作变形的情况。

以终为始,才能保证不会跑偏。

个人的理解上:数据分析是为了能以量化的方式来分析业务问题并得出结论。

其中有两个重点词语:量化和业务。

首先讲下量化。

量化是为了统一认知,并且确保路径可回溯,可复制。统一认知后,才能保证不同层级,不同部门的人在平等话语权和同一个方向进行讨论和协作,才能避免公司内的人以「我感觉」「我猜测」来猜测当前业务的情况。

路径可回溯可复制指的是:通过量化后的结果,许多优化的方法是可以被找到原因并且可以被复制的。同样是转化率优化,用 A 方案和 B 方案,谁的效果会比较好和具体好多少,都是可被预测的。

要想做到量化,需要做到三点:建立量化体系,明确量化重点和保证数据准确性。

1.1 建立量化体系

建立量化体系,主要是根据「指标设计方法」,设计业务的「核心指标+拆解指标+业务指标」,最后落地成全公司通用的「指标字典」和「维度字典」。

这种工作一般是由数据分析师或数据 PM 来担任完成。通过这种方式,我们就能初步建立面向全公司全面,系统的量化分析框架,保证日常分析可以做到「逐层拆解,不重不漏」

1.1.1 指标设计方法

讲到指标设计方法,大家可能觉得:之前听过了产品设计方法、程序开发方法,指标这种东西也有设计方法么?

确实有,指标设计是一套以准确和易懂为准则,集合统计学和业务效果的方法论。

准确是指能够准确满足衡量目的,易懂是指标算法能直观显示好与坏,并且指标的算法也能够通俗易懂。这两者很多时候需要有所抉择,准确是第一位的。举个例子:当我们想衡量一个群体收入的差异性时,用方差还是用基尼系数?

方差好懂,但不能显示两个极端的差异性多大。基尼系数算法不好懂,但能准确描述这个问题。

具体到指标设计,我们需要使用一些常用的统计学工具:

以顾客质量分析为例:概况是我们看下顾客的平均支付金额,或者支付中位数,来了解顾客概况。如果我们想了解这批顾客的质量是都比较好,还是良莠不齐,则需要通过方差和标准差来描述。如果想知道更详细的内容,可以了解每个区间的用户数是多少,来做判断。

有一些 Tips 供大家参考:

  1. 比率指标:关注实际效果(下单转化率,光看下单数是没有用的)
  2. 伴生指标:既要看新客数也要看 CAC,确保数量的前提也要确保质量
  3. 防止坏指标:错误指标,虚荣指标,复杂指标

这里简单解释下每个 Tips 的目标。

之所以采取比率指标和伴生指标,是因为能够明显反映业务的「效率」且能够有效防止因为追求单个指标而导致动作变形。

如果说这辆车能跑十万公里,其实并不能表示这辆车的性能怎么样;只有「速率=路程/时间」,才能反映这辆车的效率。

同时,如果片面追求速率,会导致汽车在设计时剑走偏锋,给驾驶者带来危险;因此需要再加个「故障率」或「事故率」等伴生指标来确保安全。

坏指标中的「虚荣指标」首次出现《精益数据分析》一书中,作者简单把「PV/UV」等指标都归为虚荣指标。

刚开始时我颇为认可,但后续在实际的应用过程中,发现对于很多业务的监控,这些指标并避免不了。后续我便把「虚荣指标」更正为「把距离业务目标过远的环节定义为核心监控指标」

对于一个即时通讯 APP 来讲,下载次数、启动用户数、注册用户数需要监控,但不能作为核心监控的指标;更合适的应该是消息数或「进行过对话的用户数」。

复杂指标往往是各种「指数」,用了很多指标各种加减乘除,这会导致此类指标在发生波动时,很难分析原因。

拥有对指标的定义权和解释权是个段位非常高的事情,这要求设计者深入了解业务和拥有极高的抽象能力。

对于分析师来讲,拥有指标定义权将凸显出你在业务方的重要性——当然,这里并不是鼓励大家为了定义指标而定义指标。寻找业界已有量化方法并在公司内推广,也是件功德无量的事情。

举个美女外卖的「美女厨师率加权指导值」为例。为避免泄露商业机密,将这个原本用来衡量用户体验的指标换成「美女厨师率」,以下背景也稍作修改,大家领会精神即可:

指标的背景是为了保证用户的用餐体验,美女外卖总部提出每个城市的商家必须配备一定比例的美女厨师。但城市提出异议:不同城市拥有的商家情况不一样——大型的商家厨师多,美女厨师率会相对较低,不能用统一的值来对比所有城市。因此总部便设计出来这么一个指导值:将全国商家进行分层,每个层次的商家得出全国平均值,然后各个城市对标平均值产出自身的对标值,即「美女厨师率加权指导值」。虽然在计算上稍微复杂点,但在实际应用的过程中,BD 们只需要知道总体的差距和每一层商家的差别,很容易针对性的落地和优化。

1.1.2 建立指标体系

在根据「指标设计方法」上,如何建立起围绕业务的指标体系呢?

核心是根据业务特征确定核心指标,在核心指标的基础上以不同的角度进行拆解,然后再慢慢补充其他业务的指标情况。

拆解的时候,要做到按指标拆解而非维度。比如订单数,也可以拆解为各品类的订单数合计,这一点可以通过保持上下两层指标名称不一致来避免。拆解的过程依照金字塔方法论的「逐层拆解,不重不漏(MECE)」。若拆解出来或业务补充的指标过多,可借鉴数据仓库的「域」概念来管理这些指标,如上图的「交易域」,「商品域」和「用户域」。

在一个规范的指标体系中,已经涉及到元数据管理的领域了。包括针对指标命名的规范,数据存储和计算的管理等等。大家有兴趣地可以搜下相关文章,或阅读阿里巴巴新出的《阿里巴巴大数据实践之路》。

下面截取一张来自云栖大会的,关于指标命名规范的 PPT 给大家:

1.1.3 建设指标维度字典

这里是转转公司早期部分的指标维度字典,(Bus Matrix),一定程度上解决了之前公司内对于指标定义不清或不统一的问题。现在这套东西已经产品化,可以在可视化产品中查看和显示了。

对于暂没能力产品化的公司,建议可由分析师们通过 Google Docs 或 Wiki 对一些关键和常用的指标进行统一的维护。

对于维度总线矩阵,主要是在以维度建模的数据仓库,设计数据产品,多维度交叉分析时提供框架和基础。

1.2 明确量化重点

每个阶段,都应该明确当前的业务重点;量化体系需要根据业务阶段,更改量化重点及方式。

这同时意味着:有更细节的指标及更大的监控和推广力度。

比如外卖行业早期,经历了看重订单数,到订单额,到新客数+补贴率,到新客数+资金使用效率(交易完成进度/费用完成进度)的历程。

我们可以看到:随着战争的阶段不断升级和变化,从不计成本打下市场份额,到看中订单质量,到存量市场争得差不多了,开始考虑新客数量,同时控制补贴力度,到战争趋于常态化,开始控制整体补贴额度,靠拼效率来战胜对手。每个阶段,都需要根据不同的战场情况来判断当前重点,从而围绕该重点建立一套360度无死角的分析监控体系。

1.3 确保数据准确性

在数据准确性这个话题里,数据产品已经有成熟的数据质量管理方法;涉及了数据源,指标计算和数据呈现等各个环节的监控。

本文主要从分析师的角度阐述确保准确性的方法,数据产品相关的就先不赘述了。

  1. 采取可信来源:多来源交叉确认,采用新来源时需格外小心
  2. 确认加工方式:指标定义和加工算法
  3. Double Check:量级,计算逻辑和业务常识

这里着重讲下 Double Check 的技巧,这些技巧可以让很多管理层或投资人在不了解业务的前提下,就能判断出来数据是否有问题。

  • 量级 Check:每个数据有它的大概范围,比如 DAU,WAU 和 MAU。
  • 计算逻辑 Check:一般对于整体部分型的分数,比如市场份额,那么它必须满足:1,取值最大不能超过1;2,各部分加和应为1;3,两数字加和后,和应该在中间范围内。
  • 业务常识 Check:根据其他常用数字推算出该业务范围。如果有人跟你说某某社交 APP DAU 过亿,你大概知道是否在吹牛,因为日活过亿的 APP 就那么几个。对于 DAU/MAU,各个行业都有响应的范围值,淘宝为:34.6%,天猫15.5%,京东15.8%。

1.4 站在业务方的角度

除了「量化」之外,另外一个重点词语是「业务」。

只有解决业务问题分析才能创造价值。

价值包括个人价值和公司价值。

对于公司来讲,你提高了收入水平或者降低了业务成本,对于个人来讲,你知道怎么去利用数据解决业务问题,这对个人的能力成长和职业生涯都有非常大的帮助。

如何站在业务方的角度思考问题呢,总结起来就是八个字「忧其所虑,给其所欲」。

这里不仅适用于分析师这个岗位,在所有以供需为主要关系的交互过程里,精准理解对方需求对于供给方都是最重要的。比如 PM 对于用户,分析师对于业务方,下级对于上级。

在具体的落地过程中,主要是在这以下几个环节

  1. 沟通充分
  2. 结论简明
  3. 提供信息量及可落地建议
  4. 寻求反馈

在沟通上,确定业务方想要分析什么,提出更合理专业的衡量和分析方式,同时做好节点同步,切忌一条路走到黑。在分析业务需求上,跟很多产品需求分析方法论是类似的,需要明确所要数据背后的含义。

举例来讲,业务方说要看「页面停留时长」,但他实际想要的,可能是想衡量用户质量,那么「留存率」「目标转化率」才是更合适的指标。

在阐述分析结果上,要记得结论先行,逐层讲解,再提供论据。论据上,图 > 表 > 文字。因为业务方或管理层时间都是有限的,洋洋洒洒一大篇邮件,未看先晕,谁都没心思看你到底分析了啥。需要做到:在邮件最前面,用 1-3 句话先把结论给出来,即使需求方不看后续内容都可以了解你报告 80% 的内容。

在「提供信息量及可落地建议」上,先要明白什么叫信息量:提供了对方不知道的信息。太阳明天从东方升起不算信息量,从西方升起才是。在分析的过程中,一定要从专业的角度,从已知边界向未知边界进军,力求角度新颖论证扎实,并且根据分析内容给出可落地的建议。

举个简单例子:

寻求反馈是很多分析过程所缺乏的一步,数据分析给出去后便没有持续跟进。那你就不知道到底做得对不对。

反馈犹如一面镜子,让你及时地调整和优化自己的方法论。

二、WHAT:什么是数据分析

数据分析的本质是抓住「变」与「不变」。

「变」是数据分析的基础,如果一个业务每天订单是 10000 单,或者每天都是以 10% 的速度稳步增长,那就没有分析的必要了。而若想抓住「变」,得先形成「不变」的意识。

积累「不变」,就是养成「数据常识(Data Common Sense)」的过程。「不变」是根据对历史数据不断的观察和积累而来。一般来说会是个范围,范围越精准,你对「变」就越敏感。这里有三个个人的习惯,可以帮助养成「不变」:

  1. 形成习惯,每天上班第一时间查看数据:实时&日周月报
  2. 记住各个指标大数,反复推算
  3. 记录关键数据(榜单&报告)

大部分指标没有记住全部数字的必要,简单记住大数,万以下只需要记到万位,有些数字只需要记住百分比。 而指标之间的推算可以帮助你对各个指标的数量级关系和逻辑脉络梳理清楚,出现波动时便能更加敏感。记录关键数据是将工作生活遇到的比较有趣的榜单或数据报告保存在一个统一的地方,方便查阅和分析。

在「不变」的基础上,便能逐渐培养出指标敏感性,即意识指标偏离的能力。这主要是通过各种日环比,周月同比的监控以及日常的好奇心来保持。

这里插播一则管理林元帅的野史:林彪领军,有个习惯是记清楚每场战斗的缴获和歼敌的数量和种类。在 1948 辽沈战役寻找对方军长的过程中,发现了一个遭遇战的战报数据有了细微的变化。他从过去「不变」的基础意识到了指标偏离:缴获的短枪与长枪比例,缴获和击毁的小车与大车比例及俘虏和击毙的军官与士兵比例都比其它战斗略高。他根据这个偏离的指标迅速圈定了对方指挥所的所在地,一举端掉了对方的大本营。

我们从一个 Questmobile 2017 年春季榜单上,来简单看下「指标偏离」是怎么应用到日常的分析上的:

这里先跟大家分享下怎么看这种榜单:

  1. 看整体排行:看哪些 APP 排在前方是出乎你意料之外的
  2. 分行业看排行:看行业里排行及其变动
  3. 看增长率:哪些 APP 增长比较快
  4. 看使用时长等其他指标

这里我试着抛出几个问题:

  1. 新浪新闻竟然比腾讯新闻还高?今日头条竟然比一点资讯低?
  2. 秒拍竟然比快手高?
  3. 百度地图在榜单上比高德高,为什么去年俞永福还敢宣称活跃终端数第一位?
  4. QQ 的时长已经连续两个季度月活出现下降了,是否意味着什么?
  5. 按增长率排序,最快的王者荣耀,其次是今日头条,快手,高德地图。高德既然还算增长得较快的 APP?

数据分析的定义,还有国外一本商务分析的书籍的定义作为注脚:

三、HOW:怎么进行数据分析

任何数据分析都是「细分,对比,溯源」这三种行为的不断交叉。最常见的细分对比维度是时间,我们通过时间进行周月同比,发现数据异常后,再进行维度或流程上的细分,一步步拆解找到问题所在。如果找到了某个维度的问题,则需要溯源到业务端或现实端,确认问题产生的源头。如果多次细分对比下来仍然没有确认问题,则需要溯源到业务日志或用户访谈来更进一步摸清楚情况。

3.1 细分

以下内容在上篇《大数据与用户研究》中略有提及,这里再做一个总结。在细分方式上,主要有以下三种方式

  1. 横切:根据某个维度对指标进行切分及交叉分析
  2. 纵切:以时间变化为轴,切分指标上下游
  3. 内切:根据某个模型从目标内部进行划分

横切上,以转转举例,我们对维度和指标做做了分类和交叉,当某一类的指标出现问题时,我们便知道该从什么维度进行分析。在进行横切分析时,经常需要多个维度交叉着使用。这在数据分析术语上叫:交叉多维分析。这也是刚才讲的「维度总线矩阵」看到的各维度交叉情况了。

纵切上,有目的有路径,则用漏斗分析。无目的有路径,则用轨迹分析。无目的无路径,则用日志分析。

漏斗分析分为长漏斗和短漏斗。长漏斗的特征是涉及环节较多,时间周期较长。常用的长漏斗有渠道归因模型,AARRR,用户生命周期漏斗等等。短漏斗是有明确的目的,时间短,如订单转化漏斗和注册漏斗。在轨迹分析里,桑基图是一种常用的方式。常见于各页面的流转关系,电商中各品类的转移关系等等。日志分析,则通过直接浏览用户前后端日志,来分析用户的每一个动作。

各种手段的细分往往交叉着使用,如订单漏斗纵切完可以接着横切,看看是哪个维度的转化率导致的问题。

内切上,主要是根据现有市面上常见的分析模型,RFM,Cohort 和 Segment等方式进行分析。RFM 即最近购买时间,频率及金额三个指标综合来判定用户忠诚度及粘性。Cohort,即同期群分析,是通过对不同时期进入平台的新用户分群分析,来区分不同新用户的质量,如留存率或目标转化率等。Segment 通过若干个条件对用户分层,然后针对不同用户进行分层分析和运营,如用户活跃度分层等等。

3.2 对比

对比主要分为以下几种:

  1. 横切对比:根据细分中的横切维度进行对比,如城市和品类
  2. 纵切对比:与细分中的纵切维护进行对比,如漏斗不同阶段的转化率
  3. 目标对比:常见于目标管理,如完成率等
  4. 时间对比:日环比,周月同比;7天滑动平均值对比,7天内极值对比

时间对比严格来说属于横切对比。但因为时间这个维度在数据分析和产品中极为重要,所以单拎出来说。横切对比中,有个比较著名的数据应用方式即是「「排行榜」。通过这种简单粗暴的方式,来驱动人们完成目标,或者占领人们的认知。前者有销售完成排行榜。后者有品类售卖畅销榜。

3.3 溯源

经过反复的细分对比后,基本可以确认问题所在了。这时候就需要和业务方确认是否因为某些业务动作导致的数据异常,包括新版本上线,或者活动策略优化等等。

如果仍然没有头绪,那么只能从最细颗粒度查起了,如

  1. 用户日志分析
  2. 用户访谈
  3. 外在环境了解,如外部活动,政策经济条件变化等等

3.4 衍生模型

在「细分对比」的基础上,可以衍生出来很多模型。这些模型的意义是能够帮你快速判断一个事情的关键要素,并做到不重不漏。

这里列举几个以供参考:

  • Why-How-What
  • 5W1H
  • 5Why
  • 4P模型(产品,价格,渠道,宣传)
  • SWOT 模型(优势,劣势,机会,威胁)
  • PEST 模型(政治,经济,社会,科技)
  • 波士顿矩阵

举个例子:

最近京东和美团外卖可能会发现送货时长延长,针对物流相关的客诉增加,从 PEST 模型就可以分析出来是否在政治上出了问题。而当你在竞品做比对分析时,SWOT 或者 4P 模型能够给你提供不同的角度。

四、数据分析如何落地

以上讲的都偏「道术技」中的「术」部分,下面则通过汇总以上内容,和实际工作进行结合,落地成「技」部分。

4.1 数据分析流程和场景

根据不同的流程和场景,会有些不同的注意点和「术」的结合

4.2 数据分析常见谬误

控制变量谬误:在做 A/B 测试时没有控制好变量,导致测试结果不能反映实验结果。或者在进行数据对比时,两个指标没有可比性。

样本谬误:在做抽样分析时,选取的样本不够随机或不够有代表性。举例来讲,互联网圈的人会发现身边的人几乎不用「今日头条」,为什么这 APP 还能有这么大浏览量?有个类似的概念,叫 幸存者偏差

定义谬误:在看某些报告或者公开数据时,经常会有人鱼目混珠。「网站访问量过亿」,是指的访问用户数还是访问页面数?

比率谬误:比率型或比例型的指标出现的谬误以至于可以单独拎出来将。一个是每次谈论此类型指标时,都需要明确分子和分母是什么。另一方面,在讨论变化的百分比时,需要注意到基数是多少。有些人即使工资只涨 10% ,那也可能是 150万…

因果相关谬误:会误把相关当因果,忽略中介变量。比如,有人发现雪糕的销量和河溪溺死的儿童数量呈明显相关,就下令削减雪糕销量。其实可能只是因为这两者都是发生在天气炎热的夏天。天气炎热,购买雪糕的人就越多,而去河里游泳的人也显著增多。

辛普森悖论:简单来说,就是在两个相差较多的分组数据相加时,在分组比较中都占优势的一方,会在总评中反而是失势的一方。

最后以几句话作为总结,也是全文中心:

  1. 数据准确性是第一位的
  2. 站在业务方的角度思考问题:忧其所虑,予其所欲
  3. 定义「变」与「不变」
  4. 细分,对比,溯源

 

  • Dec 18 / 2017
  • 0
Data

锐眼洞察 | 数据准备迈向Serverless(翻译)

作者:George Leopold

原文:Data Prep Goes Serverless

译者:TalkingData研发副总裁 阎志涛

本译文禁止商用,转载请注明作者与来源!

译者评论: 云服务正在吞噬越来越多的IT的预算,尤其是在美欧等国家。而在国内,各种云服务也取得了巨大的进展。而对于大数据分析来说,从自建数据中心到利用公有云服务的弹性来进行数据处理,也越来越变为一个趋势。对于很多公司来说,随着人员的增加,越来越多的数据科学家和数据分析师需要计算资源来进行数据的处理和建模。面向这些需求,自己购买大量的计算和存储资源显然是巨大的成本开销,而且还很难解决需求与供给间的矛盾。因此,将数据分析和建模工作迁移到云端成为一个不错的选择。而公有云提供商也意识到了这个机会,于是在公有云上提供serverless的数据准备工具就成了一个趋势。这篇文章介绍的就是相关的内容。

云供应商管理计算和存储资源的平台的兴起,为诸如serverless数据准备工具等新的服务打开了大门。自助式服务的准备工具的列表正在增长,供应商提供不同的方法来将原始数据转变为可以便于进行分析的数据。“这些工具旨在减少准备数据的时间和复杂度,从而提高分析的的工作效率”。Gartner最近在对自助服务的数据准备工具的评估中指出。这些供应商估计数据科学家花费超过80%的时间去准备他们用于分析的数据。 基于云的serveless数据准备工具正在取得重大的进展,因为数据分析师正在寻找新的ETL工具去处理他们自己的数据集,从而能够便于进行分析,他们希望这些ETL工具能够替换那些传统的用于数据仓库ETL的标准的工具。 在最近的Gartner对自助数据准备供应商的调查中获得最高分的工具包括Lavastorm和Trifacta。Google最近宣布与Trifacta合作开发称为Google Cloud Dataprep的托管Data Wrangling的测试版本。 这两家合作伙伴说,这个服务旨在利用Google云平台加速面向分析的数据准备工作。这个数据准备工具使用了Google的serverless数据准备引擎——Google Cloud Dataflow,可以根据需要来管理计算资源。 Google通过增加对BigQuery和云存储的支持扩展了Trifacta数据准备服务。 在一个使用案例中,来自物联网和其他设备的原始事件数据被放入BigQuery中,通过添加数据描述符,然后与其他数据源相结合,可以使用Looker等专门支持Google数据库的分析工具非常容易的进行查询。 在一篇博客文章中,Qubit分析产品经理Mark Rittman表示,他使用这个配置来设置BigQuery表以接收运行在Google Compute Engine虚拟机上的服务器发送的流式注入的数据。 利用Fitbit健康追踪器的数据,他利用“类似电子表格的界面”的Google工具来处理数据。 Rittman指出,目前还缺少一些对Google Cloud API的支持,例如对谷歌自然语言处理API。 他预计,Google会升级和增加更多扩展到Trificata代码中从而能够支持更多serverless分析的特性。 Serverless数据准备顺应了大数据分析从私有化Hadoop部署到公有云转变的趋势。Gartner估计全球公有云服务将会增长18%达到2470亿美金,到2020年,云服务将会占领分析市场采购的大部分预算。  

  • Dec 15 / 2017
  • 0
Data

锐眼洞察 | 隐私合规新时代(翻译)

作者:Dimitri Sirota

原文:Always New Era Continuous Privacy Compliance

译者:TalkingData全球业务负责人 戴民

本译文禁止商用,转载请注明来源与译者!

距欧盟GDPR实施仅几个月,就有越来越多的企业在思考应该做些什么,使其业务符合新规的要求。很多企业首先尝试的是做一些基于隐私影响评估(PIA)的调查,因为对于隐私领域的专家来说,这是他们最熟悉的方法。但是新规GDPR的核心是数据保护,包括数据安全和数据责任。这两者中的任何一个都不能通过调查来实现。要想满足这两个要求,需要丰富的数据知识以及具备监测变化、风险活动以及潜在违规行为的能力。PIA在应用过程中能发挥其应有的作用,但是在隐私设计和隐私运营方面,只有数据驱动的持续隐私监测才可以做到。

事与愿违

近年来,数据违规行为风行,个人数据错误使用事件频发。为应对此类问题,立法者和监管者想方设法制定各种措施来保护数据。但是,如果对储存的个人数据没有进行详细的统计计算,很多措施是无法实施的。这在很多方面也反映了很多企业在保护其最隐私的信息资产的方式发生了巨大变化。

隐私领域的专家过去是通过制定更合理的政策和流程来保证合规性,而PIA在某些方面就是用来衡量政策和流程的有效性。但是证据显示,数据违规发生的频次和范围仍在加剧。这无疑证明调查研究在数据保护、数据隐私和数据政策方面是无效的。通过主观评测或者不完整的调查问卷来降低数据风险几乎是不可能的。管控风险应从制定客观精准的衡量指标开始。

数据风险在不断演化

过去几年,在评估第三方风险和供应商风险管理领域,客观风险评价指标发生了几次演化。过去,第三方风险也是通过表格或者问卷的形式进行评估的。然而,这种形式也限制了评估的重复性、客观性和预测性。因此,最近几年,第三方风险评估变得更加实用,对于那些想降低风险的人来说,这种结果性评估能够为他们提供一定的指导。

随着BigID几个工具的发布,这些工具主要是用于寻找、匹配和分析个人数据。风险评估已经从过去的基于调查的主观性评估,转化为数据驱动的持续性风险评估。了解数据收集或加工是否超过法律或者商业政策的红线,已经成为了数据监测的一个功能。数据合规和风险管控的方法,已经从过去单纯的靠猜测转化为24小时不间断的监测。

运营隐私

像GDPR这样的法规不断地在鼓励公司去运营隐私,从研发到生产都要能够保证隐私不被泄漏。这就要求数据风险是能够被监测和衡量的。调查能够让一个企业感觉他们所作所为是符合数据隐私法规的,但是那只是一种假的安全感。去真正的运营隐私,需要有数据意识,并在研发和生产过程中持续衡量隐私。BigID就是致力于运用数据知识24小时不间断保证隐私合规和安全。

  • Dec 11 / 2017
  • 0
Data

锐眼洞察 | 2018年大数据趋势(翻译)

作者:George Hill

原文:Big Data Top Trends 2018——We take a look at what will happen to big data in the next 12 months

译者:TalkingData解决方案架构师 张雪倩

本译文禁止商用,转载请注明来源与译者!

 

2017年是数据成为主流的一年,从业内人员所认为的流行语转变成为所有人都在谈论的东西,无论是关于大数据黑客的描述还是人工智能抢走人们工作的恐怖故事。突然之间,数据确确实实在大众观念里占有了一席之地,没有以应有的方式使用数据的人,结果都受到了批评。然而,接下来的12个月很有可能见证数据启蒙更加扩大,市场改变速度更快。

就是这样一幅极难预料的动态图景,我们每年尽力去拼凑对接下来12个月的预测:

更多地向云端转移

没人会奇怪企业都看到了曙光,纷纷向云端转移。起初关于云端数据安全性的担忧,被这样的观念所替代——当在网上发布东西时,云端相比于大多数公司所能提供的都要安全得多。

越来越多的员工远程办公,意味着无论他们在世界各地的哪里,都有安全获取数据和分析工具的需求,使得大数据即服务(BDaaS)成为了日益重要的工具。当可扩展性、速度、便捷性和成本都得到了增加,Forrester预测下一年50%的企业都会采取云优先政策,也不是什么新鲜事了。

“实时”持续增长

根据“垂直分层分析市场——全球市场预测与分析(2015 – 2020)”报告,在2015 至2020年间,实时分析预测平均每年增长31.3%,似乎其在市场上仍起支配作用。

多亏了科技的普及和成本的降低,曾经仅限于大公司和有钱公司的举措现在在中小公司中越来越常见。越来越多的公司寻求内存和芯片内方法来尽可能快地获取和分析数据,一旦竞争者开始运用这项技术来更快地作出决策,市场也会被迫接受它。

根据罗杰斯采用曲线,目前我们刚刚开始从早期采用者发展为早期多数人群,但2018年是我们开始进入早期多数人群阶段的时间。这一趋势也是由日益增长的必要性所驱动的,大大小小的公司收集和分析数据以在各自的市场中保持竞争力。所以不单单是跨国集团需要实时分析,人人都需要。

掩埋大数据

“大数据”这一词会悄悄地重复IT的老路,有很宽泛的意思但单独来说几乎没什么意义。和IT一样,大数据是个在人们头脑中涵盖了太多的词,以至于除了对知之甚少的人说“我在大数据领域工作”以外,没有真正确切的意义。

现在有太多不同的东西可以算在大数据内,从机器学习和数据收集到分析和数据安全,其中任何一项和另一项都没有太大的关系,但仍归类为“大数据”。由于黑客、机器人、自动驾驶汽车和无数其它数据驱动的技术,即使在大数据领域没有相关利益的人中,对这些领域的认识也在不断提升。

这意味着即使大数据这个词的使用不会消失,把它用来描述整体数据以外的用法也会消失。大数据已死,大数据万岁。

媒体审查增加

过去一年中出现的大型黑客事件的数量意味着公众现在完全意识到了公司拥有多少数据,一旦这些数据丢失会造成多大损害。我们还从铺天盖地声称俄罗斯影响美国大选的媒体报道中发现了数据企业实际上持有多少个人数据,无论是脸书还是更加秘密的民意调查公司。

我们还看到了对人工智能和自动驾驶汽车等部分数据图景的极大兴趣,这在全球都曾成为重大新闻。尤其是人工智能,许多危言耸听的说法使其在许多新闻媒体的报道中都是热点话题。

这一觉醒意味着数据不再只是技术达人关注的领域,而是和其它主流话题一样被大众媒体报道。这意味着这些领域很有可能受到审查,只是因为现在公众了解的更多了。

这对行业来说是福是祸还有待观望。一方面,它会将公众指引到历史上被忽略的地方,但另一方面,它会带来部分谣言,和人工智能夺走人们的工作类似。

量子计算机更加真实

目前,量子计算机不过是有一些惊人数字支持的理念。谷歌、图灵研究所、微软、因特尔和许多其它公司已经做了许多令人赞叹的量子计算机实验,但现实却是我们离真实可用的量子计算机还有一定距离。

然而,经过2018年,随着进行更多各种各样的实验,我们很有可能看到量子计算机更加成型。根据2016年7月谷歌发布的一篇论文,到2017年底,他们就会有49量子位的计算机工作,这意味着它会远远超越任何现存的超级计算机。我们听说,谷歌透露说50量子位是原理证明,能立时呈现10,000,000,000,000,000位数字,远超我们目前所能生产的普通的计算机的存储能力。

2018年不会是量子突然开始成为常态或全球最大的公司可以使用的一年,但我们目前看到的是“这对开发出一部完全可扩展的机器来说绝对是进步”,牛津大学实验物理学Hooke教授和科研副校长Ian Walmsley这样说。

黑客规模更大

Benjamin Franklin(本杰明﹒富兰克林)曾说过一句很有名的话“在这个世界上,一切都不是绝对的,除了死亡和纳税以外”,在2018年,我们可以加上“还有大型黑客事件会影响公司”。

最大的10次非法入侵中8次都发生在过去3年中并非偶然。数据安全性可能在提高,但是基本上与想偷数据的人技术增长速度同步。如今,随着大量数据被收集,大型黑客事件只会继续增长,我们在写这篇文章的时候,Uber黑客事件真正的规模和其掩盖行为正遭到曝光,目前已明确了的是5700万账户信息被盗取,而且Uber花了10万美元来让黑客保持沉默。

随着数据收集更多,公司花钱或让黑客解锁数据或使其停止分享这些数据,这种事只会向坏的方向发展。根据Symnatec的研究,相比于2016年,公司支付用勒索软件入侵的黑客的金额急剧增长了266%。与此同时,很少有人因黑客行为被捕。如果黑客行为获利金额增长,而且只有很小的可能性被抓,现实就会变成,人们将其看作机会,黑客活动也会增加。

人工智能继续前进

人工智能正对世界产生巨大的影响,鉴于2017年我们看到的巨大进步,其在接下来的12个月中只会增长。越来越多的公司正在采用人工智能技术进行任何数量的行为,从相对较基础的应用如仓库管理和聊天机器人,到更复杂的部分,如会计和数据科学,不过这很有可能在接下来的12个月中更深入发展。

其中最重要的部分会是自动驾驶汽车能力更加强大,在更多地形的用途和性能上都有所体现。例如,英国财政大臣宣布2024年开始,自动驾驶汽车将会批准上路,但是到那时也只是有人类在驾驶舱的情况下才可以。我们还会看到更多的人工智能解决极其复杂问题的实验,DeepMind在这方面就走在前列,即使目前仅仅表现为围棋和象棋等游戏的形式。然而,2018年可能会是我们看到这些要素成为人工智能更加深入发展基础的一年。

随着Google Home和Amazon Alexa等产品极大增多和Apple HomePod将更多设备带进人们家中,我们还可以看到,人工智能走进了千家万户。这不单单是一时的热潮,根据加拿大皇家银行资本市场3月份的研究,“声控互联网”设备到2020年可能会有100亿美元的市场,到那时显示出巨大的增长。亚马逊目前控制着70%左右的市场,随着Alexa在2017年第二季度销量增长了25%,这表明市场还没有被完全占领。

  • Dec 04 / 2017
  • 0
Data, Tech

锐眼洞察 | Salesforce的二次开发平台的多租户架构(翻译)

原文:The Force.com Multitenant Architecture

译者:TalkingData研发副总裁 孔元明

本译文禁止商用,转载请注明来源与译者!

译者点评:

Force.com是十分优秀的多租户二次开发平台,本文详细讲述了它的高层设计。有很强的参考意义,但不建议简单模仿。

概要

Force.com是今天的卓越的按需应用程序开发平台,支持大约47,000多个组织。 企业和商业SaaS供应商都相信该平台能够提供健壮,可靠的互联网级应用程序。 为了满足其庞大用户群的极端需求,Force.com的基础是支持多租户应用的元数据驱动的软件架构。 本文解释了使Force.com平台快速,可扩展且安全的专利技术,适用于任何类型的应用程序。

介绍

历史表明,每隔一段时间,技术的不断进步和商业模式的变化就会在软件应用程序的设计,构建和交付给最终用户的方式上产生重大的范式转变。个人计算机(PC),计算机网络和图形用户界面(UI)的发明使得客户机/服务器应用程序替换昂贵的,不灵活的字符模式大型机应用程序成为可能。而今天,可靠的宽带互联网接入,面向服务的体系结构(SOA)以及管理专用本地应用程序的成本效率低下正在推动向可交付,可管理,共享的基于Web的服务(称为SaaS)。随着每一个模式的转变都带来了一系列新的技术挑战,SaaS也不例外。然而,现有的应用程序框架并不是为满足SaaS的特殊需求而设计的。这种空白导致了另一种新的范式转变,即平台即服务(PaaS)。托管应用程序平台是专为满足构建SaaS应用程序的独特挑战而设计的托管环境,并比以往更具成本效益。

本文的重点是多租户,这是一个基本的设计方法,可以显着帮助提高SaaS应用程序的可管理性。 本文定义了多租户,解释了多租户的优势,并说明了为什么元数据驱动架构是实现多租户的首要选择。 在这些大致介绍之后,本文的大部分内容解释了Force.com的技术设计,这是世界上第一个为互联网级应用程序提供交钥匙多服务的PaaS。 本文详细介绍了Force.com的专利元数据驱动架构组件,以便了解用于提供可靠,安全和可扩展的多租户应用程序的功能。

多租户应用

为了降低向多个不同的用户提供相同的应用程序的实施成本,越来越多的应用程序是多租户的,而不是单租户。 传统的单租户应用需要专门的资源来满足一个组织的需求,而多租户应用则可以满足多个租户(公司或公司内部的部门等)而只需要管理一个软件实例所需的硬件资源和人员的需求(图1)。

p1.png

多租户是一种向应用程序提供商和用户带来巨大收益的架构方法。 仅为多个组织运行一个应用程序实例会为提供商带来巨大的规模经济效益。 只需要一套硬件资源来满足所有用户的需求,一个经验丰富的管理人员就可以高效地管理一堆软硬件,开发人员只需在一个平台(操作系统,数据库等)上构建和支持一个代码库而不是许多平台。 多租户的经济性使应用程序提供商能够以较低的成本向客户提供服务。 每个参与的人都赢了。

多租户的一些有趣的优点是提高了质量,用户满意度和客户保留率。 与单租户应用程序(应用程序提供商无法使用的孤立孤岛)不同,多租户应用程序是由供应商自己托管的一个大型社区。 这种设计转变使供应商可以从集体用户群体(查询响应缓慢,发生什么错误等)收集操作信息,并对服务进行频繁,渐进式的改进,从而使整个用户群体受益匪浅。

多租户基于平台的方法的另外两个好处是协作和集成。 由于所有用户都在一个空间中运行所有应用程序,因此任何应用程序的任何用户都可以轻松访问特定的数据集。 此功能大大简化了集成相关应用程序及其管理的数据所需的工作。

比较原始云计算和PaaS

原始计算云是以机器为中心的服务,为应用程序的部署按需提供IaaS。 这样的云只提供了执行应用程序的虚拟服务器所需的计算能力和存储容量。 一些寻求快速上市策略的SaaS供应商避免了开发真正的多租户解决方案以及选择通过IaaS交付单租户实例的挑战。

像Force.com这样的平台即服务(PaaS)是一种以应用程序为中心的方法,它将服务器的概念完全抽象出来。 PaaS让开发人员从一开始就专注于核心应用程序开发,并通过按钮来部署应用程序。 提供商从不需要担心多租户,高可用性,负载平衡,可扩展性,系统备份,操作系统补丁和安全性以及其他类似的基础设施相关问题,所有这些服务都以PaaS中的“S”形式提供。

元数据驱动的架构

只有当它支持可靠,可定制,可升级,安全和快速的应用程序时,多租户才是实用的。 但是,多租户应用程序如何允许每个租户为标准数据对象和全新的自定义数据对象创建自定义扩展? 租户特定数据如何在共享数据库中保持安全,保证一个租户不能看到另一个租户的数据? 一个租户如何实时定制应用程序的界面和业务逻辑,而不影响所有其他租户的应用程序的功能或可用性? 如何修补或升级应用程序的代码库而不破坏特定于租户的定制? 随着成千上万的租户订阅服务,应用程序的响应时间如何呢?

创建静态编译的应用程序可执行文件是很难满足多租户的这些独特挑战。 本质上,多租户应用程序必须是动态的,或多态的,以满足各种租户和用户的个人期望。

由于这些原因,多租户应用程序设计已经发展到使用运行时引擎从元数据(应用程序本身的数据)生成应用程序组件 。 在一个定义良好的元数据驱动架构(图2)中,编译后的运行时引擎(内核),应用程序数据,描述应用程序基本功能的元数据,每个租户数据和定制化表的元数据,这四者之间有清晰的边界。 这些独特的边界使独立更新系统内核,独立修改核心应用程序,独立定制特定于租户的组件成为可能,而几乎不存在影响其他组件的风险。

p2.png

新的挑战和新的解决方案

尝试在应用程序的核心逻辑及其底层基础架构中编织多租户是一项复杂的任务。 从零开始构建元数据驱动的多租户应用程序,没有任何先前的经验,注定是一个耗时且易出错的工作。 最终,许多想成为SaaS的提供商将难以成功地构建多租户应用程序,并最终浪费宝贵的时间,而这些宝贵的时间本可以用在核心应用程序功能和特性的创新上。

一个问题是,传统的应用程序开发框架和平台没有适应现代Internet应用程序的特殊需求。 因此,新类型的平台正在形成,以帮助简化多租户应用程序的开发和部署。

Force.com是当今第一个也是最成熟的通用多租户互联网应用开发平台。 本文的其余部分解释了有关Force.com技术设计的具体细节,以便您更好地了解其功能。

Force.com平台体系结构概述

Force.com优化的元数据驱动架构可为按需多租户应用程序提供出色的性能,可扩展性和定制性(图3)。

p3.png

在Force.com中,暴露给开发人员和应用程序用户的所有内容均在内部表示为元数据。表单,报表,工作流程,用户访问权限,特定于租户的自定义和业务逻辑,甚至是底层数据表和索引的定义,都是抽象结构,仅仅作为Force.com的通用数据字典(UDD)中的元数据存在。 例如,当一个开发人员构建一个新的自定义应用程序并定义一个自定义表格,编写一个表单或编写一些程序代码时,Force.com不会在数据库中创建“实际”表格或编译任何代码。 相反,Force.com只是存储元数据,平台引擎可用这些元数据在运行时生成“虚拟”应用程序组件。 当有人想要修改或自定义应用程序的某些内容时,只需对相应的元数据进行简单的非阻塞更新即可。

由于元数据是Force.com应用程序的关键组成部分,因此平台的运行时引擎必须优化对元数据的访问; 否则,频繁的元数据访问会阻止平台扩展。 考虑到这个潜在的瓶颈,Force.com使用元数据高速缓存来维护内存中最近使用的元数据,避免性能降低磁盘I / O和代码重新编译,并改善应用程序响应时间。

Force.com将所有虚拟表的应用程序数据存储在几个用作堆存储的大型数据库表中。 然后平台的引擎通过考虑相应的元数据在运行时实现虚拟表数据。

为了优化对系统大型表中数据的访问,Force.com的引擎依赖于一组专门的数据透视表,这些数据透视表维护了非范式化的数据用于不同的目的,如索引,唯一性,关系等。

Force.com的数据处理引擎通过批量透明地执行数据修改操作,有助于简化大型数据加载和联机事务处理应用程序的开销。 该引擎具有内置的故障恢复机制,可以在找出导致错误的记录之后自动重试批量保存操作。

为了进一步优化应用程序响应时间,该平台采用了一种外部搜索服务,可以优化全文索引和搜索。 随着应用程序更新数据,搜索服务的后台进程几乎实时地异步更新租户和用户特定的索引。 应用程序引擎和搜索服务之间的职责分离使平台应用程序能够高效地处理事务处理,而无需文本索引更新的开销,同时快速为用户提供准确的搜索结果。

由于Force.com的运行时应用程序生成器动态构建应用程序以响应特定的用户请求,因此引擎严重依赖于其“多租户感知”查询优化器来尽可能高效地执行内部操作。 查询优化器考虑哪个用户正在执行给定的应用程序功能,然后使用UDD中维护的相关租户特定元数据以及内部系统数据透视表,构建并执行数据访问操作作为优化的数据库查询。

现在您已经对构成Force.com基础机制的关键体系结构组件有了一个大概的概念,下面的章节更详细地解释了各种内部系统元素的结构和目的。

Force.com数据定义和存储

Force.com存储模型并不是试图代表每个应用程序和租户来管理大量的,不断变化的实际数据库结构,而是使用一组元数据,数据和数据透视表来管理“虚拟”数据库结构,如图4。

p4.png

当组织创建自定义应用程序对象(即自定义表)时,UDD会跟踪有关对象,其字段,关系和其他对象定义特征的元数据。 同时,一些大型数据库表存储所有虚拟表的结构化和非结构化数据,一组相关的专用数据透视表维护非范式化的数据,使组合的数据集非常有用。

图5是三种核心Force.com元数据和数据结构的简化实体关系(ER)图,这些元数据和数据结构实现了这种方法:对象,字段和数据表。

注:为了简明扼要,Force.com系统表和列的实际名称没有在本文中引用。

Objects Metadata Table:

Objects Metadata Table存储组织为应用程序定义的自定义对象(又名表或实体)的信息,包括对象(ObjID)的唯一标识符,拥有该对象的组织(OrgID)以及给予该对象的名字(ObjName)。

Fields Metadata Table:

Fields Metadata Table存储组织为自定义对象定义的自定义字段(又名列或属性)的信息,包括字段的唯一标识符(FieldID),拥有该包含对象的组织(OrgID),包含 字段(FieldName),字段的数据类型,指示字段是否需要索引(IsIndexed)的布尔值,以及对象中的字段相对于其他字段(FieldNum)的位置。

p5.png

Data Table:

数据表存储映射到所有自定义对象及其字段的应用程序可访问数据,如对象和字段中的元数据所定义。 每行包括标识字段,如全球唯一标识符(GUID),拥有该行(OrgID)的组织和包含对象标识符(ObjID)。 数据表中的每一行还有一个名称字段,用于存储相应对象实例的“自然名称”; 例如,一个Account对象可能使用“Account Name”,Case对象可能使用“Case Number”,等等。 Value0 … Value500列存储映射到Objects和Fields表中声明的对象和字段的应用程序数据; 所有“flex”列都使用可变长度字符串数据类型,以便可以存储任何结构化类型的应用程序数据(字符串,数字,日期等)。

自定义字段可以使用多种标准结构化数据类型中的任何一种,例如文本,数字,日期和日期/时间以及特殊用途的结构化数据类型,如选项列表(列举字段),自动编号(自动增量,系统生成的序列号) ,公式(只读派生值),主从关系(外键),复选框(布尔),电子邮件,URL等。 自定义字段也可以是必需的(非空),并具有自定义验证规则(例如,一个字段必须大于另一个字段),这两者都由平台的应用程序服务器强制执行。

当组织声明或修改自定义应用程序对象时,Force.com在定义该对象的Objects表中管理一行元数据。 同样,对于每个自定义字段,Force.com管理Fields表中的一行,包括将该字段映射到Data表中的特定Flex列以存储相应字段数据的元数据。 由于Force.com将对象和字段定义作为元数据而不是实际的数据库结构进行管理,因此平台可以容忍多租户应用程序模式维护活动,而不会阻塞其他租户和用户的并发活动。

同一对象的两个字段不能映射到Data表中的同一个Flex列(槽)进行存储; 然而,只要每个字段来自不同的对象,单个Flex列就可以管理多个字段的信息。

p6.png

如图6中Data表的简化表示所示,flex列是通用数据类型(可变长度字符串),它允许Force.com在一个flex列中使用多个不同结构化数据类型(字符串,数字 ,日期等)。

Force.com使用统一的规范格式存储所有Flex列数据,当应用程序从Flex列中读写数据时,根据需要使用基础数据库系统的数据类型转换函数来转换数据类型(例如TO_NUMBER,TO_DATE,TO_CHAR)。

尽管图5中未显示,但数据表还包含其他列。 例如,有四列来管理审计数据,包括何时和谁创建对象实例(行),以及何时和谁上次修改对象实例。 数据表还包含一个IsDeleted列。Force.com用来指示对象实例何时被删除。

Clobs Table:

Force.com支持将字段声明为字符大对象(CLOB),以允许存储长达32,000个字符的长文本字段。 对于具有CLOB的Data表中的每一行,Force.com都将CLOB存储在名为Clobs的数据透视表中,系统可以根据需要将其与Data表中的对应行进行连接。

注意:Force.com还将索引形式的CLOB存储在数据库外部以进行快速文本搜索。 有关Force.com文本搜索引擎的更多信息,请参阅第9节。

Indexes Pivot Table:

传统的数据库系统依靠索引来快速定位数据库表中具有匹配特定条件的字段的特定行。 但是,为Data表的flex列创建本地数据库索引是不现实的,因为Force.com可能使用单个flex列来存储具有不同结构化数据类型的多个字段的数据。 相反,Force.com通过将标记为索引的字段数据同步复制到名为Indexes的数据透视表中的相应列,来管理Data表的索引,如简化的ER图(图7)所示。

Indexes表包含强类型的索引列,如StringValue,NumValue和DateValue,Force.com用来定位相应数据类型的字段数据。 例如,Force.com会将数据表flex列中的字符串值复制到Indexes中的StringValue字段,DateValue字段的日期值等。Indexes表的基础索引是标准的非唯一数据库索引。 当内部系统查询包含引用自定义对象中的结构化字段的搜索参数时,平台的查询优化程序将使用索引表来帮助优化关联的数据访问操作。

p7.png

注意:Force.com可以处理跨多种语言的搜索,因为平台的应用程序服务器使用了一种将字符串值转换为通用的,不区分大小写的格式的大小写折叠算法。 Indexes表的StringValue列以这种格式存储字符串值。 在运行时,查询优化器会自动构建数据访问操作,以便优化的SQL语句过滤对应于搜索请求中提供的文字的相应大小写的StringValue。

UniqueFields Pivot Table:

Force.com允许组织指示对象中的字段何时必须包含唯一值(区分大小写或不区分大小写)。 考虑到数据表的安排以及自定义字段数据的值列的共享使用情况,为表创建唯一的数据库索引(类似于上一节讨论的非唯一索引的问题)是不实际的。

为了支持自定义字段的唯一性,Force.com使用名为UniqueFields的数据透视表; 除了UniqueFields表的底层数据库索引强制唯一性以外,此表与Indexes数据透视表非常相似。 当应用程序尝试将重复值插入到需要唯一性的字段中,或者管理员尝试在包含重复值的现有字段上强制执行唯一性时,Force.com会将相应的错误消息转发给应用程序。

Relationships Pivot Table:

Force.com提供了“关系”数据类型,组织可以用它来声明应用程序对象之间的关系(参照完整性)。 当组织使用关系类型声明对象的字段时,平台将该字段映射到数据表中的值字段,然后使用此字段存储相关对象的ObjID。

为了优化连接操作,Force.com维护一个名为Relationships的数据透视表,如图8所示。

p8.png

关系索引表具有两个底层数据库唯一的复合索引(OrgID + GUID和OrgID + ObjID + RelationI D + TargetObjID),可根据需要在任一方向进行高效的对象遍历。

FallbackIndex Table:

在极少数情况下,平台的外部搜索引擎可能变得过载或不可用,并且可能无法及时响应搜索请求。 平台的应用程序服务器并没有将一个令人失望的错误返回给请求搜索的用户,而是回退到二级搜索机制来提供合理的搜索结果。

回退搜索是作为直接数据库查询实现的,搜索条件引用了目标应用程序对象的名称字段。 要优化全局对象搜索(跨越对象的搜索),而不必执行潜在的昂贵的联合查询,Force.com将维护一个名为FallbackIndex的数据透视表,记录所有对象的名称。 事务修改对象对于Fallback Index的更新是同步发生的,所以回退搜索总是可以访问最新的数据库信息。

NameDenorm Table:

NameDenorm表是一个精简数据表,它存储数据表中每个对象实例的ObjID和Name。 当应用程序需要提供超链接到父/子关系中涉及的对象实例的列表时,Force.com使用NameDenorm表执行一个相对简单的查询,该查询检索每个引用的对象实例的名称作为超链接的一部分显示。

History Tracking Table:

Force.com可轻松为任何字段提供历史记录。 当组织为特定字段启用审计时,系统将使用内部数据透视表作为审计跟踪异步记录有关对字段所做更改的信息(旧值和新值,更改日期等)。

数据和元数据的分区:

所有Force.com数据,元数据和数据透视表结构(包括基础数据库索引)均由OrgID(租户)使用本机数据库分区机制进行物理分区。 数据分区是数据库系统提供的一种经过验证的技术,可将大型逻辑数据结构物理划分为更小,更易管理的部分。 分区还可以帮助提高大型数据库系统(如多租户环境)的性能,可伸缩性和可用性。 例如,根据定义,每个Force.com应用程序查询都以特定租户的信息为目标,因此查询优化器只需要考虑访问包含租户数据的数据分区,而不是整个表或索引,这种常见的优化有时被称为“ 分区修剪“。

应用程序开发,逻辑和处理

Force.com支持两种不同的方式来创建自定义应用程序及其各个组件:声明式地使用本地平台应用程序框架,并使用应用程序编程接口(API)以编程方式进行创建。 以下部分将更详细地介绍每种方法和相关的应用程序开发主题。

Application Framework:

开发人员可以使用“原生”Force.com应用程序框架声明性地构建自定义的Force.com应用程序。 该平台的本地点击式界面支持应用程序开发过程的所有方面,包括创建应用程序的数据模型(自定义对象及其字段,关系等),安全性和共享模型(用户,组织层次结构,配置文件 等),用户界面(屏幕布局,数据输入表格,报告等)以及逻辑和工作流程。

Force.com应用程序框架用户界面很容易构建,因为不需要编码。 在幕后,他们支持所有通常的数据访问操作,包括查询,插入,更新和删除。 本地平台应用程序执行的每个数据操作操作可以一次修改一个对象,并自动提交单独事务中的每个更改。

Force.com的本地集成开发环境(IDE)提供了对许多内置平台功能的轻松访问,从而可以轻松实现通用应用程序功能,而无需编写复杂且易于出错的代码。 这些功能包括声明式工作流程,加密/屏蔽字段,验证规则,公式字段,汇总摘要字段和交叉对象验证规则。

工作流是由插入或更新对象实例(行)触发的预定义操作。 工作流可以触发任务,电子邮件警报,更新数据字段或发送消息。 工作流规则指定确定何时触发工作流操作的条件。 可以将工作流程设置为立即触发,或设置为在触发事件之后的后续间隔内进行操作。 例如,开发人员可能会声明一个工作流,在更新记录后立即自动将该行的“状态”字段更新为“已修改”,然后将模板电子邮件警报发送给主管。 所有工作流程操作都发生在触发工作流程的事务上下文中。 如果系统回滚事务,则执行的所有相关工作流操作也会回滚。

为包含敏感数据的对象定义文本字段时,开发人员可以轻松配置该字段,以便Force.com加密相应的数据,并可选择使用输入掩码来隐藏屏幕信息。 Force.com使用AES(高级加密标准)算法128位密钥来加密字段。

声明式验证规则是组织无需任何编程即可执行域完整性规则的简单方法。 例如,图9中的第一个屏幕截图说明了使用Force.com IDE声明确保LineItem对象的Quantity字段总是大于零的验证规则是多么容易。

公式字段是Force.com应用程序框架的声明性功能,可以轻松地将计算的字段添加到对象。 例如,图9中的第二个屏幕截图也显示了开发人员如何使用一个简单的IDE窗体向LineItem对象添加一个字段来计算LineTotal值。

汇总摘要字段是一个跨对象字段,可以很容易地在父对象中聚合子字段信息。 例如,图9中的最终屏幕截图显示了如何使用IDE根据LineItem对象的LineTotal字段在SalesOrder对象中创建OrderTotal摘要字段。

注意:在内部,Force.com使用本地数据库功能实现公式和汇总摘要字段,并有效地重新计算值作为正在进行的事务的一部分。

p9.png

Metadata and Web Services APIs:

Force.com还为构建应用程序提供了编程API。 这些API与基于SOAP的开发环境(包括Visual Studio .NET(C#)和Apache Axis(Java和C ++))兼容。

应用程序可以利用Force.com API与其他环境集成。 例如,应用程序可以利用API来访问其他系统中的数据,构建混合来源于多个数据源的混搭,将外部系统作为应用程序进程的一部分,或者构建胖客户端以连接Force.com Platform数据库管理系统。

Force.com元数据API对管理应用程序组件非常有用 – 创建和修改与自定义对象定义,页面布局,工作流等相对应的元数据。创建,检索,更新或删除对象实例(数据行) ,应用程序可以使用Force.com Web服务API。

要访问Force.com Web服务,开发人员首先下载一个Web服务描述语言(WSDL)文件。 开发平台然后使用WSDL文件生成一个API来访问组织的相应Force.com Web服务(数据模型)。

有两种类型的Force.com WSDL文件。 企业WSDL文件适用于构建组织特定应用程序的开发人员。 企业WSDL文件是组织数据模型的强类型表示。 它向开发环境提供有关组织架构,数据类型和字段的信息,从而使其与Force.com Web服务之间的集成更紧密。 如果将自定义字段或自定义对象添加到组织的应用程序模式,或者从组织的应用程序模式中删除自定义对象,企业WSDL也会发生变化 相反,合作伙伴WSDL文件适用于为多个组织开发客户端应用程序的salesforce.com合作伙伴。 作为Force.com对象模型的松散类型表示形式,合作伙伴WSDL提供了一个API,可用于访问任何组织内的数据。

Bulk Processing with API Calls:

事务密集型应用程序产生的开销较小,并且在批量组合和执行重复操作时性能会更好。 例如,对比应用程序可能加载对象的许多新实例的两种方式。 一个低效率的方法是使用一个循环插入单个对象实例的例程,为每个插入操作进行一次API调用。 更有效的方法是创建一个对象实例的数组,并让这个例程通过一个API调用来插入所有的对象。

适用的Force.com Web Services API调用(如create(),update()和delete()支持批量操作。 为了获得最大的效率,平台隐式地批量处理与显式批量操作相关的所有内部步骤,如图10所示。

p10.png

图10还说明了Force.com的批量处理引擎的独特机制,可以解决在任何一步中遇到的孤立故障。 当批量操作在部分保存模式下启动时,引擎会识别已知的启动状态,然后尝试执行过程中的每个步骤(批量验证字段数据,批量预触发器,批量保存记录等)。 如果引擎在任何步骤中检测到错误,则引擎将回滚违规操作和所有副作用,删除引发故障的行,并继续尝试批量处理剩余的行子集。 这个过程遍历整个过程的每个阶段,直到引擎可以提交行的一个子集而没有任何错误。 应用程序可以检查返回对象,以确定哪些行失败以及引发了哪些异常。

注意:根据应用程序的判断,批量操作也可以使用“要么全成功或要么全不成功”模式。 此外,批量操作期间触发器的执行受制于限制工作量的内部调节器。

Deletes, Undeletes, and The Recycle Bin:

当某人从自定义对象中删除单个对象实例(记录)时,Force.com只需通过修改对象实例的IsDeleted字段(在数据表中)将其标记为要删除的对象实例。 这有效地将对象放置在所谓的平台回收站中。 通过Force.com,用户可以从回收站中查看并恢复选定的对象实例长达30天,然后将其从内部数据表中永久删除。 该平台根据组织的用户许可总数限制其为组织维护的记录总数。

当某人删除涉及主从关系的父记录时,Force.com会自动删除所有相关的子记录,只要这样做不会违反任何参照完整性规则。 例如,当用户删除SalesOrder时,Force.com自动将删除级联到相关的LineItems。 如果有人随后从回收站还原父记录,平台也会自动恢复所有子对象实例。

相比之下,当某人删除涉及查找关系的引用父记录时,Force.com会自动将所有相关主键设置为空。 如果某个人随后恢复父记录,Force.com将自动恢复以前的空值关联关系,除非在删除操作和还原操作之间这些关联关系被重新分配了。

回收站还会存储丢失的字段及其数据,直到组织永久删除它们,或者已经过了45天,以先发生者为准。 直到那个时候之前,整个领域和所有的数据可用于恢复。

Data Definition Processing:

某些类型的对象定义修改需要的不仅仅是简单的UDD元数据更新。 在这种情况下,Force.com使用有效的机制来帮助降低平台多租户应用程序的总体性能影响。

例如,考虑当某人将列的数据类型从选取列表修改为文本时发生的情况。 Force.com首先为列的数据分配一个新插槽,批量复制与当前值关联的选取列表标签,然后更新列的元数据以使其指向新插槽。 发生这一切时,访问数据是正常的,应用程序继续运行,没有任何明显的影响。

作为另一个例子,考虑当某人向表中添加汇总摘要字段时会发生什么情况。 在这种情况下,Force.com使用高效批量操作在后台异步计算初始摘要。 在进行后台计算时,查看新字段的用户会收到Force.com平台当前正在计算字段值的指示。

内部查询优化

大多数现代数据库系统通过采用基于成本的查询优化器来确定最佳的查询执行计划,该优化器考虑有关目标表和索引数据的相关统计信息 但是,传统的基于成本的优化器统计信息是为单租户应用程序设计的,无法说明在多租户环境中执行查询的任何给定用户的数据访问特性。 例如,针对具有大量数据的对象(表)的给定查询对具有高可见性的用户(可以看到所有对象实例的管理员)与具有低可见性的用户( 销售人员只能看到与自己相关的行)使用不同执行计划,这样会更加高效。

为了提供足够的统计信息来确定多租户平台中的最佳查询执行计划,Force.com为每个虚拟多租户对象维护一组完整的优化程序统计信息(租户,组和用户级别)。 统计信息反映了特定查询可能访问的行数,仔细考虑了整个租户特定的对象统计信息(整个租户拥有的总行数等)以及更细化的统计信息(行数 特定的特权组或最终用户可能访问等)。

Force.com还维护其他类型的统计信息,证明对特定查询有帮助。 例如,该平台维护所有自定义索引的统计信息,以显示相应字段中的非空值和唯一值的总数,以及显示每个列表值的基数的选项列表字段的直方图。

当现有的统计数据不存在或不被认为有帮助时,Force.com的优化器会使用一些不同的策略来帮助构建合理的最佳查询。 例如,当查询过滤对象的Name字段时,优化器可以使用FallbackIndex数据透视表高效地查找请求的对象实例。 在其他情况下,优化器将在运行时动态生成缺少的统计信息。

与优化器统计结合使用时,Force.com的优化器还依赖与内部安全相关的表(Groups,Members,GroupBlowout和CustomShare),这些表维护有关平台用户安全域的信息,包括给定用户的组成员身份和自定义访问权限对象。

p11.png

图11中的流程图说明了当Force.com拦截对诸如Data之类的大型堆表之一中的数据的请求时发生的情况。 请求可能来自任何数量的来源,例如来自应用程序框架应用程序的页面请求,Web服务API调用或Apex脚本。 首先,平台执行考虑多租户感知统计的“预查询”。 然后,考虑预查询返回的结果,平台在特定的设置中建立一个最佳的数据库查询执行。

如表1所示,Force.com可以通过四种不同的方式执行相同的查询,具体取决于提交查询的人员和查询过滤条件的选择性。

Force.com全文搜索引擎

基于Web的应用程序用户期望具有交互式搜索功能,可以扫描应用程序数据的整个或选定范围,返回最新的排名结果,并在亚秒级响应时间内完成所有这些工作。 为了为平台应用程序提供强大的功能,Force.com使用基于外部搜索引擎的架构,如图12所示。

当应用程序更新文本字段(CLOB,Name等)中的数据时,称为索引服务器的平台后台进程池负责异步更新搜索引擎在核心数据库之外维护的相应索引。 为了优化索引过程,Force.com将修改过的文本数据块同步复制到一个内部的“待索引”表中,从而提供一个相对较小的数据源,以最小化索引服务器必须读取的数据量磁盘。 搜索引擎为每个组织(租户)自动维护单独的索引。

根据当前的索引服务器的负载和利用率,文本索引更新可能明显落后于实际的事务。 为了避免源自陈旧索引的意外搜索结果,Force.com还维护最近更新对象的MRU缓存,平台的应用程序服务器在实现全文搜索结果时会考虑这些对象。 该平台在每个用户和每个组织的基础上维护MRU缓存,以有效地支持可能的搜索范围。

p12.png

Force.com使用几种不同的方法来优化搜索结果中记录的排名。 例如,系统考虑执行搜索的用户的安全域并且权衡当前用户有权访问的那些对象。 系统还可以考虑特定对象的修改历史记录,并在比较静态的对象之前排列最新更新的对象。 用户可以根据需要选择权重搜索结果,例如,更加强调最近修改的对象。

APEX

Apex是一种强类型,面向对象的过程式编程语言,开发人员可以用它来声明程序变量和常量,并执行传统的流程控制语句(if-else,loops等),数据操作操作(insert,update,upsert,delete )以及代表Force.com应用程序的事务控制操作(setSavepoint,回滚)。 Apex在很多方面与Java相似。 开发人员可以构建Apex例程,为大多数应用程序事件添加自定义业务逻辑,包括按钮点击,数据更新,Web服务请求,自定义批处理服务等。

开发人员可以以两种不同的形式构建Apex程序:作为匿名独立脚本,可以根据需要执行,也可以作为在发生特定数据库操作事件(插入,更新,删除或取消删除)之前或之后自动执行的触发器。 无论哪种形式,Force.com都会编译Apex代码并将其作为元数据存储在UDD中。 当组织中的某个人第一次调用Apex例程时,Force.com的运行时解释程序会将编译后的程序版本加载到该组织的MRU缓存中。 此后,当来自同一组织的任何用户需要使用相同的例程时,Force.com可以节省内存并避免重新编译程序的开销,这是通过共享已经在内存中的准备运行的程序来实现的。

Apex不仅仅是“另一种程序语言”.Apex是一个完整的Force.com组件,可帮助平台提供可靠的多租户应用程序。 例如,Force.com自动验证Apex类中的所有嵌入式Sforce对象查询语言(SOQL)和Sforce对象搜索语言(SOSL)语句,以防止在运行时失败的代码。 然后,平台为有效的Apex类维护相应的对象相关性信息,并使用这些信息来防止元数据的更改,否则这些元数据会破坏相关的应用程序。

许多Apex标准类和系统静态方法为底层平台特性提供了简单的接口。 例如,插入,更新和删除等系统静态DML方法有一个简单的布尔参数,开发人员可以使用它来指示所需的批量处理选项(全部或全部或部分保存); 这些方法还会返回调用例程可以读取的结果对象,以确定哪些记录未成功处理以及为什么。 Apex和Force.com平台功能之间的直接联系的其他示例包括内置的Apex电子邮件类,HTTP(RESTful)服务类和XmlStream类,仅举几例。

为了防止共享的多租户平台资源遭到恶意或无意的垄断,Force.com拥有一系列与Apex代码执行相关的管理员和资源限制。例如,Force.com密切监视Apex脚本的执行情况,并限制它可以使用多少CPU时间,可以使用多少内存,可以执行多少个查询和DML语句,可以执行多少个数学计算,以及如何执行很多出站的Web服务调用,以及更多。平台优化器认为执行代价过高的个别查询会向调用方抛出运行时异常。虽然这样的限制听起来可能有些限制,但它们对于保护所有相关应用程序的共享平台的整体可扩展性和性能是必要的。从长远来看,这些措施有助于推动平台开发人员更好的编码技术,为每个人创造更好的体验。例如,最初试图编写循环的开发人员会因为资源限制而无效地一次更新一千行,将会收到运行时异常,然后开始使用Force.com的高效批量处理API调用。

为了进一步避免由编写不佳的应用程序引起的潜在平台问题,部署新的生产应用程序是一个严格管理的过程。 在组织可以将新的自定义应用程序从开发转换到生产状态之前,salesforce.com需要单元测试来验证应用程序的Apex例程的功能。 提交的单元测试必须覆盖不少于应用程序源代码的75%。 Salesforce.com会在Force.com沙箱环境中执行提交的单元测试,以确定应用程序是否会对整个多租户人群的性能和可伸缩性产生不利影响。 单个单元测试的结果表示基本信息,例如执行的总行数以及有关代码的特定信息,这些信息并不是由测试执行来获取的。

一旦应用程序通过salesforce.com进行生产认证,应用程序的部署过程由一个事务组成,该事务将所有应用程序的元数据复制到生产Force.com实例中,并重新执行相应的单元测试。 如果进程的任何部分失败,Force.com只是回滚事务并返回异常来帮助解决问题。

注意:Salesforce.com为每个应用程序的每个开发版本重新开始了单元测试,以主动了解新的平台功能和增强功能是否会打破现有的应用程序。

p13.png

历史统计

多年的经验已经将Force.com转变成一个极其快速,可扩展且可靠的多租户互联网应用平台。 作为说明Force.com支持Internet规模应用程序的成熟能力,请考虑图13.请注意,随着时间的推移,平均页面响应时间减少或保持稳定(性能的一种衡量),同时平均事务量同时增加 (可扩展性的一种衡量)。

对于更多的平台数据,如计划维护,交易量和速度的历史信息等,请访问信任。 salesforce.com是Force.com社区的实时系统性能和安全信息的家园。

总结

平台即服务(PaaS)和软件即服务(SaaS)是当代软件应用程序开发和交付模式,越来越多的组织正在使用这些模型来缩短上市时间,降低资本支出并提高全球竞争力 经济。 基于互联网的共享计算平台是有吸引力的,因为它们让企业能够根据需要快速访问托管的软件资产,并且完全避免了购买,安装,配置和持续维护本地数据中心相关的成本和复杂性, 以及硬件,软件和随行的管理人员。

在这些模式转变的最前沿,最成功的按需SaaS / PaaS公司是salesforce.com,它最近获得了成为标准普尔500指数中第一个按需软件供应商的地位。从极其成功的salesforce.com CRM SaaS应用程序中脱颖而出,Force.com是一个通用的互联网应用程序开发和交付平台,企业和服务提供商已经构建了所有类型的定制业务应用程序,包括供应链管理,计费,会计,合规跟踪,人力资源管理和理赔处理应用程序。该平台的元引擎架构使任何人都能够高效地构建和交付复杂的,可定制的任务关键的Internet规模多租户应用程序。使用基于标准的Web服务API和本地平台开发工具,Force.com开发人员可以轻松构建基于Web的应用程序的所有组件,包括应用程序的数据模型(表,关系等),用户界面(数据输入表单,报告等),业务逻辑(工作流,验证等),与其他应用程序的集成等等。

在过去的十年中,salesforce.com的工程师已经对Force.com平台的所有层进行了多租户优化,使平台能够提供前所未有的互联网可扩展性,达到每日1.7亿次交易的高峰。 诸如批量数据处理API,Apex编程语言,外部全文本搜索引擎以及其独特的查询优化器等平台功能有助于使多租户平台应用程序高效且可扩展,开发人员很少或根本没有在意。

Salesforce.com用于部署生产应用程序的托管方法确保了所有相关应用程序的一流性能,可扩展性和可靠性。 此外,salesforce.com持续监控并收集来自Force.com应用程序的操作信息,以帮助推动渐进式改进和新的平台功能,立即使现有和新应用程序受益。

  • Dec 04 / 2017
  • 0
Data, Tech

锐眼洞察 | 云端的数据科学-也就是所说的模型即服务(翻译)

作者:Vamsi Chemitiganti

原文:Data Science in the Cloud A.k.a. Models as a Service (MaaS)

译者:TalkingData研发副总裁 阎志涛

本译文禁止商用,转载请注明作者与来源!

译者点评: 数据从核心上来讲是要流动才能产生价值,但是数据又不能被交易,那如何让数据产生价值呢?这里就引出了一个新的模式Maas,也就是模型即服务。简单来讲,数据是各种实体以及其行为的数字化记录,利用这些数据,可以进行分析和预测,而分析和预测的过程,就是模型在起作用。做个类比,我们的人脑中实际上就是存在各种的模型,而我们的感官就是数据收集的部分,大脑中的模型通过对收集的数据进行处理,就指导了我们每天的各种决策。数据作为进行决策的原始材料,基本上很难通过交易来进行价值的变现,那如何变现数据的价值呢,答案就是——模型。我们不可能将大脑里存储的数据出售给别人,但是我们每个人售卖的都是我们大脑通过模型处理后产生的结果,而其价值则来自于我们大脑中模型的能力,而类似于爱因斯坦的牛人,他的大脑中的模型也超级牛,就能够改变人类对世界的认识。而我们芸芸众生,大脑中都是一些相对普通的模型,价值自然也就普通。对于大数据,模型即服务的模式无疑是让数据产生价值的一个可行路径。碰巧看到了这篇文章 http://www.vamsitalkstech.com/?p=5321 ,作者对模型即服务做了介绍,同时介绍了他对模型即服务的认识。这里翻译给大家,希望大家一起讨论。  

硬件即服务,软件即服务,数据库即服务,基础设施即服务,平台即服务,网络即服务,后端即服务,存储即服务。随着每个IT交付的模式向云端转移,难道数据科学会落后于这个趋势吗? 在这个云化的环境中,什么能够帮助数据科学家实现他们的模型能够持续利用高质量和大量的生产级别的数据进行持续的训练?答案是模型即服务。

预测分析工作流程

预测分析的工作流程总是从头脑中的一个业务问题开始的。例如:”一个营销项目去检测基于客户历史上和实时的对产品的使用模式,预测哪些客户更有可能在接下来的六个月购买新的产品或者服务”。

ence_Process.png

面向这一类用例,数据科学过程的目标是能够通过分区和过滤将客户放置到不同的分类中,从而方便排序。在完成这些后,企业可以设置简单直接的可视化来展示效果。很多时候,企业集团通常很难解释他们到底想要看到什么,无论是输入数据还是输出格式。在这种情况下,一个原型可以使得需求的收集变得更加容易。当问题被定义后,数据科学家/建模的人就会去识别与业务挑战相关联的原始的数据源(包含了内部数据源和外部数据源)。他们花费大量的时间在数据收集的过程当中(从类似于Oracle/SQL Server、DB2、主机系统、Greenplum、Excel、外部数据集等等不同的来源)。清洗过程包含了处理缺失值、处理残缺的数据单元、格式化字段使得格式一致等等。 数据清洗阶段包括利用代码将不同的数据元素关联在一起,从而使得从不同的原始的数据源来的数据可以以正确的颗粒度构成一个完备的数据集放置到数据湖当中。如果在开发过程进行中获取了新的数据,数据科学团队不得不回头重复这个过程从而能够利用新的数据。建模过程是复杂的算法开始起作用的过程,特征工程是接收业务概念和原始数据特征并从它们当中产生预测特征的过程。数据科学家得到原始的或者特征工程化之后的特征,使用不同的算法并且测试从而找到最好的算法来创建模型。当模型被完善,并且经过精度以及性能测试之后,理想情况下是被部署为一个服务。

现存方式的挑战

业务扩展性:前面提到的预测性分析通常来自于一个业务线或者创新。如果你不让多个应用和业务创新去访问构建的模型,带来的收益将会大大的降低。

缺乏数据丰富性:一个团队创建的模型并不能够总是被跨组织的来自于不同业务应用的持续产生的数据所增强。除此之外,绝大多数行业应用程序并没有在业务应用中利用所有的可能的非结构化数据以及第三方数据。使模型曝露在一系列的数据中(无论内部还是外部)只能丰富产生的洞察。

跨应用的适用性:这个挑战涉及如何从不同的应用程序(利用不同的模型)中得到业务智能洞察,去增强那些并不是创造那些模型的业务领域。这可以实现实时的以客户为中心的洞察。例如,考虑一个客户销售应用和一个呼叫中心应用,跨应用的洞察可以用来理解客户打电话到呼叫中心是因为利用网站下产品的订单非常困难吗?

数据变现:创建新的商业业务模型的一个至关重要的能力,是围绕现存的以及新的数据源进行敏捷分析的能力。如果随之而来的是企业越来越多的业务数据资产建立,那么自然而然的数据会当作商品可以进行交易,创造收入。例如,领先的支付服务商现在向零售商提供分析服务以帮助他们理解哪些产品业绩更好以及如何改善客户的微观目标。因此数据是任何数字驱动的措施的关键一环,这导致了通过创建支持生态能力的平台来进行数据变现的一些努力。我们将这个讨论简化一下,数据变现的能力需要两个方面——首先将其集中,然后进行大规模的预测建模,这要求系统需要持续的学习并且优化他们的交互、以及优化按照客户的需求和选择的响应和服务。因此模型集中化将带来传统企业想象不到的巨大收益。

MaaS 模型即服务

模型即服务接受业务变量(通常是几百个或者几千个输入)并且提供将可以预测的业务决策作为模型输出。还有可视化的用于增强和支持业务决策的支撑系统。如图所示,一旦建立、测试和验证了不同的预测模型,它们就可以在现实世界被生产部署。MaaS本质上是一种部署这些高级模型的方式,作为软件应用的一部分,他们可以被作为软件服务来订阅。

aS_Lifecycle.png

MaaS方式带来的业务价值

a. 将模型开放给不同的业务线可以提高它们的实用性,并且通过接收反馈来提高它们的准确度。

b. MaaS将模型开放给任何希望从它们当中获益的应用,这迫使数据科学家与比通常更广泛的业务团队进行合作。

c. 在整个组织中提供仪表盘和商业智能比采用孤立的方法要简单的多。

d. MaaS作为一种方法从根本上鼓励敏捷的方法来管理数据资产,并使其合理化。 对于任何MaaS的成功,都需要能及时访问组织中潜在的数百个数据源。 MaaS鼓励将数据视为整个组织的可重用资产。

MaaS方式的技术优势

页面:123456789...20
随时欢迎您 联系我们