首页 文章 精选 留言 我的

精选列表

搜索[API选型],共10000篇文章
优秀的个人博客,低调大师

toB应用私有化交付发展历程、技术对比和选型

由于数据隐私和网络安全的考虑,大多数toB场景的客户需要私有化应用交付,也就是需要交付到客户的环境里,这样的客户有政府、金融、军工、公安、大型企业、特色行业等,这些私有化场景限制很多,如何提高私有化应用交付的效率是个难题,本文将介绍,私有化应用交付有哪些技术?他们都各自有什么特点?私有化应用交付的发展历程。 toB应用私有化交付的困难点 环境网络限制,影响交付效率 交付实施过程中不能方便查找资料; 在交付过程中,交付人员需要跟公司的开发进行沟通,网络限制会影响协作工具的使用,有些客户环境甚至不能带手机,会影响解决问题的效率,环境越复杂影响越大; 在离线环境内,安装软件包也没办法直接下载,我们需要将安装文件或配置文件打包成离线包,在客户环境导入。由于业务的复杂性会导致镜像很多且很大,只能有交付人员带移动硬盘到客户现场导入,导致在导入离线包就会花费较多时间。甚至有些环境只能刻录光盘在客户环境导入,光盘本身存不了太大的包,只能分多个光盘刻录; 客户基础设施差异,需要适配过程 在私有化场景,不同客户的安装环境也不一样,有些使用物理服务器,有些使用虚拟机,不同的虚拟机厂商也有差异。操作系统也各有不同,例如常见的操作系统有 CentOS/Debian/Ubuntu/Redhat,当前还有很多国产化操作系统。CPU 架构也可能不同,有 X86、ARM 等; 资源准备周期长,需要审批流程; 交付的应用需要很重的适配过程,要么在公司适配,要么在客户现场适配; 由于环境差异很大,应用交付完需要完整测试和验证,需要大量的人力和时间投入; 交付人员的技术门槛高 交付人员需要懂底层硬件和网络; 交付人员需要懂操作系统和系统运维,需要懂服务治理、高可用、安全、性能分析、备份恢复、交付开发等等; 交付人员要能独立排查交付应用的问题,需要很强的技术基础; 定制化交付迭代效率低 在定制化交付场景,客户会参与到开发过程中,客户需要看到效果后反馈问题,再持续迭代,直到客户满意,过程中需要频繁升级产品; 如果开发人员在公司定制开发,升级过程复杂,沟通低效; 如果开发人员在客户现场,没有好的开发工具和环境,开发效率低,人力投入大; 后期维护难度大 应用交付完成后,后期需要保障应用运行的稳定性,离线环境远程没办法运维,报警没办法发出来,运维的难度大; 产品有Bug、一些预期内的变更或产品升级都需要出差客户现场,支持的成本比较高; 传统应用交付 传统的应用交付是直接交付二进制的可执行文件或软件包: 二进制的可执行文件: Java 的 Jar,Linux 的可执行文件,Windows的 EXE 等。 软件包: CentOS 使用 RPM 包,Debian 使用 DEB 包,Java Web 使用 WAR 包。 安装他们都需要先安装依赖的环境和基础软件,YUM 和 DEB 有自己的管理依赖的软件源,但离线环境用不了,如果客户的操作系统不同,还需要另外想办法解决,运行这类服务为了解决启动和自动重启的问题,还需要通过 Systemd 或 Supervisor 的方式来管理。如果交付单体架构的应用传统应用交付方式还能胜任,但如果是复杂的微服务架构,传统应用交付方式将难以胜任。 在传统应用交付过程中,管理这些运行环境和操作系统差异是一个痛点,容器的出现解决了这个问题。 当前云原生技术应用交付 云原生应用交付主要使用的容器和 Kubernetes 相关技术。 Docker 镜像交付 Docker 将业务和依赖的库一起打包成 Docker 镜像,在这个镜像中包含所有环境和应用,这样就可以达成一处打包、到处使用,我们可以将该镜像在任何支持 Docker 的操作系统上运行。Docker 的特性的确解决了很多开发、交付以及其他许多问题,因此 Docker 容器概念迅速的被普及。 在微服务架构场景,需要多个服务或应用一起交付,服务之间有依赖,还有复杂的配置,DockerCompose 解决了这个问题。 Docker-Compose应用交付 DockerCompose 将多个服务或应用使用 YAML 的方式管理,可以利用 DockerCompose 命令安装部署和管理,对于一个微服务架构的应用,利用 DockerCompose 命令就可以在任何操作系统实现一键安装和运行,当然前提是需要安装好 Docker 和 DockerCompose。 对于单机场景 DockerCompose 可以适用,当应用需要高可用或多节点分布式部署,DockerCompose 就不能胜任,Kubernetes 的出现解决了容器的高可用和分布式调度问题。 Kubernetes YAML应用交付 在 Kubernetes 中部署业务我们需要定义 Deployment Statefulset Service 等资源类型,通过调整副本的方式 Kubernetes 会自动调度到多个节点实现业务高可用,在交付时我们只需要将这些 YAML 资源和 Image 导出,在客户的 Kubernetes 环境中部署并交付给客户。这种交付方式需要客户环境有 Kubernetes 或在客户环境安装 Kubernetes。 当我们将 Kubernetes YAML 交付很多客户的时候,就需要参数配置、版本管理和简单的安装和升级,Helm 在 Kubernetes YAML 的基础上解决了上述问题。 Helm 应用交付 Helm 是 Kubernetes 资源的包管理器,它可以将一组资源定义成 Helm Chart 模版,提供了基于 Helm Chart 模块的安装和升级,安装时可以配置不同的参数。Helm 同样也是在 Kubernetes 交付中大多数人选择的工具。 Helm 最大的问题是需要开发者学习容器和 Kubernetes 整个技术栈,而且客户环境必须要有 Kubernetes,学习和使用的门槛太高。抽象的应用模型是一个解决方案。 面向未来的云原生应用模型交付 应用模型强调以应用为中心的理念,让开发者专注在业务本身,在应用级抽象和包装底层复杂的技术,应用模型跟底层基础设施完全解耦,根据对接和交付的基础设施不同,自动转换和适配,真正实现一次开发,处处自动化部署。 基于OAM的KubeVela应用交付 OAM(Open Application Model) 是一个描述应用的标准规范。有了这个规范,应用描述就可以彻底与基础设施部署和管理应用的细节分开。通过将应用定义与集群的运维能力分离,可以让应用开发者更专注于应用本身,而不是”应用部署在哪“这样的运维细节。KubeVela 基于 OAM 实现了应用跨云、跨环境持续交付。当前 KubeVela 对离线场景的应用交付支持较弱。 基于RAM的Rainbond应用交付 Rainbond 是一个云原生应用多云管理平台,Rainbond 遵循以应用为中心的核心理念,统一封装容器、Kubernetes 等复杂技术,将 Kubernetes 资源统一抽象成 RAM(Rainbond Application Model)应用模型,使用户能非常简单的使用 Kubernetes,降低用户使用的门槛,使用户专注于应用开发、应用交付和应用运维。 在对于离线交付场景,Rainbond 基于 RAM 可以导出三种离线交付包: **Rainbond应用模版包:**其中包含了复杂微服务架构交付的所有要素,支持升级和回滚,但要求客户环境安装 Kubernetes 和 Rainbond; **非容器的软件包:**非容器包按照传统应用交付方式打包,但易用性更好,包中包含了环境依赖,并采用静态编译,适合大多数操作系统,使用 Systemd 管理; **Docker-Compose离线包:**支持在标准 Docker Compose 环境一键启动和管理; 综合对比 交付门槛 微服务支持 多节点调度<br>自动化运维 离线迭代效率 客户环境支持 传统交付 高 不支持 不支持 低 服务器 Docker镜像 中 不支持 不支持 高 容器/K8s Docker Compose 中 支持 不支持 中 容器 K8s Yaml 中 支持 支持 中 K8s Helm Chart 中 支持 支持 中 K8s KubeVela 中 支持 支持 中 K8s Rainbond 低 支持 支持 高 K8s/容器/服务器 **应用交付门槛:**传统方式交付门槛最高;Docker、DockerCompose、Kubernetes Yaml、Helm 和 KubeVela 交付的门槛中等,因为需要学习会容器和Kubernetes 相关技术;Rainbond 使用最简单,不需要学习容器和 Kubernetes。 **微服务支持:**除传统应用交付和Docker镜像,其他方式都支持微服务编排和打包交付。 **多节点调度和自动化运维:**Kubernetes Yaml、Helm、KubeVela 和 Rainbond 支持 Kubernetes 的多节点调度。 **离线迭代效率:**传统方式交付效率最低;Docker 镜像有版本,而且一个命令就可以导出一个离线包,所以迭代效率高;Docker-Compose、Kubernetes Yaml、Helm 和 KubeVela 需要手工逐个打出镜像离线包,复杂架构效率不高,而且手工容易出错;Rainbond 支持自动化导出一个离线包,导入离线环境,可以一键升级和回滚,迭代效率很高。 **客户环境支持:**不同客户有不同的运行环境,交付的包需要根据客户环境选择,传统应用交付方式适合老的一些基础设施,操作系统版本老,没办法安装运行容器;客户环境没有 Kubernetes,也不允许安装 Kubernetes,可以选择 Docker 镜像和 DockerCompose;Kubernetes Yaml、Helm、KubeVela 和Rainbond 支持有 Kubernetes 的环境。

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

