Data

不晓得小伙伴们有没有注意过，在 Flowable 流程图的绘制过程中，咱们能够编写一个名为 dataObject 的元素，这个元素能够指定变量的 id、名称以及数据类型等各种属性，并且在流程实例启动的时候，会主动将 dataObject 元素的信息转换为流程实例变量，这个货色也蛮好玩的，明天松哥就率领小伙伴们来捋一捋 Flowable 中的 dataObject。 1. 增加 dataObject首先咱们来看下，在流程绘制的过程中，如何去增加 dataObject 对象。 IDEA 上的 Flowable 流程图绘制插件中还不能增加 dataObject 属性，这个须要咱们去 flowable-ui 中去增加。 咱们来轻易绘制一个如下这样简略的流程图： 我当初就想给这个流程图，增加 dataObject 属性，形式如下： 首先关上流程图，不要抉择任何节点，在下方能够找到数据对象属性，如下图： 点击之后，就能够增加 dataObject 了，如下： 配置实现之后，点击保留按钮。而后咱们下载这个流程图，下载之后，关上，咱们会发现这次的 XMl 节点比之前的 XML 节点多进去了如下一些内容： <dataObject id="name" name="流程绘制人" itemSubjectRef="xsd:string"> <extensionElements> <flowable:value>javaboy</flowable:value> </extensionElements></dataObject><dataObject id="site" name="流程作者网站" itemSubjectRef="xsd:string"> <extensionElements> <flowable:value>www.javaboy.org</flowable:value> </extensionElements></dataObject><dataObject id="date" name="流程绘制工夫" itemSubjectRef="xsd:datetime"> <extensionElements> <flowable:value>2022-09-23T00:00:00</flowable:value> </extensionElements></dataObject>2. 查问 dataObject接下来，依照之前文章介绍的形式，咱们先来部署并启动这个流程图。 当流程部署胜利之后，咱们能够在 ACT_RU_VARIABLE 表中查看到 dataObject 中的数据，如下图： 能够看到，dataObject 的数据是和执行实例 ID 以及流程实例 ID 相干的。 接下来，咱们能够通过如下形式来查问 ACT_RU_VARIABLE 表中的数据： @Testvoid test08() { List<Execution> list = runtimeService.createExecutionQuery().list(); for (Execution execution : list) { DataObject data = runtimeService.getDataObject(execution.getId(), "流程绘制人"); logger.info("key:{},name:{},value:{}",data.getDataObjectDefinitionKey(),data.getName(),data.getValue()); }}这里打印进去的信息就是咱们刚刚在定义的时候配置的所有流程信息了。 ...

Flink: Apache Flink 是一个框架和分布式解决引擎，用于在无边界和有边界数据流上进行有状态的计算。 Spark: Apache Spark 是专为大规模数据处理而设计的疾速通用的计算引擎。 Streaming：Streaming基于开源Storm，是一个分布式、实时计算框架。 Storm：Storm是Twitter开源的分布式实时大数据处理框架 ClickHouse：(不基于Hadoop集群，可独立装置)列式数据库，次要用于实时数据仓库，这个也是基于内存的，特点就是快。 HBase:HBase是一个分布式,版本化,面向列的开源数据库. 典型的NoSQL、分布式存储的数据库，速度够快。HBase是基于Hdfs的列式存储的分布式数据库。 Hive: Hive软件自身承当的是SQL语法解析编译称为MapReduce的性能职责。Hive是构建在Hadoop HDFS上的一个数据仓库工具，能够将结构化的数据文件映射为一张数据库表，并提供类SQL查问性能，其本质是将SQL转换为MapReduce或者Spark工作进行运行,对存储在HDFS中的数据进行剖析和治理. Hadoop大数据分析HDFS：分布式文件存储系统，大数据环境的基石.（数据存储）MapReduce(MR)：基于磁盘计算，次要用于大量数据的批处理计算.（计算）YARN：用于作业调度和集群资源管理的框架。（资源调度） Spark(RDD)：基于内存计算SparkSQL：个别状况都是基于离线数据处理Spark Streaming：个别状况是基于微批(实时)解决 Flink 流式计算引擎Flink SQL：相似SparkSQL，能够写SQL，更快的应用批处理操作Flink Streaming：流式数据，(开发思路)生产库产生数据一部分发送至kafka、一部分落库，后续Filnk对接kafka中的Topic ，实时对kafka中数据进行去重、荡涤、汇总、计算，维度能够寄存至redis中。

关注「Shopee技术团队」公众号，摸索更多Shopee技术实际 目录1. Shopee 数据系统建设中面临的典型问题2. 为什么抉择 Hudi3. Shopee 在 Hudi 落地过程中的实际4. 社区奉献5. 总结与瞻望湖仓一体（LakeHouse）作为大数据畛域的重要倒退方向，提供了流批一体和湖仓联合的新场景。目前，企业许多业务中会遇到的数据及时性、准确性，以及存储的老本等问题，都能够通过湖仓一体计划失去解决。 当下，几个支流的湖仓一体开源计划都在一直迭代开发中，业界的利用也都是在摸索中前行，在理论的应用中难免会遇到一些不够欠缺的中央和未反对的个性。Shopee 外部在应用过程中基于开源的 Apache Hudi 定制了本人的版本，以实现企业级的利用和一些外部业务需要的新个性。 通过引入 Hudi 的 Data lake 计划，Shopee 的 Data Mart、举荐、ShopeeVideo 等产品的数据处理流程实现了流批一体、增量解决的个性，很大水平上简化了这一流程，并晋升了性能。 1. Shopee 数据系统建设中面临的典型问题1.1 Shopee 数据系统简介 上图是 Shopee Data Infrastructure 团队为公司外部业务方提供的一套整体解决方案。 第一步是数据集成（Data Integration），目前咱们提供了基于日志数据、数据库和业务事件流的数据集成形式；而后通过平台的 ETL（Extract Transform Load）服务 load 到业务的数仓中，业务同学通过咱们提供的开发平台和计算服务进行数据处理；最初的后果数据通过 Dashboard 进行展现，应用即时查问引擎进行数据摸索，或者通过数据服务反馈到业务零碎中。上面先来剖析一下 Shopee 数据系统建设中遇到的三个典型问题。 1.2 流批一体的数据集成 第一个问题：在基于数据库的数据集成过程中，存在同一份数据同时面临流解决和批处理的需要。传统的做法是实现全量导出和 CDC 两条链路。全量导出链路满足批处理的需要，CDC 链路用于实时处理和增量解决的场景。 然而，这种做法存在的一个问题是全量导出效率低，导致数据库负载高。另外，数据一致性也难以失去保障。 同时，在批数据集构建上有肯定的存储效率优化，所以咱们心愿基于 CDC 数据去构建批数据集，以此同时满足三种解决场景的需要，进步数据时效性。 1.3 状态表明细存储 第二个问题是状态表明细的存储。咱们能够认为，传统批数据集是在某一时间点对业务数据整体状态的一个快照，压缩到一个点的快照会合并掉业务流程中的过程信息。这些变动过程反映了用户应用咱们服务的过程，是十分重要的剖析对象。一旦被合并掉，将无奈开展。 另外，在很多场景下，业务数据每天变动的局部只占全量数据的一小部分，每个批次都全量存储会带来很大的资源节约。 1.4 大宽表创立 第三个问题是大宽表的创立。近实时宽表构建是数据处理中常见的一种场景，它存在的问题是传统的批处理提早过高，应用流式计算引擎资源节约重大。因而，咱们基于多个数据汇合构建了业务宽表，反对 Ad hoc 类 OLAP 查问。 ...

Basic ConceptsData Subjects / Entities: Something that "exists", like student, grade, etc. Not equal to database tables. Database tables are sometimes artificial, duplicative(aggregates) Strong Entity: has a primary key.Weak Entity: has the partial key which acts as a discriminator between the entities of a weak entity set.Data Attributes of the Data Subjects: field / database column, like ID, name, etc.Relationship between Data Subjects: like instructor teaches a class, class is taught by an instructor. ...

