关于数据处理:获奖案例巡展信创先锋之星甘肃省住房和城乡建设厅住建数据大脑

为表彰应用大数据、人工智能等根底软件为企业、行业或世界做出杰出贡献和微小翻新的标杆我的项目,星环科技自2021年推出了“新科技 星力量” 星环科技科技实际案例评选活动,旨在为各行业提供更多的优良产品案例,彰显技术扭转世界的力量,目前已胜利举办两届,收到了来自各界的积极参与。 第二届星环科技科技实际案例评选活动新增了“年度信创先锋之星”,通过产业界、学术界专家联结评审,最终评比出了“年度信创先锋之星”、“年度科技向善之星”、年度价值奉献之星”、“年度科技前沿之星”、“年度技术革新之星”五大奖项,并特此进行案例巡展。 本期巡展案例为取得第二届“新科技 星力量” 星环科技科技实际案例评选活动“年度信创先锋之星”的甘肃省住房和城乡建设厅互联网+政务服务和监管零碎-甘肃省住建数据大脑。 案例背景 甘肃省住房和城乡建设厅在推动新型“智慧城市”建设,通过“智慧城市”及其相干畛域的信息化建设,实现城市规划、建设、治理、服务能力晋升,放慢推动中央和部门“互联网+监管”零碎建设并与国家“互联网+监管”零碎对接联通,推动造成对立标准、信息共享、协同联动的全国“互联网+监管” 体系方面,面临以下问题:一是利用零碎建设扩散,不足整合,孤岛分布、烟囱林立;二是数据资源整合、共享水平不高。 甘肃省住建数据大脑,用于帮忙“甘肃省住房和城乡建设厅”实现对政务数据采集、加工、存储、计算、剖析、数据治理等数据全生命周期服务。建设“一源、一数、一脑、一智、一屏”的智慧住建“数据大脑”撑持平台。实现省、市、县三级住建主管部门业务零碎互联互通和信息跨部门、跨层级共享共用的指标,成为智慧住建数据大脑 + 智慧业务撑持 + 智慧利用的整体框架的重要反对局部,继续推动既有平台迭代更新与互联互通,实现全省住房城乡建设行业信息全笼罩,无效晋升住房城乡建设畛域社会治理能力。 解决方案 该我的项目基于星环科技大数据根底平台TDH、分布式交易型数据库KunDB、大数据开发工具TDS产品,以及数据湖、数据仓库、数据中台、湖仓一体解决方案,构建甘肃省住建数据大脑: 大数据汇聚与根底撑持平台提供对数据的剖析计算、存储加工能力,是整个住建厅数据大脑技术底座; 数据共享替换平台是“以共享为根底、以需要为导向、以利用为抓手、以平安为撑持、以制度为保障”的根本准则,依照“内外联动、点面结合、高低协同”的工作思路,搭建目录编制、多源数据接入、资源公布、批量和实时共享服务为一体的对立的政务数据共享替换平台; 数据资源核心平台是数据接入、数据归集和数据治理造成的后果,包含数据湖和主题库、专题库三局部; 数据治理平台是进行数据治理和数据管理的重要根底撑持,采纳数据规范与数据治理管控工具,交融数据治理征询方法论,通过数据规范、数据品质、数据保护等多维度能力反对数据治理专题工作,晋升数据管理程度; 数据分析平台是面向部门级提供自助式剖析利用,买通数据分析利用的全场景需要,提供报表剖析、大屏可视化、自助式剖析、报告利用、预测与开掘等多元化分析方法,全方位晋升数据分析能力,精准撑持领导决策; 服务共享平台是依照国家《政务信息资源目录体系》及国标要求,以元数据为根底,交融全文检索和标签零碎能力,提供动静更新、多维度、分级管理的服务共享平台管理系统。 案例施行功效 进步公共服务程度,构建服务型政府 通过智慧住建大脑获取住建行业信息及其他部门的共享信息,翻新住建智慧化利用,能够发展被动服务,为公众提供自助服务,以智慧化服务伎俩满足公众日益增长的服务需要,进一步不便居民和企业办事,促成服务型政府构建。 进步住建厅的信息化和管理水平,通过整合的数据分析为领导者决策提供撑持 通过智慧住建大脑盘活数据资产,为各级住建部门提供数据汇聚、数据共享替换、数据治理等数据全生命周期服务,对立解决以后建设中存在的扩散、孤立状态,突破信息“孤岛”,实现和提供跨地区、跨机构、跨业务畛域的数据交换和资源共享服务。同时使用关联剖析、比照剖析等技术手段,对海量大数据进行多维的深度剖析;深入数据分析后果利用,服务住建部门决策、日常治理,充沛开释效力。 满足政务服务业务办理需要,缩小企业及办事人少填写,少上传通过一直夯实数据根底,实现为企业和大众提供住房公积金查问、企业资质查问、人员注册信息查问、外省进甘企业信息查问、建设工程项目查问等多方面查问服务。 案例翻新点 1.增强数据整合共享,让利用更加智慧。智慧住建数据大脑作为外围利用数据底座撑持,实现让数据多跑路,让大众少跑路。 2.升高数据建设老本,进步政务办理效率。作为住建厅与住建部、各委办厅局、上级各住建局之间的数据信息“桥梁”,实现对立入口、对立进口、集中管理、高效服务指标,升高数据建设老本,进步政务办理效率,晋升 “放管服”能力。 3.实现数据的“资产化”,实现从查问、统计等“浅层”利用形式到推演、预测等“大数据”剖析形式的转变,实现布局数据的迷信辅助决策,数据的“资产化”,施展数据资源重要价值。

April 19, 2023 · 1 min · jiezi

关于数据处理:从实测出发掌握-NebulaGraph-Exchange-性能最大化的秘密

自从开发完 NebulaGraph Exchange,混迹在各个 NebulaGraph 微信群的我常常会看到一类发问是:NebulaGraph Exchange 的性能如何?哪些参数调整下能够有更好的性能?…索性来一篇文章从实测登程,和大家讲讲如何用好这个数据工具。在本文你将取得 NebulaGraph Exchange 的最佳应用姿态。 01. 环境筹备硬件: Spark 集群:三台机器,每台 96 core,256 G 内存NebulaGraph 集群:三台机器,每台 128 core,252 G 内存,SSD,双万兆网卡数据:LDBC sf100 数据软件: Spark 版本:2.4.4NebulaGraph 版本:3.3.002. NebulaGraph 优化配置在进行大批量数据导入时,能够调整 NebulaGraph Storage 服务和 Graph 服务的配置,以达到最大导入性能。请依据 NebulaGraph 的配置形容和你的理论环境资源进行参数调整。 在本次实际中,NebulaGraph 的集群配置针对以下几个配置项进行了批改,其余均采纳默认配置: "storaged": --rocksdb_block_cache=81920, --heartbeat_interval_secs=10, --reader_handlers=64, --num_worker_threads=64, --rocksdb_db_options={"max_subcompactions":"64","max_background_jobs":"64"} "graphd": --storage_client_timeout_ms=360000, --session_idle_timeout_secs=2880, --max_sessions_per_ip_per_user=500000, --num_worker_threads=64NebulaGraph Storage 服务优化在这里简略讲一下几个 Storage 服务优化配置项: --rocksdb_block_cache 数据在内存缓存大小,默认是 4 MB,大批量数据导入时能够设置到以后内存的 1/3;--num_worker_threads storaged 的 RPC 服务的工作线程数量,默认 32;--query_concurrently 为 true 示意 storaged 会并发地读取数据,false 示意 storaged 是单线程取数;--rocksdb_db_options={"max_subcompactions":"48","max_background_jobs":"48"}:可用来减速主动 Compaction 过程;--rocksdb_column_family_options={"write_buffer_size":"67108864","max_write_buffer_number":"5"},在刚开始导入大量数据时能够将 disable_auto_compaction 选项设置为 true,晋升写入的性能;--wal_ttl=600 在大量数据导入时,若磁盘不富余,那么该参数需调小,不然可能会因为产生大量的 wal 导致磁盘空间被撑满。NebulaGraph Graph 服务优化再简略地列举下 Graph 服务相干的一些优化配置项: ...

February 1, 2023 · 9 min · jiezi

关于数据处理:高效实践|频繁项集挖掘算法在告警关联中的应用

本篇咱们将次要围绕频繁项集开掘算法的理论利用,即当该算法利用到告警关联场景中时,咱们遇到了哪些问题,如何解决这些问题,以及咱们如何在原始 FP-Growth 算法的根底上进行改良,从而研发了专用于告警关联场景下的 CW-FP-Growth 算法。为了展现该算法的实际效果,咱们在文末给出了这一算法在脱敏数据中的案例。 一、频繁项集开掘与告警关联如何联合?在前文中,咱们介绍了频繁项集开掘问题以及两种典型的算法,然而如何将频繁项集开掘算法利用到告警关联及降噪中?为了答复这一问题,咱们能够先简要剖析一些运维的典型场景。在理论运维过程中常常会呈现如下状况,零碎短时间内产生了大量的告警,其中局部告警的内容具备较高的重复性,或这些告警之间彼此存在肯定的关联关系,如果每条告警都告诉,那么用户可能会收到大量的信息,然而并非每一条信息都具备很高的剖析价值,这些反复或无意义的告诉并不能帮忙运维人员减速定位故障,反而很大水平上消耗了他们的精力,令他们不能专一于那些真正须要解决的故障。那么如何解决这一问题? 产生这一问题的次要起因在于告警之间不足剖析,如果可能在告诉运维人员之前,对告警进行一些初步的关联剖析与降噪,则能给缩小运维人员承受到的反复告诉,因而咱们尝试了从工夫相关性的角度找出须要剖析的指标告警的相干告警,这些相干告警与指标告警可能属于同一根因,或可能为查找指标告警的根因提供更多的信息,从而帮忙运维人员剖析故障之间的关联关系,使运维人员可能减速根因定位的过程。基于这一指标,咱们采纳频繁项集开掘算法从故障的产生工夫动手,开掘故障之间的关联规定,从而将这些关联规定中可信水平比拟高的局部用于告警降噪中。而在利用这一算法的过程中,咱们也常常被问到一些算法逻辑的相干问题,在这里咱们将简略的介绍这些问题的解决办法。 问题一:如何在数据中开掘尽可能多的关联规定?在商品举荐的场景中,原始的数据库由多个项集组成,每个项集是消费者购买商品的记录,也就是说这些记录彼此之间的界线十分明确,而在告警关联的场景中,告警是连续不断生成的,因而如何将这些告警宰割为项集成为了咱们在开掘关联规定中面临的第一个问题。 咱们试验的第一种办法是采纳滑动的工夫窗口解决这一问题,将固定工夫的窗口依照 1 分钟的步长进行滑动,则上午 10:00-10:05 内的告警被划分为第一个汇合,10:01-10:06 内的告警被划分为第二个汇合,以此类推。这尽管实现了跨窗口开掘规定,但这一构想引发了新的问题,假如存在规定呈现在 10:04-10:05 这段时间内,那么即便这一规定只呈现了一次,但却呈现在了 4 个不同的告警项集中,这将使得频繁项集算法开掘算法产生大量的错误判断。 为了防止这种数据反复呈现带来的影响,咱们决定采纳一种变通的办法,即采纳了多个固定窗口组合的形式解决这种问题,通过将多个不同起始工夫和切分工夫的窗口的后果加以组合,以挖掘出同一份数据所有可能的关联规定,接着采纳邻接矩阵记录多个项之间的关联度用于筛选并合并屡次开掘产生的反复或抵触的规定。 问题二:如何设计能力更不便用户了解并调整算法的相干参数?在对频繁项集开掘这一问题的介绍中,咱们引出了反对度这一概念,然而传统的反对度计算方法并不适用于告警关联场景中,或者说不合乎用户的调参直觉。同样一批数据在不同的工夫窗口下产生的告警项集个数并不相同,这导致用户很难依据心田的冀望精确的评估反对度阈值的大小,导致体验变差。 针对这一问题,咱们采纳了告警呈现在几个项集中作为以后项的反对度,比方对于项集[A, B, C],[B, C, D],[D, F, A],因为告警类别 B 呈现在了项集[A, B, C]和[B, C, D]中,因而反对度为 2。这近似于将某类告警中的告警个数作为此类告警的反对度,这种形式相比于传统的计算反对度的办法更加合乎用户的主观感知,便于用户依照本人的冀望应用算法。 问题三:如何解决项集中的反复项,解决办法是否正当?在多个不同的用户场景中,咱们常常被问到这个问题,为解决反复项的问题,咱们最终抉择了保留其中之一的形式。因为项集[A,B,C]和项集[A,A,B,C]在计算项 A 的反对度时的贡献度是统一的,都会使项 A 的反对度加 1。而如果不去重,则反复项将会烦扰 FP 树的构建过程,比方对于项集[A, B, C]和项集[A, A, B, C],这两个不同的项集将构建出一个长度为 3 的分支和一个长度为 4 的分支,但他们仅具备一个公共节点 A,图示如下,这导致 FP 树产生了不必要的分支,并可能会挖掘出相似于[A,A]这种无用的关联规定。而保留其中之一的办法可能在不影响后果的前提下解决这一问题,尽管简略然而具备合理性。 问题四:如何抉择聚类维度?在实现数据的预处理后,咱们依然面临一个重要问题,即该以什么维度聚合告警?在介绍频繁项集开掘的基本概念时,咱们能够发现啤酒不论是哪种牌子,什么规格,他们都属于啤酒,不可能呈现一瓶啤酒被误认为是鸡蛋的状况,也就是说,商品自身具备类别属性,而在告警关联场景中,告警又该如何被划分类别呢? 一种常见的办法是采纳 IP 进行划分,将告警依照 IP 聚类后,采纳该算法的确能够找出零碎中常常同时呈现故障的 IP。但这一办法也存在两个问题,首先不是所有告警都具备 IP 信息,这使得此类办法的应用存在肯定的限度条件,其次这些主机并不一定每次都呈现同样的故障,这使得该办法失去的关联规定并不精确。以上的两个问题使得采纳 IP 作为聚类维度尽管可行但并不总能失去好的后果,是否存在更适宜的维度呢? 通过试验验证,咱们更心愿从故障的维度聚类告警,行将形容同一故障的告警聚合为一类,并通过频繁项集开掘类算法找出哪些常常一起呈现的故障。依据咱们的定义,警报与故障该当具备一一对应关系,因而理论应用过程中,咱们更加举荐用户抉择警报 ID 作为告警聚合的维度。 ...

June 17, 2022 · 1 min · jiezi

关于数据处理:记录一次线上数据图源本地化操作的过程

最近学了一个比拟赞的电商我的项目,我的项目作者提供了残缺的示例数据,包含商品信息及配图,然而这些配图是固定的URL,商品详情为html,html中有img标签,img标签中也有url。依据过往教训这种在线CDN很容易挂掉,因而产生了把商品数据中的商品图片提取进去,放在本人的腾讯云服务器中的想法,保障可拜访性。演示数据[{ "ID": "b93e59e214fc4478ac72652a2c87fe54", "GOODS_SERIAL_NUMBER": "2300000059885", "SHOP_ID": "402880e860166f3c0160167897d60002", "SUB_ID": "402880e86016d1b5016016dcd7c50004", "GOOD_TYPE": 1, "STATE": 0, "IS_DELETE": 1, "NAME": "云南红提800g/盒", "ORI_PRICE": 18, "PRESENT_PRICE": 15, "AMOUNT": 10000, "DETAIL": "<img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112029_9395.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112029_3391.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112029_7603.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112029_4718.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112030_778.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112030_2602.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112030_7913.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112030_202.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112030_4296.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112030_6956.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112030_8200.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112031_3967.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20171225/20171225112031_5114.jpg\" width=\"100%\" height=\"auto\" alt=\"\" />", "BRIEF": null, "SALES_COUNT": 0, "IMAGE1": "http://images.koow.cc/shopGoodsImg/20171225/20171225112020_561.jpg", "IMAGE2": null, "IMAGE3": null, "IMAGE4": null, "IMAGE5": null, "ORIGIN_PLACE": null, "GOOD_SCENT": null, "CREATE_TIME": 1514172047397, "UPDATE_TIME": 1522037064430, "IS_RECOMMEND": 0, "PICTURE_COMPERSS_PATH": "http://images.koow.cc/compressedPic/20171225112020_561.jpg" }, { "ID": "e0ab2f6e2802443ba117b1146cf85fee", "GOODS_SERIAL_NUMBER": "4894375014863", "SHOP_ID": "402880e860166f3c0160167897d60002", "SUB_ID": "2c9f6c94609a62be0160a02d1dc20021", "GOOD_TYPE": 1, "STATE": 0, "IS_DELETE": 1, "NAME": "菓子町园道乳酸菌味夹心饼干(抹茶味)540/罐", "ORI_PRICE": 29.8, "PRESENT_PRICE": 29.8, "AMOUNT": 10000, "DETAIL": "<img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110655_230.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110656_329.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110656_2659.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110656_9521.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110656_8611.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110656_1390.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110656_7291.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110657_3919.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110657_2170.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110657_4402.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110657_1926.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110657_9438.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110657_4361.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110657_2730.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110658_314.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110658_8779.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110658_9878.jpg\" width=\"100%\" height=\"auto\" alt=\"\" /><img src=\"http://images.koow.cc/shopGoodsDetailImg/20180213/20180213110658_3471.jpg\" width=\"100%\" height=\"auto\" alt=\"\" />", "BRIEF": null, "SALES_COUNT": 0, "IMAGE1": "http://images.koow.cc/shopGoodsImg/20180213/20180213110648_2744.jpg", "IMAGE2": null, "IMAGE3": null, "IMAGE4": null, "IMAGE5": null, "ORIGIN_PLACE": null, "GOOD_SCENT": null, "CREATE_TIME": 1518491222336, "UPDATE_TIME": 1523174099461, "IS_RECOMMEND": 0, "PICTURE_COMPERSS_PATH": "http://images.koow.cc/compressedPic/20180213110648_2744.jpg" }]能够看到,数据比拟残缺,包含ID、编号、名称、价格、介绍等信息。如果想要提取JSON对象中的图片URL,对于其中的images1-images5对象比拟好解决,只须要遍历即可。对于DETAIL中的图片URL,因为URL混在html中,没有方法间接拿到,可通过正则匹配的模式获取。上面分步骤操作: ...

May 15, 2022 · 2 min · jiezi

关于数据处理:改变人类使用数据的习惯五岁的-Kyligence-许下新愿望

扭转从来不是简略的事件,但 Kyligence 决定试一试。 在 7 月 30 日举办的 Data & Cloud Summit 2021 行业峰会上,Kyligence 联结创始人兼 CEO 韩卿发表了 Kyligence 的全新愿景——“扭转人类应用数据的习惯”。他示意,面向未来的企业级数据服务与治理平台要让数据找到须要的人,而不再是人去找数据,通过人工智能、语音交互、智能举荐、常识图谱等各种新技术和新架构,进一步让数据为人服务。 此外,Kyligence 发表了全新的 “智能数据云" 策略,将基于人工智能、云原生等技术构建下一代 AI 加强的数据服务与治理产品;并公布了最新产品 Kyligence v4.5,旨在通过更弱小、更高效、更便捷的数据智能平台,赋能企业数字化转型。 智能 + 数据 + 云,Kyligence 策略全面降级数据仓库技术诞生数十年。但在云时代下,相干的行业假如曾经扭转。Kyligence 联结创始人兼 CEO 韩卿从以下几点进行了具体论述: 1. 数据的管理模式从集中式到分布式的扭转;2. 数据的应用对象从多数的决策者和专家,到一线业务人员和一般工作者的转变;3. 数据的生产形式从已知问题找答案,到通过智能举荐等性能来提供对未知问题的事后洞察。 适应变动能力驾驭变动。 面对海量数据、多个云平台、繁冗的数据源、技术间的整合和平台间的集成带来的难度,企业应如何做好数据管理和剖析?如何寻找有价值的数据? Kyligence 正式发表策略全面降级 —— 致力于为企业客户打造 “智能数据云” (Intelligent Data Cloud) 平台:在做强剖析能力的根底上加强数据管理能力,以人工智能进一步代替人工工作,以云原生进一步代替基于 Hadoop 的基础架构,让数据服务与治理施展核心作用,帮忙企业智能治理最有价值数据,反对企业全面数字化转型。 “智能数据云,不仅是 Kyligence 近些年在寰球市场的业务实际,同时也是对云原生时代下技术发展趋势的思考和总结”,韩卿介绍道,“数据仓库在云时代的改革才刚刚开始,新的技术架构、新的应用形式、新的老本构造都将粗浅扭转这个行业。将来人类应用数据,该当和明天应用云计算一样简略、不便,只需关注数据自身,而无需关注到底在哪个平台上,真正实现数据的随取随用。” 目前 Kyligence 曾经反对微软 Azure,亚马逊 AWS 及华为云平台,并在踊跃布局其余私有云平台。此外,随着企业对公有云架构的需要低落,Kyligence 正式推出玄武打算,减速下一代基于 Kubernetes 及分布式对象存储等架构的公有云产品落地的过程,Kyligence 将为大型企业级客户提供公有云环境运行 AI 加强数据服务与治理的能力, 并心愿更多的合作伙伴退出,联结共建。 此外,Kyligence 还发表了 Kyligence Partner Network 合作伙伴打算,该打算将从培训认证、资源反对、推广单干等方面赋能合作伙伴,独特携手为寰球客户带来更优质的服务。 ...

August 2, 2021 · 2 min · jiezi

关于数据处理:云原生时代企业多活容灾体系构建思路与最佳实践

简介:对于云原生的概念解读,大家常常会听到微服务、容器这些,那么这些技术跟企业容灾到底有什么样的关系?其实容灾的需要各行各业都有,比方金融行业对于容灾也有强烈的需要。然而怎么把容灾和多活能力构建起来,其实是每家企业都须要好好思考的。这篇分享心愿能给大家提供一些相干思路。 对于云原生的概念解读,大家常常会听到微服务、容器这些,那么这些技术跟企业容灾到底有什么样的关系?其实容灾的需要各行各业都有,比方金融行业对于容灾也有强烈的需要。然而怎么把容灾和多活能力构建起来,其实是每家企业都须要好好思考的。这篇分享心愿能给大家提供一些相干思路。 容灾零碎职能演进 明天讲的多活,其实是容灾体系外面的一块,大家能够看一下整个容灾体系架构的演进: 容灾 1.0:在原有利用零碎的构建过程中,业务零碎是基于传统架构部署在机房外面,那么相干的应急措施或者故障解决的方法呢?这个期间只思考到了数据备份,次要以冷备的形式。除了提供业务的机房,另外可能会思考到劫难场景做额定的机房。从零碎建设的角度,可能会抉择用独自的机房把数据同步到另外的机房做冷备,在呈现问题的时候切换。但在理论状况中,平时个别不会抉择切换机房,哪怕是每年做灾备零碎例行演练的金融行业,在生产过程中遇到零碎出了问题的时候都不太敢切换。 容灾 2.0:更多地思考到了利用。比方云原生,或者再往下层利用在传统的 IOE 体系中,切换不仅仅是简略地切过去,把原来冷备的数据加载进去,而是心愿切过去的时候能够很疾速地把利用在另外的机房拉起来。为了实现数据层上的复制不会有太大延时,咱们通常会有双活的要求。然而个别做双活会有一些要求,比方间隔要求肯定范畴以内才能够做同城双活。双活更多会利用在 AQ 模式,即在生产这边做全业务,在另外机房做别的业务。 容灾 3.0:心愿做成异地多活。多是什么?意思是不再局限两个机房,更心愿是三个或者更多的机房。比方阿里的业务散布在多个机房,怎么同时对外提供业务的撑持,这是须要对应技术支持的。而异地多活的意思就是不局限于间隔,比方 200 公里或者同城,因为现在的机房部署在全国各地。 业务连续性以及容灾概述 对于业务连续性来说其实有体系化的办法,指在容灾零碎建设上多年积攒下来的标准和领导,这其中有几个维度: 1、多活业务并不是跟原来的容灾一样,把对等在另外一个机房一样的业务间接拉过来,而是抉择有价值的业务。因为在容灾零碎建设中,要把所有的业务实现多活,在老本和技术实现上是十分艰难的。 2、实时性运行的保障,须要保障外围业务不会因为机房断电等各种起因进行服务。 3、M 代表保障体系。现在各行各业,可能都有本人不同的伎俩和治理的形式,而阿里提供的是将这一部分的货色转变为技术、工具和产品,让大家将来在构建多活能力的时候,能够很疾速地基于这套办法和产品构建业务的多活。 BCM 体系和 IT 容灾恢复能力是一个偏实际的指导性框架。从完整性来讲,顶部的业务连续性是指标,上面是各种实现形式。在底部能够看到例如 IT 打算,业务连续性呈现非凡问题解决故障的打算等,这些在原来做容灾的时候是会思考到的,而咱们是从多活的角度把这些货色思考在产品体系外面。 这里提到的几个容灾形式,其实是比拟常见的:从冷备到同城双活、同城双活加异地冷备(两地三核心),这些在业内相对来说都是比拟标准的形式。而异地多活就好比在两地三核心的三个机房外面同时提供多活的能力,在以前的根底上,又跟原来传统的容灾有一些区别。多活在建设老本上与传统也有区别,比方构建异地多活的能力,在建设老本上比传统(例如同城双活和两地三核心)会有更多的投入。 在构建多活能力的时候,其实也会思考到业务的理论状况。比方不同的行业,或者比方在多活方面只要求实现两边的读,那么不同状况下,建设老本以及对业务切换的工夫是有区别的。异地多活能力从横向时间轴来看的话能够做到分钟级切换,但如果基于冷备的话可能须要以天来切换。 阿里为什么做多活 在阿里的业务模式下,为什么要做多活的起因跟后面提到的相似。后面讲到的同城加冷备,如果不采纳多活就要建另外一个机房,老本十分高,因为那个机房只是用作平时的数据同步,并不处在运行状态,在这期间还须要不间断地更新生产零碎对应的版本和灾备零碎的版本。但理论状况下,原来的冷备或者两地三核心呈现故障的时候不敢去切换,因为很有可能切换后就无奈切回来。 而做多活次要有三个次要的诉求: 1、资源。随着明天业务高速倒退,单地资源容量受限。咱们晓得云原生、云计算提供高可用、容灾的能力,然而云计算部署在不同的机房外面,跨地区多活的能力自身须要底层的基础设施来反对,咱们心愿把业务扩大到不受限于物理机房的限度,还达到多个机房同时接业务; 2、业务有多元化的需要,须要就地或异地部署的要求; 3、针对容灾事件。比方光缆挖断,或者天气起因机房供电散热的问题,这些都会导致单机房的故障。现在的需要心愿不受限于某个机房,而是有多个机房部署在全国各地处于不同的状态,依据业务模式能够灵便调控。 因为这些诉求对多活的能力要求比拟迫切,所以阿里依据本人的业务需要和技术上的能力做了多活的计划和产品。 多活架构的拆解多活架构的拆解 1、异地互备:明天大家讲云原生有多好,云计算有多好,没有多活能力这些技术其实就是闲置的状态。冷备状态时不工作,而在什么状态下要切到冷备大多要靠人的决策。因为层层上报对业务影响比拟大,比拟成熟的客户会有一些预案,比方什么样的影响和故障须要做这种切换,但实际上基于冷备模式的话个别不敢去做切换。 2、同城双活:有肯定的间隔限度,常见的双活模式在下层利用这一层,比方像云原生的 PaaS 层两面机房都能够散发。在数据这一层因为是同城能够用贮备的形式,主机房呈现问题数据库方面切到备机房,然而这个益处是两边机房的机器、资源都属于流动的状态。另外,机房处于流动的状态就不必放心生产的版本跟备机房的版本有辨别,不会不敢切。 3、两地三核心:除了思考同城提供这个问题,对于故障应答能力会更强,在异地建一个冷备的机房,这个跟冷备第一个计划有相似,冷备的机房平时是不必的,可能会做一些其余的同步,只有在故障产生的时候做切换。 4、异地多活:有多个数据中心同时对外提供业务的能力。因为间隔的局限,在数据层面的复制可能会受限于网络,导致延时的问题是肯定会存在的。这其中有很多技术问题要解决,比方怎么做到能够很疾速从北京机房切换到上海,底层的数据受物理限度状况下没有齐全同步怎么去切。咱们操作模式不像原来容灾的形式切换,而是要做一堆筹备工作和后续数据的弥补流程。咱们将这套货色交融到产品体系中,物理极限没有方法冲破咱们就用架构的模式来优化。 递进式多活容灾架构 对于要害外围业务,其实在做多活零碎或者我的项目的时候,对业务会做一些梳理,明天讲的是单元化的梳理。 递进式多活容灾架构 双读、两地三核心,个别状况下两个机房最多一半一半去分,这是最简略的。依照这种模式能找出业务切分的规定,比方能够依照用户号码,就像银行可能依照卡号或者用户所属地分成一半一半的业务。而在多活外面咱们心愿能够灵便去配,比方机房的解决能力多大,碰到的故障是什么样子,流量能够调成 50%、60% 或者其余比例。在多个机房也一样,能够统一分配流量接入的状况。 ...

July 6, 2021 · 1 min · jiezi

关于数据处理:Tapdata-实时数据融合平台解决方案五落地

作者介绍:TJ,唐建法,Tapdata 钛铂数据 CTO,MongoDB中文社区主席,原MongoDB大中华区首席架构师,极客工夫MongoDB视频课程讲师。通过后面几篇文章,咱们从企业数据整合与分享的痛点,以及对数据中台的定义、技术需要以及技术产品的选项,都别离做了具体的论述。 有了这么多解决方案,咱们来看一下,如果是基于一个 MongoDB 的计划会是怎么样?咱们方才只是讲的数据平台在做一些抉择,然而做一个欠缺的数据中台的话还须要很多其余模块,所以这外面是用到了另一个产品,就是Tapdata DaaS。通过 MongoDB 和 Tapdata DaaS 这样一个组合,一起来做这个中台的解决方案。 这本章节里,咱们具体来介绍一下 tapdata DaaS 基于 MongoDB 的数据中台落地计划。 为什么抉择 MongoDB 作为中台架构的数据平台 咱们先来看MongoDB作为中台架构的平台劣势。 MongoDB 是一个多模数据库。所谓多模数据就是他一套零碎外面一套分布式集群,外面能够做很多的不同的事件,有的时候你能够把它作为一个内存数据库,能够把它作为一个目录数据库,也能够把它作为一个IOT的数据模型。就是说它的多模性个性是比拟有专长的,而且它的主动扩大能力也是非常适合这种中台的对立平台的需要。多模多态,对汇聚性也是十分重要,因为咱们须要撑持不同构造、半结构化、非结构化、甚至一些图片文件可能来做到这一些。 另外,就是MongoDB的API敌对能力,采纳 JSON 作为传输格局。咱们晓得当初都是微服务,都是通过Data API的形式交付数据中台的数据。后面业务中台往往都是用微服务,也是通过这种RESTful API,那MongoDB的这种JSON模型对新一代的这种架构式有得天独厚的劣势,你会发现你花很少的工夫就能够把这个API构建好。另外,MongoDB 也原生提供这种 Streaming API 帮忙来做一些流解决的事件。所以MongoDB 作为一个中台的对立平台数据库,其实是有十分得天独厚的条件。 当然,除了他的多表关联是可能是缺点。 MongoDB另外一个劣势就是它的对象模型。咱们的 JSON 模型就是十分靠近于咱们开发的对象,Json也好,或者是Java 里边的 Object,python 外面的 Dictionary。 一个传统的数仓,或者是当初的数据中台的数据对立平台,要做很多的数据治理。比方要做一系列的建模的工作有概念建模、逻辑建模、物理建模。而且物理建模就是咱们所谓的物理层,那就波及到关系模型。治理一个逻辑对象,怎么样转化成五张表,十张表,20张表听从第三方批示,这外面其实是很简单,也会很花工夫。你要设计一个很好的模型,怎么样来撑持将来的业务,这也是为什么传统数仓会花那么多的落地我的项目代价来做这个事件。 而MongoDB的解决方案能轻松地解决这方面的事件,这就是为什么 MongoDB 会受很多开发者的喜爱:MongoDB 在建模方面是一个十分独特的模式,它的模型是基于相似于这种逻辑模型的对象模型。你能够把它了解为差不多是一对一。业务人员个别都会明确这个概念,比方建模、逻辑建模,这些模型他们心里都无数。他们就是可能不懂那种种 DBA 说进去的的 Oracle 的这种建模形式,然而对于 MongoDB 来说,其实你只须要达到逻辑建模层的话,你就能够把这事件做了。而且这个模型建完了当前,间接能够用REST API的形式交付进来。从这一点上来说,它是有一个技术上是十分独到的一个先天性的劣势,尤其对咱们想做这种基于API的这种服务中台来说。 MongoDB 的读写拆散,HTAP反对全渠道业务需要。 有一些开发者会说是 HTAP (Hybrid Transaction and Analytical Process),就是说又能够做剖析业务,也能够做的交易型的业务。在MongoDB外面,咱们怎么样来做这种事件呢?比如说一个集群外面,一个cluster,一个复制集,咱们有五个节点,四个Secondary,一个primary。右边的primary节点能够用来间接。间接跟咱们的手机或者是网页端的利用进行交互收集,采集数据,用户数据。那MongDB主动同步把的数据从primary同步到secondary外面。 而后咱们还能够除去右边三个,作为失常的高可用集群来说,咱们还能够拿出两个节点专门用来做剖析,你看他这个use=analytics。就是一个标签,就比如说这两个节点是只是用来做于剖析型的,那这个时候咱们就能够用它来下面。加上咱们的BI connector,或者是间接用咱们的MongoDB charts和compass,间接能够对接MongoDB数据库做一些展现:kpi,dashboard等等。咱们也能够通过一些大数据接口,比如说spark connector 来做一些大型的machine learning或者是AI都是,有很多的这种利用场景,那这些都能够最实时的,在你最陈腐的数据上通过一个读写拆散的架构上来实现,你不须要再ETL。在MongoDB外面,这个ETL的需求量是十分非常少的,因为能够通过原生的这种同步来提供数据的汇聚,数据放到这个剖析集群外面。 ...

June 4, 2021 · 1 min · jiezi

如果你也想做实时数仓…

数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务,数据仓库的建设也是“数据智能”中必不可少的一环。本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容。 1.数据仓库简介数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策。 数据仓库是伴随着企业信息化发展起来的,在企业信息化的过程中,随着信息化工具的升级和新工具的应用,数据量变的越来越大,数据格式越来越多,决策要求越来越苛刻,数据仓库技术也在不停的发展。数据仓库的趋势: 实时数据仓库以满足实时化&自动化决策需求;大数据&数据湖以支持大量&复杂数据类型(文本、图像、视频、音频); 2.数据仓库的发展数据仓库有两个环节:数据仓库的构建与数据仓库的应用。 早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中,其应用以报表为主,目的是支持管理层和业务人员决策(中长期策略型决策)。 随着业务和环境的发展,这两方面都在发生着剧烈变化。 随着IT技术走向互联网、移动化,数据源变得越来越丰富,在原来业务数据库的基础上出现了非结构化数据,比如网站 log,IoT 设备数据,APP 埋点数据等,这些数据量比以往结构化的数据大了几个量级,对 ETL 过程、存储都提出了更高的要求;互联网的在线特性也将业务需求推向了实时化,随时根据当前客户行为而调整策略变得越来越常见,比如大促过程中库存管理,运营管理等(即既有中远期策略型,也有短期操作型);同时公司业务互联网化之后导致同时服务的客户剧增,有些情况人工难以完全处理,这就需要机器自动决策。比如欺诈检测和用户审核。 总结来看,对数据仓库的需求可以抽象成两方面:实时产生结果、处理和保存大量异构数据。 注:这里不讨论数据湖技术。3.数据仓库建设方法论3.1 面向主题从公司业务出发,是分析的宏观领域,比如供应商主题、商品主题、客户主题和仓库主题 3.2 为多维数据分析服务数据报表;数据立方体,上卷、下钻、切片、旋转等分析功能。 3.3 反范式数据模型以事实表和维度表组成的星型数据模型 4.数据仓库架构的演变数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法。随着互联网时代来临,数据量暴增,开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代,架构上并没有根本的区别,可以把这个架构叫做离线大数据架构。 后来随着业务实时性要求的不断提高,人们开始在离线大数据架构基础上加了一个加速层,使用流处理技术直接完成那些实时性要求较高的指标计算,这便是 Lambda 架构。 再后来,实时的业务越来越多,事件化的数据源也越来越多,实时处理从次要部分变成了主要部分,架构也做了相应调整,出现了以实时事件处理为核心的 Kappa 架构。 4.1 离线大数据架构数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务,比如 MySQL 或 Redis。数据仓库从模型层面分为三层: ODS,操作数据层,保存原始数据;DWD,数据仓库明细层,根据主题定义好事实与维度表,保存最细粒度的事实数据;DM,数据集市/轻度汇总层,在 DWD 层的基础之上根据不同的业务需求做轻度汇总;典型的数仓存储是 HDFS/Hive,ETL 可以是 MapReduce 脚本或 HiveSQL。 4.2 Lambda 架构随着大数据应用的发展,人们逐渐对系统的实时性提出了要求,为了计算一些实时指标,就在原来离线数仓的基础上增加了一个实时计算的链路,并对数据源做流式改造(即把数据发送到消息队列),实时计算去订阅消息队列,直接完成指标增量的计算,推送到下游的数据服务中去,由数据服务层完成离线&实时结果的合并。 注:流处理计算的指标批处理依然计算,最终以批处理为准,即每次批处理计算后会覆盖流处理的结果。(这仅仅是流处理引擎不完善做的折中)Lambda 架构问题: 同样的需求需要开发两套一样的代码:这是 Lambda 架构最大的问题,两套代码不仅仅意味着开发困难(同样的需求,一个在批处理引擎上实现,一个在流处理引擎上实现,还要分别构造数据测试保证两者结果一致),后期维护更加困难,比如需求变更后需要分别更改两套代码,独立测试结果,且两个作业需要同步上线。资源占用增多:同样的逻辑计算两次,整体资源占用会增多(多出实时计算这部分 4.3 Kappa 架构Lambda 架构虽然满足了实时的需求,但带来了更多的开发与运维工作,其架构背景是流处理引擎还不完善,流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现,流处理技术很成熟了,这时为了解决两套代码的问题,LickedIn 的 Jay Kreps 提出了 Kappa 架构。 ...

September 10, 2019 · 1 min · jiezi

如何运营一家数据标注公司数据处理分类篇

“人工智能之所以称呼他为人工智能,是因为它的核心:也就是神经网络模型。它就是根据模拟人脑的神经网络而诞生的。而图像、语音这一类信息通过特征标注处理(也就是数据标注),变成计算机能够识别的信息。同时通过大量特征数据的训练,最终达到计算机能够自主识别的目的。那么目前AI市场上特征数据主要包括哪些呢......”      我们是靠眼睛、耳朵来捕获外界信息,然后将信息通过神经元传递给我们的大脑,最后我们的大脑会对获取来的各种信息进行分析从而达到诸如判断、识别等效果。      同样,人工智能之所以称呼他为人工智能,是因为它的核心:也就是神经网络模型。它就是根据模拟人脑的神经网络而诞生的。而图像、语音这一类信息通过特征标注处理(也就是数据标注),变成计算机能够识别的信息。同时通过大量特征数据的训练,最终达到计算机能够自主识别的目的。 那么目前AI市场上特征数据主要包括哪些呢?      像人类用眼睛和耳朵获取图像、语音数据一样,计算机的特征数据现阶段也分为两大类:图像数据和语音数据。 同时,根据AI产品迭代的不同周期、算法模型的匹配结果,每个大类又可以细分为众多小类,在这里我们主要对目前市场上主流的需求类型进行一个分类说明。 1. 图像类   这里图像类就是指所有照片的统称 图像场景识别作为人工智能不可获取的一部分已经在日常生活中被大批量应用,这里对图像特征的具体处理手法做一个简单介绍: 四边形矩形拉框   这个也就是数据标注市场上统称的2D拉框,它主要是用特定软件对图像中需要处理的元素(比如:人、车、动物等等),进行一个拉框处理,同时用一个或多个独立的标签来代表一个或多个不同的需要处理元素,同时在标签的添加上可能会碰到多层次的添加(以人为标注元素为例,长短发、胖瘦、穿衣颜色等)从而实现粗线条的种类识别。多边形拉框   顾名思义就是将被标注元素的轮廓以多边型的方式勾勒出来,不同的被标注元素有不同的轮廓,除了同样需要添加单级或多级标签以外,多边型还有可能会涉及到物体遮挡的逻辑关系。从而实现细线条的种类识别。LandMark   标注行业统称打点,对需要标注的元素(比如人脸、肢体)按照需求位置进行点位标注。从而实现特定部位关键点的识别。语义分割   通过对需要标注区域或元素的充色,来达到不同元素或区域之间的分割关系,从而可以清晰的通过不同颜色的区域,对元素进行区分。从而实现系统化的识别。点云拉框   在软件生成的三维模型中,对被标注元素进行外轮廓的3D立体拉框,与2d拉框相同,也需要对生成立体框添加特定标签。从而实现具有空间感的识别。VR打标   使用VR设备,在虚拟立体场景中,对需要标注的元素(各类物体)进行关键区域的打标签。从而实现更精准的被遮挡物品外观轮廓的感知。2. 语音类   这里语音类就是指所有语音的统称语音场景在人工智能领域作为和图片场景同样重要的环节,也同样被大批量的进行应用,这里对语音特征的处理手法大致介绍一下:      目前市场上主流的语音场景都是以区间为单元对区间内的内容进行转述,区间里的元素就是被标注元素。像图片场景里给被标注元素一个特定的标签一样,对区间里的被标注元素也需要提供一个特定的标签,当然这个标签可以是一个词语,也可以是具体的一句话。从而实现对于不同语句类别的判断和对不同语句内容的理解。      当然,各种处理手法在实际的数据标注中都会碰到各种各样的问题。有简单的,也有较为复杂的。这些问题无一例外的都会影响到我们标注员、审核员在工作中的效率,那么如何在实际操作中有效的提高标注效率呢?请持续关注我们的官网www.awkvector.com及blog更新,我们会在接下来更新的文章中,给大家详细解惑。 ©著作权归作者所有:来自作者觉醒向量数据标注的原创作品,如需转载,请注明出处,否则将追究法律责任

August 20, 2019 · 1 min · jiezi

大数据学习方法学习大数据需要的基础和路线

大数据基础学习 大数据基础入门 为什么要学习大数据 1、目的:要份很好工作(钱) 2、对比:Java开发和大数据开发 什么是大数据? 举例: 1、商品推荐:问题: (1)大量的订单如何存储? (2)大量的订单如何计算? 2、天气预报:问题: (1)大量的天气数据如何存储? (2)大量的天气数据如何计算? 如果你想要学好大数据最好加入一个好的学习环境,可以来这个Q群251956502 这样大家学习的话就比较方便,还能够共同交流和分享资料 什么是大数据,本质? (1)数据的存储:分布式文件系统(分布式存储) (2)数据的计算:分布式计算 Java和大数据是什么关系? 1、Hadoop:基于Java语言开发 2、Spark:基于Scala语言,Scala基于Java语言 学习大数据需要的基础和路线 1、学习大数据需要的基础: Java基础(JavaSE)---> 类、继承、I/O、反射、泛型* Linux基础(Linux的操作) ---> 创建文件、目录、vi编辑器* 2、学习路线: (1)Java基础和Linux基础 (2)Hadoop的学习:体系结构、原理、编程 (*)第一阶段:HDFS、MapReduce、HBase(NoSQL数据库) (*)第二阶段:数据分析引擎 ---> Hive、Pig 数据采集引擎 ---> Sqoop、Flume (*)第三阶段:HUE:Web管理工具 ZooKeeper:实现Hadoop的HA Oozie: 工作流引擎 (3)Spark的学习 (*)第一个阶段:Scala编程语言 (*)第二个阶段:Spark Core-----> 基于内存,数据的计算 (*)第三个阶段:Spark SQL -----> 类似Oracle中的SQL语句 (*)第四个阶段:Spark Streaming---> 进行实时计算(流式计算)比如:自来水厂 (4)Apache Storm:类似Spark Streaming ---> 进行实时计算 (流式计算):比如:自来水厂 (*)NoSQL:Redis基于内存的数据库

July 11, 2019 · 1 min · jiezi

福利-Flink-Forward-Asia-2019-由你决定填问卷送周边

2018 年 12 月,Apache Flink Community China 成功举办了国内首届 Flink Forward China,并在诸多合作伙伴的帮助下成功将其打造为规模最大、参与人数最多的 Flink Forward 大会。 今年,Apache Flink 年度最高规格的盛会即将再次拉开帷幕!Flink Forward China 已正式升级为 Flink Forward Asia,并计划于 11 月底举办,规模将逾2000 人。 参与调研送周边为进一步提高会议质量,让 Apache Flink 社区与开发者更近距离地接触,我们诚挚地邀请您参与会前调研,想听什么议题,想见哪位大佬,想要什么礼品,由你决定!福利活动奉上: 点击文末链接,推荐您的小伙伴填写问卷,并在问卷底部的「问卷推荐人」一栏中正确填入您的姓名,可获取相应周边奖励:1. 推荐1-4人填写:Apache Flink 社区限量版专刊 S2 实体书籍2. 推荐5-10人填写:Apache Flink 社区定制马克杯3. 推荐10人以上填写:Apache Flink 社区定制T恤本次问卷调研福利我们首次送出最新定制的 Apache Flink 社区 T 恤、人气最高的社区定制马克杯以及限量纸质版 Apache Flink 第二季专刊《重新定义计算:Apache Flink 实践》。 社区周边展示Apache Flink 社区周边大饱眼福时间到,看看你最想要哪一款! Apache Flink 定制版T恤,小姐姐同款,Meetup 来撞衫! 用 Apache Flink 旗舰款马克杯,喝水都会更开心! ...

July 10, 2019 · 1 min · jiezi

回顾-Apache-Flink-X-Apache-RocketMQ-上海站PPT下载

7 月 6 日,Apache Flink Meetup X Apache RocketMQ · 上海站,来自阿里巴巴、网易的 Flink 技术专家与 Apache RocketMQ 社区大咖一起分享关于 Flink、RocketMQ 的应用实践与前沿技术。 ▼ PPT 下载 ▼ Apache Flink Meetup X Apache RocketMQ · 上海站,嘉宾分享的PPT下载请在后台回复关键字“0706PPT”领取。 《网易云音乐消息队列改造之路与 Apache Flink 应用实践》 林德智 | 网易云音乐 消息队列负责人 岳猛 | Apache Flink Contributor,网易云音乐 实时计算平台研发工程师 本次分享主要介绍了网易云音乐消息队列基于 RocketMQ 的应用以及在消息队列的基础上深度融合的 Flink 流式处理引擎为云音乐提供的实时计算解决方案,分享了在直播,广告,曲库,内容等取得的应用效果。 云音乐消息队列的历史基于 RocketMQ 改造消息队列部分高级特性与 bug 修复RocketMQ 与 Flink 结合应用实践《万亿级消息及流处理引擎 - Apache RocketMQ 的现在和未来》 ...

July 9, 2019 · 1 min · jiezi

Moonbox计算服务平台架构功能与应用场景

导读:业务系统或者日志系统产生了大量的原始数据,我们根据业务场景需求将数据保存到不同的存储中。然而,数据只有通过整合、加工、计算,才能提取出其潜在的信息,让数据变为资产,从而实现数据的价值。Moonbox就是这样一款计算服务平台,在敏捷大数据(Agile BigData)理论的指导下,围绕“计算服务化”和“数据虚拟化”两个核心概念进行设计,支持多种数据源混合计算。Moonbox的设计理念是怎样的?又有什么功能特点呢?本文带您初步走进Moonbox~ 开源地址:https://github.com/edp963/moo... 一、Moonbox设计理念大数据技术在企业中的应用日益广泛,为解决各种不同的场景问题,越来越多的数据系统出现,而如何基于全景数据去进行快速查询计算成为了迫切的需求和挑战。 目前的主流方式是建立以Hadoop为核心的数据仓库/数据湖,这在某种程度上解决了异构数据系统及数据分散的问题,但依然存在数据归集带来的维护成本和时效损失。另外,数据开发人员也面临着业务频繁变更和结果快速交付的问题。 面对这一系列挑战,计算服务化和数据虚拟化提供了很好的解决思路。Moonbox正是在大数据场景下,对计算服务化和数据虚拟化的一种实践,其设计思想主要体现在以下几个方面: 1、计算服务化Moonbox提供多种查询接口以及定时任务,将计算资源变成一种服务,终端用户可以自助注册数据源编写SQL实现需求,只需要关心业务逻辑,而不用关心作业是如何提交运行的。 2、数据虚拟化Moonbox提供虚拟表到物理表之间的映射,终端用户无需关心数据的物理存放位置和底层数据源的特性,可直接操作数据,体验类似操作一个虚拟数据库。 3、统一入口✔ 统一查询语言 Moonbox对用户提供统一的SQL语法标准,屏蔽异构数据系统查询语言的差异,用户只需编写SQL即可查询各种数据系统,也可使用SQL进行跨异构数据系统混算,降低多数据系统的学习成本。 ✔ 统一元数据服务 Moonbox能够对接多种数据系统,可以拿到各个数据系统数据表的schema信息,Moonbox并不存储schema信息,每次都是实时从数据源获取,所以不存在元数据变更不及时,需要同步更新等问题。Moonbox对外提供统一的元数据服务接口,用户无需为了获取各种数据源的元数据而调用多种接口。 ✔ 统一权限控制 每种数据源都有各自特有的安全机制,用户在使用这些数据系统的时候就需要多付出一定的学习成本。Moonbox在逻辑层提供了统一的安全访问机制,在接入时,提供认证登录功能;在查询时,通过拦截分析查询SQL,实现列级别的数据权限控制。如果查询统一从Moonbox接口进入,那么Moonbox就为各种数据源加上了一把安全锁,用户无需再学习各种数据源特有的安全机制。 二、Moonbox体系架构Moonbox体系架构图如下: Moonbox总体上由四部分组成,分别是Moonbox客户端、Moonbox接入层、Moonbox核心功能层以及存储计算层。 1、Moonbox客户端Moonbox客户端主要包括以下几种: ✔ restful api 以restful api的方式提供计算服务,支持batch、adhoc模式,支持同步和异步方式。 ✔ jdbc 对jdbc接口的实现,使用户拥有数据库般的使用体验。 ✔ cli 命令行工具,基于jline实现。通过cli可以完成DDL(Data Definition Language)、DML(Data Manipulation Language)、DCL(Data Control Language)以及Query操作。 ✔ zeppelin 提供zeppelin moonbox interpreter,可以使用zeppelin快速进行原型验证和SQL开发。 ✔ davinci 通过jdbc支持ABD Stack(敏捷大数据技术栈)中数据可视化平台davinci的接入,进行数据查询并展示。 2、Moonbox接入层接入层包括http server和tcp server,实现客户端接入,并进行用户登录认证,支持内置用户名密码认证方式和ldap集成认证方式。 3、Moonbox核心功能层Moonbox将其核心功能层命名为Grid。Grid使用master-slave集群工作模式,支持master主备切换。 Grid有Master、Worker、Runner三种角色: ✔ Master Master负责接收所有的用户请求,根据请求模式(adhoc/batch)将请求调度到合适的Worker上。 ✔ Worker Worker负责Runner的生成和销毁,将请求分配给合适Runner。 ✔ Runner Runner处理用户发过来的请求,包括用户体系管理操作、权限管理操作、SQL解析、下推优化、执行引擎选择等,并向存储/计算层提交真正的计算任务。 4、存储/计算层存储/计算层是计算真正发生的地方。Moonbox使用Spark作为混算引擎,支持standalone和yarn运行模式。当计算逻辑可以完全下推到数据源计算时,Moonbox将计算任务直接mapping成数据源的查询语言进行下推计算,以减小启动分布式作业的开销。数据源除了可以是hdfs这种纯存储系统,或者mysql、elasticsearch这种带计算能力的存储系统,还可以是presto等计算引擎,Moonbox将他们统一视为数据源。 三、Moonbox功能特点1、用户体系Moonbox建立了一套完整的用户体系,引入了Organization的概念,用于划分用户空间。系统管理员ROOT账号可以创建多个Organization,并在Organization中指定该Organization的管理者(SA)。SA可以是一个或者多个,负责创建管理普通用户。 Moonbox将普通用户的能力抽象出五大属性,分别为: ✔ 是否可以创建新用户 ...

July 8, 2019 · 1 min · jiezi

Wormhole大数据流式处理平台五大功能

导读:在上一篇文章「Wormhole 大数据流式处理平台之设计思想」中,我们介绍了Wormhole的设计思想,并给出了Stream、UMS、Flow、Namespace等相关概念的具体定义,从文章中我们得知,Wormhole作为实时流式处理平台,其设计思想最终是为流上处理数据而服务的。在本文中,我们主要从Wormhole的功能设计入手,重点介绍Wormhole所支持的几个基本功能。 Wormhole支持的功能很多,如图1所示,除了流式数据处理,Wormhole在管理和运维等方面也做的比较完善。下面我们从流式处理、平台管理、数据质量、数据安全以及运维监控五个维度来介绍Wormhole的具体功能。 一、流式处理Wormhole的核心是流式处理,并将流式处理抽象为Flow(流式处理逻辑管道,具体参见:#Wormhole# 流式处理平台设计思想)。Flow的引入,使得一个Spark Streaming上可以跑不同的处理逻辑,也就是多个Flow可以在一个Spark Streaming上同时执行而互不影响。这种异构逻辑的并行处理大大提高了资源利用率,也提高了流式处理的易用性。 如图2所示,Flow从处理过程角度分为解析、转换、写入三个过程,具体如下: 1.1 解析Flow支持多种消息协议,UMS和用户自定义JSON两种消息协议: UMSUMS是Flow支持的标准消息协议,在设计思想的文章中有介绍,这里不再介绍。(参见:#Wormhole# 流式处理平台设计思想) 自定义JSON开源后,为了适配用户已有系统的数据格式需求,Flow开始支持用户自定义JSON消息协议,使用也比较方便简单,只要在页面贴一个JSON消息例子,就会自动解析,然后通过点击配置即可完成自定义JSON的Schema的定义。 1.2 转换这里的转换主要指对流上指定的Namespace的数据进行处理,处理方式包括Transform SQL(包含Spark SQL、Lookup SQL、Stream Join SQL)和接口扩展等,并且所有操作都可以有多项,即一个Flow中可以有多个Spark SQL,多个Lookup SQL,多个接口扩展等,具体如下: Spark SQL利用Spark天然支持的SQL对数据做一些map操作,用户指需要在页面编写SQL即可实现实时对流上数据的Spark SQL处理。 Lookup SQLLookup SQL是指将流上指定Namespace数据按某个或某几个字段join外部实体数据系统的数据,也就是将流上的数据加列处理,在页面编写SQL即可实现对流上数据的Lookup操作。目前支持多种Lookup SQL数据系统,包括Mysql、Oracle、Postgresql、SQLServer、Cassandra、Mongodb、Phoenix、ElasticSearch、Vertical、KUDU、Redis、Hbase,除了Redis和Hbase写法是类SQL写法之外,其他都支持SQL写法。下面举例介绍SQL的编写: ✔ 单字段关联: select col1, col2, … from tableName where colA in namespace.X; ✔ 多字段关联: select col1, col2, … from tableName where (colA,colB) in (namespace.X,namespace.Y); ✔ Redis 因Redis不是结构化存储方式,所以只能模仿SQL写法: Redis的value是字符串时:select name:type as n1 from default(simple) joinby (key1+'_'+key2); ...

July 8, 2019 · 1 min · jiezi

大数据开发需要学习什么大数据平台是什么

大数据开发专业需要学习的内容包括三大部分,分别是大数据基础知识、大数据平台知识、大数据场景知识。大数据基础知识: 有三个主要部分,分别是数学、统计学和计算机等学科。大数据基础知识往往决定了开发人员未来的成长高度,所以要重视基础知识的学习。 大数据平台知识: 是大数据开发的基础,在学习期间,往往以搭建Hadoop、Spark平台为主,一方面Hadoop对机器的硬件要求不高,另一方面Hadoop的使用也非常普遍,很多商业大数据平台都是基于Hadoop构建的。大数据的核心是数据价值化。 大数据场景知识: 是目前大数据的重要应用,这些场景包括很多领域,比如金融大数据、交通大数据、教育大数据、餐饮大数据等等,这些场景应用的背后也需要对行业知识有一定的了解。 如果你想要学好大数据最好加入一个好的学习环境,可以来这个Q群251956502 这样大家学习的话就比较方便,还能够共同交流和分享资料 大数据开发学习 大数据开发学习有一定难度,零基础入门首先要学习Java语言打基础,然后进入大数据技术体系的学习,主要学习Hadoop、Spark、Storm等。 大数据需要学习: 语言Java、Scala等 分布式计算Spark,MapReduce等 分布式存储Hbase,MongoDB等 分布式调度与管理Yarn、Zookeeper等 大数据平台是指以处理海量数据存储、计算及不间断流数据实时计算等场景为主的一套基础设施,典型的包括Hadoop系列、Spark、Storm、Flink以及Flume/Kafka等集群,加米谷大数据提供相应的大数据技术支持服务。既可以采用开源平台,也可以采用华为、星环等商业级解决方案,既可以部署在私有云上,也可以部署在公有云上。 大数据的业务应用主要包括以下几个层面: 1、客户管理 充分挖掘分析客户的各维度基本信息以及当前/历史的行为记录,刻画用户画像,实现给客户分群。 2、精准营销 在建立用户画像的基础上,可向特定客户推荐营销针对性的产品或优惠,提升获客能力,巩固客户关系。 3、风险识别 构建异常检测和风险识别等模型,可以有效识别客户管理、产品开发及销售过程中出现的异常和风险,从而做出针对性的处置,防患于未然。 4、运行优化 大数据可以帮助优化渠道、机构,提前缓释负面舆情,保护公司品牌形象。

July 7, 2019 · 1 min · jiezi

小谈CDN回源函数计算的应用场景

CDN团队联合函数计算团队近期推出了一个全新功能,即通过CDN把回源流量指向函数计算进行处理,该功能旨在帮助CDN用户能通过函数计算快速处理和便捷处理回源数据为目的,用户仅仅需要在CDN回源地址填写函数计算的自定义域名即可把请求转发到函数计算进行处理,配置简单,费用低廉,先前CDN回源可以设置几个目的地,例如回源到IP地址、域名或者对象存储OSS,现在新增了一个回源到函数计算的类型,这种类型不同于其他类型,例如CDN回源到ECS某IP上后,ECS需要启一套服务来监听CDN请求,对系统设计要求较高,再比如CDN回源到OSS上,多半只能是一些静态文件,当用户对回源内容进行个性化处理的时候,以上的方式都不够灵活。新增CDN回源函数架构图: 业务流向图可以概述如下: 主打功能:CDN回源数据动态处理CDN请求地址处理拉通CDN请求和多类数据处理对请求地址进行鉴权和跳转场景优势请求链路缩短(减少负载均衡)请求后的弹性扩容对请求地址进行鉴权和跳转技术特点简单,仅需控制台操作配置内置负载均衡和计算弹性扩容,能支持海量并发多种主流语言支持,java,Nodejs,Python,PHP,C#等阿里云集群级别的安全访问控制台上的操作CDN控制台配置: 函数计算控制台配置: 适用场景网站场景用于CDN源站的静态、动态网站页面元数据处理文件处理场景用于CDN回源源站多媒体数据处理,例如文本、图片、视频、音频等。请求分发场景可以通过函数计算把请求做URL地址动态处理后并把请求302分发到其他应用以上各种场景推出,对用户来说有几个显而易见的好处,例如1、节约流量成本,客户通过CDN回源的函数计算走专有网域,会比走公网流量价格更优惠(价格优惠后续公布),2、客户可以很方便的把很多产品串联起来使用,例如通过函数计算能联合多个产品给CDN后的请求提供数据处理,例如新浪微博图片处理(FC+OSS),例如芒果TV的热数据加载等,3、可以做数据处理,也可以做请求分发渠道。相比较ECS,这种方案具备自动弹性伸缩特性,CDN +函数计算 = CDN + 负载均衡+计算,能通过非常优雅的弹性方式来支撑大量CDN请求。4、轻量数据处理程序便捷,5分钟编写一个函数可以灵活处理请求数据,无需维护运行环境,总之是一个很赞的功能,不妨来试用一下~ 本文作者:文意 阅读原文 本文为云栖社区原创内容,未经允许不得转载。

July 5, 2019 · 1 min · jiezi

应用案例-从Storm到Flink有赞五年实时计算效率提升实践

作者 | 贺飞 公司介绍:有赞是一个商家服务公司,提供全行业全场景的电商解决方案。在有赞,大量的业务场景依赖对实时数据的处理,作为一类基础技术组件,服务着有赞内部几十个业务产品,几百个实时计算任务,其中包括交易数据大屏,商品实时统计分析,日志平台,调用链,风控等多个业务场景,本文将介绍有赞实时计算当前的发展历程和当前的实时计算技术架构。 1.实时计算在有赞发展从技术栈的角度,我们的选择和大多数互联网公司一致,从早期的 Storm,到 JStorm, Spark Streaming 和最近兴起的 Flink。从发展阶段来说,主要经历了两个阶段,起步阶段和平台化阶段;下面将按照下图中的时间线,介绍实时计算在有赞的发展历程。 1.1 起步阶段这里的的起步阶段的基本特征是,缺少整体的实时计算规划,缺乏平台化任务管理,监控,报警工具,用户提交任务直接通过登录 AG 服务器使用命令行命令提交任务到线上集群,很难满足用户对可用性的要求。但是,在起步阶段里积累了内部大量的实时计算场景。 1.1.1 Storm 登场2014 年初,第一个 Storm 应用在有赞内部开始使用,最初的场景是把实时事件的统计从业务逻辑中解耦出来,Storm 应用通过监听 MySQL 的 binlog 更新事件做实时计算,然后将结果更新到 MySQL 或者 Redis 缓存上,供在线系统使用。类似的场景得到了业务开发的认可,逐渐开始支撑起大量的业务场景。早期,用户通过登录一组线上环境的 AG 服务器,通过 Storm 的客户端向 Storm 集群做提交任务等操作, 这样在 2 年多的时间里,Storm 组件积累了近百个实时应用。Storm 也同样暴露出很多问题,主要体现在系统吞吐上,对吞吐量巨大,但是对延迟不敏感的场景,显得力不从心。 1.1.2 引入 Spark Streaming2016 年末,随着 Spark 技术栈的日益成熟,又因为 Storm 引擎本身在吞吐 / 性能上跟 Spark Streaming 技术栈相比有明显劣势,所以从那时候开始,部分业务团队开始尝试新的流式计算引擎。因为有赞离线计算有大量 Spark 任务的使用经验,Spark Streaming 很自然的成为了第一选择,随着前期业务日志系统和埋点日志系统的实时应用的接入,大量业务方也开始逐渐接入。同 Storm 一样,业务方完成实时计算应任务开发后,通过一组 AG 服务器,使用 Spark 客户端,向大数据 Yarn 集群提交任务。 ...

July 4, 2019 · 2 min · jiezi

回顾-阿里云实时计算专场-北京站

6 月 30 日,阿里云实时计算专场北京站,由来自格灵深瞳的大数据总监与阿里巴巴产品专家、技术专家一起与大家探讨实时计算的应用实践与场景化解决方案。 实时计算是基于 Apache Flink 构建的一站式高性能实时大数据处理平台,在 PB 级别的数据集上可以支持亚秒级别的处理延时,赋能用户标准实时数据处理流程和行业解决方案。2019 年 6 月阿里云实时计算通过数据中心联盟最新制定的大数据分布式流处理平台基础能力评测,成为国内首批通过流计算产品能力评测的产品。 ▼ PPT 下载 ▼ 阿里云实时计算专场北京站,四位嘉宾分享的PPT下载请在后台回复关键字“0630PPT”领取。 《Flink在人脸识别实时业务中的应用》 陈新宇 | 格灵深瞳 大数据总监 Flink 作为下一代流计算引擎,以其高效、低延迟等特性获得了大量关注与应用。格灵深瞳自2017年开始就将 Flink 应用在生产之中,为客户提供基于人脸识别的实时数据分析服务及面向不同行业的整体解决方案,本次分享介绍了 Flink 在格灵深瞳人脸识别实时业务场景中的技术选型原因、具体应用、遇到的一些问题及改进。 背景及现状应⽤用及⽅方案问题与优化后续与局限《实时计算场景化解决方案》 高旸 | 阿里巴巴 高级产品专家 主要内容是介绍实时计算产品商业架构及技术架构,对比其他商业化流计算产品及开源软件,实时计算的产品优势,产品典型的应用场景划分,在数字媒体、在线教育、新零售以及城市大脑中的应用场景介绍及相应的解决方案分享。 实时计算产品形态产品架构 / 定位 / Unified SQL / Unified Runtime阿里云实时计算被集成方案轻量化 PaaS 解决方案实时计算典型场景演进路线典型场景 《如何构建基于 Flink on Kubernetes 的大数据平台》 任春德 | 阿里巴巴 高级技术专家 本次分享从大数据领域,初露头角的 Kubernetes 如何 PK 日臻完善的基于 Yarn 调度的平台、新一代的批流一体的大数据处理引擎 Flink 与 Kubernetes 结合形成的新平台有哪些优势、如何将其构建成一套易运维、高可用、高利用率的平台等三部分内容进行分享。 ...

July 4, 2019 · 1 min · jiezi

回顾-Apache-Flink-19-版本新特性强势预告内含PPT下载链接

6月29日,Apache Flink Meetup 北京站圆满落幕,Apache Flink 1.9 版本是自 Flink 1.0 之后变化最大的版本,社区对 Flink 进行大量重构并且加入了很多新 Feature。此次 Meetup 重点解读 Flink 1.9 版本新特性。 ▼ PPT下载 ▼关注Apache Flink 社区公众号Ververica,回复关键字“0629PPT”即可下载Apache Flink Meetup 北京站全部嘉宾分享的PPT. 本期 Meetup 由 Apache Flink PMC 与 Committer 开场,对 Flink 1.9 版本新特性进行全面分享;阿里巴巴技术专家从 Table API 和算法层面分享 Flink 的机器学习生态;还有 Flink on Kubernetes 、Flink 1.9 版本与 Hive 的兼容性解读,以及超过千台集群、日处理条目超过 264 亿条,处理峰值超过 3.6 千万条 / s 的 Flink 在快手的应用实践。 《Apache Flink 1.9 特性解读》 ...

July 3, 2019 · 2 min · jiezi

Apache-Flink-零基础入门一基础概念解析

作者:陈守元、戴资力 一、Apache Flink 的定义、架构及原理Apache Flink 是一个分布式大数据处理引擎,可对有限数据流和无限数据流进行有状态或无状态的计算,能够部署在各种集群环境,对各种规模大小的数据进行快速计算。 1. Flink Application了解 Flink 应用开发需要先理解 Flink 的 Streams、State、Time 等基础处理语义以及 Flink 兼顾灵活性和方便性的多层次 API。 Streams:流,分为有限数据流与无限数据流,unbounded stream 是有始无终的数据流,即无限数据流;而 bounded stream 是限定大小的有始有终的数据集合,即有限数据流,二者的区别在于无限数据流的数据会随时间的推演而持续增加,计算持续进行且不存在结束的状态,相对的有限数据流数据大小固定,计算最终会完成并处于结束的状态。State,状态是计算过程中的数据信息,在容错恢复和 Checkpoint 中有重要的作用,流计算在本质上是 Incremental Processing,因此需要不断查询保持状态;另外,为了确保 Exactly- once 语义,需要数据能够写入到状态中;而持久化存储,能够保证在整个分布式系统运行失败或者挂掉的情况下做到 Exactly- once,这是状态的另外一个价值。Time,分为 Event time、Ingestion time、Processing time,Flink 的无限数据流是一个持续的过程,时间是我们判断业务状态是否滞后,数据处理是否及时的重要依据。API,API 通常分为三层,由上而下可分为 SQL / Table API、DataStream API、ProcessFunction 三层,API 的表达能力及业务抽象能力都非常强大,但越接近 SQL 层,表达能力会逐步减弱,抽象能力会增强,反之,ProcessFunction 层 API 的表达能力非常强,可以进行多种灵活方便的操作,但抽象能力也相对越小。2.Flink Architecture在架构部分,主要分为以下四点: 第一, Flink 具备统一的框架处理有界和无界两种数据流的能力 第二, 部署灵活,Flink 底层支持多种资源调度器,包括 Yarn、Kubernetes 等。Flink 自身带的 Standalone 的调度器,在部署上也十分灵活。 第三, 极高的可伸缩性,可伸缩性对于分布式系统十分重要,阿里巴巴双11大屏采用 Flink 处理海量数据,使用过程中测得 Flink 峰值可达 17 亿/秒。 ...

July 2, 2019 · 4 min · jiezi

用Flink取代Spark-Streaming知乎实时数仓架构演进

作者 | 知乎数据工程团队 “数据智能” (Data Intelligence) 有一个必须且基础的环节,就是数据仓库的建设,同时,数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务。从智能商业的角度来讲,数据的结果代表了用户的反馈,获取结果的及时性就显得尤为重要,快速的获取数据反馈能够帮助公司更快的做出决策,更好的进行产品迭代,实时数仓在这一过程中起到了不可替代的作用。 本文主要讲述知乎的实时数仓实践以及架构的演进,这包括以下几个方面: 实时数仓 1.0 版本,主题:ETL 逻辑实时化,技术方案:Spark Streaming。实时数仓 2.0 版本,主题:数据分层,指标计算实时化,技术方案:Flink Streaming。实时数仓未来展望:Streaming SQL 平台化,元信息管理系统化,结果验收自动化。实时数仓 1.0 版本1.0 版本的实时数仓主要是对流量数据做实时 ETL,并不计算实时指标,也未建立起实时数仓体系,实时场景比较单一,对实时数据流的处理主要是为了提升数据平台的服务能力。实时数据的处理向上依赖数据的收集,向下关系到数据的查询和可视化,下图是实时数仓 1.0 版本的整体数据架构图。 第一部分是数据采集,由三端 SDK 采集数据并通过 Log Collector Server 发送到 Kafka。第二部分是数据 ETL,主要完成对原始数据的清洗和加工并分实时和离线导入 Druid。第三部分是数据可视化,由 Druid 负责计算指标并通过 Web Server 配合前端完成数据可视化。 其中第一、三部分的相关内容请分别参考:知乎客户端埋点流程、模型和平台技术,Druid 与知乎数据分析平台,此处我们详细介绍第二部分。由于实时数据流的稳定性不如离线数据流,当实时流出现问题后需要离线数据重刷历史数据,因此实时处理部分我们采用了 lambda 架构。 Lambda 架构有高容错、低延时和可扩展的特点,为了实现这一设计,我们将 ETL 工作分为两部分:Streaming ETL 和 Batch ETL。 Streaming ETL这一部分我会介绍实时计算框架的选择、数据正确性的保证、以及 Streaming 中一些通用的 ETL 逻辑,最后还会介绍 Spark Streaming 在实时 ETL 中的稳定性实践。 计算框架选择在 2016 年年初,业界用的比较多的实时计算框架有 Storm 和 Spark Streaming。Storm 是纯流式框架,Spark Streaming 用 Micro Batch 模拟流式计算,前者比后者更实时,后者比前者吞吐量大且生态系统更完善,考虑到知乎的日志量以及初期对实时性的要求,我们选择了 Spark Streaming 作为实时数据的处理框架。 ...

June 27, 2019 · 3 min · jiezi

原理解析-深入了解-Apache-Flink-的网络协议栈

作者:Nico Kruber 翻译:曹英杰 Flink 的网络协议栈是组成 flink-runtime 模块的核心组件之一,是每个 Flink 作业的核心。它连接所有 TaskManager 的各个子任务(Subtask),因此,对于 Flink 作业的性能包括吞吐与延迟都至关重要。与 TaskManager 和 JobManager 之间通过基于 Akka 的 RPC 通信的控制通道不同,TaskManager 之间的网络协议栈依赖于更加底层的 Netty API。 本文将首先介绍 Flink 暴露给流算子(Stream operator)的高层抽象,然后详细介绍 Flink 网络协议栈的物理实现和各种优化、优化的效果以及 Flink 在吞吐量和延迟之间的权衡。 1.逻辑视图Flink 的网络协议栈为彼此通信的子任务提供以下逻辑视图,例如在 A 通过 keyBy() 操作进行数据 Shuffle : 这一过程建立在以下三种基本概念的基础上: ▼ 子任务输出类型(ResultPartitionType):Pipelined(有限的或无限的):一旦产生数据就可以持续向下游发送有限数据流或无限数据流。Blocking:仅在生成完整结果后向下游发送数据。 ▼ 调度策略:同时调度所有任务(Eager):同时部署作业的所有子任务(用于流作业)。上游产生第一条记录部署下游(Lazy):一旦任何生产者生成任何输出,就立即部署下游任务。上游产生完整数据部署下游:当任何或所有生产者生成完整数据后,部署下游任务。 ▼ 数据传输:高吞吐:Flink 不是一个一个地发送每条记录,而是将若干记录缓冲到其网络缓冲区中并一次性发送它们。这降低了每条记录的发送成本因此提高了吞吐量。低延迟:当网络缓冲区超过一定的时间未被填满时会触发超时发送,通过减小超时时间,可以通过牺牲一定的吞吐来获取更低的延迟。 我们将在下面深入 Flink 网络协议栈的物理实现时看到关于吞吐延迟的优化。对于这一部分,让我们详细说明输出类型与调度策略。首先,需要知道的是子任务的输出类型和调度策略是紧密关联的,只有两者的一些特定组合才是有效的。 Pipelined 结果是流式输出,需要目标 Subtask 正在运行以便接收数据。因此需要在上游 Task 产生数据之前或者产生第一条数据的时候调度下游目标 Task 运行。批处理作业生成有界结果数据,而流式处理作业产生无限结果数据。 批处理作业也可能以阻塞方式产生结果,具体取决于所使用的算子和连接模式。在这种情况下,必须等待上游 Task 先生成完整的结果,然后才能调度下游的接收 Task 运行。这能够提高批处理作业的效率并且占用更少的资源。 下表总结了 Task 输出类型以及调度策略的有效组合: ...

June 26, 2019 · 3 min · jiezi

原理解析-深入了解-Apache-Flink-的网络协议栈

作者:Nico Kruber 翻译:曹英杰 Flink 的网络协议栈是组成 flink-runtime 模块的核心组件之一,是每个 Flink 作业的核心。它连接所有 TaskManager 的各个子任务(Subtask),因此,对于 Flink 作业的性能包括吞吐与延迟都至关重要。与 TaskManager 和 JobManager 之间通过基于 Akka 的 RPC 通信的控制通道不同,TaskManager 之间的网络协议栈依赖于更加底层的 Netty API。 本文将首先介绍 Flink 暴露给流算子(Stream operator)的高层抽象,然后详细介绍 Flink 网络协议栈的物理实现和各种优化、优化的效果以及 Flink 在吞吐量和延迟之间的权衡。 1.逻辑视图Flink 的网络协议栈为彼此通信的子任务提供以下逻辑视图,例如在 A 通过 keyBy() 操作进行数据 Shuffle : 这一过程建立在以下三种基本概念的基础上: ▼ 子任务输出类型(ResultPartitionType):Pipelined(有限的或无限的):一旦产生数据就可以持续向下游发送有限数据流或无限数据流。Blocking:仅在生成完整结果后向下游发送数据。 ▼ 调度策略:同时调度所有任务(Eager):同时部署作业的所有子任务(用于流作业)。上游产生第一条记录部署下游(Lazy):一旦任何生产者生成任何输出,就立即部署下游任务。上游产生完整数据部署下游:当任何或所有生产者生成完整数据后,部署下游任务。 ▼ 数据传输:高吞吐:Flink 不是一个一个地发送每条记录,而是将若干记录缓冲到其网络缓冲区中并一次性发送它们。这降低了每条记录的发送成本因此提高了吞吐量。低延迟:当网络缓冲区超过一定的时间未被填满时会触发超时发送,通过减小超时时间,可以通过牺牲一定的吞吐来获取更低的延迟。 我们将在下面深入 Flink 网络协议栈的物理实现时看到关于吞吐延迟的优化。对于这一部分,让我们详细说明输出类型与调度策略。首先,需要知道的是子任务的输出类型和调度策略是紧密关联的,只有两者的一些特定组合才是有效的。 Pipelined 结果是流式输出,需要目标 Subtask 正在运行以便接收数据。因此需要在上游 Task 产生数据之前或者产生第一条数据的时候调度下游目标 Task 运行。批处理作业生成有界结果数据,而流式处理作业产生无限结果数据。 批处理作业也可能以阻塞方式产生结果,具体取决于所使用的算子和连接模式。在这种情况下,必须等待上游 Task 先生成完整的结果,然后才能调度下游的接收 Task 运行。这能够提高批处理作业的效率并且占用更少的资源。 下表总结了 Task 输出类型以及调度策略的有效组合: ...

June 25, 2019 · 3 min · jiezi

Flink-零基础实战教程如何计算实时热门商品

在上一篇入门教程中,我们已经能够快速构建一个基础的 Flink 程序了。本文会一步步地带领你实现一个更复杂的 Flink 应用程序:实时热门商品。在开始本文前我们建议你先实践一遍上篇文章,因为本文会沿用上文的my-flink-project项目框架。 通过本文你将学到: 如何基于 EventTime 处理,如何指定 Watermark如何使用 Flink 灵活的 Window API何时需要用到 State,以及如何使用如何使用 ProcessFunction 实现 TopN 功能实战案例介绍“实时热门商品”的需求,我们可以将“实时热门商品”翻译成程序员更好理解的需求:每隔5分钟输出最近一小时内点击量最多的前 N 个商品。将这个需求进行分解我们大概要做这么几件事情: 抽取出业务时间戳,告诉 Flink 框架基于业务时间做窗口过滤出点击行为数据按一小时的窗口大小,每5分钟统计一次,做滑动窗口聚合(Sliding Window)按每个窗口聚合,输出每个窗口中点击量前N名的商品数据准备这里我们准备了一份淘宝用户行为数据集(来自阿里云天池公开数据集,特别感谢)。本数据集包含了淘宝上某一天随机一百万用户的所有行为(包括点击、购买、加购、收藏)。数据集的组织形式和MovieLens-20M类似,即数据集的每一行表示一条用户行为,由用户ID、商品ID、商品类目ID、行为类型和时间戳组成,并以逗号分隔。关于数据集中每一列的详细描述如下: 列名称说明用户ID整数类型,加密后的用户ID商品ID整数类型,加密后的商品ID商品类目ID整数类型,加密后的商品所属类目ID行为类型字符串,枚举类型,包括(‘pv’, ‘buy’, ‘cart’, ‘fav’)时间戳行为发生的时间戳,单位秒你可以通过下面的命令下载数据集到项目的 resources 目录下: $ cd my-flink-project/src/main/resources$ curl https://raw.githubusercontent.com/wuchong/my-flink-project/master/src/main/resources/UserBehavior.csv > UserBehavior.csv这里是否使用 curl 命令下载数据并不重要,你也可以使用 wget 命令或者直接访问链接下载数据。关键是,将数据文件保存到项目的 resources 目录下,方便应用程序访问。 编写程序在 src/main/java/myflink 下创建 HotItems.java 文件: package myflink;public class HotItems { public static void main(String[] args) throws Exception { }}与上文一样,我们会一步步往里面填充代码。第一步仍然是创建一个 StreamExecutionEnvironment,我们把它添加到 main 函数中。 ...

June 21, 2019 · 4 min · jiezi

揭秘每秒千万级的实时数据处理是怎么实现的

1、设计背景闲鱼目前实际生产部署环境越来越复杂,横向依赖各种服务盘宗错节,纵向依赖的运行环境也越来越复杂。当服务出现问题的时候,能否及时在海量的数据中定位到问题根因,成为考验闲鱼服务能力的一个严峻挑战。 线上出现问题时常常需要十多分钟,甚至更长时间才能找到问题原因,因此一个能够快速进行自动诊断的系统需求就应用而生,而快速诊断的基础是一个高性能的实时数据处理系统。 这个实时数据处理系统需要具备如下的能力: 1、数据实时采集、实时分析、复杂计算、分析结果持久化。2、可以处理多种多样的数据。包含应用日志、主机性能监控指标、调用链路图。3、高可靠性。系统不出问题且数据不能丢。4、高性能,底延时。数据处理的延时不超过3秒,支持每秒千万级的数据处理。 本文不涉及问题自动诊断的具体分析模型,只讨论整体实时数据处理链路的设计。 2、输入输出定义为了便于理解系统的运转,我们定义该系统整体输入和输出如下:  输入: 服务请求日志(包含traceid、时间戳、客户端ip、服务端ip、耗时、返回码、服务名、方法名)        环境监控数据(指标名称、ip、时间戳、指标值)。比如cpu、 jvm gc次数、jvm gc耗时、数据库指标。 输出: 一段时间内的某个服务出现错误的根因,每个服务的错误分析结果用一张有向无环图表达。(根节点即是被分析的错误节点,叶子节点即是错误根因节点。叶子节点可能是一个外部依赖的服务错误也可能是jvm异常等等)。 3、架构设计 在实际的系统运行过程中,随着时间的推移,日志数据以及监控数据是源源不断的在产生的。每条产生的数据都有一个自己的时间戳。而实时传输这些带有时间戳的数据就像水在不同的管道中流动一样。 如果把源源不断的实时数据比作流水,那数据处理过程和自来水生产的过程也是类似的: 自然地,我们也将实时数据的处理过程分解成采集、传输、预处理、计算、存储几个阶段。 整体的系统架构设计如下: 采集采用阿里自研的sls日志服务产品(包含logtail+loghub组件),logtail是采集客户端,之所以选择logtail是因为其优秀的性能、高可靠性以及其灵活插件扩展机制,闲鱼可以定制自己的采集插件实现各种各样数据的实时采集。 传输loghub可以理解为一个数据发布订阅组件,和kafka的功能类似,作为一个数据传输通道其更稳定、更安全,详细对比文章参考:https://yq.aliyun.com/articles/35979?spm=5176.10695662.1996646101.searchclickresult.6f2c7fbe6g3xgP 预处理实时数据预处理部分采用blink流计算处理组件(开源版本叫做flink,blink是阿里在flink基础上的内部增强版本)。目前常用的实时流计算开源产品有Jstorm、SparkStream、Flink。Jstorm由于没有中间计算状态的,其计算过程中需要的中间结果必然依赖于外部存储,这样会导致频繁的io影响其性能;SparkStream本质上是用微小的批处理来模拟实时计算,实际上还是有一定延时;Flink由于其出色的状态管理机制保证其计算的性能以及实时性,同时提供了完备SQL表达,使得流计算更容易。  计算与持久化数据经过预处理后最终生成调用链路聚合日志和主机监控数据,其中主机监控数据会独立存储在tsdb时序数据库中,供后续统计分析。tsdb由于其针对时间指标数据的特别存储结构设计,非常适合做时序数据的存储与查询。调用链路日志聚合数据,提供给cep/graph service做诊断模型分析。cep/graph service是闲鱼自研的一个应用,实现模型分析、复杂的数据处理以及外部服务进行交互,同时借助rdb实现图数据的实时聚合。 最后cep/graph service分析的结果作为一个图数据,实时转储在lindorm中提供在线查询。lindorm可以看作是增强版的hbase,在系统中充当持久化存储的角色。 4、设计细节与性能优化采集日志和指标数据采集使用logtail,整个数据采集过程如图: 其提供了非常灵活的插件机制,共有四种类型的插件: inputs: 输入插件,获取数据。processors: 处理插件,对得到的数据进行处理。aggregators: 聚合插件,对数据进行聚合。flushers: 输出插件,将数据输出到指定 sink。由于指标数据(比如cpu、内存、jvm指标)的获取需要调用本地机器上的服务接口获取,因此应尽量减少请求次数,在logtail中,一个input占用一个goroutine。闲鱼通过定制input插件和processors插件,将多个指标数据(比如cpu、内存、jvm指标)在一个input插件中通过一次服务请求获取(指标获取接口由基础监控团队提供),并将其格式化成一个json数组对象,在processors插件中再拆分成多条数据,以减少系统的io次数同时提升性能。 传输数据传输使用LogHub,logtail写入数据后直接由blink消费其中的数据,只需设置合理的分区数量即可。分区数要大于等于bink读取任务的并发数,避免blink中的任务空转。 预处理预处理主要采用bink实现,主要的设计和优化点: 1:编写高效的计算流程blink是一个有状态的流计算框架,非常适合做实时聚合、join等操作。在我们的应用中只需要关注出现错误的的请求上相关服务链路的调用情况,因此整个日志处理流分成两个流:a、服务的请求入口日志作为一个单独的流来处理,筛选出请求出错的数据。b、其他中间链路的调用日志作为另一个独立的流来处理,通过和上面的流join on traceid实现出错服务依赖的请求数据塞选。  如上图所示通过双流join后,输出的就是所有发生请求错误相关链路的完整数据。 2:设置合理的state生存周期blink在做join的时候本质上是通过state缓存中间数据状态,然后做数据的匹配。而如果state的生命周期太长会导致数据膨胀影响性能,如果state的生命周期太短就会无法正常关联出部分延迟到来的数据,所以需要合理的配置state生存周期,对于该应用允许最大数据延迟为1分钟。 使用niagara作为statebackend,以及设定state数据生命周期,单位毫秒state.backend.type=niagarastate.backend.niagara.ttl.ms=600003:开启 MicroBatch/MiniBatchMicroBatch 和 MiniBatch 都是微批处理,只是微批的触发机制上略有不同。原理上都是缓存一定的数据后再触发处理,以减少对 state 的访问从而显著提升吞吐,以及减少输出数据量。 开启joinblink.miniBatch.join.enabled=true使用 microbatch 时需要保留以下两个 minibatch 配置blink.miniBatch.allowLatencyMs=5000防止OOM,每个批次最多缓存多少条数据blink.miniBatch.size=200004:动态负载使用 Dynamic-Rebalance 替代 Rebalanceblink任务在运行是最忌讳的就是存在计算热点,为保证数据均匀使用Dynamic Rebalance,它可以根据当前各subpartition中堆积的buffer的数量,选择负载较轻的subpartition进行写入,从而实现动态的负载均衡。相比于静态的rebalance策略,在下游各任务计算能力不均衡时,可以使各任务相对负载更加均衡,从而提高整个作业的性能。 开启动态负载task.dynamic.rebalance.enabled=true5:自定义输出插件数据关联后需要将统一请求链路上的数据作为一个数据包通知下游图分析节点,传统的方式的是通过消息服务来投递数据。但是通过消息服务有两个缺点:1、其吞吐量和rdb这种内存数据库相比比还是较大差距(大概差一个数量级)。2、在接受端还需要根据traceid做数据关联。 ...

June 21, 2019 · 1 min · jiezi

DLA-SQL技巧行列转换和JSON数据列展开

1. 简介在数据库SQL处理中,常常有行转列(Pivot)和列转行(Unpivot)的数据处理需求。本文以示例说明在Data Lake Analytics(https://www.aliyun.com/product/datalakeanalytics)中,如何使用SQL的一些技巧,达到行转列(Pivot)和列转行(Unpivot)的目的。另外,DLA支持函数式表达式的处理逻辑、丰富的JSON数据处理函数和UNNEST的SQL语法,结合这些功能,能够实现非常丰富、强大的SQL数据处理语义和能力,本文也以JSON数据列展开为示例,说明在DLA中使用这种SQL的技巧。 2. 行转列(Pivot)2.1 样例数据 test_pivot表内容: +------+----------+---------+--------+| id | username | subject | source |+------+----------+---------+--------+| 1 | 张三 | 语文 | 60 || 2 | 李四 | 数学 | 70 || 3 | 王五 | 英语 | 80 || 4 | 王五 | 数学 | 75 || 5 | 王五 | 语文 | 57 || 6 | 李四 | 语文 | 80 || 7 | 张三 | 英语 | 100 |+------+----------+---------+--------+2.2 方法一:通过CASE WHEN语句 ...

June 20, 2019 · 4 min · jiezi

入门教程-5分钟从零构建第一个-Flink-应用

本文转载自 Jark’s Blog ,作者伍翀(云邪),Apache Flink Committer,阿里巴巴高级开发工程师。本文将从开发环境准备、创建 Maven 项目,编写 Flink 程序、运行程序等方面讲述如何迅速搭建第一个 Flink 应用。在本文中,我们将从零开始,教您如何构建第一个 Flink 应用程序。开发环境准备Flink 可以运行在 Linux, Max OS X, 或者是 Windows 上。为了开发 Flink 应用程序,在本地机器上需要有 Java 8.x 和 maven 环境。 如果有 Java 8 环境,运行下面的命令会输出如下版本信息: $ java -versionjava version "1.8.0_65"Java(TM) SE Runtime Environment (build 1.8.0_65-b17)Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)如果有 maven 环境,运行下面的命令会输出如下版本信息:$ mvn -versionApache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T02:33:14+08:00)Maven home: /Users/wuchong/dev/mavenJava version: 1.8.0_65, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jreDefault locale: zh_CN, platform encoding: UTF-8OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"另外我们推荐使用 ItelliJ IDEA (社区免费版已够用)作为 Flink 应用程序的开发 IDE。Eclipse 虽然也可以,但是 Eclipse 在 Scala 和 Java 混合型项目下会有些已知问题,所以不太推荐 Eclipse。下一章节,我们会介绍如何创建一个 Flink 工程并将其导入 ItelliJ IDEA。创建 Maven 项目我们将使用 Flink Maven Archetype 来创建我们的项目结构和一些初始的默认依赖。在你的工作目录下,运行如下命令来创建项目: ...

June 20, 2019 · 2 min · jiezi

如何从小白进化成-Apache-Flink-技术专家9节基础课程免费公开

随着数据量的爆发,AI走上风口,典型的大数据业务场景下数据业务最通用的做法是:选用批计算的技术处理全量数据,采用流计算的技术处理实时增量数据。在生产环境中,用户通常采用批处理和流处理两套计算引擎来支持这两种场景。弊端就是需要写两套代码,维护两套引擎,毫无疑问,这种架构带来了额外的负担与成本。 面对全量数据和增量数据,能否用一套统一的大数据引擎技术来处理? Apache Flink 被业界公认为最好的流计算引擎,其计算能力不仅仅局限于做流处理,而是一套兼具流、批、机器学习等多种计算功能的大数据引擎,用户只需根据业务逻辑开发一套代码,无论是全量数据还是增量数据,亦或者实时处理,一套方案即可全部支持。为了让大家更全面地了解 Apache Flink 背后的技术以及应用实践,今天,我们首次免费公开 Apache Flink 系列视频课程。 为什么要收藏 Apache Flink 系列课程?2018年市场调查报告显示 Apache Flink 是2018年开源大数据生态中发展“最快”的引擎,相较于2017年增长了125% 。Flink 的社区生态在不断发展壮大,在中国,越来越多的互联网公司在生产环境中采用Flink解决实时计算、流计算、风控等问题,因而,学习 Flink 迫在眉睫。 此次免费公开课共分为9个课时,课程内容包含 Flink 的基础架构、应用场景、集群部署、运行机制、编程范式,为你系统地拆分讲解大数据计算开发引擎Flink。 1.1 为什么要学习 Apache Flink? 关键词:Flink 的重要性 课程开篇由阿里巴巴高级产品专家,实时计算产品团队负责人陈守元(巴真)开讲,从开设Apache Flink 系列课程的初衷、Apache Flink 的定义/架构/原理以及学前准备与学习方法与你分享如何高效学习 Flink 系列课程。 1.2 Flink 基本概念 关键词:Apache Flink PMC、有状态的流式处理 本节课程由 Apache Flink PMC、Ververica Software Engineer 戴资力与你探讨 Flink 作为有状态的流式处理引擎的核心概念应当如何理解,Flink 与其他大数据引擎的区别是什么?为什么要使用 Flink 以及有状态的流式处理引擎面临哪些挑战? 1.3 Flink 安装部署、环境配置及运行应用程序 关键词:开发 Flink 必经第一课 破解“知易行难”的方法是实战,第三节内容由阿里巴巴高级开发工程师沙晟阳带你从Flink开发环境的部署、配置、运行,以及不同模式的应用场景入手,示范如何快速正确安装应用Flink,并为你提供了实际应用中可能出现的问题与相应的解决方案。 1.4 DataStream API 编程 ...

June 14, 2019 · 1 min · jiezi

即插即用基于阿里云Ganos快速构建云上开源GIS方案

对于轻量级GIS应用,选择具备时空能力的云上数据库再搭配开源GIS软件,能够快速构建稳定、廉价、实用的GIS解决方案。Ganos是阿里云自研时空基础设施(PaaS层)的核心引擎,该引擎整合了云上异构计算并行加速、OSS大规模存储等基础设施能力,上层与RDS PostgresSQL数据库、POLARDB for PG/Oracle云原生数据库、HBase大数据等融合,为云计算基础产品提供了免费但专业级的时空数据存储、查询与分析计算能力。本文主要介绍如何将Ganos作为数据源与GeoServer、uDig、QGIS等最常用的开源GIS软件对接,为基于开源GIS应用方案选型提供支撑。 支持常用各大开源GIS软件因Ganos设计上充分兼容了PostGIS接口,因此理论上可以无缝对接支持PostGIS的各类软件生态。 选取部分常用开源GIS软件说明如下表所示: 开源GIS软件软件定位用途Ganos作用QGIS基于C++的桌面GIS数据的可视化、管理、编辑、分析以及印刷地图的制作,功能全面兼容postgis形式的数据源GeoserverGIS服务器软件发布地图数据,允许用户对特征数据进行更新、删除、插入操作,方便共享空间地理信息兼容postgis形式数据源uDig基于Java的桌面GIS桌面GIS及开发框架,对互联网GIS、网络地图服务器和网络功能服务器有特别的加强兼容postgis形式的数据源OpenJump基于Java的桌面 GIS内置了地图编辑、可视化,GIS空间分析等操作,并可以通过插件方式进行功能的定制或拓展兼容postgis形式的数据源MapNik基于Python/C++ 地图渲染引擎数据形式的地图通过一个样式表的定义渲染成位图格式提供 WMS等服务兼容postgis形式的数据源以上主要集中在GIS最为常用的几何对象(矢量)部分,需要注意的是,Ganos在除了兼容PostGIS能力外,其他栅格、DEM、点云、网络、轨迹等高级时空特性也能与这些软件打通。如有这方面的需求,可以直接通过文末联系方式获得支持。 简单连接配置,即插即用以下以QGIS、GeoServer、OpenJump、uDig为例,展示以阿里云PostgresSQL Ganos或POLARDB Ganos为数据源的对接与应用,其他基于PostGIS数据源驱动的开源3S软件等均类似,不再一一展开。首先,需要通过阿里云主页购买RDS PostgresSQL、POLARDB for PG或POLARDB for Oracle实例(见文末链接,其中POLARDB for PG/Oracle目前可免费申请公测),并通过SQL插入或shp2pgsql工具导入矢量数据。数据导入后,可以通过控制台自带的DMS工具查看所导入的数据: 接下来,可以基于Ganos数据源,采用开源GIS软件来执行各类操作。 (1)QGIS连接Ganos,可浏览、查看、编辑、分析Ganos中的空间数据。 (2)GeoServer连接Ganos,可以将矢量数据发布为WMS,WFS等服务,实现地理空间数据的快速共享应用。 (3)OpenJump连接Ganos ,可浏览、查看、编辑、分析Ganos中的空间数据。 (4)uDig连接Ganos ,可浏览、查看、编辑、分析Ganos中的空间数据。 不一样的底座,更强大能力通过兼容PostGIS接口,Ganos具备了几乎即插即用、快速生态兼容的能力,且所有兼容PostGIS的代码都无需改动。同时,Ganos通过与阿里云基础设施融合,提供比自建PG+PostGIS更高系统稳定性和可靠性、更强数据处理能力和更大数据处理规模,尤其在时空轨迹数据处理能力上,要比原生PostGIS提高50-100性能。后续Ganos将遵循OGC规范,适配更多数据种类,广泛支持包括开源和商业不同3S平台,逐步沉淀基础时空云计算能力到云计算基础平台,赋能ISV厂商,推动时空云计算作为数字化转型的基础引擎普惠到更多客户。 如何获取Ganos时空引擎Ganos已无缝嵌入于阿里云以下数据库产品中,您无需为时空数据管理支付额外费用,了解更多相关信息请戳链接: RDS PostgreSQL with Ganos产品入口:https://www.aliyun.com/product/rds/postgresqlPOLARDB for PG/Oracle with Ganos产品入口(可申请免费公测):https://www.aliyun.com/product/POLARDBHBase with Ganos产品入口:https://www.aliyun.com/product/hbase 本文作者:ganos阅读原文 本文为云栖社区原创内容,未经允许不得转载。

June 11, 2019 · 1 min · jiezi

做可交互的统计图表这套图形语法不容错过

选好可视化“一图胜千言”,是最直观的数据可视化魅力。以图表来传达和沟通信息,其效率远超枯燥乏味的数据表达。 有需求就有市场。数据可视化崭露头角后,各个厂商出备的产品、解决方案,开发者自研的可视化工具、操作平台都如雨后春笋般冒了出来。 受众不同,个人的选择就会不同;需求不同,特色的选择就会不同。但选择繁多,很多开发者和企业就会头疼:有数据可视化的需求,但工具到底该如何选择? AntV-G2是阿里巴巴2018年推出的开源项目,是一套基于可视化编码的图形语法,具有高度的易用性和扩展性。无需关注繁琐的实现细节,一条语句即可构建出各种各样的可交互统计图表。它具备以下特性: 简单、易用:从数据出发,仅需几行代码就能轻松获得想要的图表展示效果完备的可视化编码:以数据驱动,提供从数据到图形的完整映射强大的扩展能力:任何图表,都可以基于图形语法灵活绘制,满足无限创意作为一个非常全面的图表库,AntV G2库有折线图、柱状图、条形图、雷达图、箱体图、面积图、饼图、热力图、仪表盘… …几乎满足了所有基本的图表类需求。 另外,G2还是一个使用WebGL/canvas技术实现的基础图表库,因此既可以在原生js环境下使用,也可以使用任意的js框架。基于G2封装的组件框架有BizCharts和Viser,所以如果使用angular、react、vue的话可以直接使用其封装的组件,和自行动手封装G2组件是一样的效果。 G2的构成一个可视化框架需要四部分: 数据处理模块,对数据进行加工的模块,包括一些数据处理方法。例如:合并、分组、排序、过滤、计算统计信息等图形映射模块,将数据映射到图形视觉通道的过程。例如:将数据映射成颜色、位置、大小等图形展示模块,决定使用何种图形来展示数据,点、线、面等图形标记辅助信息模块,用于说明视觉通道跟数据的映射关系,例如:坐标轴、图例、辅助文本等 在数据处理模块上,dataSet主要通过state状态管理多个dataview视图,实现多图联动,或者关联视图。dataView则是对应的是每一个数据源,通过connector来接入不同类型的数据,通过tranform进行数据的转换或者过滤。最后输出我们理想的数据,dataSet是与g2分离的,需要用到的时候可以加载;在图形映射模块上,度量 Scale,是数据空间到图形空间的转换桥梁,负责原始数据到 [0, 1] 区间数值的相互转换工作,从原始数据到 [0, 1] 区间的转换我们称之为归一化操作。我们可以通过chart.source或者chart.scale('field', defs)来实现列定义,我们可以在这对数据进行起别名,更换显示类型(time,cat类型等);辅助信息,就是标记数据,方便理解数据;图形展示chart图表是一个大画布,可以有多个view视图,geom则是数据映射的图形标识,就是指的点,线,面,通过对其操作,从而展示图形。大体步骤如下: G2 经典新生目前AntV-G2已更新到3.4版本。通过这次升级,G2往经典的“图形语法”理论注入了新的生命,为大家带来“交互语法” — 一套简洁高效的交互式可视化解决方案。同时,G2的底层渲染进行了升级,实现 SVG 和 Canvas 自由切换。 简洁灵活的交互语法G2将经典的图形语法理论扩展为“交互语法”,一方面开放 220+ 种交互事件,支持定制最小粒度的图表元素交互,另一方面封装了各类复杂的、常用的交互场景,使丰富灵活的图表交互仅需一行代码实现。 渲染引擎自由切换G2的绘图引擎开始支持 SVG 和 Canvas 双引擎,以适应更多业务场景。并在拾取、动画管线、碰撞检测等方面进行了优化,G2的绘图能力变得更自由、更流畅。 两种引擎在不同场景的性能对比 256+58的试炼通过256 plots计划和58+业务模板计划,来向用户提供更丰富的场景,也由此检验G2图表的数据表达能力。 通过256 plots计划,G2挑战了d3.js、R语言社区等经典图表绘制,检验并刺激了G2框架图形能力的更新。 58+业务模板源自真实的业务,由基础的线、柱、饼图表改造而起,进而辐射到分面、迷你图等更复杂的场景,能更好的帮助用户找到理想的可视化解决方案。 DataV数据可视化AntV-G2功能虽然强大,但对于需要开箱即用、直接适用业务的企业而言,距离可视化还缺少一个成熟的产品。幸运的是,阿里云.DataV数据可视化完美承担了这样的一个角色。DataV只需通过拖拽式的操作,使用数据连接、可视化组件库、行业设计模板库、多终端适配与发布运维于等功能,就能让非专业的人员快速地将数据价值通过视觉来传达。 DataV具有丰富的图表库,并外接有国内两大第三方图表组件库——Echarts和今日的主角:AntV-G2。在强大的图表库支持下,DataV可以制作出丰富多样的可视化页面,随心所欲自由搭配图表来做组合。 本文作者:数据智能小二原文链接 本文为云栖社区原创内容,未经允许不得转载。

June 10, 2019 · 1 min · jiezi

做可交互的统计图表这套图形语法不容错过

选好可视化“一图胜千言”,是最直观的数据可视化魅力。以图表来传达和沟通信息,其效率远超枯燥乏味的数据表达。 有需求就有市场。数据可视化崭露头角后,各个厂商出备的产品、解决方案,开发者自研的可视化工具、操作平台都如雨后春笋般冒了出来。 受众不同,个人的选择就会不同;需求不同,特色的选择就会不同。但选择繁多,很多开发者和企业就会头疼:有数据可视化的需求,但工具到底该如何选择? AntV-G2是阿里巴巴2018年推出的开源项目,是一套基于可视化编码的图形语法,具有高度的易用性和扩展性。无需关注繁琐的实现细节,一条语句即可构建出各种各样的可交互统计图表。它具备以下特性: 简单、易用:从数据出发,仅需几行代码就能轻松获得想要的图表展示效果完备的可视化编码:以数据驱动,提供从数据到图形的完整映射强大的扩展能力:任何图表,都可以基于图形语法灵活绘制,满足无限创意作为一个非常全面的图表库,AntV G2库有折线图、柱状图、条形图、雷达图、箱体图、面积图、饼图、热力图、仪表盘… …几乎满足了所有基本的图表类需求。 另外,G2还是一个使用WebGL/canvas技术实现的基础图表库,因此既可以在原生js环境下使用,也可以使用任意的js框架。基于G2封装的组件框架有BizCharts和Viser,所以如果使用angular、react、vue的话可以直接使用其封装的组件,和自行动手封装G2组件是一样的效果。 G2的构成一个可视化框架需要四部分: 数据处理模块,对数据进行加工的模块,包括一些数据处理方法。例如:合并、分组、排序、过滤、计算统计信息等图形映射模块,将数据映射到图形视觉通道的过程。例如:将数据映射成颜色、位置、大小等图形展示模块,决定使用何种图形来展示数据,点、线、面等图形标记辅助信息模块,用于说明视觉通道跟数据的映射关系,例如:坐标轴、图例、辅助文本等 在数据处理模块上,dataSet主要通过state状态管理多个dataview视图,实现多图联动,或者关联视图。dataView则是对应的是每一个数据源,通过connector来接入不同类型的数据,通过tranform进行数据的转换或者过滤。最后输出我们理想的数据,dataSet是与g2分离的,需要用到的时候可以加载;*  在图形映射模块上,度量 Scale,是数据空间到图形空间的转换桥梁,负责原始数据到 [0, 1] 区间数值的相互转换工作,从原始数据到 [0, 1] 区间的转换我们称之为归一化操作。我们可以通过chart.source或者chart.scale('field', defs)来实现列定义,我们可以在这对数据进行起别名,更换显示类型(time,cat类型等); *  辅助信息,就是标记数据,方便理解数据; *  图形展示chart图表是一个大画布,可以有多个view视图,geom则是数据映射的图形标识,就是指的点,线,面,通过对其操作,从而展示图形。 大体步骤如下: G2 经典新生目前AntV-G2已更新到3.4版本。通过这次升级,G2往经典的“图形语法”理论注入了新的生命,为大家带来“交互语法” — 一套简洁高效的交互式可视化解决方案。同时,G2的底层渲染进行了升级,实现 SVG 和 Canvas 自由切换。 简洁灵活的交互语法 G2将经典的图形语法理论扩展为“交互语法”,一方面开放 220+ 种交互事件,支持定制最小粒度的图表元素交互,另一方面封装了各类复杂的、常用的交互场景,使丰富灵活的图表交互仅需一行代码实现。 渲染引擎自由切换 G2的绘图引擎开始支持 SVG 和 Canvas 双引擎,以适应更多业务场景。并在拾取、动画管线、碰撞检测等方面进行了优化,G2的绘图能力变得更自由、更流畅。 两种引擎在不同场景的性能对比 256+58的试炼 通过256 plots计划和58+业务模板计划,来向用户提供更丰富的场景,也由此检验G2图表的数据表达能力。 通过256 plots计划,G2挑战了d3.js、R语言社区等经典图表绘制,检验并刺激了G2框架图形能力的更新。 58+业务模板源自真实的业务,由基础的线、柱、饼图表改造而起,进而辐射到分面、迷你图等更复杂的场景,能更好的帮助用户找到理想的可视化解决方案。 DataV数据可视化AntV-G2功能虽然强大,但对于需要开箱即用、直接适用业务的企业而言,距离可视化还缺少一个成熟的产品。幸运的是,阿里云.DataV数据可视化完美承担了这样的一个角色。DataV只需通过拖拽式的操作,使用数据连接、可视化组件库、行业设计模板库、多终端适配与发布运维于等功能,就能让非专业的人员快速地将数据价值通过视觉来传达。 DataV具有丰富的图表库,并外接有国内两大第三方图表组件库——Echarts和今日的主角:AntV-G2。在强大的图表库支持下,DataV可以制作出丰富多样的可视化页面,随心所欲自由搭配图表来做组合。 本文作者:数据智能小二阅读原文 本文为云栖社区原创内容,未经允许不得转载。

June 6, 2019 · 1 min · jiezi

使用EMR-Spark-Relational-Cache跨集群同步数据

背景Relational Cache是EMR Spark支持的一个重要特性,主要通过对数据进行预组织和预计算加速数据分析,提供了类似传统数据仓库物化视图的功能。除了用于提升数据处理速度,Relational Cache还可以应用于其他很多场景,本文主要介绍如何使用Relational Cache跨集群同步数据表。通过统一的Data Lake管理所有数据是许多公司追求的目标,但是在现实中,由于多个数据中心,不同网络Region,甚至不同部门的存在,不可避免的会存在多个不同的大数据集群,不同集群的数据同步需求普遍存在,此外,集群迁移,搬站涉及到的新老数据同步也是一个常见的问题。数据同步的工作通常是一个比较痛苦的过程,迁移工具的开发,增量数据处理,读写的同步,后续的数据比对等等,需要很多的定制开发和人工介入。基于Relational Cache,用户可以简化这部分的工作,以较小的代价实现跨集群的数据同步。下面我们以具体示例展示如何通过EMR Spark Relational Cache实现跨集群的数据同步。 使用Relational Cache同步数据假设我们有A,B两个集群,需要把activity_log表的数据从集群A同步到集群B中,且在整个过程中,会持续有新的数据插入到activity_log表中,A集群中activity_log的建表语句如下: CREATE TABLE activity_log ( user_id STRING, act_type STRING, module_id INT, d_year INT)USING JSONPARTITIONED BY (d_year)插入两条信息代表历史信息: INSERT INTO TABLE activity_log PARTITION (d_year = 2017) VALUES("user_001", "NOTIFICATION", 10), ("user_101", "SCAN", 2)为activity_log表建一个Relational Cache: CACHE TABLE activity_log_syncREFRESH ON COMMITDISABLE REWRITEUSING JSONPARTITIONED BY (d_year)LOCATION "hdfs://192.168.1.36:9000/user/hive/data/activity_log"AS SELECT user_id, act_type, module_id, d_year FROM activity_logREFRESH ON COMMIT表示当源表数据发生更新时,自动更新cache数据。通过LOCATION可以指定cache的数据的存储地址,我们把cache的地址指向B集群的HDFS从而实现数据从集群A到集群B的同步。此外Cache的字段和Partition信息均与源表保持一致。 在集群B中,我们也创建一个activity_log表,创建语句如下: CREATE TABLE activity_log ( user_id STRING, act_type STRING, module_id INT, d_year INT)USING JSONPARTITIONED BY (d_year)LOCATION "hdfs:///user/hive/data/activity_log"执行MSCK REPAIR TABLE activity_log自动修复相关meta信息,然后执行查询语句,可以看到在集群B中,已经能够查到之前集群A的表中插入的两条数据。 ...

June 6, 2019 · 1 min · jiezi

蚂蚁金服首席架构师何昌华开源SQLFlow是牛刀初试实时大数据系统才是未来基石

开源 SQLFlow,反哺业界,同时小小秀出 AI 肌肉。 这就是蚂蚁金服近日开源首个将 SQL 应用于 AI 引擎项目 SQLFlow 后,业界给出的反应。 SQLFlow,把艰深的 AI 与简单的 SQL 结合起来,大大简化了数据工程师使用 AI 技术的门槛。 而研发出 SQLFlow 的,正是蚂蚁金服计算存储首席架构师何昌华带领下的 AI Infra 团队。 何昌华斯坦福博士毕业,先在 Google 总部工作 7 年,赢得过公司最高技术奖项,其后又在独角兽 Airbnb 工作 2 年,负责后台系统的应用架构。 2017 年 5 月,他正式加盟蚂蚁金服,担任计算存储首席架构师,并在 2018 年入选了第 14 批国家“千人计划”专家。 在蚂蚁金服,何昌华的工作是开发新一代计算引擎,搭建金融型数据智能平台。 而 SQLFlow,就是计算引擎主线上的结晶之一。 不过对何昌华来说,世界正在巨变,他还要带队探索一些没人做成的事情。 比如全实时的大数据智能系统。 未来技术基石大数据的概念,最早来自于搜索引擎行业,因为搜索引擎面对的是人类在互联网上留下的爆炸性增长的庞大数据。 2010 年底,谷歌宣布新一代搜索引擎“咖啡因”正式上线,这项技术的革命性在于,任何时刻,世界上的任何网页发生了变化,都可以实时地添加到索引中,用户也可以实时地搜索到,解决了传统搜索引擎的延时问题。 何昌华当时正是咖啡因开发团队的核心技术负责人之一。 他解释,“咖啡因所实现的最核心的功能,就是实时。” 而现在何昌华在蚂蚁金服工作的目标,同样是搭建一个“完全实时”的大数据处理系统,或称之为大数据智能平台。由于线下生活场景的多样性和复杂性,这是个比构建实时搜索更有挑战性的任务。 他认为,这将成为未来技术的基石。 对于计算机来说,实时就是在发出请求到返回响应之间的延迟尽量小,对于大数据处理系统来说,这还意味着从数据生产到消费的延迟尽可能低,所有这些都意味着计算速度和能力的提升。 此前常用的大数据计算模型 MapReduce,对数据的处理是“分片式”的,数据的片与片之间有边界的概念,这种批处理的模式不可避免地会带来延时问题。 以搜索的场景为例,假如以天为时间单位对数据进行批处理,那就意味着今天更新的网页,用户明天才能搜索到,调高处理的频率可以部分解决问题,一天两次、一天四次、两小时一次…… 虽然能逐步接近“准实时”,但成本也会急剧上升。 要实现真正的实时,就必须打破这种批处理的边界,让数据处理的过程像水流一样,随来随算,随时反馈。 这也催生了后来流式计算引擎的蓬勃发展。 而在何昌华看来,除了快,“实时系统”还有两层重要含义。 第一是 OLTP(联机事务处理)和 OLAP(联机分析处理)的融合。 在以往的观念里,OLTP 对实时性的要求高,OLAP 对时效性的要求不那么高。 ...

June 4, 2019 · 1 min · jiezi

Pandas时序数据处理入门

作为一个几乎每天与时间序列数据打交道的人员,我发现panda Python包在时间序列的操作和分析方面有强大优势。 这篇关于panda时间序列数据处理的基本介绍可以带你入门时间序列分析。本文将主要介绍以下操作: 创建一个日期范围处理时间戳数据将字符串数据转换为时间戳在数据框中索引和切片时间序列数据重新采样不同时间段的时间序列汇总/汇总统计数据计算滚动统计数据,如滚动平均值处理丢失数据了解unix/epoch时间的基础知识了解时间序列数据分析的常见陷阱接下来我们一起步入正题。如果想要处理已有的实际数据,你可能考虑从使用panda read_csv将文件读入数据框开始,然而在这里,我们将直接从处理生成的数据开始。 首先导入我们将会使用到的库,然后用它们创建日期范围 import pandas as pdfrom datetime import datetimeimport numpy as npdate_rng = pd.date_range(start='1/1/2018', end='1/08/2018', freq='H')这个日期范围的时间戳为每小时一次。如果我们调用date_rng,我们会看到如下所示: DatetimeIndex(['2018-01-01 00:00:00', '2018-01-01 01:00:00', '2018-01-01 02:00:00', '2018-01-01 03:00:00', '2018-01-01 04:00:00', '2018-01-01 05:00:00', '2018-01-01 06:00:00', '2018-01-01 07:00:00', '2018-01-01 08:00:00', '2018-01-01 09:00:00', ... '2018-01-07 15:00:00', '2018-01-07 16:00:00', '2018-01-07 17:00:00', '2018-01-07 18:00:00', '2018-01-07 19:00:00', '2018-01-07 20:00:00', '2018-01-07 21:00:00', '2018-01-07 22:00:00', '2018-01-07 23:00:00', '2018-01-08 00:00:00'], dtype='datetime64[ns]', length=169, freq='H')我们可以检查第一个元素的类型: type(date_rng[0])#returnspandas._libs.tslib.Timestamp让我们用时间戳数据的创建一个示例数据框,并查看前15个元素: df = pd.DataFrame(date_rng, columns=['date'])df['data'] = np.random.randint(0,100,size=(len(date_rng)))df.head(15) ...

May 10, 2019 · 2 min · jiezi

选择阿里云数据库HBase版十大理由

根据Gartner的预计,全球非关系型数据库(NoSQL)在2020~2022预计保持在30%左右高速增长,远高于数据库整体市场。 阿里云数据库HBase版也是踏着技术发展的节奏,伴随着NoSQL和大数据技术的兴起和发展,从2010年开始研究和发展。时光荏苒,日月如梭,转眼九年时间,在阿里云上直接开放提供服务也有1年多时间,并在去年的12月份全新发布X-Pack,将单一的HBase演进到一个完整的数据处理平台的能力。我们注意到还有很多同学和客户不清楚HBase X-Pack是什么,什么场景下合适选择HBase X-Pack。 首先我们先来看下HBase X-Pack的定位: HBase X-Pack是基于HBase及HBase生态构建的 低成本一站式数据处理平台。HBase X-Pack支持:HBase API(包括RestServerThriftServer)、关系Phoenix SQL、时序OpenTSDB、全文Solr、时空GeoMesa、图HGraph、分析Spark on HBase,是阿里云首个支持多模式的分布式数据库,且协议100%兼容开源协议。HBase X-Pack实现数据从处理、存储到分析全流程闭环,让客户用最低成本实现一站式数据处理。接下来一起来梳理一下阿里云HBase X-Pack关键能力,一起看看选择阿里云HBase X-Pack的十个理由。 理由一:一体化数据处理平台,提供一站式能力企业数字化转型时代,业务越来越复杂,需要一个平台可以提供一站式处理能力。传统大数据各个组件非常多,各个组件分层发展,给扩展性带来非常大的便利,但同时也引入了非常高的技术门槛,云HBase X-Pack通过集成Spark,Solr,HBase,时序,时空,图等组件,打通各个组件之间的数据同步,通过数据工作台提供统一一体化交互式的操作体验,实现计算、存储、分析、检索、机器学习五位一体的一站式能力,极大的降低了使用门槛,轻松上手,同时提供全托管的服务,避免各种复杂的运维和技术坑。 云HBase X-Pack详细的能力可以访问云HBase的帮助,里面有各个能力详细的介绍: 理由二:深厚的技术积累企业决策选择云服务,最核心的一个因素就是降低TCO,最看重的核心因素就是背后的技术力量,服务能力。阿里云HBase X-Pack经过9年的发展,积累强大的专家团队,目前拥有国际认证7个committer,4个PMC,拥有国内独一无二的技术实力。我们拥有集团超过万台的服务经验,对各种异常场景,数据可靠性,可用性,性能,数据迁移各个方面有全套的服务和工具。 理由三:独家企业版本,以及最新2.0版本阿里云HBase提供的版本是经过、千锤百炼的企业版本,在稳定性和性能上远胜于开源的版本,并且全球首家提供最新2.0版本。关于阿里云HBase发展历程,可以看这里详细介绍:https://yq.aliyun.com/articles/601531。阿里云HBase和开源版本的关键区别,可以查看:https://help.aliyun.com/document_detail/49502.html。 理由四:开发效率最高的数据库Gartner在2017年数据库厂商推荐报告中就明确指出多模是发展趋势阿里云新发布X-Pack更是将多模推上新高度,KV的基础上,同时支持时序、时空、图、文档等多种数据模型。我们知道,大数据时代,业务多样性是大数据的本质之一,强制使用单一模型只会降低生产效率,HBase X-Pack提供KV、SQL、时序、时空、图丰富的多模多模能力,帮助客户可以根据不同的业务选择不同的数据处理模型,支持业务灵活选择,从而实现最高效率的开发和生产。 理由五:做成本最低的数据库HBase诞生于Google的bigtable论文,天然是为了存储海量互联网数据而诞生,低成本能力是其天然的属性。云HBase X-Pack在继承HBase自身能力的同时,为了给客户节省成本做了很多努力。体现在内核,整体方案各个方面,主要有: 云HBase版本的内核是经过优化的,性能平均高出自建版本30%~300%:如果对性能有要求的场景,就可以节省更少的CPU资源,获取更大的效果,具体可以参考https://yq.aliyun.com/articles/198654。齐全的产品形态,满足各种业务场景,提供最高性价比:HBase X-Pack支持单节点,集群版本,跨可用区/跨地域双集群版本,满足用户从测试,生产环境,高可用各种使用环境,平衡能力和成本,提供高性价比的选择,具体可以参考https://help.aliyun.com/document_detail/71538.html。提供数据全生命周期管理功能,数据冷热分离,存储成本下降3.5倍:很多场景里面,数据有冷热的需求,我们提供不同的存储介质,包括OSS,本地盘,云盘,高性能云盘,帮助客户实现最佳的存储成本,详细的可以看下https://yq.aliyun.com/articles/646983。客户基于ECS自建,存储选择云盘,hdfs副本数天然是3副本:HBase服务通过和云盘深度集成2副本就可以同样的性能和可靠性。在存储上天然节省1/3,详细的可以访问https://yq.aliyun.com/articles/646983。全托管服务,提供代维,99.9%的SLA:运维在日常数据库工作中占了很大的比重,而且数据库的稳定性关系到整个系统,牵一发和动全身,云HBase X-Pack提供全托管的服务,给客户节省运维费用,以及极大的避免故障带来的损失。提供一体化的方案节省成本:云HBase X-Pack通过把各个组件深度集成和融合,通过组合各个产品之间的能力,给很多场景带来增效,解决了性能瓶颈的同时,带来成本的下降。这里举2个典型的例子:很多人工智能,多媒体场景,在线教育里面,大量图片、小视频文件。传统的使用方法都是存在OSS里面,OSS天然并发和时延处理能力有限,同时读写都是要收费的,读写次数越多,费用越高,使用HBase X-Pack没有这部分的费用,可以解决性能的瓶颈的同时,带来综合成本的降低。 碰到非结构化数据查询的诉求时,大家一般会想起ES。ES适合文本查询,入库会比较差(一般就几百条/S),查询函数也有限。HBase X-Pack通过支持Solr完全补齐了文本查询的能力。同时Phoneix+solr组合结合了HBase和搜索的两者的优势,在吞吐和并发上有优势。对SQL的易用性也有优势。尤其是在新零售等场景,一张表中混杂结构化字段和非结构化字段,可以根据需求,自动创建索引,融合两者的优势。倒排膨胀率很高,入库会极速下降。大部分客户只是部分字段有模糊查询的需求,ES强制所有的用单一技术。Phoneix非常适合并发高的查询,条件不多。搜索技术补充了索引技术,适合各种条件。通过结合phoneix+solr成功平滑查询和存储性能,提高性能的同时,存储成本也下降几倍,非常适合结构化+非结构化混合的场景。 理由六:力争做最好用的数据处理平台HBase主要提供在线查询能力,沉淀下来的数据需要使用Spark来做复杂分析,HBase X-Pack中的Spark为了让用户更便捷的做数据处理,产品上面提供了以下能力: 1)数据工作台:支持交互式、作业管理、工作流、资源管理、元数据管理,从测试、开发、上线一站式开发体验2)spark内置connector:一键关联hbase、mongo、redis、rds等集群,免去调试的烦恼,更加便捷的分析其他数据库的数据3)支持多语言:可以选择习惯的语言进行编程4)可维护性:支持小版本升级、监控、报警,免去Spark集群维护5)离线数仓能力:一键归档在线库rds、polardb、mongo、hbase、cassandra数据到Spark数仓6)成本:集群默认存储为集群版本HDFS,同时支持数据存储在oss降成本 使用HBase X-Pack Spark能够构建业界成熟的一体化数据处理平台,支撑推荐、风控、离线数仓、实时处理及计算、大数据运营、日志分析、去oracle复杂分析等业务场景: 理由七:数据可靠性作为重中之重对大多数公司来说数据的安全性以及可靠性是非常重要的,如何保障数据的安全以及数据的可靠是大多数数据库必须考虑的。2016 IDC的报告表示数据的备份(data-protection)和数据恢复(retention)是NoSQL的最基础的需求之一,阿里云NoSQL数据库也一直把怎么保障客户的数据安全放在首位。以云HBase为例,传统数据库备份恢复的能力都是TB级别,在交易等场景下面是足够的,但面向大数据场景就捉襟见肘了。云HBase通过垂直整合高压缩、内核级优化等能力,将备份恢复的量级成功推高百倍以上,做到 百TB级别甚至更高 ,让客户在大数据量场景下也无后顾之忧。云HBase支持全量(备份集)备份、全量(备份集)恢复、增量(实时)备份、增量(时间点)恢复完整备份恢复能力。 理由八:单集群3个9高可用,双集群4个9高可用HBase通过内核加固,一系列自动运维修复工具,单集群可以提供3个9的可用性,为了满足很多场景下面更高可用性的要求,云HBase支持跨可用区或者跨地域双集群主备同步,可以让多个HBase集群保持同步关系。在一个集群出现故障的时候,迅速地将业务切换至另外一个集群从而避免故障。HBase主备之间数据的同步基于异步链路实现,遵循最终一致性协议,典型的主备同步延迟在200ms左右。 理由九:大量场景验证,久经考验阿里云HBase从10年上线以来,在阿里集团内部久经考验,超过12000台服务器,单集群超过2000台的规模应用。云HBase自发布以来,通过丰富的能力,优秀的全托管能力,全面超越同类产品的技术能力得到金融、社交、多媒体、新零售、车联网网、制作业、政企等等多个行业,多上千个客户的信赖,积累了大量的使用经验。欢迎我们的新老客户访问首页获取更多的信息: 理由十:提供不停机迁移服务,让自建迁移无忧客户已经使用ECS自建服务,想使用云HBase服务,最担心的应该还是迁移过程中对业务的影响,技术团队充分考虑这一点,提供免费的不停机迁移服务,对在线业务0影响,数据迁移一行不丢。当前业界有能力提供不提供不停机迁移HBase服务的仅此一家。 本文简单梳理了阿里云HBase X-Pack十大理由,希望能对大家理解云HBase有一个帮助,另外也给您选型做一个充分的参考。当能我们还有很多改进的空间,我们还在成长的路上持续努力,也欢迎大家联系我们提出宝贵的意见,最后福利,欢迎使用云HBase X-Pack版本,针对首次购买的用户推出了云数据库HBase单节点独享规格,欢迎大家申请试用:https://promotion.aliyun.com/ntms/act/hbasefree.html 本文作者:所在jason阅读原文 本文为云栖社区原创内容,未经允许不得转载。

April 24, 2019 · 1 min · jiezi

基于Tablestore管理海量快递轨迹数据架构实现

快递轨迹管理对于一个快递公司,在全国范围内有着大量的快递点、快递员、运输车辆以及仓储中心。而快递自产生后,就会在这些地点、人物之间流转。因而,一套完善的快递管理追踪系统是快递公司的重要管理工具;用户通过平台客户端下单后,产生唯一的快递单号作为唯一身份标识。快递除了订单号,还会有很多属性信息,如:邮寄人、邮寄人手机、邮寄人地址、收件人、快递类型等信息。生成快递订单后,用户的邮寄物品才会成为“快递”。快递公司配合扫码机器,将快递的流转事件、地点、时间等信息不定期推送至系统。快递流转信息不仅可以是简单的量化数据,也可以是描述性文字、地理位置等特殊信息。系统将流转信息记录成快递的监控数据,同时修改快递状态、实时位置等。直至快递送达收件人手中,结束快递生命周期。通过系统,用户可以管理自己的历史邮寄单列表、收件列表,掌握自己邮寄中的快递轨迹。快递公司也可以查询、修改快递信息、追踪快递时效,并借助海量轨迹监控数据,掌握快递产生、收件的高频路线,在高频位置铺设更多的基础设施、转移调度快递员;功能需求面向用户:1、用户在线下单生成快递单,等候快递员上门取件;2、管理历史订单列表,了解快递明细;3、追踪特定快递周转状态、运送轨迹;面向平台:1、借助扫码器,实现快递周转事件采集、存储;2、统计、查询所有快递订单,实现全订单的管理:CRUD;3、掌握所有邮寄中快递的实时位置;4、掌握任意一个订单的周转状态、运送轨迹;5、基于历史快递数据,分析快递时效;6、方便掌握高频地域、路线,为增设基础设施、快递员提供依据;等等…系统样例,如下所示:官网控制台地址:项目样例实现方案MySQL方案与难点通常,用户会选用MySQL作为方案数据库,因为MySQL作为数库在查询、分析等功能上有优势,用户创建两个表:订单表、事件追踪表实现对快递数据的存储。但是快递场景有几个强需求:第一、需要有强大的查询、统计能力,实现快递单的管理;第二、对于海量快递,有着高并发写入需求,对写入性能要求较高;第三、数据持续膨胀,但历史快递订单、事件数据多为冷数据,存储成本需要尽可能低;第四、数据未来挖掘潜在价值较高,需要有较好的计算生态;而MySQL方案在面对第二、第三个强需求时,劣势凸显,海量并发、不断的数据膨胀、存储成本高一直以来都是关系型数据库的痛点;表格存储方案选择表格存储有以下优势:其一、表格存储的多元索引(SearchIndex)功能轻松满足用户的多维查询、GEO检索、统计等功能需求;其二、基于LSM tree打造的分布式NoSQL数据库,轻松支持海量高并发读、写,零运维轻松应对数据量的不断膨胀,理论上无上限。其三、表格存储按量计费,提供容量型、高性能型两种实例,容量型对冷数据更适宜,提供了更低存储成本。其四、更重要的,表格存储拥有较为完善的计算生态,提供全、增量通道服务,提供流计算、批计算一体的计算体系,对未来监控数据价值挖掘提供渠道。表格存储在时序场景需求的技术点上拥有极高的匹配,而基于时序场景打造的Timestream模型更是将时序场景通用功能,封装成易用的场景接口,使用户更容易的基于表格存储,根据自身需求设计、打造不同特点的轨迹追踪系统;数据结构设计基于快递的时序,将快递的属性信息作为meta数据,而快递的周转路径、状态、位置等则为data数据,下面对两类数据做简单介绍。快递元数据meta数据管理着快递的属性信息,支持指标、标签、属性、地理位置、更新时间等参数,模型会为所有属性创建相应的索引,提供多维度条件组合查询(包含GEO查询)。其中Identifier是时间线的标识,包含两部分:name部分(监控指标标识)、tags部分(固有不可变参数集合)。在快递场景中,用户通常是基于快递单号直接定位快递,因而tags使用空的。而属性信息则存储快递的邮寄人信息、收件人信息、邮寄起/止地址等,location字段,用于最新位置追踪,可不定期根据产生新的状态周转数据时更新。快递轨迹数据data数据记录着快递的状态周转信息,主要为量化数据、地理位置、文字表述等任意类型。data数据按照+有序排列,因而同一快递的所有数据物理上存在一起,且基于时间有序。这种数据存储方式,极大的提升了时间线的查询效率。对应到快递轨迹,监控数据主要记录了:【who】do【something】@【where】with the location【geo】以及联系方式等。读写接口使用介绍写数据写接口根据数据类型分为两类:meta写入(新增快递)、data写入(快递周转数据)新增快递:当用户通过系统直接下快递单后,产生唯一订单号,加上用户填写的快递单信息组成必要的凯迪数据。此时,就会生成一个时间线,产生一个meta数据;快递周转:当快递发生取件、运输周转、派送、取件是,产生的状态转变数据时,就会产生一条追踪数据,通过data数据的写接口不定期的写入;读数据与写数据一样,针对两类数据提供了两类读接口:meta读取(快递查询)、data读取(查询快递轨迹)查询快递:根据快递号、寄件人手机、收件人手机等信息,获取对应快递的列表,掌握所有快递的最新动态;查询快递轨迹:基于单个meta的Identifier,获取该快递从产生到结束整个生命周期内的轨迹周转数据,可以通过列表、地图轨迹展示等方式,直观的了解快递的周转过程;方案核心代码SDK与样例代码SDK使用:时序模型Timestream模型集成于表格存储的SDK中,目前已在4.11.0版本中支持;<dependency> <groupId>com.aliyun.openservices</groupId> <artifactId>tablestore</artifactId> <version>4.11.0</version></dependency>代码开源:https://github.com/aliyun/tablestore-examples/tree/master/demos/MailManagement建表准备在创建完成实例后,用户需要通过时序模型的sdk创建相应的meta表(快递元数据)、data表(快递周转数据):private void init() { AsyncClient asyncClient = new AsyncClient(endpoint, accessKeyId, accessKeySecret, instance); //快递抽象Timestream TimestreamDBConfiguration mailConf = new TimestreamDBConfiguration(“metaTableName”); mailDb = new TimestreamDBClient(asyncClient, mailConf);}public void createTable() { mailDb.createMetaTable(Arrays.asList(//自定义索引 new AttributeIndexSchema(“fromMobile”, AttributeIndexSchema.Type.KEYWORD), new AttributeIndexSchema(“fromName”, AttributeIndexSchema.Type.KEYWORD), new AttributeIndexSchema(“toMobile”, AttributeIndexSchema.Type.KEYWORD), new AttributeIndexSchema(“toName”, AttributeIndexSchema.Type.KEYWORD), new AttributeIndexSchema(“toLocation”, AttributeIndexSchema.Type.GEO_POINT) )); mailDb.createDataTable(“dataTableName”);}写数据数据写入主要分两部分,meta表创建新快递、data表采集快递周转信息创建快递单(meta表写入)//metaWriter对应meta表,提供读、写接口TimestreamMetaTable mailMetaWriter = mailDb.metaTable();//identifier作为时间线的身份标识(unique),仅含:快递单号ID,TimestreamIdentifier identifier = new TimestreamIdentifier.Builder(“mail-id-001”) .build();//基于identifier创建meta对象,并为meta设置更多属性,Attributes为属性参数TimestreamMeta meta = new TimestreamMeta(identifier) .addAttribute(“fromName”, whos.get(Rand.nextInt(whos.size()))) .addAttribute(“fromMobile”, “15812345678”) .addAttribute(“toName”, whos.get(Rand.nextInt(whos.size()))) .addAttribute(“toMobile”, “15812345678”) .addAttribute(“toLocation”, “30,120”);//创建新的时间线,然后写入监控数据mailMetaWriter.put(meta);采集快递周转事件(data表写入)//dataWriter分别对应data表,提供读、写接口TimestreamDataTable mailDataWriter = mailDb.dataTable(“mailDataTableName”);TimestreamMeta meta;//meta上一步已经构建//创建新的时间线,然后写入监控数据mailDataWriter.write( meta.getIdentifier(), new Point.Builder(14500000000, TimeUnit.MILLISECONDS) .addField(“who”, “张三”) .addField(“do”, “取件”) .addField(“where”, “云栖小镇”) .addField(“location”, “30,120”) .build());数据读取数据读取分为两类:快递订单多维查询(meta表读取)//reader对应meta表,提供读、写接口,此处名字为突出读功能TimestreamMetaTable metaReader = mailDb.metaTable();//构建筛选条件Filter filter = AndFilter( Name.equal(“mail-id-001”), Attribute.equal(“fromMobile”, “15812345678”));Iterator<TimestreamMeta> metaIterator = mailDb.metaTable() .filter(filter) .fetchAll();while (iterator.hasNext()) { TimestreamMeta meta = iterator.next();//deal with metas}快递轨迹追踪(data表读取)//dataWriter分别对应data表,提供读、写接口TimestreamDataTable dataReader = db.dataTable(“dataTableName”);TimestreamMeta meta;//基于已获取的meta列表,分别获取每个快递的轨迹追踪Iterator<Point> dataIterator = mailDb.dataTable(mailDataTableName) .get(meta.getIdentifier()) .fetchAll();while (iterator.hasNext()) { Point point = iterator.next();//deal with points long timestamp = point.getTimestamp(TimeUnit.MILLISECONDS);//毫秒单位时间戳 String location = point.getField(“location”).asString();//获取该点String类型的位置信息}本文作者:潭潭阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

April 18, 2019 · 1 min · jiezi

稳坐视频云行业第一,阿里云将用边缘计算开辟新赛道

“CDN竞争的上半场已结束,中国视频云市场格局已定,边缘计算将成为下半场发展的新赛道。” 4月10日,阿里云视频云总经理、边缘计算负责人朱照远在第七届“亚太内容分发大会”暨CDN峰会表示。朱照远认为,阿里云依靠齐全的产品矩阵、最优秀的技术和人才、成本和效率、服务创新,以及在视频领域的场景实践等综合优势,已经赢得了中国视频云行业竞赛的上半场胜利。据市场咨询机构计世资讯(CCWResearch)数据显示,当前中国视频云服务市场格局已逐步进入整合阶段,技术能力与资源能力使得该市场的壁垒正在形成,头部厂商所占份额越来越大。其中,阿里云视频云以市场份额42.5%成为第一大厂商,所占份额几乎为二至五名总和。而随着大数据、人工智能、物联网、5G等技术的快速发展,百亿联网设备、海量数据、超低延时等需求都对现有的云计算模式提出了挑战,边缘计算应运而生。“云计算领域累积的领先优势为我们开展边缘计算提供了足够的技术储备、丰富的实践场景以及服务经验,边缘计算的竞争是拼基础设施的成熟度、稳定性和开放性。”朱照远说。阿里云边缘计算第一层是将分布全球的边缘IDC变化为云基础设施,这个能力可以从云覆盖到用户100公里附近的位置;第二层是MEC,深入到5G通信网络;第三层是客户侧的边缘计算,通常是放在园区、政企、家庭等客户侧网络。阿里云边缘计算正在层层前移,深入每一个计算场景,直至用户的最近一公里。2016年,阿里云开始布局边缘计算;2018年3月,阿里云正式宣布战略投入边缘计算技术领域,将云计算、大数据、人工智能的优势拓展到更靠近端的边缘计算上,打造云、边、端一体化的协同计算体系。在过去一年多的时间里,阿里云先后发布了IoT边缘计算产品Link IoT Edge和边缘节点服务ENS。工业互联网的数字化智能改造、物流行业的智能园区升级、未来酒店的低成本云边一体化实施, 7000万在线的大型游戏赛事直播的完美支持,阿里云的边缘计算已在多个场景得到实施和验证,并产生了相应成效。“未来,阿里云在边缘计算领域的投入还会加大,会以融合、标准、开发、被集成的理念,持续开拓面向未来的边缘服务,期待更多行业合作伙伴、客户与阿里云同行。”朱照远说。本文作者:隽阜阅读原文本文为云栖社区原创内容,未经允许不得转载。

April 11, 2019 · 1 min · jiezi

大规模数据传输,知易行难 — 数据传输与 ETL 平台的架构演进

本文首发于 vivo 互联网技术微信公众号(https://mp.weixin.qq.com/s/EB…) 作者:周建军本文根据周建军在 2019 年 3 月 30 日 vivo 互联网技术沙龙《亿级用户的智能体验交付之路》的演讲内容整理。周建军,vivo 大数据专家。负责 vivo 一站式数据接入平台的架构设计和技术演进。SDCC 2017 深圳峰会演讲嘉宾。加入 vivo 前曾服务于腾讯数据平台部,先后参与及负责万亿级实时数据接入系统 TDBank、实时计算平台 EASYCOUNT 等系统的设计与开发。本次分享主要分为四部分:vivo 大数据平台架构概览数据采集的需求与挑战平台架构演进过程未来规划与展望一、vivo 大数据平台架构概览vivo 大数据平台是做什么的?支撑了哪些业务?以及如何支撑这些业务?我们先来看一下 vivo 大数据平台架构的整体概览。从图中可以看出,vivo 大数据平台的定位是为公司的各个业务线提供最基础的数据服务。目前支撑的业务包括互联网业务、手机业务相关的十几条大的业务线。支撑的业务主要依赖以下四个平台:一是数据生产平台,主要做数据的采集和数据的清洗,经过采集和清洗入库到存储系统,提供给数据开发人员使用。二是存储计算平台,为公司提供统一的存储计算服务。三是数据开发平台,主要给数据开发、分析人员提供数据的查询和分析的入口。四是运营维护平台,是为整个大数据平台提供物理资源管理、基础监控等基础能力的运维服务。我主要负责数据生产平台,接下来详细介绍下 vivo 的数据生产平台。如何定义数据生产呢?就我们自己而言,vivo 数据生产平台是用户与产品之间通过数据进行交互的一个桥梁。我们的业务每天产生大量的数据,数据来源主要有公网手机、App 和内部业务。数据很有价值,后续的数据应用可以基于这些数据实时发现可能存在的风险;通过数据还可以形成运营报表以分析产品运营的情况;同时也可以对手机用户做行为分析,提供画像给产品,让产品更好地了解用户和满足用户需求。既然数据这么重要,如何保证数据能够快速稳定地触达到数据分析系统呢?这里面就有一个很重要的数据生产平台。数据生产平台提供了多种数据接入方式,比如提供消息、埋点、日志等多种方式收集,然后清洗入库以供数据开发使用。那么,现在我们的数据生产平台的数据规模如何呢?目前每天采集的数据量大概是 90 TB ,每天接收的数据条是 2500 亿,Agent 个数是 1.1 万 ,服务的业务线有 250+ 。二、数据采集的需求与挑战既然每天的数据这么大,那在构建数据生产平台的过程中都遇到了什么样的问题呢?接下来分享一下我们在数据采集过程中遇到的需求和挑战。很多人会觉得数据采集很容易,前面有采集的 Agent ,后面有消息中间件。在消息中间件之后有两个路径:一是通过实时数据消费;二是通过数据分拣离线分析。从这个数据采集的链路来看,的确比较简单。当我们数据较小,业务不复杂时采用这种数据采集链路是没有问题的。当时支持的规模达到 80 万/S、5000 个 Agent 。随着业务的发展,我们发现数据采集的链路逐渐不能满足需求。首先数据生产的环境发生了变化,从单个自建的机房变成多个。我们除了在自建机房上部署,还要在混合云环境部署。在环境变化的同时,业务要求数据采集除了具备高吞吐还要高可用。这时数据采集就会出现两个致命的问题:一是数据延时;二是数据丢失。比如采集链路中的网络抖动或者节点故障会导致数据采集延迟,采集延迟又会导致数据采集不及时从而引起丢失的问题。基于这些问题,我们开启了数据采集平台的架构演进之路。三、平台架构演进过程1、采集链路 0.2 版本为了解决上述提到的问题,我们的第一个版本在改造时对应于采集链路 0.2 版本。这个版本主要做了两件事:一是 Agent 通道分离,二是 Kafka 资源分离。之前我们的采集 Agent 是单通道的,后面的 Kafka 节点故障时会阻塞整个通道。同时因为是单通道,我们没有办法区分高低优业务。所以,我们将单通道变成多通道。在做多通道的同时,当某个 topic 采集出现异常,我们就直接丢弃,单通道的顺序发送问题也得到解决。这里面设置了一个 Kafka 资源分组,用以解决单通道的问题。简单来讲 Kafka 的资源分组按照业务 topic 对 broker 进行划分。比如将高优的业务划分到一组,低优业务划分到另外的组。保持高优的处于低负载状态,高优的发送速度比较快,这样我们的高优通道的发送速率就相对比较高。这样既解决了单通道顺序发送问题,数据延迟问题也得到缓解;同时还解决了业务优先级保障的问题。这种状态下,数据采集过程又逐渐暴露出了两个问题:一是数据恢复慢。因为当采集链路出现问题,我们要恢复某一部分数据该怎么做?要么是消费端 Kafka 重置;要么从 Agent 端重新采集。由于整个链路比较长,所以恢复慢。二是 Kafka 资源紧张。所有的数据都需要经过 Kafka。当 Kafka copy 比较多数据的情况下,就会对磁盘存储造成压力,它的磁盘 IO 会成为一个瓶颈。于是,我们对采集链路进行分析,发现采集链路上绝大部分在做离线分析,实时数据分析占其中很少一部分。而离线分析的数据没有必要经过整个采集路径。所以,我们对采集路径做了进一步优化,形成了采集链路 0.3 版本。2、采集链路 0.3 版本采集链路 0.3 版本解决了 实时离线分离和数据快速恢复的问题。过简单的架构图,大家可以发现我们的采集链路当中增加了一个 logpusher 组件。当我们做离线分析时可以从 Agent 端直接上传到 HDFS。logpusher 还可以实现数据快速恢复。我们要恢复 10 分钟的数据,logpusher 可以去定制,这样就形成了快速的恢复能力。大部分的离线数据不需要通过实时链路来采集,从而减少了 Kafka 的成本压力,这样实时采集链路数据量变小了,我们整个采集链路会更加快速。随着公司业务的继续发展,前面的 Agent 数量越来越多。这时,我们遇到了另外的问题,一是 Kafka 的连接数问题,在 Agent 增多的情况下,Kafka 的连接数呈现一个线性增长;二是出现数据丢失的问题,我们的业务日志是滚动删除的,如果采集数据跟不上业务的数据,这部分会被丢弃掉,对后端的数据分析而言是采集数据丢失。为了解决这些问题,采集链路演进到了 1.0 版本。3、采集链路 1.0 版本在 1.0 版本中,我们对采集链路做了大改动 ——在 Agent 与 Kafka 之间增加一个缓冲层,这里我们称之为 Bus。Bus 主要做三件事情:一是连接收敛;二是数据缓冲;三是数据路由转发。(1)连接收敛连接收敛,简单讲就是多个连接变成一个连接。为什么要这样呢?因为 Kafka 的每一个连接都会消耗 Kafka 的资源。当连接较多的情况下,Kafka 的性能会下降,数据采集速度也会下降。随着连接增多,故障连接的个数会更大。如果连接故障,就会触发 Kafka 的 rebalance,rebalance 会进一步影响采集性能。所以我们需要做连接收敛。(2)数据缓冲数据缓冲主要是解决数据丢失的问题。如何实现呢?比如说 Kafka 出现了故障,之前的版本很明显会导致 Agent 的发送速度下降。因为 Agent 发送速度赶不上数据的生产速度,那这部分的数据就滚动删除,这样数据就丢失了。如果我们在 Bus 层做一个数据的缓冲,假如说链路出现故障,那 Bus 可以用一些本地磁盘资源,将数据进行旁路存储,这样 Agent 可以正常发送。当 Kafka 稳定之后,Bus 再异步发送到 Kafka,这样也不会影响正常的实时采集链路,这就解决了数据丢失的问题。(3)数据路由转发在引入了 Bus 之后,我们同时也做了数据转发。有的数据不一定到 Kafka ,比如有的数据需要直接到 ES,用于做检索。我们通过对 Bus 配置修改来决定数据发送的地方。数据从哪里来到哪里去做成可配置的,让整个采集链路变得更加灵活。(4)部署问题引入的 Bus 应该部署在哪个地方呢?这里有两种部署方案:一种是将 Bus 和 Kafka 部署在一起,将 Agnet 跨机房部署;另一种是将 Bus 与 Agent 部署在一起,与 Kafka 跨机房部署。无论如何选择,都存在跨机房的问题。思考之后,我们采取的是第二种部署方案。因为跨机房数据传输无疑会导致 RT 增大,数据传输的吞吐量下降。为了弥补 RT 的问题,我们通常的做法是增大发送临界区 patchSize 或者数据发送 Task 的数量。我们要么在 Agent 端增加,要么在 Bus 端增加。在 Agent 端增加,对业务是有感知的,Agent 是与业务服务部署在一起的,所有我们只能在 Bus 端修改 patchSzie 与发送的任务数。因此,我们就需要选择第二种部署方案。4、小结:从 0.1 到 1.0 版本简单回顾下,采集链路从 0.1 到1.0版本,我们做了三件事情:第一是通道分离,解决了数据顺序发送、高低优通道发送问题。第二是通过 logpusher 将实时与离线采集链路分离,解决了 Kafka 存储资源浪费的问题和数据快速恢复的问题。第三是增加 Bus 层,解决了连接数收敛、数据缓冲、数据转发的问题。通过以上几个版本的演进,我们的吞吐量从最初的 80 w/s提升到 360 w/s,采集链路也算维持在一个比较稳定的状态。5、 采集链路 V2.0 架构我们曾经还遇到过核心交换机故障的问题和机房级掉电故障问题。出现这些问题会导致整个采集链路瘫痪,同时也暴露了采集链路在机房级容灾能力上的不足。基于这两个问题我们开启了采集链路 2.0。从采集链路 2.0 架构图中可以看出,我们在采集链路的各个组件上都增加了 failover 处理机制。Agent 默认将数据发往本机房的 Bus,当本机房 Bus 异常时 Agent 会将数据发送到备用的 Bus集群,后面的 Bus 也是如此。如果 Kafka 故障,Bus 具备将数据发往备用 Kafka 集群的能力,当然这个依赖于具体的配置。采集链路 2.0 除了链路层的修改之外,还增加了一个平台管控的 manager。这个 manger 主要用于数据接入管理、运营操作管控、指标监控预警及权限管控。通过 manger 将数据接入、运营操作平台化,全链路指标对账可视化。6、采集链路 V3.0经过采集链路 2.0 之后,我们的采集链路不管在接入效率还是在链路容灾能力上都显著提升。在采集链路稳定之后,接下来我们要做的就是如何将采集链路的元数据管控起来。这个就是采集链路 3.0 版本的主要工作。采集链路 3.0 主要是做数据运营。所谓数据运营就是让数据管理员知道数据是谁在生产,谁采集、谁负责、谁授权、谁消费。数据运营就是告知数据管理者数据从哪里来,到哪里去。比如这张图可以看出数据是谁负责,以及数据的上下游;接下来这张图是一个采集任务视图,显示了数据是谁在生产。到此为止,我们平台经历了三个大的版本迭代,数据生产平台具备了高吞吐的数据采集能力、机房级链路容灾能力和平台化的数据管理能力。那么接下来我们还有什么规划呢?四、未来规划与展望1、ETL 平台任务配置化和自助测试功能前面的内容主要介绍数据采集,对于数据生产平台,还有一个重要的数据清洗 ETL 平台。ETL 任务负责将 HDFS 数据按照业务需求处理并入库到 HIVE,以供后面的数据分析与数据统计。当前的 ETL 任务存在两个问题,一个是重复性编码工作,一个是 ETL 逻辑测试验证困难。基于以上两个问题 ,ETL 调度平台打算提供两个能力,一个是 ETL 任务配置自动化的能力,第二个是 ETL 任务自助测试的能力。ETL 任务配置生成,是依赖于代码动态注入,这样可以把重复的逻辑抽取,提高 ETL 任务的开发效率。ETL 任务测试能力,是让用户在上线 ETL 任务之前,可以引入少量的数据来验证 ETL 任务的逻辑,进而提高线上ETL 任务的质量。2、大数据平台内部子系统实现数据共享除了 ETL 的规划外,我们还计划将整个大数据平台打通。对于大数据平台而言主要有两种角色的用户,一种是数据分析人员,一种是数据开发人员。当数据分析人员有一个新的需求时,数据分析人员需要先设计埋点,让前端开发者按照埋点上报数据;然后数据分析人员告知数据开发人员配置数据采集任务和数据统计任务,数据开发人员配置完整之后再告知数据分析人员可以开始使用数据。在整个过程中首先是沟通成本比较高,如果数据开发者理解有偏差或者数据分析师表达不到位,都会造成采集的数据和计算的结果不满足要求;另外整个数据分析的链路太长,人为干预太多。为了解决以上问题,我们想将这几个平台打通,让平台直接做数据共享,减少人为沟通。假设有一个新的埋点需求,埋点系统自动推送到采集系统,采集系统自动创建采集任务,同时数据分析人员建立数据分析的任务后,将分析任务推送到数据开发平台生成数据开发任务。当埋点数据变更时,自动通知下游变更。整个大数据平台的变更做到自动传导与传递。通过大数据平台内部子系统直接的数据共享可以提高新的数据分析接入效率和分析任务变更的效率。以上,就是本次主题分享实录。Q & A1、我发现 Bus 基本上是通过 Flume 集群来实现的,那是不是可以直接通过 Flume 开发?答:我们的 Bus 是基于 Flume 的二次开发。我们知道 Flume 里面有几种常用的Channel:File Channel,Kafka Channel,Spillable Memory Channel;但是这几种都不能满足我们数据落盘然后异步发送的需求,落盘数据发送不影响正常采集链路的需求;另外我们需要自定义配置化的数据分发,所以我们需要对原生 flume 进行改造。2、数据分析从模型到落地,如何提供比较高效的方式?答:对于数据分析需要经历四个过程:数据的埋点、数据采集、数据开发和数据分析。这个过程中,阻碍我们整个数据分析的效率比较低的是沟通。如果数据分析人员不懂工程,而数据开发工程师不懂业务,就会导致两边沟通起来有障碍。我们在平台元数据做共享,埋点平台有新的任务时自动通知采集平台生成采集任务,这会减少人力沟通成本,提高接入效率。3、关于 Bus 节点,我想了解下你们如何设计 Bus 节点的高可用?答:这里的 Bus 是允许宕机的,如果你的 Bus 挂掉了几台,Agent 自动重连到其他的 Bus 节点。Agent 可以设置在一个时间段内做重连。比如说我们发现后面的 Bus 连接不均衡了,开启 Agent 重连,当监控连接均衡之后关闭掉重连。当然 Agent 也不能一直做重连,因为重连会对性能有影响。更多内容敬请关注 vivo 互联网技术微信公众号注:转载文章请先与微信号:labs2020 联系。 ...

April 11, 2019 · 2 min · jiezi

PB 级数据处理挑战,Kubernetes如何助力基因分析?

摘要: 一家大型基因测序功能公司每日会产生 10TB 到 100TB 的下机数据,大数据生信分析平台需要达到 PB 级别的数据处理能力。这背后是生物科技和计算机科技的双向支撑:测序应用从科研逐步走向临床应用,计算模式从离线向在线演进,交付效率越来越重要。作者李鹏,原文首发于InfoQ,《容器混合云,Kubernetes 助力基因分析》引言James Watson 和 Francis Crick 于 1953 年发现了 DNA 的双螺旋结构,从此揭开了物种进化和遗传的神秘面纱,开启了人类对数字化遗传的认知,但是人类基因奥秘却是一点点被读懂的。1956 年,一则癌症和染色体相关性的发现令整个癌症研究界震动:慢性骨髓性白血病(CML)患者的第 22 号染色体,比一般然明显短很多。二十余年后,学者们发现,9 号染色体的 Abl 基因,与 22 号染色体的 BCR 基因连到了一块,交错易位产生了一条 BCR-Abl 融合基因。BCR-Abl 蛋白一直处于活跃状态且不受控制,引发不受控的细胞分裂,从而导致癌症。也就是说,只要细胞表达 BCR-Abl 蛋白,就有血癌风险。美国着手深入研究,并成功推出了治疗慢性骨髓性白血病的新药。这,就是格列卫,也是去年《我不是药神》中被我们熟知的‘高价药’。在格列卫诞生前,只有 30% 的慢性骨髓性白血病患者能在确诊后活过 5 年。格列卫将这一数字从 30% 提高到了 89%,且在 5 年后,依旧有 98% 的患者取得了血液学上的完全缓解。为此,它也被列入了世界卫生组织的基本药物标准清单,被认为是医疗系统中“最为有效、最为安全,满足最重大需求”的基本药物之一。容器混合云如何应对基因测序的 IT 挑战基因测序在血液肿瘤领域应用的越来越广泛。根据病人的诊断结果, 血液肿瘤专科医生会选择相应的检查,比如 PCR 结合实时荧光探针技术, 来检测测 BCR-Abl 融合基因, 以诊断慢性骨髓性白血病, 也可以通过二代测序方式,SEGF(Single-end Gene Fusion)能够通过单端 NGS 测序数据检测复杂的基因融合类型。在另一面,无创产检唐氏/爱德华式筛查,近年来以高准确率和对胎儿的低风险,越来越受到国内年轻产妇的欢迎。基因公司每年都完成几十万例的 NIPT 检查,每一例的 NIPT 涉及到数百 MB+ 的数据处理,存储和报告生成。一家大型基因测序功能公司每日会产生 10TB 到 100TB 的下机数据,大数据生信分析平台需要达到 PB 级别的数据处理能力。这背后是生物科技和计算机科技的双向支撑:测序应用从科研逐步走向临床应用,计算模式从离线向在线演进,交付效率越来越重要。基因计算面临以下几方面挑战:1.数据存储:数据增长快,存储费用高,管理困难;长期保存数据可靠性难以保障;需要寻求低成本大数据量的数据压缩方式;元数据管理混乱,数据清理困难。2.分发共享:海量数据需要快速、安全的分发到国内多地及海外;传统硬盘寄送方式周期长,可靠性低;多地中心数据需要共享访问。3.计算分析:批量样本处理时间长,资源需求峰谷明显,难以规划;大规模样本的数据挖掘需要海量计算资源,本地集群难以满足;计算工作1. 3. 流流程迁移困难、线上线下调度困难、跨地域管理困难;线下弹性能力差,按需计算需求。4.安全合规:基因数据安全隐私要求极高;自建数据中心安全防护能力不足;数据合约(区块链);RAM 子账号支持。而这样看来一套完备架构方案则是必不可少的。与传统高性能计算相比,按需切分任务的需求,自动从云中申请资源,自动伸缩能力达到最小化资源持有成本,90% 以上的资源使用率,用完后自动返还计算资源。最大化资源的使用效率,最低单样本的处理成本,最快速的完成大批量样本的处理。随着基因测序业务增长,自动完成线下资源使用,和线上资源扩容。高速内网带宽,和高吞吐的存储,和几乎无限的存储空间。基因计算不同于常规的计算,对海量数据计算和存储能力都提出了很高的要求。主要通过容器计算的自动伸缩特性和阿里云 ECS 的自动伸缩能力的打通,可以大规模弹性调度云上的计算资源。通过对基因数据的合理切分,实现大规模的并行计算同时处理 TB 级别的样本数据。通过按需获取的计算能力,以及高吞吐的对象存储的使用,大幅降低了计算资源持有的成本和单个样本的处理成本。整体技术架构是云原生容器混合云,云上云下资源一体,跨地域集群统一管理。作为主要 Player,容器技术在数据分拆,数据质量控制,Call 变异提供了标准化流程化、加速、弹性、鉴权、观测、度量等能力,在另外一方面,高价值挖掘需要借助容器化的机器学习平台和并行框架对基因、蛋白质、医疗数据完成大规模线性代数计算来建立模型,从而使精准医疗能力成为现实。基因工程中的关键问题及解决方案数据迁移与传输数据迁移、数据拆分阶段百万小文件的读取对底层的文件系统压力,通过避免不必要小文件的读写提高样本的处理效率。 通过数据中心与阿里云的专线连接,实现高吞吐低延迟的数据上云以及与工作流结合的上云、校验、检测方式。而最终需要达成的目标是:在短时间内完成数十 TB 级数据的加密搬迁,确保数据传输客户端的高性能与安全性,实现并发传输、断点续传,且保有完善的访问授权控制。基因计算典型任务:增强型工作流基因计算的典型特征就是数据分批计算,需要按照特定步骤先后依次完成。将该问题抽象后,即需要申明式工作流定义 AGS(AlibabaCloud Genomics Service) workflow。其工作流的特点是:多层次,有向无环图。科研大工作流 1000-5000+ 深度的 DAG,需要准确的流程状态监控和高度的流程稳定性。简单流程从任意步骤重现启动 ,失败步骤可以自动完成重试和继续,定时任务,通知,日志,审计,查询,统一操作入口 CLI/UI 。[图片上传失败…(image-f4ed64-1554348389942)]我们采用的方案是:1.简单 YAML 申明式定义,多层次,有向无环图, 复杂依赖支持, 任务自动分拆,自动并行化;2.云原生,与社区 Argo 完全兼容的增强性 Workflow 定义;3.实时资源统计,监控集成云监控,云日志 SLS 集成, 审计集成, 定时任务;4.统一操作入口 ags-cli 与 Kubectl 集成;5.阿里云存储卷申明式支持,NAS,OSS,CloudDisk, 缓存加速支持。云上云下资源的统一调度通过跨越 IDC 和云上可用区的混合云 ACK 集群实现计算资源的统一调度和数据的云端汇聚。自动化,流程化上云数据,和后续的数据处理流程,形成 24 小时内完成批次下机数据的本地, 上云,云端处理和报告生成。按需弹性提供计算节点或者无服务化计算资源,形成按需计算能力,处理突发分析任务。我所带领的阿里云基因数据服务团队努力构建更具弹性的容器化集群,分钟级数百节点自动伸缩能力和分钟级数千轻量容器拉起的 Serverless 能力, 通过提高并行度来提高内网带宽的利用率,最终提高整体数据吞吐率,通过 NAS 客户端和服务端的 TCP 优化来提高 IO 读写速度,通过为 OSS 增加缓存层和分布式的缓存来实现对象存储读取加速等等。还有很多问题,篇幅原因在此不一一展开:如何进行基因数据管理、最优化单位数据处理成本、采用批量计算的方式进行对样本分析、怎样使得基因数据处理安全及跨组织安全分享等等。生命科学和精准医学应用,未来已来NovaSeq 测序仪带来了低成本(100$/WGS)高产出(6TB 通量)的二代测序方案,大量 NovaSeq 的使用为基因测序公司每天产出的几十 TB 数据,这就要求大量的算力来分拆和发现变异,以及需要大量的存储来保存原始数据和变异数据。阿里云基因数据服务不断提升极致弹性的计算能力,和大规模并行处理能力,以及海量高速存储来帮助基因公司快速自动化处理每天几十上百 TB 的下机数据,并产通过 GATK 标准产出高质量的变异数据。以 PacBio 和 Nanopore 为代表的三代测序的出现,超过 30K 到数百 K 的长读,和 20GB 到 15TB 的大通量产出,长读和数据量对数据比对,分拆,发现变异带来了更大的算力需要和高 IO 吞吐的需求,对基因计算过程中优化基因分析流程,拆分数据,按需调度大量计算资源,提供超高的 IO 吞吐带来了更大的挑战。解码未知,丈量生命。科技的每一小步,都会成为人类前行的一大步。本文作者:李鹏(Eric Li),阿里云资深架构师,数据科学家,美国 FDA2018 精准医疗大赛Top2 Winner ,金融/生物计算行业解决方案专家,专注于基于 Kubernetes 的容器产品开发和银行,生信行业的生产落地。在加入阿里云之前,曾在 IBM 担任 Watson 数据服务容器平台首席架构师,机器学习平台架构师,IBM 2015 Spark 全球大赛金奖获得者,带领多个大型开发项目,涵盖云计算,数据库性能工具、分布式架构、生物计算,大数据和机器学习。本文作者:木环阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

April 4, 2019 · 1 min · jiezi

Pick!闲鱼亿级商品库中的秒级实时选品

一、业务背景在电商运营工作中,营销活动是非常重要的部分,对用户增长和GMV都有很大帮助。对电商运营来说,如何从庞大的商品库中筛选出卖家优质商品并推送给有需要的买家购买是每时每刻都要思索的问题,而且这个过程需要尽可能快和实时。保证快和实时就可以提升买卖双方的用户体验,提高用户粘性。二、实时选品为了解决上面提到的问题,闲鱼研发了马赫系统。马赫是一个实时高性能的商品选品系统,解决在亿级别商品中通过规则筛选优质商品并进行投放的场景。有了马赫系统之后,闲鱼的运营同学可以在马赫系统上创建筛选规则,比如商品标题包含“小猪佩奇”、类目为“玩具”、价格不超过100元且商品状态为未卖出。在运营创建规则后,马赫系统会同时进行两步操作,第一步是从存量商品数据筛选符合条件的商品进行打标;第二步是对商品实时变更进行规则计算,实时同步规则命中结果。马赫系统最大的特点是快而实时,体现在命中规模为100w的规则可以在10分钟之内完成打标;商品本身变更导致的规则命中结果同步时间为1秒钟。运营可以通过马赫系统快速筛选商品向用户投放,闲鱼的流量也可以精准投给符合条件的商品并且将流量利用到最大化。那么马赫系统是如何解决这一典型的电商问题的呢,马赫系统和流计算有什么关系呢,这是下面要详细说明的部分。三、流计算流计算是持续、低延迟、事件触发的数据处理模型。流计算模型是使用实时数据集成工具,将数据实时变化传输到流式数据存储,此时数据的传输变成实时化,将长时间累积大量的数据平摊到每个时间点不停地小批量实时传输;流计算会将计算逻辑封装为常驻计算服务,一旦启动就一直处于等待事件触发状态,当有数据流入后会触发计算迅速得到结果;当流计算得到计算结果后可以立刻将数据输出,无需等待整体数据的计算结果。闲鱼实时选品系统使用的流计算框架是Blink,Blink是阿里巴巴基于开源流计算框架Flink定制研发的企业级流计算框架,可以认为是Flink的加强版,现在已经开源。Flink是一个高吞吐、低延迟的计算引擎,同时还提供很多高级功能。比如它提供有状态的计算,支持状态管理,支持强一致性的数据语义以及支持Event Time,WaterMark对消息乱序的处理等特性,为闲鱼实时选品系统的超低延时选品提供了有力支持。3.1、Blink之StateState是指流计算过程中计算节点的中间计算结果或元数据属性,比如在aggregation过程中要在state中记录中间聚合结果,比如Apache Kafka作为数据源时候,我们也要记录已经读取记录的offset,这些State数据在计算过程中会进行持久化(插入或更新)。所以Blink中的State就是与时间相关的,Blink任务的内部数据(计算数据和元数据属性)的快照。马赫系统会在State中保存商品合并之后的全部数据和规则运行结果数据。当商品发生变更后,马赫系统会将商品变更信息与State保存的商品信息进行合并,并将合并的信息作为入参运行所有规则,最后将规则运行结果与State保存的规则运行结果进行Diff后得到最终有效的运行结果。所以Blink的State特性是马赫系统依赖的关键特性。3.2、Blink之WindowBlink的Window特性特指流计算系统特有的数据分组方式,Window的创建是数据驱动的,也就是说,窗口是在属于此窗口的第一个元素到达时创建。当窗口结束时候删除窗口及状态数据。Blink的Window主要包括两种,分别为滚动窗口(Tumble)和滑动窗口(Hop)。滚动窗口有固定大小,在每个窗口结束时进行一次数据计算,也就是说滚动窗口任务每经过一次固定周期就会进行一次数据计算,例如每分钟计算一次总量。滑动窗口与滚动窗口类似,窗口有固定的size,与滚动窗口不同的是滑动窗口可以通过slide参数控制滑动窗口的新建频率。因此当slide值小于窗口size的值的时候多个滑动窗口会重叠,此时数据会被分配给多个窗口,如下图所示:Blink的Window特性在数据计算统计方面有很多使用场景,马赫系统主要使用窗口计算系统处理数据的实时速度和延时,用来进行数据统计和监控告警。3.3、Blink之UDXUDX是Blink中用户自定义函数,可以在任务中调用以实现一些定制逻辑。Blink的UDX包括三种,分别为:UDF - User-Defined Scalar FunctionUDF是最简单的自定义函数,输入是一行数据的任意字段,输出是一个字段,可以实现数据比较、数据转换等操作。UDTF - User-Defined Table-Valued FunctionUDTF 是表值函数,每个输入(单column或多column)返回N(N>=0)Row数据,Blink框架提供了少量的UDTF,比如:STRING_SPLIT,JSON_TUPLE和GENERATE_SERIES3个built-in的UDTF。UDAF - User-Defined Aggregate FunctionUDAF是聚合函数,输入是多行数据,输出是一个字段。Blink框架Built-in的UDAF包括MAX,MIN,AVG,SUM,COUNT等,基本满足了80%常用的集合场景,但仍有一定比例的复杂业务场景,需要定制自己的聚合函数。马赫系统中使用了大量的UDX进行逻辑定制,包括消息解析、数据处理等。而马赫系统最核心的商品数据合并、规则运行和结果Diff等流程就是通过UDAF实现的。四、秒级选品方案选品系统在项目立项后也设计有多套技术方案。经过多轮讨论后,最终决定对两套方案实施验证后决定最终实现方案。第一套方案是基于PostgreSQL的方案,PostgreSQL可以很便捷的定义Function进行数据合并操作,在PostgreSQL的trigger上定义执行规则逻辑。基于PostgreSQL的技术实现较复杂,但能满足功能需求。不过性能测试结果显示PostgreSQL处理小数据量(百万级)性能较好;当trigger数量多、trigger逻辑复杂或处理亿级别数据时,PostgreSQL的性能会有较大下滑,不能满足秒级选品的性能指标。因此基于PostgreSQL的方案被否决(在闲鱼小商品池场景中仍在使用)。第二套方案是基于Blink流计算方案,通过验证发现Blink SQL很适合用来表达数据处理逻辑而且Blink性能很好,综合对比之后最终选择Blink流计算方案作为实际实施的技术方案。为了配合使用流计算方案,马赫系统经过设计和解耦,无缝对接Blink计算引擎。其中数据处理模块是马赫系统核心功能模块,负责接入商品相关各类数据、校验数据、合并数据、执行规则和处理执行结果并输出等步骤,所以数据处理模块的处理速度和延时在很大程度上能代表马赫系统数据处理速度和延时。接下来我们看下数据处理模块如何与Blink深度结合将数据处理延迟降到秒级。数据处理模块结构如上图,包含数据接入层、数据合并层、规则运行层和规则运行结果处理层。每层都针对流计算处理模式进行了单独设计。4.1、数据接入层数据接入层是数据处理模块前置,负责对接多渠道各种类型的业务数据,主要逻辑如下:数据接入层对接多个渠道多种类型的业务数据;解析业务数据并做简单校验;统计各渠道业务数据量级并进行监控,包括总量和同比变化量;通过元数据中心获取字段级别的Metadata配置。元数据中心是用来保存和管理所有字段的MetaData配置信息组件。Metadata配置代表字段元数据配置,包括字段值类型,值范围和值格式等基础信息;根据Metadata配置进行字段级别数据校验;按照马赫定义的标准数据范式组装数据。这样设计的考虑是因为业务数据是多种多样的,比如商品信息包括数据库的商品表记录、商品变更的MQ消息和算法产生的离线数据,如果直接通过Blink对接这些业务数据源的话,需要创建多个Blink任务来对接不同类型业务数据源,这种处理方式太重,而且数据接入逻辑与Blink紧耦合,不够灵活。数据接入层可以很好的解决上述问题,数据接入层可以灵活接入多种业务数据,并且将数据接入与Blink解耦,最终通过同一个Topic发出消息。而Blink任务只要监听对应的Topic就可以连续不断的收到业务数据流,触发接下来的数据处理流程。4.2、数据合并层数据合并是数据处理流程的重要步骤,数据合并的主要作用是将商品的最新信息与内存中保存的商品信息合并供后续规则运行使用。数据合并主要逻辑是:监听指定消息队列Topic,获取业务数据消息;解析消息,并将消息内容按照字段重新组装数据,格式为{key:[timestamp, value]},key是字段名称,value是字段值,timestamp为字段数据产生时间戳;将组装后的数据和内存中保存的历史数据根据timestamp进行字段级别数据合并,合并算法为比较timestamp大小取最新字段值,具体逻辑见下图。数据合并有几个前提:内存可以保存存量数据;这个是Blink提供的特性,Blink可以将任务运行过程中产生的存量数据保存在内存中,在下一次运行时从内存中取出继续处理。合并后的数据能代表商品的最新状态;这点需要一个巧妙设计:商品信息有很多字段,每个字段的值是数组,不仅要记录实际值,还要记录当前值的修改时间戳。在合并商品信息时,按照字段进行合并,合并规则是取时间戳最大的值为准。举例来说,内存中保存的商品ID=1的信息是{“desc”: [1, “描述1”], “price”: [4, 100.5]},数据流中商品ID=1的信息是{“desc”: [2, “描述2”], “price”: [3, 99.5]},那么合并结果就是{“desc”: [2, “描述2”], “price”: [4, 100.5]},每个字段的值都是最新的,代表商品当前最新信息。当商品信息发生变化后,最新数据由数据接入层流入,通过数据合并层将数据合并到内存,Blink内存中保存的是商品当前最新的全部数据。4.3、规则运行层规则运行层是数据处理流程核心模块,通过规则运算得出商品对各规则命中结果,逻辑如下:规则运行层接受输入为经过数据合并后的数据;通过元数据中心获取字段级别Metadata配置;根据字段Metadata配置解析数据;通过规则中心获取有效规则列表,规则中心是指创建和管理规则生命周期的组件;循环规则列表,运行单项规则,将规则命中结果保存在内存;记录运行规则抛出异常的数据,并进行监控告警。这里的规则指的是运营创建的业务规则,比如商品价格大于50且状态为在线。规则的输入是经过数据合并后的商品数据,输出是true或false,即是否命中规则条件。规则代表的是业务投放场景,马赫系统的业务价值就是在商品发生变更后尽快判断是否命中之前未命中的规则或是不命中之前已经命中的规则,并将命中和不命中结果尽快体现到投放场景中。规则运行需利用Blink强大算力来保证快速执行,马赫系统当前有将近300条规则,而且还在快速增长。这意味着每个商品发生变更后要在Blink上运行成百上千条规则,闲鱼每天有上亿商品发生变更,这背后需要的运算量是非常惊人的。4.4、运行结果处理层读者读到这里可能会奇怪,明明经过规则运行之后直接把运行结果输出到投放场景就可以了,不需要运行结果处理层。实际上运行结果处理层是数据处理模块最重要的部分。因为在实际场景中,商品的变更在大部分情况只会命中很少一部分规则,而且命中结果也很少会变化。也就是说商品对很多规则的命中结果是没有意义的,如果将这些命中结果也输出的话,只会增加操作TPS,对实际结果没有任何帮助。而筛选出有效的运行结果,这就是运行结果处理层的作用。运行结果处理层逻辑如下:获取商品数据的规则运行结果;按照是否命中规则解析运行结果;将运行结果与内存中保存的历史运行结果进行diff,diff作用是排除新老结果中相同的命中子项,逻辑见下图。运行结果处理层利用Blink内存保存商品上一次变更后规则运行结果,并将当前变更后规则运行结果与内存中结果进行比较,计算出有效运行结果。举例来说,商品A上一次变更后规则命中结果为{“rule1”:true, “rule2”:true, “rule3”:false, “rule4”:false},当前变更后规则命中结果为{“rule1”:true, “rule2”:false, “rule3”:false, “rule4”:true}。因为商品A变更后对rule1和rule3的命中结果没有变化,所以实际有效的命中结果是{“rule2”:false, “rule4”:true},通过运行结果处理层处理后输出的是有效结果的最小集,可以极大减小无效结果输出,提高数据处理的整体性能和效率。4.5、难点解析虽然闲鱼实时选品系统在立项之初经过预研和论证,但因为使用很多新技术框架和流计算思路,在开发过程中遇到一些难题,包括设计和功能实现方面的,很多是设计流计算系统的典型问题。我们就其中一个问题与各位读者探讨-规则公式转换。4.5.1、规则公式转换这个问题的业务场景是:运营同学在马赫系统页面上筛选商品字段后保存规则,服务端是已有的老系统,逻辑是根据规则生成一段SQL,SQL的where条件和运营筛选条件相同。SQL有两方面的作用,一方面是作为离线规则,在离线数据库中执行SQL筛选符合规则的离线商品数据;另一方面是转换成在线规则,在Blink任务中对实时商品变更数据执行规则以判断是否命中。因为实时规则运行使用的是MVEL表达式引擎,MVEL表达式是类Java语法的,所以问题就是将离线规则的SQL转换成在线规则的Java表达式,两者逻辑需一致,并且需兼顾性能和效率。问题的解决方案很明确,解析SQL后将SQL操作符转换成Java操作符,并将SQL特有语法转成Java语法,例如A like ‘%test%‘转成A.contains(’test’)。这个问题的难点是如何解析SQL和将解析后的语义转成Java语句。经过调研之后给出了简单而优雅的解决方案,主要步骤如下:使用Druid框架解析SQL语句,转成一个二叉树,单独取出其中的where条件子树;通过后序遍历算法遍历where条件子树;将SQL操作符换成对应的Java操作符;目前支持且、或、等于、不等于、大于、大于等于、小于、小于等于、like、not like和in等操作。将SQL语法格式转成Java语法;将in语法改成Java的或语法,例如A in (‘hello’, ‘world’)转成(A == ‘hello’) || (A == ‘world’)。实际运行结果如下:代码逻辑如下(主要是二叉树后续遍历和操作符转换,不再详细解释):五、结论马赫系统上线以来,已经支持近400场活动和投放场景,每天处理近1.4亿条消息,峰值TPS达到50000。马赫系统已经成为闲鱼选品投放的重要支撑。本文主要阐述马赫系统中数据处理的具体设计方案,说明整体设计的来龙去脉。虽然闲鱼实时选品系统针对的是商品选品,但数据处理流计算技术方案的输入是MQ消息,输出也是MQ消息,不与具体业务绑定,所以数据处理流计算技术方案不只适用于商品选品,也适合其他类似实时筛选业务场景。希望我们的技术方案和设计思路能给你带来一些想法和思考,也欢迎和我们留言讨论,谢谢。参考资料闲鱼实时选品系统:https://mp.weixin.qq.com/s/8ROsZniYD7nIQssC14mn3wBlink:https://github.com/apache/flink/tree/blinkPostgreSQL:https://www.postgresql.org/druid:https://github.com/alibaba/druid本文作者:闲鱼技术-剑辛阅读原文本文为云栖社区原创内容,未经允许不得转载。

April 3, 2019 · 1 min · jiezi

表格存储TableStore全新升级,打造统一的在线数据存储平台!

表格存储TableStore是阿里云自研的面向海量结构化和半结构化数据存储的Serverless NoSQL多模型数据库,被广泛用于社交、物联网、人工智能、元数据和大数据等业务场景。表格存储TableStore采用与Google Bigtable类似的宽表模型,天然的分布式架构,能支撑高吞吐的数据写入以及PB级数据存储。原生的宽表数据模型,存在一些天然的缺陷,例如无法很好的支持属性列的多条件组合查询,或者更高级的全文检索或空间检索。另外在与计算系统的对接上,特别是流计算场景,传统的大数据Lambda架构,需要用户维护多套存储和计算系统,没法很天然的支持数据在存储和计算系统之间的流转。以上这些问题,均在表格存储TableStore在支持阿里巴巴集团内、阿里云公共云以及专有云等业务中逐渐暴露出来。表格存储TableStore简单可靠的数据模型和架构,开始承担越来越丰富的不同类型的数据存储,例如时序时空数据、元数据、消息数据、用户行为数据和轨迹溯源数据等。越来越多的客户也开始把表格存储TableStore当做一个统一的在线大数据存储平台,所以我们迫切需要支持海量数据中对数据的高效查询、分析和检索。同时也需要考虑如何更贴近业务,抽象出更贴近业务的数据模型,让数据的接入变得更加简单。在2019年3月6日的云栖发布会,表格存储TableStore对以下几个方面做了重大升级:提供多种数据模型,满足不同数据场景的需求,简化数据建模和开发。提供多元化索引,满足不同场景下简单或复杂条件查询的功能需求。提供实时数据通道,无缝对接流计算引擎,支持表内数据的实时更新订阅。多模型表格存储TableStore在选择要支持的数据模型的时候,更多的综合了当前业务现状以及用户画像,提取大部分客户的通用需求,总结和定义了产品适合的几大类核心数据场景,来抽象和定义数据模型。数据模型的定义分为『具象』和『抽象』:抽象模型是类似于关系模型或者文档模型的能满足大部分类型数据的抽象,属于比较通用的数据模型;具象模型是对某一具体特征场景数据的抽象,适合单一垂直类的数据场景。表格存储TableStore同时提供抽象和具象模型,当然在介绍这些模型之前,先来明确我们的核心数据场景。核心场景表格存储TableStore的核心场景包含这五大类,分别对应不同类型的应用系统,以及每类数据场景下数据有典型的特征和对存储和计算的特殊的需求,简单来说:时序数据:时序数据解决的是对包含4W(Who, When, Where, What)元素数据的抽象,数据量相对比较庞大,需要存储引擎支持对时间线的索引以及对时间线的时间范围查询。时空数据:时空数据是基于时序数据加上了空间的维度,同时可能没有时序数据的连续性。总的来说,特征和时序数据比较类似。消息数据:消息数据广泛存在于消息系统,例如即时通讯消息系统或者Feeds流消息系统内。消息的存储和传递更像是消息队列模型,但是要求消息队列能够提供海量级消息存储以及海量Topic,这是传统专业级消息队列产品所无法支撑的。元数据:这类元数据属于非关系类元数据,例如历史订单数据、图片智能标签元数据点。特点是量级比较大,每个数据存在的属性比较多且是稀疏的,要求存储能够支持对各种维度属性的条件过滤,对查询可用性有比较高的要求。大数据:这是Bigtable模型所对应的最主要数据场景,特点是数据量极其庞大,需要很好的支持批量计算。TableStore多模型基于以上总结的表格存储TableStore所针对的核心数据场景,我们从业务需求中抽象出三大类数据模型,分别是:WideColumn(宽行模型)、Timeline(消息模型)和Timestream(时序模型)。宽行模型宽行模型是由Bigtable提出,特征是:三维数据结构:对比MySQL的二维数据结构,在属性列这一维度上多了版本属性。同一列数据可以存储多个不同版本,并可定义不同的生命周期,主要用于数据的自动化生命周期管理。稀疏列:表不需要有强格式定义,可以任意的对每一行定义列和类型。大表:一张表可以存储万亿行数据,大表数据根据分区键的范围来分区,不同的分区由不同的机器来加载和提供服务,能比较简单的实现分布式。宽行模型主要应用于元数据和大数据场景,一些典型应用场景可参考:《TableStore实战:智能元数据管理方案》《TableStore实战:亿量级订单管理解决方案》《百亿级全网舆情分析系统存储设计》《基于云上分布式NoSQL的海量气象数据存储和查询方案》我们也提供HBase API兼容的Client:《使用HBase Client访问阿里云NoSQL数据库表格存储》。消息模型消息模型是表格存储TableStore针对消息数据所抽象的数据模型,主要适用于消息系统中海量消息存储和同步,特征是:轻量级消息队列:大表中能模拟海量消息队列,虽然不能完全模拟一个真正消息队列的所有能力,但是能满足对消息最基本的存储和同步能力。消息永久存储:能保证对数据的永久存储,消息写入和同步的性能不会受到数据规模的影响。消息同步模型:对消息同步模型没有严格要求,应用层可以根据自己的业务特征,同时实现推模型或者拉模型。消息模型主要应用于消息数据场景,一些典型应用场景可参考:《现代IM系统中消息推送和存储架构的实现》《TableStore Timeline:轻松构建千万级IM和Feed流系统》《如何打造千万级Feed流系统》《基于TableStore构建简易海量Topic消息队列》《如何快速开发一个IM系统》时序模型时序模型主要应用与时序和时空场景,也是表格存储TableStore综合了业界主流的时序数据库,所定义和抽象的数据模型,特征是:海量数据存储:能提供PB级数据存储,可打造多租户的时序数据库底层存储,写入和查询性能不受数据规模的影响。时间线索引:提供对时间线的索引,能满足对时间线Tag的任何条件组合过滤,并且能够支持比较海量的时间线规模。完整的模型定义:在业界标杆的时序数据库模型定义上,补充了空间维度的定义并且提供空间索引,以及支持多列值支持,不限制只对数值类型的支持。时序模型主要应用于时序和时空数据,一些典型应用场景可参考:《TableStore时序数据存储 - 架构篇》《TableStore实战:轻松实现轨迹管理与地理围栏》查询优化上述场景中提到的对于表内数据的查询优化,最基本手段就是需要对数据建立索引。表格存储TableStore选择的做法是,对于不同类型的查询场景,我们需要提供不同类型的索引。业界对海量数据建立索引的方案有多种,在传统技术架构中应用比较多的主要包括Phoenix SQL二级索引或者Elasticsearch搜索引擎。二级索引能提供高效的固定维度的条件查询,查询性能不受数据规模的影响,而Elasticsearch搜索引擎能提供比较灵活的多条件组合查询、全文索引和空间索引。两种类型的索引实现,有不同的优缺点,以及适用于不同的场景。表格存储TableStore的做法是同时实现和这两类索引原理类似的索引,来满足不同场景下对查询的不同需求。全局二级索引当用户创建一张表时,其所有PK列构成了该表的『一级索引』:即给定完整的行主键,可以迅速的查找到该主键所在行的数据。但是越来越多的业务场景中,需要对表的属性列,或者非主键前缀列进行条件上的查询,由于没有足够的索引信息,只能通过进行全表的扫描,配合条件过滤,来得到最终结果,特别是全表数据较多,但最终结果很少时,全表扫描将浪费极大的资源。表格存储TableStore提供的全局二级索引功能支持在指定列上建立索引,生成的索引表中数据按用户指定的索引列进行排序,主表的每一笔写入都将自动异步同步到索引表。用户只向主表中写入数据,根据索引表进行查询,在许多场景下,将极大的提高查询的效率。更多的技术解读,请参考这篇文章《通过全局二级索引加速表格存储上的数据查询》。多元索引表格存储TableStore多元索引是表格存储TableStore重点打造的一个多功能索引能力,旨在补位二级索引无法覆盖的场景,解决大数据场景下的复杂查询和轻量级分析问题,比如多字段组合查询、前缀查询、通配符查询、嵌套查询、全文检索(分词)、地理位置查询、排序和统计聚合等功能。关于对多元索引的更多解读,可以阅读这篇文章《TableStore多元索引,大数据查询的利器》,关于多元索引的更多应用场景,可以参考以下文章:《TableStore:交通数据的存储、查询和分析利器》《TableStore:爬虫数据存储和查询利器》计算衔接表格存储TableStore已经与比较多的开源大数据计算引擎以及阿里云计算产品衔接,例如Hive、Spark、MaxCompute以及DataLakeAnalytics等,覆盖了批量计算和交互式分析。可以由第三方产品提供的数据通道服务,将表格存储TableStore上的数据全量或者增量复制到计算系统,也可以由计算系统通过Connector直接访问表内的数据。批量计算和交互式分析访问数据存储的方式是批量扫描,主要通过自定义数据Connector的方式。但是其他类计算系统例如流计算或者函数计算(Lambda架构),数据是需要流式的并且实时的从存储系统到计算系统。这个能力是传统开源Bigtable类数据库所做不到的,例如HBase或Cassandra。如果表内的数据可以实时的流动,那将给表带来更丰富的计算和处理场景,例如可以做跨域复制、备份,或者接入流计算引擎做实时分析或者函数计算做事件触发式编程,也可以由应用方自定义数据处理,来做个性化数据处理。表格存储TableStore提供了全新的实时数据通道,能支持订阅表内的实时数据更新,来扩充表格存储TableStore的计算能力。通道服务TableStore 通道服务(Tunnel Service)是基于表格存储数据接口之上的全增量一体化服务,通道服务为用户提供了增量、全量、增量加全量三种类型的分布式数据实时消费通道。通过为数据表建立Tunnel Service数据通道,可以简单地实现对表中历史存量和新增数据的消费处理。基于通道服务用户可以轻松的实现如图所示的场景架构:数据同步、搬迁和备份,流式数据处理以及事件驱动架构。关于对通道服务TunnelService更多的技术解读,可以参考这篇文章:《大数据同步利器: 表格存储全增量一体消费通道》。基于通道服务的更多应用场景,可以参考以下文章:《实时计算最佳实践:基于表格存储和Blink的大数据实时计算》《TableStore: 海量结构化数据实时备份实战 》《TableStore: 海量结构化数据分层存储方案》总结表格存储TableStore通过同时提供具象和抽象的数据模型,来满足不同核心数据场景的要求,更贴近业务抽象;提供多元化索引(全局二级索引和多元索引)来满足不同类型场景条件查询需求;提供全新的实时数据通道,来扩充实时计算的能力以及可自定义的实时数据处理。这三大方面的新功能发布,能够让我们在数据模型、灵活查询以及数据分析层面,都有一定的提升,帮助打造统一的在线数据存储平台。本文作者:木洛阅读原文本文为云栖社区原创内容,未经允许不得转载。

March 11, 2019 · 1 min · jiezi

TableStore:爬虫数据存储和查询利器

TableStore是阿里云自研的在线数据平台,提供高可靠的存储,实时和丰富的查询功能,适用于结构化、半结构化的海量数据存储以及各种查询、分析。爬虫数据特点在众多大数据场景中,爬虫类型的数据非常适合存储在TableStore。主要是因为爬虫类型数据的一些特征和TableStore和匹配:数据量大爬虫数据一般都是抓取的互联网上的某个行业或领域的数据,数据规模和这个行业的数据规模有关,比如资讯类,每时每刻都在产生大量新闻报道,这个数据规模可能在10 TB到100 TB级别,如果考虑到历史存量数据,那么规模可能会更大。这么大量的数据存储已经不适合用单机的关系型数据库了,也不适合分库分表了,而需要一款分布式NoSQL数据库,这样可以将数据按一定的路由规则分布到不同机器上,实现自动的水平扩展,非常适合存储海量数据,尤其是爬虫类。宽行和稀疏列爬虫的数据一般来源于多个数据源,比如资讯数据可以来自人民网、新浪或者腾讯,每个数据源的数据特征不可能完全一样,每家有每家的特殊性,这样就会出现每一行数据的属性列有差异,虽然可以归一化处理后,可以将通用的属性列统一,但是不同数据源还是会存在一定差异性。如果为每个数据源建立一张表,那么工作量就会非常大,也不适合。这时候,就需要用到宽行和稀疏列功能,既能保证列数无上限,也能保证不同行不同列,还可以不额外增加存储成本和运维成本。查询类型多样爬虫数据的存储后,一般有两个出口,一个是数据处理程序,数据处理程序会读取最新的爬虫数据,然后按照自定义的处理逻辑做数据加工,处理完后会新数据写入原表或新表。数据处理完之后,数据可以提供给下游企业客户或终端用户使用了,场景的查询需求有下列几种:多种属性列组合查询。比如全网简历信息里面,通过年龄、学历、专长查询,且每个人查询的条件可能都完全不一样,需要多种属性列的自由组合查询。分词查询。不管是咨询类,还是简历类,都有大量的文本描述,这部分内容都需要支持分词后再查询。排序能力。比如资讯类数据中,查询某个新闻后,需要按时间逆序返回,越新的数据价值越大。随机读能力。如果是用来做全局数据分析或处理,那么随机读是一种必须要有的能力。轻量级统计分析。比如资讯类,想查看某个热点新闻的传播时间段和趋势,就需要统计每个时间段的此类新闻出现次数。这些查询能力,在传统的关系型数据库或者开源NoSQL中都无法提供。开源解决方案爬虫数据存储的方案已经演进了将近二十年了,千奇百怪的各种方案都有,主要的差异来源于两点:当前能获取到的存储系统能力。自身对系统可靠性、可用性的要求高低。我们下面以当前业界流行的开源系统为材料,打造一个爬虫数据存储的系统。当前业内的开源存储系统有两大类,一类是开源的关系型数据库,比如MySQL等,一类是NoSQL,比如HBase等。这两类数据存储系统都不能支持分词查询,那么还需要一个全文检索的系统,当前可选的有solr和Elasticsearch。基于上述的素材,我们就可以搭建一个存储爬虫的系统了:首先,选择存储系统,MySQL和HBase都可以,如果使用MySQL,则需要分库分表,两者架构图差不多,这里我们就选择HBase。再次,选择查询系统,可选的solr和Elasticsearch,虽然是同一类型系统,但是Elasticsearch的目前更流行,那我们也选择Elasticsearch。这样,架构图大致如下:大概解释下:流程:爬虫系统将抓取的数据写入HBase离线集群,然后数据处理系统周期性或流式的处理新到的数据,将处理后的结果写入HBase在线集群。HBase在线集群存储所有属性列的值,然后将需要查询的列通过co-processor发送给消息队列,最后再将消息队列中的数据被Elasticsearch消费,生成索引。最后,用户通过索引查询到PK,然后通过proxy到HBase在线集群读取这一行完整数据,最后返回给用户。数据存储集群有两个,一个是在线集群,一个是离线集群,原因是为了避免减少离线集群对在线查询的影响,因为离线系统重吞吐,而在线系统重延迟,所以,这里会分成两个集群,目的是挺高系统可用性。消息队列的目的是削峰填谷,减少对下游系统:Elasticsearch的压力,同时当Elasticsearch写入慢或者出故障后,不至于影响上游系统,目的也是为了提高系统可用性,避免单点故障导致整个系统雪崩。Proxy的目的是减轻客户端工作量,提高易用性的工具,原因是爬虫数据是系数列,这些列不可能全部都在Elasticsearch中创建索引,只有部分需要查询、分析的属性列才会在Elasticsearch中建立索引,但是查询的时候也需要未建立索引的字段,这样就需要一个系统做反查和合并,就是先查Elasticsearch获取到PK,然后通过PK到HBase在线集群查询这一行完整数据。这个系统中,需要运维6个不同开源系统,运维压力比较大。TableStore云解决方案最开始,我们说TableStore很适合存储爬虫数据,在介绍了开源系统的解决方案后,我们再来看一下TableStore的解决方案,以及相对于开源系统,可以为客户带来的收益。也先看一下架构图:大概解释下:爬虫系统抓取的数据写入TableStore的离线表,然后经过TunnelService的流式通道,数据进入数据处理系统做处理加工,再将加工后的数据写入在线表,用户直接查询在线表即可。将离线表和在线表同时放在TableStore服务中,会不会出现离线表干扰在线表的情况?这个不会的,TableStore服务内部有自动的负载均衡和隔离系统,会自动处理这些问题。所有的查询都可以直接查询在线表及其索引,提供了多字段组合查询、分词查询、排序和统计分析等功能,完全可以满足用户对查询的需求。数据处理部分一般有两种处理方式,一种是离线全量处理,这种可以使用阿里云的MaxCompute系统,MaxCompute可以直读TableStore的数据做计算,不需要额外把数据导过去。另一种是流式实时处理,TableStore提供了TunnelService系统,可以获取到实时的Table中的数据更新记录,然后将更新记录发送到函数计算、流式计算系统,或者自己的应用、flink等系统处理。这个架构中,用户只需要运维2个系统即可。示例我们接下来举一个简历类爬虫数据存储和查询的示例,帮忙读者快速理解。简历一般是一个PDF文档或者doc文档,是一个文件,但是我们可以从这些文件中抽取出结构化的信息,比如姓名、电话号码、身份证、邮箱、毕业学校、学历、专业领域、项目经验、兴趣、期望薪水和工作年限等。首先,我们设计TableStore中主表结构:主键列属性列属性列属性列属性列属性列属性列属性列属性列属性列身份证姓名电话号码邮箱毕业学校学历专业领域项目经验兴趣期望薪水工作年限StringStringStringStringStringStringStringStringStringLongDouble61xxx5王一152xxx7aa@xx.comMIT硕士[数据库,MySQL]1.数据库binlog优化。[足球]200003.5大概解释下:主键列需要一个唯一值,用来唯一确定某个人,这里我们用了身份证,有些场景获取不到身份证,那可以用手机号或其他ID。后面几个全部是属性列,包括姓名,电话号码等。期望薪水因为都是整数,所以可以选择Long类型,工作年限由于有小数,所以可以是Double类型。通过这张表,我们可以通过身份证,查询到该用户的详细信息。但是无法通过属性列查询,如果需要通过属性列查询,则需要创建多元索引。然后,我们再创建多元索引,多元索引的结构如下:属性列属性列属性列属性列属性列属性列属性列属性列属性列姓名电话号码毕业学校学历专业领域项目经验兴趣期望薪水工作年限Text:单字分词KeywordKeywordKeywordKeyword ArrayText:多层语义Keyword ArrayLongDouble解释下:上面的多元索引结构中包括9列,比Table中少了2列,是因为不需要通过“邮箱”和“身份证”两个属性列查询,所以,在建立index的时候就不需要为这两列创建index了。但是如果业务中确实需要通过邮箱查询,那么多元索引创建时加上邮箱即可。姓名的类型是Text:单字分词,意思是类型是Text,分词是单子分词,这样好处就是我可以通过搜索“小刚”搜索到“王小刚”、“冯小刚”等。电话号码、毕业院校、学历都是Keyword类型(对应Table中的String),因为这些都字符串都比较短,且查询方式是直接完全匹配或者前缀查询,那么用String就可以了。专业领域和项目经验两个属性列是Keyword Array的,因为是这两个属性列中会包括多个值,查询的时候只要有一个满足就可以返回,比如某个人的专业领域是:数据库、MySQL,那么我们查询“数据库”的时候,希望这个人返回。期望薪水和工作年限是数字类型的Long和Double,这样这两个属性列就可以支持范围查找,比如查找工作年限大于2年,小于5年,且期望薪水小于2万的简历。至此,我们就把简历库的table和index都建好了,用户就可以往Table中开始写数据,数据写入后会异步同步到Index中,这样就可以通过Index查询了。总结使用TableStore解决方案后,相对于开源解决方案,可以带来不少的收益:减少运维负担使用开源系统的架构中,需要运维6个系统,包括了3个开源系统:HBase、Kafka和Elasticsearch,为了运维这三个开源系统,需要有人对这三个系统比较熟悉,否则很难运维好。就算比较熟悉,也很难处理线上遇到的所有的问题,总会碰到无法解决的棘手问题而影响生产环境。如果使用了TableStore云解决方案,那么就不需要运维任何开源系统,只需要运维自己开发的两个系统,同时关注TableStore中的两个表就可以了,这两张表的运维全部是TableStore服务负责,且提供SLA保障,绝对比自己运维开源系统的可用性要高。同时,采用TableStore方案后,由于TableStore支持实时自动扩容,客户不再需要提前规划水位和集群容量,也不用担心高水位和突发流量对系统的冲击,将这些工作都交给了更擅长的云服务处理。这样,不仅降低了运维的工作量和压力,同时也降低了系统风险,提高了系统整体的可用性。减少时间成本TableStore云架构方案相对于开源方案,系统更少,从零开始到上线需要的开发时间更少,同时,TableStore是serverless的云服务,全球多个区域即开即用,可以大大降低客户的开发上线的时间,提前将产品推出,抢先争取市场领先优势。同时,TableStore支持按量付费,用户完全可以根据真实使用量付费,不再需要担心低峰期系统资源的浪费了,一定程度上,也能降低使用成本。最后目前,已经有不少行业的客户在使用TableStore存储爬虫数据,比如资讯类、生活类、文章类等等,也有部分用户在小数据量级时使用MySQL等关系型数据库,等数据规模大了后被迫迁移到TableStore存储。同时欢迎更多的客户开始使用TableStore存储你们的爬虫数据。本文作者:少强阅读原文本文为云栖社区原创内容,未经允许不得转载。

March 5, 2019 · 1 min · jiezi

10分钟了解Pandas基础知识

背景在数据分析中pandas举足轻重,学习pandas最好的方法就是看官方文档,以下是根据官方文档10 Minutes to pandas学习记录。(官方标题10分钟,感觉起码得半个小时吧)在pandas中主要有两种数据类型,可以简单的理解为:Series:一维数组DateFrame:二维数组(矩阵)有了大概的概念之后,开始正式认识pandas:首先要引入对应的包:import numpy as npimport pandas as pd新建对象 Object CreationSeries可以通过传入一个list对象来新建Series,其中空值为np.nan:s = pd.Series([1,3,4,np.nan,7,9])sOut[5]: 0 1.01 3.02 4.03 NaN4 7.05 9.0dtype: float64pandas会默认创建一列索引index(上面的0-5)。我们也可以在创建时就指定索引:pd.Series([1,3,4,np.nan,7,9], index=[1,1,2,2,‘a’,4])Out[9]: 1 1.01 3.02 4.02 NaNa 7.04 9.0dtype: float64要注意的是,索引是可以重复的,也可以是字符。DataFrame新建一个DataFrame对象可以有多种方式:通过传入一个numpy的数组、指定一个时间的索引以及一个列名。dates = pd.date_range(‘20190101’, periods=6)datesOut[11]: DatetimeIndex([‘2019-01-01’, ‘2019-01-02’, ‘2019-01-03’, ‘2019-01-04’, ‘2019-01-05’, ‘2019-01-06’], dtype=‘datetime64[ns]’, freq=‘D’)df = pd.DataFrame(np.random.randn(6,4), index=dates, columns=list(‘ABCD’))dfOut[18]: A B C D2019-01-01 0.671622 0.785726 0.392435 0.8746922019-01-02 -2.420703 -1.116208 -0.346070 0.7859412019-01-03 1.364425 -0.947641 2.386880 0.5853722019-01-04 -0.485980 -1.281454 0.354063 -1.4188582019-01-05 -1.122717 -2.789041 -0.791812 -0.1743452019-01-06 0.221597 -0.753038 -1.741256 0.287280通过传入一个dict对象df2 = pd.DataFrame({‘A’:1., ‘B’:pd.Timestamp(‘20190101’), ‘C’:pd.Series(1, index=list(range(4)), dtype=‘float32’), ‘D’:np.array([3]*4, dtype=‘int32’), ‘E’:pd.Categorical([“test”, “tain”, “test”, “train”]), ‘F’:‘foo’})df2Out[27]: A B C D E F0 1.0 2019-01-01 1.0 3 test foo1 1.0 2019-01-01 1.0 3 tain foo2 1.0 2019-01-01 1.0 3 test foo3 1.0 2019-01-01 1.0 3 train foo这里我们指定了不同的类型,可以通过如下查看:df2.dtypesOut[28]: A float64B datetime64[ns]C float32D int32E categoryF objectdtype: object可以看出DataFrame和Series一样,在没有指定索引时,会自动生成一个数字的索引,这在后续的操作中十分重要。查看 Viewing Data查看开头几行或者末尾几行:df.head()Out[30]: A B C D2019-01-01 0.671622 0.785726 0.392435 0.8746922019-01-02 -2.420703 -1.116208 -0.346070 0.7859412019-01-03 1.364425 -0.947641 2.386880 0.5853722019-01-04 -0.485980 -1.281454 0.354063 -1.4188582019-01-05 -1.122717 -2.789041 -0.791812 -0.174345df.tail(3)Out[31]: A B C D2019-01-04 -0.485980 -1.281454 0.354063 -1.4188582019-01-05 -1.122717 -2.789041 -0.791812 -0.1743452019-01-06 0.221597 -0.753038 -1.741256 0.287280可以通过添加行数参数来输出,默认为输出5行。查看索引和列名df.indexOut[32]: DatetimeIndex([‘2019-01-01’, ‘2019-01-02’, ‘2019-01-03’, ‘2019-01-04’, ‘2019-01-05’, ‘2019-01-06’], dtype=‘datetime64[ns]’, freq=‘D’)df.columnsOut[33]: Index([‘A’, ‘B’, ‘C’, ‘D’], dtype=‘object’)使用DataFrame.to_numpy()转化为numpy数据。需要注意的是由于numpy array类型数据只可包含一种格式,而DataFrame类型数据可包含多种格式,所以在转换过程中,pandas会找到一种可以处理DateFrame中国所有格式的numpy array格式,比如object。这个过程会耗费一定的计算量。df.to_numpy()Out[35]: array([[ 0.67162219, 0.78572584, 0.39243527, 0.87469243], [-2.42070338, -1.11620768, -0.34607048, 0.78594081], [ 1.36442543, -0.94764138, 2.38688005, 0.58537186], [-0.48597971, -1.28145415, 0.35406263, -1.41885798], [-1.12271697, -2.78904135, -0.79181242, -0.17434484], [ 0.22159737, -0.75303807, -1.74125564, 0.28728004]])df2.to_numpy()Out[36]: array([[1.0, Timestamp(‘2019-01-01 00:00:00’), 1.0, 3, ’test’, ‘foo’], [1.0, Timestamp(‘2019-01-01 00:00:00’), 1.0, 3, ’tain’, ‘foo’], [1.0, Timestamp(‘2019-01-01 00:00:00’), 1.0, 3, ’test’, ‘foo’], [1.0, Timestamp(‘2019-01-01 00:00:00’), 1.0, 3, ’train’, ‘foo’]], dtype=object)上面df全部为float类型,所以转换会很快,而df2涉及多种类型转换,最后全部变成了object类型元素。查看数据的简要统计结果df.describe()Out[37]: A B C Dcount 6.000000 6.000000 6.000000 6.000000mean -0.295293 -1.016943 0.042373 0.156680std 1.356107 1.144047 1.396030 0.860725min -2.420703 -2.789041 -1.741256 -1.41885825% -0.963533 -1.240143 -0.680377 -0.05893950% -0.132191 -1.031925 0.003996 0.43632675% 0.559116 -0.801689 0.382842 0.735799max 1.364425 0.785726 2.386880 0.874692转置df.TOut[38]: 2019-01-01 2019-01-02 2019-01-03 2019-01-04 2019-01-05 2019-01-06A 0.671622 -2.420703 1.364425 -0.485980 -1.122717 0.221597B 0.785726 -1.116208 -0.947641 -1.281454 -2.789041 -0.753038C 0.392435 -0.346070 2.386880 0.354063 -0.791812 -1.741256D 0.874692 0.785941 0.585372 -1.418858 -0.174345 0.287280按坐标轴排序,其中axis参数为坐标轴,axis默认为0,即横轴(对行排序),axis=1则为纵轴(对列排序);asceding参数默认为True,即升序排序,ascending=False则为降序排序:df.sort_index(axis=1)Out[44]: A B C D2019-01-01 0.671622 0.785726 0.392435 0.8746922019-01-02 -2.420703 -1.116208 -0.346070 0.7859412019-01-03 1.364425 -0.947641 2.386880 0.5853722019-01-04 -0.485980 -1.281454 0.354063 -1.4188582019-01-05 -1.122717 -2.789041 -0.791812 -0.1743452019-01-06 0.221597 -0.753038 -1.741256 0.287280df.sort_index(axis=1, ascending=False)Out[45]: D C B A2019-01-01 0.874692 0.392435 0.785726 0.6716222019-01-02 0.785941 -0.346070 -1.116208 -2.4207032019-01-03 0.585372 2.386880 -0.947641 1.3644252019-01-04 -1.418858 0.354063 -1.281454 -0.4859802019-01-05 -0.174345 -0.791812 -2.789041 -1.1227172019-01-06 0.287280 -1.741256 -0.753038 0.221597可见df.sort_index(axis=1)是按列名升序排序,所以看起来没有变化,当设置ascending=False时,列顺序变成了DCBA。按数值排序:df.sort_values(by=‘B’)Out[46]: A B C D2019-01-05 -1.122717 -2.789041 -0.791812 -0.1743452019-01-04 -0.485980 -1.281454 0.354063 -1.4188582019-01-02 -2.420703 -1.116208 -0.346070 0.7859412019-01-03 1.364425 -0.947641 2.386880 0.5853722019-01-06 0.221597 -0.753038 -1.741256 0.2872802019-01-01 0.671622 0.785726 0.392435 0.874692df.sort_values(by=‘B’, ascending=False)Out[47]: A B C D2019-01-01 0.671622 0.785726 0.392435 0.8746922019-01-06 0.221597 -0.753038 -1.741256 0.2872802019-01-03 1.364425 -0.947641 2.386880 0.5853722019-01-02 -2.420703 -1.116208 -0.346070 0.7859412019-01-04 -0.485980 -1.281454 0.354063 -1.4188582019-01-05 -1.122717 -2.789041 -0.791812 -0.174345筛选 Selection获取某列df[‘A’]Out[49]: 2019-01-01 0.6716222019-01-02 -2.4207032019-01-03 1.3644252019-01-04 -0.4859802019-01-05 -1.1227172019-01-06 0.221597Freq: D, Name: A, dtype: float64type(df.A)Out[52]: pandas.core.series.Series也可直接用df.A,注意这里是大小写敏感的,这时候获取的是一个Series类型数据。选择多行df[0:3]Out[53]: A B C D2019-01-01 0.671622 0.785726 0.392435 0.8746922019-01-02 -2.420703 -1.116208 -0.346070 0.7859412019-01-03 1.364425 -0.947641 2.386880 0.585372df[‘20190102’:‘20190104’]Out[54]: A B C D2019-01-02 -2.420703 -1.116208 -0.346070 0.7859412019-01-03 1.364425 -0.947641 2.386880 0.5853722019-01-04 -0.485980 -1.281454 0.354063 -1.418858通过一个[]会通过索引对行进行切片,由于前面设置了索引为日期格式,所以可以方便的直接使用日期范围进行筛选。通过标签选择选择某行df.loc[dates[0]]Out[57]: A 0.671622B 0.785726C 0.392435D 0.874692Name: 2019-01-01 00:00:00, dtype: float64选择指定行列的数据df.loc[:, (‘A’, ‘C’)]Out[58]: A C2019-01-01 0.671622 0.3924352019-01-02 -2.420703 -0.3460702019-01-03 1.364425 2.3868802019-01-04 -0.485980 0.3540632019-01-05 -1.122717 -0.7918122019-01-06 0.221597 -1.741256df.loc[‘20190102’:‘20190105’, (‘A’, ‘C’)]Out[62]: A C2019-01-02 -2.420703 -0.3460702019-01-03 1.364425 2.3868802019-01-04 -0.485980 0.3540632019-01-05 -1.122717 -0.791812传入第一个参数是行索引标签范围,第二个是列索引标签,:代表全部。选定某值df.loc[‘20190102’, ‘A’]Out[69]: -2.420703380445092df.at[dates[1], ‘A’]Out[70]: -2.420703380445092可以通过loc[]和at[]两种方式来获取某值,但需要注意的是,由于行索引为datetime类型,使用loc[]方式获取时,可直接使用20190102字符串来代替,而在at[]中,必须传入datetime类型,否则会有报错:df.at[‘20190102’, ‘A’] File “pandas/_libs/index.pyx”, line 81, in pandas._libs.index.IndexEngine.get_value File “pandas/_libs/index.pyx”, line 89, in pandas._libs.index.IndexEngine.get_value File “pandas/_libs/index.pyx”, line 449, in pandas._libs.index.DatetimeEngine.get_loc File “pandas/_libs/index.pyx”, line 455, in pandas._libs.index.DatetimeEngine._date_check_typeKeyError: ‘20190102’通过位置选择选择某行df.iloc[3]Out[71]: A -0.485980B -1.281454C 0.354063D -1.418858Name: 2019-01-04 00:00:00, dtype: float64iloc[]方法的参数,必须是数值。选择指定行列的数据df.iloc[3:5, 0:2]Out[72]: A B2019-01-04 -0.485980 -1.2814542019-01-05 -1.122717 -2.789041df.iloc[:,:]Out[73]: A B C D2019-01-01 0.671622 0.785726 0.392435 0.8746922019-01-02 -2.420703 -1.116208 -0.346070 0.7859412019-01-03 1.364425 -0.947641 2.386880 0.5853722019-01-04 -0.485980 -1.281454 0.354063 -1.4188582019-01-05 -1.122717 -2.789041 -0.791812 -0.1743452019-01-06 0.221597 -0.753038 -1.741256 0.287280df.iloc[[1, 2, 4], [0, 2]]Out[74]: A C2019-01-02 -2.420703 -0.3460702019-01-03 1.364425 2.3868802019-01-05 -1.122717 -0.791812同loc[],:代表全部。选择某值df.iloc[1, 1]Out[75]: -1.1162076820700824df.iat[1, 1]Out[76]: -1.1162076820700824可以通过iloc[]和iat[]两种方法获取数值。按条件判断选择按某列的数值判断选择df[df.A > 0]Out[77]: A B C D2019-01-01 0.671622 0.785726 0.392435 0.8746922019-01-03 1.364425 -0.947641 2.386880 0.5853722019-01-06 0.221597 -0.753038 -1.741256 0.287280筛选出符合要求的数据df[df > 0]Out[78]: A B C D2019-01-01 0.671622 0.785726 0.392435 0.8746922019-01-02 NaN NaN NaN 0.7859412019-01-03 1.364425 NaN 2.386880 0.5853722019-01-04 NaN NaN 0.354063 NaN2019-01-05 NaN NaN NaN NaN2019-01-06 0.221597 NaN NaN 0.287280不符合要求的数据均会被赋值为空NaN。使用isin()方法筛选df2 = df.copy()df2[‘E’] = [‘one’, ‘one’, ’two’, ’three’, ‘four’, ’three’]df2Out[88]: A B C D E2019-01-01 0.671622 0.785726 0.392435 0.874692 one2019-01-02 -2.420703 -1.116208 -0.346070 0.785941 one2019-01-03 1.364425 -0.947641 2.386880 0.585372 two2019-01-04 -0.485980 -1.281454 0.354063 -1.418858 three2019-01-05 -1.122717 -2.789041 -0.791812 -0.174345 four2019-01-06 0.221597 -0.753038 -1.741256 0.287280 threedf2[‘E’].isin([’two’, ‘four’])Out[89]: 2019-01-01 False2019-01-02 False2019-01-03 True2019-01-04 False2019-01-05 True2019-01-06 FalseFreq: D, Name: E, dtype: booldf2[df2[‘E’].isin([’two’, ‘four’])]Out[90]: A B C D E2019-01-03 1.364425 -0.947641 2.386880 0.585372 two2019-01-05 -1.122717 -2.789041 -0.791812 -0.174345 four注意:isin必须严格一致才行,df中的默认数值小数点位数很长,并非显示的5位,为了方便展示,所以新增了E列。直接用原数值,情况如下,可看出[1,1]位置符合要求。df.isin([-1.1162076820700824])Out[95]: A B C D2019-01-01 False False False False2019-01-02 False True False False2019-01-03 False False False False2019-01-04 False False False False2019-01-05 False False False False2019-01-06 False False False False设定值通过指定索引设定列s1 = pd.Series([1, 2, 3, 4, 5, 6], index=pd.date_range(‘20190102’, periods=6))s1Out[98]: 2019-01-02 12019-01-03 22019-01-04 32019-01-05 42019-01-06 52019-01-07 6Freq: D, dtype: int64df[‘F’]=s1dfOut[101]: A B C D F2019-01-01 0.671622 0.785726 0.392435 0.874692 NaN2019-01-02 -2.420703 -1.116208 -0.346070 0.785941 1.02019-01-03 1.364425 -0.947641 2.386880 0.585372 2.02019-01-04 -0.485980 -1.281454 0.354063 -1.418858 3.02019-01-05 -1.122717 -2.789041 -0.791812 -0.174345 4.02019-01-06 0.221597 -0.753038 -1.741256 0.287280 5.0空值会自动填充为NaN。通过标签设定值df.at[dates[0], ‘A’] = 0dfOut[103]: A B C D F2019-01-01 0.000000 0.785726 0.392435 0.874692 NaN2019-01-02 -2.420703 -1.116208 -0.346070 0.785941 1.02019-01-03 1.364425 -0.947641 2.386880 0.585372 2.02019-01-04 -0.485980 -1.281454 0.354063 -1.418858 3.02019-01-05 -1.122717 -2.789041 -0.791812 -0.174345 4.02019-01-06 0.221597 -0.753038 -1.741256 0.287280 5.0通过为止设定值df.iat[0, 1] = 0dfOut[105]: A B C D F2019-01-01 0.000000 0.000000 0.392435 0.874692 NaN2019-01-02 -2.420703 -1.116208 -0.346070 0.785941 1.02019-01-03 1.364425 -0.947641 2.386880 0.585372 2.02019-01-04 -0.485980 -1.281454 0.354063 -1.418858 3.02019-01-05 -1.122717 -2.789041 -0.791812 -0.174345 4.02019-01-06 0.221597 -0.753038 -1.741256 0.287280 5.0通过NumPy array设定值df.loc[:, ‘D’] = np.array([5] * len(df))dfOut[109]: A B C D F2019-01-01 0.000000 0.000000 0.392435 5 NaN2019-01-02 -2.420703 -1.116208 -0.346070 5 1.02019-01-03 1.364425 -0.947641 2.386880 5 2.02019-01-04 -0.485980 -1.281454 0.354063 5 3.02019-01-05 -1.122717 -2.789041 -0.791812 5 4.02019-01-06 0.221597 -0.753038 -1.741256 5 5.0通过条件判断设定值df2 = df.copy()df2[df2 > 0] = -df2df2Out[112]: A B C D F2019-01-01 0.000000 0.000000 -0.392435 -5 NaN2019-01-02 -2.420703 -1.116208 -0.346070 -5 -1.02019-01-03 -1.364425 -0.947641 -2.386880 -5 -2.02019-01-04 -0.485980 -1.281454 -0.354063 -5 -3.02019-01-05 -1.122717 -2.789041 -0.791812 -5 -4.02019-01-06 -0.221597 -0.753038 -1.741256 -5 -5.0空值处理 Missing Datapandas默认使用np.nan来表示空值,在统计计算中会直接忽略。通过reindex()方法可以新增、修改、删除某坐标轴(行或列)的索引,并返回一个数据的拷贝:df1 = df.reindex(index=dates[0:4], columns=list(df.columns) + [‘E’])df1.loc[dates[0]:dates[1], ‘E’] = 1df1Out[115]: A B C D F E2019-01-01 0.000000 0.000000 0.392435 5 NaN 1.02019-01-02 -2.420703 -1.116208 -0.346070 5 1.0 1.02019-01-03 1.364425 -0.947641 2.386880 5 2.0 NaN2019-01-04 -0.485980 -1.281454 0.354063 5 3.0 NaN删除空值df1.dropna(how=‘any’)Out[116]: A B C D F E2019-01-02 -2.420703 -1.116208 -0.34607 5 1.0 1.0填充空值df1.fillna(value=5)Out[117]: A B C D F E2019-01-01 0.000000 0.000000 0.392435 5 5.0 1.02019-01-02 -2.420703 -1.116208 -0.346070 5 1.0 1.02019-01-03 1.364425 -0.947641 2.386880 5 2.0 5.02019-01-04 -0.485980 -1.281454 0.354063 5 3.0 5.0判断是否为空值pd.isna(df1)Out[118]: A B C D F E2019-01-01 False False False False True False2019-01-02 False False False False False False2019-01-03 False False False False False True2019-01-04 False False False False False True运算 Operations统计注意 所有的统计默认是不包含空值的平均值默认情况是按列求平均值:df.mean()Out[119]: A -0.407230B -1.147897C 0.042373D 5.000000F 3.000000dtype: float64如果需要按行求平均值,需指定轴参数:df.mean(1)Out[120]: 2019-01-01 1.3481092019-01-02 0.4234042019-01-03 1.9607332019-01-04 1.3173262019-01-05 0.8592862019-01-06 1.545461Freq: D, dtype: float64数值移动s = pd.Series([1, 3, 5, np.nan, 6, 8], index=dates)sOut[122]: 2019-01-01 1.02019-01-02 3.02019-01-03 5.02019-01-04 NaN2019-01-05 6.02019-01-06 8.0Freq: D, dtype: float64s = s.shift(2)sOut[125]: 2019-01-01 NaN2019-01-02 NaN2019-01-03 1.02019-01-04 3.02019-01-05 5.02019-01-06 NaNFreq: D, dtype: float64这里将s的值移动两个,那么空出的部分会自动使用NaN填充。不同维度间的运算,pandas会自动扩展维度:df.sub(s, axis=‘index’)Out[128]: A B C D F2019-01-01 NaN NaN NaN NaN NaN2019-01-02 NaN NaN NaN NaN NaN2019-01-03 0.364425 -1.947641 1.386880 4.0 1.02019-01-04 -3.485980 -4.281454 -2.645937 2.0 0.02019-01-05 -6.122717 -7.789041 -5.791812 0.0 -1.02019-01-06 NaN NaN NaN NaN NaN应用通过apply()方法,可以对数据进行逐一操作:累计求和df.apply(np.cumsum)Out[130]: A B C D F2019-01-01 0.000000 0.000000 0.392435 5 NaN2019-01-02 -2.420703 -1.116208 0.046365 10 1.02019-01-03 -1.056278 -2.063849 2.433245 15 3.02019-01-04 -1.542258 -3.345303 2.787307 20 6.02019-01-05 -2.664975 -6.134345 1.995495 25 10.02019-01-06 -2.443377 -6.887383 0.254239 30 15.0这里使用了apply()方法调用np.cumsum方法,也可直接使用df.cumsum():df.cumsum()Out[133]: A B C D F2019-01-01 0.000000 0.000000 0.392435 5.0 NaN2019-01-02 -2.420703 -1.116208 0.046365 10.0 1.02019-01-03 -1.056278 -2.063849 2.433245 15.0 3.02019-01-04 -1.542258 -3.345303 2.787307 20.0 6.02019-01-05 -2.664975 -6.134345 1.995495 25.0 10.02019-01-06 -2.443377 -6.887383 0.254239 30.0 15.0自定义方法通过自定义函数,配合apply()方法,可以实现更多数据处理:df.apply(lambda x: x.max() - x.min())Out[134]: A 3.785129B 2.789041C 4.128136D 0.000000F 4.000000dtype: float64矩阵统计矩阵中每个元素出现的频次:s = pd.Series(np.random.randint(0, 7, size=10))sOut[136]: 0 21 02 43 04 35 36 67 48 69 5dtype: int64s.value_counts()Out[137]: 6 24 23 20 25 12 1dtype: int64String方法所有的Series类型都可以直接调用str的属性方法来对每个对象进行操作。比如转换成大写:s = pd.Series([‘A’, ‘B’, ‘C’, ‘Aaba’, ‘Baca’, np.nan, ‘CABA’, ‘dog’, ‘cat’])s.str.upper()Out[139]: 0 A1 B2 C3 AABA4 BACA5 NaN6 CABA7 DOG8 CATdtype: object分列:s = pd.Series([‘A,b’, ‘c,d’])sOut[142]: 0 A,b1 c,ddtype: objects.str.split(’,’, expand=True)Out[143]: 0 10 A b1 c d其他方法:dir(str)Out[140]: [‘capitalize’, ‘casefold’, ‘center’, ‘count’, ’encode’, ’endswith’, ’expandtabs’, ‘find’, ‘format’, ‘format_map’, ‘index’, ‘isalnum’, ‘isalpha’, ‘isascii’, ‘isdecimal’, ‘isdigit’, ‘isidentifier’, ‘islower’, ‘isnumeric’, ‘isprintable’, ‘isspace’, ‘istitle’, ‘isupper’, ‘join’, ’ljust’, ’lower’, ’lstrip’, ‘maketrans’, ‘partition’, ‘replace’, ‘rfind’, ‘rindex’, ‘rjust’, ‘rpartition’, ‘rsplit’, ‘rstrip’, ‘split’, ‘splitlines’, ‘startswith’, ‘strip’, ‘swapcase’, ’title’, ’translate’, ‘upper’, ‘zfill’]合并 Mergepandas`可以提供很多方法可以快速的合并各种类型的Series、DataFrame以及Panel Object。Concat方法df = pd.DataFrame(np.random.randn(10, 4))dfOut[145]: 0 1 2 30 -0.227408 -0.185674 -0.187919 0.1856851 1.132517 -0.539992 1.156631 -0.0224682 0.214134 -1.283055 -0.862972 0.5189423 0.785903 1.033915 -0.471496 -1.4037624 -0.676717 -0.529971 -1.161988 -1.2650715 0.670126 1.320960 -0.128098 0.7186316 0.589902 0.349386 0.221955 1.7491887 -0.328885 0.607929 -0.973610 -0.9284728 1.724243 -0.661503 -0.374254 0.4092509 1.346625 0.618285 0.528776 -0.628470# break it into piecespieces = [df[:3], df[3:7], df[7:]]piecesOut[147]: [ 0 1 2 3 0 -0.227408 -0.185674 -0.187919 0.185685 1 1.132517 -0.539992 1.156631 -0.022468 2 0.214134 -1.283055 -0.862972 0.518942, 0 1 2 3 3 0.785903 1.033915 -0.471496 -1.403762 4 -0.676717 -0.529971 -1.161988 -1.265071 5 0.670126 1.320960 -0.128098 0.718631 6 0.589902 0.349386 0.221955 1.749188, 0 1 2 3 7 -0.328885 0.607929 -0.973610 -0.928472 8 1.724243 -0.661503 -0.374254 0.409250 9 1.346625 0.618285 0.528776 -0.628470]pd.concat(pieces)Out[148]: 0 1 2 30 -0.227408 -0.185674 -0.187919 0.1856851 1.132517 -0.539992 1.156631 -0.0224682 0.214134 -1.283055 -0.862972 0.5189423 0.785903 1.033915 -0.471496 -1.4037624 -0.676717 -0.529971 -1.161988 -1.2650715 0.670126 1.320960 -0.128098 0.7186316 0.589902 0.349386 0.221955 1.7491887 -0.328885 0.607929 -0.973610 -0.9284728 1.724243 -0.661503 -0.374254 0.4092509 1.346625 0.618285 0.528776 -0.628470Merge方法 这是类似sql的合并方法:left = pd.DataFrame({‘key’: [‘foo’, ‘foo’], ’lval’: [1, 2]})right = pd.DataFrame({‘key’: [‘foo’, ‘foo’], ‘rval’: [4, 5]})leftOut[151]: key lval0 foo 11 foo 2rightOut[152]: key rval0 foo 41 foo 5pd.merge(left, right, on=‘key’)Out[153]: key lval rval0 foo 1 41 foo 1 52 foo 2 43 foo 2 5另一个例子:left = pd.DataFrame({‘key’: [‘foo’, ‘bar’], ’lval’: [1, 2]})right = pd.DataFrame({‘key’: [‘foo’, ‘bar’], ‘rval’: [4, 5]})leftOut[156]: key lval0 foo 11 bar 2rightOut[157]: key rval0 foo 41 bar 5pd.merge(left, right, on=‘key’)Out[158]: key lval rval0 foo 1 41 bar 2 5Append方法在DataFrame中增加行df = pd.DataFrame(np.random.randn(8, 4), columns=[‘A’, ‘B’, ‘C’, ‘D’])dfOut[160]: A B C D0 -0.496709 0.573449 0.076059 0.6852851 0.479253 0.587376 -1.240070 -0.9079102 -0.052609 -0.287786 -1.949402 1.1633233 -0.659489 0.525583 0.820922 -1.3685444 1.270453 -1.813249 0.059915 0.5867035 1.859657 0.564274 -0.198763 -1.7941736 -0.649153 -3.129258 0.063418 -0.7279367 0.862402 -0.800031 -1.954784 -0.028607s = df.iloc[3]sOut[162]: A -0.659489B 0.525583C 0.820922D -1.368544Name: 3, dtype: float64df.append(s, ignore_index=True)Out[163]: A B C D0 -0.496709 0.573449 0.076059 0.6852851 0.479253 0.587376 -1.240070 -0.9079102 -0.052609 -0.287786 -1.949402 1.1633233 -0.659489 0.525583 0.820922 -1.3685444 1.270453 -1.813249 0.059915 0.5867035 1.859657 0.564274 -0.198763 -1.7941736 -0.649153 -3.129258 0.063418 -0.7279367 0.862402 -0.800031 -1.954784 -0.0286078 -0.659489 0.525583 0.820922 -1.368544这里要注意,我们增加了ignore_index=True参数,如果不设置的话,那么增加的新行的index仍然是3,这样在后续的处理中可能有存在问题。具体也需要看情况来处理。df.append(s)Out[164]: A B C D0 -0.496709 0.573449 0.076059 0.6852851 0.479253 0.587376 -1.240070 -0.9079102 -0.052609 -0.287786 -1.949402 1.1633233 -0.659489 0.525583 0.820922 -1.3685444 1.270453 -1.813249 0.059915 0.5867035 1.859657 0.564274 -0.198763 -1.7941736 -0.649153 -3.129258 0.063418 -0.7279367 0.862402 -0.800031 -1.954784 -0.0286073 -0.659489 0.525583 0.820922 -1.368544分组 Grouping一般分组统计有三个步骤:分组:选择需要的数据计算:对每个分组进行计算合并:把分组计算的结果合并为一个数据结构中df = pd.DataFrame({‘A’: [‘foo’, ‘bar’, ‘foo’, ‘bar’, ‘foo’, ‘bar’, ‘foo’, ‘foo’], ‘B’: [‘one’, ‘one’, ’two’, ’three’, ’two’, ’two’, ‘one’, ’three’], ‘C’: np.random.randn(8), ‘D’: np.random.randn(8)})dfOut[166]: A B C D0 foo one -1.252153 0.1728631 bar one 0.238547 -0.6489802 foo two 0.756975 0.1957663 bar three -0.933405 -0.3200434 foo two -0.310650 -1.3882555 bar two 1.568550 -1.9118176 foo one -0.340290 -2.141259按A列分组并使用sum函数进行计算:df.groupby(‘A’).sum()Out[167]: C DA bar 0.873692 -2.880840foo -1.817027 -5.833961这里由于B列无法应用sum函数,所以直接被忽略了。按A、B列分组并使用sum函数进行计算:df.groupby([‘A’, ‘B’]).sum()Out[168]: C DA B bar one 0.238547 -0.648980 three -0.933405 -0.320043 two 1.568550 -1.911817foo one -1.592443 -1.968396 three -0.670909 -2.673075 two 0.446325 -1.192490这样就有了一个多层index的结果集。整形 Reshaping堆叠 Stackpython的zip函数可以将对象中对应的元素打包成一个个的元组:tuples = list(zip([‘bar’, ‘bar’, ‘baz’, ‘baz’,‘foo’, ‘foo’, ‘qux’, ‘qux’],[‘one’, ’two’, ‘one’, ’two’,‘one’, ’two’, ‘one’, ’two’]))tuplesOut[172]: [(‘bar’, ‘one’), (‘bar’, ’two’), (‘baz’, ‘one’), (‘baz’, ’two’), (‘foo’, ‘one’), (‘foo’, ’two’), (‘qux’, ‘one’), (‘qux’, ’two’)]## 设置两级索引index = pd.MultiIndex.from_tuples(tuples, names=[‘first’, ‘second’])indexOut[174]: MultiIndex(levels=[[‘bar’, ‘baz’, ‘foo’, ‘qux’], [‘one’, ’two’]], codes=[[0, 0, 1, 1, 2, 2, 3, 3], [0, 1, 0, 1, 0, 1, 0, 1]], names=[‘first’, ‘second’])## 创建DataFramedf = pd.DataFrame(np.random.randn(8, 2), index=index, columns=[‘A’, ‘B’])dfOut[176]: A Bfirst second bar one -0.501215 -0.947993 two -0.828914 0.232167baz one 1.245419 1.006092 two 1.016656 -0.441073foo one 0.479037 -0.500034 two -1.113097 0.591696qux one -0.014760 -0.320735 two -0.648743 1.499899## 选取DataFramedf2 = df[:4]df2Out[179]: A Bfirst second bar one -0.501215 -0.947993 two -0.828914 0.232167baz one 1.245419 1.006092 two 1.016656 -0.441073使用stack()方法,可以通过堆叠的方式将二维数据变成为一维数据:stacked = df2.stack()stackedOut[181]: first second bar one A -0.501215 B -0.947993 two A -0.828914 B 0.232167baz one A 1.245419 B 1.006092 two A 1.016656 B -0.441073dtype: float64对应的逆操作为unstacked()方法:stacked.unstack()Out[182]: A Bfirst second bar one -0.501215 -0.947993 two -0.828914 0.232167baz one 1.245419 1.006092 two 1.016656 -0.441073stacked.unstack(1)Out[183]: second one twofirst bar A -0.501215 -0.828914 B -0.947993 0.232167baz A 1.245419 1.016656 B 1.006092 -0.441073stacked.unstack(0)Out[184]: first bar bazsecond one A -0.501215 1.245419 B -0.947993 1.006092two A -0.828914 1.016656 B 0.232167 -0.441073unstack()默认对最后一层级进行操作,也可通过输入参数指定。表格转置df = pd.DataFrame({‘A’: [‘one’, ‘one’, ’two’, ’three’] * 3,‘B’: [‘A’, ‘B’, ‘C’] * 4,‘C’: [‘foo’, ‘foo’, ‘foo’, ‘bar’, ‘bar’, ‘bar’] * 2,‘D’: np.random.randn(12),‘E’: np.random.randn(12)})dfOut[190]: A B C D E0 one A foo -0.933264 -2.3874901 one B foo -0.288101 0.0232142 two C foo 0.594490 0.4185053 three A bar 0.450683 1.9396234 one B bar 0.243897 -0.9657835 one C bar -0.705494 -0.0782836 two A foo 1.560352 0.4199077 three B foo 0.199453 0.9987118 one C foo 1.426861 -1.1082979 one A bar -0.570951 -0.02256010 two B bar -0.350937 -1.76780411 three C bar 0.983465 0.065792通过pivot_table()方法可以很方便的进行行列的转换:pd.pivot_table(df, values=‘D’, index=[‘A’, ‘B’], columns=[‘C’])Out[191]: C bar fooA B one A -0.570951 -0.933264 B 0.243897 -0.288101 C -0.705494 1.426861three A 0.450683 NaN B NaN 0.199453 C 0.983465 NaNtwo A NaN 1.560352 B -0.350937 NaN C NaN 0.594490转换中,涉及到空值部分会自动填充为NaN。时间序列 Time Seriespandas的在时序转换方面十分强大,可以很方便的进行各种转换。时间间隔调整rng = pd.date_range(‘1/1/2019’, periods=100, freq=‘S’)rng[:5]Out[214]: DatetimeIndex([‘2019-01-01 00:00:00’, ‘2019-01-01 00:00:01’, ‘2019-01-01 00:00:02’, ‘2019-01-01 00:00:03’, ‘2019-01-01 00:00:04’], dtype=‘datetime64[ns]’, freq=‘S’)ts = pd.Series(np.random.randint(0, 500, len(rng)), index=rng)ts.head(5)Out[216]: 2019-01-01 00:00:00 2452019-01-01 00:00:01 3472019-01-01 00:00:02 1132019-01-01 00:00:03 1962019-01-01 00:00:04 131Freq: S, dtype: int64## 按10s间隔进行重新采样ts1 = ts.resample(‘10S’)ts1Out[209]: DatetimeIndexResampler [freq=<10 * Seconds>, axis=0, closed=left, label=left, convention=start, base=0]## 用求平均的方式进行数据整合 ts1.mean()Out[218]: 2019-01-01 00:00:00 174.02019-01-01 00:00:10 278.52019-01-01 00:00:20 281.82019-01-01 00:00:30 337.22019-01-01 00:00:40 221.02019-01-01 00:00:50 277.12019-01-01 00:01:00 171.02019-01-01 00:01:10 321.02019-01-01 00:01:20 318.62019-01-01 00:01:30 302.6Freq: 10S, dtype: float64## 用求和的方式进行数据整合 ts1.sum()Out[219]: 2019-01-01 00:00:00 17402019-01-01 00:00:10 27852019-01-01 00:00:20 28182019-01-01 00:00:30 33722019-01-01 00:00:40 22102019-01-01 00:00:50 27712019-01-01 00:01:00 17102019-01-01 00:01:10 32102019-01-01 00:01:20 31862019-01-01 00:01:30 3026Freq: 10S, dtype: int64这里先通过resample进行重采样,在指定sum()或者mean()等方式来指定冲采样的处理方式。显示时区:rng = pd.date_range(‘1/1/2019 00:00’, periods=5, freq=‘D’)rngOut[221]: DatetimeIndex([‘2019-01-01’, ‘2019-01-02’, ‘2019-01-03’, ‘2019-01-04’, ‘2019-01-05’], dtype=‘datetime64[ns]’, freq=‘D’)ts = pd.Series(np.random.randn(len(rng)), rng)tsOut[223]: 2019-01-01 -2.3276862019-01-02 1.5278722019-01-03 0.0639822019-01-04 -0.2135722019-01-05 -0.014856Freq: D, dtype: float64ts_utc = ts.tz_localize(‘UTC’)ts_utcOut[225]: 2019-01-01 00:00:00+00:00 -2.3276862019-01-02 00:00:00+00:00 1.5278722019-01-03 00:00:00+00:00 0.0639822019-01-04 00:00:00+00:00 -0.2135722019-01-05 00:00:00+00:00 -0.014856Freq: D, dtype: float64转换时区:ts_utc.tz_convert(‘US/Eastern’)Out[226]: 2018-12-31 19:00:00-05:00 -2.3276862019-01-01 19:00:00-05:00 1.5278722019-01-02 19:00:00-05:00 0.0639822019-01-03 19:00:00-05:00 -0.2135722019-01-04 19:00:00-05:00 -0.014856Freq: D, dtype: float64时间格式转换rng = pd.date_range(‘1/1/2019’, periods=5, freq=‘M’)ts = pd.Series(np.random.randn(len(rng)), index=rng)tsOut[230]: 2019-01-31 0.1971342019-02-28 0.5690822019-03-31 -0.3221412019-04-30 0.0057782019-05-31 -0.082306Freq: M, dtype: float64ps = ts.to_period()psOut[232]: 2019-01 0.1971342019-02 0.5690822019-03 -0.3221412019-04 0.0057782019-05 -0.082306Freq: M, dtype: float64ps.to_timestamp()Out[233]: 2019-01-01 0.1971342019-02-01 0.5690822019-03-01 -0.3221412019-04-01 0.0057782019-05-01 -0.082306Freq: MS, dtype: float64在是时间段和时间转换过程中,有一些很方便的算术方法可以使用,比如我们转换如下两个频率:1、按季度划分,且每个年的最后一个月是11月。2、按季度划分,每个月开始为频率一中下一个月的早上9点。prng = pd.period_range(‘2018Q1’, ‘2019Q4’, freq=‘Q-NOV’)prngOut[243]: PeriodIndex([‘2018Q1’, ‘2018Q2’, ‘2018Q3’, ‘2018Q4’, ‘2019Q1’, ‘2019Q2’, ‘2019Q3’, ‘2019Q4’], dtype=‘period[Q-NOV]’, freq=‘Q-NOV’)ts = pd.Series(np.random.randn(len(prng)), prng)tsOut[245]: 2018Q1 -0.1126922018Q2 -0.5073042018Q3 -0.3248462018Q4 0.5496712019Q1 -0.8977322019Q2 1.1300702019Q3 -0.3998142019Q4 0.830488Freq: Q-NOV, dtype: float64ts.index = (prng.asfreq(‘M’, ’e’) + 1).asfreq(‘H’, ’s’) + 9tsOut[247]: 2018-03-01 09:00 -0.1126922018-06-01 09:00 -0.5073042018-09-01 09:00 -0.3248462018-12-01 09:00 0.5496712019-03-01 09:00 -0.8977322019-06-01 09:00 1.1300702019-09-01 09:00 -0.3998142019-12-01 09:00 0.830488Freq: H, dtype: float64注意:这个例子有点怪。可以这样理解,我们先将prng直接转换为按小时显示:prng.asfreq(‘H’, ’end’) Out[253]: PeriodIndex([‘2018-02-28 23:00’, ‘2018-05-31 23:00’, ‘2018-08-31 23:00’, ‘2018-11-30 23:00’, ‘2019-02-28 23:00’, ‘2019-05-31 23:00’, ‘2019-08-31 23:00’, ‘2019-11-30 23:00’], dtype=‘period[H]’, freq=‘H’)我们要把时间转换为下一个月的早上9点,所以先转换为按月显示,并每个月加1(即下个月),然后按小时显示并加9(早上9点)。另外例子中s参数是start的简写,e参数是end的简写,Q-NOV即表示按季度,且每年的NOV是最后一个月。更多了freq简称可以参考:http://pandas.pydata.org/pand…asfreq()方法介绍可参考:http://pandas.pydata.org/pand…分类目录类型 Categoricals关于Categories类型介绍可以参考:http://pandas.pydata.org/pand…类型转换:astype(‘category’)df = pd.DataFrame({“id”: [1, 2, 3, 4, 5, 6],“raw_grade”: [‘a’, ‘b’, ‘b’, ‘a’, ‘a’, ’e’]})dfOut[255]: id raw_grade0 1 a1 2 b2 3 b3 4 a4 5 a5 6 edf[‘grade’] = df[‘raw_grade’].astype(‘category’)df[‘grade’]Out[257]: 0 a1 b2 b3 a4 a5 eName: grade, dtype: categoryCategories (3, object): [a, b, e]重命名分类:catdf[“grade”].cat.categories = [“very good”, “good”, “very bad”]df[‘grade’]Out[269]: 0 very good1 good2 good3 very good4 very good5 very badName: grade, dtype: categoryCategories (3, object): [very good, good, very bad]重分类:df[‘grade’] = df[‘grade’].cat.set_categories([“very bad”, “bad”, “medium”,“good”, “very good”])df[‘grade’]Out[271]: 0 very good1 good2 good3 very good4 very good5 very badName: grade, dtype: categoryCategories (5, object): [very bad, bad, medium, good, very good]排列df.sort_values(by=“grade”)Out[272]: id raw_grade grade5 6 e very bad1 2 b good2 3 b good0 1 a very good3 4 a very good4 5 a very good分组df.groupby(“grade”).size()Out[273]: gradevery bad 1bad 0medium 0good 2very good 3dtype: int64画图 PlottingSeriests = pd.Series(np.random.randn(1000),index=pd.date_range(‘1/1/2000’, periods=1000))ts = pd.Series(np.random.randn(1000),index=pd.date_range(‘1/1/2019’, periods=1000))ts = ts.cumsum()ts.plot()Out[277]: <matplotlib.axes._subplots.AxesSubplot at 0x1135bcc50>import matplotlib.pyplot as pltplt.show()DataFrame画图使用plot可以把所有的列都通过标签的形式展示出来:df = pd.DataFrame(np.random.randn(1000, 4), index=ts.index,columns=[‘A’, ‘B’, ‘C’, ‘D’])df = df.cumsum()plt.figure()Out[282]: <Figure size 640x480 with 0 Axes>df.plot()Out[283]: <matplotlib.axes._subplots.AxesSubplot at 0x11587e4e0>plt.legend(loc=‘best’)导入导出数据 Getting Data In/OutCSV写入:df.to_csv(‘foo.csv’)读取:pd.read_csv(‘foo.csv’)HDF5写入:df.to_hdf(‘foo.h5’, ‘df’)读取:pd.read_hdf(‘foo.h5’, ‘df’)Excel写入:df.to_excel(‘foo.xlsx’, sheet_name=‘Sheet1’)读取:pd.read_excel(‘foo.xlsx’, ‘Sheet1’, index_col=None, na_values=[‘NA’])异常处理 Gotchas如果有一些异常情况比如:>>> if pd.Series([False, True, False]):… print(“I was true”)Traceback …ValueError: The truth value of an array is ambiguous. Use a.empty, a.any() or a.all().可以参考如下链接:http://pandas.pydata.org/pand…http://pandas.pydata.org/pand… ...

February 25, 2019 · 13 min · jiezi

基于快速GeoHash,如何实现海量商品与商圈的高效匹配?

小叽导读:闲鱼是一款闲置物品的交易平台APP。通过这个平台,全国各地“无处安放”的物品能够轻松实现流动。这种分享经济业务形态被越来越多的人所接受,也进一步实现了低碳生活的目标。今天,闲鱼团队就商品与商圈的匹配算法为我们展开详细解读。摘要闲鱼app根据交通条件、商场分布情况、住宅区分布情况综合考虑,将城市划分为一个个商圈。杭州部分区域商圈划分如下图所示。 闲鱼的商品是由用户发布的GPS随机分布在地图上的点数据。当用户处于某个商圈范围内时,app会向用户推荐GPS位于此商圈中的商品。要实现精准推荐服务,就需要计算出哪些商品是归属于你所处的商圈。在数据库中,商圈是由多个点围成的面数据,这些面数据形状、大小各异,且互不重叠。商品是以GPS标记的点数据,如何能够快速高效地确定海量商品与商圈的归属关系呢?传统而直接的方法是,利用几何学的空间关系计算公式对海量数据实施直接的“点—面”关系计算,来确定每一个商品是否位于每一个商圈内部。闲鱼目前有10亿商品数据,且每天还在快速增加。全国所有城市的商圈数量总和大约为1万,每个商圈的大小不一,边数从10到80不等。如果直接使用几何学点面关系运算,需要的计算量级约为2亿亿次基本运算。按照这个思路,我们尝试过使用阿里巴巴集团内部的离线计算集群来执行计算,结果集群在运行了超过2天之后也未能给出结果。经过算法改进,我们采用了一种基于GeoHash精确匹配,结合GeoHash非精确匹配并配合小范围几何学关系运算精匹配的算法,大大降低了计算量,高效地实现了离线环境下海量点-面数据的包含关系计算。同样是对10亿条商品和1万条商圈数据做匹配,可以在1天内得到结果。▌点数据GeoHash原理与算法GeoHash是一种对地理坐标进行编码的方法,它将二维坐标映射为一个字符串。每个字符串代表一个特定的矩形,在该矩形范围内的所有坐标都共用这个字符串。字符串越长精度越高,对应的矩形范围越小。对一个地理坐标编码时,按照初始区间范围纬度[-90,90]和经度[-180,180],计算目标经度和纬度分别落在左区间还是右区间。落在左区间则取0,右区间则取1。然后,对上一步得到的区间继续按照此方法对半查找,得到下一位二进制编码。当编码长度达到业务的进度需求后,根据“偶数位放经度,奇数位放纬度”的规则,将得到的二进制编码穿插组合,得到一个新的二进制串。最后,根据base32的对照表,将二进制串翻译成字符串,即得到地理坐标对应的目标GeoHash字符串。以坐标“30.280245, 120.027162”为例,计算其GeoHash字符串。首先对纬度做二进制编码:将[-90,90]平分为2部分,“30.280245”落在右区间(0,90],则第一位取1。将(0,90]平分为2分,“30.280245”落在左区间(0,45],则第二位取0。不断重复以上步骤,得到的目标区间会越来越小,区间的两个端点也越来越逼近“30.280245”。下图的流程详细地描述了前几次迭代的过程: 按照上面的流程,继续往下迭代,直到编码位数达到我们业务对精度的需求为止。完整的15位二进制编码迭代表格如下: 得到的纬度二进制编码为10101 01100 01000。按照同样的流程,对经度做二进制编码,具体迭代详情如下:得到的经度二进制编码为11010 10101 01101。按照“偶数位放经度,奇数位放纬度”的规则,将经纬度的二进制编码穿插,得到完成的二进制编码为:11100 11001 10011 10010 00111 00010。由于后续要使用的是base32编码,每5个二进制数对应一个32进制数,所以这里将每5个二进制位转换成十进制位,得到28,25,19,18,7,2。 对照base32编码表,得到对应的编码为:wtmk72。 可以在geohash.org/网站对上述结果进行验证,验证结果如下:验证结果的前几位与我们的计算结果一致。如果我们利用二分法获取二进制编码时迭代更多次,就会得到验证网站中这样的位数更多的更精确结果。GeoHash字符串的长度与精度的对应关系如下: ▌面数据GeoHash编码实现上一节介绍的标准GeoHash算法只能用来计算二维点坐标对应的GeoHash编码,我们的场景中还需要计算面数据(即GIS中的POLYGON多边形对象)对应的GeoHash编码,需要扩展算法来实现。算法思路是,先找到目标Polygon的最小外接矩形MBR,计算此MBR西南角坐标对应的GeoHash编码。然后用GeoHash编码的逆算法,反解出此编码对应的矩形GeoHash块。以此GeoHash块为起点,循环往东、往北找相邻的同等大小的GeoHash块,直到找到的GeoHash块完全超出MBR的范围才停止。如此找到的多个GeoHash块,边缘上的部分可能与目标Polygon完全不相交,这部分块需要通过计算剔除掉,如此一来可以减少后续不必要的计算量。 上面的例子中最终得到的结果高清大图如下,其中蓝色的GeoHash块是与原始Polygon部分相交的,橘黄色的GeoHash块是完全被包含在原始Polygon内部的。上述算法总结成流程图如下: ▌求临近GeoHash块的快速算法上一节对面数据进行GeoHash编码的流程图中标记为绿色和橘黄色的两步,分别是要寻找相邻的东边或北边的GeoHash字符串。传统的做法是,根据当前GeoHash块的反解信息,求出相邻块内部的一点,在对这个点做GeoHash编码,即为相邻块的GeoHash编码。如下图,我们要计算"wtmk72"周围的8个相邻块的编码,就要先利用GeoHash逆算法将"wtmk72"反解出4个顶点的坐标N1、N2、N3、N4,然后由这4个坐标计算出右侧邻接块内部的任意一点坐标N5,再对N5做GeoHash编码,得到的“wtmk78”就是我们要求的右边邻接块的编码。按照同样的方法,求可以求出"wtmk72"周围总共8个邻接块的编码。这种方法需要先解码一次再编码一次,比较耗时,尤其是在指定的GeoHash字符串长度较长需要循环较多次的情况下。通过观察GeoHash编码表的规律,结合GeoHash编码使用的Z阶曲线的特性,验证了一种通过查表来快速求相邻GeoHash字符串的方法。还是以“wtmk72”这个GeoHash字符串为例,对应的10进制数是“28,25,19,18,7,2”,转换成二进制就是11100 11001 10011 10010 00111 00010。其中,w对应11100,这5个二进制位分别代表“经 纬 经 纬 经”;t对应11001,这5个二进制位分别代表“纬 经 纬 经 纬”。由此推广开来可知,GeoHash中的奇数位字符(本例中的’w’、’m’、‘7’)代表的二进制位分别对应“经 纬 经 纬 经”,偶数位字符(本例中的’t’、‘k’、‘2’)代表的二进制位分别对应“纬 经 纬 经 纬”。‘w’的二进制11100,转换成方位含义就是“右 上 右 下 左”。’t’的二进制11001,转换成方位含义就是“上 右 下 左 上”。根据这个字符与方位的转换关系,我们可以知道,奇数位上的字符与位置对照表如下: 偶数位上的字符与位置对照表如下:这里可以看到一个很有意思的现象,奇数位的对照表和偶数位对照表存在一种转置和翻转的关系。有了以上两份字符与位置对照表,就可以快速得出每个字符周围的8个字符分别是什么。而要计算一个给定GeoHash字符串周围8个GeoHash值,如果字符串最后一位字符在该方向上未超出边界,则前面几位保持不变,最后一位取此方向上的相邻字符即可;如果最后一位在此方向上超出了对照表边界,则先求倒数第二个字符在此方向上的相邻字符,再求最后一个字符在此方向上相邻字符(对照表环状相邻字符);如果倒数第二位在此方向上的相邻字符也超出了对照表边界,则先求倒数第三位在此方向上的相邻字符。以此类推。以上面的“wtmk72”举例,要求这个GeoHash字符串的8个相邻字符串,实际就是求尾部字符‘2’的相邻字符。‘2’适用偶数对照表,它的8个相邻字符分别是‘1’、‘3’、‘9’、‘0’、‘8’、‘p’、‘r’、‘x’,其中‘p’、‘r’、‘x’已经超出了对照表的下边界,是将偶数位对照表上下相接组成环状得到的相邻关系。所以,对于这3个超出边界的“下方”相邻字符,需要求倒数第二位的下方相邻字符,即‘7’的下方相邻字符。‘7’是奇数位,适用奇数位对照表,‘7’在对照表中的“下方”相邻字符是‘5’,所以“wtmk72”的8个相邻GeoHash字符串分别是“wtmk71”、“wtmk73”、“wtmk79”、“wtmk70”、“wtmk78”、“wtmk5p”、“wtmk5r”、“wtmk5x”。利用此相邻字符串快速算法,可以大大提高上一节流程图中面数据GeoHash编码算法的效率。▌高效建立海量点数据与面数据的关系建立海量点数据与面数据的关系的思路是,先将需要匹配的商品GPS数据(点数据)、商圈AOI数据(面数据)按照前面所述的算法,分别计算同等长度的GeoHash编码。每个点数据都对应唯一一个GeoHash字符串;每个面数据都对应一个或多个GeoHash编码,这些编码要么是“完全包含字符串”,要么是“部分包含字符串”。a)将每个商品的GeoHash字符串与商圈的“完全包含字符串”进行join操作。join得到的结果中出现的<商品,商圈>数据就是能够确定的“某个商品属于某个商圈”的关系。b)对于剩下的还未被确定关系的商品,将这些商品的GeoHash字符串与商圈的“部分包含字符串”进行join操作。join得到的结果中出现的<商品,商圈>数据是有可能存在的“商品属于某个商圈”的关系,接下来对这批数据中的商品gps和商圈AOI数据进行几何学关系运算,进而从中筛选出确定的“商品属于某个商圈”的关系。如图,商品1的点数据GeoHash编码为"wtmk70j",与面数据的“完全包含字符串wtmk70j”join成功,所以可以直接确定商品1属于此面数据。商品2的点数据GeoHash编码为“wtmk70r”,与面数据的“部分包含字符串wtmk70r”join成功,所以商品2疑似属于面数据,具体是否存在包含关系,还需要后续的点面几何学计算来确定。 商品3的点数据GeoHash编码与面数据的任何GeoHash块编码都匹配不上,所以可以快速确定商品3不属于此面数据。 实际应用中,原始的海量商品GPS范围散布在全国各地,海量商圈数据也散布在全国各个不同的城市。经过a)步骤的操作后,大部分的商品数据已经确定了与商圈的从属关系。剩下的未能匹配上的商品数据,经过b)步骤的GeoHash匹配后,可以将后续“商品-商圈几何学计算”的运算量从“1个商品 x 全国所有商圈”笛卡尔积的量级,降低为“1个商品 x 1个(或几个)商圈”笛卡尔积的量级,减少了绝大部分不必要的几何学运算,而这部分运算是非常耗时的。在闲鱼的实际应用中,10亿商品和1万商圈数据,使用本文的快速算法,只需要 10亿次GeoHash点编码 + 1万次GeoHash面编码 + 500万次“点是否在面内部”几何学运算,粗略换算为基本运算需要的次数约为1800亿次,运算量远小于传统方法的2亿亿次基本运算。使用阿里巴巴的离线计算平台,本文的算法在不到一天的时间内就完成了全部计算工作。另外,对于给定的点和多边形,通过几何学计算包含关系的算法不止一种,最常用的算法是射线法。简单来说,就是从这个点出发做一条射线,判断该射线与多边形的交点个数是奇数还是偶数。如果是奇数,说明点在多边形内;否则,点在多边形外。▌延伸面对海量点面数据的空间关系划分,本文采用是的通过GeoHash来降低计算量的思路,本质上来说是利用了空间索引的思想。事实上,在GIS领域有多种实用的空间索引,常见的如R树系列(R树、R+树、R*树)、四叉树、K-D树、网格索引等,这些索引算法各有特点。本文的思路不仅能用来处理点—面关系的相关问题,还可以用来快速处理点—点关系、面—面关系、点—线关系、线—线关系等问题,比如快速确定大范围类的海量公交站台与道路的从属关系、多条道路或铁路是否存在交点等问题。本文作者:峰明阅读原文本文来自云栖社区合作伙伴“ 阿里技术”,如需转载请联系原作者。

February 21, 2019 · 1 min · jiezi

数据脱敏的处理方法及查询

【摘要】1)、数据脱敏是“指对某些敏感信息通过脱敏规则进行数据的变形,实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下,在不违反系统规则条件下,对真实数据进行改造并提供测试使用,如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。是数据库安全技术之一。”2)、本文介绍的脱敏数据报表查询将利用润乾集算器编写 SPL 脚本,对敏感信息字段 (如: 姓名、证件号、银行账户、住址、电话号码、企业名称、工商注册号、纳税人识别号) 等通过预定义的脱敏规则进行数据脱敏、变形,实现敏感隐私数据的保护。 3)、润乾集算器能使脱敏工作变得的简单易行,同时可以减少大量重复性工作。通过集算器 SPL 脚本实现的脱敏数据,可直接作为报表数据集进行查询分析,也可以作为开发、测试和其它非生产环境或外包环境下的真实数据集使用。去乾学院看个究竟吧! 数据脱敏的处理方法及查询数据脱敏的处理方法及查询1.1 数据脱敏介绍根据百度词条的解释,数据脱敏是“指对某些敏感信息通过脱敏规则进行数据的变形,实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下,在不违反系统规则条件下,对真实数据进行改造并提供测试使用,如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。是数据库安全技术之一,数据库安全技术主要包括:数据库漏扫、数据库加密、数据库防火墙、数据脱敏、数据库安全审计系统。”随着信息时代的发展,我们对数据信息的安全要求越来越重视,比如对非生产环境下的敏感数据的脱敏保护。在金融、运营商、政府、能源等部门,非生产环境下数据脱敏已列入监管部门的法规要求。非生产环境数据多用于开发、测试、培训以及第三方数据分析、挖掘,如果不能有效实施敏感数据保护,极易造成敏感数据的泄露。所以,保证非生产数据的安全已经成为一个重要的课题,要求我们能够通过对敏感信息进行脱敏、变形,实现有效的数据保护。1.2 对数据脱敏工具的要求数据脱敏工具应该具有对多种异构数据源的支持,从而将一个脱敏规则应用于不同的数据源,比如针对“客户名称”字段的修改,脱敏规则基本一致,所以应该可以在 Excel、TXT、Oracle、MS SQLServer、MySQL、Hadoop 等数据源上直接引用。另外,工具还应支持将脱敏数据完全不落地分发,提供文件到文件、文件到数据库、数据库到数据库、数据库到文件等方式,并且不需要在生产系统或本地安装任何客户端。本文介绍的脱敏数据报表查询将利用润乾集算器编写 SPL 脚本,对敏感信息字段 ( 如: 姓名、证件号、银行账户、住址、电话号码、企业名称、工商注册号、纳税人识别号) 等通过预定义的脱敏规则进行数据脱敏、变形,实现敏感隐私数据的保护。润乾集算器能使脱敏工作变得的简单易行,同时可以减少大量重复性工作。通过集算器 SPL 脚本实现的脱敏数据,可直接作为报表数据集进行查询分析,也可以作为开发、测试和其它非生产环境或外包环境下的真实数据集使用。1.3 脱敏数据的特征数据脱敏不仅要执行数据漂白,抹去数据中的敏感内容,同时也需要保持原有的数据特征、业务规则和数据关联性,保证开发、测试、培训以及大数据类业务不会受到脱敏的影响,达成脱敏前后的数据一致性和有效性:l 保持原有数据特征数据脱敏前后必须保证数据特征的保持,例如:身份证号码由十七位数字本体码和一位校验码组成,分别为区域地址码(6 位)、出生日期(8 位)、顺序码(3 位)和校验码(1 位)。那么身份证号码的脱敏规就需要保证脱敏后依旧保持这些特征信息。l 保持数据之间的一致性在不同业务中,数据和数据之间具有一定的关联性。例如:出生年月或年龄和出生日期之间的关系。同样,身份证信息脱敏后仍需要保证出生年月字段和身份证中包含的出生日期之间的一致性。l 保持业务规则的关联性保持数据业务规则的关联性是指数据脱敏时数据关联性以及业务语义等保持不变,其中数据关联性包括:主、外键关联性、关联字段的业务语义关联性等。特别是高度敏感的账户类主体数据往往会贯穿主体的所有关系和行为信息,因此需要特别注意保证所有相关主体信息的一致性。l 多次脱敏之间的数据一致性相同的数据进行多次脱敏,或者在不同的测试系统进行脱敏,需要确保每次脱敏的数据始终保持一致性,只有这样才能保障业务系统数据变更的持续一致性以及广义业务的持续一致性。1.4 数据脱敏应用场景一般常见的数据脱敏场景,是将生产数据或是生产数据文件按照脱敏规则,将数据不落地脱敏至测试数据库或是测试数据文件中,具体如下所示:使用集算器的 SPL 可以按照业务场景要求自行定义和编写脱敏规则,比如针对上面的人员信息:姓名、身份证号、地址、电话号码、卡号等进行不落地脱敏,满足数据脱敏需要。集算器是一个无框架,可快速部署开发的数据计算中间件工具,能够直接运行编写好的 SPL 数据脱敏脚本即时进行数据脱敏,支持各种常见的数据脱敏的处理方式,包括数据替换、无效化、随机化、偏移和取整、掩码屏蔽、灵活编码等,本文介绍的数据脱敏方法都可以在实际应用中混合替换使用。本文中应用场景的数据脱敏都是基于下表数据内容进行的,数据存储在“数据脱敏验证表.txt”文件中。1.4.1 数据替换数据脱敏要求: 用设置的固定虚构值替换真值。例如将手机号码统一替换为 13800013800。使用集算器 SPL 编码实现的脚本,如下:A1:导入“数据脱敏验证表”的文本数据。手机号码脱敏前的显示值如下:A2:将手机号码统一数据替换。直接使用run()函数对 mobile 手机号码字段数据进行赋值替换为13800013800。数据替换后,手机号码脱敏后的显示值如下:1.4.2 无效化数据脱敏要求:通过对数据值得截断、加密、隐藏等方式使敏感数据脱敏,使其不再具有利用价值,例如将地址以 ****** 代替真值。数据无效化与数据替换所达成的效果基本类似。使用集算器 SPL 编码实现的脚本,如下:A1:导入“数据脱敏验证表”的文本数据。地址脱敏前显示值如下:A2:将地址进行数据隐藏式的无效化脱敏。直接使用run()函数对 address 地址字段数据进行无效化的 处理。数据无效化后,地址脱敏后的显示值如下:A3:将地址进行数据截断式的无效化脱敏。使用left()函数对 address 地址源字符串的左边三位字串加上 的截断无效化处理。截断无效化的地址脱敏后显示值如下:1.4.3 随机化数据脱敏要求:采用随机数据代替真值,保持替换值的随机性以模拟样本的真实性。例如用随机生成的姓和名代替真值。使用集算器 SPL 编码实现的脚本,如下:A1:导入外部姓名字典表,用于随机化替换姓名真值。此处需特别注意一下,由于“姓氏”和“名字”文本数据都是单列数据表,在使用import()函数时需要增加 @i 选项,@i 表示文本数据只有1列时返回成序列,在单元格 A3 中可以直接位置获取随机值。A2:导入“数据脱敏验证表”的文本数据。姓名脱敏前显示值如下:A3:将姓名进行随机化脱敏。直接使用run()函数对 name 姓名进行随机化,使用rand()函数从“姓氏.txt”和“名字.txt”外部字典表随机化组合生成姓名。随机化后姓名的显示值如下:【注意】这个例子中我们针对数据脱敏引入了外部字典表,实际情况中可以根据数据脱敏要求,随时引入任意外部字典表,通过数据的随机化组合,实现替换真值数据的脱敏处理。1.4.4 偏移和取整数据脱敏要求:通过随机移位改变数字数据,例如日期 2018-01-02 8:12:25 变为 2018-01-02 8:00:00,偏移取整在保持了数据的安全性的同时保证了范围的大致真实性,此项功能在大数据利用环境中具有重大价值。使用集算器 SPL 编码实现的脚本,如下:A1:导入“数据脱敏验证表”的文本数据。操作日期脱敏前显示值如下:A2:将操作日期进行时间的偏移和取整脱敏。使用使用string()函数按照偏移和取整规则格式化成“yyyy-MM-dd HH:00:00”格式,操作时间脱敏后的显示值如下:【注意】脱敏后的日期时间保持了原有的数据特征,方便脱敏数据的后续使用。1.4.5 掩码屏蔽数据脱敏要求:掩码屏蔽是针对账户类数据的部分信息进行脱敏时的有力工具,比如银行卡号或是身份证号的脱敏。使用集算器 SPL 编码实现的脚本,如下:A1:导入“数据脱敏验证表”的文本数据。身份证号脱敏前显示值如下:A2:将身份证号的出生日期进行掩码屏蔽脱敏。使用left()函数截取身份证号的左边 6 位 + 字符串 +right()函数截取身份证号右边 4 位替换源身份证字符串,身份证号码脱敏后的显示值如下:1.4.6 灵活编码数据脱敏要求:在需要特殊脱敏规则时,可执行灵活编码以满足各种可能的脱敏规则。比如用固定字母和固定位数的数字替代合同编号真值。使用集算器 SPL 编码实现的脚本,如下:码 A1:导入“数据脱敏验证表”的文本数据。合同编号脱敏前显示值如下:A2:将合同编号进行自定义编码脱敏。自定义编码规则:4 位固定码 + 当前年份 + 源目标字符串 4 位号码 +9 位数值组成,使用的函数已有介绍,不再赘述,合同编号脱敏后显示值如下:1.4.7 脱敏数据的分发集算器 SPL 支持文件到文件、文件到数据库、数据库到数据库、数据库到文件的脱敏数据分发。下面分别进行具体说明:1.4.7.1 文本分发到文本使用集算器 SPL 编码实现的文本分发到文本的脚本如下:A1-B1:引入外部字典表“姓氏”和“名字”的文本数据,用于随机组合生成姓名信息。A2:使用游标导入大数据量的“数据脱敏验证表”文本数据。A3:按照脱敏规则进行数据表脱敏。A4:直接将脱敏的数据导出到文本文件。使用export()函数导出脱敏数据,其中,其中 @t 指定将第一行记录作为字段名, 如果不使用 @t 选项就会以 _1,_2,…作为字段名,@a表示追加写, 不使用 @a 表示覆盖,分发到文本的脱敏结果如下:【注意】集算器 SPL 的文件处理能力还支持导入、导出 xls、xlsx、csv 等多种类型文件。1.4.7.2 文本分发到数据库使用集算器 SPL 编码实现的文本分发到数据库(以 MySQL 为例)的脚本如下:A1-A3:同上。A4:连接 MySQL 数据源。使用connect()进行 MySQL 数据库的连接。如果用鼠标点击 A4 单元格,可以直接查看 MySQL 数据库的连接信息。具体查看数据库配置教程相关章节文档配置说明。A5:更新 MySQL 数据库中“personinfo”库表的数据。使用update()将单元格 A3 的游标数据更新到 MySQL 数据库“personinfo”库表中。使用数据库工具查看结果如下A6:使用close()函数关闭 A4 建立起的 MySQL 数据源连接。1.4.7.3 数据库分到数据库使用集算器 SPL 编码实现的数据库分发到数据库的脚本如下(均以 MySQL 为例):A1:同上。A2:连接 MySQL 数据源。A3:游标读取 MySQL 中表“personinfo_copy”的待脱敏数据。该表的数据如下:A4:同上。A5:更新 MySQL 数据库中“personinfo_copy_test”库表的数据。使用update()将单元格 A3 的游标数据更新到 MySQL 数据库的“personinfo_copy_test”库表中。结果如下:A6:使用close()函数关闭 A2 建立起的 MySQL 数据源连接。1.4.7.4 数据库分到文本使用集算器 SPL 编码实现的数据库(以 MySQL 为例)分发到文本的脚本如下:A1-A4:同上。A5:直接将脱敏的数据库(MySQL)数据分发到文本文件。分发到文本的脱敏结果同上。A6:使用close()函数关闭 A2 建立起的 MySQL 数据源连接。1.5 脱敏数据报表查询实例下面我们就结合上面介绍的数据脱敏方法,具体实现一个可以动态配置是否脱敏数据的报表查询实例,大致流程如下:1.5.1 集算器数据脱敏 SPL 脚本准备 利用上面已有的"数据脱敏验证表.txt" 文本数据,实现脱敏数据报表查询,具体脚本如下:A1-B1:引入外部字典表“姓氏”和“名字”的文本数据,用于随机组合生成姓名信息。A2:定义一个子程序。使用func函数定义一个通用的数据脱敏规则处理子程序,该子程序主要是调用配置文件中的数据脱敏规则进行数据脱敏。不同数据字段可以根据自身特点和业务要求进行规则复用。关于子程序的内容可以参考:集算器 -> 教程 -> 高级代码 ->子程序文档说明。B3:读取数据脱敏规则配置文件信息。使用property()函数从“数据脱敏规则配置.ini”属性文件中读取 type 属性值。B4-B5:使用动态解析并计算规则配置文件中的规则,实现对应字段的数据脱敏处理。其中,子程序中使用eval()函数动态解析并计算表达式,实现动态解析并替换脱敏规则配置文件(*.ini)中的 “?” 值,增加一个 type 值判断,将一般 type 中的 “?” 替换为调用 func 子程序主格的位置值,对引入外部数据字典表的 tpye2 规则,单独判断替换 “?” 值为外部字典所在单元格值,最终计算替换的表达式并执行对应字段的数据脱敏。B6:使用宏动态计算表达式并返回运算结果,使用return函数将从属性配置文件中读取的 type 属性值通过“${}”宏替换并返回运算结果给被 B9 单元格调用的程序中。A7:游标获取未脱敏的源端生产数据。A8:通过传递的网格参数 type(type=0:不脱敏)值判断是否对数据脱敏,如果脱敏,则执行 B9 单元格的源端生产数据的脱敏处理。B9:按照脱敏规则进行数据表脱敏,直接调用 A2 主格子程序 func 进行数据脱敏。A10:根据 type 值返回对应的脱敏或未脱敏数据。接下来,需要在集算器设计器的功能菜单“程序 -> 网格参数”中设置一个参数“type”,用于接收报表参数传递进行是否脱敏的数据权限控制。至此,集算器的 SPL 脚本编写和设置完成,下一步进行“数据脱敏规则配置.ini”文件的新建设置。1.5.2 数据脱敏规则配置文件文件“数据脱敏规则配置.ini”为集算器 SPL 脚本提供了对数据字段的脱敏规则配置,从而实现脱敏规则与脚本分离的设计,可以在不修改脚本的情况下自定义脱敏规则。当然,这个配置文件也可以数存储在数据库中,提供全局的脱敏规则配置管理。该配置文件的内容如下:配置文件说明:#自定义配置脱敏规则,使用 eval() 函数实现动态解析替换解析 “?",通常 type 中的 “?” 是指固定调用 func 子程序的主格,这里 tpye2 规则特殊,需要单独判断替换 “?"。【注意】这里仅是提供一种脱敏规则的配置思路,目的是可以最大限度的复用和灵活调用,相似的数据字段就不需要重复定义和编写脱敏规则了。实际应用中,程序员们可以根据需求自定义配置。1.5.3 报表模板准备使用最新版本的润乾报表 V2018 版本开发一张报表模板,并设置报表是否脱敏参数“type”(与集算器 SPL 脚本中的网格参数对应使用)。设置集算器 SPL 脚本为报表的数据集“ds1”,选中对应的 dfx 脚本,并配置 type 参数表达式,具体如下:开发的报表模板“报表数据脱敏.rpx”如下:【注意】这里面调用的集算器数据集返回的是游标,需要在报表属性 -> 常规 设置集算器数据集为大数据集,并且该功能需要报表产品包含集算器授权。1.5.4 脱敏数据报表发布直接在报表设计器中启动 web 服务,使用浏览器浏览报表,当设置参数 type 值为“0”不脱敏时,报表展示数据如下:当参数 type 设置非“0”值时,报表展示数据如下:1.5.5 脱敏数据报表查询总结这个脱敏数据报表查询实例有以下四个特点:l 1)直接对源数据脱敏后在报表 WEB 端进行数据查询和展示。没有按常规数据脱敏的方式,先将脱敏数据进行分发入库或入文件,而是直接将数据使用集算器 SPL 脚本进行脱敏,配合报表的大数据集异步数据加载实现了大数据的即时脱敏数据查询展示。免去源数据脱敏 -> 目标入库 -> 数据展示的目标入库步骤。l 2)免去新建数据脱敏库步骤,减少脱敏工作量。为了应对一些老项目或特殊情况,比如脱敏的数据表都是明文显示,但是不能分发或新建脱敏后的数据库表,通过对明文数据直接抽取加密,免去新建脱密库步骤,减少整体脱敏工作量。l 3)自定义配置数据脱敏规则。可以灵活配置规则文件,满足不同的规则配置需求。l 4)动态控制数据是否开启脱敏权限。可以根据平台用户查看数据的权限,动态的传递参数值控制是否对数据进行脱敏显示,一方面防止数据的泄密,从底层保证数据安全,另一方面也为高权限客户提供查看敏感数据的途径。 ...

January 14, 2019 · 2 min · jiezi

深度 | 线下场景的客流数字化探索与应用

阿里妹导读:数字化的时代,无论是商场里的大小专柜,还是小区门口的便利店,大多仍处于“数据荒漠”中。店家不知道店内多少商品被人浏览,多少衣服被试穿了,作为顾客的我们也不知道哪些商品是最受同龄人喜爱的畅销好物。在新零售场景中,线下的行为数据是潜藏的宝矿。如何进行数字化升级,更好辅佐商家和消费者,成为摆在我们眼前的重要课题。下面,搜索事业部的算法专家京五将为大家详细介绍阿里在线下场景的客流数字化探索与应用。在互联网时代,数据是所有应用的基础,淘宝的商家可以基于商品历史的点击成交量来判断店内各个商品的情况,并做出相应的运营行为,淘宝的买家会根据商品历史的成交数据,评论数据等,来辅助自己判断是否进行购买,同时我们平台也会基于用户和商品的历史数据,来训练模型,预测各个商品的点击率,预测各个用户的偏好,使展示的结果更符合用户的需求。可以看出,数据对于各个不同的角色都有很重要的作用。在互联网中,获取数据相对容易,反观线下零售场景,大部分数据都是缺失的,商家并不知道店内多少商品被浏览了,多少商品被试穿了,买家也不知道各件商品的历史数据。因此,我们的客流数字化相关的探索,就是要将线下的用户和商品的行为数据收集起来,让线下的行为也能有迹可循,为商业决策和市场运营提供准确有效的数据支撑,将传统零售中的导购经验逐渐数字化成可量化和统计的数字指标,能够辅助商家运营,同时帮助用户进行决策。基于这些数据,也能够让算法在线下发挥更大的作用。整体方案整体方案如下图所示,方案涉及场外的选品策略指导,线下引流,进店的人群画像,顾客轨迹跟踪,人货交互数据沉淀,试衣镜互动/推荐,以及离店后的线上二次触达。从场外到场内再到线上,构成了整体全流程的产品方案。客流数字化探索在门店客流数字化的探索中,硬件部署上,我们使用了门店已有的监控摄像头和RFID标签,并结合视觉及射频相关技术,通过在门店部署GPU终端进行计算。技术方案上,我们基于人脸识别技术,识别进店用户的性别,年龄,新老客等基础属性,并通过行人检测跟踪与跨摄像头的行人重识别技术跟踪用户在门店内的动线变化,同时得到整体门店各个区域的热力图分布,此外,还通过摄像头与RFID 多传感器融合的技术识别用户在门店内的行为,包括翻动,试穿等,精确定位门店内各个商品的浏览与试穿频次以及用户在线下的偏好。下面会主要介绍其中的行人检测,行人重识别和动作识别这3个技术方向相关的优化。行人检测在新零售的客流数字化场景中,我们需要通过监控摄像头对门店客流的进店频次、性别、动作、行为轨迹、停留时间等全面的记录和分析。要达到我们的目标,首先需要能够检测并识别出摄像头中的行人。虽然目前YOLO等目标检测算法可以做到近乎实时的计算性能,但其评估环境都是Titan X、M40等高性能GPU,且只能支持单路输入。无论从硬件成本或是计算能力方面考虑,这些算法都无法直接应用到真实场景中。当然YOLO官方也提供了像YOLOv3-Tiny这种轻量级的模型方案,但模型性能衰减过大,在COCO上mAP下降超过40%。同时现有目标检测方案的泛化能力还比较弱,不同场景的差异对模型性能会造成较大的影响。门店场景下的视角、光线、遮挡、相似物体干扰等情况与开源数据集差异较大,直接使用基于VOC、COCO数据集训练的模型对该场景进行检查,效果非常不理想。我们分别针对模型的性能和在实际数据集的效果两方面做了相应的优化。网络结构精简与优化我们在YOLO框架的基础上对模型进行改进,实现了一种轻量级实时目标检测算法,在服饰门店的真实场景下,和YOLOv3相比,模型性能下降不超过2%,模型大小缩小至原来的1/10,在Tesla P4上对比FPS提升268%,可直接部署到手机、芯片等边缘设备上,真实业务场景中一台GTX1070可以同时支持16路摄像机同时检测,有效节约了门店改造的经济成本。标准YOLOv3的网络结构有106层,模型大小有237M,为了设计一个轻量级的目标检测系统,我们使用Tiny DarkNet来作为骨干网络,Tiny DarkNet是一个极简的网络结构,最大通道数为512,模型大小仅4M,该模型结构比YOLO官方的YOLOv3-Tiny的骨干网络还要精简,但精简网络会造成特征抽取能力的衰减,模型性能下降剧烈,在我们人工标注的2万多张服饰门店场景数据集上,替换后的Tiny DarkNet + FPN结构较原生结构的AP-50(IOU=0.5)下降30%。我们在特征抽取网络之后进行Spatial Pyramid Pooling[10],与原特征一起聚合,之后通过下采样与反卷积操作将不同层级特征合并,希望将底层的像素特征和高层的语义特征进行更充分的融合来弥补特征抽取能力的下降,整体网络结构如下图所示,精简后的检测模型大小约为原来的1/10。知识蒸馏进一步优化知识蒸馏[2]通过Teacher Network输出的Soft Target来监督Student Network学习网络中Dark Knowledge,以实现Knowledge Transfer的目的,与量化、剪枝、矩阵近似等方法常被用来实现对模型的压缩。但蒸馏与量化等方法之间又是可以互相结合的,而且蒸馏本身对模型的修改更加透明,无需特殊的依赖及执行框架。上图是我们网络蒸馏的模型结构设计,蒸馏时我们采用原生YOLOv3作为Teacher Network,虽然YOLOv3拥有较好的检测性能,且结构上与我们的模型比较相似,但直接在二者输出层之间建立L2约束,无法克服Teacher Network中的噪声及回归预测的波动,结果反而抑制了Student Network的学习。实验中发现Hint Layer的损失设计和回归预测的不确定性是蒸馏效果的核心问题,强行在对应Channel之间建立损失约束的方式过于严苛。对于普通卷积而言,我们无需要求Teacher / Student Network的Input Channel顺序保持一致,仅需要整个输入的分布是一致的。每个Channel相当于一次采样结果,相同的分布,采出的样本顺序可能多种多样,但整体结果符合相同分布,同时经过激活函数的Channel分布不再稳定,需要进行归一处理。为了避免Teacher Network回归预测本身的不稳定,回归损失设计时仍以Ground Truth为目标,将Teacher Network的Output作为Bound,仅对误差大于Teacher Network的部分进行约束,本质上是在借Teacher Network来进行Online Hard Example Mining。行人重识别行人重识别(Person Re-identification)问题是指在跨摄像头场景下,给定待查找的行人图片,查找在其他摄像头是否出现该人。一般用来解决跨摄像头追踪。在线下门店场景中,每个门店都会在各个不同的区域安装摄像头,当顾客在店内逛时,我们需要了解用户是如何在各个区域之间活动,了解各个区域客流的去向与来源,因此需要将各个不同摄像头中同一个行人进行关联。行人特征提取行人重识别的难点在于,多个摄像头下拍摄行人的角度不同,图像中的行人可能72变,同时还有可能会有不同程度的遮挡,导致直接使用整体的行人特征来做重识别非常具有挑战性,那能不能用人脸识别做行人重识别?理论上是可以的,但是在实际场景中非常难应用,首先,广泛存在后脑勺和侧脸的情况,做正脸的人脸识别难,其次,摄像头拍摄的像素可能不高,尤其是远景摄像头里面人脸截出来很可能都没有32x32的像素。所以人脸识别在实际的重识别应用中存在很大的限制。行人重识别问题中,如何学得一个鲁棒的行人特征表示成为了一个很关键的问题。学得行人特征表示最直观的方式是直接以整张行人图片作为输入,提取一个全局特征,全局特征的目标是学到能够区分不同行人之间最突出的信息,比如衣服颜色等,来区分这个行人。然而监控场景的复杂性,使得这样的方法的准确性受到了很大的限制,比如,各个摄像头之间存在色差,并且门店的不同区域的光照条件会有差异,此外,还有很多穿相似服装的行人。同时由于目前行人重识别数据集在体量及丰富性上有比较大的欠缺,一些不突出,不频繁出现的细节特征在全局特征的训练中很容易被忽略。要解决上面提到的问题,使用局部特征替换全局特征是一个比较好的解决方案,基于局部特征的行人重识别方法将原始输入表示成多个特征块,每一个特征块代表一个局部的特征,基于局部特征的方法能够更关注行人的局部细节方面的特征。基于局部特征的方法,也存在一些问题,这一类方法将行人划分为各个独立的语义分块,并没有考虑各个局部特征之间的关联,因此,在我们的方案中,我们使用到了多级局部特征的融合方案,在考虑各个局部特征的同时考虑多个局部特征的关联关系,具体网络结构如下图所示,在原始的局部特征的基础之上增加了多个不同尺度的局部特征以及全局特征,学到的特征不仅能够表示各个部位的细节特征,还能表达不同部位融合在一起的特征,相较原始版本更加丰富化。目前基于此版本模型还在持续优化中,在Market数据集上Rank@1能达到96.19%,使用同样骨干网络结构的情况下提取全局特征的版本的Rank@1只能达到89.9%,而仅使用local特征的版本Rank@1能够达到92.5%,融合的方案相比两个版本均有较明显的提升。跨数据集的行人重识别的探索与尝试由于线下场景的特殊性,我们的模型需要部署到各家不同的门店,各个门店的光线,环境存在很大的差异,不同门店的摄像头安装的角度也会有些许不同,因此我们在一个数据集上训练的模型可能并不适用于所有门店,然而我们又不可能逐家门店去做数据的标注,因此,我们想通过一种方式,让我们的模型能够自适应到新的门店的数据中。在门店中,由于顾客是在一个封闭空间,因此顾客在各个摄像头之间的转移是存在一定的规律的,比如说:顾客肯定是最先出现在门口的摄像头,顾客只能在相邻的两个区域之间进行转移等,基于门店场景的特性,我们首先尝试了基于摄像头时空信息的混合模型,参考[7],模型结构如下图所示:混合模型首先基于原始的视觉特征的分类器来计算各个摄像头以及不同时间间隔之间转移的概率分布,再使用时空信息与原始分类器结合得到最终的结果。人货动作检测除了基础的客流动线数据以外,顾客在门店中的行为数据也是非常有价值的,我们尝试使用视觉结合RFID射频信号的融合方案,试图解决顾客在门店中与货物的交互问题,即哪个顾客在什么地点翻动/拿起了哪一件商品,比较类似线上的点击数据。人货交互的数据在线下是很重要的一个环节,人货交互的数据可以让商家知道哪些商品被翻动的多,了解哪些商品比较能够吸引顾客,哪一类顾客更喜欢哪些风格的商品,同时这一部分数据也完善了整个门店的漏斗转化,以前商家仅仅能根据成交来判定每个商品的受欢迎程度,而有些潜在畅销款可能是由于摆放的位置不恰当,导致可能根本没有顾客仔细看到,导致最终成交额较低,同时有的商品虽然成交笔数不少,但是实际上被顾客拿起的次数也特别多,可能是因为这件商品在一个更显眼的位置,相比同样成交笔数的拿起次数较少的商品,实际转化率更低。补全这个环节的数据对商家的线下运营有很关键的作用,同时这一部分行为数据在商家线上线下商品打通之后为线上服务起到最重要的作用。人货交互的数据是目前线下数据缺失的比较严重的环节,商家一般都能很容易的拿到商品的成交的统计数据,而人货交互的数据由于发生更频繁,且不易判断,因此整体数据的收集难度比较高,此外人货交互的数据需要精确到具体的SKU,单纯的顾客发生了动作并没有太大的意义,因此在人货动作检测的方案上,我们设计了一套结合视觉技术和RFID射频信号的融合方案,得到最终的人货交互数据。下图为整体方案:门店中装配有监控摄像机设备与RFID接收器器设备,分别录制实时视频与RFID标签受激反射的 时序信号,首先基于回传的RFID信号与检测哪些RFID标签可能被翻动了,由于店铺服务员已经将RFID标签的EPC编号与商品的 SKU编号关联入库,基于被翻动的标签EPC编号可以取到对应商品的SKU,同时,使用回传的顾客图片检测出疑似有在翻动商品的顾客,并根据顾客的图像坐标进行坐标变换,得到该顾客的真实物理坐标,最后,将检测出的疑似被翻动的商品与疑似有翻动商品动作的顾客进行关联,得到商品与行人的最佳匹配。其中基于RFID射频技术的商品动作识别是一个比较新的尝试。当顾客翻动衣服时,衣服上的RFID标签会随之发生微小抖动,RFID接收机设备记录标签反射的信号RSSI,Phase等特征值的变化,回传到后台,算法通过对每个天线回传的信号值进行分析判断商品是否发生翻动。基于RFID信号判断商品翻动存在诸多问题,包括信号自身噪声、环境多径效应、偶然电磁噪声、货柜对信号遮挡的影响等。同时RFID反射信号的大小与接收器离标签距离远近存在非线性关系,其中,d代表RFID标签与接收器之间距离, ,受Multipath和当前环境的影响,表示各种静态设备误差带来的偏移。从公式中可以看出,接收器安装的位置,商店环境等都会给RFID信号带来很大影响,寻找统一的可以适用于不同商店、不同位置接收器的翻动判断算法存在很大挑战。最初的版本我们使用RSSI和Phase的原始值作为特征值来训练模型,这样的模型存在一个问题,在我们的样本不充足的情况下,受环境的影响较大,在真实环境中往往不能达到离线测试的结果,因此,我们试图基于原始的信号值产生于空间位置不那么强相关的特征值来辅助动作的判断。虽然频率信息中的幅度信息与空间位置存在关系,但是当我们只关注于频率分布(不同频率成份的占比)时,可以将频率信息也当成与空间位置信息无关的特征。频率信息的获取需要对RSSI信号与Phase信号进行离散傅利叶变换, 然后统计频率信号与相位信号的分布图。对得到的分布图,计算当前分布与前一个时刻分布的JS散度(相对于KL散度,JS散度具有加法的对称性,因此可以用来衡量多个分布之间的相对距离)。基于相邻时刻前后两个样本的JS散差异的版本在我们的测试数据上能够达到94%的识别精度,相比最初版本基于原始的RSSI值和phase值作为特征的版本的91.9%的精度,有一定的提升。基于图像的顾客动作检测是经典的分类问题,为了减小对计算能力的需求,我们使用了:MobileNet[12]对行人检测的图像进一步分类,并根据模型Logits输出进行了最优化参数寻优,在保持分类精度时,提高正例召回率,确保正例尽可能被召回,如下图所示。我们通过时间关联程度与动作可疑程度两个维度同时进行匹配,使得最终的匹配行人与翻动商品的准确率达到85.8%。客流数字化应用客流数字化产出的客流相关数据不仅仅用于商家的线下运营,同时我们也基于这部分数据在线下场的流量分发上有一些初步应用,淘宝是线上的一个很大的流量分发的入口,淘宝的搜索和推荐决定了消费者当前能看到哪些商品,也同时影响了各个商家和商品的整体流量情况,搜索和推荐就是将商家、商品和用户做匹配,将适当的商品展示给合适的用户,满足消费者的购物体验的同时,也平衡各个商家商品的流量分配,避免流量的浪费,实现流量的最大化的价值。在线下商场,也有一样的流量分发的需求。但是线下场相比线上,有两个比较大的挑战:1) 线下目前没有统一的入口,类似线上的搜索和推荐应用,无法触达到用户;2) 线下没有类似线上丰富的日志和行为数据,没有数据支撑比较难做到精准的个性化,无法优化效果。在线下场的流量分发的探索中,我们使用商场已有的互动屏幕、门店的互动屏幕作为流量分发的出口,同时,利用前文提到的客流数字化沉淀的数据来支撑线下场的个性化流量分发。场外引流屏场外引流屏的作用,是进行第一级的流量分发,首先需要通过不同的互动玩法,营销活动吸引用户,再通过屏幕对用户进行个性化的优惠券投放,引导用户进入不同的门店。在传统商场中,用户刚进来商场,可能会随机地在这个楼层进行活动,当看到感兴趣的品牌完成进店的活动,或者用户会基于导览屏,大概了解商场楼层的品牌分布情况,再进行有一定针对性的浏览。而我们的引流屏的作用是将合适的优惠推荐给对应的人,从而引导用户进店,相当于在商场中岛进行整体的流量分发,将集中在中岛的用户往各个不同的方向进行引导。整体方案如下图所示:整体方案依赖三部分的数据,分别是基于用户的图像特征产出的人群属性数据,以及各个店铺的进店人群分布数据和店铺的其他统计量的特征,基于用户当前的属性特征与店铺的人群分布进行匹配,可以得到初步的个性化的店铺推荐结果,此外,使用店铺本身的统计量特征作为辅助信息,在同等匹配条件下额外考虑各个店铺本身的热度,效率等维度特征,以及当前所提供的优惠券的力度信息,得到最终的优惠券的排序,并展示给用户。场内试衣屏场内试衣屏的作用是做第二层的流量分发,即用户进店后,需要推荐哪些商品展示给用户。在传统的门店中,用户进店后会在店内进行随机的浏览,对于感兴趣的衣服会找导购员提供试穿,试穿后导购员也会对顾客进行推荐。整个过程中存在一些问题,首先,用户对于商品的浏览和商品摆放的位置关系很大,橱窗的商品会更容易吸引用户注意,而部分较密集的衣架区,用户可能没有办法注意到部分货品;其次,试穿之后导购进行的推荐也会因人而异,和导购本身的素质关系也较大,有些经验丰富的导购员可以根据你个人的长相气质推荐更适合你的商品,而更多的导购员只能简单的基于当前的热销款来进行推荐,无法做到因人而异。试衣屏推荐要解决的就是上述的两个问题,整体展现形式如下图:在用户进行试穿时,会在镜子侧方显示商品的详情信息,包括目前商品是否有折扣等,同时会基于用户的试穿行为,推荐相关商品与搭配商品,给部分商品一次额外的展示机会,同时也能够基于用户的试穿以及用户当前的图像特征给出个性化的推荐结果,方便用户的选购,即使用户暂时没有这个消费习惯,镜子屏幕上的推荐结果也能对导购员进行一些辅助决策,能够帮助导购员给用户推荐更加个性化更加丰富的商品。整体算法方案如下图所示:考虑到隐私问题,在我们的应用中,我们不去尝试通过人脸关联到对应的id,仅在场内通过用户的行为和其他用户行为的相似性进行推荐。工程实现AI inference是GPU终端计算重要的一环,最开始探索的时候,AI inference采用串行模式:通过观察测试数据,我们惊讶地发现,虽然程序已经处于视频流图片处理饱和的状态,但是6核心CPU的使用率才到150%,GPU的使用率才到30%,也就是说,超过一半的硬件资源处于闲置状态。 为了使得原本间歇性闲置的资源得到重新的利用,我们改造成了流水线模式,结构图如下所示:在多进程实现的流水线方案中,由于每个进程的数据都是相互独立的,一个进程产生或修改的数据对另一个进程而言它是无感知。如何提高进程间的数据传递是能否高效实现并发的关键点。 我们采用了基于mmap ctypes实现的共享内存,对比管道、socket多进程通讯机制,共享内存在多进程数据通讯方案中是非常高效和灵活,参考multiprocessing Value的解决方案,使用ctypes内置的基本数据结构来实现我们的数据模型,非常方便的进行内存切分并转换成可用的数据结构。结合业务情况,我们的流水线工作模式会将各个阶段分割为子任务,我们还设计了图片共享队列,整个过程只需要写入一次图片数据,各个阶段只需要从这个共享队列读取图片即可,等所有流程都操作完之后再从图片队列删除这个图片数据,这样就能保证图片操作的正确性和高效性。通过测试发现,我们实现的共享内存队列在读取数据上比pipe方式快了300多倍。业务效果目前我们客流数字化的数据已经沉淀到相应的产品,以下是基础客流的示意图,品牌商可以看到门店每日的基础客流量以及分时段的客流情况,了解各个门店当前的经营状况。下图为区域热力图和区域动线图,区域热力图展示了门店在一天内各个小时各个区域的人流量密度情况,我们将各个不同摄像头的数据进行整合,最终映射到门店的平面CAD图上展示区域热力,让门店能够更直观的看到各个区域的热度,区域动线图展示了各个区域客流的去向和来源的占比,基于区域热力和动线数据,商家能够清晰的了解到门店各个区域的密度情况以及各个区域之间顾客的转移情况,目前合作的品牌商也会基于区域的数据对店内的陈列做适当的调整,甚至有门店基于动线的数据重新调整整个门店的区域分布情况。 下图为门店进店客流的人群画像,展示了门店每天进店客流的性别和年龄的分布,商家会基于进店的人群画像数据与当前品牌的目标人群进行对比,并基于实际进店客流的分布调整门店陈列商品的品类结构以及不同类型商品的占比。本文作者:京五阅读原文本文来自云栖社区合作伙伴“阿里技术”,如需转载请联系原作者。

January 8, 2019 · 1 min · jiezi

阿里云图数据库GraphDB上线,助力图数据处理

GraphDB简介GraphDB图数据库适用于存储,管理,查询复杂并且高度连接的数据,图库的结构特别适合发现大数据集下数据之间的共性和特性,特别善于释放蕴含在数据关系之间的巨大价值。GraphDB引擎本身并不额外收费,仅收取云hbase费用。适合的业务场景在如下多种场景中图数据库比其他类型数据库(RDBMS和NoSQL)更合适推荐及个性化几乎所有的企业都需要了解如何快速并且高效地影响客户来购买他们的产品并且推荐其他相关商品给他们。这可能需要用到云服务的推荐,个性化,网络分析工具。如果使用得当,图分析是处理推荐和个性化任务的最有效武器,并根据数据中的价值做出关键决策。举个例子,网络零售商需要根据客户过往消费记录及订单推荐其他商品给这个客户。为了能成功的达到目的,当前回话下用户浏览操作等都可以实时集成到一张图中。图非常适合这些类似的分析用例,如推荐产品,或基于用户数据,过去行为,推荐个性化广告。电商商品推荐案例如何使用GraphDB做商品实时推荐安全和欺诈检测在复杂及高度相关的用户,实体,事务,时间,交互操作的网络中,图数据库可以帮助检测哪些实体,交易,操作是有欺诈性质的,从而规避风险。简而言之,图数据库可以帮助在数不清金融活动中产生的关系及事件组成的海量数据集中找到那根坏针。某深圳大数据风控案例客户介绍:该大数据有限公司专注于为银行、消费金融、三方支付、P2P、小贷、保险、电商等客户解决线上风险和欺诈问题。案例背景及痛点近几年互联网金融行业兴起,诞生了很多互联网金融企业,用户参加线上贷款,金融消费,P2P融资等金融活动门槛大大降低,在这些金融行为中如何有效规避风险,进行风控是每个金融企业面临的比较严峻的问题。用户的金融行为中会沉淀大量有价值的数据,在白骑士客户小贷场景中会产生一笔笔贷款记录关联的手机号,身份证,银行卡号,设备号等。这些数据代表一个个实体人,正常金融活动中,贷款,金融服务不是高频行为,一个实体人一般有一个唯一身份证,常用银行卡号,手机号,设备号。这几者顶点见不会产生高密度图,但有一些高危低信用用户可能会使用同一手机设备申请贷款进行骗贷。客户痛点在于如何高效识别这些高危低信用用户。解决方案建立图模型分别创建手机号,设备号,身份证,银行卡号四类顶点及相互关联的边,扩展属性便于查询。从原数据仓库清洗后通过graph-loader工具导入GraphDB在线评估用户信用资质在申请贷款流程中,可以通过使用图库可以实时查询图中任意一手机号关联的身份证数量(一跳/二跳查询),恶意申请有如下特点,关联子图各类顶点过多,并且可能关联上离线分析标注过得黑名单用户,说明当前用户存在恶意申请风险,实时拒掉贷款申请。下图显示如何与自身小贷平台打通,做实时风控预警,箭头方向代表数据流方向。主动识别黑名单用户借助spark graphframes分析能力,离线计算全图中各个顶点出入度及pagerank,主动挖掘超级顶点,超级顶点如一个手机号关联了多个身份证顶点,说明该用户金融活动频繁,背后的故事是一个实体人有多笔申请记录,分别关联了不同的身份证,手机号,说明该用户在进行恶意欺诈活动,人工标注黑名单用户,从源头禁掉用户金融活动。物联网物联网(IoT)是另一个非常适合图数据库领域。 物联网使用案例中,很多通用的设备都会产生时序相关的信息如事件和状态数据。在这种情况下,图数据库效果很好,因为来自各个独立的终端的流汇聚起来的时候产生了高度复杂性此外,涉及诸如分析根本原因之类的任务时,也会引入多种关系来做整体检查,而非隔离检查。GraphDB特性整体架构使用Apache TinkerPop构建GraphDB是Apache TinkerPop3接口的一个实现,支持Tinkerpop全套软件栈,支持Gremlin语言,可以快速上手。在GraphDB中,为应对不同的业务场景,数据模型已经做到尽可能的灵活。例如,GraphDB中点和边均支持用户自定义ID;自定义ID可以是字符串或数字;属性值可以是任意类型,包括map,数组,序列化的对象等。因此,应用不需要为了适应图数据库的限制而做多余的改造,只需要专注在功能的实现上面。GraphDB具有完善的索引支持。支持对顶点建立label索引和属性索引;支持对边建立label索引,属性索引和顶点索引;支持顶点索引和边索引的范围查询和分页。良好的索引支持保证了顶点In/Out查询和根据属性查找顶点/边的操作都具有很好的性能。与HBase深度集成GraphDB使用企业认证的HBase版本作为其持久数据存储。 由于与HBase的深度集成,GraphDB继承了HBase的所有主要优势,包括服务可用性指标,写/读/时刻都在线高可用功能,线性可扩展性,可预测的低延迟响应时间,hbase专家级别的的运维服务。 在此基础上,GraphDB增强了性能,其中包括自适应查询优化器,分片数据位置感知能力。使用spark graphframes做图分析借助阿里云HBase X-Pack提供的Spark产品,可以对GraphDB中的图数据进行分析。作为优秀的大数据处理引擎,Spark能够对任意数据量的数据进行快速分析,Spark支持scala、java、python多种开发语言,可本地调试,开发效率高。此外,阿里云HBase X-Pack的Spark服务通过全托管的方式为用户提供企业级的服务,大大降低了使用门槛和运维难度。Spark GraphX中内置了常见的图分析操作,例如PageRank、最短路径、联通子图、最小生成树等。云上大规模GraphDB优势全托管,全面解放运维,为业务稳定保驾护航大数据应用往往涉及组件多、系统庞杂、开源与自研混合,因此维护升级困难,稳定性风险极高。云HBase GraphDB提供的全托管服务相比其他的半托管服务以及用户自建存在天然的优势。依托持续8年在内核和管控平台的研发,以及大量配套的监控工具、跨可用区、跨域容灾多活方案,GraphDB的底层核心阿里云HBase提供目前业界最高的4个9的可用性(双集群),11个9的可靠性的高SLA的支持,满足众多政企客户对平台高可用、稳定性的诉求。使用阿里云GraphDBGraphDB引擎包含在HBase 2.0版本中,用户在购买云上HBase数据库服务时,可以选择GraphDB作为其图数据引擎。GraphDB引擎本身并不额外收费,对于需要使用图数据功能的用户而言,将大幅降低应用和开发成本。了解更多关于阿里云云数据库HBase及图引擎GraphDB请戳链接:产品入口:https://cn.aliyun.com/product/hbase?spm=5176.224200.100.35.7f036ed6YlCDxm帮助文档:https://help.aliyun.com/document_detail/92186.html?spm=a2c4g.11174283.6.610.260d3c2eONZbgs本文作者:恬泰阅读原文本文为云栖社区原创内容,未经允许不得转载。

January 2, 2019 · 1 min · jiezi

阿里云时空数据库引擎HBase Ganos上线,场景、功能、优势全解析

摘要: 2018年12月18日,伴随阿里云HBase全新发布X-Pack全托管NoSQL数据库平台,HBase Ganos时空数据库引擎正式上线。HBase Ganos以阿里云飞天操作系统为强大底座,结合云HBase新一代KV、时序、时空、图多模数据综合处理能力以及云上Spark大数据分析计算服务,为迎接在线时空全量大数据应用构筑PaaS(Platform-as-a-Service)平台能力。随着全球卫星导航定位系统、传感网、移动互联网、IoT等技术的快速发展,越来越多的终端设备连接至网络,由此产生了大规模的时空位置信息,如车辆轨迹、个人轨迹、群体活动、可穿戴设备时空位置等。这些数据具有动态变化(数据写入频繁)、时空多维、规模巨大、价值随时间推移而衰减、空间搜索和时序查询相结合等特征,这对传统数据库带来了新的挑战。2018年12月13日,伴随阿里云HBase全新发布X-Pack全托管NoSQL数据库平台,HBase Ganos时空数据库引擎正式上线。Ganos取名于大地女神盖亚(Gaea)和时间之神柯罗诺斯(Chronos),代表着“时空” 结合。HBase Ganos以阿里云飞天操作系统为强大底座,结合云HBase新一代KV、时序、时空、图多模数据综合处理能力以及云上Spark大数据分析计算服务,为迎接在线时空全量大数据应用构筑PaaS(Platform-as-a-Service)平台能力。1、适用场景举例互联网出行互联网出行涉及到运力的调度、拼车、供需预测、热力图等业务。以供需预测为例,基于对历史轨迹数据的分析,并结合实时订单数据,预测当前订单密集区域的分布,提高接单概率并减少司机空驶时间。这背后涉及到大量时空型数据和业务信息的快速读取,并结合业务算法进行预测,利用HBase Ganos可有力支持该业务场景。IoTIoT行业产生的数据兼具时序和空间特征。以车联网为例,海量的车辆终端在不断地产生轨迹数据,轨迹数据包含了时间和空间位置。利用HBase Ganos,实时监测车辆的行驶轨迹、是否偏航、是否进入某个限制区域等。除了实时监控外,还可以进行实时时空查询,如查询某段时间的轨迹,某段时间进入该区域的车辆等。结合大数据分析框架(如Spark)还可以进行穿越分析、区域分布热力图等。智慧物流与外卖递送在物流与外卖等领域,需要实时监控车辆、骑手的位置,以便进行可靠的时间预测等服务。车辆和骑手的位置需要实时上报,云端需要处理高并发写入并进行实时路径规划、偏航监测等计算,背后都需要大量的时空计算。 传感网与实时GIS在环保、气象、水利、航空监测等领域,需要通过各种传感器获取天、空、地、海不同地理现象、事件、要素的全生命周期多尺度监测指标,比如污染监测、水位监测、降雨量监测、航标监测等。HBase Ganos可以为构建实时GIS大数据应用提供稳定、可靠、弹性、免运维的PaaS服务,为地理国情常态化监测和智慧城市建设提供基础平台。2、HBase Ganos主要功能与特性PB级时空数据存储与高并发写入基于阿里云HBase存储计算分离和完全分布式系统架构, Ganos引擎可支撑TB-PB级时空数据的存储与管理需求,且存储节点可弹性扩展。针对GNSS、传感网、移动APP等千万甚至上亿终端的数据采集,HBase Ganos在提供高效时空索引的同时,结合HBase LSM模型,可满足高并发数据写入需求,其中一个最小的HBase Ganos集群节点写入速度可达到数十万QPS,数据规模可达千亿记录级别。遵循OpenGIS标准规范,支持多种空间数据类型与访问接口引擎遵循OpenGIS标准规范,支持完备的时空点、线、面等常用数据结构,这些数据结构可对应于现实中的POI兴趣点、道路与车辆轨迹、地理围栏等。常见的地理围栏判断、轨迹数据查询与计算、空间搜索等均可完美支持。接口层面上,提供了多种访问方式,包括基于GeoTools API的访问、支持GeoJson作为时空数据结构的REST API、以及即将推出的GeoSQL支持,可最大程度兼容不同用户需求。高效的时空索引与算法分析包引擎以Z-Order、Hilbert等空间填充曲线为基础,支持二维和三维时空索引,百亿量级的时空条件查询可到秒级,完全能够满足海量时空数据的在线处理业务需求。此外,针对常用的时空分析场景,引擎在HBase中内嵌了轨迹抽稀、轨迹相似度计算、密度图等分析算法包,可充分利用HBase协处理器等技术带来的并行优势,加快查询性能、减轻业务层代码量。结合流式计算引擎支撑实时大数据处理为了满足对实时数据分析计算需求,HBase Ganos流数据处理框架基于Lambda架构设计开发,融合了不可变性、复杂性隔离和读写分离等一系原则,具备低延时、高容错、易于扩展等特性。数据接入层面,支持Kafka等消息中间件的实时接入,将基于事件的数据流直接转换到内部数据源。数据分析层面,与Spark Streaming或Flink流数据引擎无缝集成,具备了实时地在任意大数据集上进行数据流查询分析的能力,帮助用户随时随地快速准确地应对复杂的实时数据处理场景。3、云上大规模时空数据处理的优势K-V、时序、时空、图多模型(Multi-Model)助力综合业务场景建模对于互联网和政企客户而言,时空场景虽然是一种重要业务类型,但要支撑好复杂业务系统开发,更多时候需要具备多模型支撑能力。针对这类业务系统,阿里云HBase X-Pack提供了强大的多模式处理能力,不仅支持时空,还支持K-V、时序和图模型等,每一类模型都内置有丰富数据处理能力。Ganos作为其中的时空数据引擎,能够与其他引擎结合,做到开箱即用,满足用户多维度的查询分析需求,让业务开发效率大幅提升。冷热混合存储,助你不改代码,1/3成本轻松搞定冷数据处理时空大数据应用场景下,存储成本占比往往是大头,把存储成本降下来,整体成本才能下降。针对时空数据的价值随时间而衰减的特性,提供了将访问量极少,访问延迟要求不高的历史数据按规则(比如一个月之前的数据)自动转储到阿里云OSS冷存储介质中,其存储成本可下降为高效云盘的1/3,写入性能与云盘相当,并能保证数据随时可读,从而降低存储成本,基本不用改代码就获得了低成本存储能力。全托管,全面解放运维,为业务稳定保驾护航大数据应用往往涉及组件多、系统庞杂、开源与自研混合,因此维护升级困难,稳定性风险极高。云HBase Ganos提供的全托管服务相比其他的半托管服务以及用户自建存在天然的优势。依托持续8年在内核和管控平台的研发,以及大量配套的监控工具、跨可用区、跨域容灾多活方案,Ganos的底层核心阿里云HBase提供目前业界最高的4个9的可用性(双集群),11个9的可靠性的高SLA的支持,满足众多政企客户对平台高可用、稳定性的诉求。4、HBase Ganos实操使用途径Ganos时空引擎包含SQL版和NoSQL版,此次发布的HBase Ganos为NoSQL版,主要服务于在线全量时空大数据应用。引擎包含在HBase 2.0版本中,用户在购买云上HBase数据库服务时,可以选择Ganos作为其时空引擎。Ganos引擎本身并不额外收费,这对于需要使用GIS或时空大数据功能的用户而言,将大幅降低应用和开发成本。Ganos将逐步沉淀基础时空云计算能力到云计算基础平台,赋能ISV厂商,推动时空云计算作为数字化转型的基础引擎普惠到更多客户。本文作者:ganos阅读原文本文为云栖社区原创内容,未经允许不得转载。

December 21, 2018 · 1 min · jiezi

如何创建一个数据科学项目?

摘要: 在一个新的数据科学项目,你应该如何组织你的项目流程?数据和代码要放在那里?应该使用什么工具?在对数据处理之前,需要考虑哪些方面?读完本文,会让你拥有一个更加科学的工作流程。假如你想要开始一个新的数据科学项目,比如对数据集进行简单的分析,或者是一个复杂的项目。你应该如何组织你的项目流程?数据和代码要放在那里?应该使用什么工具?在对数据处理之前,需要考虑哪些方面?数据科学是当前一个不太成熟的行业,每个人都各成一家。虽然我们可以在网上参照各种模板项目、文章、博客等创建一个数据科学项目,但是目前也没有教科书对这些知识做一个统一的回答。每个数据科学家都是从经验和错误中不断的探索和学习。现在,我逐渐了解到什么是典型的“数据科学项目”,应该如何构建项目?需要使用什么工具?在这篇文章中,我希望把我的经验分享给你。工作流程尽管数据科学项目的目标、规模及技术所涉及的范围很广,但其基本流程大致如下:如上图所示,项目不同,其侧重点也会有所不同:有些项目的某个过程可能特别复杂,而另一些项目可能就不需要某一过程。举个例子来说,数据科学分析项目通常就不需要“部署”(Deployment)和“监控”(Monitoring)这两个过程。现在,我们逐一来细说各个过程。源数据访问不管是你接触到人类基因组还是iris.csv,通常都会有 “原始源数据”这一概念。数据有很多种形式,可以是固定的,也可以是动态变化的,可以存储在本地或云端。其第一步都是对源数据访问,如下所示:源数据是*.csv文件集合。使用Cookiecutter工具在项目的根文件夹中创建一个data/raw/子目录,并将所有的文件存储在这里;创建docs/data.rst文件描述源数据的含义。源数据是*.csv文件集合。启动SQL服务器,创建一个raw表,将所有的CSV文件作为单独的表导入。创建docs/data.rst文件描述源数据及SQL Server位置。源数据是基因组序列文件、患者记录、excel及word文档组合等,后续还会以不可预测的方式增长。这样可以在云服务器中创建SQL数据库,将表导入。你可以在data/raw/目录存储特别大的基因组序列,在data/raw/unprocessed目录存储excel和word文件;还可以使用DVC创建Amazon S3存储器,并将data/raw/目录推送过去;也可以创建一个Python包来访问外部网站;创建docs/data.rst目录,指定SQL服务器、S3存储器和外部网站。源数据中包含不断更新的网站日志。可以使用ELK stack 并配置网站以流式传输新日志。源数据包含10万张大小为128128像素的彩色图像,所有图像的大小则为100,0001281283,将其保存在HDF5文件images.h5中。创建一个Quilt数据包并将其推送给自己的私人Quilt存储库;创建/docs/data.rst文件,为了使用数据,必须首先使用quilt install mypkg/images导入工作区,然后再使用 from quilt.data.mypkg import images导入到代码中。源数据是模拟数据集。将数据集生成实现为Python类,并在README.txt文件中记录其使用。通常来说,在设置数据源的时候可以遵循以下规则:存储数据的方式有意义,另外还要方便查询、索引。保证数据易于共享,可以使用NFS分区、Amazon S3存储器、Git-LFS存储器、Quilt包等。确保源数据是只读状态,且要备份副本。花一定的时间,记录下所有数据的含义、位置及访问过程。上面这个步骤很重要。后续项目会你可能会犯任何错误,比如源文件无效、误用方法等等,如果没有记住数据的含义、位置及访问过程,那将很麻烦。数据处理数据处理的目的是将数据转化为“干净”的数据,以便建模。在多数情况下,这种“干净”的形式就是一个特征表,因此,“数据处理”通常归结为各种形式的特征工程(feature engineering),其核心要求是:确保特征工程的逻辑可维护,目标数据集可重现,整个管道可以追溯到源数据表述。计算图(computation graph)即满足以上要求。具体例子如下:根据cookiecutter-data-science规则,使用Makefile来描述计算图。通过脚本实现每个步骤,该脚本将一些数据文件作为输入,然后输出一个新的数据文件并存储在项目的data/interim或data/processed目录中。可以使用 make -j <njobs>命令进行并行运算。使用DVC来描述和执行计算图,其过程与上面类似,此外还有共享生成文件等功能。还可以使用Luigi、Airflow或其他专用工作流管理系统来描述和执行计算图。除此之外,还可以在基于web的精美仪表板上查看计算进度。所有源数据都以表的形式存储在SQL数据库中,在SQL视图中实现所有的特征提取逻辑。此外,还可以使用SQL视图来描述对象的样本。然后,你可以根据这些特征和样本视图创建最终的模型数据集。首先,允许用户轻松的跟踪当前所定义的特征,而不用存储在大型数据表中。特征定义仅在代码运行期间有效;其次,模型从部署到生产非常简单,假设实时数据库使用相同的模式,你就只需要复制相应的视图。此外,还可以使用CTE语句将所有的特征定义编译为模型最终预测的单个查询语句。在进行数据处理时,请注意一下问题:1.重复以计算图的形式处理数据。2.考虑计算基础架构。是否进行长时间计算?是否需要并行计算还是聚类?是否可以从具有跟踪任务执行的管理UI作业中获益?3.如果想要将模型部署到生产环境中,请确保系统支持该用例。如果正在开发一个包含JAVA Android应用程序模型,但是还是想用Python开发,为了避免不必要的麻烦,就可以使用一个专门设计的DSL,然后将这个DSL转换为Java或PMML之类的中间格式。4.考虑存储特征或临时计算的元数据。可以将每个特征列保存在单独的文件中,或使用Python函数注释。建模完成数据处理和特征设计后即可开始进行建模。在一些数据科学项目中,建模可以归结为单个m.fit(X,y)或某个按钮;而在其他项目中则可能会涉及数周的迭代和实验。通常来说,你可以从“特征工程”建模开始,当模型的输出构成了很多特征时,数据处理和建模这两个过程并没有明确的界限,它们都涉及到计算。尽管如此,将建模单独列出来作为一个步骤,仍然很有意义,因为这往往会涉及到一个特殊的需求:实验管理(experiment management)。具体例子如下:如果你正在训练一个模型,用于在iris.csv数据集中对Irises进行分类。你需要尝试十个左右的标准sklearn模型,每个模型都有多个不同的参数值,并且测试不同的特征子集。如果你正在设计一个基于神经网络的图像分类模型。你可以使用ModelDB(或其他实验管理工具,如TensorBoard,Sacred,FGLab,Hyperdash,FloydHub,Comet.ML,DatMo,MLFlow,…)来记录学习曲线和实验结果,以便选择最佳的模型。使用Makefile(或DVC、工作流引擎)实现整个管道。模型训练只是计算图中的一个步骤,它输出model-<id>.pkl 文件,将模型最终AUC值附加到CSV文件,并创建 model-<id>.html报告,还有一堆用于评估的模型性能报告。实验管理/模型版本控制的UI外观如下:模型部署在实际应用中,模型最终都要部署到生产环境中,一定要有一个有效的计划,下面有些例子:建模管道输出一个训练过模型的pickle文件。所有的数据访问和特征工程代码都是由一系列Python函数实现。你需要做的就是将模型部署到Python应用程序中,创建一个包含必要函数和模型pickle文件的Python包。管建模道输出一个训练过的模型的pickle文件。部署模型需要使用Flask创建一个REST服务将其打包为一个docker容器,并通过公司的Kubernetes云服务器提供服务。训练管道生成TensorFlow模型。可以将TensorFlow服务当做REST服务。每次更新模型时,都要创建测试并运行。训练管道生成PMML文件。你可以用Java中的JPMML库来读取,一定要确保PMML导出器中要有模型测试。训练管道将模型编译为SQL查询,将SQL查询编码到应用程序中。我们对模型部署做一下总结:1.模型部署的方式有很多种。在部署之前一定要了解实际情况,并提前做计划:是否需要将模型部署到其他语言编写的代码库中?如果使用REST服务,服务的负载时多少?能否进行批量预测?如果打算购买服务,费用是多少?如果决定使用PMML,那么就要确保它能够支持你的预期预处理逻辑。如果在训练期间使用第三方数据源,那么就要考虑是否在生产中能够与它们集成,以及如何在管道导出模型中对访问信息进行编码。2.模型一旦部署到生产环境,它就转变为一行行实际的代码,所以也要满足所有需求,因此,这就需要测试。在理想情况下,部署管道应该产生用于部署的模型包以及测试时需要的所有内容。模型监控将模型成功部署到生产环境,也许训练集中的输入分布与现实不同,模型需要重新练或重新校准;也许系统性能没有达到预期。因此,你需要收集模型性能的数据并对其进行监控。这就需要你设置一个可视化仪表板,具体事例如下:将模型的输入和输出保存在logstash或数据表中,设置Metabase(或Tableau,MyDBR,Grafana等)并创建可视化模型性能和校准指标报告。进一步探索和报告在整个数据科学项目中,你还需要尝试不同的假设,以生成图标和报告。这些任务与构建管道有所不同,主要体现在两个方面:首先,大部分任务不需要可再现性,即不用包含在计算图中。另外,也没必要使用模型的可重复性,在Jupyter中手动绘制图即可。其次,这些“进一步探索”的问题往往具有不可预测性:可能需要分析性能监控日志中的一个异常值;或者测试一个新的算法。这些探索会塞满你的笔记本中,团队中的其他人可能看不懂你的记录。因此按照日期排列子项目很重要。在项目中创建project目录,子文件夹命名格式为:projects/YYYY-MM-DD -项目名称。如下所示:./2017-01-19 - Training prototype/ (README, unsorted files)./2017-01-25 - Planning slides/ (README, slides, images, notebook)./2017-02-03 - LTV estimates/ README tasks/ (another set of date-ordered subfolders)./2017-02-10 - Cleanup script/ README script.py./… 50 folders more …注意,你可以根据需要自由组织每个子项目的内部目录,因为每个子项目很可能也是一个“数据科学项目”。在任何情况下,在每个子项目中都要有个README文件夹或README.txt文件,简要列出每个子项目目录的信息。如果项目列表太长,你需要重新组织项目目录,比如压缩一部分文件移动到存档文件夹中。“探索性”的任务有两种形式,即一次性分析和可重复性使用的代码,这时候建立一些约定很有必要。服务清单数据科学项目可能会依赖一些服务,可以指定提供以下9个关键服务,来描述期望:1.文件存储。任何一个数据科学项目都必须有个存储项目的地方,且需要整个团队共享。它是网络驱动器上的一个文件夹?还是Git存储库中的一个文件夹?2.数据服务。如何存储和访问数据?这里的“数据”指的是计算机读取或输出的所有内容,包括源数据、中间结果及第三方数据集访问、元数据、模型及报告等。3.版本。代码、数据、模型、报告和文档都需要有版本控制,另外一定要备份!4.元数据和文档。如何记录项目及子项目?是否有任何机器都可读的特征、脚本、数据集或模型的元数据?5.交互式计算。在交互式计算中,你选择JupyterLab、RStudio、ROOT、Octave还是Matlab?您是否为交互式并行计算设置了一个聚类(如ipyparallel或dask)?6.作业队列和调度程序。代码如何运行?是否需要安排定期维护?7.计算图。如何描述计算图并建立可重复性?8.实验管理。如何收集、查看和分析模型培训进度和结果?使用 ModelDB、Hyperdash还是 FloydHub?9.监控仪表板。如何收集和跟踪模型在生产环境中的具体表现?使用元数据库、Tableau、 PowerBI还是Grafana?最后,我总结了一个电子表格,包含了本文提到的所有工具,可自行下载使用。本文作者:【方向】阅读原文本文为云栖社区原创内容,未经允许不得转载。

December 14, 2018 · 1 min · jiezi