每日一博 | 云端数据仓库的模式选型与建设

数据,对一个企业的重要性不言而喻,如何利用好企业内部数据,发挥数据的更大价值,对于企业管理者而言尤为重要。作为最传统的数据应用之一,数据仓库在企业内部扮演着重要的角色,构建并正确配置好数据仓库,对于数据分析工作至关重要。一个设计良好的数据仓库,可以让数据分析师们如鱼得水;否则可能使企业陷入无休止的问题之中,并在未来的企业竞争中处于劣势。 随着越来越多的基础设施往云端迁移,数据仓库是否也需要上云?上云后能解决常见的性能、成本、易用性、弹性等诸多问题吗?如果考虑上云,需要注意哪些方面?目前主流云厂商产品又有何特点?面对上述问题,本文尝试给出一些答案,供各位参考。本文部分内容参考了MIT大学教授David J.DeWitt的演讲材料。 一、数据仓库建设 数据仓库(DW)的建设方式有很多种,企业可以根据自身需求进行选择。下图简单罗列了主要的DW建设方案并做出扩展对比。 1.1 建设方案 1)商业方案 商业方案,是最为传统的一种,也是过去20~30年的主流方式。企业外购数仓,包括软、硬件一体交付。其典型产品很多,多为国际知名大厂,国产厂商也有部分。 2)自建+开源 这是很多互联网公司通常采用的方案,通过自建底层基础设施+部署开源软件方式完成。整个方案对企业完全自主可控,但对自有人员技术要求较高。颇为典型的产品就是GreenPlum。 3)云+开源 这是上一种方案的变体,即Iaas层通过云厂商提供,其他仍然是自建的。当企业业务已经上云,为更好地数据集成,方便数据迁移,往往会采用此方案。 4)DW云 企业直接选用数据仓库的云服务,而不再独立建设。下文将针对这种情况,重点说明。 1.2 方案对比 针对上述4种方案,从成本、运维、交付、扩展、性能等多角度进行对比。 成本:包括前期购买和后期运营的费用,这里也包含人员投入的折算费用。 运维复杂度:主要针对企业自有技术人员的运维工作复杂度评估。 交付速度:方案的整体交付速度,包括基础设施的购买、建设。 扩展性:包括数仓的容量扩展和性能扩展能力的综合。 性能表现:数仓的整体性能表现。 1.3 重点对比 - 性价比 从上图中可见: 方案1、2,成本、性能相对固定。其中方案1,成本较高,但性能突出;方案2(自建),则两者均为中等。 方案3、4,成本与性能都是一个区间,且范围较大。方案3,主要取决于云厂商提供的基础设施的能力。方案4,则依靠云厂商的数仓云能力。这也对云厂商产品的选择,提出了更高的要求。下文将就此展开说明。 二、云端数据仓库 2.1 云方案优势 基于上面的说明,采用数据仓库的云服务,具有较多优势,包括: 更好的性价比(无论是前期购买、还是后期运营) 更快的交付速度(最快在分钟级) 更优的弹性能力(扩展或压缩、计算或存储) 更低的运维复杂度(无需专业人士) 更简单地数据集成(如果已上同一云) 更丰富的数据生态(取决于云厂商产品) 2.2 数仓关键因素 数据仓库不同于交易型数据库,它的构建是为了便于分析海量数据,而不是处理事务。这意味着数据仓库往往比其相应的交易型数据库大几个数量级,同时对于交易型数据库的某些关键特性(例如ACID、响应时间等)可能没有那么重要。相反,数据仓库有自己的需求,亦可作为上云选择因素。 1)多种数据集成方式 将数据放入仓库并正确格式化通常是数据仓库面临的最大挑战之一。传统上,数据仓库依赖于批处理提取转换加载作业-ETL。ETL作业仍然很重要,但现在也有从流式摄取数据,甚至允许你直接对不在仓库中的数据执行查询的能力。 2)支持数据多元查询 现有数据仓库,除了要支持典型批量查询外,还需要支持诸如adhoc类的查询方式。传统大数据技术栈hadoop的MapReduce不太适用于此类查询。很多数据仓库转向大规模并行处理(MPP)数据库,其原始是将数据打散后,通过并行技术在多台服务器上执行。此外,还有类似Spark这种利用内存并行处理技术完成查询。 3)标准数据访问方式 数据仓库支持什么语言进行查询。显然,标准SQL是对用户最为友好的方式,可显著降低用户的使用门槛。此外,诸如Python、R等高级语言,也可为用户带来更多访问的方式。但有些是依赖于方言,这就需要进行仔细评估。毕竟,移植的成本是笔不小的开销。 4)灵活资源弹性能力 数据仓库都是为了处理海量数据的,但其规模变化可能很大。此外,其计算资源的需求也是会随着业务而不断变化。因此对基于云的数据仓库的资源的弹性能力要求很高,这也是区别与传统自建方式一个非常大的优势。这里的资源,不仅包括计算资源、也包括数据存储资源。此外,还需要区分是否支持计算、存储的单独提供,而不是紧耦合在一起。 5)低廉运营维护成本 数据仓库是复杂的系统,从底层的物理资源、操作系统、仓库软件,到上层的数据对象、访问语句等。作为云上的数仓,是需要提供简单、灵活、自动化、甚至智能化的运维能力,方便客户使用进而节省用户的综合运营维护成本。 6)灵活使用方式 数据仓库本身是资源密集型应用,如何减低用户的使用成本,是云厂商均需考虑的。例如支持暂停与恢复功能,支持计算与存储的独立扩展等。 2.3 是否上云/如何选择? 使用数据仓库云服务,好处多多。那是否都要上云呢?这需要结合企业需求,考量以下因素来决定。 1)是否有足够的技术积累? 数据仓库本身具备较高的技术门槛,即使选择开源也需要摸索积累的过程,除非是直接使用外部商业产品。 2)是否已经在使用云? 如果已经是某云的客户,那么从云做数据集成将更加容易。否则,跨云或从本地加载数据,将是一个大工程。 3)是否对可用性要求很高? 这方面各企业差异较大,如企业比较重视可用性,云厂商/商业产品无疑具有优势。 4)数据规模是否很大? 数据仓库的一个核心难点,就是支撑的数据规模。如企业数据规模非常大,将对自建方式带来很大挑战。 5)扩展需求是否强烈? 如企业在快速发展期,其数据规模、使用复杂度等变化很大,这就要求数仓具有很好的可扩展性,可快速适应企业发展。云方案相较于其他三种方案,无疑具有优势。 6)使用特征变化剧烈? 如企业的数据使用,非常具有不确定性,即要求数仓具有很好地弹性,可根据需要灵活扩缩容;乃至对查询能力也同样有此类要求。非云的三种方案,都很难适应快速变化。 7)短期成本压力较大? 企业有数仓需求,但短期通过自建、外采商业都一次性投入过大,亦可考虑云方案。 三、数仓的两种模式 数仓从技术实现上,有两种大的分类。在下面说明厂商产品前,简单普及下。 3.1 Shared-Nothing 节点间通过高速网络互连,访问本地资源不需要通过网络。这种方式设计简单,扩展性较好。在较好的模型设计下,数据无需移动,处理效率高。 节点本身具有计算和存储资源,即两者是需要耦合在一起的。这是此模式的硬伤,即存储、计算无法分离,无法做到按需独立弹性。 3.2 Shared Disk/Storage 节点间互相访问或节点访问存储,都是需要通过高速网络。数据本身都是存储在”远端存储”中,而非本地。网络可能成为瓶颈,受到IO传输总量的限制。网络除了承载节点间的数据交换流量外,更多的是要承担大量数据访问的流量。 这种方式弹性很好,计算、存储可独立扩展。 两种方式的优劣,尚无统一定论,但较为主流是采用shared disk/storage的共享方式。但这种方式下,远端存储的性能?如何利用本地存储?网络性能对整体影响?如何实现动态资源分配?扩缩容的实现?等问题均值得研究。 四、典型数仓云服务 4.1 Amazon (AWS) Redshift Redshift是典型的shared-nothing设计,本地挂载存储。充分利用AWS的基础服务,EC2作为计算节点,S3作为存储及故障恢复使用。优势在于通过调整和定制,性能表现突出;但其架构也决定了计算与存储不能独立缩放。 支持从多种数据源加载数据,也支持集成流式数据,但只支持结构化数据。支持直接对S3上的数据进行查询,而无需ETL。其支持PostgreSQL的方言,对有些数据类型和函数不支持。Redshift本身监控组件性能并自动恢复,其他维护工作由用户负责。日常运维工作,通过用户手工在控制台完成。 4.2 Snowflake Snowflake是Shared-storage设计,存储与计算分离。本身构建在AWS上,充分利用AWS的基础服务能力,EC2作为计算节点,本地支持缓存,数据表存储在S3中。它提出一种“虚拟仓库”的概念,每个查询可分配到不同的虚拟仓库中,针对不同的仓库也分配不同的资源。仓库间不会影响性能,且仓库本身具有很高的弹性,可自动提供额外的计算资源。 支持结构化和半结构化数据,不需要ETL或预处理就可以摄取这些数据。虽然先不支持流式数据,但可连接到Spark以接收流数据。它使用标准SQL并做了适当扩展。其维护比较简单,不需要维护索引、清理数据等工作。 4.3 Microsoft Azure SQL Data Warehouse SDW是Shared-Storage设计。基于微软的SQL Server PDW软件,利用Azure存储弹性能力。对T-SQL的全面兼容,可动态调整资源,可通过Ploybase支持非加载访问。 4.4 Google BigQuery BigQuery是存储与计算分离设计,利用Google的基础服务能力,存储在Collosus FS。工作机制是将SQL查询转换为低级指令,依次执行。其完全抽象了资源的提供、分配、维护、扩缩容等,所有都是Google自动处理。非常适合易用性作为第一诉求的场景。存储上根据处理规模、负载等情况,自动分配分片。计算上资源不专有,在内部和外部客户复用。不能显式控制单一查询的资源使用。计费上使用按计算量收费方式(TB “processed”) 使用上支持标准SQL,也支持半结构化数据类型,支持外部表。支持从Google云端加载或直接访问,也可以导入数据流。其没有索引,除了数据管理外,几乎不需要维护。 作者:韩锋 首发于作者个人公号《韩锋频道》。 来源:宜信技术学院

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

