首页 文章 精选 留言 我的

精选列表

搜索[年度经常性收入],共8849篇文章
优秀的个人博客,低调大师

Apache Flink 1.10.0 重磅发布,年度最大规模版本升级!

Flink 1.10 同时还标志着对 Blink[1] 的整合宣告完成,随着对 Hive 的生产级别集成及对 TPC-DS 的全面覆盖,Flink 在增强流式 SQL 处理能力的同时也具备了成熟的批处理能力。本篇博客将对此次版本升级中的主要新特性及优化、值得注意的重要变化以及使用新版本的预期效果逐一进行介绍。 官网下载链接 https://flink.apache.org/downloads.html 新版本的二进制发布包和源码包已经可以在最新的 Flink 官网下载页面[2]找到。更多细节请参考完整的版本更新日志[3]以及最新的用户文档[4]。欢迎您下载试用此版本,并将您的反馈意见通过 Flink 邮件列表[5]或 JIRA[6] 与社区分享。 新特性及优化 内存管理及配置优化 Flink 目前的 TaskExecutor 内存模型存在着一些缺陷,导致优化资源利用率比较困难,例如: 流和批处理内存占用的配置模型不同; 流处理中的 RocksDB state backend 需要依赖用户进行复杂的配置。 为了让内存配置变的对于用户更加清晰、直观,Flink 1.10 对 TaskExecutor 的内存模型和配置逻辑进行了较大的改动 (FLIP-49 [7])。这些改动使得 Flink 能够更好地适配所有部署环境(例如 Kubernetes, Yarn, Mesos),让用户能够更加严格的控制其内存开销。 ■ Managed 内存扩展 Managed 内存的范围有所扩展,还涵盖了 RocksDB state backend 使用的内存。尽管批处理作业既可以使用堆内内存也可以使用堆外内存,使用 RocksDB state backend 的流处理作业却只能利用堆外内存。因此为了让用户执行流和批处理作业时无需更改集群的配置,我们规定从现在起 managed 内存只能在堆外。 ■ 简化 RocksDB 配置 此前,配置像 RocksDB 这样的堆外 state backend 需要进行大量的手动调试,例如减小 JVM 堆空间、设置 Flink 使用堆外内存等。现在,Flink 的开箱配置即可支持这一切,且只需要简单地改变 managed 内存的大小即可调整 RocksDB state backend 的内存预算。 另一个重要的优化是,Flink 现在可以限制 RocksDB 的 native 内存占用(FLINK-7289 [8]),以避免超过总的内存预算——这对于 Kubernetes 等容器化部署环境尤为重要。关于如何开启、调试该特性,请参考 RocksDB 调试[9]。 注:FLIP-49 改变了集群的资源配置过程,因此从以前的 Flink 版本升级时可能需要对集群配置进行调整。详细的变更日志及调试指南请参考文档[10]。 统一的作业提交逻辑 在此之前,提交作业是由执行环境负责的,且与不同的部署目标(例如 Yarn, Kubernetes, Mesos)紧密相关。这导致用户需要针对不同环境保留多套配置,增加了管理的成本。 在 Flink 1.10 中,作业提交逻辑被抽象到了通用的 Executor 接口(FLIP-73 [11])。新增加的 ExecutorCLI (FLIP-81 [12])引入了为任意执行目标[13]指定配置参数的统一方法。此外,随着引入 JobClient(FLINK-74 [14])负责获取 JobExecutionResult,获取作业执行结果的逻辑也得以与作业提交解耦。 上述改变向用户提供了统一的 Flink 入口,使得在 Apache Beam 或 Zeppelin notebooks 等下游框架中以编程方式使用 Flink 变的更加容易。对于需要在多种不同环境使用 Flink 的用户而言,新的基于配置的执行过程同样显著降低了冗余代码量以及维护开销。 原生 Kubernetes 集成(Beta) 对于想要在容器化环境中尝试 Flink 的用户来说,想要在 Kubernetes 上部署和管理一个 Flink standalone 集群,首先需要对容器、算子及像 kubectl 这样的环境工具有所了解。 在 Flink 1.10 中,我们推出了初步的支持 session 模式的主动 Kubernetes 集成(FLINK-9953 [15])。其中,“主动”指 Flink ResourceManager (K8sResMngr) 原生地与 Kubernetes 通信,像 Flink 在 Yarn 和 Mesos 上一样按需申请 pod。用户可以利用 namespace,在多租户环境中以较少的资源开销启动 Flink。这需要用户提前配置好 RBAC 角色和有足够权限的服务账号。 正如在统一的作业提交逻辑一节中提到的,Flink 1.10 将命令行参数映射到了统一的配置。因此,用户可以参阅 Kubernetes 配置选项,在命令行中使用以下命令向 Kubernetes 提交 Flink 作业。 ./bin/flink run -d -e kubernetes-session -Dkubernetes.cluster-id=<ClusterId> examples/streaming/WindowJoin.jar 如果你希望第一时间尝试这一特性,欢迎参考相关文档[16]、试用并与社区分享你的反馈意见: Table API/SQL: 生产可用的 Hive 集成 Flink 1.9 推出了预览版的 Hive 集成。该版本允许用户使用 SQL DDL 将 Flink 特有的元数据持久化到 Hive Metastore、调用 Hive 中定义的 UDF 以及读、写 Hive 中的表。Flink 1.10 进一步开发和完善了这一特性,带来了全面兼容 Hive 主要版本[17]的生产可用的 Hive 集成。 ■ Batch SQL 原生分区支持 此前,Flink 只支持写入未分区的 Hive 表。在 Flink 1.10 中,Flink SQL 扩展支持了 INSERT OVERWRITE 和 PARTITION 的语法(FLIP-63 [18]),允许用户写入 Hive 中的静态和动态分区。 写入静态分区 INSERT { INTO | OVERWRITE } TABLE tablename1 [PARTITION (partcol1=val1, partcol2=val2 ...)] select_statement1 FROM from_statement; 写入动态分区 INSERT { INTO | OVERWRITE } TABLE tablename1 select_statement1 FROM from_statement; 对分区表的全面支持,使得用户在读取数据时能够受益于分区剪枝,减少了需要扫描的数据量,从而大幅提升了这些操作的性能。 ■ 其他优化 除了分区剪枝,Flink 1.10 的 Hive 集成还引入了许多数据读取[19]方面的优化,例如: 投影下推:Flink 采用了投影下推技术,通过在扫描表时忽略不必要的域,最小化 Flink 和 Hive 表之间的数据传输量。这一优化在表的列数较多时尤为有效。 LIMIT 下推:对于包含 LIMIT 语句的查询,Flink 在所有可能的地方限制返回的数据条数,以降低通过网络传输的数据量。 读取数据时的 ORC 向量化: 为了提高读取 ORC 文件的性能,对于 Hive 2.0.0 及以上版本以及非复合数据类型的列,Flink 现在默认使用原生的 ORC 向量化读取器。 ■ 将可插拔模块作为 Flink 内置对象(Beta) Flink 1.10 在 Flink table 核心引入了通用的可插拔模块机制,目前主要应用于系统内置函数(FLIP-68 [20])。通过模块,用户可以扩展 Flink 的系统对象,例如像使用 Flink 系统函数一样使用 Hive 内置函数。新版本中包含一个预先实现好的 HiveModule,能够支持多个 Hive 版本,当然用户也可以选择编写自己的可插拔模块 [21]。 其他 Table API/SQL 优化 ■ SQL DDL 中的 watermark 和计算列 Flink 1.10 在 SQL DDL 中增加了针对流处理定义时间属性及产生 watermark 的语法扩展(FLIP-66 [22])。这使得用户可以在用 DDL 语句创建的表上进行基于时间的操作(例如窗口)以及定义 watermark 策略[23]。 CREATE TABLE table_name ( WATERMARK FOR columnName AS <watermark_strategy_expression> ) WITH ( ... ) ■ 其他 SQL DDL 扩展 Flink 现在严格区分临时/持久、系统/目录函数(FLIP-57 [24])。这不仅消除了函数引用中的歧义,还带来了确定的函数解析顺序(例如,当存在命名冲突时,比起目录函数、持久函数 Flink 会优先使用系统函数、临时函数)。 在 FLIP-57 的基础上,我们扩展了 SQL DDL 的语法,支持创建目录函数、临时函数以及临时系统函数(FLIP-79 [25]): CREATE [TEMPORARY|TEMPORARY SYSTEM] FUNCTION [IF NOT EXISTS] [catalog_name.][db_name.]function_name AS identifier [LANGUAGE JAVA|SCALA] 关于目前完整的 Flink SQL DDL 支持,请参考最新的文档[26]。 注:为了今后正确地处理和保证元对象(表、视图、函数)上的行为一致性,Flink 废弃了 Table API 中的部分对象申明方法,以使留下的方法更加接近标准的 SQL DDL(FLIP-64 [27])。 ■ 批处理完整的 TPC-DS 覆盖 TPC-DS 是广泛使用的业界标准决策支持 benchmark,用于衡量基于 SQL 的数据处理引擎性能。Flink 1.10 端到端地支持所有 TPC-DS 查询(FLINK-11491 [28]),标志着 Flink SQL 引擎已经具备满足现代数据仓库及其他类似的处理需求的能力。 PyFlink: 支持原生用户自定义函数(UDF) 作为 Flink 全面支持 Python 的第一步,在之前版本中我们发布了预览版的 PyFlink。在新版本中,我们专注于让用户在 Table API/SQL 中注册并使用自定义函数(UDF,另 UDTF / UDAF 规划中)(FLIP-58 [29])。 如果你对这一特性的底层实现(基于 Apache Beam 的可移植框架 [30])感兴趣,请参考 FLIP-58 的 Architecture 章节以及 FLIP-78 [31]。这些数据结构为支持 Pandas 以及今后将 PyFlink 引入到 DataStream API 奠定了基础。 从 Flink 1.10 开始,用户只要执行以下命令就可以轻松地通过 pip 安装 PyFlink: pip install apache-flink 更多 PyFlink 规划中的优化,请参考 FLINK-14500[32],同时欢迎加入有关用户需求的讨论[33]。 重要变更 FLINK-10725[34]:Flink 现在可以使用 Java 11 编译和运行。 FLINK-15495[35]:SQL 客户端现在默认使用 Blink planner,向用户提供最新的特性及优化。Table API 同样计划在下个版本中从旧的 planner 切换到 Blink planner,我们建议用户现在就开始尝试和熟悉 Blink planner。 FLINK-13025[36]:新的 Elasticsearch sink connector[37] 全面支持 Elasticsearch 7.x 版本。 FLINK-15115[38]:Kafka 0.8 和 0.9 的 connector 已被标记为废弃并不再主动支持。如果你还在使用这些版本或有其他相关问题,请通过 @dev 邮件列表联系我们。 FLINK-14516[39]:非基于信用的网络流控制已被移除,同时移除的还有配置项“taskmanager.network.credit.model”。今后,Flink 将总是使用基于信用的网络流控制。 FLINK-12122[40]:在 Flink 1.5.0 中,FLIP-6[41] 改变了 slot 在 TaskManager 之间的分布方式。要想使用此前的调度策略,既尽可能将负载分散到所有当前可用的 TaskManager,用户可以在 flink-conf.yaml 中设置 “cluster.evenly-spread-out-slots: true”。 FLINK-11956[42]: s3-hadoop 和 s3-presto 文件系统不再使用类重定位加载方式,而是使用插件方式加载,同时无缝集成所有认证提供者。我们强烈建议其他文件系统也只使用插件加载方式,并将陆续移除重定位加载方式。 Flink 1.9 推出了新的 Web UI,同时保留了原来的 Web UI 以备不时之需。截至目前,我们没有收到关于新的 UI 存在问题的反馈,因此社区投票决定[43]在 Flink 1.10 中移除旧的 Web UI。 发行说明 准备升级到 Flink 1.10 的用户,请参考发行说明[44]中的详细变更及新特性列表。对于标注为 @Public 的 API,此版本与此前的 1.x 版本 API 兼容。 贡献者列表 Fink 社区对此次新版本的所有贡献者表示感谢: Achyuth Samudrala, Aitozi, Alberto Romero, Alec.Ch, Aleksey Pak, Alexander Fedulov, Alice Yan, Aljoscha Krettek, Aloys, Andrey Zagrebin, Arvid Heise, Benchao Li, Benoit Hanotte, Benoît Paris, Bhagavan Das, Biao Liu, Chesnay Schepler, Congxian Qiu, Cyrille Chépélov, César Soto Valero, David Anderson, David Hrbacek, David Moravek, Dawid Wysakowicz, Dezhi Cai, Dian Fu, Dyana Rose, Eamon Taaffe, Fabian Hueske, Fawad Halim, Fokko Driesprong, Frey Gao, Gabor Gevay, Gao Yun, Gary Yao, GatsbyNewton, GitHub, Grebennikov Roman, GuoWei Ma, Gyula Fora, Haibo Sun, Hao Dang, Henvealf, Hongtao Zhang, HuangXingBo, Hwanju Kim, Igal Shilman, Jacob Sevart, Jark Wu, Jeff Martin, Jeff Yang, Jeff Zhang, Jiangjie (Becket) Qin, Jiayi, Jiayi Liao, Jincheng Sun, Jing Zhang, Jingsong Lee, JingsongLi, Joao Boto, John Lonergan, Kaibo Zhou, Konstantin Knauf, Kostas Kloudas, Kurt Young, Leonard Xu, Ling Wang, Lining Jing, Liupengcheng, LouisXu, Mads Chr. Olesen, Marco Zühlke, Marcos Klein, Matyas Orhidi, Maximilian Bode, Maximilian Michels, Nick Pavlakis, Nico Kruber, Nicolas Deslandes, Pablo Valtuille, Paul Lam, Paul Lin, PengFei Li, Piotr Nowojski, Piotr Przybylski, Piyush Narang, Ricco Chen, Richard Deurwaarder, Robert Metzger, Roman, Roman Grebennikov, Roman Khachatryan, Rong Rong, Rui Li, Ryan Tao, Scott Kidder, Seth Wiesman, Shannon Carey, Shaobin.Ou, Shuo Cheng, Stefan Richter, Stephan Ewen, Steve OU, Steven Wu, Terry Wang, Thesharing, Thomas Weise, Till Rohrmann, Timo Walther, Tony Wei, TsReaper, Tzu-Li (Gordon) Tai, Victor Wong, WangHengwei, Wei Zhong, WeiZhong94, Wind (Jiayi Liao), Xintong Song, XuQianJin-Stars, Xuefu Zhang, Xupingyong, Yadong Xie, Yang Wang, Yangze Guo, Yikun Jiang, Ying, YngwieWang, Yu Li, Yuan Mei, Yun Gao, Yun Tang, Zhanchun Zhang, Zhenghua Gao, Zhijiang, Zhu Zhu, a-suiniaev, azagrebin, beyond1920, biao.liub, blueszheng, bowen.li, caoyingjie, catkint, chendonglin, chenqi, chunpinghe, cyq89051127, danrtsey.wy, dengziming, dianfu, eskabetxe, fanrui, forideal, gentlewang, godfrey he, godfreyhe, haodang, hehuiyuan, hequn8128, hpeter, huangxingbo, huzheng, ifndef-SleePy, jiemotongxue, joe, jrthe42, kevin.cyj, klion26, lamber-ken, libenchao, liketic, lincoln-lil, lining, liuyongvs, liyafan82, lz, mans2singh, mojo, openinx, ouyangwulin, shining-huang, shuai-xu, shuo.cs, stayhsfLee, sunhaibotb, sunjincheng121, tianboxiu, tianchen, tianchen92, tison, tszkitlo40, unknown, vinoyang, vthinkxie, wangpeibin, wangxiaowei, wangxiyuan, wangxlong, wangyang0918, whlwanghailong, xuchao0903, xuyang1706, yanghua, yangjf2019, yongqiang chai, yuzhao.cyz, zentol, zhangzhanchum, zhengcanbin, zhijiang, zhongyong jin, zhuzhu.zz, zjuwangg, zoudaokoulife, 砚田, 谢磊, 张志豪, 曹建华。 参考链接: [1] https://flink.apache.org/news/2019/08/22/release-1.9.0.html#preview-of-the-new-blink-sql-query-processor[2] https://flink.apache.org/downloads.html[3] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12345845[4] https://ci.apache.org/projects/flink/flink-docs-release-1.10/[5] https://flink.apache.org/community.html#mailing-lists[6] https://issues.apache.org/jira/projects/FLINK/summary[7] https://cwiki.apache.org/confluence/display/FLINK/FLIP-49%3A+Unified+Memory+Configuration+for+TaskExecutors[8] https://issues.apache.org/jira/browse/FLINK-7289[9] https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/state/large_state_tuning.html#tuning-rocksdb-memory[10] https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/mem_setup.html[11] https://cwiki.apache.org/confluence/display/FLINK/FLIP-73%3A+Introducing+Executors+for+job+submission[12] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=133631524[13] https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/cli.html#deployment-targets[14] https://cwiki.apache.org/confluence/display/FLINK/FLIP-74%3A+Flink+JobClient+API[15] https://jira.apache.org/jira/browse/FLINK-9953[16] https://ci.apache.org/projects/flink/flink-docs-release-1.10/ops/deployment/native_kubernetes.html[17] https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/table/hive/#supported-hive-versions[18] https://cwiki.apache.org/confluence/display/FLINK/FLIP-63%3A+Rework+table+partition+support[19] https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/table/hive/read_write_hive.html#optimizations[20] https://cwiki.apache.org/confluence/display/FLINK/FLIP-68%3A+Extend+Core+Table+System+with+Pluggable+Modules[21] https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/table/modules.html[22] https://cwiki.apache.org/confluence/display/FLINK/FLIP-66%3A+Support+Time+Attribute+in+SQL+DDL[23] https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/table/sql/create.html#create-table[24] https://cwiki.apache.org/confluence/display/FLINK/FLIP-57%3A+Rework+FunctionCatalog[25] https://cwiki.apache.org/confluence/display/FLINK/FLIP-79+Flink+Function+DDL+Support[26] https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/table/sql/[27] https://cwiki.apache.org/confluence/display/FLINK/FLIP-64%3A+Support+for+Temporary+Objects+in+Table+module[28] https://issues.apache.org/jira/browse/FLINK-11491[29] https://cwiki.apache.org/confluence/display/FLINK/FLIP-58%3A+Flink+Python+User-Defined+Stateless+Function+for+Table[30] https://beam.apache.org/roadmap/portability/[31] https://cwiki.apache.org/confluence/display/FLINK/FLIP-78%3A+Flink+Python+UDF+Environment+and+Dependency+Management[32] https://issues.apache.org/jira/browse/FLINK-14500[33] http://apache-flink.147419.n8.nabble.com/Re-DISCUSS-What-parts-of-the-Python-API-should-we-focus-on-next-td1285.html[34] https://issues.apache.org/jira/browse/FLINK-10725[35] https://jira.apache.org/jira/browse/FLINK-15495[36] https://issues.apache.org/jira/browse/FLINK-13025[37] https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/connectors/elasticsearch.html#elasticsearch-connector[38] https://issues.apache.org/jira/browse/FLINK-15115[39] https://issues.apache.org/jira/browse/FLINK-13884[40] https://issues.apache.org/jira/browse/FLINK-12122[41] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65147077[42] https://issues.apache.org/jira/browse/FLINK-11956[43] http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Remove-old-WebUI-td35218.html[44] https://ci.apache.org/projects/flink/flink-docs-release-1.10/release-notes/flink-1.10.html 原文链接:https://flink.apache.org/news/2020/02/11/release-1.10.0.html

