大數據

勇敢的技术达人，你们好： 旧岁辞去，已是春暖花开时，阿里云 MVP也开始迎新纳友，广招天下技术精英！阿里云最有价值专家，简称 MVP（Most Valuable Professional），是专注于帮助他人充分了解和使用阿里云的技术实践领袖。【我要成为阿里云 MVP】 这个春节与往年不太一样，一场悄无声息的战役在全国打响，牵动着14亿人的心。疫情严峻，我们从未退缩；技术难关，我们直面挑战。在这场蔓延全国的灾难面前，阿里人和MVP用饱满的精神能量和温暖的技术力量，取得一次次成就斐然的结果，缔造了一个个扣人心扉的故事。 DataV提供可视化指挥台；钉钉扩容万台服务器，支撑两亿人在家办公，提供在线教育服务；天池实验室开放病毒数据，开放计算资源；阿里云向全球公共科研机构开放一切AI算力；达摩院的算法将原来数小时的疑似病例基因分析缩短至半小时；餐饮集团告急，盒马鲜生租用停业餐厅员工上班……除此之外，我们的MVP伙伴们也在关注着，并付诸自己的努力。 在上海启动社区登记购买口罩方式后，社区人员逆风而行，忙得不可开交。看到这一景象，阿里云 MVP肖修鹏，作为小i机器人副总裁立即响应，紧急集结公司资源，向社会公众无偿提供公益服务：针对各级政府、企事业单位、社区、相关机构无偿提供防疫外呼机器人及疫情防控问答机器人服务。 万博智云CTO孙琦，疫情在前，公司提供“零接触云迁移”3个月免费使用，工作项目线上化，人不聚，活儿继续！ 为保证正常经济运转，云沃客副总裁应俊、CTO江同飞为企业恢复生产免费提供云工作平台。凌晨三点，万家灯火眠，而应俊的团队正在忙着系统的升级和扩容。本该新婚燕尔的同事只能跟新娘视频，另一位新手爸爸在哄睡宝宝后继续投入工作。这支武汉的研发团队虽分散各地，仍心系疫情，为了暴露更多bug，大家都在跟流量洪峰争分夺秒。 深夜伏案，工作才刚刚开始 山川异域，风月同天。技术是有温度的。平凡人，做非凡事。阿里云 MVP始终信守并践行着。迄今为止，我们已有全球超过30个国家和地区的470+位顶尖技术专家伙伴。他们在各自擅长的行业和领域发光发热，如星辰四散而闪耀。 现在，我们邀请你，加入这个队伍。 点击链接，申请成为阿里云 MVP 了解更多信息，可移步阿里云 […]

作者 | Rafal  导读：Helm 是 Kubernetes 的一个软件包管理器。两个月前，它发布了第三个主要版本，Helm 3。在这一新版本中，有许多重大变化。本文作者将介绍自己认为最关键的 5 个方面。 移除了 Tiller Helm 最终移除了其服务器端组件，Tiller。现在，它完全没有代理。Tiller 之前是一个运行在 Kubernetes 上的小型应用程序，它用于监听 Helm 命令并处理设置 Kubernetes 资源的实际工作。 这是

导读：近期的特殊情况牵动所有人的心，除关注最新动态外，小伙伴们还要注意自身防护，减少外出。Ververica 在此为大家奉上 2019 全年 Flink 相关技术文章合集，希望能够帮助大家充实假期～ 在过去的一年中 Apache Flink 社区官方微信公众号为小伙伴们推送了大数据及 Flink 相关活动资讯 46 篇；Apache Flink 的系列基础教程 19 篇、企业级应用实践 20+、实操系列以及实时数仓、风控、CEP 等典型应用场景及技术干货

导读：阿里主搜（淘宝天猫搜索）是搜索离线平台非常重要的一个业务，具有数据量大、一对多的表很多、源表的总数多和热点数据等特性。对于将主搜这种逻辑复杂的大数据量应用迁移到搜索离线平台总是不缺少性能的挑战，搜索离线平台经过哪些优化最终实现全量高吞吐、增量低延迟的呢？文章大纲如下： 前言 搜索离线平台基本概念 主搜业务特点与性能要求 Blink Job 性能调优详解 结语 本文将与大家分享阿里主搜在实现全量高吞吐、增量低延迟方面的优化经验，希望对大家的 Flink 应用有所帮助。 一.前言 在阿里搜索工程体系中我们把搜索引擎、在线算分等毫秒级响应用户请求的服务称之为“在线”服务；与之相对应的，将各种来源数据转换处理后送入搜索引擎等“在线”服务的系统统称为“离线”系统。搜索离线平台作为搜索引擎的数据提供方，是集团各业务接入搜索的必经之路，也是整个搜索链路上极为重要的一环，离线产出数据的质量和速度直接影响到下游业务的用户体验。 搜索离线平台经过多年沉淀，不仅承载了集团内大量搜索业务，在云上也有不少弹外客户，随着平台功能的丰富，Blink（阿里内部版本的 Flink） 版本的领先，我们在 2019 年年初开始计划把主搜（淘宝天猫搜索）迁移到搜索离线平台上。 主搜在迁移搜索离线平台之前的架构具有架构老化、Blink 版本低、运维困难、计算框架不统一等不少缺点，随着老主搜人员流失以及运维难度与日俱增，重构工作早已迫上眉睫。