IOT数据库选型——NOSQL,MemSQL,cassandra,Riak或者OpenTSDB,InfluxDB

补充: Basho公司开源了它的时序数据库产品Riak TS 1.3 代码在github riak的riak-ts分支上! Riak KV产品构建于Riak内核之上,提供了一种高弹性、高可用的键值数据库。Riak KV产品当前正在持续改进中,专注于数据正确性、预防数据损失和破坏等特性。 Riak TS产品源于Riak KV数据库,是一种为时序数据仓库而专门构建的产品。其中集成了Riak KV产品的所有强大功能,并使用这些功能去解决用户在处理时序数据中所遇到的问题。我们在该产品中确实地实现了哪些特性呢?这里我列出了其中的一部分: 数据的快速写入路径; 为数据桶建立模式; 查询规划及查询子系统; 对虚拟节点的并行数据抽取; 灵活的复合键值; 我们也查看了时序数据库产品的市场情况,当时只见到了寥寥可数的几个解决方案,并且所有这些解决方案的质量都不足以承担企业级的生产工作负荷。已有的时序数据解决方案或者是缺乏可扩展集群或弹性,或者是管理和操作非常繁琐。所有这些使得它们成为糟糕的选择。 为讨论解决这个问题的创意,我们进而开了一次架构会议。最终,我们的一个工程师提出了一个有意思的创意,即使用量子(时间范围)将数据围绕哈希 环分布,并基于此创意构建了一个看上去运行良好的概念验证原型。依此我们开始了Riak TS产品的开发过程,力图去解决许多时序数据处理中更加困难的问题。 见: https://elixirforum.com/t/which-database-for-time-series-data/715/6 http://db-engines.com/en/system/Graphite%3BInfluxDB%3BRiak+TS IoT databases should be as flexible as required by the application.NoSQLdatabases -- especially key-value, document and column family databases -- easily accommodate different data types and structures without the need for predefined, fixed schemas. NoSQL databases are good options when an organization has multiple data types and those data types will likely change over time. In other cases, applications that collect a fixed set of data -- such as data on weather conditions -- may benefit from a relational model. In-memory SQL databases, such as MemSQL, offer this benefit. Managing a database for IoT applications in-house For those organizations choosing to manage their own databases,DataStax Cassandrais a highly scalable distributed database that supports a flexible big table schema and fast writes and scales to large volumes of data.Riak IoTis a distributed, highly scalable key-value data store which integrates withApache Spark, a big data analytics platform that enables stream analytic processing.Cassandra also integrates with Spark as well as other big data analytics platforms, such as HadoopMapReduce. OpenTSDB is an open source database capable of running on Hadoop andHBase.The database is made up of command line interfaces and a Time Series Daemon (TSD). TSDs, which are responsible for processing all database requests, run independently of one another. Even though TSDs use HBase to store time-series data, TSD users have little to no contact with HBase itself. MemSQL is a relational database tuned for real-time data streaming. With MemSQL, streamed data, transactions and historical data can be kept within the same database. The database also has the capacity to work well with geospatial data out of the box, which could be useful for location-based IoT applications. MemSQL supports integration withHadoop Distributed File Systemand Apache Spark, as well as other data warehousing solutions. 摘自:http://internetofthingsagenda.techtarget.com/feature/Find-the-IoT-database-that-best-fits-your-enterprises-needs You’ve heard the hype, the Internet of Things (IoT) is going to connect more people to devices, more devices to the Internet and generate more data than any major IT shift in history. IoT is going to be bigger than the web, mobile and the cloud, right? It’s still too early to tell for sure, but at InfluxData we are helping startups and enterprises everyday bring an interconnected world closer to reality. What does time-series have to do with IoT? Everything, actually. Sensors and devices used in IoT architectures emit time-series data, and a lot of it. Why are companies building IoT and sensor data solutions? Whether it’s pH and humidity readings from an agri-sensor, depth and fluid readings from a geo-sensor or voltage and temperature from a power control sensor, these metrics are forming the basis of intelligent businesses. Common use cases we run across are: Agro industries are monitoring and trying to control environmental conditions for optimal plant growth. Power and utility companies are building smart solutions to reduce resource wastage for residential and commercial customers. Research labs and heavy industries are tracking the resources, usage and health of millions of tiny valves and instruments that go into their massive production plants, factories and manufacturing facilities. Smart cars are now powerful computers making runtime decisions based on data collected by 100s of sensors on every vehicle. Challenges in building IoT and sensor data solutions The key challenges organizations face while building an IoT solution are: Bandwidth– As sensors are generally deployed on-premise and need to communicate over wireless networks, bandwidth constraints prevent sending large packets of data in real-time Horsepower– Compute power on sensors are generally limited. Hence analytics software – programs or databases or even processing logic needs to have a tiny footprint. Concurrency– In case of industrial IoT, number of sensors could easily range in 100s of 1000s, each transmitting metrics every minute or so. Anticipating backend database’s concurrency limits is crucial in the design of such solutions Protocol– As this space is rapidly evolving, there aren’t any definitive standards for communication protocols. MQTT, AMQPP, CoAP etc are being used based on use cases. Hence IoT analytics solutions need to support many communication protocols. Scale– Data retention, compression and visualization has it’s own challenges in such a large data footprint solution. Businesses want to plot trends (WoW, MoM, YoY) and aggregation of massive data sets can be very compute heavy. 摘自:https://www.influxdata.com/use-cases/iot-and-sensor-data/ NoSQL Database: The NoSQL database is typically used to address the fast data ingest problem for device data. In some cases, there may be a stream processor—e.g. Storm, Samza, Kinesis, etc.—addressing data filtering and routing and some lightweight processing, such as counts. However, the NoSQL database is typically used because,unlike most SQL databases, which top out at about 5,000 inserts/second, you can get up to 50,000 inserts/second from NoSQL databases.However, NoSQL databases are not designed to handle the analytic processing of the data or joins, which are common requirements for Internet of Things applications. NoSQL effectively provides a real-time data ingest engine for data that is then moved to Hadoop using an extract, transform and load (ETL) process.——NOSQL写入快,但是数据分析,联合查询不方便! 本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6265106.html,如需转载请自行联系原作者

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