优秀的个人博客,低调大师

二次点火 19,still love you 20 -- GuiLite 年度总结

2019是GuiLite开源的第二年,发生了很多有趣的事情,简单罗列了一些数字、事件,算是给2019作一个总结。 2019关键数字 GuiLite可统计的编译、运行次数均超过10,000次;Linux平台下的编译活动约占80%,Windows约占10%,单片机平台约占10% GitHub star数从800+ => 3400+ Gitee star数从500+ => 1400+ 开发群人数从400+ => 900+ Demo实例从2个 => 14个 GuiLite源码从5500+行 => 4900+行 2019的自打脸事件 GuiLite的最低运行配置为:嵌入式Linux设备 => 欢迎大家使用GuiLite开发STM32系列单片机,新增7个STM32实例,并支持移植到各种型号的单片机上 GuiLite跟Qt是完全不同的定位 => 欢迎大家使用Qt调试各种GuiLite实例程序,各实例的Qt工程见BuildQt GuiLite强烈建议大家用代码来布局UI => 欢迎大家使用VS Code插件进行“所见即所得”的UI布局 GuiLite的代码是自解释的,且代码量小;无需文档也能看懂 => 欢迎大家参看“软件设计说明及代码注释” GuiLite的关注于2D的操作体验 => 欢迎大家使用GuiLite进行Web及单片机上的3D效果开发 2019的探索 为什么要存在? 全年都是大厂的声音:“不要重复造轮子”。我百度了一下“轮子”,得到了这样的图片: 原来世界上有这么多的“轮子”,汽车,飞机,自行车,三蹦子,貌似没有什么轮子是可以复用的。甚至除了都是圆的以外,几乎没有啥共同点了。我想正是应用场景的复杂多变,才导致大家一边呼吁“不要重复造轮子”,一边暗自打造自己的神器。如果说造轮子无法避免,为啥不把造轮子的基本技法传播给更多人呢?“授人以鱼不如授人以渔”;我相信GuiLite没有能力提供一个人人受用的产品,但可以成为一个对开发者有用的工具,比如:一个两脚圆规;大道至简,设计师手中的工具往往简单至极,比如:铅笔,圆规,直尺 如何存在? 其实从打脸事件,可以看出来,GuiLite是一个3D(Developer Drive Development)项目,开发者的要求,是项目前进的主要动力。无论开发者的水平、经验如何,只要是开发者提出的要求,我们都会认真考虑,并在能力范围内尽量满足,并快速上线。我们不是开发者“导师”,因为一水的C语言开发者,亦能开发出超越我们的产品级UI。我们可能无法在专业应用领域给予帮助,但可以在GUI运作原理上给予充分的协助。不管你是开发大神,还是大一新生,GUI作为计算机软件的经典程序,是你增进编程功力的捷径。群主虽不是送子观音,但一般都有求必回应。 2020: still love you 2020,GuiLite依然会爱开发者,尽力支持更多的开发者;同时,也请老板、同事、同行公平对待身边的开发者,鼓励狼性的时候,也莫丢掉人性;关怀别人,亦是关怀3年后的自己。祝大家开发顺利,新年大吉!