DataWorks数据质量模块是支持多种异构数据源的质量校验、通知、管理服务的一站式平台。这次数据质量发布包括质量报告自定义、规则模板库、动态阈值、问题处理及反馈等新功能，得让规则创建更加便捷、数据质量更加可控！ *适用版本：欢迎升级至DataWorks企业版使用。 1 质量报告自定义支持数据质量报告模板的动态配置，按照报告模板定时生成并发送报告。 2 规则模板库支持将通用的自定义规则沉淀为模板，统一管理。帮助您提升规则配置的效率。 3 动态阈值用户不再需要手动设置红、橙色阈值，系统自动根据时序列算法模型检测指标的正确性，使得规则校验更加灵活和智能。 4 问题处理及反馈对规则校验结果进行处理，对动态阈值报警情况进行反馈。

阿里集团设立10亿元医疗物资供给专项基金淘宝天猫备货7200多万件库存民用防护物资阿里健康推出居民“线上义诊“菜鸟开通医疗防护用品全球绿色通道钉钉上线“防疫精灵“群机器人…… 疫情面前，阿里巴巴上下启动了系列措施进行驰援与抗击。作为阿里巴巴集团的科技型中小企业创新赋能平台，阿里云创新中心的创企们正在利用“黑科技”，推出了一个又一个硬核产品和解决方案，与各地政府及机构合作，冲在了抗击疫情的最前线。 **高新兴集团：5G警用巡逻机器人创始人：柏林【赛道明星班一期32号学员】** 抗击疫情期间，戴口罩、测体温成为人们进出公共场所必做的“两件大事”。人工测量体温，不仅需要投入人力，也增加了人员接触带来的安全风险。 日前，这一问题在技术上迎来突破。位于黄埔区、广州开发区的高新兴集团自主研发出升级版5G警用巡逻机器人，可实现红外线5米以内快速测量体温，并识别过往人员是否戴口罩。 “请大家戴好口罩，注意个人卫生，不要前往人流密集场所，身体若有不适请及时就医……”连日来，在广州南沙万达广场，一款由高新兴集团自主研发的巡逻机器人不停来回喊话，提醒市民时刻注意个人安全防范。 高新兴集团自主研发的巡逻机器人在南沙万达广场执勤 据悉，高新兴集团自主研发的这款名为“千巡警用巡逻机器人”，是目前国内第一款用于测体温的巡逻机器人，可一次性测量10个人的体温，温度误差在0.5摄氏度。 “人员移动到哪，机器人可以实现快速记录。温度超过设定值，或发现行人不戴口罩，机器人立马启动报警系统。”高新兴集团旗下高新兴机器人公司总经理柏林说，“通过机器人‘执勤’，真正做到隔而不离，有效节约了人力，不仅分担了执勤工作任务，也有助于避免人员交叉感染。” 据介绍，高新兴5G警用巡逻机器人搭载了5个高清摄像头，能实现全景无死角巡逻。可在机场、车站、广场、医院、社区以及重点卡口路段，启用疫情防控模式，借助移动式红外测温筛查、循环播报提醒等功能，实现远程可视化指挥，协助一线民警，在危险、高强度的工作环境中完成排查、防控任务，有效节约了人力资源。 高新兴自主研发的巡逻机器人在贵阳龙洞堡机场“执勤” 抗击疫情期间，高新兴集团充分发挥高科技的优势为群众健康安全护航。柏林介绍，目前高新兴集团的驰援点包括广州、武汉、上海、天津、北京等大城市，覆盖全国范围内的110多个项目。面对即将到来的春运返工潮，高新兴大部分员工已到岗，保障各个城市的系统和设备正常运作。 抗击疫情期间，高新兴集团还将为执法审讯者铸起一道“防护网”，能解决近期奋战在一线的执法民警遇到的难题。对于民警审讯、律师会见，如果戴口罩提讯、会见则不符合执法审讯相关的规定，如果不戴口罩，在这种特殊时期又会不安全。对此，高新兴集团迅速提供解决方案，推出律师会见和远程提讯系统。该系统可以提供远程非接触式的提讯和交流，打破地域限制，无需直接接触在押人员，提讯更安全，相关业务流程可在系统内实现闭环。 疫情当前，我们责无旁贷，阿里云创新中心将携手更多科技型中小企业为疫区驰援。近期还将推出系列创企解决方案以及各合作伙伴驰援情况。 各地政府及合作伙伴若有此类需求，请联系我们。在改变世界之前，让我们共同为国家尽一份力！ 呼吁更多硬核心创企加入我们，与阿里云一起用黑科技抗击疫情。 欢迎到创新赋能平台上了解更多赋能资源