瑞小博的大数据平台技术选型及架构实践

前言 瑞小博成立于2014年,是一家专注于“商用WI-FI覆盖”产品研发与运营模式创新的科技公司。 公司创立之初,基于成本、效率等考量,我们选择了阿里云,至今已3个年头。这3年多里,我们使用了覆盖 弹性计算、网络、存储、数据库、大数据、安全、应用服务等多项领域的多款阿里云产品。 下面,给大家分享我们在不同阶段使用MaxCompute(原ODPS)的一些实践,以供参考。 低廉的存储&高效的运算 我们使用ODPS的首要原因,就是因为它低廉的存储和高效的运算。 公司刚成立时,业务量很小,数据存储和计算都在阿里云RDS中,简单直接。但两个月后,业务快速发展,RDS存储的费用直线上升,而且任务计算耗时越来越长,已经影响到业务的发展。 彼时,开源大数据存储计算框架Hadoop如火如荼,Spark冉冉兴起,分布式数据库Greenplum也是逐步成熟,看起来有很多的选择,我们也就此做了调研和前期尝试。但实际操作起来就会发现,这些平台在搭建初期的硬件成本、运维成本、时间成本远远超出一家创业公司的承受范围,而且这些平台并不是公司的主营业务。自建平台的方案被PASS掉。 只是想喝一杯牛奶,为什么一定要建一个牧场呢? 我们转而考察商业大数据产品,自然也就分析了ODPS。实事求是的讲,我们当时的需求其实很基础,稍微像点样子的大数据产品基本都能满足我们的需求。而我们选择ODPS的原因,一方面是因为我们的业务数据本身就在阿里云内部,ODPS更方便数据同步,但更重要的还是因为ODPS的价格很便宜。当时,存储冷数据及计算周期性任务的RDS节点一个月需要1200元,而切换到ODPS后每天存储只需要7块钱,计算仅需要4块钱,比之前便宜了近70%。另外,切换以后,ODPS的分布式计算使得周期性任务执行的更快,业务表现更好。 所以,基于ODPS低廉的存储和高效的运算,2014年9月我们将历史数据存储和周期性任务计算切换到ODPS,性能提升的同时成本也有所降低,支撑了当时业务的快速发展。 附:第一阶段数据处理流程图 完整的大数据开发框架 独木不成林。如果只有大数据存储和后分析处理,数据是割裂的,功能也是残缺的。所幸,阿里云逐步开放了一套完整的大数据开发框架,以ODPS为核心将一个个独立的功能点连成了线,也吸引我们长期成为阿里云大数据产品的忠实用户。 2015年,公司的业务飞速发展,数据量陡增,每天会产生上亿条业务记录。按照之前的数据处理架构,业务数据入RDS再同步到ODPS的做法,即使是高配RDS的IO性能也根本撑不住。而且一个高配RDS每月需要2000多块,成本比较高。 本来,最初公司的技术演进roadmap中,虽然也觉得RDS作为数据采集模块会有瓶颈,但考虑到数据量不大,预计这套数据处理架构能使用一到两年。而随着业务量陡增,我们只有提前做出改变。技术方案是:以日志文件系统,部分代替关系型数据库作为数据采集模块。业务上看,大数据量、低可靠性要求的数据通过日志文件系统采集,小数据量、高可靠性要求的数据依然通过关系型数据库采集。 有了之前的经验,技术方案确定后,我们没有考虑立即去搭建fluentd/flume,而是看看阿里云上有没有类似的产品,然后发现了SLS。SLS以正则匹配近实时(5分钟时延)采集ECS上的日志文件,不仅存储到日志文件中,还提供类Elasticsearch的文本搜索服务,完全满足我们的业务诉求。更为关键的是,SLS与ODPS是完全打通的,不需要业务系统介入,简单配置就可以将SLS采集的日志数据自动同步到ODPS。另外,当时SLS还是完全免费的(2016年11月开始SLS不再免费,但如果不使用搜索服务,费用还是比较低廉的)。最终,通过引入SLS,很好的解决了我们数据采集的性能问题,而且还减少了两个高配的RDS节点,每年节约了近6万的成本,此架构也一直沿用至今。 附:第二阶段数据处理流程图 当然,也不是每次探索都是成功的。这个阶段,由于实时计算的需求我们研究了Stream SQL(目前已下线),由于BI报表的需求我们研究了AnalyticDB,都不太符合我们的业务场景,只能通过自建或其他方案实现。 我们一直认为,独立割裂的数据价值是很低的,数据开发框架也是如此。而阿里云大数据产品这几年一步步的完善,尤其是将一个个独立的功能点连成了线,产品之间打通促进数据之间打通,吸引我们与之共同成长和进步。 发挥主观能动性 阿里云数据产品目前还处在完善阶段,不可能所有需求都能够立即满足。所以,我们还需要发挥主观能动性,解决业务问题。下面分享我们自建数据仓库和BI报表系统的实践。 2015年底,公司业务开始进入正轨,运营、市场等各方面的数据诉求越来越多,现有机制和人力开始捉襟见肘。因此,我们考虑开发数据仓库和BI报表系统。 当时,阿里云没有一款独立的BI产品,部分产品中零散的有点类似BI报表的功能(如DPC的“数据分析”)也相对较局限,不能满足我们的需求,只能自建。因此,我们在业务上构建了维度体系和指标模型,统一业务语言。数据处理架构上,将详单事实表和维度表同步到ODPS后,在ODPS中进行汇聚运算,输出统计事实表到RDS。同时,开发了 DashBoard、即席查询、查询报表 三个应用,满足我们的业务需求。其间的过程不再赘述,开发的应用如图所示。 DashBoard 即席查询 现在,阿里云的QuickBI已经发布,能很好的满足BI报表的需求。好的产品,可能会迟到,但不会缺席。 数加,新的纪元 数加的发布,是最近一年多的事,我们也还在摸索与尝试。 目前来说,比较大的感受是机器学习平台的组件化和数据模型化做的很好。在数加发布之前,我们也会自己写一些算法做业务分析,包括统计分析中的各种检验、机器学习中的分类聚类、时间序列分析等。但相对都比较散,输入输出数据模型不统一,组合比较麻烦。数加的组件化设计,能比较好的解决这个问题。 另外,数加的公开数据集也比较不错,测试验证算法很方便。 结语 三年多来,ODPS一直稳定的支持着我们的存储和计算,是我们的核心基础平台。 我们希望,在数加时代ODPS能一如既往的稳定,并提供更多的数据产品,帮助我们在数据的海洋里继续遨游。

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