本文由亚马逊云科技首席科学家李沐2021年5月首发于其知乎账号  五年前的明天我飞往西雅图加入亚马逊的面试。面试完后连夜做红眼航班飞往波士顿赶去加入老婆在MIT的博士问难。问难一半的时候电话响了，对方说祝贺你面试通过，想聊下薪水。我说其实就面了你们一家，间接给就是，先挂了。 问难完第二天跟老婆去市政局注销结婚。在宣誓厅门口排队的时候老板打电话过去，很兴奋的说你来了后能够做这个做那个。我说是挺好的，但先要结婚去了。老板一愣，道了一声祝贺，持续往下说。我不得不打断：得先走了，轮到咱们进去宣誓了。 五年一眨眼就过来了。里面来看最大的变动是多了两个娃。但最大的变动来自认知，是人生观、世界观、价值观的扭转。 博士毕业的时候曾写过我的领会 ——“博士这五年” （https://zhuanlan.zhihu.com/p/...） 很多同学留言说深受鼓舞。当初我想同样给大家分享这五年工作中的教训和感悟。更确切说是失败的教训，因为每一点就是付出了学费后取得的教训。心愿这些同样能对大家有所帮忙和启发。 事件的价值是对社会的价值读书的时候，你会有明确的指标，例如考试的分数、深造的学校、或找到好工作。工作后的最大不同是你有太多能够谋求的指标。 这个带来的扭转是你须要决定哪些事件当初做，哪些当前做，哪些能够不去做。 决定优先级应该是依据事件的价值。我当初评估一件事的价值是它对社会的价值，用公式来写就是 受害人数 x 人均工夫 x 单位工夫价值差 这里能从一件事件受害的人数，和受害的人均工夫是这件事自身属性。第三项取决于你对这件事实现的好坏，就是你做得比他人做的相似的事件要好，从而受益人从你这里受害比从他人那里多。 这个公式能够用在各种不同的事件上，接下来咱们会一直应用它。这里先举几个例子。例如平凡的产品个别具备极高的价值。拿微信来说，它是手机通信软件，面向几十亿手机用户，每人每天会应用数小时，所以它价值的前两项十分大。因为微信用户体验很好，它比其它替代品的用户体验好给用户带来的价值就是价值差。所以微信是一个十分有价值的产品。 举个小点的例子，例如你带人写一篇论文。论文影响的人数就是这个钻研畛域的大小；作用工夫是他人做一个跟你工作相干的研究所花的工夫，可能一辈子就几个月；价值差则是你的钻研在前人工作之上的奉献。这样看来，你须要做热门畛域和跨时代论文能力取到高价值。但咱们晓得一篇论文个别奉献不大、也就几个人会读，所以算下来根本没什么价值，为什么大家还是会踊跃“灌水”呢？ 这里咱们还要细看两个价值：一是你通过这个钻研相熟了一个新畛域或者新办法，对你集体有学习价值。二是你带人做钻研能晋升他们在想办法、做试验、和写论文上能力，对他们价值很大。所以即便是出名研究者，名字也会呈现在很多老手习作一样的论文下面。 再举一个更小的例子。过来四年里我花在带娃上的工夫比工作多。在相当一段时间内都感觉事业被娃耽误了。直到起初我用这个公式来算：尽管人数只是两个人，但受害工夫相当高，一周五十小时以上。而且父亲就一个，有我陪和没我陪对小孩来说区别微小（自我感觉），所以价值公式的后两项很高。此外，带娃对我集体也有价值，包含如何去了解思维形式齐全不一样的别人，以及时刻跟本人想暴怒的激动做奋斗，最终达到佛性的状态。这样算下来心里就顺了。 服务社会最初也是服务本人下面这个价值公式强调的是事件对别人的奉献。在用它之前，我的价值公式更关注本人。例如我罕用一件事件的好玩水平，或者外面的技术含量来划分优先度。问题是尽管享受做事件这个过程，但之后的成就感不高。有点相似打完游戏后的充实。因为做完后常常发现，这个尽管酷炫但没什么用，没多少人理会。起因是对集体的有间接高价值的事件，对别人价值不肯定大。很有可能这件事件自身只对很小群人有意义，可能每个人受害工夫短，或者其实是反复造轮子，市面上曾经有了差不多的替代品。 如果优化对社会的价值，你会失去对本人的延后回报。这个回报包含了你晓得做这个事件对别人有用时带来的更高层次的心田满足，以及别人从你这里受害时给与的馈赠（给你点赞、或者老板给你升职加薪）。当然，这两者不肯定同时呈现。很多时候你发明的价值不肯定被他人关注（数十年保护那些大家用起来司空见惯的开源工具包），也有时候大家会夸张吹捧你的奉献。你应该踊跃寻求他人的必定，这会给你更多的资源做更大事件。但你应该更关怀心田的满足，因为更可控、不容易别别人误导。更多是它会给你外在能源去把事件做得更好，这是你能一直成长的根基。 技术最终是为产品服务技术业余的同学刚进入公司通常会持续做技术。刚毕业那会儿我感觉进入大公司就是做技术，成为世界上最好的技术专家之一。而且不要做产品，因为如果做产品的话我为什么不本人守业呢，赚的钱还是本人的。后半句没什么问题，但前半句疏忽了技术最终是为产品服务这一事实。尽管因为公司的不同，对技术进入产品的预期工夫会不同，但通常在半年到五年之间。预期是超过五年的公司比比皆是，而且大多曾经作古。所以就算你在公司的钻研部门，也应该晓得公司对于技术落地工夫的预期。否则工夫一到就会面临公司削减不达预期的技术的投资。最坏状况是你们上新闻了：某某公司研究院院长到职，部门成员各奔东西。 那么什么样的技术能进产品？通常你会依据公司现有的产品有个大抵的想法。接下来你要晓得这个产品的次要价值是什么（套用之前的公式）。而后你须要去推敲你做的技术对这个产品的价值。如果你的技术能晋升产品的外围性能，哪怕是一点点，也会失去资源来落地技术。例如晋升微信的视频压缩技术、今日头条的举荐算法、苹果的外壳资料。反过来，如果没有抓住骨干，例如微信装皮肤、今日头条网页版减速，苹果操作系统兼容其余硬件。就算你能够做到比现有技术晋升很多，产品团队也可能没能源帮你，甚至一开始就通知你别做这个。 所以不论你是在产品团队做技术，还是在公司研究院，都应该对产品的价值有所理解。例如深刻了解产品经理的口头禅：市场、刚需、痛点、高频。同时也应该晓得你手上的技术对产品的价值，用它来领导你对技术路线的布局。 不想当将军的士兵不是好士兵人的满足感来自于比照，不论是比照他人还是比照本人过来。这个欲望驱动你去谋求有更大价值的事件。这意味着你须要更多资源去做大做强。最起码的是你须要一个团队。你可能是这个团队的管理者、领导者、或者专任两者。 兴许你更喜爱一个人做技术，至多我一开始是这么想的。但随着你的能力的增长，他人对你的责任的冀望也越大，你不可避免得去带一个团队。否则你得去其余中央找满足感。与其别动的被推到了这个地位，不如一开始就做好筹备。 这里有大量的职场书籍能够参考。我本人的教训很简略：领导者是领路者，须要有好眼光。管理者是后勤官，让团队执行高效。上面别离解释这两点。 放眼在三年当前领导者最重要的是在带着团队摸索未知领域时找出正确的方向。也就是说保障你们做的产品或技术是有价值的。因为做一件事须要工夫，所以你得预判事件在将来的价值。如果判断不准，大家辛苦做了很久，做完后发现成果个别，那么团队士气就会低下。各种问题就会接踵而来。 你去想一件事件将来的价值时，工夫不要太短也不要太长，三年比拟适合。假如你想持续沿着当初的方向走，那么须要思考三年后你关注的用户群和应用工夫是不是会发生变化。变多是坏事，不变示意你做不了太大，但如果会变少，你得思考要转向了。你还须要警觉新技术的呈现，很可能新的技术会短短几年就齐全颠覆旧技术（深度学习、智能手机、电动车）。剖析那些失败的例子，当事人其实很早就察觉到了新技术，但低估了它的能量。他们只看到了新技术比现有成熟技术的有余，而后套用成熟技术的倒退速度在新技术上，低估了三年后新技术能达到的高度，和用户喜新厌旧的水平。 如果你要做一个新的方向，那你可能不再有技术积攒劣势，就是跟他人比你给用户带来的价值差可能不显著，甚至更低。那么你须要找到好赛道（投资人口头禅），通常是颠覆性的新技术，以及随之带来产品和用户的变动。只有在疾速变动的赛道上，新入局者才更容易通过更精确的预测将来的价值来弯道超车。也就是盛世出英雄。 好的眼光须要一个长期的训练。你须要一直的去做深刻思考，取得本人独特的观点，而不是靠敌人圈里大家的浅见。所以你须要时不时放下手头的事件，给本人空出工夫做深刻思考。例如我会时不时去家左近的Bay Trail走上几个小时，边走边想。 治理的外围是诚心待人如果你有一个明确的团队指标，和一个高质量的团队，高效执行是瓜熟蒂落的事件。所以管理者有三个外围事件：招人、留住厉害的成员、和帮忙落后的。招人最现实是招比本人厉害的人。另外是每次招的人都比同级别的一半人厉害，这样能保障团队扩张时能一直晋升团队品质。 能力突出的成员在哪里都会受欢迎。你的一个工作是让他们能尽可能长的留在团队里（尽管最终是要走的）。一个方法是把本人放在他们的地位，设想你想你的领导如何待你。例如我本人最心愿的是一直做有更大价值的事件（成就感），并从中学到新货色（集体晋升）。在我艰难时候老板能给与反对（常常产生）。其余的都能够换算成以后待遇，例如能够多少工夫做不喜爱的事件（不同意一件事的价值，但又没能压服他人不做）、上下班路上很堵、食堂没西餐。所以大方向上是发明轻松的环境、每年能新立项有价值的我的项目、和尽量给大家争取待遇。 对于绩效不现实的队员，你须要经常性的指出问题并给予倡议，如果一段时间没改良则须要探讨是不是以后我的项目不适合。如果依然无停顿的话，那只能帮忙他们换组，或者要求他们来到。同样，你须要把本人代入对方的地位，明确想得到什么样的帮忙和尊重。绝大部分时候，不是他们人不行，只是你们不适合。欢快的离别能让前成员更快的找到更适合的职位（从而防止他们给你寄刀片）。 专一！专一！有人说守业公司一个常见死因是在有了肯定问题后自觉扩张。这个在哪里都成立。不论你是一个人，带一个团队，还是领导一家公司，资源总是无限。集中资源在最有价值的事件能力保障胜利。例如苹果好几十万人，但对于产品线的扩张上十分审慎。从而能保障每一款产品都砸上足够多资源来颠覆市场。在初期你兴许能够广撒网多捕鱼，一旦事件的价值缓缓清晰，咱们须要逐渐集中资源。因为同时把做几件相似的事件最好，不如只把一件事件做到极致、做到市面上最好。这样你总是能够失去正的价值差。一个第一比十个第二好，第三通常都活不长。同样的情理也能够用在生存、社交、和学习上。 只有投入力量，短板能够变成劣势 以前每次公布MXNet的新个性时，知乎同学都是吐槽：回去写好文档先。大家都晓得程序员不喜爱写文档。我从小语文和英语都是在及格线彷徨，更是心有冲突。17年的时候痛下决心来写文档，我把我所有留下做技术的工夫都花在下面，最初跟大家一起写出了《入手学深度学习》这本教科书，当初被全世界近200所大学采纳做教材。所以，你的有余能成为你的机会。只有你直面它，狠下心来花力量，一直去改良，你的短板会变成劣势。 取长补短所有命运的馈赠，都在暗中标好了价格。当我把精力都花在文档上时，便疏忽了MXNet自身。没能组织投入大量资源去继续晋升它的性能和易用性，导致它没能做到前二。从价值上来说，《入手学深度学习》和MXNet在用户数和用户价值上差不多，但用户应用深度学习框架工夫多于读教材，所以MXNet价值更大。在不善于的畛域破费了大力量打赢一仗，但在劣势畛域失去了价值更大一个，很难说是划得来。所以，在扬长和补短下面，肯定是要依据价值来判断，而不是体面。 分布式系统里通信开销才是大头当一台机器算力不够时，咱们用多台机器协同工作来共同完成工作。尽管分布式系统是很多家互联网公司的基础架构，但晋升性能依然是很难。因为每台机器理论算力会有不同，时不时还会罢工。而且一台实现本人的小工作时，常常须要等其余机器工作的后果，导致频繁数据通讯和期待。所以大家都晓得晋升性能的要害是缩小通信开销。 当你须要一个大团队来协同做一件事时，同样通信开销是大头，优化起来比分布式系统能难，因为人的差异性和不稳定性比机器大多了。人的能力不同，做事效率不同。每个人分工的不同，导致做事形式也不样，甚至优化的指标都不一样。大部分人只关怀本人的事件，不想也不愿操心他人的事件。如果不能无效把所有人拧在一起，就是人心涣散，做不成小事。如果你刚进职场，最要害的一点是你须要意识到：你须要预留足够多的工夫和精力来沟通。不要埋怨这是你们公司的制度问题，这是大团队作战时的固有景象。 升职我因为运气不错升到了一个比拟高的职位，从而有机会常常加入公司的从高级工程师、科学家到总监的升职评定。尽管公司、职位、级别不同带来差异性，但总体来说，一个人是否升职胜利取决于她做的最大我的项目对公司的价值是不是达到这个职位的要求。这里有三个要点：一是我的项目对公司的价值。意味着针对的人群和价值差都是公司关怀的，而不是你集体或者社会关怀的。这里价值通常就是给公司赚了多少钱，或者3-5年后可能会赚多少钱。二是看的是你最大的我的项目要够“品位”。累积很多我的项目，想通过不看功绩看苦劳升职可能是行不通的。三是你在我的项目中的奉献，例如你负责多大一块，是奉献了代码、团队协调、宣传、制订打算、还是申请到了资源。一个常见误会是跟人单干会升高我的奉献。如果你和合作者配合不好，导致1+1远小于2，那么你的奉献的确升高了。但如果通过单干把我的项目价值做大了，那么你分到的奉献是不会少的。特地是如果我的项目价值上了一个品位，那就更好了。 升职有一个常常被疏忽的“潜规则”是影响力。随着职位的升高，公司对你的影响力的冀望也越高。从能影响一个小团队，包含制订技术路线、帮忙队员上手、解答纳闷、甚至是帮忙他人来实现工作，到影响隔壁组（经理），影响隔壁部门（高级经理），影响隔壁团体（总监），最初到影响整个公司策略（副总裁）。 除非你是天生的领导者，不然你得花力量去造就本人的影响力。简略来说是在管好本人的事件外，踊跃的去帮忙他人。当他人信你、征询你意见、违心找你单干时，那你就有了对他们的影响力。你可能会感觉帮别人会耽搁本人的活。但从公司角度来看，是须要激励这种奉献精神，而且要予以处分。此外，你从中赢下的信赖给你带来名声和人脉，久远来看是很有用的。 加薪大公司里薪酬绝对通明，每个级别对应的薪酬通常能够在网上找到。一个级别内薪酬有浮动，个别有个最小值和最大值。80%在中值左近，中间各10%，别离是刚升到这个级别的人和快要到下一个级别的人。能够简略的认为，随着能力的晋升，你的薪酬会从最小值逐渐跳到最大值，而后升职到下一个级别对应的区间。 不同级别的薪酬中值通常是个等比序列，而不是等差。例如比你高一级的人可能工资比你多一半，但高三级的人不是比你多150%，而是多238%。在这个模型里，你须要优化你的五年后，或者十年后能达到的高度。所以在比拟offer时，你不要太关怀它们之间的数字差价，而是关怀去你去了之后的倒退（你说我当初多拿点去买币，说不定马上就财产自在了，那也是一个思路 ）。 总结：专一于最有价值的事件如果把这五年的感悟精炼成一句话的话，会是很平淡的一句：专一于最有价值的事件。首先，你须要对价值有清晰的意识。接着，对一件事件，不仅是要意识当下的价值，更多的是对将来价值的预测。其次，当你通过一直的疾速试错对将来有了把握的时候，你须要逐渐的把你能调用的资源专一到最有价值的那一件事件上，尽你可能的做好。 如果毕生中能做好几件有着极大价值的事，那也就值了。 写此文的时候惊闻袁隆平老师去世。谨以此文留念他平凡的毕生：专一于杂交水稻，发明了人类历史上最平凡的价值之一。我辈楷模。

2022 “熊” 心登程 联名 Global AI Bootcamp 人工智能畛域技术创新、R 语言在数据分析畛域奉献 具备挑战的开发者喜好揭秘 2022年首期【比特熊故事汇】富丽收场 特地提醒：文末有惊喜  比特熊用心送礼物互动情意：发送直播弹幕有礼转发直播预报至朋友圈，并配文你想对【比特熊直播间】说的话。播种多多点赞的小伙伴（点赞超过66），截图发送给比特熊微信。有机会取得2022年比特熊联名系列礼物，限定5份，先到先得。快快 Show 出你的创意，越踊跃越侥幸。 互动情意：发送直播弹幕有礼本期直播时，参加弹幕问答或评论的小伙伴，比特熊会在每个直播平台随机抽取5位，送出粉丝们喜爱的比特熊贴纸。欢送大家踊跃发言，让比特熊捕捉到特地的你。 举手参加：精选热评有礼在下方评论区写下你对本期直播有哪些期待或者对于嘉宾有什么问题，入选精选评论，截图发给比特熊微信，即可取得带有比特熊 logo 的限定收纳袋一个。限定10个，速来评论。 欢送大家继续关注【比特熊直播间】 心愿始终反对比特熊的你播种满满技能和幸福处分 比特熊直播间，只做真直播 扫描比特熊个熊微信二维码 退出【比特熊粉丝后援会】 与开发者一起嗨聊，期待成为你的好友~

Amazon DocumentDB(兼容MongoDB)是一项疾速、可扩大、具备高可用性的全托管文档数据库服务，可反对MongoDB工作负载。明天，咱们发表Amazon DocumentDB正式取得MongoDB 4.0兼容能力。通过此次降级，当初您能够应用原子性、一致性、隔离性与持久性（ACID）事务，为数据库或集群关上变更流游标等等。对于Amazon DocumentDB 4.0的残缺发行版阐明，请参阅MongoDB 4.0兼容性。 Amazon DocumentDB(兼容MongoDB)https://aws.amazon.com/cn/doc...MongoDB 4.0兼容性https://docs.aws.amazon.com/d...在本文中，咱们将独特理解Amazon DocumentDB 4.0当中的新增性能，并向您展现如何在Amazon Cloud9环境之上应用Amazon DocumentDB 4.0及事务。 想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注在上海、北京、深圳三地举办的2021亚马逊云科技中国峰会！点击图片报名吧～ Amazon DocumentDB 4.0中的新个性以下是Amazon DocumentDB 4.0引入的各项次要性能个性。要查看新性能的残缺列表，请参阅MongoDB 4.0兼容性。 MongoDB 4.0兼容性https://docs.aws.amazon.com/d...ACID事务–Amazon DocumentDB现可反对跨多个文档、语句、汇合及数据库执行事务。事务反对使您可能跨Amazon DocumentDB集群内的一个或多个文档执行ACID操作，从而简化利用开发流程。对于更多详细信息，请参阅事务。 事务https://docs.aws.amazon.com/d...1.变更流–当初，您能够在集群层级 (client.watch()或 mongo.watch()) 或者数据库层级(db.watch())开启变更流。您也能够指定一个 startAtOperationTime以关上变更流游标，并将变更流的保留周期缩短至7天（之前最多为24小时）。对于更多详细信息，请参阅在Amazon DocumentDB上应用变更流。 在Amazon DocumentDB上应用变更流https://docs.aws.amazon.com/d...2.Amazon DMS–当初，您能够应用Amazon Database Migration Service (Amazon DMS)将MongoDB 4.0工作负载迁徙至Amazon DocumentDB 4.0。Amazon DMS现可反对以MongoDB 4.0为源、以Amazon DocumentDB 4.0为指标，并能够Amazon DocumentDB 3.6为源实现由3.6版本到4.0版本的降级。对于更多详细信息，请参阅 将Amazon DocumentDB 作为Amazon Database Migration Service的指标。 Amazon Database Migration Servicehttps://aws.amazon.com/cn/dms/将Amazon DocumentDB作为Amazon Database Migration Service的指标https://docs.aws.amazon.com/d...3.监控–通过增加事务，当初您能够应用五项新的Amazon CloudWatch指标: TransactionsOpen, TransactionsOpenMax, TransactionsAborted, TransactionsStarted 以及 TransactionsCommitted, 外加 currentOp, ServerStatus与 profiler等新字段。对于更多详细信息，请参阅应用Amazon CloudWatch监控Amazon DocumentDB。 ...