2月12日，国际知名调研机构Gartner发布2020年商业智能和分析平台魔力象限报告（《Magic Quadrant for Analytics and Business Intelligence Platforms》），阿里云成为首个且唯一入选该领域魔力象限权威评测的中国企业。 报告显示，阿里云作为该领域魔力象限的全新闯入者，旗下产品Quick BI已经在特定细分市场和区域取得成功，获得了市场广泛认可。 Gartner分析师认为，“它在未来将有影响全球市场的潜力”。 根据Gartner统计数据，阿里云已稳居全球公有云市场前三，中国公共云市场份额第一位。目前，阿里云通过Quick BI可以为用户提供数据准备、可视化的数据分析和交互式仪表板等服务，它支持公有云和私有云两种部署模式，满足客户不同场景需求。 报告显示，“运营能力强和客户满意度高是Quick BI 核心优势之一。”目前Quick BI服务用户包括了恒大地产、中通快递、阳光保险、中策橡胶在内的地产、物流、保险、零售、媒体、教育、金融等十二大领域的核心用户。 与此同时，该报告还首次提到了数据中台概念。过去，阿里巴巴所倡导的数据中台理念备受市场关注。阿里云智能总裁张建锋在去年7月的上海阿里云峰会上表示：阿里巴巴数据中台是阿里云上实现数据智能的最佳实践。而对于数据中台的定义，阿里也给出了官方的解释：数据中台是构建既“准”且“快”的“全”“统”“通”的“智能”大数据体系。 当前，阿里巴巴数据中台已经沉淀成为云上的技术、产品、解决方案和完整的生态体系，通过阿里云平台对外输出服务，帮助企业现降本提效，促进业务增长。 “Quick

3年前，Uber采用了Hadoop作为大数据分析的存储（HDFS）和计算（YARN）基础设施。借助于这套系统，Uber的服务能力得到了增强，用户体验也得到了提升。 Uber将基于Hadoop的批量和流式分析应用在了广泛的场景中，例如反作弊、机器学习和ETA计算等。随着过去几年的业务增长，Uber的数据容量和访问负载也呈现了指数级增长的趋势，如：仅2017年，存储在HDFS中的数据量就增加了超过400%。 同时保证系统扩展能力和高性能并不是一件容易的事情。Uber的数据基础设施团队采用了多种方式来扩展HDFS系统，例如视图文件系统（ViewFS）、频繁的HDFS版本更新、NameNode的垃圾回收调优、减少小文件的数量、HDFS负载管理服务、只读的NameNode副本等。下面将详细介绍，Uber是如何通过这些改进措施来保证存储系统的持续增长、稳定和可靠的。 一．扩展带来的挑战 HDFS被设计成在单一集群上部署的、能够包含数千个节点的、可扩展的分布式文件系统。只要硬件配置满足，单一集群可以方便又快速的扩展到超过100PB的存储容量。 可是在Uber，由于业务的快速增长，每周都有成千上万个用户进行百万次的Hive和Presto查询，在这种情况下，既要可靠的扩展系统，又要不影响数据分析业务是很难的。 目前，一半的HDFS访问都来自Presto，90%的Presto查询需要约100秒的时间。如果我们的HDFS系统过载，Presto查询就会因为在队列中长时间等待而延迟。除此之外，当一个查询来到时，我们还需要保证HDFS中的数据是立即可用的。 在之前的存储系统中，为了减少数据复制导致的延迟，数据抽取、转换、加载（ETL）和用户查询都在同一个集群中进行。为了适应这种频繁写入和更新，系统产生了很多的小文件，这进一步导致了队列的阻塞。 此外，每个业务方都需要使用到大部分的存储数据，如果按照场景用例和组织架构来拆分集群，势必会增加数据的冗余存储、降低效率和增加成本。 扩展HDFS和用户体验之间的主要矛盾和瓶颈在于NameNode的性能和吞吐能力。NameNode保存了整个系统的目录树以及数据的位置信息。正是因为NameNode保存了所有的元数据信息，所有的客户请求都必须先访问它。而且，NameNode对整个命名空间只使用一把读写锁，使得任何写请求都会阻塞其它请求，这进一步限制了NameNode的吞吐量。 2016年下半年，我们开始遇到上述原因带来的问题 – 超长的NameNode RPC请求排队时间。有时候，NameNode的请求排队时间会超过500毫秒（最长的排队时间达到了1秒），这就意味着每个HDFS请求都需要在队列中至少等待半秒钟 。相比起常态10毫秒的处理时间，这无疑是巨大的性能下降。 图1. 2016年，NamoNode单个请求的RPC排队时间超过了0.5秒 二．扩展系统 & 提升性能