泛谈实时通信协议选型 good

Wolfram Hempel 是 deepstreamIO 的联合创始人。deepstreamIO 是一家位于德国的技术创业公司,为移动客户端、及物联网设备提供高性能、安全和可扩展的实时通信服务。文本由魏佳翻译,转载译文请注明来自高可用架构。 想要向服务器发送请求并获得响应?直接使用 HTTP 吧!非常简单。但是当需要通过持久的双向连接来通信时,如 WebSockets,当然你也有其它的选择。这篇文章会简单扼要的解释 MQTT,XMPP,STOMP,AMQP,WAMP 和其它替代品。这里常被引用的 XKCD 漫画[1]之一: 等等,其实没有“实时协议”这种东西! 确实如此,但这里我将该术语(Realtime Protocol)当作一堆协议的代称,这类协议都是设计用于分发消息,同步数据和通过持久双向的连接来进行请求/响应。 我们先来根据它们各自的目的进行分类: 纯消息 底层协议(例如 TCP)是被设计用来将一个消息从一个发送者(sender)传递给一个接收者(receiver)。他们并不关系消息本身应该如何构建,也不关系消息的请求、获取、存储以及如何保证安全可靠。像 WebSockets 这样在 TCP 之上的协议,添加了一些额外的功能,例如使用头部(header)传输元数据,通过多个数据包分割较大的消息,简单的身份验证,以及路由/重定向相关信息。本质上它们仍然是点对点交换数据的方式。当涉及到构建更大,更复杂的系统时,你需要一个更高层次的通信范式: 发布-订阅 发布-订阅模式是在大规模系统中被广泛使用的通信方式,用于多对多无状态消息传递。“订阅者”(Subscribers)可以订阅“消息主题”(topics,channels,events,namespaces), “发布者”(Publishers)可以将消息发布到“消息主题”,通过路由,所有的订阅者都将收到。这种范式是非常灵活,高效和可扩展。它将发送者与接收者隔离开,允许订阅者自由得订阅主题或取消订阅。这和我们日常订阅报纸是一样的。有许多支持发布-订阅的协议:MQTT,STOMP,WAMP 等等。那么我们应该如何选择呢? MQTT MQTT(Message Queue Telemerty Transport)[2]是一种二进制协议,主要用于服务器和那些低功耗的物联网设备(IoT)之间的通信。它位于 TCP 协议的上层,除了提供发布-订阅这一基本功能外,也提供一些其它特性:不同的消息投递保障(delivery guarantee),“至少一次”和“最多一次”。通过存储最后一个被确认接受的消息来实现重连后的消息恢复。 它非常轻量级,并且从设计和实现层面都适合用于不稳定的网络环境中。 什么时候应使用它? 物联网(IoT)场景中更适合,支持几乎所有语言进行开发,并且浏览器也可通过 WebSocket 来发送和接收 MQTT 消息。 同时,对于MQTT Broker,也有很多选择,如 Mosquitto[3] 或 VerneMQ[4] 以及基于云的 MQTT 平台,如 HiveMQ[5] 或 CloudMQTT[6]。 STOMP 面向流文本的消息传输协议(STOMP,Streaming Text Oriented Messaging Protocol)[7],是 WebSocket 通信标准。在通常的发布-订阅语义之上,它通过 begin/publish/commit 序列以及 acknowledgement 机制来提供消息可靠投递。 由于协议简单且易于实现,几乎所有的编程语言都有 STOMP 的客户端实现。但是在消息大小和处理速度方面并无优势。 什么时候会使用它? 当与 Apache Apollo[8] 这样的多协议代理(multi-protocol broker)中间件结合使用时,可以做许多有趣的集成。比如在浏览器的图表中不断更新 IoT 设备的数据。 选择二进制还是基于文本? 到目前为止,我们已经讲了两个协议:一个二进制、另一个基于文本。让我们快速比较一下差异:通过控制线缆中光或电的打开或关闭(逻辑开关),或控制 WiFi 信号的波峰或波谷来实现计算机之间的信息交换。从原理上来说,这是基于二进制的形式。因此,从这个层面来说所有协议都是二进制协议。信息一旦发送,接收方有两个选择:它可以将 0/1 流分组成字节序列,进而获取(解析)信息;或者可以执行额外的步骤,将其转换为文本,然后再解析此文本。前一种方法称为(基于)二进制的。它节省了一些昂贵的操作,同时是传输任何非文本信息的标准形式。例如,图像,音频,视频或文件。当然它也可用于发送文本信息。例如,通过向每个消息增加几个字节来表达元信息,比如描述该消息的长度或类型,这样就只需将实际的消息数据转换为文本。然而,由于在许多发布-订阅式的架构中,信息交换是基于文本的,所以许多协议选择简单地将整个信息转化为文本,从而降低复杂性并提高了可读性,当然带来的代价就是需要再消息接受后执行额外的计算任务。 WAMP Web 应用消息协议(WAMP,Web Application Messaging Protocol)[9],它尝试开发一种开放的、基于文本的协议标准,并且结合了基于发布-订阅的请求/响应编程模型,同时具备强大的路由和消息投递策略。目前它被广泛用于集成 crossbar.io[10] 路由器和 autobahn 的高速缓存客户端[11]。 Pusher / PubNub&Co 那些实时通信平台即服务(Realtime platform-as-a-service)的产品,例如 Pusher 或 PubNub,通常使用它们自己的专有协议。Pusher 已经公开了它们研发的基于 JSON 协议的详细规范[12],并且鼓励第三方或社区帮助构建不同语言的客户端。Pubnub 虽然更封闭一些,但它们目前支持一系列其它开放协议进行交互,如 MQTT。 队列 有些场景下,简单的发布-订阅模式还不够。这就是队列存在的场合:它支持多种不同的消息和存储的模式。 通过获取/确认策略,消费者接收到队列的一些消息,确认他们的“消费”,处理它们,然后取下一批消息。这是一个强大同时常用的方式。 想象一下,你正在构建一个类似 Instagram 的产品,它允许用户上传图片并添加各种滤镜。应用滤镜的过程是一个计算密集型的操作。因此,不能在上传时直接进行操作,所以接收图像的服务器只是记录下在文件系统中的位置,接着将“什么图像需要使用什么样的滤镜”这个任务添加到任务队列中。 另一台专门用于处理滤镜的机器可以从任务队列中获取这个任务,读取原始图像文件,应用滤镜,并确认这个任务已经消费(完成)。之后为了水平扩展图像处理的能力,只需要添加更多的消费者(处理滤镜的机器)来处理任务队列即可。 这种模式非常易于扩展,可以添加复杂的路由策略,任务分配策略等。 AMQP 高级消息队列协议(AMQP,Advanced Message Queuing Protocol)[13]是各种消息队列协议中的佼佼者。RabbitMQ[14] 和 HornetQ[15] 都是实现该协议的流行中间件。 什么时候会使用它? 当简单的发布-订阅模型不能满足使用要求。AMQP 十分可靠且功能强大。当然它及它的实现并不是足够轻量级。如果你需要一个更轻量级的选择,那接下来的内容可能会更好: ZeroMQ ZeroMQ[16] 既是一个协议,也是一套协议实现的组件。提供比 AMQP 更高速同时去中心化的替代方案。 什么时候会使用它? 当你需要海量吞吐以及无单点故障风险的消息队列支撑你的复杂工作流,那么 ZeroMQ 是个不错的选择,当然,你需要对陡峭的学习曲线做好准备。 JMS Java 消息服务(JMS,Java Messaging Service)[17],是协议同时也是 Java 消息服务规范的标准实现,同时也是 Java 企业版(JEE)规范的一部分。 什么时候应使用它? 当你使用 Java 栈,同时也为 Java Enterprise Platform 付费了,那 JMS 是最佳选择。如果没有,那就优先考虑上述那些方案。 请求/响应 有时我们只需要发送单个请求,并等待收到一个响应,这完全可以使用HTTP请求完成 / 。 但是既然你已经建立了一个与服务器的持久连接 ,那为什么不利用它呢?这种通过持久连接进行的请求/响应模式的通信过程,通常被称为远程过程调用(RPC,Remote Procedure Calls)或远程方法调用(RMI,Remote Method Invocation)。AMQP 或 ZeroMQ 可以通过响应队列(response-queue)来实现这种模式,JMS 可以直接支持 Java RMI。 DataSync DataSync 是实现实时通信的最新可选方案。DataSync 将数据存储中的数据同步给客户端。客户端对数据的变更都将同步给所有的订阅者。DataSync 隐藏了实时通信类应用中维护数据状态的细节,降低了复杂性,并极大加快了开发速度,但它目前仍然是一种没有开放的协议标准。 目前 DataSync 已可以在几个 PaaS 平台上使用,如 deepstreamHub[18],Firebase[19] 或 Realm[20]。 总结一下 利用 deepstream[21] 的分布式实时协议(DRP,Distributed Realtime Protocol),我们有信心找到一种方法,将所有上述概念组合成一个协议,同时确保消息大小,可扩展性和互操作性方面的效率最大化。 参考 https://xkcd.com/ http://mqtt.org/ https://mosquitto.org/ https://vernemq.com/ http://www.hivemq.com/ https://www.cloudmqtt.com/ https://stomp.github.io/ https://activemq.apache.org/apollo/ http://wamp-proto.org/ http://crossbar.io/ http://crossbar.io/autobahn/ https://pusher.com/docs/pusher_protocol https://www.amqp.org/ https://www.rabbitmq.com/ http://hornetq.jboss.org/ http://zeromq.org/ http://docs.oracle.com/javaee/6/tutorial/doc/bncdq.html https://deepstreamhub.com/ https://firebase.google.com/ https://realm.io/ https://deepstream.io/ 推荐阅读 设计消息中间件时我关心什么? 如何实现支持数亿用户的长连消息系统 Redis作者又一大作:Disque分布式内存队列(一) 揪出一个导致GC慢慢变长的JVM设计缺陷 https://mp.weixin.qq.com/s/IyvKMTQY3Nzt719Bs09uyg

资源下载

更多资源
Mario

Mario

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

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text

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

用户登录
用户注册