交互式应用程序对于申请解决与响应速度提出了更高的要求，而这种要求也体现在架构内的所有组件上。如果您恰好采纳的是蕴含泛滥小型独立服务并互相通信频繁的微服务架构，那么速度就是决定利用体验的关键因素。 长久以来，各方都对数据库性能给予高度关注。而当读取提早须要管制在微秒级别时，能够在长久化数据库之前搁置一套内存缓存。而目前最具人气的缓存解决方案当数——Redis，一套开源的内存数据存储。事实上，依据Stack Overflow公布的《2021年开发者考察》报告，Redis在过来五年中始终蝉联最受欢迎数据库宝座。 在亚马逊云科技上，同样能够进行这样的缓存设置。将Amazon ElastiCache （一项齐全托管的内存缓存服务，兼容Redis）作为低提早缓存搁置在Amazon Aurora或Amazon DynamoDB等长久数据库服务之前，能够最大水平升高数据失落率。然而，这种形式要求咱们在利用中引入自定义的数据同步程序，确保缓存与数据库内容始终同步，而这进步了缓存与数据库经营老本。   想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注2021亚马逊云科技中国峰会！点击图片报名吧～ Amazon MemoryDB for Redis现已正式推出近期，咱们快乐地发表Amazon MemoryDB for Redis曾经正式推出。这是一套新的高持久性、兼容Redis的内存数据库。Amazon MemoryDB for Redis可能帮忙您经济高效地构建起读取性能达微秒级别、写入性能维持在个位数毫秒，而且持久性与可用性极高的应用程序。 相较于以往将低提早缓存部署在长久数据库之前的作法，当初能够间接将Amazon MemoryDB for Redis作为独立主数据库应用。您的所有数据都将存储在内存当中，实现低提早与高吞吐量的数据拜访能力。 Amazon MemoryDB for Redis与开源Redis我的项目放弃着良好的兼容性，您能够在这里应用本人相熟的Redis数据类型、参数及命令。换句话说，您能够在之前曾经积攒的基于开源Redis的代码、应用程序、驱动程序及工具间接与Amazon MemoryDB for Redis配合应用。作为开发人员，您能够立刻拜访各类数据结构，例如字符串、散列、列表、汇合、带范畴查问的排序汇合、位图、超级日志、天文空间索引及流等等。您还能够在这里取得多种高级性能，例如内置复制、最近起码应用（LRU）清理、事务与主动分区等等。Amazon MemoryDB for Redis全面兼容Redis 6.2版本，并反对以开源形式公布的后续更新版本。 置信不少敌人看到这里会心生疑难——那Amazon MemoryDB for Redis与Amazon ElastiCache相比，到底孰优孰劣？毕竟这两种服务都能拜访Redis数据结构与API。咱们能够分以下几点来看： 1，Amazon MemoryDB for Redis可能平安充当您应用程序的主数据库，提供良好的数据持久性、微秒级读取与个位数毫秒级写入提早。应用Amazon MemoryDB for Redis，您无需在数据库前增加缓存，即可为交互式应用程序及微服务架构提供必要的低提早性能。 2，另一方面，Amazon ElastiCache为读取及写入操作均提供微秒级提早。它是缓存类利用场景的现实解决方案，专门放慢从现有数据库中拜访数据的速度。Amazon ElastiCache也能够作为主数据存储应用，但前提是您的用例可能承受数据失落（例如，应用另一数据源疾速重建数据库）。 应用Amazon MemoryDB for Redis作为主数据库客户数据管理无疑是各类业务流程中的重要组成部分。只须要几行代码，咱们就能创立出微服务框架。更重要的是，Amazon MemoryDB for Redis为咱们提供了生产环境下必须的持久性与高可用性，而且无需在后端增加额定数据库。 联合工作负载的理论须要，咱们也能够增加或删除节点实现集群的横向扩大，或者迁徙至配置更高或更配的节点类型对集群进行纵向扩大。Amazon MemoryDB for Redis还反对通过分片进行写入扩大，以及通过增加正本进行读取扩大。咱们的集群可能在规模伸缩期间持续放弃在线，并失常反对读取/写入操作。 上线工夫与费率规范Amazon MemoryDB for Redis现已在美国东部（北弗吉尼亚州）、欧洲（爱尔兰）、亚太地区（孟买）以及南美洲（圣保罗）区域上线，后续还将登陆更多亚马逊云科技区域。 您能够应用亚马逊云科技治理控制台、亚马逊云科技命令行界面（CLI）或者亚马逊云科技开发工具包在几分钟之内轻松创立一个Amazon MemoryDB for Redis集群。 ...

在Amazon Redshift的帮助下，客户得以顺利完成一系列业务指标，例如从减速现有数据库环境，到提取网络日志以进行大数据分析等等。Amazon Redshift是一套全托管PB级大规模并行数据仓库，领有极低的上手难度与杰出的性能体现。Amazon Redshift还提供凋谢的规范JDBC/ODBC驱动程序接口，供您间接对接现有商业智能（BI）工具并复用现有剖析查询方法。 Amazon Redshifthttps://aws.amazon.com/cn/red...Amazon Redshift可能运行任意类型的数据模型，涵盖生产事务处理零碎第三范式模型、星型与雪花型模型、数据仓库以及各类简略的立体表等。 本文将向大家介绍如何在利用Amazon Redshift过程中实现性能优化，并针对各类优化形式做出深刻分析及操作领导。   想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注2021亚马逊云科技中国峰会！点击图片报名吧～ 内容更新本文更新了2019年初公布的同名文章，旨在纳入一年多以来亚马逊云科技的各项最新进展，并将着重对其中要点做出论述。 查问吞吐量比查问并发性更为重要配置并发性（如内存治理）能够通过Automatic WLM与Query Priorities队列优先级机制将并发能力引入Amazon Redshift的外部机器学习模型。在大规模生产集群当中，咱们看到自动化流程会为某些工作负载调配更多的流动语句，并对其余类型的用例调配较少流动语句。这种作法是为了最大水平进步吞吐量，保障Amazon Redshift集群可能在特定时段之内实现特定工作总量，例如实现每分钟300条查问，或者每小时解决1500条SQL语句等。本文倡议大家充分利用并发机制进步吞吐量，因为吞吐量正是对集群用户具备间接影响的一类外围性能指标。 除了通过优化Automatic WLM设置实现吞吐量最大化之外，Amazon Redshift中的并发扩大性能还能够将集群的吞吐量扩大至原始集群固有吞吐量的10倍。目前Amazon Redshift将10倍设定为吞吐量的软限度，大家能够依据需要与你的客户团队分割以调整此下限。 关注Amazon Redshift驱动程序Amazon Web Services倡议大家应用Amazon Redshift JDBC或ODBC驱动程序，借此进步性能体现。每种驱动程序都对应多种可选配置，您能够进一步调整以管制语句使用量以及后果集中的具体行数。 对各类常见数据库治理工作进行自动化，借此升高应用门槛2018年，咱们曾在文章中通过排序键、编码、表保护、散发以及工作负载治理等角度探讨了性能优化方面的几大要害注意事项。自那时以来，Amazon Redshift先后增加多项自动化性能，为SET DW提供100%信息反对、将表保护纳入Amazon Web Services服务职责（不再由用户方承当），并通过智能化水平更高的默认设置加强了开箱即用性能。即便表工作随时间推移而有所变动，Amazon Redshift Advisor仍会继续监控集群以寻找各类优化机会。Amazon Web Services还公布了用于量化Amazon Redshift性能的基准计划，帮忙大家轻松重现性能测试后果。 Amazon Redshift Advisorhttps://docs.aws.amazon.com/r...基准计划https://github.com/awslabs/am...应用RA3节点与Amazon Redshift Spectrum实现计算与存储资源的独立扩大除了本来提供的Dense Compute与Dense Storage节点等便捷集群构建块之外，当初大家还能够应用其余工具进一步对计算与存储资源进行独立扩大。Amazon Redshift Managed Storage（即RA3节点家族）将帮忙大家专一于调整计算资源量，而不用分神于存储容量问题。此外，并发扩大则容许咱们依据理论需要，对整个集群内的其余计算资源进行调整。Amazon Redshift Spectrum应用由Amazon Simple Storage Service(Amazon S3)提供的、近乎有限的存储容量以反对按需计算层，其容量可高达主集群容量的10倍，且现已提供配套的物化视图反对选项。 Amazon Redshift Spectrumhttps://docs.aws.amazon.com/r...Amazon Simple Storage Servicehttps://aws.amazon.com/cn/s3/利用暂停与还原性能优化应用老本当初，所有Amazon Redshift集群皆可应用暂停与还原性能。对于按需创立的集群，集群暂停操作将进行按秒计算的服务计费。预留实例集群则可通过暂停与还原性能，定义特定拜访工夫或在特定工夫点上解冻数据集。 技巧一：应用Amazon Redshift物化视图获取预计算后果物化视图可能极大改善高反复度、可预测型剖析工作负载的查问性能，包含仪表板、商业智能工具中的查问，以及提取、加载与转换（ELT）等数据处理操作。数据工程师可能轻松轻松创立并保护一套蕴含物化视图的高效数据处理管道，同时将性能劣势无缝扩大至各类数据分析与商业智能工具当中。 物化视图实用于须要反复执行、且后果具备肯定可预测性的查问操作。应用程序能够查问物化视图中保留的事后计算数据，而不用对大型表重复执行资源密集型查问。 当基表中的数据产生变更时，您能够收回Amazon Redshift SQL语句“refresh materialized view”以刷新物化视图。在收回刷新语句之后，您的物化视图将蕴含与惯例视图雷同的数据内容。刷新能够采取增量刷新与齐全刷新（从新计算）两种具体模式。Amazon Redshift还会在实现上一次物化视图刷新之后，尽可能通过增量形式刷新基表中的已变更数据。 ...

在本篇博文中，咱们将具体介绍如何应用 Amazon Cloud Formation 与 Amazon Neptune 重建亚马逊云科技 COVID-19常识图谱（简称CKG），以及如何在亚马逊云科技账户中应用托管在 Amazon SageMaker 上的 Jupyter notebook。COVID-19 常识图谱可能帮忙咱们摸索并剖析托管在亚马逊云科技 COVID-19 数据湖中的 COVID-19 凋谢钻研数据集（CORD-19）。该图谱的强度，由学术文献、作者、迷信概念以及各机构间的关联决定。此外， COVID-19 常识图谱还为 CORD-19 的搜寻页面提供技术根底。 亚马逊云科技 COVID-19 数据湖是一套公共集中存储库，其中包容着对于新型冠状病毒（SARS-CoV-2）及其相干疾病 COVID-19 的流传、特色与其余公开信息的最新数据集。对于更多详细信息，请参阅用于 COVID-19 数据分析的公开数据湖以及摸索亚马逊云科技 COVID-19 公开数据湖。 COVID-19 常识图谱由 Amazon Neptune、CORD-19 数据集以及来自 Amazon Comprehend Medical 提供的正文独特构建而成。截至2020年4月17日，CORD-19 数据集中共蕴含超过52000篇学术文献，其中41000篇为全文收录。这些数据来自多个渠道，包含 PubMed、bioArxiv 以及 medRxiv 等。在艾伦人工智能研究所与钻研行业的密切合作之下，数据集规模仍在持续增长，信息规范化与数据品质改善工作也在稳步推动。这套数据集波及多个学科，次要涵盖病毒学、转化医学以及流行病学层面的统计数据。 想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注在上海、北京、深圳三地举办的2021亚马逊云科技中国峰会！点击图片报名吧～上海站峰会曾经圆满闭幕，更多精彩内容，敬请期待北京、深圳分会吧！ 图构造COVID-19 常识图谱属于有向图。下表总结了其中各节点与边之间的关系。各有向边以指定的边权重从源节点指向指标节点。 下图所示，为123中的示例图谱。请留神，从论文（Paper）节点到作者（Author）及概念（Concept）节点延长出的连贯，以及从作者（Author）节点到钻研机构（Institution）节点间的连贯。 图中的蓝色节点代表论文，由黄色节点所代表的作者撰写而成，而作者又隶属于绿色节点代表的钻研机构。一篇论文能够有多位作者，而这些作者又可能隶属于多家钻研机构。 概念节点（红色节点）是由 Amazon Comprehend Medical Detect Entities V2 通过提取各类医学信息所生成，具体包含医学情况、药物剂量、解剖信息、医治程序以及药物类型等。 主题节点（上图中未显示）则是由通过扩大的 Latent Dirichlet 调配模型负责生成。这类生成模型依照察看到的内容对文件进行分组，并为每份文件调配一条主题向量混合指标。对于每一篇论文，该模型都会参考其中的纯文本题目、摘要以及注释局部，同时疏忽掉表格、数字与书目等局部。 ...

前言从2020年10月，基于 Amazon Graviton2 的数据库逐渐推出，您能够在应用 Amazon RDS for MySQL、Amazon RDS for PostgreSQL 、Amazon RDS for MariaDB 以及兼容 PostgreSQL 和 MySQL 的 Amazon Aurora时启动这些数据库实例。 Amazon Graviton2 处理器由 Amazon Web Services 应用 64 位 Arm Neoverse 内核定制，对第一代 Amazon Graviton 处理器进行了多种性能优化。这包含 7 倍的性能、4 倍的计算外围数量、每个内核 2 倍的公有内存、5 倍的内存速度和每个外围 2 倍的浮点性能。此外，Amazon Graviton2 处理器还具备全天候运行的全加密 DDR4 内存性能，并且每核加密性能进步 50%。这些性能晋升使 Graviton2 R6g 数据库实例成为数据库工作负载的上佳之选。 本文将向您展现Graviton2 R6g 数据库实例对R5数据库实例的性能加强以及从自建或者托管数据库上迁徙到Graviton2 R6g 数据库实例的办法流程。通过测试咱们能够分明地看到，无论是何种工作负载和并发条件，R6g实例比之等同资源配置的R5实例性能均有显著的晋升，而每小时单价却有降落，因此R6g实例对客户来说，有更好的性价比。 环境筹备1.环境信息 留神：Aurora的参数根本选用默认参数。因为sysbench1.0.18会有大量prepared statement，所以要设置max_prepared_stmt_count为最大值1048576保障测试顺利进行，否则初始化时可能遇到谬误FATAL: MySQL error: 1461 “Can’t create more than max_prepared_stmt_count statements (current value: 16382)” ...