抗击疫情，社区是关键。为帮助社区加强疫情防控，记者采访获悉，阿里云日前开发出社区电子通行证和居民健康信息智能上报应用，提供高效无接触管理方案。目前，这套系统已经上线，供社区在疫情期间免费使用。 随着春节假期结束，企事业单位陆续复工，各地迎来人员返程高峰，社区成为最前沿的疫情防控阵地。 不过，当前社区在限制出入期，纸质出入证的发放存在诸多弊端，如工作量大、人工发放过程中存在感染风险、根据政策变动灵活性差等；同时社区对小区人员健康情况获取渠道较少，摸排效率较低。 为了解决这些问题，阿里云开发了在线化的电子出入通行证和智能外呼管理系统，帮助物业公司、社区街道办管理好小区，方便小区业进行信息的上报和登记，有效遏制疫情在小区内部交叉感染，发挥群防群治。 具体而言，小区物业人员通过下载钉钉App，找到“社区微脑”小程序，对小区备案之后，即可向业主发放电子二维码，对进出小区进行智能化管理；通过智能外呼机器人，社区工作人员可对小区居民，尤其高危群体（疑似病例、医学观察人群）进行逐个电话外呼，在对话中采集体温、咳嗽、腹泻等症状数据，或确认是否有武汉旅行史、返程乘坐何种交通工具、接触人群等信息。采集完成后自动进行数据汇总，形成报表，从而替代人工拨打电话并汇总信息的低效方式。 据悉，为助力科技抗疫，阿里巴巴在技术方面投入了诸多资源：提供基于阿里云的AI算力，帮助科研机构缩短肺炎疫苗研发周期；阿里达摩院研发的AI算法，将原来数小时的疑似病例基因分析缩短至半小时；用一天搭建出疫情信息采集系统，免费开放给全社会，解决基层疫情上报繁琐、耗时耗力等问题。 本文来源：新浪科技