优秀的个人博客,低调大师

开源中国“2019 年度开源软件”评选启动,作者报名通道开启

奖品赞助同步寻求中,有意合作者可私信@xplanet 或发送邮件至oscbianji@oschina.cn “中国开源软件评选”是开源中国一年一度的线上评选盛事,也是目前国内最权威的开源软件榜单。活动面向国内所有的开发者和开源作者,会有 100 余款由国人发起的知名开源软件参与评选,由开发者投票,决出最终的人气 TOP 20 。 为发掘更多优质开源软件,本届评选设有自主报名通道,开源作者可通过此通道提交软件信息进行报名,由编辑人员进行审核和筛选。同时,我们也会像往届一样,根据社区热度筛选出一批 2019 年的热门国产软件。最终将二者名单综合补全,进入评选投票。 时间安排 征集时间:2019 年 10 月 23日 - 11 月 15日 评选时间:2019 年 11 月 15日 - 12 月 06日(公开投票,敬请参与) 结果公布:2019 年 12 月 10 日 报名方式 直接在本帖下方回复“软件名称”+“软件详情页地址”即可。 示例:OSSName +https://www.oschina.net/p/ossname 特别注意,是软件在开源中国社区的收录地址,不是软件的码云地址,也不是项目的其它托管地址。 报名规则 软件由国人发起,2019年在开源中国社区具备一定的关注度(2019 年内软件详情页新增 PV ≥ 6000 或新增收藏量 ≥ 150); 软件使用的是已通过 OSI 认证的开源许可证,或者国产木兰宽松许可证,并未附加额外条款限制; 软件有在持续更新,半年内发布过新版本或合并 PR; 必须是完整、独立的软件(不是一个小的插件、示例、demo、SDK 与集成等); 同一作者最多提交 3 个软件。 我们将对报名软件进行筛选,符合条件的送入参选,不符合的将不作另行通知。 希望通过此次征集,能对更多国内优秀开源软件进行集中展示和报道。所有进入投票页面的参选软件均有机会角逐最终的 TOP 20 榜单,摘得属于自己和团队的荣誉。还等什么,快来报名吧~ P.S. 届时积极参与投票并分享活动的网友有机会获得丰厚礼品,请持续关注噢! 本次软件评选活动投票环节的奖品赞助通道也同步开启!诚邀各位参与 :D。有意合作者可私信@xplanet 或发送邮件至 oscbianji@oschina.cn 注意:目前只是报名阶段,在下方评论处回复一次就算报名成功,已报名的软件请勿多次回复造成无意义刷屏。可合理利用点赞功能,切勿刷屏,恶意刷屏将取消参选资格,谢谢配合。