Amazon Database Migration Service(DMS)是一项云服务，可轻松实现对关系数据库、数据仓库、NoSQL数据库以及其余类型数据存储的迁徙工作。Amazon DMS专门用于从多个本地实例，或者云与本地实例的组合将数据迁徙至亚马逊云。 Database Migration Servicehttp://aws.amazon.com/dms在应用Amazon DMS进行数据迁徙的过程中，最重要的是对以后正在进行的复制工作的状态执行监控。您能够通过工作的管制表以及Amazon CloudWatch服务进行这项操作。您能够通过Amazon治理控制台、Amazon命令行界面（Amazon CLI）或者Amazon DMS API监控工作进度、理论应用的资源与网络连接。 您通常应用多个工作执行迁徙。这些工作之间彼此独立，可能同时运行，而复制工作的数量则依据理论场景而有所区别。当面对大量同时进行的复制工作时，靠人工去监控每项工作的进度无疑是一项既干燥、又容易出错的工作。 想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注在上海、北京、深圳三地举办的2021亚马逊云科技中国峰会！点击图片报名吧～ 在本文中，咱们为您提供一套应用Amazon CloudFormation模板的自动化解决方案。此解决方案蕴含以下步骤： 为复制工作创立一个CloudWatch告警。创立Amazon DMS事件订阅。配置Amazon Simple Notification Service (Amazon SNS)，将工作的CloudWatch日志中发现的谬误告诉给您。创立一个Amazon Lambda函数，发送SNS告诉以重现CloudWatch告警。Amazon Simple Notification Service http://aws.amazon.com/sns前提条件在开始之前，您必须领有以下资源： Amazon DMS源与指标端点一个 Amazon DMS复制实例启用日志记录的Amazon DMS复制工作（对于具体阐明，请参阅应用Amzon DMS创立继续复制工作）一个 SNS主题应用Amzon DMS创立继续复制工作https://docs.aws.amazon.com/d...在具备以上先决条件之后，大家即可开始主动执行复制工作监控。 用于Amazon DMS复制工作的CloudWatch告警对工作状态进行监控的首选办法，就是为复制工作创立CloudWatch告警。因为只有复制工作的指标产生扭转，告警就会被立刻触发。 咱们建议您为以下DMS指标设置告警： CDCLatencySourceCDCLatencyTargetCDCChangesDiskSourceCDCChangesDiskTarget对于Amazon DMS指标的更多详细信息，请参阅Amazon Database Migration Service 指标。 Amazon Database Migration Service 指标https://docs.aws.amazon.com/d...CDCLatencySource CDCLatencySource是指从源终端节点中捕捉的最初一个事件与 Amazon DMS实例的以后零碎工夫戳之间的距离 (秒)。如果因为工作范畴限度起因而没有从源终端节点处捕捉到任何变更，则Amazon DMS将此值设置为零。 在复制期间，Amazon DMS会从源数据库事务日志中读取变更。 依据源数据库的理论引擎，源事务日志可能蕴含未提交的数据。在复制进行期间，Amazon DMS会从事务日志中读取传入的变更，但仅将曾经提交的变更转发至指标，这最终将引发源数据库发送提早。 CDCLatencyTarget CDCLatencyTarget是指在指标上期待提交的第一个事件工夫戳与Amazon DMS 实例的以后零碎工夫戳之间的距离（秒）。如果存在指标没有解决的事务，则会产生此值。如果所有事务都失去及时处理，则指标提早将与源提早雷同。指标提早不应低于源提早。 指标提早之所以高于源提早，是因为前者代表的是从源数据库中的插入工夫、直到对应行产生提交为止的以后记录的总提早时长。 CDCChangesDiskSource CDCChangesDiskSource是指在磁盘上累积并期待从源处进行理论提交的总行数。 CDCChangesDiskSource当中的所有行都已经处于内存内，只是因为达到了容许驻留在内存内的最长工夫阈值而被逐出保留在磁盘上了。咱们的指标是理解引擎的内部结构，并应用工作设置将CDCChangesDiskSource的值最小化。例如咱们能够尝试设置MemoryLimitTotal与MemoryKeepTime的值来达到目标。如果须要理解更多详细信息，请参阅调试Amazon DMS迁徙：呈现问题时应采取的各项措施（第二局部）。 ...