前言 Solr和ElasticSearch到底有一些什么不同？我在网上搜索了一些文章，这些文章要么是列出一个表，详细地介绍两者什么功能有，什么功能没有（比较好的一篇博客），要么是从大类出发（其中比较好的一篇文章），比较两者的关注度，社区等等。但看完这些文章，还是没法解决我心中的疑惑。最近由于项目的原因，Solr和ElasticSearch都有所使用。最近又把solr和ElasticSearch的官方文档都过了一遍。对两者有了一些浅显的见解。所以在这里想跟大家分享下我的一些看法。在这篇文章中，我不会列出一个列表来说明两者的异同，而是抽出我觉得比较重要的几点来讲一讲。本文的对比基于Solr7.3和ElasticSearch7.4。两者都在快速迭代，可能有一些最新的进展我没有考虑到，同时我接触搜索引擎的时间不长，难免有一些错误或者我没关注到的点，欢迎大家指正。 相同点 两者都基于Lucene实现 这看起来像一句废话，因为知道这两个产品的人，一定知道Solr和ElasticSearch都是基于Luence实现的。但其实这句话蕴含了两层意思。 第一层是Luence支持的功能他们都支持，只是概念和用法上稍有不同。Luence这个引擎已经非常强大，我们在使用搜索引擎时看到的绝大部分功能，Luence都可以实现。比如索引时的分词，查询时的切面(Facet)，高亮，拼写检查，搜索建议，相似页面等等，其实这些都是Luence中实现的功能，Solr和ElasticSearch都只不过做了包装而已。Luence中不仅有倒排索引，还有TermVector这种每个文档的正排索引，还有DocValue这种列存结构，不同的数据类型支持了不同的搜索要求。举例来说，对于按某一个列排序的需求，如果只有倒排索引，拿到每个doc的ID之后再去分别做seek取出列值来做排序，DocValue这种按列存的结构可以很快地取出对应document的列值，而减少磁盘seek操作。同样，在TermVector中记录了一个doc中每个term的位置，这是实现关键词高亮的基础。 这句话第二层意思是Luence做不到的事情，Solr和ElasticSearch必须自己想办法实现。比如Luence是不支持Document的部分更新的。做为一个数据库+搜索引擎的混合体，Solr和ElasticSearch如果也不支持Document的部分更新肯定说不过去，所以他们两者都实现了先把原来的文档读出来再写的逻辑。当然，要读出原来的文档就要求文档的原始数据都在，因此Solr中的部分更新要求schema中所有字段要么是stored，要么有docvalue。而ElasticSearch中则比较激进，每个Document默认都会带_source字段，原始文档都会存在里面，不用任何配置就可以支持部分更新。另外一个Luence做不了的事情就是文档的立即可见性。Luence的Document一定要commit刷成Segment后，才能被搜索到。对于一个搜索引擎来讲，这无可厚非，写入的数据过段时间才能被查到非常正常。但是很多人是把Solr和ElasticSearch当数据库用的，如果写入的数据不能立刻可见，这对一个数据库来说是不可以接受的。所以Solr和ElasticSearch都实现了一个“Realtime Get”功能，即写入的数据，如果是用id去查，是立马可以查出来的。实现原理也很简单，Solr/ES里在index前都会先写log，面对Get请求时，Luence中不可见的数据，可以查log。另外一个有意思的例子是翻页。在Luence3.5之前是没有SearchAfter这个接口的，要实现翻页，Solr的早期版本只能全查出来，然后跳过offset条数据。可想而知，如果用户深翻，性能有多差。而当Luence开始支持SearchAfter，支持从某一个文档开始搜索，Solr也开始支持Cursor功能，给上次翻页的最后一个文档做个标记，下一页从这个文档开始查，大大优化了翻页功能。 不止于搜索 除了单纯基于Luence提供的搜索功能，Solr和ElasticSearch还提供了丰富的能力。比如说ElasticSearch的Aggregation能力。ElasticSearch一定是对他的Aggregation功能非常的自信，因为在官方文档中，Aggregation是介绍完基本概念，安装部署后的第一章。用户完全可以把ElasticSearch当成一个分析引擎来用，各种avg，sum，count以及各种聚合方式，都可以实现。Solr也同样提供了Analytics Component。两者的分析功能我都没有使用过，因此我没有发言权说谁的功能更加强大。ElasticSearch还提供了一个强大的scripting，可以用ES支持的几种脚本语言来写一些复杂的求值函数。Solr中也有streamExpression，自定义了丰富的语法和函数让用户直接写表达式来查询。当然，人见人爱的SQL功能也必不可少，Solr和ElasticSearch均支持SQL和JDBC访问。两者支持的SQL功能可能存在一些差异，在这里我没有细究。 分布式架构和高可用 Solr(Cloud)和ElasticSearch都是分布式架构，支持对索引进行分片，将索引分布到不同服务器上来实现scale out。同时，他们都支持给每个Shard来设置多个replica来实现高可用。Shard的多个replica都是主从架构，相当于一写多读。主从之间都是同步复制。因此在写入时，一定需要找到主replica，而读的时候，随机选择replica都能读到最新数据。同时，Solr和ElasticSearch还支持集群间复制，但两者的实现稍微有些不同，Solr的集群间复制采用推的方式，而ElasticSearch采用的是拉。Solr支持双向复制，从而能够实现双活，而ElasticSearch只能实现主向从的复制来做主备。此外，一些数据库常用的运维功能，如snapshot，backup&restore，两者都支持。 不同点 分布式的设计理念不同 Solr在最开始的时候是单机版的，并不是分布式架构。当SolrCloud出现时，才有了分布式架构。Solr选用了Zookeeper来做分布式架构下的协调者。Solr中每一个节点都是对等的，Zookeeper的使用主要是用来存分片的路由信息，以及各个replica之间，overseer节点的抢主。Solr中唯一一个不同的角色就是overseer，相当于Solr集群中的master角色，所有的Collection creation等admin操作，都需要进过overseer节点。同时，overseer节点可以根据AutoScalling框架的配置，在节点丢失和新节点加入时，做一些预设的操作。比如节点丢失时，为该节点上的replica自动再add一个新的replica，保持可用replica数为固定值。AutoScalling框架是Solr 7.0才加入的，从这里开始，Solr才有真正意义上的自动运维，在这之前，Solr的自动运维能力比较弱，就连balance集群，都需要手工去操作。 ElasticSearch从一出生就是分布式架构设计。与Solr不同的是，ElasticSearch并没有依赖其他产品来做分布式，而是自研了一套Zen