优秀的个人博客,低调大师

2018 年度阿里云存储十大新闻盘点篇

数据量的爆炸式增长和企业对数据价值挖掘的渴求,让存储市场迎来前所未有的发展机遇。在过去的一年中,我们看到工业制造、在线教育、智能驾驶、基因生命科学、医疗健康、安防监控等行业正加速从数字化到智能化的转型升级,在存储空间持续增长的同时,也对存储技术提出更大的挑战。 2018年1月,阿里云正式发布全新一代分布式存储引擎盘古 2.0,在稳定性、安全、性能、成本和智能运维等领域进行创新,提供微秒级别的延迟、百亿级 IOPS 、EB 级容量和万亿级文件数的弹性扩展能力。 基于盘古 2.0,阿里云存储产品,包括块存储、对象存储、文件存储、表格存储、归档存储在内的云上存储家族以及混合云存储家族也完成了技术上的换代升级。 在此背景下,2018年,阿里云存储在业务上也前进了巨大的一步,本文盘点了过去一年来,阿里云存储十大新闻。 1.FAST探寻脉冲星背后:阿

优秀的个人博客,低调大师

EasyStack获评2016年度制造行业OpenStack最佳实践

近日,由工业和信息化部信息化和软件服务业司指导,中国信息通信研究院和中国通信标准化协会共同主办,云计算开源产业联盟承办的“云计算开源产业联盟第一次成果发布会”在京召开。 工信部信息化和软件服务业司巡视员李颖、中国信息通信研究院党委书记李勇出席会议并致辞,云计算开源产业联盟常务副理事长 何宝宏主持会议。会议发布了中国首个云计算开源产业发展白皮书,以及政府、广电、电力、电信、教育、金融、医疗、制造八大行业基于OpenStack技术 的最佳实践。 EasyStack合作伙伴副总监 罗云飞 其中,制造行业OpenStack最佳实践由EasyStack助力联想集团OpenStack高可用企业云平台项目获 得。EasyStack合作伙伴副总监罗云飞在会上对最佳实践进行了分享。他表示,联想采用EasyStackESCloud全开源解决方案,将计算, 存储,网络全虚拟化和计算与存储融合架构,实现以少量资源支撑20%内部IT业务系统和MotoCloud业务,IT部门逐步由成本中心转变为创新中 心。此外,EasyStack在银行、电信、电力,物流以及教育行业等等都有非常多的成果案例。 具体最佳实践分享如下: 联想集团的私有云就是其中之一,联想集团不用多说,他的交互的业务特别多,他的IT系统非常庞大和复杂,他在全球有很多的 数据中心,涵盖像中间件、虚拟化、备份、安全等等各种不同的技术平台,以及数不清的业务系统,非常庞大的一个IT。这些业务系统和技术平台的特点,他们是 各自独立部署的,各自成为一个体系,也就是说我们经常讲的信息孤岛的问题比较严重。 它给联想带来的困境比较多,首先第一个是效率的问题,他们在交付一个新的基础设施的时候,通常需要一个周甚至几个周的时 间。但是我们知道,如果通过云计算交付的话,可能分钟级甚至秒级就可以完成,另外因为它不是自服务的,所以它需要人工去干预,需要专业的技术团队去部署和 实施。这里面沟通、协调以及交付的效率都会影响它业务的上线。第二是成本,联想采用很多大型商业的系统,因为这些系统不是去自动伸缩的,它的资源利用率非 常低,效率就比较低下,资源的透明度也不好,最后是安全。目前采用的都是封闭的网络设计,这些直接导致了他的应用不能很好的隔离和做到安全。 从2015年上半年开始,我们逐步去帮联想做私有云的部署,基于我们的OpenStack系统,这个是一个架构图,非常清 晰明了,底层采用的是X86通用服务器加万兆的网络,另外通过像OpenStack的一些模块,比如通过KVM实现计算的虚拟化,像对象存储、块存储以及 一些定向文件,我们用Ceph来存储等,上层还有一些计量、编排的能力,总体来讲这个系统是开源、开放的,我们最终做到是软件和硬件的解耦,对于联想带来 的好处,他可以去灵活使用各种异构的硬件资源,而不会被任何一个技术或者一个产品去绑定,有很好的灵活性。 业务的稳定运行离不开高可用,我们在高可用上也做了一些设计,像计算、存储的这些数据,我们实现三副本的拷贝,另外为了实现不同网络、不同租户的安全,我们设计了很多的VLAN。包括管理网络,以及内部的数据私有网,还有对外的接入网络,这种VLAN都有。 当前的状态怎么样,目前完成的联想IT的一期,在北京的数据中心搭建了云计算平台,主要是为他的手机业务提供云资源,因为 大家知道联想收购了摩托罗拉,后面他也不断在发展自己的手机业务,所以我们一期是在北京,他们也会逐步把北京其他的业务迁移到云上来。后面的二期我们会牵 扯到像武汉等等其他一些城市的数据中心,甚至联想在全球的数据中心,都纳入进来,去做跨区域、跨数据中心的云计算资源池。在必要的时候我们会去考虑公有云 的能力。 在走向移动化、社交网络的过程中,无论传统的PC与手机都经历着激烈的竞争及快速的技术转变。作为国内IT标杆企业的联想 集团,在面临市场的飞速演变与竞争中提出——从产品向用户转型的新战略。而只有可快速迭代、弹性扩展的企业云平台才能够支撑联想这种业务创新的需求。经过 慎重研究与评估后,联想集团IT选择EasyStack公司,基于OpenStack承载其“互联网”战略的企业云平台。经过半年多的实践,已经建设成为 规模超过3000Core的OpenStack生产级环境,数据以最高10TB/天的速度快速增长,并计划在年内将10%~20%IT负载迁移到云环 境,这让联想走在了国内企业级OpenStack的实践的前列。 转型与云选型 以往的联想的内部IT主要面向大型客户以及渠道为主,系统架构以包括IBMPower小机、AIX、PowerVM、 DB2及近年普遍使用的VMware虚拟化的传统IT架构构建而成。在向互联网企业转型的过程中,首先在用户数与交易量就远远无法支撑全新的B2C的业 务。其次在成本方面,联想以往的IT架构是大规模采用商用化的解决方案,可靠但不便扩展且成本昂贵。 此外,对于IT团队的效率与安全合规性,传统的IT架构仍然无法支撑起联想面向电商与移动新业务转型。2015年,联想IT进入到基础架构再造的阶段——需要采用新的云计算平台来支撑新的业务。 联想的选型历程 在选型过程中,联想对主流的x86虚拟化技术、私有云平台、公有云进行了全面分析与对比后,联想从稳定性、可用性、开放 性、以及生态系统的全面与活跃度等因素考虑,最终认为OpenStack云平台技术可以满足联想的企业需求,联想确定采用OpenStack作为其业务持 续创新的基础云平台,并选择EasyStack作为合作伙伴一同实践前行。 高可用的架构设计 在逻辑架构上,联想企业云平台完全通过软件定义环境的方式来管理基础架构,底层采用x86服务器以及10Gb网络,引入互联网式的监控运维解决方案,并用OpenStack平台来管理所有资源。 联想企业云逻辑架构 出于高可用角度、最大化的提升云平台的系统效率,联想设计了云平台的物理架构,并采用高配置的服务器来构成计算、存储与网络一体的超融合系统,通过OpenStack整合为统一的资源池,将计算节点和存储节点放在同一个物理节点上。 联想企业云物理架构 硬件层面,双路的SystemX3650服务器,以及四路的ThinkServerRQ940,成为了联想企业云平台 的硬件支柱。每节点用5个SSD硬盘与12个SAS硬盘来构成存储模块;SSD不仅用来做存储的缓冲,也是高性能存储池资源;并通过VM访问分布式存储, 来实现系统的高可用性。 为了将OpenStack提升至企业级服务水平,我们在计算、网络、存储等方面解决了很多挑战。 计算 在计算方面,联想采用高密度的虚机部署方式,底层基于KVM虚拟化技术,通过多种优化手段,发挥物理机最大性能,在计算存储融合架构下对CPU,内存等硬件资源做隔离。最终实现在每台双路CPU计算节点上保证50+虚机仍能平稳高效运行。 另外,在云环境里面一般提倡应用程序自身高可用来应对硬件故障,但仍然有一些应用属于传统应用,对于单个主机的可用性还有 要求。对于不能做高可用的传统应用,联想通过ComputeHA技术实现了计算节点的高可用,通过多种检测手段判定计算结点是否发生故障,将故障物理机 上的虚机迁到其它可用的物理机上,整个过程无人值守,最大程度减少因为物理机故障导致的业务中断。 网络 ——网络隔离 使用不同网卡,不同交换机或不同VLAN将各种网络隔离,如:单独的OpenStack管理网,虚机生产网络,存储网络,公网,PXE网络。避免网络相互干扰,达到提高整体带宽和更好监控网络的目的。 联想OpenStack企业云平台网络架构 ——多Public网络 通过多个Public网络实现网络灵活性,便于管理安全策略。比如联通Public网络,电信Public网络,办公Public网络。 ——网络及优化 使用VLAN网络模式,与传统数据中心网络更好的整合,通过优化VLAN数据包处理,达到很好的网络数据包处理能力,让虚机网络带宽接近物理网络带宽。 ——双网卡绑定,多交换机 通过双网卡绑定到不同的交换机达到物理网络的高可用。 ——网络节点HA 通过多个网络节点,实现公网的负载均衡及HA,实现高性能和高可用,网络节点使用Router级别的Active/Standby方式实现HA,使用独立的网络路由监控服务确保网络HA的稳定性。 存储 联想OpenStack云平台采用Ceph作为统一存储后端,其中Glance镜像、Nova虚拟机系统盘、Cinder云硬盘的数据存储由CephRBD提供,利用Ceph的CopyonWrite特性,通过修改OpenStack代码,可做到秒级虚拟机部署。 Ceph作为统一存储后端,其性能无疑是企业核心应用是否虚拟化、云化的关键指标之一。在计算存储共同运行的超融合部署架 构中,存储性能调优既要最大化存储性能、又要保证计算和存储资源的隔离,保证系统的稳定性。针对如下图所示的整个IO栈,联想从下往上,对各层进行了优 化: ——网络方面 打开Jumbo帧,提高数据传输效率;同时可采用10Gb以太网络来承载CephCluster网络的流量,提高Ceph数据复制效率。 ——性能方面 利用SSD固态盘作为CephOSD日志盘来提高整个集群IO性能,来达到关键业务(如电商系统的数据库业务等)对性能 的要求,做到性能和成本的最佳平衡点。SSD具有低功耗,响应时间短,高IOPS,高吞吐量的特点。在Ceph的日志系统,对应的是多线程访问,采用 SSD来代替机械硬盘,可以充分发挥,SSD随机读写响应时间短,高IO吞吐量的特点。通过调整IO调度策略,使之更适合于SSD盘,降低了整个IO的延 时。 ——合理规划 根据服务器上虚拟机的密度,合理规划超融合节点下CephOSD的数量,并为OSD预分配CPU和内存等资源,同时,为保证系统稳定性,采用cgroup、taskset等工具对QEMU-KVM和CephOSD进行资源隔离。 ——参数调优 Ceph参数调优方面,通过调整Journal,FileStore的默认队列、OSD的OP线程数等参数,可有效提高性能。其它更多调优参数,可通过迭代测试,找到当前硬件环境的最佳参数。 ——数据高可用 数据高可用方面,除了OpenStack已有的数据保护措施之外,联想未来规划中的两地三中心也做了数据灾备方案的准备: 通过专有的低延迟的光纤专线,数据可同步存储在同城备份中心,可异步存储在异地灾备中心,最大限度保证数据安全性。 AD集成 此外,联想还将自身的业务需求融入到了OpenStack企业云平台中,作为一个拥有数万名员工的大企业,需要通过AD活动目录来进行认证,员工就不用单独再建用户、记口令等;通过协作方的定制开发,联想已将AD功能融入OpenStack企业云平台之中。 应用成果 在采用EasyStackESCloud方案后,推动联想集团向”PC+”、”互联网+”转型,支持大数据、电子商务、 智能硬件、MotoCloud等创新业务。混合云连接器对接公有云实现业务弹性。通过超融合架构和虚拟机高密度设计,实现云主机成本低于公有云。多数据 中心运行多业务系统,数据中心间异步数据复制,保证业务安全和数据安全。 原文发布时间为:2016-08-01 本文来自云栖社区合作伙伴至顶网,了解相关信息可以关注至顶网。