数据总量的一直增长，使得负责为客户提供策略解决方案的企业面临日益严厉的业务挑战。好消息是，随着云端新型数据库技术的衰亡，种种创新型办法的呈现令这些挑战变得更易于解决。数据仓库曾经成为剖析团队高度关注的一种风行选项；除此之外，开发人员也心愿寻求更多替代性办法，应用更加多样化的技术扭转组织内商务智能的运作形式。对于心愿转换本身剖析平台的企业而言，图数据库无疑是个现实的抉择。得益于Amazon Neptune的无力反对，Thermo Fisher Scientific公司团队利用数据仓库平台构建起一套图数据库，其中囊括可用于反对组织内整体商务智能剖析性能的弱小工具。 Thermo Fisher Scientific公司是一家生命科学企业，致力于为科学研究、开发与制作需要提供广泛支持，旨在让整个世界更加衰弱、清洁与平安。Thermo Fisher Scientific商业团队是一个高度面向剖析的业务部门，致力于构建创新型应用程序以改善组织外部的业务经营形式，借此与须要要害工作产品的大型迷信客户群体建设起密切联系。作为寰球翻新团队的一部分，咱们应用Amazon Neptune构建常识图谱，借此反对工程师、分析师与数据科学家的利用程序开发流程，进而推动本身业务的全面倒退。咱们应用这套常识图谱为火线业务人员构建了举荐零碎，依据类似客户行为向客户提供产品倡议。咱们的业务团队应用这套举荐零碎在适当机会为客户提供满足客户需要的产品。在本文中，咱们将重要介绍Thermo如何立足现有亚马逊云科技数据仓库生态系统构建起Amazon Neptune常识图谱，以及如何将策略关系整合至常识图谱内以将其拓展为一套弱小的举荐零碎。 想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注在上海、北京、深圳三地举办的2021亚马逊云科技中国峰会！点击图片报名吧～ 关系数据库对图数据库凭借着杰出的简略性与广泛应用范畴，治理数据仓库的业务剖析人员能够应用关系数据库查问（SQL）轻松执行数据操作与查问工作。然而，某些特定剖析工作可能须要在多个数据层内进行遍历联接与聚合能力取得所需的后果。剖析中波及的实体越多，须要进行多层简单数据操作的可能性就越大。这不仅令整个申明性编码过程变得非常复杂，也可能导致每次运行查问都可能带来高提早。另外，这些查问可能往往难以了解与破译——如果编写查问的人员没有为相干逻辑增加解释，后来者甚至根本无法跟上思路。 在另一方面，图数据库是专为数据关系建设起的解决方案。对这些关系进行遍历以获取实质上的特色，这就缩小了跨域检索互连数据所消耗的工夫与复杂性。以此为根底，分析师可能明确理解本人的查问从哪里开始、到哪里完结。图查询语言中还内置有弱小的算法，可帮忙大家应用关系数据库所无奈实现的逐渐遍从来解决问题。这意味着图数据库特地善于从高度互联数据集中，为最终用户及应用程序提取深刻的见解。 但问题在于，图数据库中提供的查问性能往往很难在数据仓库中间接复制；更要命的是，数据仓库自身的实用性极强，曾经成为剖析生态系统中不可代替的重要一环。数据仓库易于应用、性能杰出，特地适宜受过SQL专业培训的用户应用。通过立足云端对各类剖析解决方案进行宽泛摸索，咱们的团队得出结论——数据仓库与图数据库应该在剖析生态系统中严密合作，保障在不同性质及复杂度的工作负载中别离应用对应的最佳工具。图数据库特地适宜多维分析这类难以使用关系数据库执行的工作，而关系数据库则侧重于图数据库无奈搞定的高强度计算密集型批处理工作负载聚合。那么，咱们的团队该如何构建起一套可能与数据仓库协同运作的常识图谱呢？Thermo Fisher Scientific商业团队设计出连通桥梁，解决方案当中蕴含一套弱小的数据仓库，可通过扩大构建起常识图谱，且整个体系齐全运行在亚马逊云科技云之上。 通过数据仓库构建常识图谱咱们的剖析生态系统重度依赖于数据仓库。咱们依据客户行为、外部经营、营销流动、客户账户构造等数据提供有深刻的见解，借此改善公司的业务经营。咱们首先从各种外部及内部源零碎中获取交易数据，而后对其进行整顿、剖析，并将后果集成至应用程序当中以供最终用户拜访。下图所示，为如何应用Python从各种源零碎处收集数据集，进而实现整个数据工程流程。 应用Python脚本与SQL转换，咱们能够为数据仓库构建自定义数据提取管道，借此满足上游看板、报告与应用程序的需要。这套计划取得了良好的收效，可能集中收集来自多个数据源的数据。事实也证实，保留咱们的Amazon Redshift数据仓库并将其集中在剖析生态系统之内，的确给剖析工作带来了弱小助力。因而，咱们将Amazon Neptune常识图谱作为Amazon Redshift数据仓库的衍生产品。下一节中，咱们将重点介绍如何构建大规模数据集成管道以桥接这两个彼此独立的平台。 图数据库ETL过程在用于将Amazon Redshift中现有关系数据迁徙至Amazon Neptune中图模型内的解决方案中，咱们充沛联合了Amazon Redshift的弱小数据转移性能与Amazon Neptune的批量加载性能。在下图中，咱们将整个流程简化为四个根本步骤。 步骤1与步骤2：应用适当的批量加载格局，对来自Amazon Redshift的数据以CSV文件格式导出。步骤3：将文件复制到与Amazon Neptune处于同一区域的Amazon Simple Storage Service (Amazon S3)存储桶当中。步骤4：调用Amazon Neptune指加载器API，加载CSV文件中的特定关系。Amazon Neptune批量加载器API帮忙咱们轻松便捷地加载大量关系。在本用例中，咱们在10分钟内加载了超过30万个顶点与1600万条边。Amazon Redshift的疾速批量导出性能与Amazon Neptune的疾速批量加载性能相结合，使得在数据仓库与图数据库之间高效迁徙大量数据成为可能。只有明确了须要从数据仓库迁徙至图数据库的实体与关系，即可轻松增加多个数据集。但除了执行剖析之外，咱们还须要认真思考图数据库的保护问题。 咱们在Amazon Neptune中保持数据更新的办法，是应用Amazon Step Functions配置自动化计划，借此在数据仓库与Amazon Neptune之间疾速复制变更的数据。在起步阶段，咱们的图谱规模绝对较小（20万个顶点，关系边少于1000万条），因而能够通过调度删除并从新加载图谱以随时保持数据更新。但随着图规模的继续扩大，在集群上执行残缺革除-从新加载操作的效率越来越低。尽管能够间接应用现成的并发解决形式以放慢图删除办法，但咱们依然决定开发一款自定义利用以实现增量化加载操作。这种增量式数据捕捉，相似于在事务与剖析零碎之间捕获变更数据的传统ETL办法。只管目前仍在开发当中，但其曾经可能剖析Amazon Neptune最新加载数据的相干元数据，而后通过各个原始数据源在Amazon Redshift中增加或更改的字段实现变更确定。为了进一步解决异样问题，咱们还决定持续在保护期间按计划执行残缺的历史数据刷新。 应用Amazon Neptune实现数据分析当初，图曾经加载就绪且源数据刷新也实现了自动化，咱们能够开始进行剖析了。在以下示例中，咱们将执行之前具体介绍过的批量加载过程，将表（LABS）与表（PRODUCTS）的简略行为关系加载至Amazon Neptune当中。这里，咱们将数据仓库的关系数据库模型转换为图数据模型，如下图所示。 只需应用两个顶点之间的关系，咱们就能答复商务智能层面的种种简单问题，例如： 咱们应该依据过往交互关系，向 lab举荐哪些产品？相距最多五个跃点的两个lab之间，存在着哪些行为重叠？与特定lab类似度最高/最低的lab是什么？lab购买了，但与之最类似的另一lab却没有购买的产品是什么？咱们应用Gremlin作为遍历语言构建查问，旨在帮忙解决这类问题以提供原型验证。参考Apache TinkerPop我的项目等领有丰盛材料的同类我的项目，咱们的Gremlin遍历语言学习过程变得十分简单易行。咱们从简略查问开始，逐渐摸索图谱中的机密： 计算图中的顶点数量：g.V().count()计算图中的lab顶点数量 ：g.V().hasLabel(‘lab’).count()查找所有已购买产品 ：g.E().hasLabel(‘purchased’).outV().hasLabel(‘product’)以此为根底，咱们逐渐丰盛查问性能，心愿能以更简单的形式解决更艰难的问题，例如： 依据lab X与lab Y之间购买行为的相似之处，咱们该如何为lab X提供产品举荐？请参阅以下代码： 1g.V().has(‘lab’, ‘lab_name’, ‘X’).as(‘Laboratory’).     out(‘purchased’).aggregate(‘self’).in(‘purchased’).where(neq(‘Laboratory’)).groupCount().order(local).by(values,desc).limit(local,1).select(keys).out('purchased').where(without('self)).values('product_name').dedup().23limit(25).toList()4依据另一lab的行为，此查问可能会给出lab X尚未购买、但却最感兴趣的25种产品。答复此类问题，有助于咱们开发出一款举荐工具，应用咱们的Amazon Neptune常识图谱建设举荐引擎。以往，应用关系数据库解决方案执行SQL查问以答复此类问题时，咱们须要进行大量批处理与计算操作；但现在，Amazon Neptune帮忙咱们将整个流程简化为繁多Gremlin查问。咱们能够间接加载两个实体（labs与 products）之间的关系以间接答复这类问题。 ...

Amazon Relational Database Service (Amazon RDS) 与 Amazon Aurora 反对多种实例类型，可依据您的理论需要扩大数据库工作网域（请分参见文末参考资料中Amazon RDS数据库实例类与Aurora数据库实例类）。2020年，亚马逊云科技颁布面向Amazon RDS的全新M6g及R6g实例类型，又于日前发表正式推出搭载Amazon Graviton2处理器的Aurora R6g实例类型。值得一提的是，这种全新实例类型领有远超x86同类产品的性价比。 Graviton2处理器由亚马逊云科技应用64位ARM Neoverse外围定制构建而成，相较于第一代Amazon Gravtion处理器做出了多项优化。您能够通过Amazon RDS控制台或Amazon命令行界面（Amazon CLI）启动新的Graviton2 M6g与R6g数据库实例，并以最小停机工夫将多可用区数据库迁徙至Gravtion2实例，尽可能防止因迁徙造成的I/O解冻影响到失常服务。 在本文中，咱们将独特理解将现有RDS与Aurora数据库实例转为Graviton2实例类时的重要注意事项，包含应配合哪些先决条件及具体策略以尽量缩短停机工夫。 为什么抉择Graviton2？以下是将Amazon RDS与Amazon Aurora迁徙至Graviton2的几大外围理由： 1.Graviton2实例可依据具体数据库引擎、版本及工作负载，为RDS开源数据库提供最高达52%的性能价格比晋升。 2.与第一代Amazon Graviton处理器相比，Graviton2实例的性能进步达7倍、计算外围数量减少至4倍、单核心独立缓存减少2倍、内存容量减少了5倍、浮点性能则晋升2倍。 3.Graviton2处理器提供始终启用的全加密DDR4内存，且单核心加密性能晋升达50%。 4.在将Amazon RDS与Aurora数据库由英特尔架构迁徙至Graviton2实例时，大家无需进行任何移植或代码变更。 想学习 Graviton2 实例的更多玩法？来2021亚马逊云科技中国峰会与业内当先的技术践行者们一起探讨交换吧！点击图片报名吧～ 解决方案概述无论是对Amazon RDS (Amazon RDS for MySQL, Amazon RDS for PostgreSQL, Amazon RDS for MariaDB) 还是 Aurora (Aurora MySQL 与 Aurora PostgreSQL)，整个实例迁徙流程的根本步骤都大致相同。 在本文中，咱们假设这样一个用例，即一套运行有PostgreSQL 9.6.16版本的多可用区Aurora数据库集群，其中蕴含三个实例：一个写入实例与两个读取实例。 联合惯例最佳实际，咱们倡议先在非生产环境中测试整个流程。您能够首先应用生产数据库的快照，而后将其还原至这套非生产环境的实例当中，确保测试实例的配置（包含实例类、参数组设置、加密机制等）与现有生产实例基本相同。接下来，将您的非生产实例批改为Graviton2，而后通过验证测试确保所有均按预期实现配置及运行。 上面来看整个流程中的各次要步骤： 1.更新数据库（如果须要）： 确定以后数据库版本是否合乎迁徙至Graviton2所须要的最低版本。 将数据库引擎降级至所需的最低版本。 2.批改实例类： 确定您的批改策略以及对实例的批改程序。 将您的实例类批改为适当的Graviton2实例。 3.验证并确认应用程序是否失常运行。 ...

前言从2020年10月，基于 Amazon Graviton2 的数据库逐渐推出，您能够在应用 Amazon RDS for MySQL、Amazon RDS for PostgreSQL 、Amazon RDS for MariaDB 以及兼容 PostgreSQL 和 MySQL 的 Amazon Aurora时启动这些数据库实例。 Amazon Graviton2 处理器由 Amazon Web Services 应用 64 位 Arm Neoverse 内核定制，对第一代 Amazon Graviton 处理器进行了多种性能优化。这包含 7 倍的性能、4 倍的计算外围数量、每个内核 2 倍的公有内存、5 倍的内存速度和每个外围 2 倍的浮点性能。此外，Amazon Graviton2 处理器还具备全天候运行的全加密 DDR4 内存性能，并且每核加密性能进步 50%。这些性能晋升使 Graviton2 R6g 数据库实例成为数据库工作负载的上佳之选。 本文将向您展现Graviton2 R6g 数据库实例对R5数据库实例的性能加强以及从自建或者托管数据库上迁徙到Graviton2 R6g 数据库实例的办法流程。通过测试咱们能够分明地看到，无论是何种工作负载和并发条件，R6g实例比之等同资源配置的R5实例性能均有显著的晋升，而每小时单价却有降落，因此R6g实例对客户来说，有更好的性价比。 环境筹备1.环境信息 留神：Aurora的参数根本选用默认参数。因为sysbench1.0.18会有大量prepared statement，所以要设置max_prepared_stmt_count为最大值1048576保障测试顺利进行，否则初始化时可能遇到谬误FATAL: MySQL error: 1461 “Can’t create more than max_prepared_stmt_count statements (current value: 16382)” ...

AQUA（高级查问加速器）是什么？ AQUA是一款功能强大的硬件查问加速器，将配合RA3节点（ra3.4xl或ra3.16xl）与S3托管存储独特起效。 上面来看亚马逊云科技官网博文中的相干形容： 这套存储系统采纳多种提醒机制（包含数据块热度、数据阻塞与工作负载模式）治理缓存，借以实现更高性能。 除了缓存机制之外，AQUA还充分发挥Amazon Nitro System与定制化FPGA减速计划的劣势，在更靠近数据的地位解决规约及聚合查问对应的计算负载。这种形式可能缩小网络流量，减弱RA3节点中CPU的工作累赘，由此将查问性能晋升达10倍。更重要的是，AQUA不产生任何额定费用，也无需更改代码内容。AQUA还采纳Amazon Simple Storage Service (S3)提供的疾速、高带宽连贯资源。 利用快照创立AQUA集群这里，咱们将尝试通过快照还原性能创立AQUA集群。您能够抉择ra3.4xlarge或ra3.16xlarge节点类型。如果您曾经领有采纳这些节点的集群，则其中的AQUA会被默认配置为“Automatic”。要开始应用AQUA，请抉择[Actions]-[Configure AQUA]并将以下对话框中的 Automatic 配置调整为Turn On。 这里，咱们应用默认配置Automatic创立一套集群。在配置AQUA的过程中，您能够灵便调整以下选项： Automatic (默认)Redshift确定是否应用AQUA。截至目前，AQUA（高级查问加速器）应用状态仍为：尚未激活AQUA，但状况随时可能有所变动（“Currently, AQUA isn't activated with this option, but this behavior is subject to change”）。在变动之前，此状态依然等效于Turn Off；代表AQUA不会被激活。Turn On您将抉择始终应用AQUA。AQUA仅可在某些亚马逊云科技区域以及ra3.4xlarge与ra3.16xlarge节点类型当中激活。Turn Off您抉择不应用AQUA。 期待约5分钟后，AQUA即转为Available可用状态。能够看到，本文中的示例集群采纳AQUA“Automatic”配置进行启动。 创立测试数据AQUA在LIKE及SIMILAR TO等操作中的减速成果尤其杰出，这里咱们筹备了约3亿条数据。 dev=> create table lineitem (dev(> l_orderkey bigint not null,dev(> l_partkey bigint,dev(> l_suppkey bigint,dev(> l_linenumber integer not null,dev(> l_quantity decimal(18,4),dev(> l_extendedprice decimal(18,4),dev(> l_discount decimal(18,4),dev(> l_tax decimal(18,4),dev(> l_returnflag varchar(1),dev(> l_linestatus varchar(1),dev(> l_shipdate date,dev(> l_commitdate date,dev(> l_receiptdate date,dev(> l_shipinstruct varchar(25),dev(> l_shipmode varchar(10),dev(> l_comment varchar(44))dev-> distkey (l_orderkey)dev-> sortkey (l_receiptdate);CREATE TABLEdev=> copy lineitem from 's3://cm-bucket/redshift-immersionday-labs/data/lineitem-part/'dev-> iam_role 'arn:aws:iam::123456789012:role/AmazonRedshiftRole'dev-> region 'ap-northeast-1' gzip delimiter '|' compupdate preset;INFO: Load into table 'lineitem' completed, 303008217 record(s) loaded successfully.COPYdev=> select * from lineitem limit 1;-[ RECORD 1 ]---+----------------------------------------l_orderkey | 7428384l_partkey | 9121341l_suppkey | 621360l_linenumber | 4l_quantity | 23.0000l_extendedprice | 31323.4700l_discount | 0.0900l_tax | 0.0500l_returnflag | Rl_linestatus | Fl_shipdate | 1992-01-02l_commitdate | 1992-03-22l_receiptdate | 1992-01-03l_shipinstruct | DELIVER IN PERSONl_shipmode | FOBl_comment | haggle carefully about the furiously irAQUA性能测试这里，咱们通过显式更改Turn On/Off进行性能差别比照。要更新AQUA配置，您能够点击[Actions]-[Configure AQUA]。 ...

Amazon Aurora 既具备高端商用数据库的性能和可用性，又具备开源数据库的简略性和老本效益。它提供了比规范 MySQL 高五倍的吞吐量，并且具备更高的可扩展性、持久性和安全性。 Amazon Aurora应用了计算和存储拆散的架构，数据库集群蕴含一个或多个数据库计算实例以及一个跨多可用区的数据存储层。 Amazon Aurora 集群架构图 Amazon Aurora Parallel Query（并行查问）是 Aurora数据库的一项性能，实用于兼容 MySQL 的 Amazon Aurora。Aurora 最新的 MySQL 5.6 和 MySQL 5.7 兼容版本均反对并行查问。 并行查问充分利用了 Aurora 的架构，将解决向下推送到 Aurora 存储层，将计算散布到数千个节点上。通过将剖析查询处理卸载到 Aurora 存储层，并行查问缩小了与事务工作负载对网络、CPU 和缓冲池的争用，能够将查问速度进步多达两个数量级，同时放弃外围事务工作负载的高吞吐量。 并行查问非常适合 Aurora MySQL 数据库集群里具备蕴含数百万行的表以及须要数分钟或数小时能力实现的剖析查问。本文通过测试了各场景下的查问耗时，并行查问的启用对于OLTP事务性查问影响甚微，而对于OLAP剖析性查问则能显著进步速度。例如在试验场景下：在千万行至亿行的数据集里，应用db.r5.2xlarge机型，运行一个多表联结剖析查问，禁用并行查问时，耗时为22 分1.33 秒，开启并行查问后，耗时仅为39.74秒。 以下为试验内容，具体阐明了试验步骤并展示了并行查问所带来的优化成果。 试验环境筹备试验须要预置Aurora MySQL数据库集群以及MySQL客户端实例。 并行查问现已在由光环新网经营的亚马逊云科技中国（北京）区域以及由西云数据经营的亚马逊云科技中国（宁夏）区域正式推出。本试验应用了亚马逊云科技中国宁夏区域。 1. Aurora MySQL数据库集群要创立具备并行查问的 Aurora MySQL 集群，能够应用与其余 Aurora MySQL 集群雷同的亚马逊云科技治理控制台和 Amazon CLI 办法。您能够创立新的集群以应用并行查问，也能够通过从 MySQL 兼容的 Aurora 数据库集群的快照还原，创立一个数据库集群以应用并行查问。 在抉择 Aurora MySQL 引擎版本时，建议您抉择与 MySQL 5.7 兼容的最新引擎Aurora MySQL 2.09 或更高版本，以及与 MySQL 5.6 兼容的Aurora MySQL 1.23 或更高版本。应用这些版本，应用并行查问的限度起码，这些版本还具备最大的灵活性，能够随时关上或敞开并行查问。 ...

Amazon Timestream 是一种疾速、可扩大的无服务器工夫序列数据库服务，实用于物联网和经营应用程序，应用该服务每天能够轻松存储和剖析数万亿个事件，速度进步了 1000 倍，而老本仅为关系数据库的十分之一。通过将近期数据保留在内存中，并依据用户定义的策略将历史数据移至老本优化的存储层，Amazon Timestream 为客户节俭了治理工夫序列数据生命周期的工夫和老本。Amazon Timestream 专门构建的查问引擎可用于拜访和剖析近期数据和历史数据，而无需在查问中显示指定数据是保留在内存中还是老本优化层中。Amazon Timestream 内置了工夫序列剖析函数，能够实现近乎实时地辨认数据的趋势和模式。Amazon Timestream 是无服务器服务，可主动缩放以调整容量和性能，因而无需治理底层基础设施，能够专一于构建应用程序。 本文介绍通过Timestream、Kinesis Stream托管服务和Grafana 和Flink Connector开源软件实现物联网（以PM 2.5场景为示例）时序数据实时采集、存储和剖析，其中蕴含部署架构、环境部署、数据采集、数据存储和剖析，心愿当您有类似物联网时序数据存储和剖析需要的时候，能从中取得启发，助力业务倒退。 架构Amazon Timestream 可能应用内置的剖析函数（如平滑、近似和插值）疾速剖析物联网应用程序生成的工夫序列数据。例如，智能家居设施制造商能够应用 Amazon Timestream 从设施传感器收集静止或温度数据，进行插值以辨认没有静止的工夫范畴，并揭示消费者采取措施（例如缩小热量）以节约能源。 本文物联网（以PM 2.5场景为示例），实现PM2.5数据实时采集、时序数据存储和实时剖析， 其中架构次要分成三大部分： 实时时序数据采集：通过Python数据采集程序联合Kinesis Stream和Kinesis Data Analytics for Apache Flink connector 模仿实现从PM 2.5监控设施, 将数据实时采集数据到Timestream。时序数据存储：通过Amazon Timestream时序数据库实现时序数据存储，设定内存和磁性存储（老本优化层）存储时长，能够实现近期数据保留在内存中，并依据用户定义的策略将历史数据移至老本优化的存储层。实时时序数据分析：通过Grafana （装置Timesteam For Grafana插件）实时拜访Timestream数据，通过Grafana丰盛的剖析图表模式，联合Amazon Timestream 内置的工夫序列剖析函数，能够实现近乎实时地辨认物联网数据的趋势和模式。具体的架构图如下：部署环境1.1 创立Cloudformation请应用本人帐号 (region 请抉择 us-east-1)下载 Cloudformation Yaml 文件：https://bigdata-bingbing.s3-a... 其它都抉择缺省， 点击Create Stack button. Cloud Formation 创立胜利 1.2 连贯到新建的Ec2堡垒机:批改证书文件权限 chmod 0600 [path to downloaded .pem file]ssh -i [path to downloaded .pem file] ec2-user@[bastionEndpoint] ...

【注】本文译自：A Guide to DataOps - DZone Big Data DataOps 不仅仅是另一种开发方法。它通过民主化的拜访和微小的后劲从根本上扭转了组织应用数据的形式。    最近一项对于企业面临的大数据挑战的考察揭示了一些无关数据利用的惊人事实。38% 的企业“不足”令人信服的商业案例来应用他们的数据。34% 的公司没有足够成熟的流程来解决大数据技术，其中 24% 的公司无奈为最终用户提供大数据！     说这些发现令人震惊是轻描淡写。如果调查结果属实，那么很大一部分企业不晓得他们能够做什么——他们必须做什么——利用他们领有的数据，并持续从客户那里收集数据。与竞争对手相比，这使他们处于重大劣势。     在数据驱动的竞争格局中，漠视数据的益处，甚至无奈充分发挥其后劲，对组织来说只会意味着灾难性的终局。能够必定的是，其中许多组织正在收集大量数据。他们只是不想、不晓得或没有适当的流程来应用它。     局部问题是遗留数据管道。随着数据在数据管道中从源挪动到指标，每个阶段对数据的含意以及如何应用它都有本人的想法。这种不连贯的数据视图使数据管道变得软弱且难以扭转，从而使组织在面对变动时反馈缓慢。     应答这一挑战的解决方案是 DataOps。 什么是DataOps（数据运维）？    DataOps 是 data operationalization（数据操作化）的缩写，是一种合作数据管理办法，强调组织内数据管道的通信、集成和自动化。     与数据存储管理不同，DataOps 并不次要关注“存储”数据。它更关注“交付”，即让所有利益相关者都能够轻松取得、拜访和应用数据。它的指标是创立可预测的数据、数据模型和相干工件的交付和变更治理，以便在整个组织和消费者中更快地交付价值。     DataOps 通过采纳技术将数据的设计、部署、治理和交付自动化来实现这一指标，以改良其应用和提供的价值。这使所有应用数据的利益相关者都能够轻松拜访数据，并放慢数据分析的周期时间。     通过这样做，DataOps 大大提高了组织对市场变动的响应工夫，并使他们可能更快地应答挑战。 DataOps 解决的挑战和问题    大数据最重要的承诺——疾速且牢靠的数据驱动的可操作业务洞察——仍未实现，因为存在泛滥挑战，这些挑战可大抵分为组织、技术和人员（应用数据的人）的挑战。     DataOps 通过联合来自麻利、DevOps 和精益制作办法的学习和实际，帮忙克服这些挑战。以下是 DataOps 所要应答的最重要挑战： 速度    古代组织依赖（至多必须依赖）来自许多不同起源和许多不同模式的数据。清理、改良和应用数据可能是一个如此简单和漫长的过程，以至于当最终从中产生洞察力时，它们与疾速倒退的业务环境不再相干。     DataOps 从根本上进步了从数据中获取洞察力的速度。 数据类型    有时，组织收集的数据可能是非结构化格局，这使得从中提取见解变得极其艰难。此类数据源齐全有可能甚至有可能为新兴业务挑战提供线索。因而，仅仅应用易于解决的结构化数据是不够的。     DataOps 使组织可能辨认、收集和应用来自每个可用数据源的数据。 数据孤岛    DataOps 突破组织内的数据孤岛并集中所有数据。同时，它构建了弹性零碎，为每个须要拜访数据的利益相关者提供自助服务。这些零碎随着组织内外的变动而倒退，并且为“数据用户”提供了可预测的形式来查找和应用他们须要的数据。 DataOps 的业务劣势    通过克服挑战，DataOps 使 DataOps 团队可能将数据交付给须要它的人——数据工程师、数据科学家、ML 工程师，甚至客户——并且速度比以前快得多。这一成就为数据驱动型企业带来了多项益处，其中包含： 最大限度地利用数据    DataOps 为所有数据“用户”解锁数据，无论是分析师、高管，还是客户。它使数据交付自动化，并在此过程中容许每个部门从数据中提取最大价值。 后果是进步了竞争力、对变动的响应能力和更高的投资回报率。 在正确的工夫取得正确的见解    迄今为止，大数据的一个常见问题是在谬误的工夫取得正确的见解。来得太晚的见解是无用的。DataOps 将数据疾速提供给须要它的每个人。因而，他们能够比以往任何时候都更快地做出更理智的决策，使组织可能疾速倒退以适应市场变动。 进步数据生产力    DataOps 应用自动化工具将数据交付作为自助服务进行操作。因而，打消了数据申请和数据拜访之间的任何固有提早，从而使所有团队可能迅速做出数据驱动的决策。     DataOps 还解脱了手动数据管道变更治理流程的组织。相同，对数据管道的所有更改都通过简化和自动化，以提供疾速、有针对性的更改。 针对后果优化的数据管道    DataOps 在数据管道中退出了一个反馈循环，容许各种数据消费者辨认他们须要的特定数据并从中取得定制的见解。而后，每个团队都能够应用这些洞察来降低成本、发现新机会、增加收入并进步组织的盈利能力。 DataOps 的准则    在技术方面，DataOps 实现了组织最具开创性的里程碑之一——使他们的数据程序具备高度可扩展性，而不会影响数据分析的速度或品质。 因为它借鉴了 DevOps 的经验教训和实际，所以 DataOps 在许多要害方面与前者重叠。这在 DataOps 的三个根本准则中可见： ...

首先，这是我一直同时在用的 3 个开源同步服务。那为什么我要同时用着多个同步服务呢？主要是因为它们各有优势，有一些无可替代的功能。Resilio Sync 高级版提供的 可选择性同步，让我用 0KB 的占用空间，可以得到所有文件的目录和名称。在我需要的时候，又能以极快的速度下载到本地。这是个我使用极少的功能，但是却是使用中最为爽快的一个功能。分享和下载的时候，我都毫无负担，因为它们都不存在于本地，我只用下载自己想要的文件。Nextcloud 提供的文件 分享 可以让你有更多的选择以及权限控制，只用一条 url 链接，你就可以简单的分享给需要的人，而且还能提供文件操作动态，你可以知道文件在什么时候做了哪些变动，这对你希望监控文件动态的时候非常好用。并且它还提供许多不同类型的 App 拓展，其中包括 Rss程序、Keepass管理程序、音乐播放、视频播放 等诸多功能。Syncthing 这是我 个人文件同步 的主力服务，我用它进行跨设备同步和备份。它是我的 Inbox 文件夹，收集着每台设备上的数据，我用它来进行 数据、库、配置 等文件的同步。它的优点也非常简单，安装简单，网络要求低，提供完善的版本控制。我只需要后台开启，配置好，就无需再担心。当然，我并不单单只依赖上面 3 个同步服务（当然rsync、webdav、ftp我也用，但这不在讨论范围内。），我还搭配电脑的备份服务进行备份。家庭文件服务器还会有快照计划，重要文件也会定时冷备份。这样，我才能任性的对待数据，并再也不用担心它们会消失不见了。: )下面，我们进入正题，对比一下 3 款同步服务的优缺点吧。1. 平台覆盖平台SyncthingResilio SyncNextcloudiOS✘✔︎✔︎Android✔︎✔︎✔︎macOS✔︎✔︎✔︎Windows✔︎✔︎✔︎Linux✔︎✔︎✔︎Linux Arm✔︎✔︎✔︎Docker x86✔︎✔︎✔︎Docker Arm✘✘✔︎Nas System✔︎✔︎✘PS: 主要统计的是官方支持的平台。第三方方案，不计入统计。这里比较遗憾的是 Syncthing 并没有 iOS 客户端，曾经有一款但是现在已经下架了，我手机端主要用 Nextcloud 偶尔用 Resilio Sync（毕竟只同步大文件用）。docker arm 不支持的服务需要自行构建（第三方也可），通常支持 linux arm 的都支持 docker arm，但是官方只构建了 x86 版本。Nextcloud 的 Nas 版本很可能是有的，但是 Nextcloud 官方没介绍，NAS 系统 官方库一般也有下载，毕竟这个服务很普遍了。2. 功能对比功能SyncthingResilio SyncNextcloud版本控制阶段性版本控制回收站限客户端网络环境1. 同步无限制2. 中区中转服务器稀少1. 同步无限制2. 设备发现需国外环境1. 同步无限制2. 应用下载需国外环境3. 部分应用依赖国外服务同步速度1. 内网满带宽2. 外网依赖中转服务器带宽1. 内网满带宽2. 外网依赖同步设备带宽总和1. 内网满带宽2. 外网依赖部署服务器带宽WebDav✘✘✔︎选择同步✘✔︎（高级版）✘文件加密✘✔︎（加密文件夹）✔︎（需设置）同步加密✔︎✔︎✔︎（需启用https）部署难度低低高文件分享✔︎（只能整库分享）✔︎（只能整库分享）✔︎权限管理✔︎✔︎✔︎2.1 网络问题这里重点讨论一下主要影响大家使用的网络问题。2.1.1 Syncthing 的同步速度为什么那么慢？先说结论，原因是由于对 Syncthing 开放且距离你最近的 中继服务器 过少并且速度较慢导致的。PS: https://relays.syncthing.net/ 这里可以看到开放的 中继服务器 列表。（个人使用的中继服务器可以不开放）最开始用的时候，我并没有觉得这个问题影响使用，因为数据量不大（都是配置文件），也就没有在意。自从 Resilio Sync 因为众所周知的问题挂了以后，我把大量同步任务也迁移到了 Syncthing，其中就包括了 虚拟机、多媒体文件、下载的系统文件、备份文件 等大文件数据。但这就要了命了，几十 kb 的速度同步至少按周来算，而且是不关机的那种。这时候，我就想了 2 个办法先缓缓。通过复制/同步到目标机器的方式，把所有文件传输过去。（这种方式不治本，因为虚拟机变化产生的文件很大，如果不经常变动，你可以采用此方法。）修改 文件拉取顺序 为 小文件优先。在文件夹 选项->高级->文件拉取顺序 中修改。——————– （想治本的同学看这里）我是善良友好的分割线 ——————–当然以上方法都是不解决根本问题的。真正解决问题的办法是，自建中继服务器（划重点）。如何构建 Syncthing Relay Server。（官方英文文档）如何设置 Relaying。（官方英文文档）我在测试过的的docker镜像 t4skforce/syncthing-relay。（构建源码可参考）碍于篇幅，这里不能教大家如何去部署。先提供一些资料给大家参考。 : )2.1.2 Resilio Sync 为什么无法找到设备？先说结论，原因是 Resilio Sync 的 trackers and relays 服务器无法访问。解决办法也很简单，让无法访问的地址走代理就可以了。获取配置文件 https://config.resilio.com/sync.conf参考图：碍于篇幅，细节就略略略了。 : )Nextcloud 为什么无法访问应用页面下载应用？先说结论，原因是因为应用商店无法访问。你可以自行去 GitHub 下载 App 项目。并解压到 NEXTCLOUD-PATH/apps 目录下，按照项目教程进行部署。解决部署服务器无法访问 Nextcloud App Servier 无法访问的问题。碍于篇幅，略略略。 : )2.2 版本控制既然和数据有关，那最害怕的是什么？那当然就是数据 同步异常、数据丢失、数据误删、意外导致数据丢失 等数据消失不见的严重问题了。——————– （结论看这里）我是善良友好的分割线 ——————–这里不讲如何保障数据，直接说结论：以上软件所提供的版本控制，都无法完全保证数据同步过程中不丢失。所以不要认为有了版本控制，数据就可以随意处理了。有时候你想找回某个数据还真不一定找得到。（自行搭配快照、副本、备份。）——————– （评测看这里）我是善良友好的分割线 ——————–Syncthing 提供的 版本控制 非常多，可以适应多种场景下使用。其中 阶段版本控制 提供了 小时 级别的历史记录，最大程度的保障数据安全，并且提供了历史记录查看器，可以很方便的查看历史记录，并恢复。基本上，它可以适应所有个人同步需求，并且同步过程中对数据也相对安全。参考图：Resilio Sync 并不提供版本控制功能，只有最简单的回收站机制。甚至你也不清楚有没有放入回收站。所以它只适合 分享型、大文件型、变动少、文件相对而言不那么重要、目录层次少结构不复杂 等使用环境。我基本上，都是用来放大文件和多媒体文件。Nextcloud 提供文件变化版本控制，但仅限于使用其客户端的方式。通过 WebDav 等访问的方式，是 没有版本控制 的，由于其使用数据库来记录所有文件，所以文件数量和结构，考验着你的数据库服务器。并且其 http 传输原理导致默认对 文件大小 有所限制。当然以上问题，都能通过其他方法来解决，但是我仍然 不推荐用来作为主要的同步服务。但是其丰富的拓展性，以及详尽的文件记录，非常适合 分享 和 多人协作，适合对外提供服务，可以弥补 Syncthing 这类个人同步服务的短板，也就是协作和分享。3. 结语这 3 款开源同步服务，在同步速度上，都是可以满速运行的，同步速度上体验没多大区别。但是由于各自服务的机制不同，需要一定动手能力，才能达到最佳效果。以上只是对这 3 款开源服务的一些细节做了一些对比。如果大家有比较关心的其他细节，再做补充。Bye. : ) ...

本文由云+社区发表作者：腾讯云数据库Introduction 导言任何看到显著增长的应用程序或网站，最终都需要进行扩展，以适应流量的增加。以确保数据安全性和完整性的方式进行扩展，对于数据驱动的应用程序和网站来说十分重要。人们可能很难预测某个网站或应用程序的流行程度，也很难预测这种流行程度会持续多久，这就是为什么有些机构选择“可动态扩展的”数据库架构的原因。在这篇概念性文章中，我们将讨论一种“可动态扩展的”数据库架构：分片数据库。近年来，分片（Sharding）一直受到很多关注，但许多人并没有清楚地了解它是什么，或者对数据库进行分片可能有意义的场景。我们将讨论分片是什么，它的一些主要优点和缺点，以及一些常见的分片方法。下方是本文目录，帮助您接下来的阅读What is Sharding? 什么是分片？分片（Sharding）是一种与水平切分（horizontal partitioning）相关的数据库架构模式——将一个表里面的行，分成多个不同的表的做法（称为分区）。每个区都具有相同的模式和列，但每个表有完全不同的行。同样，每个分区中保存的数据都是唯一的，并且与其他分区中保存的数据无关。从水平切分（horizontal partitioning）与垂直切分（vertical partitioning）的关系，可能会有所帮助。在垂直切分表中，所有的列被分离出来，并放入新的不同的表中。每个垂直切分内的数据，独立于所有其他分区中的数据，并且每个分区都包含不同的行和列。下图说明了如何在水平和垂直方向上对表进行分区：添加描述分片（Sharding）将一个数据分成两个或多个较小的块，称为逻辑分片（logical shards）。然后，逻辑分片（logical shards）分布在单独的数据库节点上，称为物理分片（physical shards）。物理分片（physical shards）可以容纳多个逻辑分片（logical shards）。尽管如此，所有分片中保存的数据，共同代表整个逻辑数据集。数据库分片（Database shards）是无共享架构的一个例子。这意味着分片是自治的：分片间不共享任何相同的数据或服务器资源。但是在某些情况下，将某些表复制到每个分片中作为参考表是有意义的。例如，假设某个应用程序的数据库依赖于重量测量的固定转换率。通过将包含必要转换率数据的表复制到每个分片中，有助于确保查询所需的所有数据都保存在每个分片中。通常，分片（Sharding）在应用程序级别进行实现。这意味着应用程序包含“要向哪个分片发送读和写”的代码。但是，某些数据库管理系统内置了分片功能，允许您直接在数据库级别实现分片。以上是分片（Sharding）的概述，接下来让我们来看一下，这种数据库架构的优点和缺点。Benefits of Sharding 分片的好处数据库分片的主要吸引力在于，它可以帮助促进水平扩展（horizontal scaling），也称为向外扩展（scaling out）。水平扩展是将更多的机器添加到现有堆栈中，以分散负载，允许更多的流量和更快的处理。这通常与垂直扩展（vertical scaling）形成对比，垂直扩展也称为向上扩展（scaling up），是指升级现有服务器的硬件，通常是添加更多内存或CPU。让一个关系数据库在单个机器上运行，并按需升级其服务器资源进行向上扩展是相对简单的。但最终，任何非分布式数据库在存储和计算能力方面都会受到限制，因此可以自由地水平扩展数据库，会使您的架构更加灵活且适应性强。选择分片数据库架构的另一个原因，是为了加速查询响应的时间。当您对尚未分片的数据库提交查询时，必须先搜索您查询的表中的每一行，然后才能找到您要查找的结果集。对于具有大型单片数据库的应用程序，查询可能变得极其缓慢。但是，通过将一个表分成多个，查询过程会遍历更少的行，并且返回结果集的速度要快得多。分片还可以通过减少宕机（outage）的影响，使应用程序更稳定可靠。如果您的应用程序或网站依赖于未分片的数据库，则宕机可能会导致整个应用程序不可用。但是，对于分片数据库，宕机可能只会影响单个分片。即使这可能使某些用户无法使用应用程序或网站部分功能，但仍会低于整个数据库崩溃带来的影响。Drawbacks of Sharding 分片的缺点虽然对数据库进行分片可以使扩展更容易并提高性能，但它也可能会带来某些限制。在这里，我们将讨论其中的一些限制，以及为什么这些限制会让我们避免对数据库全部分片。正确实现分片数据库架构，是十分复杂的，所以这是分片遇到的第一个困难。如果操作不正确，则分片过程可能会导致数据丢失或表损坏，这是一个很大的风险。但是，即使正确地进行了分片，也可能对团队的工作流程产生重大影响。与从单个入口点访问和管理数据不同，用户必须跨多个分片位置管理数据，这可能会让某些团队存在工作混乱。在对数据库进行分片后，用户有时会遇到的一个问题是分片最终会变得不平衡。举例来说，假设您有一个数据库，其中有两个单独的分片，一个用于姓氏以字母A到M开头的客户，另一个用于名字以字母N到Z开头的客户。但是，您的应用程序为姓氏以字母G开头的人提供了过多的服务。因此，A-M分片逐渐累积的数据比N-Z分片要多，这会导致应用程序速度变慢，并对很大一部分用户造成影响。A-M分片已成为所谓的数据热点。在这种情况下，数据库分片的任何好处都被慢速和崩溃抵消了。数据库可能需要修复和重新分片，才能实现更均匀的数据分布。另一个主要缺点是，一旦对数据库进行了分片，就很难将其恢复到未分片的架构。分片前数据库的备份数据，都无法与分片后写入的数据合并。因此，重建原始的非分片架构，需要将新的分区数据与旧备份合并，或者将分区的数据库转换回单个数据库，这两种方法都是昂贵且耗时的。要考虑的最后一个缺点是，并不是每个数据库引擎本身都支持分片。例如，尽管可以手动分片PostgreSQL数据库，但PostgreSQL本身并不包括自动分片功能。有许多Postgres分支包括自动分片功能，但这些分支通常落后于最新的PostgreSQL版本，并且缺乏某些其他的功能特性。一些专业的数据库技术——如MySQL Cluster或某些数据库即服务产品（如MongoDB Atlas）确实包含自动分片功能，但这些数据库管理系统的普通版本却并不包含。因此，分片通常需要“自己动手”的方法。这意味着通常很难找到有关分片或故障排除技巧的文档。现在我们已经介绍了一些分片的缺点和好处，我们将讨论一些分片数据库的不同架构。一旦你决定对数据库进行分片，接下来你需要弄清楚的是如何进行分片。在运行查询或将传入的数据分发到分片表或数据库时，关键是要将其分配到正确的分片。否则，它可能导致数据丢失或查询速度缓慢。在本节中，我们将介绍一些常见的分片架构，每个架构使用稍微不同的流程来跨分片分发数据。Key Based Sharding 基于键的分片添加描述为了确保数据记录以正确的方式被放置在正确的分片中，哈希函数中输入的值都应该来自同一列。此列称为分片键。简单来说，分片键与主键类似，因为它们都是列，用于为各个行建立唯一标识符。一般来说，分片键应该是静态的，这意味着它不应包含可能随时间变化的值。否则，它会增加更新操作的工作量，并可能降低性能。虽然基于键的分片是一种相当常见的分片架构，但在尝试动态添加或删除数据库中的其他服务器时，它会使事情变得棘手。在添加服务器时，每个服务器都需要一个相应的哈希值，并且许多现有条目（如果不是全部）都需要重新映射到新的正确哈希值，然后迁移到相应的服务器。当您开始重新平衡数据时，新旧哈希函数都不会有效。因此，在迁移期间，您的服务器将无法编写任何新数据，您的应用程序可能会停机。这种策略的主要吸引力在于，它可以用于均匀分布数据，从而防止热点。此外，由于它以算法方式分配数据，因此无需维护所有数据所在位置的映射，而其他策略（如范围或基于目录的分片）必须维护数据位置的映射。Range Based Sharding 基于范围的分片基于范围的分片（Range based sharding），基于给定值的范围进行数据分片。为了说明，假设您有一个数据库，用于存储零售商目录中所有产品的信息。您可以创建一些不同的分片，并根据每个产品的价格范围分配每个产品的信息，如下所示：添加描述基于范围的分片的主要好处是，它实现起来相对简单。每个分片都包含一组不同的数据，但它们都具有相同的模式，以及原始数据库。应用程序代码只读取数据所属的范围，并将其写入相应的分片。另一方面，基于范围的分片并不能预防数据不均匀分布的现象，而有可能会出现前面提到的数据热点现象。查看示例图，即使每个分片拥有相同数量的数据，特定产品比其他产品获得更多关注的可能性也会很大。相应的，各个的分片将接收不成比例的读取操作。Directory Based Sharding 基于目录的分片要实现基于目录的分片，必须创建并维护一个查找表，该查找表使用分片键来跟踪哪个分片包含哪些数据。简而言之，查找表是一个表，其中包含有关可以找到特定数据的静态信息集。下图显示了基于目录的分片的简单示例：添加描述此处，Delivery Zone列被定义为分片键。将来自分片键的数据，连同每一行应该写入的分片写入查找表。这与基于范围的分片类似，但不是确定分片键的数据落入哪个范围，而是将每个键绑定到其自己的特定分片。如果分片键的基数很低，并且分片键存储键的范围没有意义，那么基于目录的分片比基于范围的分片要更好。请注意，它也不同于基于密钥的分片，因为它不通过散列函数处理分片键; 它只是根据查找表检查键值，以查看数据需要写入的位置。基于目录的分片的主要吸引力在于其灵活性。基于范围的分片架构只能指定键值范围，而基于键的分片架构只能使用固定的哈希函数，如前所述，在以后更改该函数非常困难。另一方面，基于目录的分片允许您使用任何系统或算法将数据项分配给分片，使用这种方法动态添加分片也相对容易。虽然基于目录的分片是这里讨论的最灵活的分片方法，但是在每次查询或写入之前连接到查找表，可能会对应用程序的性能产生不利影响。此外，查找表可能出现单点故障：如果查询表损坏或出现其他故障，它可能会影响数据库写入新数据或访问现有数据的能力。Should I Shard? 我应该分片吗？是否应该实现分片数据库架构，几乎总是一个争论的问题。有些人认为分片对于达到一定规模的数据库来说，是不可避免的结果。而另一些人则认为这是一个令人头疼的问题，除非绝对必要，否则应该避免，因为分片增加了操作的复杂性。由于这种增加的复杂性，通常仅在处理非常大量的数据时才执行分片。以下是一些常见方案，可能对数据库分片的操作有所帮助：· 应用程序数据量增长到超过单个数据库节点的存储容量。· 对数据库的读写量，超过单个节点或其只读副本可以处理的量，从而导致响应时间增加或超时。· 应用程序所需的网络带宽，超过单个数据库节点和任何只读副本可用的带宽，从而导致响应时间增加或超时。在分片之前，您应该用尽所有其他选项来优化数据库。您可能需要考虑的一些优化包括：设置远程数据库。如果您使用的是一个整体应用程序，其中所有组件都位于同一个服务器上，那么可以通过将数据库移到它自己的机器上来提高数据库的性能。由于数据库的表保持不变，因此这不会增加分片的复杂性。但是，它仍然允许您垂直伸缩数据库，使其与基础结构的其他部分分离。实现缓存。如果您的应用程序的读取性能导致您遇到麻烦，那么缓存是一种可以帮助改进它的策略。缓存涉及临时存储已在内存中请求的数据，以便您以后更快地访问它。创建一个或多个只读副本。另一种有助于提高读取性能的策略，包括将数据从一个数据库服务器（主服务器）复制到一个或多个从服务器。在此之后，每次新的写操作在复制到从服务器之前都要先到主服务器，而读操作只对从服务器进行。像这样分发读写可以防止任何一台机器承担过多的负载，从而有助于防止速度下降和崩溃。请注意，创建读副本需要更多的服务器资源，因此花费更多的钱，这对一些人来说可能是一个很大的限制。升级到更大的服务器。在大多数情况下，将一个数据库服务器扩展到具有更多资源的计算机比分片需要更少的工作量。与创建只读副本一样，具有更多资源的服务器升级可能会花费更多的钱。因此，只有当它确实是您的最佳选择时，您才应该进行服务器扩容。请记住，如果您的应用程序或网站增长超过某个点，这些策略本身都不足以提高性能。在这种情况下，分片可能确实是您的最佳选择。Conclusion 结语对于那些希望横向扩展数据库的人来说，分片是一个很好的解决方案。但是，它还会增加很多复杂性，并为您的应用程序创建更多潜在的故障点。分片对于某些人来说可能是必要的，但是创建和维护分片架构所需的时间和资源可能会超过对其他人的好处。通过阅读这篇概念性文章，您应该更清楚地了解分片的优缺点。接下来，您可以使用这些见解来对分片数据库架构是否适合您，做出更明智的决定。版权声明：本文由腾讯云数据库产品团队整理，页面原始内容来自于db weekly英文官网，若转载请注明出处。翻译目的在于传递更多全球最新数据库领域相关信息，并不意味着腾讯云数据库产品团队赞同其观点或证实其内容的真实性。如果其他媒体、网站或其他任何形式的法律实体和个人使用，必须经过著作权人合法书面授权并自负全部法律责任。不得擅自使用腾讯云数据库团队的名义进行转载，或盗用腾讯云数据库团队名义发布信息。此文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号

Data Lake Analytics 作为云上数据处理的枢纽，最近加入了对于Redis 的支持, 这篇教程带你玩转 DLA 的 Redis 支持。创建数据库在 DLA 里面创建一个底层映射到 Redis 的数据库的语法如下:CREATE DATABASE redis_testWITH DBPROPERTIES (catalog = ‘redis’,location = ‘r-xxxxx.redis.rds.aliyuncs.com:6379/hello_’,password = ‘xxxxx’,vpc_id = ‘vpc-xxxxx’,instance_id = ‘r-xxxxxx’)这里要特别说明一下这个 location 属性，前面 r-xxxxx.redis.rds.aliyuncs.com:6379 是redis服务器的域名和端口，最后的 hello_ 是一个前缀，具体的用途后面再细说，redis服务的域名和端口你可以从阿里云控制直接查询到:跟普通的建库语法不同的是这里多了两个属性: VPC_ID 和 INSTANCE_ID , 这是因为现在用户的 Redis 数据库都是处于用户自己的VPC内部，默认情况下 DLA 是访问不了用户 VPC 里面的资源的，为了让DLA能够访问到用户RDS里面的数据，我们需要利用阿里云的VPC反向访问技术。权限声明: 当您通过上述方式建库，就视为您同意我们利用VPC反向访问的技术去读写您的 Redis 。另外您还需要把 100.104.0.0/16 加入你的 Redis 的白名单列表，这是我们VPC反向访问的IP地段，如下图:创建表数据库建完之后，我们可以建表了，我们先在你的 Redis 里初始化一些数据用来测试, 因为Redis是没有schema信息的，我们必须往里面插入数据才能生效，所以我们插入一些测试数据:CSV格式的数据set hello_world_1 1,james,10set hello_world_2 2,bond,20set hello_world_3 3,lily,30set hello_world_4 4,lucy,20JSON格式的数据set hello_foo_1 ‘{“id”:1,“name”:“james”,“age”:110}‘set hello_foo_2 ‘{“id”: 2, “name”: “bond”, “age”: 210}‘set hello_foo_3 ‘{“id”: 3, “name”: “lily”, “age”: 310}‘set hello_foo_4 ‘{“id”: 3, “name”: “lucy”, “age”: 210}‘我们插入了两种格式的数据，一种是CSV格式的，一种是JSON格式的，这是我们目前支持的两种格式，后面会分别演示。然后就可以在 DLA 的数据库里面建立相应的映射表了:CREATE EXTERNAL TABLE dla_person (id int,name varchar,age int) TBLPROPERTIES (COLUMN_MAPPING = ‘id,2;name,1;age,0’,TABLE_MAPPING = ‘world_’,format = ‘csv’);这里几个字段详细说明一下:TABLE_MAPPING 让我们可以让DLA层面的表名映射到底层Redis里面指定模式的的一组key。回忆一下我们前面在建库的时候指过前缀 hello_ , 再与这里的 world_ 相结合，表达的意思就是:表 dla_person 里面的数据映射到Redis数据库里面所有key的前缀为 hello_world_ 的数据。这里，你也可以省略这个设置，默认的前缀跟表名一致，在上面的例子里面省略 TABLE_MAPPING, 那么最终查询的key的前缀为 hello_dla_person。下一个我们关注一下参数 format, 这里指定Redis里面数据的格式，目前支持: csv, json 两种格式。COLUMN_MAPPING 的作用是把DLA层面的列映射到底层的数据上，由于Redis底层没有column的概念，因此具体映射的方法根据 format 的不同而不同, 比如这里的 CSV, 我们知道CSV的数据被解析之后会形成一个string数组，对应的column_mapping就映射到底层这个数组的index(下标)。比如这里把 id 映射到下标 2, 把 name 映射到下标 1 等等。column_mapping 也可以不设置，对于CSV格式来说会按照column声明的顺序依次映射到0, 1, 2等等。这样我们就可以通过MySQL客户端连接到 DLA 数据库上面，就可以对 Redis 数据库里面的数据进行查询了:mysql> select * from dla_person;nameidagebond202lily303lucy204james1014 rows in set (0.18 sec)熟悉SQL的同学一定觉得很爽吧，可以去熟悉的SQL语法去操作 Redis 数据库了。JSON上面演示的是CSV格式的数据，下面我们再来试试JSON格式的数据，我们再来创建一个新表:CREATE EXTERNAL TABLE dla_person_json (id int,name varchar,age int) TBLPROPERTIES (COLUMN_MAPPING = ‘id,age;name,name;age,id’,TABLE_MAPPING = ‘foo_’,format = ‘json’);注意这里我们指定了 TABLE_MAPPING 为 foo_，结合数据库的前缀 hello_, 因此它最终查询的是Redis里面所有前缀为 hello_foo_ 的数据; 另外这里还指定了 COLUMN_MAPPING, 因为JSON数据里面是有字段名字的，因此DLA的层面的column的名字是映射到JSON数据里面字段的名字的，这里为了演示的需要故意把DLA的 id column映射到了 Redis的 age, 我们来查询看看结果:mysql> select * from dla_person_json;nameidagelucy2103james1101bond2102lily31034 rows in set (0.12 sec)如我们所愿，id column显示的是Redis里面对应的 age 字段的值。总结我们今天介绍了DLA对于Redis的支持，目前DLA支持的数据源已经包括: OSS, OTS, RDS(MySQL, SQLServer, Postgres), MongoDB, Redis等等 数据可以在这些数据源之间进行联合JOIN、流转本文作者：xumingmingv阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

在Data Lake Analytics中使用视图概述在Data Lake Analytics（以下简称DLA）中使用视图（VIEW）功能，可以大大简化对于重复SQL，特别是较为复杂的SQL语句的编写和维护。目前DLA中还不支持SQL视图的物化。在使用DLA进行跨多个数据源的联合分析场景中，使用视图，尤其能够方便后续对于包含重复SQL片段的SQL查询语句的编写和维护。在介绍视图的功能之前，需要注意两个概念：1）在DLA中，每个SCHEMA（https://help.aliyun.com/docum…）下的表必须属于同一类数据源（通过CATALOG属性指定），也必须属于同一个LOCATION约束的数据源。对于OSS，SCHEMA中LOCATION指向一个目录，后续在该SCHEMA下的表所指向的LOCATION必须从属于该SCHEMA的LOCATION目录；对于其他实例型数据源（比如Table Store、RDS等），SCHEMA中LOCATION指向一个实例URL，后续在该SCHEMA下的表必须也属于该实例。2）和表类似，视图必须属于一个SCHEMA，在SQL中引用视图时，可以通过“schema_name.view_name”来进行引用，如果当前数据库连接的schema是视图所属的SCHEMA时，在SQL中可以直接用视图名进行引用。创建视图语法：CREATE [OR REPLACE]VIEW view_name [(column_list)]AS select_statement例如：CREATE OR REPLACEVIEW basic_test.test_view_1_ossASSELECT *FROM nationORDER BY n_nationkey通过CREATE语句创建视图。如果指定名称的视图之前在系统中已经存在，则会报错提示视图已经存在。通过CREATE OR REPLACE方式，如果指定名称的视图之前在系统中已经存在，则会进行更新，用新的视图定义替换之前的视图定义。查询视图元数据视图元数据相关信息查询的方式有很多种，下面一一列举：查询视图的创建语句：语法：SHOW CREATE (TABLE | VIEW) view_name例如：SHOW CREATE VIEW basic_test.test_view_1_oss;ViewCreate Viewcharacter_set_clientcollation_connectiontest_view_1_ossCREATE VIEW basic_test.test_view_1_oss AS SELECT *FROM nationORDER BY n_nationkeyutf8utf8_general_ci 查询information_schema.views元数据：SELECT * FROM information_schema.views WHERE table_schema = ‘basic_test’;TABLE_CATALOGTABLE_SCHEMATABLE_NAMEVIEW_DEFINITIONCHECK_OPTIONIS_UPDATABLEDEFINERSECURITY_TYPECHARACTER_SET_CLIENTCOLLATION_CONNECTIONdefbasic_testtest_view_1_ossSELECT *FROM nationORDER BY n_nationkey | NONE | YES | mysql.sys@localhost | INVOKER | utf8 | utf8_general_ci || def | basic_test | test_view_2_oss | SELECT *FROM nationNONEYESmysql.sys@localhostINVOKERutf8utf8_general_ci 目前，DLA中不保存视图定义的详细列定义元数据信息。嵌套视图DLA支持视图的嵌套，即VIEW 1定义指向VIEW 2，VIEW 2定义指向VIEW 3。例如：CREATE OR REPLACE VIEW view_1 (col1, col2, col3) ASSELECT *FROM tpch_test.nationORDER BY n_nationkey;CREATE OR REPLACE VIEW view_2 (col_1, col_2) ASSELECT col1, col2 FROM view_1 a;注意：在定义VIEW时，VIEW中指向的SQL语句中，建议对引用的table都加上所属的schema名，特别是在跨schema的场景下（schema1中的定义view，指向的SQL语句中目标表有其他schema的table或view）。删除视图语法：DROP VIEW [IF EXISTS] view_name本文作者：julian.zhou阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

概述C1FlexGrid提供了创建轮廓树的功能，其中可以显示缩进结构，每个节点行旁边都有折叠/展开图标。 然后，用户可以展开和折叠轮廓以查看所需的细节级别。 为此，C1FlexGrid允许您使用其Tree属性和Subtotal方法。现在，如果有任何关于：如何将网格绑定到分层数据源并在子网格中显示细节的想法，ComponentOne已经提供了一个“DataTree”演示，用来实现相同的效果。这个Demo默认存放在这个位置中：Documents ComponentOne Samples WinForms C1FlexGrid CS DataTree。这是通过从C1FlexGrid控件派生控件（C1FlexDataTree）来实现的。 绑定时，控件会检测从属数据源并创建其附加实例以显示子表。但是，如果需要在此分层显示中设置RightToLeft布局，则需要通过代码处理此问题。以下就是具体实现步骤：实现从右到左的布局本文将介绍通过代码处理这些子网格的呈现来实现从右到左布局的步骤。 按照下面提到的两个步骤这将很容易实现：首先，我们将父网格的RightToLeft属性设置为RightToLeft.Yes值。this._flex.RightToLeft = System.Windows.Forms.RightToLeft.Yes;接下来，在C1FlexDataTree.cs的UpdatePosition方法中，子位置和客户端大小计算如下：rc.X = rc.Left - parent.ScrollableRectangle.Width;rc.Y = rc.Bottom;rc.Width = Cols[Cols.Count - 1].Left;rc.Width = Math.Max(Cols[Cols.Count - 1].Left, parent.ScrollableRectangle.Width);点击此处，下载示例DemoComponentOne Enterprise | 下载试用ComponentOne是一款专注于企业应用高性能开发的 .NET 全功能控件套包，包含300余种控件，支持7大平台，涵盖7大功能模块。较于市面上其他同类产品，ComponentOne更加轻盈，功能更加强大，20多年的开发经验，将为您的应用系统带来更为安全的使用体验。纯中文操作界面，一对一技术支持，厂商级的技术服务，共同造就了这款国际顶级控件套包。您对ComponentOne 产品的任何技术问题，都有技术支持工程师提供1对1专业解答，点击此处即可发帖提问>> 技术支持论坛

Characters_of_the_Three_Kingdoms - 三国人物结构化数据三国人物结构化数据为什么会有这个项目需求1：摆脱网上那些长篇累牍的文章；需求2：只是想简单查看下人物姓甚名谁、生辰八字、家住何地、三姑六婆；需求3：只是想简单查看下人物的历史简介、演义简介；需求4：只是想简单查看下人物的历史评价；需求5：只是想简单查看下人物的…需求6：想集中查看多个人物的资料；需求7：想获取完整而不累赘的结构化数据，自己开发应用尽情发挥；…需求N：…有了数据能干嘛有了数据，除了不能上天入地，剩下的就看少年你自己的活泼思想了。数据来源数据主要整理自 维基百科 、百度百科 和其他网络资源。数据展示 DEMO所有已经完成的人物数据可查看数据展示 DEMO。DEMO 页面使用 ajax 获取 characters 文件夹的 json 文件，若要本地运行 DEMO 页面，需本地启动 server。将项目 clone 到本地后，执行：npm run start或gulp然后浏览器打开 localhost:4300 即可。数据示例{ // 姓名 “name”: “刘备”, // 字 “courtesyName”: “玄德”, // 号 “pseudonym”: null, // 其他称谓 “aliase”: [ { “name”: “汉先主”, “desc”: null }, { “name”: “先主”, “desc”: “三国志、华阳国志等称为先主” }, { “name”: “汉主”, “desc”: “资治通鉴称刘备父子为汉主” } ], // 乳名、小名、小字 “infantName”: null, // 性别：1 男，2 女 “gender”: 1, // 头像 “avatar”: “./images/avatars/刘备.jpg”, // 所属势力 “faction”: “蜀汉”, // 出生日期 “birthdate”: “161年”, // 出生地点：古时地名 “birthplace”: “幽州涿郡涿县”, // 出生地点：现在地名 “birthplacePresentDay”: “河北省涿州市”, // 逝世日期 “deathdate”: “223年6月10日”, // 逝世地点：古时地名 “deathplace”: “白帝城永安宫”, // 逝世地点：现在地名 “deathplacePresentDay”: “重庆市奉节县”, // 在位时期 “tenure”: “汉中王：219年-221年；蜀主：221年5月15日-223年6月10日”, // 职位 “position”: [“蜀国皇帝”], // 封爵 “peerage”: null, // 封地 “enfeoffment”: null, // 侍奉的帝王 “monarch”: null, // 谥号 “posthumousName”: [“昭烈皇帝”], // 庙号 “templeName”: [“烈祖”], // 世系、氏族 “genealogy”: null, // 历史上的简介 “historicalBriefIIntroduction”: “蜀汉的开国皇帝，相传是汉景帝之子中山靖王刘胜的后代…”, // 演义上的简介 “novelisticBriefIIntroduction”: “刘备，蜀汉的开国皇帝，汉景帝之子中山靖王刘胜的后代…”, // 家庭成员 // 若名不详，则 name 字段为 名不详 “family”: { “father”: { “character”: [ { “name”: “刘弘”, “desc”: “东汉末年的州郡小官” } ], “desc”: null }, “mother”: { “character”: [ { “name”: “名不详”, “desc”: null } ], “desc”: null }, “brothers”: null, “sisters”: null, “spouse”: { “character”: [ { “name”: “甘夫人”, “desc”: “沛人，妾室，刘禅生母，曾于长阪被困，幸得赵云解救。后病死，谥皇思夫人，后再追谥昭烈皇后，与刘备合葬。” }, { “name”: “糜夫人”, “desc”: “麋竺之妹，于刘备在豫州落难时，麋竺将她嫁给刘备。” }, { “name”: “孙夫人”, “desc”: “孙权之妹，与刘备结为政治婚姻，后刘备入蜀，孙权接回她，再无记录。” }, { “name”: “穆皇后”, “desc”: “吴氏，吴懿之妹，刘瑁遗孀，刘备入蜀后纳为夫人，后为汉中王后。刘禅即位时，尊她为皇太后，称长乐宫。延熙八年病死，与刘备合葬。” } ], “desc”: “甘夫人被刘备纳为妾室时，因他“数丧嫡室”，而主内事。数位嫡室的身份已不可考。仅知建安元年（196年），吕布曾俘虏刘备的妻儿[32]，转至广陵郡海西县时，又娶了麋夫人。次子刘永和三子刘理各自的生母亦不可考，仅知非正室且非同一人。” }, “sons”: { “character”: [ { “name”: “刘禅”, “desc”: “字公嗣，刘备长子。后登上皇位。乳名阿斗。” }, { “name”: “刘永”, “desc”: “字公寿，刘备次子。先为鲁王，后封为甘陵王。与刘禅宠臣黄皓不和，被刘禅疏远。后东迁洛阳，拜奉车都尉，封为乡侯。” }, { “name”: “刘理”, “desc”: “字奉孝，刘备三子。先为梁王，后封为安平王。早卒，谥为悼王。” }, { “name”: “刘封”, “desc”: “刘备养子。本姓寇，刘备入蜀后委任为将，但因关羽兵败时不予救援及逼反孟达丧失上庸之责遭赐死。” } ], “desc”: null }, “daughters”: { “character”: [ { “name”: “名不详”, “desc”: null }, { “name”: “名不详”, “desc”: null } ], “desc”: “有二女于刘备南逃至长坂时被曹将曹纯所俘。” } }, // 历史评价 “historicalEvaluations”: [ “刘元起：“吾宗中有此儿，非常人也。”（《三国志·蜀书·先主传第二》）”, “陈登：“雄姿杰出，有王霸之略，吾敬刘玄德。”（《三国志·魏书·桓二陈徐卫卢传第二十二》）”, “袁绍：“刘玄德弘雅有信义，今徐州乐戴之，诚副所望也。”（《三国志·蜀书·先主传第二》）” ]}已经完成的人物数据所有已经完成的人物数据可查看 DEMO。刘备 诸葛亮 曹操 孙权 张让 张角 张宝 张梁 张飞 张钧 张举 张纯 张济 张辽 张郃 张邈 张超 张杨 张虎 张统 张闿 张燕 张昭 张纮 张英 张勋 张绣 张鲁 张道陵 张衡 张???? 张南 张南 张武 张温 张温 张允 张横 张既 张卫 张松 张任 张肃 张翼 张著 张音 张爽 张裔 张达 张苞 张嶷 张休 张茂 张当 张特 张约 张缉 意见建议所有数据整理自网络，且鄙人才疏学浅，一定会有疏忽错误，欢迎指正。如果你有好的建议或意见，欢迎提 issue 反馈。联系方式Email: 851399101@qq.comLicenseMITCopyright (c) 2018-present, myvin ...