优秀的个人博客,低调大师

年度大片:StackOverflow2017开发者调查报告

【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》 Stack Overflow 发布了2017 开发者调查报告,此次有超过 64,000 名开发人员参与调查,分别对其技能、工具、学习趋势等数据进行了统计,现将其中一些有趣的数据和趋势撷取出来分享给大家。 一、开发角色 开发类型 大约有四分之三的受访者是 web 开发人员,不过这其中也有许多人表示正在努力构建桌面应用和移动应用。 具体开发类型 二、开发经验 Web 和移动开发人员平均而言,比其他技术学科的开发人员(如系统管理和嵌入式编程)的专业编码经验要少得多。软件行业是新人才的主要孵化器,经验丰富的开发人员比例相对较低。 三、开发者推荐哪种学习方式? 想学习编程,但不知道从哪下手? 调查显示开发者建议先进行在线课程,然后买一本书练习。 四、编程语言 最常用编程语言 JavaScript 连续五年夺得最常用编程语言。 SQL 再次占据第二位,Java 第三。 但是,Python 在五年内***超过了 PHP。 编程语言使用趋势 可以看到,Python 和 Node.js 等语言日益普及,而 C#和 C 语言的使用却在减少。 最喜欢的编程语言 Rust连续两年成为***的编程语言。Swift 去年排名第二,今年降至第四名。 最可怕的编程语言 Visual Basic连续两年被评为最可怕的语言。最可怕的意思是,目前使用该技术的开发人员比例很高,表示没有兴趣继续做下去。 最希望使用的编程语言 Python 去年排名第四,今年已成为开发者最希望使用的语言。 五、开发技术和其他 框架、库 Node.js 和 AngularJS 仍然是这一类中最常用的技术。 数据库 ***对数据库进行调查,MySQL 和 SQL Server 是最常用的。 平台 Windows 是开发人员最常用的平台,其次是 Linux 。 六、开发环境 Web 开发 桌面开发 系统管理员/Devops 七、技术生态 技术被集中在几个不同的“生态系统”中:下图的左侧,一个是代表 Web 开发的大型集群(中心是 JavaScript ),一个是用微软技术群(以 C#和 Visual Studio 为中心)。右边,有一个连接着 Java、Android 和 iOS 的集群“星座”。 其他较小的相关集群包括 C / C ++ / Assembly、Raspberry Pi 与 Arduino,语言如 Python 和 R 以及特定的 IDE 。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册