数据库

导读：9 月 25 日，2023 飞轮科技产品发布会在线上正式召开，本次产品发布会以 “新内核、新图景” 为主题，飞轮科技 CEO 马如悦全面解析了现代化数据仓库的演进趋势，发表立足于多云之上的 SelectDB Cloud 云服务全面凋谢，减少了全新的公有仓库（BYOC）产品模式，同时公布了更加自主可控的 SelectDB Enterprise 企业版。飞轮科技联结创始人兼 COO 连林江介绍了基于 SelectDB 的多个场景解决方案以及生态单干模式，来自同盾科技、趣丸科技以及观测云的多位客户代表为大家分享了基于 SelectDB 的架构降级在实在业务场景中带来的收益，将来飞轮科技将保持以“客户价值”为出发点引领技术革新、以“凋谢共赢”为核心理念携手更多合作伙伴，为行业注入新的生机。以下内容依据飞轮科技 CEO 马如悦演讲内容整顿： 收费试用 SelectDB Cloud：https://cn.selectdb.cloud/ 间隔上一次产品发布会曾经有近一年的工夫，在这一年的工夫里，咱们对于技术趋势、对于客户服务、对于市场需求都有了更加深度的思考，因此咱们的外围产品 SelectDB 也有了更加长足的提高，因而很快乐能够给大家分享这一年咱们所获得的成绩——这就是咱们明天发布会的主题 “新内核、新图景” ，新内核指的是 SelectDB 产品内核将全面采纳最新公布的 Apache Doris 2.0 版本，新图景指的是新的产品定位与产品状态，接下来将为大家一一论述。 数据仓库的现代化趋势纵观数据仓库的倒退历程，数据仓库的演进经验了三个阶段，第一阶段即在 2010 年之前，以 Teradata、Greenplum、IBM Netezza 为代表的传统数据仓库占据支流。 2010 年前后，随着谷歌三驾马车的问世，基于 Hadoop 的大数据平台成为大数据分析的基座，成为第二阶段的事实标准。现在曾经进入第三阶段，现代化的数据仓库产品开始涌现，这些产品兼顾了传统数据仓库的可靠性和性能劣势，以及对大数据的高效解决和实时剖析能力。 总体而言，数据仓库的三大现代化趋势为实时剖析、湖仓交融以及云原生化。 实时剖析：大规模实时数据上的极速查问 随着工夫的推移，数据的利用价值逐渐降落 过来，大多数企业应用的传统数据仓库/大数据平台次要是对历史数据进行批量剖析，如果能对数据进行实时剖析并将剖析后果实时使用到业务之中，毫无疑问将会进一步利用好数据的实时价值并驱动业务提高。因而到现在时代，数据分析逐步从原来的批量解决演变到当初的实时处理。 以业务剖析需要的变动为例，越来越多的企业开始采纳实时报表和实时仪表盘展现数据，取代了传统跑批工作生成的报表。而从批量生成的动态报表到交互式剖析也是另一个典型趋势，过来咱们只须要跑一份动态报表，而现如今当初很多公司外部都有大量的数据分析师，须要与零碎进行疾速互动实时产出剖析后果。此外，数据后果不再仅限于人应用，逐步转向为机器和算法应用的实时决策零碎。这些变动清晰地展示了一个新的趋势：数据从批量解决逐步转向实时剖析已成为必然。 与此同时，过来数据分析系统次要是给外部的经营决策或数据统计来应用，而随着业务的倒退、数字化转型的深入，越来越多的数据分析开始面向业务的内部客户，次要场景包含广告营销报表、物流实时看板、保险客户剖析和交易明细查问等。这些都是数据分析需要由内到外的转换，这种转变也要求咱们的剖析零碎可能适应更多样化的业务场景。 在应答大规模数据的实时剖析时，外围挑战来自两个方面： 随着数据实时写入数据库，咱们面临的挑战之一是如何以更低的提早提供数据。咱们须要升高数据传输和解决的提早，以进步数据的新鲜度，并及时处理最新数据的变动。对于下层数据利用而言，如何提供更快的查问、升高查问耗时。咱们须要继续优化查问性能，进步查问的疾速响应度，以满足下层数据利用的性能需求。 SelectDB 实现了大规模实时数据的极速查问 那么 SelectDB 是如何解决实时剖析的难点呢？一方面是 SelectDB 实现了 大规模数据的实时导入与实时存储： 秒级的数据实时更新（主键表）与追加：SelectDB 实现了实时数据的秒级可见，在主键表和非主键表上实现了高效的实时更新和追加，相比之下，许多传统数据仓库甚至包含当初宽泛应用的 Snowflake 和 Redshift 往往只能反对批量更新、甚至没有主键表的反对，很难实现高频率的实时更新。数据库 CDC / Kafka 流式数据同步：实时数据仓库的上游数据源往往来自 TP 数据库或 Kafka 音讯队列 ，为此 SelectDB 内置了数据库的CDC（变更数据捕捉）性能以及 Kafka 的流式数据同步性能，可能实现秒级的数据同步。毫秒级轻量化表模式批改：不止数据能够实时写入和更新，对于表的模式（Schema）也须要进行疾速变更，以适应当今疾速变动的业务环境。而 SelectDB 可能毫秒级提供 Schema 批改的性能，同时 Schema 批改期间齐全不影响在线业务的运行丰盛的半结构化数据类型反对：随着不同类型的数据一直减少，半结构化数据类型也日益常见。SelectDB 通过引入 Array、Map、JSON 等数据结构，可能高效反对半结构化数据类型的存储和解决需要。在查问方面，SelectDB 实现了多种查问负载上的极速剖析性能 ： ...

BTM 382 Database ManagementAssignment 1Use the database shown in Figure 1 to answer Problems 1-4. For each table, identify the primary key and the foreign key(s). If a table does not have aforeign key, write None.Do the tables exhibit entity integrity? Answer yes or no, and then explain your answer.Do the tables exhibit referential integrity? Answer yes or no, and then explain your answer.Write NA (Not Applicable) if the table does not have a foreign key.Identify all the relationships between the tables and describe their type.BTM 382 Database ManagementUse the database shown in Figure 2 to work Problems 5−7. Note that the database iscomposed of four tables that reflect these relationships: • An EMPLOYEE has only one JOB_CODE, but a JOB_CODE can be held by manyEMPLOYEEs. • An EMPLOYEE can participate in many PLANs, and any PLAN can be assigned to manyEMPLOYEEs.For each table in the database, identify the primary key and the foreign key(s). If a table doesnot have a foreign key, write None.Do the tables exhibit entity integrity? Answer yes or no, and then explain your answer.Do the tables exhibit referential integrity? Answer yes or no, and then explain your answer.Write NA (Not Applicable) if the table does not have a foreign key.BTM 382 Database ManagementUse the database shown in Figure 3 to answer Problems 8-11.Do the tables exhibit entity integrity? Answer yes or no, and then explain your answer.Do the tables exhibit referential integrity? Answer yes or no, and then explain your answer.Write NA (Not Applicable) if the table does not have a foreign key.Identify the TRUCK table’s candidate key(s).For each table, identify a superkey and a secondary key.Use the database shown in Figures 4 & 5 to answer Problems 12−15.ROBCOR is an aircraft charter company that supplies on-demand charter flight services using afleet of four aircraft. Aircrafts are identified by a unique registration number. Therefore, the aircraftregistration number is an appropriate primary key for the AIRCRAFT table.BTM 382 Database ManagementBTM 382 Database ManagementThe nulls in the CHARTER table’s CHAR_COPILOT column indicate that a copilot is not requiredfor some charter trips or for some aircraft. Federal Aviation Administration (FAA) rules requirea copilot on jet aircraft and on aircraft having a gross take-off weight over 12,500 pounds. Noneof the aircraft in the AIRCRAFT table are governed by this requirement; however, some customersmay require the presence of a copilot for insurance reasons. All charter trips are recorded in theCHARTER table.For each table, identify the primary key and foreign key(s) when possible.You want to see data on charters flown by either Robert Williams (employee number105) orElizabeth Travis (employee number 109) as pilot or copilot, but not charters flown by both of them.Complete Problems 13–15 to find this information.Create the table that would result from applying the SELECT and PROJECT relationaloperators to the CHARTER table to return only the CHAR_TRIP, CHAR_PILOT, andCHAR_COPILOT attributes for charters flown by either employee 105 or employee 109 as pilotor copilot.Create the table that would result from applying the SELECT and PROJECT relationaloperators to the CHARTER table to return only the CHAR_TRIP,CHAR_PILOT, andCHAR_COPILOT attributes for charters flown by both employee 105 and employee 109.Create the table that would result from applying a DIFFERENCE relational operator of yourresult from Problem 13 to your result from Problem 14.

IP地址定位是一种广泛应用于网络畛域的技术，它容许咱们确定特定设施或用户在互联网上的地位。这项技术在很多方面都具备重要的特点，本文将深入探讨这些特点。1.全球性笼罩： IP地址定位具备全球性的覆盖范围。无论设施或用户位于世界的哪个角落，只有连贯到互联网，它们都会被调配一个惟一的IP地址。这使得IP地址成为一种弱小的工具，能够追踪和定位寰球范畴内的设施和用户。 精确性不一：只管IP地址定位功能强大，但其精确性因各种因素而不同。在一些状况下，它能够准确到特定城市或甚至街区级别，而在其余状况下，只能确定到国家或地区级别。这一不一致性源于IP地址调配形式和定位技术的限度。隐衷问题：IP地址定位引发了隐衷方面的关切。尽管IP地址自身通常不蕴含个人身份信息，但当与其余数据联合应用时，它可能裸露用户的地位和行为。因而，隐衷爱护是应用IP地址定位技术时必须认真思考的问题。商业和平安利用：IP地址定位在商业和平安畛域有着宽泛的利用。企业能够应用它来剖析客户地位，改良市场营销策略，并提供更好的客户体验。同时，平安机构能够应用IP地址定位来检测和防止网络立功，追踪犯罪分子的地位。服务质量优化：运营商和互联网服务提供商能够应用IP地址定位来优化网络服务质量。通过理解用户地位，他们能够更好地治理网络流量，提供更快的速度和更稳固的连贯，从而进步用户满意度。法律合规性：IP地址定位在法律合规性方面也扮演着重要的角色。法律部门能够利用它来追踪和考察犯罪活动，收集证据并保护社会平安。然而，这也引发了无关个人隐私和监控的答辩。适用性宽泛：IP地址定位不仅限于计算机和挪动设施，还实用于物联网（IoT）设施，这些设施越来越多地连贯到互联网。这使得IP地址定位在智能家居、车辆追踪、物流和衰弱监测等畛域具备宽泛的利用前景。技术不断进步：IP地址定位技术在不断进步中。新的算法和办法不断涌现，以进步定位精确性，并解决隐衷和平安方面的问题。这意味着IP地址定位将在将来持续施展重要作用，并变得更加牢靠和准确。IP地址定位是一项具备全球性影响的技术，它在商业、平安、隐衷和法律方面都具备重要作用。然而，应用它时必须审慎，均衡好精确性和隐衷爱护，以确保其非法和道德的利用。随着技术的不断进步，咱们能够期待IP地址定位在将来施展更大的作用，为咱们的生存带来更多便当和平安。

一、背景在预发环境中，由音讯驱动最终触发执行事务来写库存，然而导致MySQL产生死锁，写库存失败。 com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: rpc error: code = Aborted desc = Deadlock found when trying to get lock; try restarting transaction (errno 1213) (sqlstate 40001) (CallerID: ): Sql: "/* uag::omni_stock_rw;xx.xx.xx.xx:xxxxx;xx.xx.xx.xx:xxxxx;xx.xx.xx.xx:xxxxx;enable */ insert into stock_info(tenant_id, sku_id, store_id, available_num, actual_good_num, order_num, created, modified, SAVE_VERSION, stock_id) values (:vtg1, :vtg2, :_store_id0, :vtg4, :vtg5, :vtg6, now(), now(), :vtg7, :__seq0) /* vtgate:: keyspace_id:e267ed155be60efe */", BindVars: {__seq0: "type:INT64 value:"29332459" "_store_id0: "type:INT64 value:"50650235" "vtg1: "type:INT64 value:"71" "vtg2: "type:INT64 value:"113817631" "vtg3: "type:INT64 value:"50650235" "vtg4: "type:FLOAT64 value:"1000.000" "vtg5: "type:FLOAT64 value:"1000.000" "vtg6: "type:INT64 value:"0" "vtg7: "type:INT64 value:"20937611645" "}初步排查，在同一时刻有两条申请进行写库存的操作。 ...

始终以来，大数据量始终是爆炸性增长，每天几十 TB 的数据增量曾经十分常见，但云存储相对来说还是不便宜的。泛滥云上的大数据用户特地心愿能够非常简单疾速的将文件挪动到更实惠的 S3、OSS 上进行保留，这篇文章就来介绍如何应用 SeaTunnel 来进行到 OSS 的数据同步。 首先简要介绍一下 Apache SeaTunnel，SeaTunnel 专一于数据集成和数据同步，次要解决以下问题： 数据源多样：罕用的数据源有数百种，版本不兼容。随着新技术的呈现，呈现了更多的数据源。用户很难找到可能全面疾速反对这些数据源的工具。简单同步场景：数据同步须要反对离线-全量同步、离线-增量同步、CDC、实时同步、全库同步等多种同步场景。资源需要高：现有的数据集成和数据同步工具往往须要大量的计算资源或 JDBC 连贯资源来实现海量小表的实时同步。这在肯定水平上减轻了企业的累赘。不足品质和监控：数据集成和同步过程常常会失落或反复数据。同步过程不足监控，无奈直观理解工作过程中数据的真实情况SeaTunnel 反对海量数据的高效离线/实时同步, 每天可稳固高效同步数百亿级数据，曾经有 B 站，腾讯云，微博，360，Shopee 等数百家公司生产应用。 上面步入明天的正题，明天具体来说是讲 Apache SeaTunnel 产品与阿里云 OSS 的集成。 在阿里云 OSS 产品界面，开明 Bucket： 上面是 SeaTunnel 的部署, SeaTunnel 反对多种部署形式: 单机，集群，K8s 等形式。因为 SeaTunnel 不依赖 Zookeeper 等第三方组件，所以整体部署非常简单，具体请参考其官网：https://seatunnel.apache.org/docs/2.3.0/start-v2/locally/depl... 接下来是 SeaTunnel 应用过程，应用命令： ./bin/seatunnel.sh -m local -c ./config/localfile-oss.config在 SeaTunnel 中，用户能够通过 config 文件定制本人的数据同步需要，最大限度地施展 SeaTunnel 的后劲。那么接下来就给大家介绍一下如何配置 Config 文件 能够看到，config 文件蕴含几个局部：env、source、transform、sink。不同的模块有不同的性能。理解这些模块后，您将理解 SeaTunnel 的工作原理。 用于增加一些引擎可选参数，无论是哪个引擎（Spark或Flink），这里都要填写相应的可选参数。 source 用于定义 SeaTunnel 须要从哪里获取数据，并将获取的数据用于下一步。能够同时定义多个源。当初反对的起源查看 SeaTunnel 的起源。每个 Source 都有本人特定的参数来定义如何取数据，SeaTunnel 也提取了每个 source 会用到的参数，比方parameter，用来指定 result_table_name 以后 source 产生的数据的名称，不便供其余模块后续应用。 ...

在近日由中国信息通信研究院（以下简称“中国信通院”）和中国通信标准化协会联结主办的“2023 OSCAR 开源产业大会”上，主办方颁布了 2023 年“OSCAR 开源尖峰案例”评比后果，包含“开源人物”“开源我的项目”“开源社区”“开源企业”“开源技术创新”五个畛域，旨在表彰优良开源案例，建立开源榜样。其中，Apache DolphinScheduler 荣获「尖峰开源我的项目」奖项！ 正如中国通信标准化协会副理事长兼秘书长代晓慧在致辞中所说，数字化时代，开源已逐步成为软件开发的重要模式，是推动数字技术创新的重要抓手。Apache DolphinScheduler 作为一个开源的分布式工作流调度零碎，它的指标是简化大规模数据处理和剖析工作的调度和治理，旨在帮忙数据工程师、数据分析师和数据科学家更轻松地治理和执行简单的工作流工作。随着大数据技术的一直倒退，工作流治理变得越来越重要，而 Apache DolphinScheduler 提供了一个开源、弱小、牢靠的解决方案。 右二为 Apache DolphinScheduler 代表下台领奖 作为一个开源社区，Apache DolphinScheduler 社区不仅拥有者宽泛的用户根底、翻新的性能加强和卓越的性能，更重要的是有领有沉闷的社区反对，以及强烈的开源精力，这种开源模式促成了常识的共享和技术的提高。此次在“2023 OSCAR 开源尖峰案例”评比中荣获「尖峰开源我的项目奖」是 Apache DolphinScheduler 倒退历程中的一个重要里程碑，将来社区将持续致力于提供高质量的工作流调度解决方案，满足一直增长的用户需要，持续在开源畛域施展重要作用，为数据工程师和分析师提供优良的工作流调度解决方案，推动数据处理和剖析的倒退。 本文由 白鲸开源科技 提供公布反对！

奇富科技（原360数科）是人工智能驱动的信贷科技服务平台，致力于凭借智能服务、AI钻研及利用、平安科技，赋能金融机构提质增效，助推普惠金融高质量倒退，让更多人享受到平安便捷的金融科技服务。作为国内当先的信贷科技服务品牌，累计注册用户数2亿多。 奇富科技之前应用的是自研的任务调度框架，基于Python研发的，常常面临着调度不稳固的情况，难以保护。起初引入了Apache DolphinScheduler作为公司的大数据任务调度零碎，面对大量任务调度的考验，经验了半年磨合期，目前Apache DolphinScheduler在奇富科技运行十分稳固。本文将介绍该公司团队最近一年在开源版Apache DolphinScheduler根底上所做的优化和改良。 一、技术架构在咱们公司的大数据离线任务调度架构中，调度平台处于中间层。用户通过数据集成平台提交数据同步工作给调度平台，通过数据开发平台提交工作流给调度平台。用户不和调度平台间接交互，而是和数据集成平台和数据开发平台交互（图1）。 因为咱们是一个金融相干业务的公司，业务须要保障高可用。因而，咱们的调度平台是异地双机房架构，外围工作流会异地双机房运行。集群角色分为cluster A和cluster B，其中cluster A为主集群，cluster B为从集群（图2）。用户的工作流在A集群运行，其中外围要害工作流会在A和B集群双机房运行。以下是调度集群各服务个数。其中Api、Alter、Master服务在虚拟机部署，Worker和Logger部署在物理机上。 二、业务挑战01 调度任务量大咱们目前每天调度的工作流实例在3万多，工作实例在14万多。每天调度的任务量十分宏大，要保障这么多任务实例稳固、无提早运行，是一个十分大的挑战2 02 运维简单因为每天调度的工作实例十分多，咱们经验了几次调度机器扩容阶段。目前2个调度集群有6台Master、34台Worker机器。而且调度机器处于异地2个城市，减少了很多治理运维复杂性。 03 SLA要求高因为咱们业务的金融属性，如果调度服务稳定性出问题，导致工作反复调度、漏调度或者异样，损失会十分大。 三、调度优化实际咱们在过来一年，对于调度服务稳固，咱们做了如下2个方向的优化。第一，调度服务稳定性优化。第二、调度服务监控。 01 反复调度在2023年初，用户大规模迁徙工作流时，遇到了工作流反复调度问题。该问题，景象是同一个工作流会在同一个集群同一时间，生成2个工作流实例。通过排查，是因为用户在迁徙时，会有工作流迁徙我的项目的需要，比方从A我的项目迁徙到B我的项目。在工作流上线时，用户通过提交工单，批改了调度数据库中工作流的我的项目ID，进行迁徙。这么做会导致该工作流所对应的quartz元数据产生2条数据，进而导致该工作流反复调度。如图3所示，JOB_NAME为’job_1270’的记录，有2条数据，而JOB_GROUP不一样。查问源码job_name对应工作流的定时器ID，JOB_GROUP对应我的项目ID。因而批改工作流对应的我的项目ID，会导致quartz数据反复和反复调度。正确迁徙工作流我的项目的形式是，先下线工作流，而后再批改我的项目ID。 如何防止和监控此问题，咱们依据这个逻辑，写了反复调度的监控sql，在最近一年中，数次提前发现了quartz的漏调度问题。 SELECT count(1)FROM (SELECT TRIGGER_NAME, count(1) AS num FROM QRTZ_TRIGGERS GROUP BY TRIGGER_NAME HAVING num > 1 )t02 漏调度在2023年初，在凌晨2点，有些工作流产生漏调度，咱们排查后发现是凌晨2点0分调度太集中，调度不过去。因而咱们优化了quartz参数，将org.quartz.jobStore.misfireThreshold从60000调整为600000。 如何监控和防止此问题，监控sql摘要如下： select TRIGGER_NAME,NEXT_FIRE_TIME ,PREV_FIRE_TIME,NEXT_FIRE_TIME-PREV_FIRE_TIMEfrom QRTZ_TRIGGERSwhere NEXT_FIRE_TIME-PREV_FIRE_TIME=86400000*2原理就是依据quartz的元数据表QRTZ_TRIGGERS的上一次调度工夫PREV_FIRE_TIME和下一次调度工夫NEXT_FIRE_TIME的差值进行监控。如果差值为24小时就失常，如果差值为48小时，就阐明呈现了漏调度。 如果曾经产生了漏调度如何紧急解决？ 咱们实现了漏调度补数逻辑通过自定义工作流进行http接口调用。如果监控到产生了漏调度状况，能够立刻运行此工作流，就能把漏调度的工作流立刻调度运行起来。 03 Worker服务卡死这个景象是凌晨调度Worker所在机器内存占用飙升至90%多，服务卡死。 咱们思考产生该问题的起因是，调度worker判断本机残余内存时，有破绽。比方咱们设置worker服务残余内存为25G时，不进行任务调度。然而，当worker本机残余内存为26G时，服务判断本机残余内存未达到限度条件，那么开始从zk队列中抓取工作，每次抓取10个。而每个spark的driver占用2G内存，那么本地抓取的10个工作在将来的内存占用为20G。咱们能够简略计算得出本机残余内存为26G-20G为6G，也就是说抓取了10个工作，将来的残余内存可能为6G，会面临严重不足。 为了解决这个问题，咱们参考Yarn，提出了”预申请”机制。预申请的机制是，判断本机残余内存时，会减去抓取工作的内存，而不是简略判断本机残余内存。 如何获取将要抓取工作的内存数呢？ 有2种形式，第一种是在创立工作流时指定本工作driver占用的内存，第二种是给一个固定平均值。 咱们综合思考，采纳了第二种形式，因为对于用户来说，是没有感知的。咱们对要抓取的每个工作配置1.5G（经验值）内存，以及达到1.5G内存所须要的工夫为180秒，抓取工作后，会放入缓存中，缓存过期工夫为180（经验值）秒。残余内存计算公式，本机残余内存=本机实在物理残余内存-缓存中工作个数1.5G+本次筹备抓取的工作数1.5G 。 还是同样的场景，本机配置的残余内存为25G，本机理论残余内存为26G，要抓取的工作为10个。每个工作将来占用的driver内存为1.5G。简略计算一下，本机残余内存=26G-10*1.5G。在“预申请”机制下，本机残余内存为1G，小于25G，不会抓取，也就不会导致Worker机器的内存占用过高。那么会不会导致Worker服务内存使用率过低呢，比方shell、python、DataX等占用内存低的工作。论断是不会，因为咱们有180秒过期机制，过期后，计算失去的本机残余内存为变高。 依据同样的原理，CPU占用，咱们也加上了同样的机制，给每个要抓取的任务分配肯定的cpu负载值。 加上内存预申请后，最近半年，没有遇到因为内存占用过高导致worker服务卡死的问题。以下是咱们加上内存预申请机制后，worker内存使用率状况，能够看见worker最大内存使用率始终稳固放弃在80%以下。 04 工作反复运行在worker服务卡死时，咱们发现yarn上的工作没有被杀死，而master容错时导致工作被反复提交到yarn上，最终导致用户的数据异样。 咱们剖析后发现，工作实例有一个app_link字段，寄存用户提交的yarn工作的app id，而第一次调度的工作的app id为空。排查代码发现worker在运行工作时，只有实现的yarn 工作，才会更新app_link字段。这样导致master在容错时，拿不到app id，导致旧工作没有被杀死，最终导致工作反复提交。 ...

IP地址定位是一种技术手段，能够通过获取设施的IP地址精确定位设施的地理位置。它在古代社会的许多方面都有宽泛的利用，包含网络安全、广告投放市场调研等。 在互联网时代，人们越来越依赖于网络而IP地址作为网络连接的基石扮演着重要的角色。IP地址定位技术的呈现，使得咱们可能通过IP地址准确地定位设施的地位这对咱们的生存和工作都带来了很大的便当。IP地址定位的原理是基于Internet协定（IP）和地理位置信息之间的映射关系。当设施通过网络进行通信时，它会被调配一个惟一的IP地址。IP地址蕴含了设施所属的网络段和主机地址两局部，通过这个地址咱们能够确定设施所在的网络但无奈确定其具体的地理位置。为了实现IP地址的定位，就须要将IP地址与地理位置信息进行关联。 IP地址定位有两种办法：基于数据库和基于网络。基于数据库的办法是将IP地址与地理位置信息建设映射关系，并将其存储在数据库中。当须要定位某个IP地址时，零碎会依据数据库中的数据查找对应的地理位置信息。而基于网络的办法则是通过在不同地点部署服务器，利用测量网络提早和路由门路等信息来推断设施的地理位置。

数据库技术始终是信息时代中不可或缺的外围组成部分，随着信息量的爆炸式增长和数据的多样化，其重要性愈发凸显。作为中国数据库联盟（ACDU）的品牌流动之一，【ACDU 中国行】在线下会集数据库畛域的行业知名人士，独特探讨数据库前沿技术及其利用，促成行业倒退和翻新，同时也为开发者们提供一个敌对交换的技术平台。 10月14日（周六），第三期【ACDU 中国行】将在"天府之国"成都开启， 将以 数据库前沿技术摸索及利用之路 为主题，汇聚多位行业大咖和各位行业开发者，独特探讨数据库的将来倒退方向和技术创新，欢送大家报名参加！ 嘉宾及议题介绍14:00-14:30 构建牢靠MySQL服务：RPO=0实现计划剖析分享嘉宾：冯光普 多点生存（中国）网络科技有限公司 数据库负责人14:30-15:00 MogDB/openGauss数据库性能治理之道分享嘉宾：熊军 云和恩墨副总经理兼数据库生态产品群总经理15:00-15:30 行远自迩，PostgreSQL修炼之道分享嘉宾：熊灿灿 PostgreSQL ACE/MVP，PostgreSQL学徒公众号作者15:40-16:10 浅析基于Golang的MySQL Proxy中间件实现原理分享嘉宾：冯浩 书声科技DBA16:10-16:40 咱们追赶的数据库：Oracle分享嘉宾：尹海文 Oracle ACE、国内某科技公司任DBA总监16:40-17:10 新一代PG数据库开源监控零碎建设之路分享嘉宾：王军 Zabbix大中华区培训师流动亮点高质量的嘉宾阵容本次流动邀请到了精通OceanBase、PG、MySQL等技术畛域的六位专家大咖，他们将从多个维度登程，探讨数据库将来倒退方向和技术创新的重要议题，并分享他们在实践中的教训和心得，为您带来最新、最有价值的信息。 关注热点话题探讨数据库行业的热点话题，包含数据库新个性解读、利用实际等等，参与者们将从实在案例中取得启发，理解如何将数据库技术与业务需要相结合，为企业发明更大的商业价值。 现场互动与交换本次流动提供与各位专家进行面对面交换的机会，为参会者搭建交换互动平台，晋升与行业内人士的交换、学习和单干！ 精美伴手礼与惊喜互动大奖现场筹备了三重好礼，除了到场即可支付的精美伴手礼，前 40 位到场的敌人还能够取得价值墨天轮定制数据库扑克牌，现场还可参加多轮精美电子产品抽奖。此外，流动设置茶歇环节，邀您一起享受粗劣下午茶。 点击此处即可报名：https://www.modb.pro/event/843欢送各位朋友增加墨天轮小助手（_微信号：modb666_）备注 “成都” 进入专属交换群！期待与大家线下相聚，共论数据库前沿技术与发展趋势！ 欲了解更多可浏览墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、流动直播、在线课程、文档阅览、资源下载、常识分享及在线运维为一体的对立平台，继续促成数据畛域的常识流传和技术创新。

近日，由中国信息通信研究院（以下简称“中国信通院”）泰尔终端实验室主办的“2023数字生态倒退大会”暨中国信通院“铸基打算”年中会议在北京顺利召开。本次会议集中邀请了通信、金融、证券、汽车、制作、能源、交通、云计算、大数据、区块链、人工智能、物联网等行业代表深入探讨高质量数字化的行业倒退及需要，并正式公布了最新的《高质量数字化转型产品及服务全景图（2023）》——悦数图数据库胜利入选，并成为惟一上榜的国产图数据库厂商。 作为工业和信息化部直属的科研事业单位，中国信通院是国内 ICT 畛域惟一可能买通新技术钻研、规范研制、试验验证、检测认证到产业推动全链条全环节的产业翻新平台，在国内外信息通信行业都享有很高的名誉和影响力。 《高质量数字化转型产品及服务全景图》是中国信通院以产业图谱的形式，对国内数字化转型畛域中具备显著市场和商业价值的企业进行的权威总结和集中展现，这份图谱对于数字化转型的需求方以及数字化转型产品服务的供应方，都具备重要的参考价值。 悦数图数据库胜利入选中国信通院“全景图” 在数字化转型的过程中，数据被视为企业最贵重的资源之一，而图数据库则是解决简单数据关系的重要工具。悦数图数据库（Yueshu Graph Database）凭借其卓越性能和独特价值，正在为各行各业带来高质量的数据摸索与剖析体验。 「悦数图数据库」是一款高性能、高可用的企业级原生分布式图数据库，它采纳先进的图计算引擎和分布式存储技术，可能无效解决海量数据，并满足简单场景下的数据深度、实时查问的需要。它具备弱小的数据关联剖析能力，完满撑持常识图谱、图计算、图剖析等套件在前台的构建和大规模数据存储，为数字化业务晋升搭建起一个高可用、高吞吐、低时延的图技术底座，有助于企业深刻开掘数据关联，为更粗浅的数据洞察和更迷信的业务决策提供反对。 本次胜利入选中国信通院《高质量数字化转型产品及服务全景图（2023）》既是对悦数图数据库产品性能和价值的认可，也是对其在推动数字化转型中的踊跃作用的必定。将来，悦数图数据库将持续秉持凋谢、单干、翻新的理念，继续打磨好技术产品，持续施展其弱小的性能和独特的价值，为我国的数字化转型奉献更多力量。欢送查看悦数图数据库官网：https://www.yueshu.com.cn/，理解更多信息

随着互联网的遍及和数字化社会的倒退，网络安全问题日益严重。网络攻击曾经成为威逼集体、企业和国家平安的常见景象。在网络安全建设中，IP（Internet Protocol）地理位置信息的利用变得越来越重要。本文将探讨网络安全建设与IP地理位置的关系，以及IP地理位置在网络安全中的作用和重要性。网络安全建设的重要性网络安全建设是爱护互联网用户、企业和国家免受网络威逼和攻打的要害工作之一。随着数字化信息的广泛传播，网络安全问题曾经演变成一种全球性的挑战。网络攻击形式多样，包含病毒、恶意软件、勒索软件、网络钓鱼、拒绝服务攻打（DDoS）等。这些攻打可能导致数据泄露、金融损失、名誉侵害，甚至国家平安危机。因而，网络安全建设至关重要，它须要综合思考技术、政策、法律和教育等多个方面的因素。IP地理位置的概念IP地址是互联网上惟一标识设施的地址。每个连贯到互联网的设施都有一个独特的IP地址，它相似于传统世界中的邮政地址。与此相关的是IP地理位置，它指的是依据IP地址确定设施所在地理位置的技术和办法。IP地理位置在网络安全中的作用 入侵检测与进攻：通过剖析IP地理位置信息，网络管理员能够更容易地检测到潜在的入侵行为。如果一台设施从一个未知的地理位置尝试拜访零碎，这可能是一个潜在的威逼迹象。因而，IP地理位置能够用于辨认并阻止歹意流动。身份验证与访问控制：在某些状况下，IP地理位置信息能够用于加强用户身份验证和访问控制。例如，如果一个用户宣称他们是从某个中央登录的，但实际上他们的IP地址显示在另一个国家，零碎能够要求额定的验证步骤，以确保用户的身份不被冒用。地理位置限度：有些内容提供商心愿限度特定地区的拜访，例如，因为某些内容可能在某些国家被视为非法或不合适。IP地理位置能够用来辨认访问者的地位并相应地限度他们的拜访。疑似欺诈流动辨认：在金融畛域，IP地理位置信息能够用于检测可能的欺诈流动。如果一个用户在短时间内从多个不同国家的IP地址尝试进行银行交易，这可能是一个欺诈信号。IP地理位置信息的重要性IP地理位置信息在网络安全中的作用越来越受到重视，因为它能够提供无力的工具来加强网络的安全性。然而，须要留神的是，IP地理位置信息并非齐全牢靠，因为一些用户可能应用代理服务器或虚构专用网络来暗藏其实在的地理位置。因而，在应用IP地理位置信息进行网络安全决策时，须要审慎并联合其余安全措施。网络安全建设是爱护互联网世界的要害工作之一，而IP地理位置信息是实现这一指标的无力工具之一。通过正当利用IP地理位置信息，网络管理员能够更好地辨认和应答网络威逼，爱护用户、企业和国家的平安。然而，须要审慎应用这些信息，以确保不会误判或进犯用户的隐衷。网络安全是一个一直倒退的畛域，随着技术的提高，咱们能够期待更多翻新的办法来爱护网络安全。

判断IP地址的合法性是网络管理和平安畛域中十分重要的工作之一。IP地址（Internet Protocol Address）是计算机网络中用于标识和定位设施的一种数字地址。非法的IP地址必须合乎特定的格局和标准。在这篇文章中，咱们将探讨如何判断IP地址的合法性以及一些常见的验证办法。 IP地址的根本构造IP地址通常分为两个次要版本：IPv4和IPv6。IPv4地址由32位二进制数字示意，通常以点分十进制的模式出现，如192.168.1.1。IPv6地址则更长，由128位十六进制数字和冒号示意，如2001:0db8:85a3:0000:0000:8a2e:0370:7334。无论是IPv4还是IPv6，都有一些根本规定来判断IP地址的合法性。判断IPv4地址的合法性判断IPv4地址的合法性须要查看以下几点： 长度：IPv4地址应蕴含四个整数，每个整数在0到255之间，以点分十进制模式示意。因而，IPv4地址应该蕴含三个点（.），分为四个局部。数值范畴：每个局部的值必须在0到255之间。不能有正数或大于255的数值。无前导零：每个局部的值不能以零结尾，除非该局部的值自身是零。例如，192.168.01.1是不非法的。非法字符：IPv4地址只能蕴含数字和点，不能蕴含字母、特殊字符或空格。上面是一个用Python编写的示例代码，用于判断IPv4地址的合法性： import redef is_valid_ipv4(ip): # 应用正则表达式验证IPv4地址的格局 pattern = r'^(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})$' if not re.match(pattern, ip): return False # 将IP地址宰割成四个局部 parts = ip.split('.') # 查看每个局部的值是否在0到255之间 for part in parts: if not 0 <= int(part) <= 255: return False return True判断IPv6地址的合法性 判断IPv6地址的合法性也须要查看一些要害要点： 长度：IPv6地址应蕴含8个局部，每个局部由4个十六进制数字组成，用冒号分隔。总共有7个冒号来分隔这8个局部。数值范畴：每个十六进制局部应为0到FFFF之间的数值。字母大小写：IPv6地址中的字母应应用小写字母示意，只管IPv6地址不辨别大小写。非法字符：IPv6地址只能蕴含十六进制数字和冒号，不能蕴含其余字符。以下是一个用Python编写的示例代码，用于判断IPv6地址的合法性： import redef is_valid_ipv6(ip): # 应用正则表达式验证IPv6地址的格局 pattern = r'^([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$' if not re.match(pattern, ip): return False return True判断IP地址的合法性是确保网络配置正确和平安的重要步骤。通过查看IP地址的长度、数值范畴、格局和字符，能够无效地确定一个IP地址是否非法。上述示例代码能够帮忙您验证IPv4和IPv6地址的合法性，确保您的网络配置正确无误。在网络管理和平安中，正确验证IP地址的合法性是至关重要的一步。

引言 数据库与大数据始终是技术圈的两个常青畛域。PC 时代诞生了最早的关系型数据库，之后数据类型越来越多，呈现了各种非关系型数据库。云时代拉开序幕的同时，“大数据”一词也被宽泛应用，涵盖海量数据的采集、解决、存储、剖析和出现的系列流程。大模型席卷而来的当下，许多数据库、数据分析解决引擎纷纷寻求与 AI 技术的结合点，试图找到更新、更切合将来倒退的翻新点…… 回顾以往围绕数据所产生的各项新技术，一方面，随着需要的迭代，从数据存储传输，到剖析应用，各个节点的技术都须要不断创新。另一方面，以数据库为代表的数据技术呈现出“四世同堂”的状态，如晚期的 PostgreSQL、Oracle、MySQL 仍旧占据很大份额的市场，新兴的向量数据库、时序数据库等等也在攻城略地，又比方数据库技术和大数据技术也在一直交融。 因而，腾讯云 TVP 联结 OSCHINA 社区，以“数据与前沿技术”为主题，举办 Techo TVP 技术沙龙暨OSC 源创会，心愿出现业界围绕数据存储、剖析，数据挖掘等所做的技术创新，独特探讨数据技术的将来倒退。 峰会简介本期腾讯云 TVP 与 OSCHINA 社区强强联合，汇集了 5 位数据畛域的大佬，话题涵盖老牌数据库 PostgreSQL 和最新的向量数据库解析，更有来自大数据、数据挖掘畛域的讲师带来干货满满的最佳实际分享。 9 月 23 日（周六） 13:30-17:30，成都市天府三街腾讯大厦 A 座 817 会议室，期待各位的到来！ 参会形式辨认下图二维码或点击文末左下角「浏览原文」，即可收费报名加入本次 Techo TVP 开发者峰会，9 月 23 日（周六），成都市天府三街腾讯大厦 A 座 817 会议室，TVP 与你相约，不见不散！ 大会现场更有腾讯定制噗噗盲盒、鹅厂周边公仔等精美礼物，所有到场参会的开发者皆有机会参加抽奖。你还在等什么，快扫码报名参会吧！报名胜利后，增加云小助微信：tvp1215，回复关键词：数据，可提前进群参加互动，抽取礼品大奖！ 结语Techo TVP 开发者沙龙，是腾讯云 TVP 面向宽广开发者举办的技术交流活动，旨在通过最用心的分享、最前沿的洞察、最理论的观点，为开发者敌人献上一场“最有料、乏味、且有用”的技术盛宴。 OSC 源创会是 OSCHINA 社区（http://oschina.net）主办，聚焦开源、翻新的技术沙龙。从 2011 年起已继续举办 11 年，胜利举办 94 期，笼罩 19 座城市，在开发者群体中影响深远。

以后，在政府、军事、城市规划、自然资源治理等畛域，企业对地理信息的需要迅速减少，人们须要更无效地治理和剖析天文数据，以进行决策和布局。在此背景下，“GIS 根底平台”应运而生，它通常指的是一个地理信息系统（GIS）的外围基础设施，包含用于解决和治理天文数据的根本工具和性能。 近日，涛思数据与天穹数码已实现产品兼容互认证工作，经单方独特严格测试，涛思数据旗下物联网、工业大数据平台 TDengine V3.0 与天穹数码旗下大型 GIS 根底平台-天穹地理信息平台（KQGIS）V8.5 实现产品兼容性验证，两款产品可能相互兼容、顺利装置、运行稳固，为企业进行数字化转型提供更全面的技术保障。 作为一款全面反对国产化环境的大型 GIS 根底平台，KQGIS 产品体系欠缺，蕴含桌面 GIS、服务 GIS、大数据 GIS 以及挪动 GIS 等业余利用与二次开发包，同时其还具备二三维数据整合与治理、空间大数据分析与可视化、高性能服务公布与共享以及简便型二次开发等能力，可能为数字中国、数字社会、数字经济建设提供技术与产品撑持。 此次认证单干并非 TDengine 与天穹数码的首次接触。此前，在天穹数码的地灾业余监测物联网平台我的项目中，因为本来的关系型数据库 Oracle 曾经无奈满足实时写入与高性能查问要求，他们抉择接入 TDengine 以解决海量时序数据的存储和计算问题。在该我的项目中，TDengine 展现出了弱小的读写性能和数据压缩能力，无效升高了机器应用老本。 此次 TDengine 与 KQGIS 实现产品兼容性互认证，置信两大产品将暴发弱小的协同作用，为企业提供更多的工具和资源来开掘地理信息的潜在价值，以便做出更智能的决策和更高效的业务经营。 对于天穹数码天穹数码技术股份有限公司成立于 2001 年，是国内当先的时空信息 3S 平台产品与利用服务提供商，集空间大数据分析与交融解决、信息化运维服务及行业信息化整体解决方案于一体的地理信息全产业链领军企业。天穹数码专一于地理信息系统（GIS）、遥感技术（RS）及卫星导航定位定向（GNSS）技术等产品研发，通过二十余载的积淀和积攒，领有了一批自主可控的外围关键技术，造成了四大平台体系：地理信息平台（KQ GIS）、遥感智能服务平台（KQ RS）、卫星导航定位及定向平台（KQ GNSS）、业务协同平台（KQ CO）。 对于 TDengineTDengine 外围是一款高性能、集群开源、云原生的时序数据库（Time Series Database，TSDB），专为物联网、工业互联网、电力、IT 运维等场景设计并优化，具备极强的弹性伸缩能力。同时它还带有内建的缓存、流式计算、数据订阅等零碎性能，能大幅缩小零碎设计的复杂度，升高研发和经营老本，是一个高性能、分布式的物联网、工业大数据平台。以后 TDengine 次要提供两大版本，别离是反对私有化部署的 TDengine Enterprise 以及全托管的物联网、工业互联网云服务平台 TDengine Cloud，两者在开源时序数据库 TDengine OSS 的性能根底上有更多增强，用户可依据本身业务体量和需要进行版本抉择。

时至今日，数据曾经被越来越多的企业视为倒退的策略资源，而云数仓则是数据施展重要价值的要害媒介。云数仓的呈现，不仅扭转了传统数据仓库的服务模式，更给用户带来了应答海量、新型数据的存储和解决能力，为满足业务现代化需要提供了根底。 然而，随着经营节奏的放慢，企业对实时剖析和疾速论断的需要越来越强烈，传统数仓的离线同步曾经逐步无奈满足业务要求。 站在这样一个行业需要的路口，面对这个难题，酷克数据给出了本人的解法：在劣势OLAP产品的根底上，研发推出了簇新的UnionStore模块，在放弃顶层同一套引擎、底层同一套存储与数据的一致性设计的状况下，实现了近事务级的计算与查问实时性，为用户利用云数仓关上了新的思路和场景。 图1：HashData UnionStore模块架构图酷克数据是一家专一于云端数据仓库的科技公司，公司旗舰产品HashData秉承云原生的理念与设计框架，帮忙诸多企业突破了数据烟囱，整合了数据孤岛；打造的企业级云数仓，撑持着各种各样的数据分析负载。 要想理解HashData是如何实现云数仓的实时个性，咱们须要回到云数仓的演进历史。其实，正所谓“历史始终在螺旋式回升”，任何新变动都不是欲速不达，云数仓成为明天企业数字化转型的核心技术，其中的变动也是逐渐演变而来，并非欲速不达的过程。  云数仓演进历史过来十年是信息化高速倒退的十年，也是大数据疾速成长的十年。信息数据呈爆发式增长，不仅让传统企业减速向数字经济聚拢，更带来了底层数据架构变动的新范式。越来越多的企业心愿把数据存好、用好，通过数据背地的逻辑剖析去开掘商业价值，摸索数据之间的关联关系，找出大数据外面有价值的信息，辅助商业决策。数据仓库在此种背景下逐步被企业器重。 同传统数据仓库相比，云数仓依靠云计算的特点，在搭建、应用、扩容及运维等方面有着显著的劣势，已成为目前最为支流的技术产品。它能够把大规模并行计算与云的劣势联合在一起，更好地实现数仓的剖析能力。 比方：在高性能方面，云数仓能够反对向量计算异步的执行框架，包含通过并行计算来最大化地利用 CPU资源去晋升查问的性能。在数据一致性方面，能够反对ACID个性，包含在数据新鲜度上，能够反对数据的实时增、删、改、查。而从可扩展性来看，云数仓这种存算拆散的架构，能够按需扩大，按使用量去计费，极大地升高了用户的应用老本。当计算不够的时候能够去扩计算，存储不够的时候能够扩存储，实现充沛灵便。 架构改革一般来说，因为数仓产品广泛采纳列存，产品通常在离线解决和实时处理之中更偏差离线，而实时性会成为绝对的短板。 在离线解决的场景中，用户数据载入后，通过ETL进行数据的抽取和荡涤，而后存储到数据仓库，执行离线剖析、批处理、报表生成等作业。数据工程师们经常在上班前将前一天或者当天的查问打算输出到数仓，零碎在夜间来执行作业，第二天下班起初查问报表后果，时效是T+1天以上。 然而，随着企业数据品种越来多，数据量越来越大，数据处理过程越来越简单，繁多的传统数仓越来越难以满足业务需要。企业心愿应用一套架构去承载数据，晋升整体性能，同时还要满足实时需要，这些都在促使OLAP和OLTP产生进一步的交融。 现在，各行各业都在一直谋求更好的用户体验，这一谋求带动了实时数据分析能力的需要越来越强烈。 例如，消费品公司心愿通过电商平台和社交网络上来理解用户的搜寻行为和关注热点，这无疑须要获取实时数据。这一变动将传统的Lambda架构推到风口浪尖。Lambda架构的劣势是高容错、低延时和可扩大等特色。然而，它的弊病则在于须要将所有的算法实现两次。其中，一套零碎用来做批处理，进行存量数据计算；另一套零碎用来满足实时性业务需要。两套零碎的并行运作为开发和运维工作带来了大量的老本与累赘。 为了实现架构简化，业界推出了Kappa架构作为一个新的演进方向。这种只采纳流式解决引擎的形式，使得开发人员只需保护实时处理模块，极大地升高了开发的复杂性。 提到实时处理，很难不提Flink。通过音讯队列的模式，Flink能够保留历史数据，并反对用户源源不断地去生产这些数据，对数据进行实时处理，将后果反馈输入。对于云数仓而言，与Flink计划的联合，在计算和存储引擎端带来了不同的架构变动。在计算引擎上，产品须要反对实时性，疾速捕获数据。而在存储引擎上，通过分布式存储，实现高可靠性与高扩展性的需要，同时实现较低的存储老本。  图2：基于“存算拆散”架构的HashData云数仓在金融行业落地计划示意图展望未来，存算拆散和Serverless架构将会成为支流。思考到可扩展性老本，企业更违心基于欠缺的存储设施平台去构建技术底座，晋升查问性能。作为业内当先的云数仓产品，HashData采纳的是元数据、计算和存储齐全拆散的架构设计，通过对象存储来共享一份全域数据的形式，充分发挥云架构劣势，实现集群的秒级主动扩缩容，在满足实时性的同时，提供了更高的架构与老本灵便度。利用趋势从利用趋势来看，金融、电信、能源、政务等行业畛域，会是云数仓的重要利用场景。在数字化转型浪潮推动下，会有越来越多的企业想成为数据驱动型企业，动员基于数据的业务翻新。 对于金融行业而言，业务属性对云数仓的实时性提出了更高要求，包含处理速度、I/O性能等。例如，在金融风控和反欺诈场景中，数据系统须要在短时间内进行响应，做出决策，能力最大水平防止经济损失。 同时，可扩展性、易用性、性价比也是金融场景的重要需要点。只有突破部门之间的壁垒，实现架构上的冲破，能力经受得住简单场景下的打磨和验证。 面对用户“既要、又要、还要”的问题，HashData在内核层面进行了翻新冲破，让实时数据处理成为可能。以HashData UnionStore为例，这是一种基于日志的数据库架构思维，当存算解耦后，让应用不同引擎离开解决数据成为可能，Log is database理念能够全面晋升数仓的TP性能，在磁盘随机拜访、异步提交、并发管制、批处理、重放等方面进行了全面优化，从而实现了实时性晋升。 图3：HashData UnionStore利用场景现在，曾经有很多的当先金融企业抉择用HashData实现了传统数据仓库的代替，解决传统架构扩容难题。金融畛域数据量个别比拟大，集群很多，传统MPP的部署形式导致每个部门都有本人的专属集群及相干数据，扩容过程繁琐，工夫周期长，运维老本居高不下。在进行数据流动、数据共享，数据互通的操作时，个别通过数据同步或者复制的形式来创立数据正本，创立新的集群，这样的形式带来了微小的老本压力。 HashData不仅解决了用户的可扩大问题，还能实现按需免费。举例来说，如果用户的CPU需要密集，能够创立一个CPU比拟多的集群，依据集群申请灵便扩大资源。不同集群对应同一份数据，能够满足各类读写需要。 明天咱们看到，存算拆散曾经成为云数仓的支流技术趋势。HashData正通过一份数据全域共享的形式，满足外围业务的实时性需要，为企业业务决策提速带来了弱小助力。置信随着企业对实时剖析需要的一直加强，HashData会和更多用户携手同行，奔向数智化的新将来！

引言PostgreSQL 应用基于音讯的协定在前端（客户端）和后端（服务器）之间进行通信。该协定通过 TCP/IP 和 Unix 域套接字反对。 《深度解析 PostgreSQL Protocol v3.0》系列技术贴，将带大家深度理解 PostgreSQL Protocol v3.0（在 PostgreSQL 7.4 及更高版本中实现，无关晚期协定版本的形容请参考 PostgreSQL 文档的晚期版本，该系列文章不予赘述）相干的音讯传输格局和格局码、音讯反对的数据类型、音讯的格局、协定交互流程、谬误音讯和告诉音讯、反对的子协定等，相干的代码解读基于 PostgreSQL 代码仓库的REL_14_STABLE 分支。 本期是《深度解析 PostgreSQL Protocol v3.0》系列技术贴的第二期文章，在第一期文章中带大家解读了 PostgreSQL Protocol v3.0（一）—概述，本期将为大家分享 PostgreSQL Protocol v3.0（二） — 扩大查问性能的内容。 一、扩大查问介绍扩大查问（Extended Query）协定将简略查问协定合成为多个步骤，为提高效率，可多次重复应用筹备（Prepare）步骤的后果。此外，扩大查问协定还提供了其余性能，例如能够将数据值作为独自的参数提供，而不用将它们直接插入到查问字符串中。 在扩大查问协定中，客户端首先发送一条 Parse 音讯，其中蕴含文本查问字符串、可选的参数占位符的数据类型信息以及指标筹备语句对象的名称（指标筹备语句对象名称为空字符串，则抉择未命名的筹备语句）。响应为ParseComplete 或 ErrorResponse 音讯。参数数据类型能够由 OID 指定；如果没有指定参数数据类型，解析器将尝试以与无类型的文本字符串常量雷同的形式推断数据类型。 Parse 过程须要留神： （1）参数的数据类型能够不指定，此时设置参数数据类型的 OID 为 0，或者使参数数据类型 OID 的数组比查问字符串中应用的参数符号的数量（$n）短。另一种非凡状况是参数的数据类型能够指定为 void（即 void 伪类型的 OID）。这意味着容许实际上是输入 OUT 应用的参数符号，作为函数的入参应用。通常状况下，没有能够应用 void 参数的上下文，但如果函数的参数列表中呈现了这样的参数符号，则实际上会疏忽它。例如，如果将 $3 和 $4 指定为具备 void 类型，则诸如 foo($1, $2, $3, $4) 之类的函数调用能够匹配具备两个 IN 和两个 OUT 参数的函数。 （2）Parse 音讯中蕴含的查问字符串不能蕴含多个 SQL 语句，否则报告语法错误。这种限度在简略查问协定中不存在，但在扩大查问协定中的确存在，因为容许筹备语句或门户蕴含多个 SQL 命令会使协定适度复杂化。 如果胜利创立命名的筹备语句对象，除非明确销毁它，否则它将继续到以后会话完结。未命名的筹备语句只继续到解决下一个指定未命名语句为指标的 Parse 语句为止。 须要特地留神的是，简略查问音讯 Query 也会销毁未命名的筹备语句。命名的筹备语句必须显式敞开，而后能力被另一个 Parse 音讯从新定义，但这对于未命名语句来说不是必须的。还能够应用 PREPARE 和 EXECUTE 在 SQL 命令级别创立和拜访命名的筹备语句。 ...

哈喽，大家好！又到每月发版工夫，本次 CloudQuery 社区版又为大家带来哪些新体验呢？咱们一起往下看！（拉到文末，预约操作演示直播）本次更新快览：新增云市场装置形式新增三大数据源：Hive、Impala、Vertica审计剖析新增越权操作、高危操作、慢 sql、用户受权视图明细新增监控性能数据保护功能完善数据字典功能完善去 Message…… 新增性能新增云市场装置形式自 V2.4.0 始，CloudQuery 社区版减少云市场装置形式！目前 CloudQuery 已在天翼云云市场上架，领有天翼云服务器资源的小伙伴可间接在「天翼云云市场」搜寻「CloudQuery」。同时在 CloudQuery 官网下载页面也减少了「云市场装置」入口，具体操作步骤可参照CQ官网文档核心中的「云市场装置手册」。装置手册地址：https://bintools.yuque.com/org-wiki-bintools-xniowl/do4ums/zt...后续 CloudQuery 将会在更多云市场上架，请继续关注咱们的社区动静~ 三大数据源新增在 V 2.4.0 中，咱们新增了 Hive、Impala、Vertica 三大数据源的反对，对这些数据源反对权限管控、数据保护、审计剖析等。目前 V 2.4.0 总计反对 14 个数据源。详细情况见下表：  新增越权操作、高危操作、慢 SQL、用户受权视图明细在 V 2.4.0 及以前，零碎中所有的操作行为都被对立打包记录在语句明细或操作明细中，用户只能通过这两个维度来进行查看，针对局部用户比拟关注的类型操作，没有做到具体的分块展现。V 2.4.0 在审计模块中，将数据依照不同的维度进行了划分，更清晰的展现了用户的行为动作，包含高危操作、越权操作、慢 SQL、用户受权详情示图。示意图： 新增监控性能V 2.4.0 反对了容器监控和主机监控，可能实时监控零碎的 CPU 内存、网络 I/O、磁盘 I/O ...... 应用状况。示意图： 功能完善数据保护功能完善在 V 2.4.0 及以前，数据保护模块中对字段设置的脱敏算法对全局用户失效，无奈满足不同等级用户查表时数据脱敏差异化。即：只有对数据库表中的某个字段设置了脱敏算法，所有用户查表时都出现脱敏成果。而在 V2.4.0 版本中，新增的策略性能能够通过配置策略条件，来决定哪些用户或某个时间段可明文查看数据。示意图：在脱敏字段模块，抉择提前设置好的脱敏字段详情中，抉择「策略」即可增加条件。 数据字典功能完善在 V 2.4.0 及以前，只能由连贯管理员、或 DBA 角色通过手动在「资源纳管」中进行同步，资源纳管的「禁用/启用」操作可能会导致资源中波及的权限和关联用户被回收，并不能作为数据字典的同步工作入口。因而，在 V 2.4.0 中减少了「手动同步」和「定时同步」工作。「手动同步」工作即在用户进行数据操作时，可能间接在 sdt 树右键菜单上进行同步。「定时同步」工作即零碎定时同步数据字典，确保数据的统一性。 去 Message V 2.4.0 及以前版本 Message 服务只有执行音讯、导入导出完结音讯的告诉，没有其余性能；音讯告诉形式应用 WebSocket 形式实时通信；前后端的 WebSocket 常常产生断联，又没有较好地设计出 WebSocket 的复原断联形式，一旦呈现断联前段频繁发动 Websocket的建设申请，并且断联后执行会卡死。 ...

笔者之前写的「全方位比照 Postgres 和 MySQL」还在继续发酵，最近腾讯的公众号也公布了一篇「MySQL VS PostgreSQL，谁是世界上最胜利的数据库？」，其中在比照两者应用的开源证书时写到： PostgreSQL License 是一个宽松的开源许可证，相似于 MIT 许可证。它容许用户自在应用、批改和散发，无需公开源代码。它也不强制任何特定的版权申明，这使得它与许多其余开源和专有许可证兼容。MySQL 采纳 GPLv2 是一个“传染性”的开源许可证，这意味着任何基于 GPLv2 许可的代码进行批改或扩大，并且要散发的派生作品，也必须在 GPLv2 下公布。这确保了软件的自由性，但也可能限度了与非 GPL 软件的集成。艰深来说，PostgreSQL License 反对第三方进行批改后商业化，还能够不开源。但 GPLv2 协定要求任何基于 GPLv2 软件的衍生作品也必须是开源的，所以第三方的优化成绩最终也会反馈给社区。长期来看，GPLv2 协定更能带动开源社区的倒退。这段话对于两个证书的解释是正确的，然而最初对于 GPLv2 协定更能带动开源社区倒退的论断有待商讨。 咱们先来看一下 PostgreSQL 应用的证书。 再比照一下 MySQL 应用的 GPLv2 证书。 证书太长了，在 27 寸的显示器上都没法一屏截完。另外属于 Oracle 的 MySQL 还提供独自的商业证书，给那些想应用 MySQL 组件，但又无奈遵循 GPL 证书的厂商。 Google 的 Open Source 网站也做了一个归类, PostgreSQL 的证书是归在了 notice 之列。 而 GPL 证书是归在了 restricted 之列。 笔者之前在 Google 保护外部的 MySQL 和 PostgreSQL 分支以及相关联的组件，凡是要引入 restricted 证书的开源我的项目，也须要提供更多的资料来论述引入的必要性，让开源部门进行审核。毕竟还是要尽量避免净化 (Taint) Google 本人的代码。在决定把软件我的项目开源后，首要思考的就是抉择哪种开源证书。GitHub 还为此做了特意的定制，在 GitHub 上我的项目的根目录下尝试创立 LICENSE 的文件，就能间接抉择风行的开源证书模版。 ...

事务日志是数据库的重要组成部分，记录了数据库系统中所有更改和操作的历史信息。 WAL log(Write Ahead Logging)也被称为xlog，是事务日志的一种，也是关系数据库系统中用于保证数据一致性和事务完整性的一系列技术，在数据库复原、高可用、流复制、逻辑复制等模块中扮演着极其重要的角色。 在这次直播中，咱们为大家介绍了WAL log模块的基本原理、形成和个性。以下内容依据直播文字实录整顿而成。 WAL log简介数据库在写入或更新材料时，要确保事务始终保持ACID的个性。当零碎产生故障时，数据库通过事务日志回放来保障故障复原后数据不失落。 图1：单机WAL log流程示意图如图1所示，在单机场景下，如果每一次写入或更新都间接去写表文件，单次更新表文件的代价绝对昂扬，对于硬盘来说随机写的性能也会十分差。 此时，能够通过引入缓冲池（Buffer Pool），将数据写入内存中。相比间接写表文件，这种形式的性能更高。 同时，为了保证数据的长久化，须要引入WAL log：在内存更新前，先写入WAL log，再更新内存。在这种状况下，即便呈现了断电或故障等状况，也能精确地复原数据，保障了数据库的ACID。相比间接去更新表文件，WAL log代价更小，执行门路更短。在PostgreSQL中，WAL log的写入也属于随机写。 图2：联机WAL log流程示意图除此之外，WAL log在联机场景下还能够反对主从同步，以及热备份等性能。 以Greenplum为例，如果没有引入WAL log ，主从之间须要约定好一份同步/备份的协定，或者是在从节点执行同样的SQL语句，这样不仅操作简单，而且很难做到热切换。在引入WAL log之后，主从节点之间间接同步WAL log，就可能保证数据的一致性。当主节点产生故障时，从节点也能疾速地通过相应的WAL log重放，让数据恢复到可应用的状态，整个过程操作更为简便。 WAL log实现形式不同的数据库对WAL log实现的需要点也有所区别，次要体现在四个方面： 首先是格局，个别由meta+data两个局部组成。meta局部记录了关联资源的元信息，data是资源自定的裸数据。meta和data能够离开存储，也能够对立存储。离开存储时，单条WAL log须要先读取残缺的meta，再按需要解data；对立存储时，能够一条条解。举个例子，在离开存储时，数据组成往往是meta1+meta2.. metaN+data1+data2...dataN；而在对立存储时，数据组成往往是meta1+data1+meta2+data2...metaN+dataN。其次，在批改数据时有undo log和redo log两种形式。undo log从后往前写，redo log从前往后写。PostgreSQL采纳的是redo log。此外，循环校验码信息（CRC）分为残缺数据和分段数据两种。分段CRC的长处是当呈现谬误时，可能疾速定位到坏的块数据，且损坏的范畴很小，但代价是速度较慢；相比之下，残缺数据的CRC读写速度更快，但如果单个meta损坏，则可能导致整个WAL log都损坏，复原老本较高。最初，是否须要落盘，这次要取决于具体场景，如果只做同步和备份，能够思考不落盘。WAL log的组成在PostgreSQL中，WAL log由头部、块头部、块公有数据块、自定义资源数据块四局部组成。 图3：PostgreSQL中WAL log形成图头部和块头部，相当于下面提到的meta，次要用于数据块的疾速定位、数据块的形容以及对数据块CRC操作等。其中，块头部是公有的，须要和page绑定。而块公有数据和WAL log自身数据属于data局部，用于存储具体的数据。 在WAL log自身数据中，初始化资源管理器rmgr(Resource managers definition)是自定义资源的次要载体，也是WAL log数据块内容的生产与消费者。 WAL log checkpointWAL log在执行过程中，数据量会一直地累积，当达到肯定数量后，会对系统性能产生影响，因而须要定时清理WAL log数据。 清理页缓存和xlog文件须要借助checkpoint（检查点）机制。执行checkpoint 之后，页缓存能够被清空，这样能够保障不会因为页缓存太大而导致性能降落。 checkpoint的次要作用包含脏数据块回写、xlog回收（非archive xlog 且已同步的 xlog）和checkpoint redo。 通常触发checkpoint的机会次要有包含按时定期清理、数据最大长度限度、checkpoint语句、数据库敞开在内的四种场景。当然在其余场景下，也可能会触发checkpoint，这里不再一一列举。 主动checkpoint指的是依照肯定的工夫距离执行checkpoint命令，工夫距离在PostgreSQL.conf文件中能够配置，默认是5分钟。 WAL log recovery与replay如图4所示，在GPDB中，数据恢复的过程蕴含了数据重放。数据库启动时，会有startup过程关上checkpoint redo文件，开始按程序读取xlog，进行复原操作。 ...

IP地址是互联网上设施的惟一标识符，而将IP地址转换为地理位置信息是网络管理、安全监控和市场定位等畛域中的一项重要工作。本文将深入探讨IP转地理位置的技术原理和各种利用场景。IP地址与地理位置IP地址（Internet Protocol Address）是一组数字，用于惟一标识互联网上的设施。它们分为IPv4（32位地址）和IPv6（128位地址），通常示意为点分十进制（如IPv4的"192.168.1.1"）或冒号分隔的十六进制（如IPv6的"2001:0db8:85a3:0000:0000:8a2e:0370:7334"）。地理位置信息包含国家、地区、城市、经度和纬度等数据，能够用于辨认设施所在的理论地理位置。IP转地理位置的基本原理IP转地理位置的基本原理是将IP地址映射到一个或多个地理位置信息的数据库。这些数据库蕴含了大量的IP地址与地理位置信息之间的关联，它们的更新频率能够从每天到每月不等。以下是实现IP转地理位置的次要办法： IP地理位置数据库这些数据库包含MaxMind的GeoIP、IP2Location等，它们提供了IP地址与地理位置信息的关联。这些数据库通常由网络爬虫、用户提交的数据和互联网号码调配机构（如RIPE、ARIN等）提供的信息构建而成。 基于BGP路由表BGP（Border Gateway Protocol）是互联网路由协定，它蕴含了寰球范畴内的IP地址路由信息。通过查看BGP路由表，能够推断出IP地址的地理位置，尽管这种办法通常只能确定到城市或地区级别。 统计分析和数据挖掘一些提供IP转地理位置服务的公司采纳统计分析和数据挖掘的办法来进步准确性。他们可能会收集来自多个数据源的信息，而后进行模型训练和剖析，以便提供更准确的地理位置信息。利用场景IP转地理位置技术在多个应用领域中施展了关键作用： 网络安全通过将IP地址转换为地理位置，平安专家能够更好地监控和辨认潜在的威逼。异样的地理位置拜访可能示意平安问题，例如，如果一台服务器在短时间内被多个不同地理位置的IP地址频繁拜访，这可能是DDoS攻打的迹象。市场营销公司能够应用IP地址定位来为用户提供更有针对性的广告和举荐内容。通过理解用户的地理位置，他们能够更好地适应地方性需要，提供与用户所在地区相干的产品和服务。 物流和定位服务物流和地图利用能够应用IP地址定位来确定用户或交付目的地的精确地位。这对于提供实时导航、配送跟踪和定位服务至关重要。 网络性能优化网络管理员能够利用IP地址定位信息来更好地治理流量和资源，确保用户从离他们更近的服务器获取数据，进步网络性能。 个性化内容提供许多网站和应用程序应用IP地址定位来提供用户个性化的内容，例如天气预报、当地新闻和商家信息。这进步了用户体验和黏性。隐衷思考只管IP转地理位置技术有许多利用，但隐衷问题是一个须要特地关注的方面。收集和应用地理位置信息可能波及到个人隐私，因而在应用这些数据时必须恪守相干法规和最佳实际，以确保用户的隐衷失去爱护。总之，IP转地理位置技术是网络管理、市场营销和平安畛域的要害工具，它为多种利用场景提供了精确的地理位置信息。通过理解其原理和利用，能够更好地利用这一技术，进步用户体验、加强网络安全性和优化业务经营。但在应用地理位置信息时，必须审慎解决隐衷问题，确保非法合规和用户隐衷的爱护。

近日，杭州悦数科技有限公司(以下简称“杭州悦数”)正式签订 CLA（Contributor License Agreement，贡献者许可协定），退出龙蜥社区（OpenAnolis）。  杭州悦数成立于 2018 年 10 月，其着力打造的悦数图数据库是一款企业级的原生分布式图数据库产品，基于业界优良的开源分布式图数据库 NebulaGraph 为国内用户提供业余的图数据库产品及运维服务，具备高性能、易扩大、平安稳固等特点。截止 2022 年底，杭州悦数的企业用户已冲破 1000 家，更有超过 80% 的头部互联网公司抉择应用悦数图数据库的产品撑持线上业务。 作为根底的数据库软件，悦数图数据库齐全原生研发，确保数据安全可控，并能与AI人工智能技术深度联合，在大语言模型、智能问答、常识图谱利用等畛域均走在行业前列，可能帮忙企业造成智能化决策，无效进步数据分析实时性与准确度。目前，悦数图数据库已通过 ISO27001、ISO9001、CMMI3 认证，中国信通院图数据库/图计算根底和高级能力专项评测，并领有飞腾、龙芯、麒麟 OS 等多个芯片/服务器/操作系统的国产反对。 杭州悦数产品总监方扬示意：“退出龙蜥社区意味着悦数图数据库在国产操作系统的适配中更进一步，后续悦数图数据库将与龙蜥其余开源工具和技术建设更加严密的分割，实现劣势资源和技术互补，独特推动图数据库的倒退和利用。咱们也期待着与社区成员和其余开发者共同开发和摸索图数据库的将来。” 龙蜥社区经营委员会副主席任紫东示意：“杭州悦数的退出将拓展龙蜥社区联结翻新的幅员，其实时摸索大规模数据的产品悦数图数据库，将是社区在大数据方向新的征途。今后单方将围绕适配发展更多单干，咱们也对将来的单干充斥期待。” 截至目前，已有 600 家企业签订 CLA 协定退出龙蜥社区，包含平安厂商格尔软件、海泰方圆，数据库厂商南大通用、巨杉数据库，中间件厂商西方通、中创中间件、宝兰德等，欢送更多企业退出。  龙腾打算 2.0 可参看：首批招募 50 家！「龙腾社区生态倒退打算」正式公布 —— 完 ——

作者 | 李晨 编辑 | Debra Chen Gartner最近对寰球2,500名高管进行的一项考察发现，近一半（45%）的人示意，ChatGPT的宣传促使他们减少人工智能（AI）投资。调查报告称，70%的高管示意他们正在考察人工智能的应用，而19%的高管正在试点或曾经在生产中部署人工智能。 Gartner发现，大量组织正在应用ChatGPT等生成式AI来改良宣传内容或者生成代码。这种技术能够加强使用者的能力，并能够自主执行业务和IT流程，生成式AI能够潜在地取代或补充多项工作工作。考察发现，68%的高管认为生成式AI的益处大于危险，而只有5%的人认为危险大于收益。然而，随着应用水平的不断深入，高管们可能会开始扭转他们的观点。 Gartner给出了倡议和正告：“最后对新技术的激情可能会让位于对危险和施行挑战的更严格的管控，组织在开始开发和部署生成式AI时，可能会遇到许多信赖、危险、平安、隐衷和道德问题。” ChatGPT，文心一言，Bard或通义千问等工具应用先进的机器学习技术来生成简单的文本。生成式AI的益处包含易于培训和定制化、升高经营老本和7x24全天候服务。然而，只管有这些益处，但像ChatGPT这样的生成式AI工具的确存在着捏造信息、泄露隐衷和错误引导等危险。 生成式AI如何提供业务价值？生成式 AI 是一种特定自然语言解决（NLP）工具，该工具以相似人类的对话形式生成对用户提醒或问题的响应。生成式AI剖析和“学习”各种类型的数据：文本、音频、图像，并生成相似人类的输出答案。 在用于客户服务目标的生成式AI的场景下，组织通常将该工具集成到基于文本或语音的聊天机器人中，用于实现以下工作： 答复客户无关产品或服务的问题。自动化实现订单，换货和退货。提供多种语言服务。将用户疏导至FAQ和服务团队寻求帮忙。依据企业业务的不同，客户服务用例可能会有很大差别。然而ChatGPT这类生成式AI工具的确帮忙企业晋升了AI机器人对客户服务的效率和准确率。 生成式AI在企业应用中的危险只管有益处，但像ChatGPT这类的生成式AI工具也有不少毛病，甚至是致命问题。因而，企业在将重要业务控制权移交给AI机器人之前必须理解以下危险： 捏造信息生成式AI机器人的有用性取决于它们领有的信息。在某些状况下，人工智能可能会谬误地解释信息，或者应用不充沛或过期的信息。如果人工智能零碎学习到不精确或捏造的数据，它可能会对用户问题产生不正确的答复。 生成式人工智能聊天机器人还能够发明连贯的废话，自信而雄辩地做出虚伪陈说。在这种状况下，生成式AI工具会生成随机且不精确的输入，这会使用户感到困惑，捏造的信息也可能导致用户对该工具失去信赖，从而升高其实用性。 隐衷泄露危险隐衷泄露危险是指用户不知情状况下，集体的私密信息被泄露，或者通过其余信息被ChatGPT推断进去的隐衷信息。在应用 ChatGPT 过程中，集体、企业、甚至国家的机密信息都可能泄露。 个人信息的泄露可能会对集体的心理健康、人身和财产平安造成影响。而国家或企业商业秘密则往往只有多数人可能获悉，这些信息的泄露和流传可能会危及国家和企业的平安。此外，即便用户未间接泄露私密信息，ChatGPT 在一直学习的过程中，也可能自行推断出这些信息，减少了隐衷信息被推导进去的危险。 有偏见的信息人工智能模型能够学习辨认和形容对象，以区别很多类似的名字或外观，但ChatGPT应用和剖析的数据是来自数十亿个网页的数据。因而，在互联网上存在的种族或政治偏见能够被夹带到工具的输入中。 如果一个企业的生成式AI聊天机器人产生种族主义、歧视或政治偏见的回应，该企业的品牌可能会受到重大侵害。 不足同理心ChatGPT能够在其回复内容中模仿人类口气和行为，但它依然不足实在人类的同情心和同理心。如果一个愤恨的客户与一个不足真正人类情感的AI机器人互动，他们可能会变得越来越丧气和愤恨。 平安问题与任何网络连接技术一样，一些组织或集体能够机密地将虚伪信息插入生成人工智能零碎。例如，他们可能会插入受恶意软件感化的链接或网络钓鱼做法，为AI提供向用户传递恶意软件和网络钓鱼信息的机会。 企业应该应用生成式AI吗？如何应用更稳当？在这个AIGC时代，生成式AI会极大的扭转社会运行形式和企业商业运行逻辑。客户服务和征询行业、金融和银行业、制造业、教育行业、翻译、影视制作、图像服务等行业都会迎来天翻地覆的变动。咱们不要因噎废食，因为生成式AI有这样或那样的危险就不去应用，这样会使集体或企业错过技术革新而失去竞争力。然而，也须要在应用时进行粗疏的布局和标准的治理。倡议企业在应用生成式AI时遵循以下准则： 用户教育和安全意识晋升：进步用户的教育和安全意识是确保安全应用生成式AI的重要措施。平台和开发者应该提供明确的使用指南和行为准则，向用户解释生成式AI的工作原理、其生成内容的特点以及潜在的危险。推广数字素养和信息鉴别能力，帮忙用户更好地分别虚伪信息、不当行为和歹意攻打。开发者能够发展宣传流动、举办培训和研讨会等，让用户理解生成式AI的利用场景、限度和危险。通过减少用户对生成式AI的认知，能够帮忙他们更加审慎地应用，并被动参加保障应用生成式AI的安全性。 私有化部署生成式AI大模型，并尽量应用自有残缺数据进行二次训练，而非间接采纳内部服务或现成大模型：对生成式AI进行无效的训练和筛选是必要的，训练数据的品质和多样性对于生成出精确、有用的答复至关重要。通过对训练数据进行筛选和审核，去除虚伪、无害或误导性的内容，可能进步生成式AI的可信度和安全性。通过外部残缺数据的二次训练，会让生成式AI更懂理论业务场景和正确的应答内容，提供给用户的反馈信息就会更精确，针对性更强。 欠缺管理策略， 遵循国家政策或法律法规，防止产生道德、隐衷或平安问题：施行内容审核和监管机制是确保生成式AI平安应用的要害一环。平台和使用者应该增强对生成内容的监控和审核，及时发现和处理不当的舆论或内容。建设机制，使用户可能报告无害或违规内容，从而保障平台的平安和用户的权利。 如何私有化部署大模型并疾速训练？面对以上问题，有不少企业心愿训练本人的私有化GPT大模型，然而不菲的硬件投入老本和工夫成为最大的妨碍，让很多尝试拥抱生成式AI的企业望而生畏。如何能用最小的代价，疾速训练出平安、精确、实用的GPT大模型？Apache顶级开源社区海豚调度- DolphinScheduler给出了答案。 Apache DolphinScheduler是一个Star超过1万的大数据和AI的调度工具，它是Apache软件基金会旗下的顶级我的项目，这意味着你能够收费应用它，也能够间接批改代码而不必放心任何商业问题。在AIGC畛域，DolphinScheduler的指标是让任何对GPT大模型有需要的集体或者企业，都能享受到领有更“懂”本人的模型的乐趣，每个人或企业都有权力和能力去塑造本人的AI助手，而DolphinScheduler可见即所得的工作流程为此提供了可能。 无论你是业界专家，寻求用专属于你的数据来训练模型，还是AI爱好者，想尝试了解并摸索深度学习模型的训练，DolphinScheduler都将为你提供便捷的服务。它为你解决了简单的预处理、模型训练、优化等步骤，只需1-2个小时几个简略的操作，加上几十小时的运行工夫，就能够构建出更“懂”你的定制化ChatGPT大模型。 在这个以数据和技术驱动的世界中，领有一个专属的生成式AI模型具备无法估量的价值。随着人工智能和深度学习的日益倒退，咱们正处在一个可塑造个性化AI助手的时代。而训练和部署属于本人的生成式AI模型，能够帮忙咱们拿到更精确，更平安、更可信的后果，更好地利用AI实现业务价值。 总体而言，自训练和部署生成式AI模型能够帮忙你更好地爱护数据安全和隐衷、满足特定的业务需要、节约技术老本，同时通过工作流工具如DolphinScheduler使训练过程自动化，能够减速这一工作的实现。更多信息，请拜访海豚调度官方网站 https://dolphinscheduler.apache.org/ 或者关注微信公众号 “海豚调度”。 本文由 白鲸开源科技 提供公布反对！

作者 | 代立冬 编辑 | Debra Chen Apache DolphinScheduler 是古代数据工作流编排平台，具备十分弱小的可视化能力，DolphinScheduler 致力于使数据工程师、分析师、数据科学家等数据工作者都能够简略轻松地搭建各种数据工作流，让数据处理流程更简略牢靠。 DolphinScheduler 十分易于应用(easy to use)，目前有四种创立工作流的办法： 在 UI 界面上间接通过拖放工作的形式来创立工作PyDolphinScheduler，通过 Python API 创立工作流，也就是 workflow as code 的形式编写 yaml 文件，通过 yaml 创立工作流（目前必须装置 PyDolphinScheduler）通过 Open API 的形式来创立工作流以上 4 种总有一种形式适宜您的场景！ 得益于 DolphinScheduler 采纳无中心化的整体架构设计，使得 DolphinScheduler 调度性能也是同类开源数据工作流编排平台的 5 倍以上，如果您正有这样的性能问题或者调度延时问题，也无妨试试 DolphinScheduler。 DolphinScheduler界面 好的，接下来言归正题，有不少用户想在 DolphinScheduler 扩大新的工作插件反对(比方增加 Kettle)，DolphinScheduler 的工作插件体系是基于 SPI 来进行工作插件扩大的。 什么是 SPI 服务发现？SPI 是 Service Provider Interface 的缩写，是一种常见的服务提供发现机制，比方出名的 OLAP 引擎 Presto 也是应用 SPI 来扩大的。在 java.util.ServiceLoader 的文档里有比拟具体的介绍，其形象的概念是指动静加载某个服务实现。 比方 java.sql.Driver 接口，不同厂商能够针对同一接口做出不同的实现，比方 MySQL 和 PostgreSQL 都有不同的实现提供给用户，而 Java 的 SPI 机制能够为某个接口寻找服务实现。Java 中 SPI 机制次要思维是将拆卸的控制权移到程序之外，在模块化设计中这个机制尤其重要，其核心思想就是解耦。 ...

智能环保零碎通常波及大量的传感器和监测设施，以收集环境数据并对其进行剖析和解决，这些数据通常是时序数据，即在一段时间内按工夫程序生成的数据，规模宏大且要求疾速精确地进行剖析和解决。也因而时序数据处理是智能环保零碎面临的一个重要难题，很多我的项目在创立之初采纳了传统的大数据解决方案，随着数据体量的日益增长，性能差、效率低、老本低等问题逐步露出。在本篇文章中，咱们汇总了三个典型的智能环保我的项目的数据架构降级实际，给到有须要的企业参考。 中科惠软 x TDengine“以往智慧环保我的项目咱们采纳传统数据库架构设计，对在海量秒级监测数据实时统计和剖析耗时长、CPU 和内存利用率低、磁盘 IO 超负荷。在 A 市智慧环保物联网利用我的项目咱们翻新应用了 TDengine，利用了实时流式计算相干函数，解决了大数据存储和计算，升高了代码开发复杂度，让运维工作变得极为简略，极大升高了经营老本。”业务背景中科惠软承建的 A 市“智慧环保”物联网利用我的项目须要采集各类感知设施产生的监测数据和监控设施各种运行状态，我的项目每天采集各类监测数据 2 亿余条，如果应用公司原架构，能够勉强将每天的数据存储下来，但如果须要实现“某天下午两点 A 路段有多少辆渣土车通过”相似条件的多纬度分组聚合查问，那么采纳传统的数据库就无奈达成这类查问需要了。思考到各类感知监测设施会时刻产生大量秒级和分钟级监测数据存储和实时计算，在通过多个时序数据库（Time Series Database）之间的性能和稳定性方面比照，最终，中科惠软采纳了 TDengine 对生态环境监测数据进行实时存储、计算。 中科惠软选型测试后果点击案例查看更多技术细节 昆岳互联 x TDengine“利用 TDengine 后，在进行每分钟的均匀量进行实时计算时，咱们只须要简略的定义工夫窗口和滑动增量，数据库就能返回每分钟的均匀量；在解决实时监测、预警的指标上，能够专门为这类数据建设流计算，并将计算结果写入新的表（如下strm_pt_0304）中存储，这样整个实时计算的后果也能够做历史回顾。本来很多须要在程序中解决的数值计算，当初齐全都由 TDengine 承当，不仅分担了程序的计算压力，更重要的是聚合后果能够主动长久化存储，反对历史数据即时回看。”业务背景 昆岳互联的“a 环保”APP 基于自主打造的环保产业互联网平台（INECO 平台），对环境基础设施海量数据实时处理与剖析，能够秒级实时采集工业大气环保各项监控指标的数据，别离通过年、月、日三个维度，联合不同的采集频率周期，对采集到的海量数据进行剖析、展现。在进行数据库选型中，别离比照了阿里的时序数据库 TSDB、传统的 MySQL 以及 TDengine 后，最终 TDengine 凭借着高效的性能和独特的设计思路怀才不遇。架构图点击案例查看更多技术细节 广东环境迷信研究院 x TDengine“咱们的一张超级表中存储了 76.5 亿条数据（四张超级表总共 160 亿条数据），扩散在 19,419 张子表中，均匀每张表 39 万行。因为 TDengine 超级表个性，再加上列式存储和超高的压缩能力，这些数据仅占用了 240GB 内存，不仅帮忙咱们节俭了大量的存储空间，也为数据查问性能打下了良好的根底：对于 76 亿行的超级表，分组 TOP 查问仅用了 0.2 秒；基于 TDengine 返回 2,968 行，仅用了 0.06 秒。”业务背景为解决国内环境质量治理、污染源监管和数字政府等生态环境数据的管理工作，广东迷信研究院创立了生态环境数据治理服务项目，帮忙企业买通所有相干的业务信息系统、建设数据仓库。与个别的数据存储要求不同，该我的项目感知层的存储计划对数据读写频度和低延时要求更高，同时因为数据量极大，还须要更高的存储效率，此前采纳关系型数据库进行数据存储，最多只能保留 3-5 天的数据，不得不按天删除旧数据。之后思考过采纳 PostgreSQL 的 TimescaleDB 扩大，但却不满足政务信息化自主可控的要求。在通过很长一段时间的钻研和测试后，TDengine 被胜利利用。 ...

S3File 是一个用于治理 Amazon S3（Simple Storage Service）的 Python 模块。以后，Apache SeaTunnel 曾经反对 S3File Sink Connector，为了更好地应用这个 Connector，有必要看一下这篇应用文档指南。 形容将数据输入到 AWS S3 文件系统。 提醒： 如果您应用的是 Spark/Flink，在应用此连接器之前，必须确保您的 Spark/Flink 集群曾经集成了 Hadoop。Hadoop 2.x 版本已通过测试。 如果您应用的是 SeaTunnel Engine，它会在您下载和装置 SeaTunnel Engine 时主动集成 Hadoop JAR 包。您能够在 ${SEATUNNEL_HOME}/lib 目录下确认这个 JAR 包是否存在。 次要个性[x] 仅一次语义默认状况下，咱们应用 2PC 提交来确保 "仅一次语义"。 [x] 文件格式类型 [x] 文本 (text)[x] CSV[x] Parquet[x] ORC[x] JSON[x] Excel选项名称类型必须默认值备注pathstring是- bucketstring是- fs.s3a.endpointstring是- fs.s3a.aws.credentials.providerstring是com.amazonaws.auth.InstanceProfileCredentialsProvider access_keystring否-仅在 fs.s3a.aws.credentials.provider = org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider 时应用access_secretstring否-仅在 fs.s3a.aws.credentials.provider = org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider 时应用custom_filenameboolean否false是否须要自定义文件名file_name_expressionstring否"${transactionId}"仅在 custom_filename 为 true 时应用filename_time_formatstring否"yyyy.MM.dd"仅在 custom_filename 为 true 时应用file_format_typestring否"csv" field_delimiterstring否'\001'仅在 file_format 为 text 时应用row_delimiterstring否"\n"仅在 file_format 为 text 时应用have_partitionboolean否false是否须要解决分区partition_byarray否-仅在 have_partition 为 true 时应用partition_dir_expressionstring否"${k0}=${v0}/${k1}=${v1}/.../${kn}=${vn}/"仅在 have_partition 为 true 时应用is_partition_field_write_in_fileboolean否false仅在 have_partition 为 true 时应用sink_columnsarray否 当此参数为空时，将写入所有从 "Transform" 或 "Source" 获取的字段is_enable_transactionboolean否true batch_sizeint否1000000 compress_codecstring否none common-optionsobject否- max_rows_in_memoryint否-仅在 file_format 为 Excel 时应用sheet_namestring否Sheet${Random number}仅在 file_format 为 Excel 时应用path [string]目标目录门路是必须的。 ...

景象最近收到一个慢sql工单,慢sql大略是这样：“select xxx from tabel where type = 1”。 咦，type字段明明有索引啊，为啥是慢sql呢？ 起因通过执行explain，发现实际上数据库执行了全表扫描，从而被零碎断定为慢sql。这时有肯定开发教训的共事会说：“字段区分度不够，这种字段作独自索引是没有意义的”。那么为什么会产生索引生效这种状况呢？索引生效都有哪些状况呢？ 索引生效概括上面总结了若干索引生效的状况： 不满足最左匹配如果表中有个组合索引，idx\_start\_org\_code\_start\_province\_id\_trans\_type,它的索引程序如下： start\_org\_code, start\_province\_id, trans_type 当咱们从第二个索引字段开始查问时就不会走索引： 因为索引是BTree构造的，不能跳过第一个索引间接走第二个索引 索引列上有计算当咱们用主键做条件时，走索引了： 而当id列下面有计算，比方： 能够看到走了全表扫描 索引列上有函数有时候咱们在某条sql语句的查问条件中，须要应用函数，比方：截取某个字段的长度： 你有没有发现，在应用该函数之后，该sql语句居然走了全表扫描，索引生效了 字段类型不同在sql语句中因为字段类型不同，而导致索引生效的问题，很容易遇到，可能是咱们日常工作中最容易疏忽的问题。 到底怎么回事呢？ 咱们看下表里的start\_org\_code字段，它是varchar字符类型的 在sql语句查问数据时，查问条件咱们能够写成这样： 从上图中看到，该字段走了索引 但如果在写sql时，不小心把引号丢了： 咦，该sql语句竟然变成全表扫描了，为什么索引生效了？ 答：因为这个索引列是varchar类型，而传参的类型是int，mysql在比拟两种不同类型的字段时会尝试把这两个转化为同一种类型，再进行比拟。这样就能够了解为在字段上加了函数，依据下面剖析，索引列加了函数会索引生效。 比拟有意思的是，如果int类型的id字段，在查问时加了引号条件，却还能够走索引： 从图中看出该sql语句的确走了索引。int类型的参数，不论在查问时加没加引号，都能走索引。 这还迷信吗？有没有王法了？ 答：MySQL发现如果是int类型字段作为查问条件时，它会主动将该字段的传参进行隐式转换，把字符串转换成int类型。 MySQL会把下面列子中的字符串12348，转换成数字12348，所以依然能走索引。 事实上，索引列上对字段做任何操作都会导致索引生效，因为mysq认为任何计算或者函数都会扭转索引的实际效果，如果持续应用索引可能会造成后果不精确。 like右边蕴含%这个置信有点编程教训的同学都晓得,这里就不举例说明了。然而为什么索引会生效呢？ 答：其实很好了解，索引就像字典中的目录。个别目录是按字母或者拼音从小到大，从左到右排序，是有程序的。 咱们在查目录时，通常会先从右边第一个字母进行匹对，如果雷同，再匹对右边第二个字母，如果再雷同匹对其余的字母，以此类推。 通过这种形式咱们能疾速锁定一个具体的目录，或者放大目录的范畴。 但如果你硬要跟目录的设计反着来，先从字典目录左边匹配第一个字母，这画面你能够自行脑补一下，你眼中可能只剩下失望了，哈哈 列比照如果咱们当初有这样一个需要：过滤出表中某两列值雷同的记录。例如： 索引生效了吧？惊不惊喜？ 答：表里create\_time和update\_time都建了索引，独自查问某一字段时都会走索引。但如果把两个独自建了索引的列，用来做列比照时索引会生效。这其实和在索引列上加函数一个原理，MySQL认为索引无奈满足需要。 or和in和exist和not in和not exist这几个有殊途同归之处，就放一起说了。这里就不像下面几种状况100%不走索引了，而是有时候会走索引，有时候不走索引。到底走不走？成本计算说了算。 成本计算查问优化器是 MySQL 的外围子系统之一，成本计算又是查问优化器的外围逻辑。 全表扫描老本作为参照物，用于和表的其它拜访形式的老本做比照。任何一种拜访形式，只有老本超过了全表扫描老本，就不会被应用。 基于全表扫描老本的重要位置，要讲清楚 MySQL 的成本计算逻辑，从全表扫描成本计算开始是个不错的抉择。 全表扫描成本计算定义咱们先来看一下Mysql源码里成本计算的定义： class Cost_estimate { private: // cost of I/O operations double io_cost; // cost of CPU operations double cpu_cost; // cost of remote operations double import_cost; // memory used (bytes) double mem_cost; ......}从下面代码能够看到，MySQL 成本计算模型定义了四种老本： ...

置信对于“古代数据堆栈（Modern Data Stack）”这个名词，大家早已不生疏。但若问及其真正含意，往往又很难疾速、精确地说明。 事实上，对于咱们的团队组织而言，吃透并灵便利用“古代数据栈”所能带来的价值与收益，将会是深远且合乎发展趋势的。 Q1：什么是古代数据堆栈？ 古代数据堆栈的风行随同着云计算和云数据仓库的崛起，实质上是各种软件工具的组合，用于在一个齐全集成的基于云的数据平台上收集、解决和存储数据。因为在稳定性、速度和可扩展性方面的突出表现，其在数据处理方面劣势显著。 典型的古代数据堆栈通常蕴含： 抽取、转换、加载（ETL）工具数据获取/集成服务数据仓库数据编排工具商业智能（BI）平台这些工具用于治理大数据，即无奈通过传统形式解决的大型或简单数据。它们将整个数字化建设过程拆分成了各个模块，让企业可能从眼下的问题登程，依据业务需要进行选型再组合，而不是像过来那样，一口气建设一个大一统的数据平台或数据中台。 Q2：古代数据堆栈具备哪些差别与劣势？进步可扩展性：借助古代数据栈，能够更轻松地依据理论场景进行扩大或放大。堆栈中的各种工具能够一起应用，也能够独自应用，具体取决于本身需要。云的弹性能力可帮忙组织按需应用所需的计算资源来执行重要的数据工作。当作业实现后，资源能够复原到失常状态，从而最大限度地升高计算成本。进步灵活性：古代数据堆栈也比传统数据堆栈更灵便。反对通过不同形式应用各种工具，以满足特定需要。数据堆栈中的服务能够依据须要增加或删除。这里的许多服务都采纳基于生产的定价模式，这使得公司在开始迁徙到云时无需事后承当微小的软件洽购费用。也无效防止了数据资产受限于特定供应商的情况。提高效率：比传统数据堆栈更高效。堆栈中的工具在设计之初就对在云平台上协同工作更加敌对，这有助于节省时间和资源。在云计算的反对下，更多的数据业余人员取得了拜访数据的权限，例如：数据分析师能够应用 Tableau 等 BI 工具，数据科学家能够应用 Dataiku 等数据迷信工具实现对数据仓库的拜访。更好的数据文化：古代数据堆栈有助于在组织内创立更好的“数据文化”。各种工具的设计都思考到了可用性，因此无论员工的技术特长如何，都能更轻松地拜访和应用数据。此外，古代数据堆栈的灵活性意味着组织成员不再受限于应用特定工具，能够自由选择最合乎需要的。在良好的数据文化中，成员们能够通过搜寻和发现为即时决策找到相干数据；晋升数据素养，点亮解释和剖析数据并得出正当论断的能力。从久远来看，古代数据栈还可能推动数据治理，减速落实数据工作流中某些类型数据的管理条例，当数据失去适当治理，成员们便可能以正确的形式应用正确的数据。Q3：哪些人能够采纳古代数据堆栈？随着对数据“利用”以及数字化建设贯彻落实的要求越来越高，越来越多的企业，不管规模大小，都开始面临数据资产盘活的压力，并将最终受害于古代数据堆栈。 具体来讲，如果你的组织有数据需要，且围绕数据采集到数据分析、利用全流程各个环节设置了多种职能的团队，那么古代数据堆栈就是你的不二之选，因为它恰好能够很好地促成合作。 古代数据堆栈能够简化 IT 瓶颈，放慢须要数据的各个团队的访问速度，包含 数据分析师业务分析师数据科学家软件工程师网站开发人员数字分析师云计算工程师数据工程师企业领导者……基本上，任何心愿改善其数据管理的公司都能够采纳古代数据堆栈。 如果想要现代化你的数据堆栈，有几点须要留神：首先，须要确定你须要哪些服务和工具，以及它们将如何协同工作；其次，须要找到一个可能反对你的古代数据堆栈的数据平台；再次，须要思考如何将数据从传统零碎迁徙到新的古代数据堆栈；最初，须要培训团队如何应用古代数据栈中的新工具和服务。 尽管这看起来有肯定的工作量，但数据堆栈现代化无疑是改善公司数据管理的好办法，其性价比和回报率都很可观。 Q4：如何构建一个古代数据堆栈？构建一个古代数据堆栈并不像听起来那么简单。只有了解了其中的组合逻辑，就会非常简单。上面让咱们一步一步拆解来看： ① 抉择一个数据仓库市面上有许多数据仓库可供选择，须要咱们基于本身理论充沛调研。 这里能够宽泛地分为两种类型：本地数据仓库和基于云的数据仓库。前者装置在公司的服务器上；后者则托管在云上，能够从任何中央拜访。 劣势上，云数据通常更便宜且更容易设置；本地数仓可能提供更多对数据的管制。大多数状况下，咱们将抉择云数仓合作伙伴作为古代数据堆栈的一部分。当然，受监管行业（如医疗保健或银行业）中的一些公司很多时候仍须要利用本地数据存储来恪守合规性规定。 ② 抉择一个数据采集工具并连贯你的数据源当初咱们曾经有了一个数据仓库，上面则须要将数据导入其中。最好的办法是应用数据采集工具，应用数据连接器或 API 的形式连贯到咱们的数据源连贯到它。像是 Tapdata，就内置了大量连接器用于连贯各种类型的数据源。 ③ 抉择一个数据转换工具荡涤并筹备数据一旦数据导入了数据仓库，上面就须要通过荡涤加工，将原始数据转换为有用的信息，以便进行剖析。 ④ 抉择一个数据迷信工具并进行数据分析数据筹备好之后，就能够开始进行数据分析了。数据迷信工具能够帮忙剖析数据并生成见解。这些工具提供了各种数据分析和建模性能，能够帮忙咱们了解咱们的数据。 ⑤ 抉择一个 BI 工具并可视化你的数据最初，咱们能够应用 BI 工具来实现数据可视化。一些风行的的 BI 工具能够帮忙咱们创立仪表盘、图表和报告，以便咱们的团队更容易地了解数据。 综上所述，古代数据堆栈中蕴含着弱小的能量，能够帮忙企业做出更好的数据驱动决策。将来，咱们能够期待从中看到更多翻新。诚然，建设一个古代数据堆栈确实须要一些后期调研等工作，但一旦建设起来，将大大提高企业数据管理和剖析的能力。不同的组织会依据其具体需要抉择不同的工具和技术，而理解如何构建一个古代数据堆栈便是至关重要的第一步。 为了帮忙更多团队入门并相熟古代数据栈的方法论和实际，更深刻地理解古代数据栈的劣势和利用，同时也为大家的数据管理和剖析工作提供一些启发。作为古代数据栈工具组合中的优良代表，Tapdata 开源社区联结 MongoDB 开源社区以及 Doris 开源社区，发动古代数据栈主题系列 Meetup，会集了业内当先的专家和翻新技术，为大家带来多种古代数据栈工具的性能个性详解以及各工具组合利用的最佳实际剖析等内容。 目前，咱们的 Meetup 北京首站已上线，如果你想获取更多无关数据基础设施建设、古代数据栈搭建指南的干货，欢送报名参加： Modern Data Stack Meetup · 北京站流动详情：日期：2023年9月24日（周日）工夫：14:00-17:00地点：北京市阿里核心 · 望京A座-望京A座-20F-03 万松书院主办方： Tapdata 开源社区MongoDB 开源社区Doris 开源社区特地反对：阿里云嘉宾与议题： ...

小 T 导读：只管时序数据处理的特点是以写操作为主，读操作为辅，但查问需要也不容忽视。为不便用户上手，时序数据库（Time Series Database）TDengine 采纳 SQL 作为查询语言，次要查问性能包含单列及多列数据查问、数值列及聚合后果的四则运算、工夫戳对齐的连贯查问操作等，本文将就局部查问细则做剖析。 在《查问性能：TDengine 最高达到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍》中，咱们理解到了 TDengine 在查问方面展现出的具体实力。但想要更好地施展出 TDengine 的查问性能，在实际操作上，也还有一些事项须要留神，局部内容汇总如下： TDengine SQL 查问语句能够指定局部或全部列作为返回后果。数据列和标签列都能够呈现在列表中。 通配符和标签列通配符 * 能够用于代指全部列。对于一般表和子表，后果中只有一般列。对于超级表，还蕴含了 Tag 列。 SELECT * FROM d1001;通配符反对表名前缀，以下两个 SQL 语句均为返回全副的列： SELECT * FROM d1001;SELECT d1001.* FROM d1001;在 JOIN 查问中，带表名前缀的和不带前缀返回的后果有差异， *返回全副表的所有列数据（不蕴含标签），而带表名前缀的通配符，则只返回该表的列数据。 SELECT * FROM d1001, d1003 WHERE d1001.ts=d1003.ts;SELECT d1001.* FROM d1001,d1003 WHERE d1001.ts = d1003.ts;下面的查问语句中，前者返回 d1001 和 d1003 的全部列，而后者仅返回 d1001 的全部列。 在应用 SQL 函数来进行查问的过程中，局部 SQL 函数反对通配符操作。其中的区别在于： count(*)函数只返回一列。first、last、last_row函数则是返回全部列。 ...

IP地址是互联网上设施的惟一标识符，它们在网络通信和连贯时起到至关重要的作用。然而，歹意用户可能会试图盗用您的IP地址，导致平安和隐衷问题。为了爱护您的IP地址免受盗用，以下是一些无效的办法和最佳实际。 应用防火墙和安全策略配置和保护防火墙是爱护IP地址的第一道防线。确保只有受权用户和设施可能拜访您的网络和资源。应用网络防火墙规定来限度拜访，只容许来自可信赖起源的流量。 启用网络身份验证要避免未经受权的拜访，施行强制的身份验证机制。这包含应用双因素身份验证（2FA）或多因素身份验证（MFA）来确保只有受权用户可能拜访网络资源。 更新和治理明码定期更改明码是一种简略但无效的办法，能够防止歹意用户获取IP地址的拜访权限。确保明码复杂性强，包含数字、字母、特殊字符，并不要共享明码或应用弱明码。应用VPN技术虚构专用网络（VPN）是一种加密通信的形式，可帮忙爱护IP地址免受中间人攻打。通过应用VPN，您的数据在传输过程中失去加密，使攻击者无奈轻松窃取您的IP地址。确保网络设备的安全性保护和更新网络设备（如路由器和交换机）的固件和软件十分重要。安全漏洞可能会被黑客利用来获取对网络和IP地址的拜访权。及时利用安全补丁和更新是要害。监控网络流量施行网络流量监控和日志记录，以便检测任何异样流动。当发现异常登录尝试或大量的流量时，您能够迅速采取措施来阻止潜在的攻打。 应用IP地址管理工具应用业余的IP地址管理工具，以跟踪和治理您的IP地址调配。这些工具能够帮忙您及时发现和应答IP地址的异样应用，以及保护精确的IP地址清单。 培训员工为员工提供网络安全培训，教育他们无关明码平安、网络安全最佳实际以及如何警觉社会工程攻打。员工的网络安全意识对于爱护IP地址十分重要。 理解社交工程攻打社交工程攻击者可能会试图通过坑骗或伪装成非法用户来获取IP地址。要学会辨认此类攻打，不要随便分享敏感信息。恪守法规和合规要求确保您的网络和IP地址治理恪守实用的法规和合规要求，特地是在解决敏感数据时。合规性有助于爱护您的IP地址和网络不受法律危险。爱护IP地址免受盗用是网络安全的根底之一。通过采取上述办法和最佳实际，您能够增强网络安全，升高IP地址被盗用的危险，从而确保您的数据和隐衷失去无效爱护。定期审查和更新安全措施以适应一直演变的威逼也是十分重要的。

2021 年 9 月 8 日，StarRocks 开源社区诞生。从第一天开始，咱们怀揣着“打造世界一流的数据分析产品”的幻想，踏上了星辰大海的征途。两年间，StarRocks 在 GitHub 上播种了 5.4K Stars，产品共迭代公布了 90 余个版本，288 家市值超过 10 亿美元的头部用户在生产环境中上线运行。“不止步于极速”，StarRocks 更是在短短一年内实现了从全场景 OLAP 剖析进化到云原生湖仓剖析的进化。 StarRocks 突飞猛进的倒退都要得力于社区用户的应用反馈和开发者们一直地帮 StarRocks 添砖加瓦，使其生态体系更加欠缺。在过来一年内，StarRocks 公布了 v2.5、v3.0、v3.1 三个重大的里程碑版本，其中存算拆散、湖仓剖析、物化视图等重量级个性， 为极速对立湖仓剖析新范式的落地奠定了坚实基础。 进化，永不止步从诞生之初，StarRocks 就一直在摸索对于“极速对立”之道。全面向量化引擎、CBO 查问优化器、实时更新数据模型、Pipeline 执行引擎相继公布，将 OLAP 剖析性能晋升到了新的高度，也引领了以后大数据分析的发展趋势。随着各项重要性能历经 2 年、近 300 家各行业头部用户在生产环境中的打磨与欠缺，StarRocks 实现从 OLAP 到云原生湖仓的疾速进化，通过湖仓一体让企业能基于一份数据，满足 BI 报表、多维分析、Ad-hoc 查问、实时剖析等不同场景的数据分析需要， StarRocks 往 "One data，all analytics" 的指标一直前行。 湖仓一体化极速查问引擎Presto/Trino/Impala 始终以来都是行业最好的数据湖（Hive/Hudi/Iceberg/Deltalake 等）查问引擎。然而其性能无奈和将数据导入到 ClickHouse 或是 StarRocks 此类极速 OLAP 数据库/数仓相媲美，用户通常会组合应用，运维和应用都会比较复杂，StarRocks 冀望彻底改变这种“组合”模式，推出更一体化的计划。StarRocks 的湖仓一体化极速查问引擎的理念是能够同时极速查问数据湖数据和 StarRocks 本地数据。从 StarRocks 2.0 到 StarRocks 3.0 版本， 通过一年半的工夫和 7 个大版本的继续打磨，StarRocks 终于公布了业内第一个成熟欠缺的湖仓一体化极速查问引擎，让数据湖查问和本地数据查问根本持平，并且数据湖查问达到了 Presto/Trino/Impala 等零碎的 3-6 倍以上的性能程度。 ...

前言ProxySQLProxySQL 是基于 MySQL 的一款开源的中间件的产品，是一个灵便的 MySQL 代理层，能够实现读写拆散，反对 Query 路由性能，反对动静指定某个 SQL 进行缓存，反对动静加载（无需重启 ProxySQL 服务），故障切换和一些 SQL 的过滤性能。 GreatSQL MGRGreatSQL是实用于金融级利用的国内自主开源数据库，具备高性能、高牢靠、高易用性、高平安等多个外围个性，能够作为MySQL或Percona Server的可选替换，用于线上生产环境，且完全免费并兼容MySQL或Percona Server。 GreatSQL在高牢靠方面的次要晋升是针对MGR做了大量的改良和晋升工作，进一步晋升MGR的高牢靠等级。包含但不限于以下晋升： 天文标签，晋升多机房架构数据可靠性。读写节点动静VIP，高可用切换更便捷。仲裁节点，用更低的服务器老本实现更高可用。疾速单主模式，在单主模式下更快，性能更高。智能选主，高可用切换选主机制更正当。全新流控算法，使得事务更安稳，防止激烈抖动。优化了节点退出、退出时可能导致性能激烈抖动的问题。解决磁盘空间爆满时导致MGR集群阻塞的问题。解决了长事务造成无奈选主的问题。优化事务认证队列清理算法，躲避每60s抖动问题。修复了recover过程中长时间期待的问题。理解更多详细信息能够返回➥https://gitee.com/GreatSQL/GreatSQL-Manual/blob/master/5-enha...部署环境介绍部署架构图 GreatSQL MGR集群实现数据库复制性能及高可用。Proxysql对应用程序提供拜访，对MGR集群进行读写拆散，集群状态检测，实现故障切换。 部署环境配置部署软件详情软件名版本号GreatSQL8.0.32-24ProxySQL2.5.4-58部署环境筹备本次采纳的是单机多实例的部署形式，如何部署单机多实例能够返回➥https://gitee.com/GreatSQL/GreatSQL-Manual/blob/master/6-oper... IP端口角色172.17.139.773306MGR01172.17.139.773307MGR02172.17.139.776032、6033ProxySQL$ cat /etc/system-releaseRed Hat Enterprise Linux Server release 7.9 (Maipo)$ uname -aLinux gip 3.10.0-1160.el7.x86_64 #1 SMP Tue Aug 18 14:50:17 EDT 2020 x86_64 x86_64 x86_64 GNU/LinuxGreatSQL配置#mgr settingsloose-plugin_load_add = 'mysql_clone.so'loose-plugin_load_add = 'group_replication.so'loose-group_replication_group_name = "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1"loose-group_replication_group_seeds = '172.17.139.77:33061,172.17.139.77:33071'loose-group_replication_start_on_boot = ONloose-group_replication_bootstrap_group = OFFloose-group_replication_exit_state_action = READ_ONLYloose-group_replication_flow_control_mode = "DISABLED"loose-group_replication_single_primary_mode = ONloose-group_replication_communication_max_message_size = 10Mloose-group_replication_transaction_size_limit = 3Gloose-group_replication_arbitrator = 0loose-group_replication_single_primary_fast_mode = 0loose-group_replication_request_time_threshold = 20000report_host = "172.17.139.77"MGR01节点配置如下 ...

IP（Internet Protocol）地址是互联网上的设施标识，通过辨认IP地址的归属地信息，能够帮忙咱们进行网络管理、安全监控、市场定位等多种利用。本文将介绍一些高效辨认IP归属地信息的办法与工具，帮忙您更好地利用这些信息。办法一：应用在线IP查问工具许多在线工具和网站能够帮忙您查找IP地址的归属地信息。这些工具通常提供简略、疾速的查问，无需装置任何软件。以下是一些罕用的在线IP查问工具： IP查问网站：诸如https://www.ip66.net/?utm-source=Lik&utm-keyword=?1124等网站，只需输出IP地址，即可获取相干的信息，包含国家、城市、经纬度等。批量查问工具：如果您须要一次性查问多个IP地址，能够应用一些批量查问工具，例如api.ipdatacloud.com/v2/query?ip= 的批量查问接口。这些工具通常反对导入IP地址列表，而后一次性获取归属地信息。API服务：许多提供IP信息的网站也提供API服务，这使得您能够通过编程形式集成IP查问性能到本人的应用程序中，以实现自动化的IP信息获取。办法二：应用业余的IP地理位置数据库如果您须要更高级的IP归属地信息，例如更具体的地理坐标、ASN（自治零碎号码）、ISP（互联网服务提供商）等信息，能够思考应用业余的IP地理位置数据库。这些数据库通常蕴含大量的IP地址信息，供您进行高级查问和剖析。办法三：自建IP数据库如果您有大量的IP地址须要解决，或者须要更高级的自定义性能，能够思考自建IP数据库。这须要肯定的技术和资源投入，但能够提供更大的灵活性和性能。数据收集：收集IP地址和相应的归属地信息可能须要应用网络爬虫或从第三方提供商购买数据。确保数据的准确性和及时性十分重要。数据库设计：抉择适当的数据库引擎，如IP数据云数据库，而后设计数据库表构造以存储IP信息。数据导入：将收集到的IP数据导入数据库中，确保数据可能高效地被查问。更新和保护：IP数据会一直变动，所以须要建设更新机制来保持数据的准确性。办法四：联合多种办法通常，为了进步准确性，能够联合多种办法。例如，您能够首先应用在线IP查问工具进行疾速查问，而后在须要更详细信息时，再应用业余的IP地理位置数据库或自建数据库进行查问。在高效辨认IP归属地信息时，要确保爱护隐衷和恪守法规，不要滥用这些信息。只有在非法合规的状况下应用IP归属地信息，以确保网络的平安和隐衷。总之，辨认IP归属地信息是网络管理和安全监控中的重要一环。通过抉择适合的办法和工具，您能够高效地获取这些信息，帮忙您更好地治理和爱护网络资源。

各位的社区小伙伴们大家好，咱们很快乐的发表，ByConity 0.2.0 版本正式公布了，这个版本提供多项有用的新个性，同时修复了若干已知的问题，进一步晋升了零碎的性能和稳定性。 重要新个性： 冷读优化，包含 IOScheduler 和 Preload 能力数据湖反对，包含 Hive，Hudi，Multi-Catalog 等反对ELT 长时工作反对，包含异步执行，队列，算子 Spill 等RBAC欢送大家应用体验，期待听到大家的反馈和倡议。https://github.com/ByConity/ByConity/releases 冷读优化因为 ByConity 的存算拆散架构，对远端存储的冷读相比本地磁盘有肯定的性能差距，在 0.2.0 版本专门针对冷读进行了性能优化，次要伎俩有：IOScheduler为了缩小单个申请端到端的耗时，晋升节点的吞吐，同时升高肯定工夫范畴外的查问的数量。咱们引入 IOScheduler 对远端数据进行读取，能达到如下指标： 缩小 IO 申请的数量并升高节点带宽的应用；在慢 IO 比例肯定的状况下，缩小 IO 数量能缩小查问受到慢 IO 影响的可能性；对大 IO 的切分与并行执行，缩小大 IO 的耗时；反对 Prefetch 容许将数据预取回来，缩小查问端到端的耗时；对 S3 的冷读相比于上一个版本有 3 倍的晋升。Preload反对被动将远端存储数据预拉取到 Disk Cache 中。反对：主动 Preload：当表产生 insert、merge 后会主动把更新后的数据拉取到本地，可通过配置项开启；手动 Preload：应用 ALTER 语句手动 Preload 特定范畴的数据。数据湖反对 Hive 表引擎从 0.2.0 版本开始，ByConity 能够通过建设表面的模式拜访 Hive 数据，创立 Hive 表面时， ByConity 会获取并解析 Hive table 元数据，主动推断表的构造（列名，类型，分区），并通过 Hive 引擎读取 Parquet 以及 ORC 格局的 Hive 数据，同时反对将 Hive 的统计信息集成到 ByConity 的优化器。该版本同时反对 HDFS 和 S3 存储。 ...

鸿鹄展翅凌云志，骏马扬蹄踏雪心。 2023年9月的 墨天轮中国数据库风行度排行 炽热出炉，本月共有287个数据库参加排名。本月排行榜前十中，OceanBase 间断10个月稳居榜首，头部产品得分差距日益放大，阿里华为两大云厂商继续发力正在“弯道超车”。 本月排行榜次要出现以下几个特点： 国产金融级分布式数据库热度回升，金融行业国产化正在减速代替中。例如：华为云 GaussDB、中兴 GoldenDB、科蓝软件 SUNDB、万里数据库等。数据仓库产品排名有所回升，企业更加重视以经济的形式开掘数据价值。例如：Doris、鼎石 StarRocks、阿里云 Hologres、飞轮科技 SelectDB 等。图数据库细分赛道炽热，人工智能技术给图数据库带来新的增长点。例如：TuGraph、星环科技 StellarDB、腾讯云数图 TGDB 等。本月排行榜解读文章 「专家观点」 板块邀请到某央企数据库专家，Oracle ACE（Alumni)，2019年墨天轮数据库技术社区十大突出贡献人物 梁策 解读本期排行榜。 图1：2023年9月排行榜TOP10得分详情表 一、群雄并起竞前十中国数据库行业头部竞争日益强烈，尤其是本月排行榜第三名 TiDB 与华为云 GaussDB 之间的分差仅有1.29分，各家厂商纷纷锻造策略利器。依据国资委下发的79号文件，政策要求到2027年央企国企100%实现信创代替，替换范畴涵盖芯片、根底软件、操作系统、中间件等畛域。这意味着国产数据库将进入决战期，输赢即见分晓。接下来具体看看排行榜前十名的倒退态势。 OceanBase 仍以王者之势雄踞墨天轮榜首，本月得分634.8分，新增4篇论文。 其作为一款金融级分布式数据库，全国已有1/4的头部金融客户将其作为外围系统升级首选。上月，OceanBase 中标中原银行2023年信息技术利用翻新我的项目，并开源生态工具 ODC，极大地巩固了其在榜单上的劣势位置。荣登墨天轮榜眼的阿里云 PolarDB，本月排名较上月回升两位，得分584.69分。 在多云的趋势下，PolarDB 风行度水涨船高。开源的 PolarDB 吸引了越来越多使用者试用尝鲜，其逐步欠缺培训认证体系，不断丰富文档内容，以不同的模式扩充影响力。TiDB 本月被反超，以566.14分位列榜单第3。 其作为一款开源的分布式数据库，近年来在产品迭代、社区建设、生态工具等方面齐头并进。TiDB 正在为 3000 多家不同行业的当先企业提供服务。因为其近日在宣发上放弃低调，产品热度有所降落。华为云 GaussDB 本月排名较上月回升1位至第4，在金融场景扩张领地。 GaussDB 已在华为外部 IT 零碎和多个行业外围业务零碎失去利用。历经20多年的技术积攒，GaussDB 已实现600多套数据库的全面替换；在华为终端云，已建设6000多个分布式数据库节点，目前曾经承载高达6个PB数据。openGauss 本月得分519.31分，较上月排名降落两位，排名第5。 openGauss是一款开源的关系型数据库系统，提供面向多核架构的极致性能、全链路的业务、数据安全、基于 AI 的调优和高效运维的能力。第六届 openGauss 技术文章征集流动圆满结束，丰盛了 openGauss 主题的相干内容。达梦间断3个月位居榜单第6，本月得分432.71分。 达梦数据库为中国联通包含沃告诉零碎等在内的多个信息管理系统提供数据库服务反对，为中国联通超20万员工的数字化办公提供全面撑持。其在政府端具备先发性劣势，目前已广泛应用于金融、能源、交通、政法、电信、政企、央企等畛域。人大金仓本月凭借深厚的积攒维持上个月排名，以422.44分位列榜单第7，新增21篇论文。 其在多地打造标杆案例，热度始终比较稳定。近日，人大金仓助力某大型金融机构应收账款融资服务平台异地容灾我的项目顺利上线，保障了平台零碎运行的连续性和数据安全，为充分发挥平台的融资性能，缓解中小微企业融资难提供了强有力的保障。GBase南大通用间断4个月位列榜单第8，本月得分366.41分。 近日，GBase南大通用市场捷报频传：中国移动内蒙古公司“2023年GBASE数据库维保服务项目”、中国移动上海公司“2023-25年GBASE详单云软件维护服务项目”、河北联通“2023年数字化业余原厂维保我的项目”、福建省农信社“GBase数据库信创革新服务洽购我的项目”。将来，GBase南大通用将会进一步开疆拓土。腾讯云TDSQL 2023年在墨天轮的排名始终在第8-9名彷徨，本月以323.51分位列第9，维持着上个月排名。 其在技术上一直精进，TDSQL-C Serverless 架构降级，翻新推出可开释存储架构，截至目前，TDSQL-C 已助力好将来、富途、虎扑等企业升高应用老本。阿里云另一款产品 AnalyticDB 间断6个月蝉联榜单第十，本月得分202.8分。 近日，国内权威咨询机构 Forrester 公布最新云数据仓库钻研报告 《The Forrester Wave™: Cloud Data Warehouses, Q2 2023》，凭借产品性能和市场规模等方面的体现，阿里云间断第二次进入卓越表现者象限，是国内惟一挺进该象限的科技公司。二、千帆竞发勇者胜本月排行榜前40名中，拓数派 PieCloudDB，TGDB 争先恐后，进入这一赛段。此外，还有一些数据库产品深耕细作，体现亮眼。限于篇幅，小编仅在此筛选了局部数据库的得分和排名，一起来看看它们的最新动静。 图2：2023年9月排行榜优良数据库得分详情表 科蓝软件的 SUNDB 本月排名较上月晋升3位，排名第20名，与其重视生态建设非亲非故。SUNDB数据库是科蓝软件潜心二十余年自研的国产数据库品牌，研发团队保持从0到1的原始翻新，工信部评测外围源代码自研率为98.31%，已通过中国信通院“可信数据库”评测。目前，科蓝软件SUNDB已在中国移动、中国联通、中化化肥、多省市智慧城市、多家银行及非银金融机构、央企国企等外围业务零碎上线，为各行业数据库国产化代替建立了标杆。 ...

本文导读： 以后，大数据、人工智能、云计算等技术利用正在推动保险科技倒退，减速保险行业数字化过程。在这一背景下，招商信诺一直摸索如何将多元数据交融裁减，以赋能代理人把握更加详实的用户线索，并将智能剖析贯通业务全链路，实现对用户、产品、场景策略的全面洞察与闭环迭代。本文将具体介绍招商信诺在大数据根底建设方面的探索之旅，从最后为线报表、Ad-hoc 剖析提供服务的 OLAP 引擎，逐渐倒退至基于 Apache Doris 构建的对立实时数据仓库，通过一套架构实现各业务畛域的多元数据实时剖析与交融对立治理，最终实现保险一线业务降本增收的指标。 作者：招商信诺大数据平台研发团队 招商信诺人寿是由招商银行与信诺团体中外合资的寿险公司，为企业和集体提供涵盖保险保障、衰弱治理、财产布局等产品及服务。目前，招商信诺已累积服务客户超千万、实现理赔客户超百万，并凭借一站式便捷的衰弱治理服务、可灵便配置“定制化”的保险计划取得宽广用户的继续抉择与信赖。 面对寰球数据量爆炸性增长的趋势，数据的时效性与准确性对企业精细化经营越来越重要。咱们心愿通过数据可能疾速感知客户行为、定位客户问题、高效匹配用户所需的产品与服务，以达到精细化业务营销、拓宽可保边界等指标。 随着业务一直拓展、剖析场景逐步多元化，业务分析师的要求也变得更为简单，不仅要求数仓可能疾速开发数据报表，还须要实现流批一体、湖仓一体、多元化数据类型的对立剖析与治理。在大数据根底建设中，这些交融对立的个性变得至关重要。在这样的背景下，继续降级与改良数仓架构，从最后仅反对 BI 报表、数据大屏的一代架构到采纳多个零碎和组件提供数据服务的二代架构，再到现在新一代对立实时数据仓库 ，通过 Apache Doris 一套组件实现了架构的简化、技术栈的对立、数据的对立治理与剖析，不仅晋升了数据处理效率，并且满足了更多样化的数据分析需要。 本文将具体介绍招商信诺在数仓架构迭代与降级过程中如何基于 Apache Doris 对立存储、计算和查问进口、如何满足写入时效性的要求、如何在高并发点查与多表关联等场景下实现极速查问性能，为销售线索高效写入与查问、客户留存信息高频更新、服务场景数据统一买通等方面提供助力，进一步将客户线索转化为私域商机，赋予企业在经营、服务、营销等多方面的能力。 架构 1.0 ：多组件准实时数仓最后的业务需要是心愿通过数仓来承载面向 C 端用户的保单自助查问、面向业务剖析人员的多维分析报表以及面向管理者的实时数据大屏（Dashboard）三类业务场景。数仓须要满足业务数据的对立存储和高效的查问能力，以反对业务高效剖析决策，同时还须要反对数据回写，以实现闭环式业务经营。 保单自助查问：用户通过招商信诺 APP 依据保单 ID 自助查问承保合同，或者通过不同维度（如承保工夫、保险类别、理赔金额）进行自定义筛选查问，查看保单生命周期内的信息。多维报表剖析：根据业务需要，业务剖析人员通过开发明细数据、指标维度报表，取得对于保单在产品翻新、费率、反理赔欺诈等方面的业务洞察，并据此反对经营策略调整。数据大屏（Dashboard）：次要用于某银行渠道、某分公司的实时大屏，通过对指标等数据的对立汇总，将热门险种、每日销售额、保险品种缴纳总额与占比、历年保险缴纳涨幅趋势等信息展现于实时大屏中。业务初期对数据服务的要求较为繁多，次要是以晋升报表数据的时效性为主，因而在数仓搭建的过程中，咱们采纳典型的 Lambda 架构，通过实时与离线两条链路别离进行数据采集、计算与存储，其中数仓次要采纳宽表模型设计以反对对指标数据、明细数据的查问剖析。 由架构图能够看到，FlinkCDC 负责实时数据采集，咱们自研的 Hisen 工具（包含 Sqoop、DataX 以及 Python）负责离线数据采集。原始数据采集后，实时数据利用 Flink 进行计算、离线数据交由 Hive 进行批处理，最终导入至不同的 OLAP 组件（包含 Presto、Clickhouse、HBase 以及 MySQL）中，由 OLAP 向下层业务提供数据服务，其中各组件在架构中别离表演不同的角色： MySQL 依照业务需要，在数据实现计算后次要用于存储指标数据。目前，数仓表的数据量曾经冲破千万级， 而 MySQL 存储具备局限性，容易呈现执行工夫过长、零碎返回谬误等问题。 Clickhosue Clickhouse 在单表数据读取的性能上表现出色，在大表 Join 性能较弱。随着业务场景的减少，实时数据量一直叠加与更新下，Clickhouse 面对新的业务需要存在肯定局限： 为缩小指标反复计算，须要引入星型模型进行多表关联与高并发点查问，而 Clickhouse 无奈反对；当保单内容产生变更时，须要数据实时更新写入，而 Clickhouse 短少实时事务的反对，面对数据变更时须要从新生成宽表以笼罩旧数据，在数据更新时效性要求方面存在肯定有余；HBase ...

1.KaiwuDB 是什么？KaiwuDB 是由浪潮翻新研发的一款分布式、多模交融，反对原生 AI 的数据库产品，领有“就地计算”等核心技术，具备高速写入、极速查问、SQL 反对、随需压缩、智能预计算、订阅公布、集群部署等个性，具备稳固平安、高可用、易运维等特点。 2.KaiwuDB 设计理念在当今数据爆炸的时代，企业和组织面临着如何解决并用好海量数据的微小挑战。传统的数据处理形式难以满足激增的数据量及包含极致压缩、实时处理、高效剖析、数据价值开掘等在内的延长需要。 为助力用户应答这一微小挑战，KaiwuDB 以“快人一步”为设计理念，心愿提供一款真正“好用抗打”的数据库产品： 面对解决海量数据的挑战，利用就地计算实现对数据“快”速剖析查问；产品最终是服务于“人”，也就是咱们的用户。一款产品好不好，最终肯定是用户说了算；数据库只是利用环节中的一环，提供“一”站式整体解决方案，能力更好地解决用户业务难点；分“布”式不是一个可选项，而是一个必选项。► 就地计算，实现高性能读写传统的数据处理形式须要屡次数据转换，如果利用上没有大量的并发更新，例如时序数据，此种形式将会带来额定的性能开销。内存数据库虽可解决这个问题，但仍受内存大小的限度，无奈高效解决大量数据，并且在扩展性上也有问题。 正是基于这种现状，KaiwuDB 推出“就地计算”核心技术，通过该技术可能很好将磁盘和内存融为一体，突破传统数据库从磁盘读取数据到内存再进行解决的模式，间接在磁盘上进行计算，防止了数据的屡次转换和挪动。换言之，KaiwuDB 把计算推向数据，而不是把数据移向计算，这既进步了数据处理的效率，也防止因数据挪动而造成的性能损失。 KaiwuDB 可反对每秒 100 万记录入库操作；千万记录简单查问毫秒内可实现；20 亿记录数据摸索 1 秒内实现；500 万记录数据可实现 15 层下钻。上述能力都已在先前与用户的单干中失去验证。 ► 多模架构，实现“化繁为简”国内数据库市场多库利用场景越来越常见，但这种模式带来了泛滥应用问题：对于开发者，需要求其具备不同模型开发的最佳实际与扎实技术；对于 DBA，需清晰明确不同数据库的运维规定，开发运维老本高；此外，数据在不同库之间的传输和转换会波及多正本治理，数据在转换传输间容易出错，且在性能和一致性上也十分难以失去保障。 针对上述现状，KaiwuDB 通过“多模架构”，真正实现“化繁为简”： 多模数据库反对不同类型的数据在同一个数据库中对立存储、对立解决；对立的算子定义交融不同模型的计算引擎，便于引擎扩大；对立的通信协议（共享内存、gPRC）交融不同部署模型下的算子通信；多模 SQL 优化器/执行器反对多种粒度的算子（原子算子或者子打算）下推；模型的主动抉择和主动转换，始终以最高效的形式解决数据。 KaiwuDB 基于对立的 SQL 语法、对立的数据库命令、开发运维工具、平安认证等实现真正多模交融，高性能时序引擎、灵便部署机器学习引擎。依靠“就地计算”、"原生 AI”等核心技术反对时序数据、内存数据、关系型数据在同一数据库中对立汇存、解决及 AI 智能剖析，“一库多用”把本来复杂化的数据存储管理流程大大简化。 多模架构下，开发人员只需应答一款数据库，运维人员只需运维一个脚本，从多库到多模极大升高用户开发运维老本，真正实现“降本提效”。 3.KaiwuDB 外围性能（1）高性能写入依靠“就地计算”核心技术实现高性能读写，反对百万级，甚至千万级记录秒级写入；反对毫秒级精度数据写入； （2）实时查问与剖析反对数据实时剖析，千万笔数据聚合查问毫秒级响应，提供丰盛的函数反对能力； （3）多模数据反对时序型数据、关系型数据采、存、算、管；反对数据跨模剖析； （4）低成本存储10 -100 倍数据压缩；数据降采样存储；按“工夫热度” 进行数据生命周期治理； （5）流式计算反对多种物联网利用场景下流式计算性能；反对间断查问、数据订阅公布性能； （6）云边端一体化反对端侧轻量化部署；具备集群部署、数据同步、数据订阅等能力，撑持云边端一体化建设； （7）多重平安保障反对身份鉴权、权限治理、数据库审计；反对通信加密、数据加密；兼容支流芯片和操作系统； （8）高可用及灾备数据库层面的灾备和高可用能力建设；数据库自治等 AIOps 能力； （9）高兼容性兼容 PostgreSQL 数据类型、SQL 语法和协定；反对 HTTP 协定；提供 Restful API；反对 ODBC/JDBC 接口；提供多种编程语言接口。 4.写在最初从用户中来，到用户中去。KaiwuDB 将始终保持从用户本位登程，专一于打造一款基于多模架构“小而全”的数据库产品，给市场与用户带来更多的可能。

随着互联网的遍及，网络攻击变得越来越广泛和简单，对企业和集体的网络安全形成了重大威逼。其中，DDoS（分布式拒绝服务）攻打和CC（网络连接）攻打是两种常见且具备破坏性的攻打类型，它们能够对网络基础设施和在线业务造成重大侵害。为了抵挡这些攻打，IP危险查问变得至关重要。DDoS攻打简介：DDoS攻打旨在通过同时发送大量网络申请来超载指标服务器或网络，使其无奈失常工作。攻击者通常应用大量被感化的计算机（僵尸网络）来协同发动攻打，以减少攻打威力。CC攻打简介：CC攻打是一种通过继续发动大量的HTTP申请或连贯申请来占用服务器资源的攻打。攻击者通常应用自动化脚本或恶意软件来执行此类攻打，以减弱服务器的性能或使其无奈失常响应非法申请。IP危险查问的重要性：IP危险查问是辨认和阻止DDoS攻打和CC攻打的要害一步。以下是为什么IP危险查问如此重要的几个起因：1.攻击者IP辨认：通过查问IP地址，网络管理员能够确定与歹意流动相干的攻击者IP地址。这有助于将这些IP地址列入黑名单或采取其余阻止措施，以避免它们对网络造成更多威逼。 实时监控：IP危险查问工具能够提供实时监控，以便及早发现潜在的攻打。通过监测大量连贯申请或异样流量，管理员能够迅速采取行动来抵挡攻打。自动化进攻： 一些IP危险查问工具具备自动化进攻性能，能够依据当时定义的规定来主动阻止歹意IP地址的拜访。这有助于升高人工干预的需要，放慢应答攻打的速度。数据分析：查问IP地址还有助于进行数据分析，以辨认攻打的模式和趋势。这有助于网络管理员采取预防措施，以缩小将来的攻打危险。抉择适宜的IP危险查问工具：抉择适宜您需要的IP危险查问工具至关重要。这些工具的性能能够包含实时监控、攻击者IP地址辨认、流量剖析和自动化进攻等。确保您的抉择与您的网络环境和业务需要相匹配，以确保网络的安全性和可用性。在网络攻击一直增多的环境中，抵挡DDoS攻打和CC攻打是网络安全的要害挑战之一。通过应用IP危险查问工具，您能够及早发现攻打，辨认攻击者IP地址，采取自动化进攻措施，并分析攻击模式，从而进步网络的安全性和稳定性。投资于这种关键技术是确保您的网络和在线业务免受攻打威逼的重要一步。

理论开发中 sql 的高级用法并不罕用，特地是在做数据库迁徙时，高级用法几乎是噩梦 只满足于简略的查问，而后用代码实现相干逻辑，又感觉本人的 sql 能力太弱 通过 leetcode 中数据库相干的练习题，刷下题目，减少下本人的 sql 能力 leetcode 只提供了 MySQL 和 Oracle 两种数据库，我是用 MySQL 刷题的 上面两条题目： 第一题[简略]，次要考查 MySQL 的根本用法：比方正则应用，条件判断，如果判断偶数第二题[中等]，次要考查 MySQL 的高级用法：比方将一张表的统计后果去和另一张表的数据做匹配题目一题目链接：计算非凡奖金 编写解决方案，计算每个雇员的奖金。如果一个雇员的 id 是 奇数 并且他的名字不是以 'M' 结尾，那么他的奖金是他工资的 100% ，否则奖金为 0 。 返回的后果依照 employee_id 排序。 Create table If Not Exists Employees (employee_id int, name varchar(30), salary int);Truncate table Employees;insert into Employees (employee_id, name, salary) values ('2', 'Meir', '3000');insert into Employees (employee_id, name, salary) values ('3', 'Michael', '3800');insert into Employees (employee_id, name, salary) values ('7', 'Addilyn', '7400');insert into Employees (employee_id, name, salary) values ('8', 'Juan', '6100');insert into Employees (employee_id, name, salary) values ('9', 'Kannon', '7700');输出：Employees 表:+-------------+---------+--------+| employee_id | name | salary |+-------------+---------+--------+| 2 | Meir | 3000 || 3 | Michael | 3800 || 7 | Addilyn | 7400 || 8 | Juan | 6100 || 9 | Kannon | 7700 |+-------------+---------+--------+输入：+-------------+-------+| employee_id | bonus |+-------------+-------+| 2 | 0 || 3 | 0 || 7 | 7400 || 8 | 0 || 9 | 7700 |+-------------+-------+解释：因为雇员id是偶数，所以雇员id 是2和8的两个雇员失去的奖金是0。雇员id为3的因为他的名字以'M'结尾，所以，奖金是0。其余的雇员失去了百分之百的奖金。解析本题考查了三个知识点： ...

随着数字时代的降临，咱们迎来了有限的时机，同时也随同着网络安全畛域新的挑战。网络攻击变得更加智能化和复杂化，威逼也在一直演变。为了应答这些新挑战，咱们必须采取翻新的网络安全策略和技术。本文将探讨数字时代网络安全的新挑战，并提供一些应答策略。新挑战人工智能和机器学习的滥用： 攻击者利用人工智能和机器学习来辨认潜在指标、制订更无效的攻打策略和躲避传统的检测办法。为了反抗这一威逼，防御者须要采纳相似的技术来监测网络流量并检测异样行为。物联网（IoT）设施的脆弱性： IoT设施的爆炸式增长给网络安全带来了新问题。这些设施通常不足足够的安全措施，容易成为攻击者的指标。为了应答这一挑战，制造商和用户须要更加器重IoT设施的安全性。零日破绽的利用： 攻击者越来越频繁地利用尚未被发现的零日破绽进行攻打，这给网络安全形成了严重威胁。及时的破绽治理和强化软件开发过程是应答这一挑战的要害。社交工程和钓鱼攻打： 攻击者不再仅仅依赖技术破绽，他们也越来越依赖社交工程手法坑骗用户。教育用户，增强对社交工程的警惕性，以及应用平安的验证机制是应答这一威逼的重要步骤。IP地址查问：https://www.ipdatacloud.com/?utm-source=Lik&utm-keyword=?1094应答策略人工智能与机器学习进攻： 部署智能网络安全解决方案，利用机器学习和人工智能来监测网络流量，检测异样流动，并疾速作出反应。IoT设施安全性： 制造商应增强IoT设施的安全性设计，包含固件更新、强明码要求和加密通信。用户应定期更新设施固件，应用强明码，并在可能的状况下将IoT设施隔离在独立网络中。破绽治理： 组织应建设严格的破绽管理程序，包含定期破绽扫描和疾速破绽修复。同时，利用破绽情报来理解最新的威逼和攻打趋势。员工培训： 发展网络安全培训，教育员工如何分别和应答社交工程和钓鱼攻打。强调员工在接管生疏电子邮件或点击不明链接时要放弃审慎。多层次进攻策略： 施行多层次的网络安全策略，包含防火墙、入侵检测零碎、反病毒软件和访问控制等。这种深层次的进攻能够升高单一点故障的危险。论断数字时代网络安全新挑战确实存在，但通过采取翻新的网络安全策略和技术，咱们能够更好地应答这些挑战。爱护个人隐私、企业数据和国家平安须要全球性的合作，同时也须要不断更新和降级咱们的网络安全策略，以适应一直变动的威逼环境。只有通过个体致力，咱们能力确保数字时代的网络空间平安。

“本文由社区用户 @阿七从第一视角讲述其团队重构图数据库的过程，首发于阿七公众号「浅谈架构」” 原文出处：https://mp.weixin.qq.com/s/WIJNq-nuuAGtMjYo5rPLyg一、写在后面读过我公众号文章的同学都晓得，我做过很屡次重构，能够说是“重构钉子户”，然而这次，重构图数据库 OrientDB 为 NebulaGraph（https://www.nebula-graph.com.cn/），能够说是我做过最艰巨的一次重构。 那这篇文章就来聊聊，图数据库重构之路。 二、难点在哪里历史包袱重，原来应用 OrientDB 零碎是2016年开始开发的，逻辑很简单，历史背景齐全不分明。业务不理解，咱们是长期接的大数据需要，之前没有参加过这块业务，齐全不理解。技术栈不理解，图数据库是第一次接触（团队中也没有人理解），OrientDB 和 NebulaGraph 之前都没有接触过，原来老零碎大部分代码是 Scala 语言写的，零碎中应用的 HBase、Spark、Kafka，对于咱们也比拟生疏。工夫紧迫总结来说: 业务不理解，技术栈不相熟 tips: 大家思考一个问题，在业务和技术栈都不熟的状况下，如何做重构呢？三、技术计划上面介绍一下本次重构技术计划 1、迁徙背景猎户座的图数据库 OrientDB 存在性能瓶颈和单点问题，需降级为 NebulaGraph。 老零碎是用应用技术栈无奈反对弹性伸缩，监控报警设施也不够欠缺。 具体的应用痛点后续我将会写一篇文章具体讲述下，本篇就不具体开展了。2、调研事项注：既然业务都不相熟，那咱们都调研了哪些货色呢？ 对外接口梳理：梳理零碎所有对外接口，包含接口名、接口用处、申请量 QPS、均匀耗时，调用方（服务和 IP）；老系统核心流程梳理：输入老零碎整顿架构图，重要的接口（大略 10 个）输入流程图；环境梳理：波及到的须要革新的我的项目有哪些，利用部署、MySQL、Redis、HBase 集群 IP，及目前线上部署分支整顿；触发场景：接口都是如何触发的，从业务应用场景登程，每个接口至多一个场景笼罩到，不便前期性能验证；革新计划：可行性剖析，针对每一个接口，如何革新（OrientDB 语句改为 NebulaGraph 查问语句），入图（写流程）如何革新；新零碎设计方案: 输入整顿架构图，外围流程图。3、我的项目指标实现图数据库数据源 OrientDB 革新为 NebulaGraph，重构老零碎对立技术栈为 Java，反对服务水平扩大。 4、整体计划咱们采纳了比拟激进的计划: 从调用接口入口登程，间接重写底层老零碎，影响面可控；一劳永逸，不便前期保护；对立 Java 技术栈、接入公司对立服务框架，更利于监控及保护；根底图数据库利用边界清晰，后续下层利用接入图数据库更简略。注：这里就贴调研阶段画的图，图波及业务，我这里就不列举了。 5、灰度计划 灰度计划写申请：采纳同步双写读申请：按流量从小到大陆续迁徙、平滑过渡灰度打算阶段一阶段二阶段三阶段四阶段五阶段六阶段七0%1‰1%10%20%50%100%同步双写, 流量回放采样比照，100% 通过、预计灰度 2 天灰度 2 天灰度 2 天灰度 5 天、此阶段要压测灰度 2 天灰度 2 天-注： 配置核心开关管制，有问题随时切换，秒级复原。读接口脱漏无影响, 只有改到的才会影响。应用参数 hash 值作为 key，确保同一参数屡次申请后果统一、满足 abs(key) % 1000 < X ( 0< X < 1000， X 为动静配置 ) 即为命中灰度。题外话：其实重构，最重要的就是灰度计划，这个我在之前文章《浅谈这些年做过的千万级零碎重构我的项目》也提到过。本次灰度方案设计比较完善，大家重点看阶段一、在灰度放量之前，咱们用线上实在的流量去异步做数据比照，比照齐全通过之后，再放量，本次比照阶段比预期长了很多（实际上用了 2 周工夫，发现了很多问题）。 ...

IP地址定位https://www.ipdatacloud.com/?utm-source=Lik&utm-keyword=?1094 性能曾经广泛应用到各种网络应用当中，但少数都停留在城市级别的IP定位，满足不了局部用户需要，在强劲的市场需求推动下，近年来市场中呈现了精准度更高的IP定位接口，比方IP数据云的API接口可能精准定位到区县级，街道级是大多数企业的抉择，哪该如何判断其精度品质？能够依据上面几个指标来综合判断。定位率。指的是IP定位后果的成功率，例如，对一个IP地理位置定位产品而言，定位100个IP，胜利定位75个IP，则该IP地理位置定位产品的定位率为75%，定位率越高越好。误差间隔。指的是对定位后果经纬度与“实在地位”之间的间隔的指标。比方对一个IP精确定位接口而言，一个IP的实在地位在A，定位后果为B，实在地位与定位后果之间的间隔为900米，那么该IP定位接口的误差间隔为900米。笼罩半径。为了更加精确地形容定位IP的区域范畴，个别用笼罩半径来阐明IP定位所笼罩的范畴，笼罩半径则代表IP所笼罩区域最大外接圆的半径。定位精度。指的是对定位后果定位精度级别的形容，有6个级别，别离是洲、国家、省、城市、区县和街道。准确度。指的是IP定位的地位和事实地址的误差状况，误差越小准确度越高，基于IP精度、IP场景、IP变动频率等因素剖析，通过机器学习形式系统性的进步IP准确度，市面上不同平台接口的准确度差距较大，倡议用户购买之前做好测试工作。一致性。指的是在一段时间内IP可能发生变化的水平，由精度和利用场景来确定。精度越高，一致性越高，比方学校单位的IP就比住宅区IP的一致性强。

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群往年 Google 发表其提供的A/B测试工具 Optimize 将在2023年9月30号进行服务。在全球化浪潮席卷下，越来越多的中国企业正在减速走向寰球市场，要在出海业务中实现降本增效，只依赖人为教训远远不够，一直的打磨翻新十分要害，而利用大规模AB试验，能够帮忙企业进步决策效率、升高试错老本。 现在，很多原先应用 Optimize 和 Optimize 360 的企业也开始了新合作伙伴的抉择，火山引擎AB测试 DataTester 凭借优良的产品能力、全面的性能以及在字节积淀的大量教训，成为许多出海公司的首选单干平台。 据理解，经验了屡次版本升级的火山引擎 DataTester，可深刻满足企业各类业务场景，其中的可视化AB试验能力，因为无代码/低代码的个性，经营人员无需研发就能疾速优化产品界面和交互体验，受到了不少跨境出海客户的青眼。近期，DataTester又一次降级了可视化编辑器，满足了更加精细化的经营场景。 在跨境电商业务中，PC端的流量大，波及内容文案、页面色彩、按钮提醒等内容改版时，如果未做验证贸然上线改版计划，对网站外围数据的影响会存在不可把控的危险；而频繁验证，又难以避免研发设计资源缓和的状况。火山引擎 DataTester 本次新增的 Chrome 扩大模式就能很好地解决这个问题。利用 DataTester 后，经营人员在浏览产品页面时， 可能间接在浏览器中编辑网页的内容，而无需进入网站后盾或者应用其余编辑工具，这种模式大幅晋升效率和准确性，同时易于存档和治理。 目前DataTester的VisualEditor上线了Chrome利用商店，不便疾速增加应用。（VisualEditor扩大地址：https://chrome.google.com/webstore/detail/visualeditor/kejgja...）从用户进入产品到产生交易，两头会经验很多简单的交互，以电商场景为例，常见门路是：登录->浏览商品->退出购物车->提交订单->付款，每个环节都是用户交互的过程。那么什么样的交互方式设计，可能带来最高的转化率呢？DataTester 也可能通过可视化AB试验的模式，帮忙企业解决这个问题。DataTester 可视化编辑器3.0新增了可视化交互元素和身份验证页面的编辑，能够在同一个编辑模式下，实现从首页直至登录页的无缝环节编辑，便于清晰复现用户实在门路，并实现相应的交互优化。此外，在营销流动页、产品下载落地页等场景中，可视化AB试验的利用也十分多，业务人员可在其帮忙下，在周期紧凑的工作中，实现更加灵便的调整。 火山引擎DataTester源自字节跳动长期积淀，截至2023年6月，字节已通过DataTester累计做过240万余次AB试验，日新增试验 4000余个，同时运行试验5万余个。DataTester目前服务了包含美的、失去、凯叔讲故事等在内的上百家企业，为业务的用户增长、转化、产品迭代、经营流动等各个环节提供迷信的决策依据，将成熟的“数据驱动增长”教训赋能给各行业。 点击跳转火山引擎DataTester理解更多

更多技术交换、求职机会，欢送关注字节跳动数据平台微信公众号，回复【1】进入官网交换群在数据分析场景中，企业应用的数据通常具备起源多样化的特点，如领取交易记录、用户行为等，且数据格式各异，有的为行式存储构造，有的为列式存储构造。这就要求企业数仓具备肯定的数据转换能力。 传统形式是采纳Extract-Transform-Load (ETL)来将业务数据转换为适宜数仓的数据模型，然而，这依赖于独立于数仓外的ETL零碎，导致保护老本较高。但随着云计算时代的到来，云数据仓库具备更强扩展性和计算能力，也要求改变传统的ELT流程。 火山引擎ByteHouse是一款基于开源ClickHouse推出的云原生数据仓库，为用户提供极速剖析体验，可能撑持实时数据分析和海量数据离线剖析，同时还具备便捷的弹性扩缩容能力，极致剖析性能和丰盛的企业级个性。凭借其弱小的计算能力，火山引擎ByteHouse目前已全面反对Extract-Load-Transform (ELT)的能力，让用户免于保护多套异构零碎，产品易用性实现飞跃。通过ByteHouse的ELT能力，用户只需将数据导入，用自定义SQL语句在ByteHouse外部进行数据转换，无需依赖独立的ETL零碎及资源。具体来说，ByteHouse次要通过以下三个能力实现ELT能力： 首先，长工作治理。ByteHouse的查问工夫为秒级，一旦查问中出故障，零碎会间接返回谬误并重试。在ETL场景下，如果一个工作曾经执行50分钟才产生故障，重试意味着节约了前50分钟的资源，影响工作推动。在ByteHouse中，SQL查问会被转化为一系列的算子，研发团队则通过晋升算子的容错能力，来应答长时间查问下的系统故障问题，即当某个算子无奈取得足够的内存时，零碎容许该算子将一部分数据缓存在磁盘上，保障在资源缓和的状况下仍可能实现工作。 其次，异步提交能力。面对大量长耗时的ETL工作时，传统的同步执行形式须要客户端期待服务端返回，容易呈现超时问题，影响后续工作执行，而ByteHouse提供的异步提交能力，通过客户端的间歇性轮训来取得用户工作的最终状态，由此保障工作在规定工夫内实现。 最初，查问队列。当面临大量离线加工申请时，零碎会呈现超载。ByteHouse为此提供了查问队列能力，容许用户从队列大小、总CPU占用率、总内存占用率三个维度定义一个队列。 具体来说，当用户向某队列提交查问时，ByteHouse能够通过组件监听各个队列中的查问指标，如果队列未达到下限，则会将查问入队，否则回绝。除此之外，ByteHouse还会查看队列的资源利用率，当闲暇资源高过某阈值时，主动将期待中的查问出队。利用查问队列，用户在编排ETL工作时无需放心底层资源过载，让开发更加便捷。 长工作治理、异步提交和查问队列是火山引擎ByteHouse ELT的外围能力。将来，ByteHouse也会进一步迭代，反对转换函数、长工作容错、优先级队列等更丰盛ELT性能，为用户提供更极致、更便捷的应用体验。 点击跳转火山引擎ByteHouse理解更多

一、装置docker-compose完结后以下下是docker-compose.yml文件内容 version: '3.0'services: master: image: mysql:8.0.23 container_name: master restart: always network_mode: bridge ports: - 3306:3306 environment: LANG: C-UTF.8 TZ: Asia/Shanghai MYSQL_ROOT_PASSWORD: "root" volumes: - /root/mysql001/:/mysql001 slave01:image: mysql:8.0.23container_name: slave01restart: alwaysnetwork_mode: bridgeports: - 3307:3306environment: LANG: C-UTF.8 TZ: Asia/Shanghai MYSQL_ROOT_PASSWORD: "root"volumes: - /root/mysql001/:/mysql001 slave02:image: mysql:8.0.23container_name: slave02restart: alwaysnetwork_mode: bridgeports: - 3308:3306environment: LANG: C-UTF.8 TZ: Asia/Shanghai MYSQL_ROOT_PASSWORD: "root"volumes: - /root/mysql001/:/mysql001 slave03: image: mysql:8.0.23 container_name: slave03 restart: always network_mode: bridge ports: - 3309:3306 environment: LANG: C-UTF.8 TZ: Asia/Shanghai MYSQL_ROOT_PASSWORD: "root" volumes: - /root/mysql001/:/mysql001二、操作确定关上docker 检测docker ps -a ...

本文导读： 以后，电商经营的次要痛点不仅来自多变的市场和客户需要，也受困于碎片化用户触达等带来的竞争与挑战。为了深度开掘用户价值、造就用户忠诚度、实现业绩增长，有赞为商家搭建了全方位 OLAP 剖析零碎，提供实时与离线剖析报表、智能营销与人群圈选等 SaaS 服务。本文将具体介绍有赞从 Clickhouse 至 Apache Doris 的迁徙布局和性能比照测试实际，分享如何基于 Apache Doris 对立 OLAP 技术栈，并满足宏大数据体量下的实时剖析与极速查问，最终有赞在多个场景下实现查问均匀提速 200% 。 作者：李闯 有赞 根底平台数据研发工程师 有赞是国内当先的电商 SaaS 服务商，目前领有社交电商、新批发、美业、教育及有赞国际化五大业务体系，通过旗下的社交电商、门店治理、解决方案以及其余新批发 SaaS 软件产品，全面帮忙商家解决在挪动互联网时代遇到的推广获客、成交转化、客户留存、复购增长、分享裂变等问题，帮忙每一位器重产品和服务的商家实现顾客资产私有化、互联网客群拓展、经营效率晋升，最终助力商家胜利。 在面对商家与开发者的定制化服务需要的同时，为了可能更好地反对商家无效解决引流获客、分销体系等难题，有赞为商家搭建了 OLAP 剖析零碎，提供以下 SaaS 服务场景： 商家离线后盾报表： 面向 B 端为商家提供 T+1 报表查问，对计算精度、查问性能及稳定性要求较高，同时会面临简单查问场景。人群圈选与智能营销： 从私域触点、线下触点获取用户数据，联合罕用社交平台中接入的用户数据，依据业务需要在客户数据平台（Customer Data Platform - 以下简称 CDP）、数据管理平台（ Data Management Platform -以下简称 DMP）、客户关系管理系统（Customer Relationship Management- 以下简称 CRM） 进行不同消费者的全方位画像剖析。该场景会面临大量高频的数据实时更新，同时查问体量较大、QPS 较高，时常呈现简单 SQL 查问场景。商家实时剖析报表： 面向 B 端为商家提供相干实时报表剖析查问，该场景特点是 QPS 比拟高，商家能够抉择不同的维度组合进行查问，对实时性和稳定性要求高。天网日志剖析零碎： 为所有业务零碎提供日志采集、生产、剖析、存储、索引和查问的一站式日志服务。该场景写入吞吐高，须要达到每秒百万级别的数据写入；且查问频率低，波及天网 TopN 日志查问，因而零碎要求具备实时聚合以及含糊搜寻能力。随着业务数据体量逐步宏大，业务对于时效性、联邦查问剖析的需要也更加迫切，现有组件在应用过程中对业务人员开发、运维人员保护都存在肯定痛点，因而决定降级数据架构并基于 Apache Doris 来对立 OLAP 技术栈。本文将具体介绍晚期架构的组成、 OLAP 零碎运行流程、以及理论利用痛点，分享零碎架构在迁徙过程中的技术与调优教训。 ...

行业背景工业物联网场景下，随着智能设施及物联网技术的广泛应用，数据是最重要的资源之一，企业须要对各种机器、设施和传感器产生的时序数据进行采集、存储与剖析。因而，何为卓有成效的数据库解决方案？企业广泛更为关注如何解决并剖析由泛滥设施采集而来的数据进而优化生产流程、晋升治理效力，进而实现“智能制作”。与此同时，这些方向也为带来了诸如数据安全、数据品质、数据管理等在内的新挑战。 痛点与挑战1. 数据存储和治理难面临多种类型的数据、协定和零碎，难以实现对立的数据采集和存储管理，导致数据汇总和存储艰难。 2. 据实时剖析要求高原有零碎仅将数据进行存储而未进行无效利用，导致数据利用率低，无奈及时辅助管理人员做出决策。传统工业物联网场景数据需极高实时处理和剖析，以实现设施调度、预警系统等性能。 3. 多库利用和运维老本高多库利用要求开发者需把握多种数据库模型和技术实际的挑战，DBA 也需承担不同数据库的运维规定，导致昂扬的开发运维老本。此外，多库间数据传输和转换波及多正本治理，易出错且难以保障性能和数据一致性。 4. 人员和产线工作统计艰难生产环节不通明导致产能降落，产线工人虚报工时，设施运行状况须要人工统计，不足数据反对的排程往往通过主观臆断规定产品交期，进而导致设施利用率和工作饱和度升高。 解决方案 1. 实时数据处理和剖析通过建设多协定集成的数据平台，实现多源异构数据接入，同时利用 KaiwuDB+KDP 的就地计算和实时剖析技术，实现生产数据的高速存储和实时剖析，无效进步数据利用率，并反对管理层制订即时决策。 2. 数据汇入与剖析同步进行通过实时剖析技术，将数据存储和剖析同时进行，解决原有零碎仅存储数据而未进行无效利用的问题，进步数据利用率，并使数据展现更加及时。 3. KaiwuDB 多引擎+弹性扩大利用KaiwuDB 的多引擎个性，实现一库多用，升高多库利用的运维老本。同时，反对弹性扩大，满足数据增长需要，解决性能扩大受限的问题。 4. 产线运行数据接入剖析将操作台运行数据入库统计并剖析，实现对一线工人的工时和产线运行状况的综合研判，解决虚报工时和产线不通明的问题，进步产能和效率。 计划价值1. 数据平滑迁徙和对立治理将原零碎的大量历史数据对立迁徙至 KaiwuDB，实现一库多用，缩小数据存储老本，并提供对立的数据管理平台，便于数据的保护和查问。 2. 高效数据接入和入库性能晋升通过 KaiwuDB 多协定集成计划，实现各类设施接入并高效汇入数据，保障大规模数据的高速入库，进步数据采集效率和实时性。 3. 数据全面采集和协同治理实现工厂各作业环境的数据全面采集，将生产数据与经营治理数据进行关联，实现数据的协同剖析和治理，进步生产效率和响应速度。 4. 高效数据分析和性能晋升零碎反对简单场景数据聚合剖析和海量数据实时剖析，通过 KaiwuDB+KDP 的技术，晋升查问和剖析性能。缩小了异样停机，进步了设施利用率，从而晋升数据可用性和服务能力。

引文在数据库运维过程中，所应用的运维治理平台是否存在这样的问题： 1、默认监控粒度不够,业务须要更细颗粒度的监控数据。2、平台默认的监控命令不适宜,须要调整阈值量身定制监控策略。3、不同类型的实例或组件须要有不同的监控重点,但治理平台监控固化，难以应答多样化的监控需要。4、只监控零碎要害指标,屏蔽不必要的指标,优化CPU耗费、网络、采集数据量等，缩小资源耗费,晋升零碎性能。在数据库运维过程中，用户或者DBA常常会因为治理平台监控面板无奈配置，或者监控模板固化，监控模板中没有所关注的指标项，而不得已弃用局部治理平台，进而自建监控或者基于本身业务自定义一批运维监控脚本，来实现数据库或者主机的多样化监控需要。 但这些脚本往往出自不同DBA之手，监控脚本的治理、更新和保护，以及危险评估给数据库的稳固运行带来了新的危险，而且脚本的输入后果须要DBA周期查看剖析，展现上也不够直观。明天咱们来看下GreatADM是如何解决上述问题的。 一、GreatADM的监控介绍GreatADM提供灵便的自定义监控配置办法，反对通用的prometheus+grafana的标准，用户能够依照理论业务上的需要，通过配置规范的grafana面板json格式文件或者通过图形化选项配置监控采集项，手动定义dashboard面板。用户可按需灵便的配置监控面板。同时GreatADM反对用户按需调整监控数据的采集频率、监控超时阈值等，用户可按理论业务需要来定义调整，以及对应的SQL命令的调整等。 GreatADM提供不同数据库架构的监控指标和监控模板，反对采集频率、超时阈值的调整，并提供3个维度监控： 1、架构层面：数据库高可架构整体全局状态概览和复制状态、提早、运行时长、趋势概览。2、数据库实例：数据库实例节点层面的监控，如SQL执行状况，内存稳定，网络申请，I/O负载等方面监控。3、物理主机：数据库实例所在主机性能指标如CPU、内存、IO、磁盘用量等,能够发现数据库的性能瓶颈,及时进行优化。 针对监控采集，DBA在分析判断问题时，也可清晰理解到监控应用的SQL命令是什么，办法是否和本人的应用的SQL雷同等。 如果下面的监控指标，或者面板不是你想要的，接下来咱们就具体看下GreatADM如何自定义业务中，或者DBA想要的监控项，和监控面板的配置。 二、如何自定义GreatADM的监控面板配置整体步骤如下： a、增加监控采集指标，编辑采集命令Demo1：只监控Linux根空间用量Demo2：监控慢日志累计增长量b、查看采集器是否无效c、配置监控面板d、自定义监控实现e、多个面板配置在同一页面1、增加空间采集项Demo1、【如何减少主机自定义监控项---独立监控linux根空间用量】针对以下选项：填写采集组名称：host_root采集频率：300s采集超时：5s采集组默认是否启用：启用增加到哪个类型数据库架构：paxos高可用复制 采集指标：数据库主机抉择任一节点：hostname运行shell采集命令：df -Th|grep root|awk -F' ' '{print $6}'|awk -F'%' '{print $1}'采集命令留神：监控主机，则采集语句为shell命令，指标抉择主机；监控数据库，则采集语句为SQL命令，指标抉择数据库。另外对应的采集器返回的后果只容许是"单项后果值"，如果存在多列，多行后果，对应的采集器会报错，并且无奈失常采集。 采集器增加实现之后，信息如下 查看对应的采集命令 Demo2、【如何减少数据库自定义监控项---数据库慢日志增长趋势】针对以下选项配置办法同上：填写采集组名称：slow_queries采集频率：5s采集超时：5s采集组默认是否启用：启用增加到哪个类型数据库架构：paxos高可用复制 采集指标：数据库实例抉择任一实例节点： 抉择数据库名:paxos_600 实例节点：database_1运行SQL采集命令：select variable_value from performance_schema.global_status where variable_name='slow_queries' 提交并查看监控项信息 应用的SQL语句 增加采集项的整体配置流程能够总结为： 1抉择类型2抉择主机/数据库3采集命令4运行采集命令5提交并查看2、查看新增采集项是否无效抉择【监控告警】--子项【查问】来验证新减少的采集项是否可采集到数据，以及前端绘图是否失常 点击【应用查问】可看到对应的graph的绘制图，点击【查看】，可具体看到采集项【统计数据】，如下共采集了482行。以后因为我抉择了2台主机的，因截图遮展现框盖住了另外一台的绘图。 具体【数据】可查看到时序工夫对应的主机采集的磁盘数值。 登录主机和理论主机的磁盘根空间比照查看 确认对应的采集数据能够失常，无误，为可用状态。(数据库的采集项和此查看统一，这里就不在赘述了)。 接下来就能够配置grafana面板了。 3、配置监控面板登录GreatADM的http://172.17.139.50/graph/login可间接跳转到GreatADM集成Grafana面板配置页，默认账号为admin，明码为GreatADM内置的初始密码。 抉择【+】 Dashboard--增加新的【panel】 在这里Data sorce 抉择【监控】 点击【指标浏览器】--搜寻栏搜寻采集项名称【host_root】--匹配到【node_ext_host_root_demo】--主动匹配【address标签】展现可监控的主机IP列表 抉择要监控的主机【IP】--点击【应用查问】--可失常绘制监控图 调整横坐标轴的题目title【主机 "/" 根空间使用率】和纵坐标的lable形容【磁盘空间使用率（%）】 ...

在前端页面显示，为了防止一次性展现全量数据，通过高低翻页或指定页码的形式查看局部数据，就像翻书一样，这就利用了MySQL的分页查问。 一、MySQL的深分页查问偏移量过大的分页会导致数据库获取数据性能低下，以如下SQL为例： SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10这句SQL会使得MySQL在无奈利用索引的状况下跳过1000000条记录后，再获取10条记录，其性能可想而知。这种查问偏移量过大的场景咱们称为深分页。 MySQL的深分页会带来性能降落等问题，而这个问题在分布式数据库场景下，会变得更加简单。 二、分布式数据库的深分页弹性数据库JED能够简略了解成分布式的MySQL数据库，这里以JED为例，介绍下大多数分布式数据库是如何做分页查问的。 2.1 弹性数据库的分页实现以下图的例子，咱们来介绍多分片数据库如何执行分页查问。t\_order表以id作为主键以t\_col1作为分片键，数据分布如下： 为了获取t_order表第2条之后的两条数据，执行SQL： SELECT * FROM t_order ORDER BY id LIMIT 2, 2如果只是简略的把SQL下推到每个分片的MySQL实例执行，再在内存中对返回后果进行聚合排序解决，会是什么成果呢？ 分片1返回后果 {(id : 4, t\_col1 : "a"), (id : 10, t\_col1 : "a")}; 分片2返回后果 {(id : 7, t\_col1 : "b"), (id : 8, t\_col1 : "b")}； 内存排序计算后，将后果{(id : 4, t\_col1 : "a")，(id : 7, t\_col1 : "b")}返回，显然这是一个谬误的后果。为了失去正确的后果，须要每个分片都获取前4条（2+2）数据，之后在内存中进行排序后分页。因而，每个分片执行的SQL改写为： SELECT * FROM t_order ORDER BY id LIMIT 0, 4再将返回的后果集在内存排序后，取第2条之后的两条数据{(id : 4, t\_col1 : "a")，(id : 5, t\_col1 : "b")} 返回用户。 ...

数据库系统数据：是数据库中存储的根本对象，是形容事物的符号记录数据的品种：文本，图形，图像，音频，视频，等数据库：是长期存储在计算机内，有组织的，可共享的大量数据的汇合 数据库的基本特征 数据依照肯定的数据模型组织，形容和存储堪称各种用户共享冗余度较小数据独立性较高易扩大数据库系统是一个采纳了数据库技术，有组织的，动静的存储大量相干数据，方柏霓多用户拜访的计算机系统， 组成： 数据库硬件软件人员数据库管理系统DBMS ： 实现对共享数据无效的组织、治理和存取包含数据定义、数据库操作、数据库运行治理、数据的存储管理、数据库的建设和保护等。三级模式两级映像内模式：治理如何存储物理数据，对应具体物理存储文件模式：又称为概念模式，就是咱们通常应用的根本表，依据利用，需要将物理数据划分为一张张表外模式：对应数据库中的视图级别，将表进行肯定的解决后再提供给用户应用。两级映像外模式-模式映像模式-内模式映像 数据库设计需要剖析：信息要求、解决要求、零碎要求概念结构设计：E-R 图 属性抵触：同一个属性可能会存在于不同的ER图中命名抵触：雷同意义的属性 ，在不同的分ER图中有不同的命名结构冲突：同一个实体在不同的er图中有不同的属性逻辑结构设计：E-R图，转关系模式（表（针对关系型））物理设计：表如何存储到硬件数据库施行：建表，录数据巴拉巴拉数据库运行和保护：运维image.png 数据模型四种根本模型 关系模型：是二维表的的模式示意的实体分割图概念模型网状模型面向对象数据模型的三要素 数据结构数据操作数据的约束条件ER图来形容概念数据模型，在ER模型中，应用椭圆来示意属性，长方形示意实体，菱形示意分割，分割的两端要填写分割类型eg: 实体：客观存在并且能够互相区别的事物弱实体：依赖于强实体存在强实体：实在体实体集 属性： 属性分类：简略属性，复合属性域：属性的取值范畴成为该属性的域码（键key)：惟一标识实体的属性集 关系模型中数据的逻辑构造是一个二维表，由行列组成。 ER模型转换为关系模式：每个实体都对应一个关系模式；分割分为三种： 一对一：分割能够放到任意的两端实体中，作为一个属性，也能够转换为一个独自的关系模式一对多：分割能够独自作为一个关系模式，也能够在N端中退出1端实体的主键多对多：分割必须作为一个独自的关系模式，其主键只M和N端的联结主键 关系代数并：后果是两张表中的所有记录数合并，雷同记录只显示一次 交：后果是两张表中雷同的记录差：s1-s2 后果是两张表中 s1中有，而s2中没有的那些记录。 笛卡尔积s1Xs2 产生的后果包含s1和s2 所有的属性列，并且s1中的每条记录顺次和s2中所有记录组合成一条记录，最终属性列为s1+s2 属性列，记录数为s1Xs2记录数 投影：理论是依照条件抉择某关系模式中的某列，列也能够用数字示意抉择：理论是依照条件抉择某关系中的某条记录 天然链接 天然链接的结果显示全副属性列， 然而雷同的属性列只显示一次， 显示两个关系模式中属性雷同且值雷同的记录。 函数依赖给定一个x,能确定一个y，就成为x确定y， 函数依赖： 局部函数依赖： a能够确定c，（a,b)也能够确定c，（a,b) 中的一部分能够确定c ，称为局部函数依赖传递函数依赖 ： a,b不等价， a能够确定b, b能够确定c ,则a 能够确定c函数依赖公理零碎 自反律增广律传递律合并规定伪传递律合成规定键与束缚 超键： 能惟一标识此表属性的组合候选键： 超键中去掉荣誉的属性，剩下的就是候选键主键：选一个候选键能够作为主键外键：其余表中的主键主属性：候选键内的属性为主属性，其余属性为非主属性 实体完整性束缚：即主键束缚， 主键值不能为空，也不能反复参照完整性束缚：即外键束缚，外键必须是其余表中曾经存在的主键的值，或者为空用户自定义的完整性束缚：自定义表达式束缚，如设定年龄属性必须在0-100 等。范式第一范式关系中的每一个重量必须是一个不可分的数据项第二范式如果关系R属于1NF，且每一个非主属性齐全函数依赖与任何一个候选码，则R属于2NF局部函数依赖只存在多属性，单属性必然是2NF第一范式不满足第二范式，能够通过合成表格实现2NF满足第三范式关系R属于2NF，且不存在传递依赖，则属于3NFbc范式bc范式是指 在第三范式的根底上，进一步打消主属性对码的局部函数依赖和传递依赖在每一种状况下，每一个依赖的右边决定因素都必然蕴含候选键。候选关键字求法：依据依赖集，找出从未在左边呈现过的属性，必然是候选键之一，以该属性为根底，依据依赖集顺次扩大，看是否便当所有属性，将无奈遍历的退出到候选集中 模式合成范式之间的转换个别是通过拆分属性，即模式合成，将具备局部函数依赖和传递依赖的属性分离出来， 放弃函数依赖合成对于关系模式R，有依赖集F，若对R进行合成，合成进去的多个关系模式，放弃原来的函数依赖集不变，则放弃函数依赖的合成。 放弃函数依赖的判断如果F上的每一个函数依赖都在其合成后的某一个关系上成立，则这个合成时放弃依赖的如果上述判断失败，并不能断言合成不是放弃依赖的，还要应用上面的通用办法来做进一步判断，该办法的表述如下：对F上的每一个a->b 应用上面的过程算法挺简单，可不必记，灵便了解即可 result:=awhile(result changed) do for each parsed Ri t = (result 交 Ri) + 交 Ri result= result 并 t done无损合成合成后的关系模式可能还原出原关系模式，就是无损合成，不能还原就是有损 ...

什么是 Scalar Type（标量类型）？Scalar Type（标量类型）是数据库中的一种根本数据类型，用于示意单个值或原子值。与简单数据类型（如数组、对象或自定义类型）不同，标量类型示意繁多数据项，没有内部结构。Scalar Types是数据库中的根底构建块，它们用于存储各种类型的数据，包含数字、文本、日期、工夫、布尔值等。理解Scalar Type是数据库开发中的基础知识，它们是构建数据库模式、定义表构造以及插入、查问和更新数据的重要组成部分。 常见的 Scalar Types1. 整数类型（Integer Types）整数类型用于存储整数值，通常包含以下子类型： INT：规范整数类型，通常占用4字节，可用于存储常见整数范畴的数据。SMALLINT：占用2字节，用于存储较小的整数值。BIGINT：占用8字节，用于存储大整数值，实用于须要更大范畴的数据。例如，在一个员工信息表中，能够应用整数类型存储员工的工号： CREATE TABLE employees ( employee_id INT PRIMARY KEY, first_name VARCHAR(50), last_name VARCHAR(50));2. 浮点数类型（Floating-Point Types）浮点数类型用于存储带有小数局部的数字，通常包含以下子类型： FLOAT：单精度浮点数，通常占用4字节。DOUBLE：双精度浮点数，通常占用8字节。例如，在一个商品价格表中，能够应用浮点数类型存储商品的价格： CREATE TABLE products ( product_id INT PRIMARY KEY, product_name VARCHAR(100), price DECIMAL(10, 2));3. 字符串类型（String Types）字符串类型用于存储文本数据，通常包含以下子类型： CHAR：固定长度的字符，须要指定字符的最大长度。VARCHAR：可变长度的字符，只存储理论应用的字符，须要指定最大长度。例如，在一个客户信息表中，能够应用字符串类型存储客户的姓名： CREATE TABLE customers ( customer_id INT PRIMARY KEY, first_name VARCHAR(50), last_name VARCHAR(50));4. 日期和工夫类型（Date and Time Types）日期和工夫类型用于存储日期、工夫或日期工夫信息，通常包含以下子类型： DATE：仅存储日期信息。TIME：仅存储工夫信息。DATETIME：存储日期和工夫信息。TIMESTAMP：存储日期和工夫信息，通常与时区相干。例如，在一个日程安排表中，能够应用日期和工夫类型存储会议的工夫信息： CREATE TABLE meetings ( meeting_id INT PRIMARY KEY, meeting_name VARCHAR(100), meeting_datetime DATETIME);5. 布尔类型（Boolean Type）布尔类型用于存储逻辑值，通常有两个取值：TRUE和FALSE。在某些数据库系统中，也能够应用整数类型（通常1示意TRUE，0示意FALSE）来模仿布尔类型。 ...

IP地址定位在各个行业有以下利用：1.广告与营销：依据用户的IP地址定位，能够向特定地理位置的用户发送定向广告和促销信息进步广告的精准度和成果。2.商业地理信息系统（GIS）：IP地址定位能够将用户的地位信息与地理信息系统相结合，提供具体的地位导航、天文数据查问等服务。3.物流与交通管理：通过IP地址定位，能够实时监控和跟踪货物的地位优化物流和交通管理提高效率和安全性。4.金融风险管制：IP地址定位能够帮忙金融机构辨认用户的实在地理位置，提供更精确的危险评估和反欺诈措施。5.社交网络与地位共享：利用IP地址定位，用户能够与四周的敌人共享本人的地位信息实现实时交换和社交互动。 6.安全监控与防护：通过IP地址定位，能够实时监控网络和设施的安全性对异样IP地址进行防护和拦挡。 7.游览与餐饮行业：通过IP地址定位，能够提供左近的景点、酒店餐厅等举荐，帮忙旅游者更好地布局行程。 网络应用剖析与优化：IP地址定位能够帮忙网络运营商剖析用户地理分布，优化网络资源配置和服务提供。 9.公共安全与紧急救济：IP地址定位能够帮忙紧急救济机构迅速定位事变或劫难产生地点，提供及时的救济和声援。市场钻研与商业竞争剖析：通过IP地址定位，能够理解不同地区的用户行为和偏好为企业的市场钻研和商业竞争剖析提供参考根据。

本文整顿自阿里云高级开发工程师曾庆栋（曦乐）在 Streaming Lakehouse Meetup 分享的内容，深入探讨了传统数据仓库剖析、Paimon+StarRocks湖仓一体数据分析、StarRocks 与 Paimon 的协同应用办法与实现原理，以及StarRocks 社区湖仓剖析的将来布局。 01 传统数据仓库剖析实现计划简介传统数据仓库剖析的实现是一个典型 Lambda 架构，通过下图咱们能够看出传统架构次要分为两层：下层是实时链路层，上层是离线链路层。它们的数据通过左侧的数据摄入层，通过不同门路将数据对立整合到像 Kafka 这样的音讯队列中间件中，而后将数据分为两份雷同的数据，别离由实时链路和批量链路进行解决，最终汇总到数据服务层，实现对用户提供数据分析服务的能力。 Lambda 架构的呈现次要是因为用户对于实时剖析需要的呈现，以及流解决技术的逐步成熟。然而它也有一些显著的弊病，如上图所示，它须要保护两套零碎，这就会导致部署老本和人力老本都会减少。当业务变更的时候，也须要批改两套零碎来适应业务的变动。随着流解决技术的逐步成熟，Lambda 架构之后又推出了 Kappa 架构，如下图所示。 Kappa 架构是应用流解决链路来代替原来的 Lambda 架构，因为流解决的成熟，所以通过一套零碎去实现实时和离线的计算成为可能。Kappa 架构有一个前提，它认为对于历史数据的反复计算，在非必要的状况下是不必进行的。这就使得当用户须要从新计算历史数据或是呈现新业务变动的时候，往往须要将整个数据摄入阶段的过程重放一次。在大量生产历史数据的状况下，必然造成资源节约，并遇到一些瓶颈。 02 Paimon+StarRocks 构建湖仓一体数据分析实现计划2.1 数据湖核心第一个计划是 Paimon 和 StarRocks 构建湖仓一体数据分析的数据湖核心计划。 StarRocks 自身是一个 MPP 的数据库，同时能够外接多种格局的数据湖组件，能够以单纯作为查问引擎去外接数据湖组件，实现查问性能。如上图，通过 StarRocks 或 Spark 都能够对 ODS 等数据层的 Paimon 组件进行查问。在这个架构里，Paimon 通过对数据的落盘和索引，补救了上文介绍的 Kappa 架构中音讯队列中间件在数据的批改、回溯、查问等方面的有余，从而使得这个架构的容错率更高，反对的能力也更宽泛。同时在批处理方面，Paimon 也能够齐全兼容 HIVE 的能力。 2.2 减速查问第二个计划是 Paimon 和 StarRocks 构建湖仓一体数据分析的减速查问计划。 它与第一个计划的区别是简直整个零碎都由 StarRocks 独自实现。当数据接入 Paimon，使它作为 ODS 层之后，通过 StarRocks 的表面个性来读取 Paimon 上的数据，建设一层物化视图来作为 DWD 层。StarRocks 的物化视图具备肯定的 ETL 的能力，当它作为 DWD 层之后，又通过第二层嵌套物化视图来作为 DWS 层，最终提供给数据服务层进行数据分析。通过 StarRocks 的这套零碎配合 Paimon 这个架构的两个长处是： ...

本文为墨天轮社区整顿的2023年8月国产数据库大事件和重要产品公布音讯。 目录8月国产数据库大事记 TOP108月国产数据库大事记（工夫线）产品/版本公布兼容认证代表厂商大事记厂商流动相干材料8月国产数据库大事记 TOP10 8月国产数据库大事记（工夫线）8月1日，强制性国家标准GB 18030-2022《信息技术 中文编码字符集》正式施行！该规范适用范围是具备中文信息处理及替换性能的软硬件产品，设立三档实现级别，共收录汉字87887个，比上一版增收了1.7万余个生僻汉字。数据库软件对强制性国家标准GB 18030的反对水平，间接关系到信息系统的文字处理能力，与生僻字人群的切身利益非亲非故。据检测与认证机构统计，我国数据库厂商已有23家首次通过测评认证。 GB 18030-2022 首批数据库企业认证名单 序号厂商产品名称及版本号适配处理器适配操作系统实现级别规范后果认证后果1华为云计算技术有限公司GaussDB V2.0KunpengKylin实现级别3符合标准正式发证2贵州易鲸捷信息技术有限公司数据库产品QianBase V9.0KunpengKylin实现级别3符合标准正式发证3北京柏睿数据技术股份有限公司柏睿数据企业级交易型数据库系统（信创版）V4.0KunpengKylin实现级别3符合标准正式发证4金篆信科有限责任公司GoldenDB数据库软件 V6KunpengKylin实现级别3符合标准正式发证5福建星瑞格软件有限公司星瑞格数据库管理系统 SinoDB V16.8KunpengKylin实现级别3符合标准正式发证6北京华宇软件股份有限公司ArteryBase数据库管理系统 V3.6KunpengKylin实现级别3符合标准正式发证7湖南亚信安慧科技有限公司亚信安慧AntDB数据库系统6.2（集中式） 亚信安慧AntDB数据库系统6.2（分布式）KunpengKylin实现级别3符合标准正式发证8深圳计算迷信研究院崖山数据库 V23KunpengKylin实现级别3符合标准正式发证9北京优炫软件股份有限公司优炫数据库管理系统 V2.1KunpengKylin实现级别3符合标准正式发证10阿里云计算有限公司阿里云PolarDB数据库管理软件 V2.0HygonUOS实现级别3符合标准正式发证11平凯星辰（北京）科技有限公司平凯数据库企业版软件 V7.1HygonKylin实现级别3符合标准正式发证12北京海量数据技术股份有限公司海量数据库管理系统Vastbase G100 V3.0PhytiumUOS实现级别3符合标准正式发证13北京人大金仓信息技术股份有限公司金仓数据库管理系统KingbaseES V8 金仓数据库管理系统 KingbaseES V9IntelWindows实现级别3符合标准正式发证14武汉达梦数据库股份有限公司达梦数据库管理系统 V8IntelWindows实现级别3符合标准正式发证15成都虚谷伟业科技有限公司虚谷数据库管理系统 V11.0IntelUOS实现级别3符合标准正式发证16腾讯云计算（北京）有限责任公司腾讯云分布式数据库 TDSQL 管理系统10.3 TDSQL 关系型数据库治理系统软件8.0IntelUOS实现级别3符合标准正式发证17天津南大通用数据技术股份有限公司南大通用平安数据库管理系统 V8.8 南大通用大规模分布式并行数据库集群零碎 V9.5 南大通用大规模分布式并行数据库集群零碎 V9.8 南大通用多模多态数据库管理系统 V5Intel AMD AMD IntelRed Hat UOS UOS UOS实现级别3符合标准正式发证18天津神舟通用数据技术有限公司神通数据库管理系统 V7.0IntelUOS实现级别3符合标准正式发证19北京奥星贝斯科技有限公司OceanBase数据库软件 V4IntelAnolis实现级别3符合标准正式发证20新华三技术有限公司H3C 川海数据库系统软件 V2.0IntelH3C实现级别3符合标准正式发证21云和恩墨（北京）信息技术有限公司MogDB企业版数据库管理系统 V3.0IntelUOS实现级别3符合标准正式发证22深圳九有数据库有限公司九有数据库UDB-TX软件 V2.4IntelUOS实现级别3符合标准正式发证23杭州易景数通科技有限公司義和（Halo）通用数据库系统软件 V1.0IntelUOS实现级别3符合标准正式发证《信息技术-中文编码字符集》是中文信息技术畛域最重要的基础性规范，对汉字和我国多种少数民族文字对立编码，施行场景丰盛，利用范畴宽泛。规范首次于2000年公布，2005年第一次订正。此次公布的新版规范是强制性国家标准，不仅收录《通用标准汉字表》全副汉字，同时笼罩我国绝大部分人名、地名用生僻字以及文献、科技等业余畛域用字，为传承中华文化、加强中文信息处理能力、满足姓名生僻字人群用字需要提供规范保障。8月1日音讯，赛迪参谋公布了《2022-2023年度中国平台软件市场钻研报告》，报告对包含数据库、操作系统等在内的平台软件市场倒退进行了剖析。2022年寰球数据库管理系统市场占比持续放弃最大，且增速最快，规模达到 492.1亿美元，占比达44.9%。2022年，中国数据库管理系统市场竞争格局出现国外厂商市场占有率萎缩，外乡厂商市场占有率晋升的趋势。 报告指出，在对平台软件需要增长最快的金融行业，OceanBase已占据国产分布式数据库销售额第一地位。报告显示，武汉达梦数据股份有限公司（简称“达梦数据”）在2022年中国数据库管理系统国产数据库市场占有率和事务型数据库管理系统市场占有率均排名第一。报告显示，天津南大通用数据技术股份有限公司(简称“GBASE南大通用”)在2022年中国剖析型数据库管理系统市场占有率第一，曾经间断多年领跑中国剖析型数据库管理系统榜单。优炫数据库市场份额在事务型数据库和剖析型数据库均位居前三，继续位居中国数据库管理系统市场国内数据库厂商前列。8月1日，腾讯云向量数据库（Tencent Cloud Vector DB）正式上线公测。作为一款全托管的自研企业级分布式数据库服务，腾讯云向量数据库专用于存储、检索、剖析多维向量数据。该数据库反对多种索引类型和类似度计算方法，单索引反对10亿级向量规模，可反对百万级QPS及毫秒级查问提早。 腾讯云向量数据库不仅能为大模型提供内部知识库，进步大模型答复的准确性，还可广泛应用于举荐零碎、文本图像检索、自然语言解决等AI畛域。腾讯云向量数据库是国内首个从接入层、计算层、到存储层提供全生命周期AI化的向量数据库。8月1日音讯，近日，由中国信息通信研究院与中国通信企业协会联结主办的2023“鼎新杯”数字化转型利用大赛入围名单公示，山东挪动基于GoldenDB分布式数据库的CRM&BOSS外围零碎自主翻新实际胜利入选。 该我的项目在6个月内实现首个地市外围零碎疾速上线，并在21天内实现后续地市外围零碎的部署、测试、上线，成为中兴通讯与中国移动在数据库要害畛域的又一个单干范例。8月2日音讯，日前，国内权威征询与钻研机构Gartner首次公布《2023年中国数据、剖析与人工智能技术成熟度曲线报告》（Hype Cycle for Data, Analytics and AI in China, 2023 ）。TDengine、柏睿数据、DolphinDB、Kyligence凭借当先的技术实力入选实时数据管理技术畛域典型厂商。 ...

导语：随着互联网和挪动设施的遍及，通过IP地址进行精准定位已成为事实。这一技术的倒退带来了许多便当，但也引发了隐衷问题的关注。本文将探讨通过IP地址进行精准定位的技术、办法以及波及的隐衷问题。 一、技术和办法： 1.IP地址的基本原理：IP地址是一个数字，用于标识一个设施在网络中的地位。通过查问IP地址的归属地，能够确定设施所在的大抵地位。 2.IP地址定位服务：有许多在线服务提供IP地址定位性能，如https://www.ip66.net/?utm-source=Lik&utm-keyword=?1124等。这些服务通常应用天文定位数据库，通过匹配IP地址与地理位置的映射关系实现对设施地位的定位。 3.WiFi定位技术：WiFi定位是指利用WiFi信号强度和地位数据库进行定位的技术。通过手机或计算机连贯到WiFi网络时，零碎会主动获取左近WiFi信号的强度和地位信息通过与地理位置数据库的匹配能够实现对设施地位的定位。二、隐衷问题： 定位精度与隐私权的均衡：IP地址定位技术的精度曾经相当高，能够准确到城市甚至街区级别。这引发了隐私权的担心，因为精确定位可能裸露用户的个人信息和行踪。2.数据保护与访问控制：IP地址定位服务须要大量的集体数据，包含IP地址、地理位置和设施信息等。为了爱护用户的隐衷，服务提供商须要采取严格的数据保护措施，并限度对数据的拜访。非法与非法应用：IP地址定位技术能够为许多非法利用提供便当，如定位失落的手机或防止网络欺诈。然而，一些人可能会滥用这一技术用于追踪、跟踪或进犯别人隐衷。因而，须要建设相干法规和监管措施避免滥用行为的产生。 三、论断： 通过IP地址进行精准定位在现在的互联网时代已成为一项不可漠视的技术。精准定位技术的倒退为咱们提供了许多便当，如失落手机的追踪和准确的本地搜寻等。然而，咱们也须要关注波及的隐衷问题，并采取措施爱护个人信息的平安。只有找到定位精度与隐私权之间的均衡，能力真正施展IP地址定位技术的后劲。 注：本文旨在探讨通过IP地址进行精准定位的技术和办法，以及波及的隐衷问题。在理论利用中，咱们还须要恪守相干法规和条例确保非法和正当应用IP地址定位技术。

前言在之前的文章中，咱们介绍了弹性数据库连贯生效的背景，并探讨了HikariCP、Druid连接池探活策略的相干内容。在本文中，咱们将会持续探讨另一个线上罕用的连接池——DBCP，并为您介绍如何在应用DBCP时实现最佳实际的弹性数据库连接池探活策略。 DBCPDBCP有两个版本：1.x和2.x（也称为DBCP2）。DBCP 2基于Commons Pool 2，相比1.x版本，在性能、JMX反对和其余许多方面都有所提高。因为DBCP 2.x与DBCP 1.x不是二进制兼容，所以降级到2.x的用户应该晓得Java包名称曾经扭转，以及Maven坐标。 首先咱们先列出对于DBCP探活相干的参数： 参数名称阐明默认值initialSize初始化时建设物理连贯的个数。0minIdle最小闲暇连贯:连接池中答应放弃闲暇状态的最小连贯数量,低于这个数量将创立新的连贯,如果设置为0则不创立0maxIdle最大闲暇连贯:连接池中答应放弃闲暇状态的最大连贯数量,超过的闲暇连贯将被开释,如果设置为正数示意不限度8maxActive/maxTotal最大流动连贯:连接池在同一时间可能调配的最大流动连贯的数量，超过这个值的申请进入期待队列, 如果设置为非负数则示意不限度（1.x版本 maxActive 2.x版本maxTotal）8testOnBorrow指明是否在从池中取出连贯前进行测验,如果测验失败,则从池中去除连贯并尝试取出另一个truetestOnReturn指明是否在偿还到池中前进行测验。falsetestWhileIdle指明连贯是否被闲暇连贯回收器进行测验。如果检测失败,则连贯将被从池中去除.留神: 设置为true后如果要失效,validationQuery参数必须设置为非空字符串falsetimeBetweenEvictionRunsMillis驱赶连贯的线程运行的工夫距离,以毫秒为单位. 如果设置为非负数,则不运行闲暇连贯回收器线程-1validationQuery用来检测连贯是否无效的sql，要求是一个查问语句。select 1validationQueryTimeout单位：秒，检测连贯是否无效的超时工夫。底层调用jdbc Statement对象的void setQueryTimeout(int seconds)办法 minEvictableIdleTimeMillis连贯在池中处于闲暇状态的最小工夫，超过这个工夫会被驱赶驱赶。30分钟softMinEvictableIdleTimeMillis这个参数与minEvictableIdleTimeMillis相比是这个参数受minIdle的限度，当达到这个值的时候只会驱赶大于minIdle的连接数-1numTestsPerEvictionRun在每次闲暇连贯回收器线程运行时查看的连贯数量。3DBCP 和与Druid 的探活配置相比，只管它们的许多参数名字和性能类似，但在细节和默认值上存在不同之处。例如，testWhileIdle 参数在 Druid 中用于判断是否在申请连贯时开启探活，且需大于 timeBetweenEvictionRunsMillis 参数值。而在 DBCP 中，该参数在驱赶连贯时进行判断，若开启，则间接进行验证，相似Druid中的keepAlive参数。两个连接池中，驱赶闲暇连贯的工夫距离都受到 timeBetweenEvictionRunsMillis 参数的管制。此外，testOnBorrow 参数的性能雷同，但默认值有所不同。 另外在DBCP在驱赶线程中也受numTestsPerEvictionRun参数影响，这个参数是指每次驱赶线程运行时驱赶连贯的个数，不会一次查看池内全副的连贯。此外DBCP的minEvictableIdleTimeMillis跟Druid不同超时驱赶的连接数不受minidle管制。 下图是DBCP1.4.0的驱赶连接线程的源码：org.apache.commons.pool.impl.GenericObjectPool#evict 咱们能够从源码中看到驱赶的连贯个数从getNumTests获取，getNumTests返回的是连接池的现有size和numTestsPerEvictionRun的最小值。驱赶过程的第一步先判断闲暇工夫是否超过minEvictableIdleTimeMillis，没有的话再判断softMinEvictableIdleTimeMillis是否超时和现有的连贯是否大于minIdle，第三个if是判断testWhileIdle的配置为true时且下面没有回收该连贯，在第四步的时候对此连贯进行探活。 总结：DBCP在各个版本中对探活变动不大，个别都是在驱赶连接数时能够应用testWhileIdle来进行探活，驱赶线程运行的间隔时间是timeBetweenEvictionRunsMillis参数的值，此外numTestsPerEvictionRun参数是每次驱赶线程的个数，因而咱们只有应用这两个参数设置的能够在10分钟之内对池内所有连贯（最大值为maxActive/maxTotal）进行探活就能无效防止JED网关的生效连贯。 总的来说，DBCP在不同版本中对探活的实现形式变动不大。通常状况下，能够通过在驱赶连贯时应用testWhileIdle参数来进行连贯的探活。驱赶线程的运行间隔时间受timeBetweenEvictionRunsMillis参数的管制，而numTestsPerEvictionRun参数则决定了每次驱赶线程能够解决的连接数。倡议numTestsPerEvictionRun配置的值和maxActive/maxTotal统一，并配置timeBetweenEvictionRunsMillis小于10分钟可能保障对所有连贯进行探活，防止拿到网关生效的连贯。 此外，利用应用DBCP时，默认开启testOnBorrow参数个别能够无效防止拿到生效的连贯，而Druid默认不开启testOnBorrow参数。对于是否开启testOnBorrow参数，利用能够自行评估。尽管开启testOnBorrow参数会在每次拿到连贯前进行连贯验证，损耗一小部分性能，然而这样可能及时销毁有效连贯并重建新连贯，在遇到JED网关故障重启时可能无效防止利用报错。 JED配置模版：DBCP1.4<propertyname="minIdle"value="5"/> <propertyname="maxActive"value="10"/> <propertyname="testWhileIdle"value="true"/> <propertyname="validationQuery"value="SELECT 1"/> <propertyname="timeBetweenEvictionRunsMillis"value="300000"/> <propertyname="numTestsPerEvictionRun"value="10"/> DBCP2.2.0<propertyname="minIdle"value="5"/> <propertyname="maxTotal"value="10"/> <propertyname="testWhileIdle"value="true"/> <propertyname="validationQuery"value="SELECT 1"/> <propertyname="timeBetweenEvictionRunsMillis"value="300000"/> <propertyname="numTestsPerEvictionRun"value="10"/> DBCP2.1.1同2.2.0 总结本文以JED的网关超时报错为背景，对常见的数据库连接池进行了调研，并介绍了连接池探活相干的参数和探活逻辑。通过本文的内容，读者应该理解到不同连接池的探活内容，能够依据不同的参数设置连接池，无效防止利用拿到网关敞开的连贯。本文提供了在JED数据库中的连接池配置模板，读者能够依据本人的利用需要进行调整。 作者：京东批发 王雷鑫 起源：京东云开发者社区 转载请注明起源

对从事互联网 IT 技术岗位的来说，数据库也是咱们日常必备的技能之一，而 MySQL 数据库更是常见、罕用的数据库之一。 依据 DB-Engines 的数据显示，MySQL 是寰球最风行的开源数据库，并且在过来十多年中始终排名第二。数据起源：DB-Engines 官方网站截图，具体数据：https://db-engines.com/en/ranking MySQL 的发展史MySQL 的历史能够追溯到1979年，它的创始人叫作Michael Widenius，他在开发一个报表工具的时候，设计了一套API，起初他的客户要求他的API反对sql语句，他间接借助于 mSQL 的代码，将它集成到本人的存储引擎中。然而他总是感觉不称心，故萌发了要本人做一套数据库的想法。1996 年 MySQL 1.0公布，同年 10 月 MySQL 3.11.1 公布了 Solaris 的版本，一个月后，Linux 版本公布，从那时候开始，MySQL 缓缓的被公众所承受。 1999 年，Michael Widenius 成立了 MySQL AB 公司，MySQL 由集体开发转变为团队开发，2000 年应用 GPL 协定开源。 2010 年 12 月，MySQL 5.5 公布，Oracle 也把 InnoDB 做成了 MySQL 默认的存储引擎，MySQL 从此进入了辉煌倒退的期间。 2015年10月，MySQL 5.7 版本公布，它带来很多新的个性，比方：默认引擎改成了InnoDB，更新了安全策略，性能方面的晋升，新增JSON数据类型，加强了sql模式及用户权限等等弱小的性能。因而，这个版本自从公布之后始终受到业界的欢送，也成为了泛滥开发者的首选数据库版本。 2018年4月，MySQL 8.0 正式公布。 上面咱们一起回顾一下各大版本的生命周期，重温一下这些经典的版本。 MySQL 大版本生命周期上面是各个版本的生命周期工夫范畴： Release        Release Date            End of life  MySQL 8.0      April 19, 2018       MySQL 5.7      October 21, 2015       October 21, 2023  MySQL 5.6      February 5, 2013       February 5, 2021  MySQL 5.5      December 3, 2010       December 3, 2018  MySQL 5.1      November 14, 2008      December 31, 2013 MySQL 5.0                             January 9, 2012上面是来自官网给出的一份生命周期数据：在 2023 年 10 月 21 日，MySQL 5.7 将达到其生命周期的起点（EOL,End of Life）。这意味着 Oracle 将不再为 MySQL 5.7 提供官网更新、谬误修复或安全补丁。 ...

作为一种Schema Free文档数据库，MongoDB因其灵便的数据模型，撑持业务疾速迭代研发，广受开发者欢送并被宽泛应用。在企业应用MongoDB承载利用的过程中，会因为业务上云/跨云/下云/跨机房迁徙/跨地区迁徙、或数据库版本升级、数据库整合、数据库拆分、容灾等业务场景，存在MongoDB迁徙或同步的业务诉求。 在MongoDB迁徙的过程中，其迁徙工夫、迁徙数据准确性及迁徙过程中业务的停机要求无疑是影响迁徙是否胜利的关键因素。由此，如何抉择适合的迁徙工具，提供高效、平安、精确的迁徙能力至关重要。 01 传统数据迁徙计划 传统的MongoDB迁徙个别基于mongodump及mongorestore等导入导出工具进行数据搬迁，应用这种搬迁工具个别存在如下问题： 停机工夫长，因为mongodump/mongorestore不反对增量数据的采集复制，在MongoDB迁徙期间，要求业务停机，停服工夫通常高达数小时/入地，对业务的挑战极大。特地当迁徙难度较高时，通常重复屡次迁徙，业务停服工夫更不可控。可靠性不高，不提供迁徙过程的观测、诊断与修复能力，迁徙过程中呈现谬误个别须要从新迁徙，迁徙难度较高。数据准确性难保障，此类工具因不提供对应的品质检测能力，所以迁徙的数据品质个别难以保障。大数据量迁徙挑战，因其容灾能力有余，不能很好撑持大数据量、大表的迁徙。02 NineData数据迁徙计划 为解决用户面临的MongoDB迁徙问题，玖章算术旗下的云原生智能数据管理平台NineData 推出了MongoDB 业务不停服数据迁徙能力。NineData实现了齐全自动化的全量数据迁徙，以及增量数据的采集复制能力。其中，增量数据迁徙能力，可能在构造迁徙及全量数据迁徙期间，实时监听采集源MongoDB数据变更产生的oplog，并在实现全量迁徙后，将变更数据实时复制到指标MongoDB，实现源/指标MongoDB的动静复制。基于变更数据迁徙能力，在MongoDB数据迁徙过程中，业务能够失常提供服务，无需停服。最终，业务可依据须要抉择对应工夫点切换到指标MongoDB，具体流程如下图。 除了提供业务不停服的迁徙能力外，NineData提供的MongoDB还具备如下能力： ▶︎ 大数据量或大表的迁徙能力 基于智能分片、动静攒批、并发迁徙、表级断点续传等多种技术能力，提供强劲迁徙能力。 ▶︎ 数据一致性比照 NineData提供了MongoDB的数据比照能力，可能进行高效的一致性比照，疾速辨认差别数据，并提供对应的勘误脚本，疾速勘误修复差别内容，无效保障迁徙数据品质。 ▶︎ 可观测可干涉能力 NineData提供具体的迁徙状态、停顿及详情信息，当呈现迁徙异样时，会提供多种诊断修复能力，帮忙您保障工作稳定性。同时，提供迁徙限流能力，您可依据业务须要，自定义迁徙速度，保障MongoDB的稳定性。 03 一分钟启动全自动化迁徙 尽管提供了比拟弱小的MongoDB迁徙能力，然而NineData应用起来非常简单，只须要花1分钟工夫实现工作配置，即能够齐全自动化实现数据的迁徙及同步过程。上面咱们来看下整个工作的配置过程： 3.1 配置复制工作 基于上述操作，实现复制数据源、复制对象及复制类型的抉择后，即可疾速启动MongoDB的全自动化迁徙。当实现工作启动后，NineData会主动进行全量数据迁徙及增量数据复制。 当数据迁徙实现后，也能够配置对应的数据比照进行数据一致性的校验，疾速发现、定位并修复差别数据。上面会对方才迁徙的mongodb数据进行数据一致性校验。 3.2 全量数据比照 如视频所示，针对方才迁徙的MongoDB数据能够通过配置运行数据比照工作，进行精准、残缺的数据比照。数据比照过程中，NineData会对每个Document的内容进行精准比照，并疾速发现差别内容，并针对性提供勘误脚本。 至此，当数据迁徙实现、数据校验及业务验证通过后，业务能够抉择一个低峰期进行MongoDB的停机切换，切换到新的数据库，至此实现整个迁徙过程。 04 写在最初 当然，除了MongoDB迁徙外，NineData反对MongoDB实例间的长期复制，可利用于数据容灾、读写拆散、测试数据构建等业务场景。同时，NineData也已反对数十种常见数据库的迁徙复制。NineData提供即开即用的SAAS模式，及企业专属集群模式，满足企业最高的数据安全合规要求。以后，NineData已在运营商、金融、制造业、地产、电商等多个行业实现大规模利用实际。如果您感兴趣的话，能够登录官网 https://www.ninedata.cloud/dbmigration，立刻开始收费应用。

晋升网络安全防御能力对于集体和组织来说都至关重要。网络安全是一个全面的概念，包含爱护个人信息、避免歹意攻打和确保网络资源的平安。在这篇文章中，我将介绍几个方面来进步网络安全防御能力其中包含IP地址查问。 首先，IP地址查问是一种网络安全工具能够帮忙用户理解特定IP地址的信息比方它的地理位置、ISP提供商和潜在的危险。通过进行IP地址查问，用户能够迅速辨认潜在的歹意流动，并采取适当的措施来爱护本人的网络。常见的IP地址查问工具包含Whois和IP查问网站。 其次，增强网络防火墙是进步网络安全防御能力的重要一环。网络防火墙能够无效地阻止未经受权的拜访和恶意软件的入侵管理员能够配置网络防火墙以容许特定的IP地址或端口拜访，并阻止潜在的威逼。此外，定期更新防火墙软件和及时修补破绽也是至关重要的。 除了IP地址查问和网络防火墙，强明码和多因素身份验证也是进步网络安全的重要措施。强明码应该蕴含数字、字母和特殊字符，并且应该定期更换。多因素身份验证是一种额定的平安层，要求用户提供两个或多个身份验证因素能力登录如明码、指纹或短信验证码。 另外，定期进行网络安全培训和教育也是进步网络安全防御能力的重要伎俩。员工应该理解常见的网络威逼和攻打技术，并学会辨认和应答这些威逼。组织能够组织网络安全培训课程，提供在线资源和指南以帮忙员工进步其网络安全意识和技能。 最初，及时更新和降级软件和操作系统也是进步网络安全防御能力的要害。软件和操作系统的破绽可能会被黑客利用，因而确保及时装置安全补丁和更新能够无效地缩小潜在的危险。 总而言之，通过IP地址查问、增强网络防火墙应用强明码和多因素身份验证进行网络安全培训和教育以及及时更新和降级软件和操作系统等多个方面的致力，能够进步网络安全防御能力，并无效地爱护集体和组织的网络资源。网络安全是一个一直倒退的畛域，一直学习和适应新的威逼和技术变动是放弃网络安全的要害。

如何装置MySQLdb?为了用DB-API编写MySQL脚本，必须确保曾经装置了MySQL。复制以下代码，并执行： import MySQLdb如果执行后的输入后果如下所示，意味着你没有装置 MySQLdb 模块： Traceback (most recent call last): File "test.py", line 3, in <module> import MySQLdbImportError: No module named MySQLdb装置MySQLdb，请拜访 http://sourceforge.net/projects/mysql-python ，(Linux平台能够拜访：https://pypi.python.org/pypi/MySQL-python)从这里可抉择适宜您的平台的安装包，分为预编译的二进制文件和源代码安装包。 如果您抉择二进制文件发行版本的话，装置过程根本装置提醒即可实现。如果从源代码进行装置的话，则须要切换到MySQLdb发行版本的顶级目录，并键入下列命令: $ gunzip MySQL-python-1.2.2.tar.gz$ tar -xvf MySQL-python-1.2.2.tar$ cd MySQL-python-1.2.2$ python setup.py build$ python setup.py install留神：请确保您有root权限来装置上述模块。 数据库连贯连贯数据库前，请先确认以下事项： 您曾经创立了数据库 TESTDB.在TESTDB数据库中您曾经创立了表 EMPLOYEEEMPLOYEE表字段为 FIRST_NAME, LAST_NAME, AGE, SEX 和 INCOME。连贯数据库TESTDB应用的用户名为 "testuser" ，明码为 "test123",你能够能够本人设定或者间接应用root用户名及其明码，Mysql数据库用户受权请应用Grant命令。在你的机子上曾经装置了 Python MySQLdb 模块。如果您对sql语句不相熟，能够拜访咱们的 SQL基础教程实例：以下实例链接Mysql的TESTDB数据库： import MySQLdb db = MySQLdb.connect("localhost", "testuser", "test123", "TESTDB", charset='utf8' ) cursor = db.cursor() cursor.execute("SELECT VERSION()") ...

2019 年，江苏省人社厅正式启动全省人社一体化信息平台建设项目。省人社一体化信息平台基于全省对立的人社业务规范、标准、流程和数据体系，以大众需要为导向，以省集中建设为重点，以云平台架构为根底，采纳人社部 LEAF6.2 中台架构，指标建设成为全省人社全业务省集中大平台，构建了省、市、县（市区）、街道（乡镇）、社区（村）5级纵向集中统一、横向粗放整合、纵横对接一体的服务体系，实现全省人社业务全层级、全流程、全渠道的一体化运行。 这一我的项目标记着江苏省全省人社数字化转型的启动，并作为国家人社部全国对立软件和省级集中全业务一体化零碎建设惟一试点。 2021年10月11日全省13个设区市、95个县（市、区）人社部门全副业务胜利切换上线，全省人社366个经办服务事项和352个网办事项实现“一网通办、就近可办、跨省通办”，新平台建设标记着全省人社信息化进入了零碎大集中、业务大交融、经办大对立、服务大协同、数据大共享的新阶段。 随着省集中的一体化平台建设的推动，全业务上云、数据集中得以实现，但同时数据安全危险也逐渐增大。 从数据内容上来看，人力资源和社会保障数据涵盖了国家、社会倒退过程中的社会保险、公共待业、人事人才、劳动关系、根底信息库等五大类。这就意味着开发运维人员在具体工作中，会接触到大量的数据信息、人员信息、岗位信息和工作信息等。一旦产生数据安全事件，如数据被窃取、篡改、泄露、失落，不仅会给社会治理与公共服务造成重大妨碍，还会对公民、社会和国家造成严重危害。 「防火防盗防管理员」 运维治理面临挑战“在咱们过来的运维管理工作中，为了确保开发运维人员对数据库的应用和平安操作，咱们制订了一系列规章制度，也有像堡垒机这样的产品对人员进行管控”，江苏省人社信息中心秦主任如是说，“但无论如何，开发人员仍须要间接连贯数据库，这其中就存在着微小的平安危险。开发运维人员是最理解数据也是最相熟数据的人，但同时也是最危险的。只管有监控和审计伎俩，但这些都是在预先进行查看和追踪，无奈在事先防止安全事故产生。” 通常，人力资源和社会保障单位的数据库保护都委托给第三方单位。因而，管理手段不欠缺、账号共享景象普遍存在，这也导致更加难以治理运维人员的行为。在江苏人社数字化转型的过程中，仅靠规章制度和传统的数据库安全管理模式曾经暴露出各种问题： 数据库管理工具简单多样：外部连贯数据库的形式简单多样，人员泛滥却没有对立的数据库拜访治理入口，无奈实现针对用户操作数据的对立治理。同时，第三方数据库工具还潜藏着平安危险和版权危险。 外部操作安全隐患：传统网络安全设施只能解决一部分问题，已有的堡垒机达到不了数据层，无奈实现无效管控。 权限滥用危险：外部数据库操作前没有严格的身份认证和细粒度的权限划分，存在高权限账号共用问题，容易产生越权操作等违规行为。 传统数据库审计乏力：传统数据库审计产品技术原理是对网络流量进行解析，对于数据库协定解析存在反复解析、解析不精确、长语句拆分解析等问题，行为记录数量微小且无奈保障其准确性，运维人员无奈针对数据库审计产品提供的行为记录进行无效剖析，重大影响运维效率和安全事件的剖析定性。 敏感信息透露危险：社会保险、待业、人事人才、居民根底信息等零碎中存在着大量的敏感信息，DBA 第三方人员等任何人只有具备数据库拜访权限都能间接接触到明文存储的敏感信息，从而引发敏感信息透露的危险。 “咱们以前会开玩笑的说，‘防火防盗防管理员’”，江苏人社的秦主任示意，“如何从事前、事中、事起初实现对这类‘最危险人群’的全链路管控是咱们要解决的最重要问题。” 拆解问题 明确五大需要事实上，早在 2015 年，国务院就公布了《促成大数据倒退口头大纲》，其中提到了数据安全治理。随后，2018年公布的《迷信数据管理方法》以及 2021 年通过的《中华人民共和国数据安全法》，进一步强调了对要害数据安全爱护的要求。特地是要害根底信息设施对平安的器重水平更高，须要在遵循等级爱护要求的根底上，进行额定强化。对于数据库的安全隐患如何可能失去无效解决，始终都是企业运维人员和 DBA 关注的焦点。 随着江苏人社一体化信息平台建设的逐渐深刻，他们提出了构建业余一体化数据安全管控平台的想法。 同时，联合以后运维管理工作中存在的问题和运维工作中的日常习惯，江苏人社对一体化管控平台提出了明确需要： 第一，对立人员拜访入口，所有人员仅通过一个平台实现对数据库的全副操作； 第二，强化对数据库运维人员的权限治理，全面实现对第三方人员违规操作、权限滥用等危险进行事先严格的权限管控，事中的全流程行为追踪，事变产生后可能精准溯源； 第三，代替日常运维工作中应用的 Navicat、PL/SQL 等客户端直连工具，躲避应用第三方软件的平安危险； 第四，细化对数据库及人员行为的操作审计，确保可能精准溯源； 第五，运维中的三权分立，将数据的设计者开发人员，执行者数据库管理人员，监督者平安运维人员分区而治互相牵制，缩小繁多角色对数据库系统的适度管制，确保不同职能之间的协调单干，以实现数据库数据安全的最优状态； 第六，对接江苏省人社一体化信息平台，借助权限零碎、音讯中台、工单零碎实现一体化零碎的反向赋能管控平台形成一个强耦合一体化，实现操作人员日常工作顺畅连接。 通过一体化数据安全管控平台建设，实现开发运维人员行为「可管、可控、可视、可追溯」，实现数据全生命周期中的各环节平安管控。 产品+服务 打造贴合业务的全链路管控平台秦主任示意，“之前咱们外部也定制开发过一个程序，但因是非专业公司开发，能力还是有所缺点，只能实现一些通用一般的操作，很多简单业余数据库的操作无奈实现，大数据量并发的问题也无奈解决，无奈做到让咱们开发运维人员所有的工作都在这平台上实现。” 基于明确的「一体化」想法，江苏人社在市场上寻找更为成熟业余的一体化管控平台产品。然而，选型的过程也并非一帆风顺。 人社业务极为简单，内容涵盖了人民生存的方方面面，这也意味着数据量之大、敏感数据之多超乎设想。 “咱们把市面上的产品根本都看了一遍，产品性能各有千秋，但没有一个平台可能满足咱们所有的需要。人社的业务非常复杂，有实时的交易，也有大批量操作。要求一个现成的平台来满足咱们所有的需要，这可能性十分小。所以，咱们在抉择平台的时候，更看重单干。除了思考平台自身的性能，更看重其背地公司的服务能力，最终咱们抉择了 CloudQuery。”秦主任如是说。 CloudQuery 作为一体化数据安全操作平台，自身已具备了一体化管控平台弱小的管控和操作性能。它以数据流向贯通了整个数据安全过程，实现数据库治理对立接入，通过一个集中管控平台实现对数据库的治理。可依据不同人员的应用性质从不同业务层面进行权限赋予，实现人员的权限拆散和细粒度管控。 而 CloudQuery 自主研发的 SQL 编辑器，则可代替国外第三方数据库操作工具，解决存在的平安危险和版权危险隐患。针对数据库操作行为，进行操作中的同步监控。 值得一提的是，区别于传统数据库审计产品，CloudQuery 的审计后果能达到百分百精确。针对用户在平台上的所有动作，可进行全方位审计，留存日志和记录，通过动静监测用户操作行为，并通过页面展现具体的行为记录和平安趋势，无效加重运维人员审计工作量，实现精准行为审计。 此外，联合江苏人社的理论业务需要，CloudQuery 团队对产品进行了多重降级革新，使平台的操作和管控能力更加贴合人社业务。于此同时，也实现了与江苏人社一体化信息平台的对接，从登录、到流程审批、音讯告诉、日志治理，无缝连接操作人员日常工作，无效晋升人员合作效率。 至此，江苏人社的一体化数据安全管控平台建设领有了欠缺的解决方案。 在数据的全流程周期中，通过 CloudQuery 一体化数据安全管控平台，实现了事先的权限管控和身份认证，事中的访问控制和资产爱护，预先的行为审计和溯源剖析，实现了对「危险人员」的全方位管控，进步数据库运维效率和平安管理水平。 （下一篇「成绩篇」，将具体讲述江苏人社的 CloudQuery 利用及其建设成果，敬请期待~）

简介Kubernetes 作为以后工业界风行的云原生容器编排和管理工具，在大量我的项目实际中被应用。目前，OpenMLDB 的离线引擎和在线引擎，均曾经残缺反对了基于 Kubernetes 的部署，能够实现更为不便的治理性能。本文将别离介绍离线和在线引擎基于 Kubernetes 的部署攻略。 留神，离线和在线引擎基于 Kubernetes 的部署是两个齐全解耦的部署策略，用户能够别离针对不同的需要，为离线或者在线引擎应用基于 Kubernetes 的部署。除了基于 Kubernetes 部署，离线引擎也反对基于 local 本地模式和基于 yarn 模式进行部署；在线引擎也反对原生的不依赖容器的部署形式。这些部署策略能够在理论场景中灵便混合应用，以满足生产环境需要。 离线引擎应用 Kubernetes 后端部署治理 Spark 工作的 Operator请参考 spark-on-k8s-operator 官网文档。以下是应用 Helm 部署到 default 命令空间的命令，能够依据须要批改命令空间以及权限信息。 helm install my-release spark-operator/spark-operator --namespace default --create-namespace --set webhook.enable=truekubectl create serviceaccount spark --namespace defaultkubectl create clusterrolebinding binding --clusterrole=edit --serviceaccount=default:spark部署胜利后，能够应用 spark-operator 提供的代码示例测试 Spark 工作是否能够失常提交。 HDFS 反对如果须要配置 Kubernetes 工作读写 HDFS 数据，须要提前准备 Hadoop 配置文件并且创立 ConfigMap 。依据须要可批改 ConfigMap 名称和文件门路，创立命令示例如下： kubectl create configmap hadoop-config --from-file=/tmp/hadoop/etc/离线引擎配置 Kubernetes 反对离线引擎的 TaskManager 配置文件中能够指定 Kubernetes 相干配置，相干配置项如下 ...

前言在上一篇文章中，咱们介绍了弹性数据库连贯生效的背景，并探讨了HikariCP连接池探活策略的相干内容。在本文中，咱们将会持续探讨另一个线上罕用的连接池——Druid，并为您介绍如何在应用Druid时实现最佳实际的弹性数据库连接池探活策略。 DruidDruid的版本迭代更新比拟快，同时探活配置的参数也比拟多，这导致即便是雷同的参数在不同的版本中达到的成果也可能不一样。但与探活相干的逻辑实现只存在源码里的两个函数里， 咱们先列举一下跟Druid探活相干的参数，在具体看一下源码的实现对这些参数的应用。日后咱们在开发中遇到配置探活不失效的状况下，能够看一下对应版本源码来判断本人的探活是否配置正确。 上面是与Druid探活相干的参数： 参数名称阐明默认值initialSize初始化时建设物理连贯的个数。初始化产生在显示调用init办法，或者第一次getConnection时。0minIdle最小连接池数量。0maxActive最大连接池数量。8testOnBorrow申请连贯时执行validationQuery配置的SQL检测连贯是否无效，做了这个配置会升高性能。falsetestOnReturn偿还连贯时执行validationQuery检测连贯是否无效，做了这个配置会升高性能。falsetestWhileIdle倡议配置为true，不影响性能，并且保障安全性。在连接池中申请连贯的时候检测，如果闲暇工夫大于timeBetweenEvictionRunsMillis，执行validationQuery检测连贯是否无效。大多数版本为TruetimeBetweenEvictionRunsMillis1) Destroy线程会检测连贯的间隔时间，每隔这个值的工夫就会执行一次DestroyTask。 2) testWhileIdle的判断根据，具体看testWhileIdle属性的阐明。大多数版本是1分钟keepAlive连接池中的minIdle数量以内的连贯，闲暇工夫超过minEvictableIdleTimeMillis，则会执行探活操作此参数在1.0.28以上的版本才反对 具体阐明参考官网文档。falsekeepAliveBetweenTimeMillis配合keepAlive应用在低版本不反对，如果闲暇工夫小于timeBetweenEvictionRunsMillis但大于keepAliveBetweenTimeMillis扔执行探活操作大多数版本是2分钟validationQuery用来检测连贯是否无效的sql，要求是一个查问语句。select 1validationQueryTimeout单位：秒，检测连贯是否无效的超时工夫。底层调用jdbc Statement对象的void setQueryTimeout(int seconds)办法 minEvictableIdleTimeMillis连贯闲暇工夫大于该值时敞开闲暇连贯大于minIdle的连贯，相似hikaricp的idleTimeout30分钟maxEvictableIdleTimeMillis连贯闲暇工夫大于该值时不论minIdle都敞开该连贯，相似hikaricp的maxlifetime（低版本不反对）7小时Druid的探活次要有以下两个函数来实现： com.alibaba.druid.pool.DruidDataSource#getConnectionDirectgetConnectionDirect是每次从连接池中取连贯时会被调用的函数。咱们从上面的代码中能够看出，如果testOnBorrow为true，则每次获取连贯之前都会检测连贯是否无效。如果testOnBorrow为false且testWhileIdle为true，则须要判断连贯的闲暇工夫是否超过timeBetweenEvictionRunsMillis设置的值，如果超过则进行探活检测。生效的连贯会被抛弃，并且会补充到连接池的minIdle数量。timeBetweenEvictionRunsMillis在大多数版本中的默认值为1分钟。只有这个值设置的工夫小于十分钟，并且保障testWhileIdle开启，就能保障拿不到网关敞开的生效连贯。 在不反对keepalive的低版本中，只能依附testOnBorrow或testWhileIdle来进行探活。倡议配置testWhileIdle来进行探活。在高并发的场景下，这种形式的性能耗费会更小一些。 com.alibaba.druid.pool.DruidDataSource#shrink(boolean, boolean)在上面的代码中咱们能够看出，shrink办法是在DestroyTask线程的run办法中调用的，用于销毁连接池中的连贯。如果timeBetweenEvictionRunsMillis大于0，则每隔这个工夫距离就会调用destroyTask.run(boolean, boolean)办法，即执行shrink办法。 从下面的代码中能够看出，shrink办法会应用keepAlive参数。须要留神的是，在不同版本的Druid中，keepAlive参数的反对和实现逻辑可能不同。官网倡议在应用keepAlive参数时，应该应用1.1.21以上的版本。只管官网文档中阐明了闲暇工夫超过minEvictableIdleTimeMillis，就会执行探活操作，然而在高版本中，这个探活操作的执行工夫也受到了keepAliveBetweenTimeMillis参数的影响。因而，在高版本中，如果想要正确地应用keepAlive参数，就须要理解其在具体版本中的实现逻辑。 上面代码是1.1.10和1.1.21版本中对于shrink办法的源码比照： 首先看一下1.1.10版本的源码，它首先会判断连贯闲暇工夫是否大于minEvictableIdleTimeMillis，如果是，则接下来进行第二步的判断：是否是多于minIdle的闲暇连贯。如果是，就将这些连贯退出到驱赶连贯的数组中，以便进行后续的驱赶操作。如果不是，就再次判断连贯闲暇工夫是否大于maxEvictableIdleTimeMillis，如果是，则将这些连贯退出到驱赶连贯的数组中。如果也不是，则进行最初的判断：是否开启了keepAlive配置。如果开启了，就将这些连贯退出到保活连贯数组中，以进行后续的探活操作。 在1.1.21版本中，shrink办法的总体逻辑与1.1.10版本相似，然而新增了一个名为keepAliveBetweenTimeMillis的参数。这个参数决定了应用keepAlive进行探活的工夫距离，其默认值为2分钟，keepalive开启且闲暇工夫大于这个值会进行探活。 另一个不同点是，在进行探活操作时，1.1.10版本仅会敞开有效的连贯，但1.1.21版本则更进一步，除了敞开有效连贯外，还会主动增加连贯以达到minIdle的最小连接数。 1.1.10 1.1.21 总结，druid的探活参数在1.0.28版本之前没有定时的探活性能只能在每次拿到连贯前进行检测是否无效，倡议配置testWhileIdle为true在高并发状况下不会太影响性能，如果对可用性要求高的能够开启testOnBorrow，以在每次获取连贯时检测连贯的有效性。在高版本中能够用keepAlive参数对连贯进行保活。针对线上应用Druid连接池的利用倡议应用反对keepAlive的1.1.21或者更高版本。 JED配置模版：Druid1.1.10<propertyname="testWhileIdle"value="true"/> <propertyname="validationQuery"value="SELECT 1"/> <propertyname="timeBetweenEvictionRunsMillis"value="30000"/> <propertyname="minEvictableIdleTimeMillis"value="300000"/><propertyname="keepAlive"value=true/>此版本反对keepAlive能够配置minEvictableIdleTimeMillis工夫小于10分钟，可能高效的进行探活避免网关敞开连贯。 Druid1.1.9同1.1.10 Druid1.0.9<propertyname="testWhileIdle"value="true"/> <propertyname="validationQuery"value="SELECT 1"/> <propertyname="timeBetweenEvictionRunsMillis"value="30000"/> <propertyname="minEvictableIdleTimeMillis"value="300000"/>此版本不反对keepAlive只能在获取连贯对象的时候检测，对可用性高的也能够开启testOnBorrow。 作者：京东批发 王雷鑫 起源：京东云开发者社区 转载请注明起源

引言：8 月 15 日，CloudQuery 数据操作管控平台与阿里云 PolarDB 数据库管理软件，实现产品集成认证测试。也在以下性能上欠缺了用户应用 PolarDB 的体验，使数据库的治理更加平安高效。 反对在 CloudQuery 中创立连贯，便于进行数据库管控。反对编辑连贯、资源纳管、连接池治理以及连贯设置，可设置此连贯下的事务模式、最大连接数、最大等待时间、闲暇连贯超时工夫、连贯管理员等。反对开启/敞开测试环境、暗藏模式，设置此连贯的同步复核形式。反对受权治理，受权粒度到表级别。反对动静脱敏，可针对字段配置脱敏规定。反对在 CQ 中执行 SQL 语句对此连贯下的数据进行治理。反对后果集导出。反对后果集编辑。反对执行日志的查看。 不同的功能模块如何操作？权限管控在 CloudQuery 平台中创立 PolarDB 连贯，将 PolarDB 纳入 CloudQuery 平台进行管控。 首先，CloudQuery 平台实现了对连贯的管控，包含以下四项。 1）连贯概览：查看/编辑连贯信息、监控连贯用户数以及连贯下的 SQL 执行总数、图表视图查看连贯的逻辑库数、schema 数量、表数量。 2）资源管理：资源管理可到 schema 层级，可开启连贯下局部 schema，开启后的资源可在 CloudQuery 平台中实现权限管控、数据操作和权限管控。 3）连接池治理：查看以后连贯下 SQL 语句、执行打算以及连贯时长等信息。 4）连贯设置：设置连贯下的事务模式、最大连接数、最大等待时间、闲暇连贯最大等待时间等。 综上，实现了对连贯级的设置和治理，监控并纳管连贯资源。 其次，CloudQuery 平台实现了对资源操作的权限管控，可细粒度到表级别。 1）反对对普通用户授予数据库对象操作权限，包含自定义权限等级（DML、DQL、DDL），以及授予右键菜单、后果集操作、导出性能权限，实现真正意义上的权限管控。 2）反对批量受权，可依据用户属性判断是否领有某些权限，用户退出某个项目组就领有此项目组的权限。 3）反对分级受权治理，可将连贯下的资源分配多个管理员。 数据操作CloudQuery 平台自带 SQL 编辑器（类 似PL/SQL、Navicat），SQL 编辑器反对语法提醒、关键词高亮、SQL 丑化等，不扭转用户的应用习惯。 数据保护CloudQuery 平台反对敏感数据爱护，可设置多种脱敏算法，依据需要抉择动静脱敏/动态脱敏。反对自定义拜访数据库工夫，如工作日拜访，非工作禁止拜访；也反对行过滤，依据用户属性设置属于此用户可见的数据范畴。 审计剖析在 CloudQuery 平台上对 PolarDB 所有的操作都进行了审计，包含 SQL 执行语句：语句内容、语句执行时长、胜利/失败、执行语句的权限起源、哪个用户执行等。并且，能够图像化展现此数据源下不同操作类型的执行次数和均匀执行时长。 CloudQuery & PolarDB 案例现阶段，CloudQuery 和 PolarDB 曾经为不同行业的多家独特用户提供了优质的服务，包含但不限于大型保险公司、证券公司等。 CloudQuery 和 PolarDB 的独特应用也为这些用户提供了全面的数据解决方案，满足了他们对数据处理、查问和存储的需要。 ...

HHDBCS反对新增、关上、删除、级联删除、清空、级联清空、重命名、属性查看等操作。 1 新增右键树形构造的表节点，在弹出菜单中选择“新增”，会弹出创立表的表单，能够输出表名称，正文，点击增加列，输出列名，抉择类型，默认值等。表单下有3个tab页：列：增加字段和删除字段操作惟一键：增加和删除惟一键外键：为表增加外键关联 2 关上抉择表，右键，点击“关上”，主面板将关上一个tab页显示表数据. 3 清空选中表节点下的具体表，右键弹出菜单中选择“清空”，抉择“是”。级联清空，当表有外键关联时，进行级联操作清空。 4 删除选中表节点下的具体表，右键弹出菜单中选择“删除”或“级联删除”，抉择“是”。 5 查看表属性选中表节点下的具体表，右键弹出菜单中选择“属性”。

9月6日，由山东省工信厅、济南市人民政府、凋谢原子开源基金会领导，济南市工信局及浪潮联结主办的“软件名城看济南”暨浪潮软件技术大会顺利举办，深度聚焦软件智能技术开发、助力企业数字化治理、赋能产业数智化转型等热点话题。 KaiwuDB CTO 魏可伟受邀缺席，以“KaiwuDB 技术与社区摸索之路”为题开展分享，与开源基金会共建单位、科技企业、科研机构、高校等 300 余名开源技术畛域代表共谈开源技术及社区倒退将来。 KaiwuDB CTO 魏可伟发表主题演讲 作为浪潮旗下首款分布式多模数据库，KaiwuDB 在技术研发、人才培养、社区工作、行标制订等方面踊跃投身行业与社区生态建设。 魏可伟介绍：KaiwuDB 继续推动产品在技术上的冲破与翻新，目前已领有就地计算、多模数据库架构、主动式时序引擎、超速剖析引擎、原生 AI 等 8 项核心技术，累计取得 16 项自有产品软著受权，近 300 余项发明专利受理。在设计上，KaiwuDB 针对工业物联网、数字能源等场景进行了优化，领有海量时序数据高吞吐写入、高性能大批量简单查问、集群部署等外围性能，可高效实时处理海量数据，对立运管、低成本运维帮忙用户降本增效，真正做到了好用易用，为用户业务发展保驾护航。 同时，KaiwuDB 在推动数据库架构技术与原生 AI 技术交融倒退的摸索实际。在 AI4DB 方向，得益于智能化引擎，KaiwuDB 数据库具备了自运维、自治理、自调优和故障自诊断能力；通过机器学习赋能数据挖掘及智能剖析，数据库中海量数据的法则和模式清晰出现，为决策提供科学依据。 在 DB4AI 方向，KaiwuDB 创造性地将算法内置到数据库中，实现了在数据库系统中进行模型训练的“Modelops in DB”。这一技术极大简化了模型的零碎搭建流程，并无效升高因数据传输导致的算法准确度偏差，让智能剖析更精确，更好地辅助管理决策。 魏可伟示意：将来，KaiwuDB 将持续踊跃投身行业与社区生态建设工作，为数据库行业与社区生态的倒退贡献力量，也欢送更多敌人退出咱们一起摸索。

随着科技的倒退，恶意软件成为了互联网世界中的一大威逼。恶意软件是指那些在未经用户受权的状况下，通过违反用户志愿或者对用户计算机系统造成毁坏而植入的软件。恶意软件的目标往往是为了取得用户的隐衷信息、进行欺诈行为或者对系统进行毁坏。以下是常见的几种恶意软件类型及其危害。 1.病毒（Virus）：病毒是最为人熟知并且最常见的恶意软件类型之一。它的特点是通过在其余程序中插入本身代码来流传并感化其余文件一旦感化，病毒会毁坏文件或者零碎的失常运行，并且能够自我复制，从而扩散到更多的文件和零碎中。 2.木马（Trojan horse）：木马是一种伪装成非法软件的恶意软件，经常通过坑骗用户的形式获取用户的敏感信息。木马通常会暗藏在其他软件中，并且在用户运行该软件时，恶意代码会被激活并开始盗取用户信息。 3.蠕虫（Worm）：蠕虫是一种可能自我复制并通过网络流传的恶意软件。它通常会占用大量系统资源并导致网络拥挤蠕虫的传播速度通常很快，能够疾速感化大量的计算机系统。 4.特务软件（Spyware）：特务软件是一种以用户不知情的形式收集用户信息的恶意软件。它能够监督用户的上网行为、记录键盘输入以及窃取用户的个人信息。特务软件往往会悄无声息地存在于用户的计算机中，并悄悄地监督用户的流动。 5.广告软件（Adware）：广告软件是一种常见的恶意软件类型。它以显示广告为目标，并且会在用户浏览网页或者运行软件时弹出广告。广告软件通常会重大烦扰用户的失常应用，也可能会导致系统运行迟缓。 这些恶意软件的存在给用户的电脑系统和个人隐私带来了微小的危害。他们可能会导致系统解体，使用户丢失数据。此外，恶意软件还可能盗取用户的集体和金融信息导致财务损失和身份偷盗。恶意软件还能够使用户成为网络攻击的发起者，从而导致违法行为的产生。恶意软件不仅对个人用户无害，也对企业和政府机构造成了微小的危害。 为了缩小恶意软件的危害，用户应该保持警惕并采取一些预防措施。首先，定期更新操作系统和安全软件以确保零碎具备最新的安全性补丁。其次，审慎下载和装置来自不可信起源的软件。此外，定期备份数据，并在必要时复原零碎。最重要的是，教育用户如何辨认和防止恶意软件不随便点击可疑的链接或关上未知的附件。 https://www.ipdatacloud.com/?utm-source=Lik&utm-keyword=?1094恶意软件的一直变动和进化让网络安全变得更为重要。只有通过一直的学习和增强进攻措施，能力更好地爱护本人的电脑和个人信息免受恶意软件的威逼。

（一）背景三年前，我用 Fiber(协程) 实现了 TerarkDB 中 MultiGet 的 IO 并发，因为 TerarkDB 分叉自 RocksDB 5.18，其 MultiGet 实现简略间接，所以我能够用 10 行代码就对其实现 Fiber(协程) 革新，并取得数量级的性能晋升。然而在 ToplingDB 中，为了充沛借助社区力量，排汇社区成绩，咱们总是在 RocksDB 的最新版上开展工作，基本上每一两个月就会合并一次 RocksDB 上游代码。然而最近两三年，上游 RocksDB 对 MultiGet 进行了大规模的批改：针对每个 SST 的 MultiRead，在 FSRandomReadFile 中减少了 MultiRead 接口因为 MultiGet 中多个 Key 落到同一个 SST 的概率太低，从而对单个 SST 的 MultiRead 收益太小所以 RocksDB 又在 FSRandomReadFile 中减少了 ReadAsync 接口MultiGet 的整个执行链路都进行了相应批改以反对 MultiRead 和 ReadAsync其中用到了 folly::Coroutine和 C++20 的 Coroutine默认状况下 Coroutine 选项是敞开的(管制宏USE_COROUTINES)Coroutine 选项关上时，同时会关上 USE_FOLLY通过另一个宏 WITH_COROUTINES 来生成整个调用链路上的所有相干函数的异步版：TableCache::MultiGet 的异步版 MultiGetAsyncVersion::MultiGetFromSST 的异步版 MultiGetFromSSTAsyncTableCache::MultiGet 的异步版 MultiGetAsyncBlockBasedTable::RetrieveMultipleBlocks 的异步版 RetrieveMultipleBlocksAsync在调用理论干活的 MultiGet 之前，还须要简单的 Prepare 操作结构专门的 MultiGetContext 对象，调用链上的函数都减少 MultiGetContext::Range 参数MultiGet 减少了额定的参数 is_sorted，示意要 MultiGet 的多个 Key 是否曾经排序，如果未排序，就要先进行排序就连不须要 IO 的 MemTable 也减少了 MultiGet 接口所有这些下来，相干的代码批改数以万行计，并且因为不必要的计算太多，对性能有较大影响，在 Cache 命中的状况下（不须要 IO），反而对性能有很大的负面影响。BTW: 甚至于连 Linux kernel io_uring 的作者 Jens Axboe 也给 RocksDB 当外援：（二）ToplingDB 怎么办ToplingDB 中有三种 SST：Topling Fast Table(SST)极速，个别常驻内存，并且仅用于 L0 和 L1Topling Zip Table(SST)应用可检索内存压缩算法，间接在压缩的数据上执行搜寻。压缩率和性能都远高于 RocksDB BlockBasedTable（不论它是用 zstd 还是 lz4/snappy/gzip/bzip）。用于 L2 及更上层Topling Auto Sort Table(SST)容许输出的数据无序，用于 MyTopling(MySQL on ToplingDB) 中索引创立以及批量加载在这三种 SST 中，只有 Topling Zip Table 须要 IO 异步(实现 IO 并发)，如果也依照 RocksDB 那一套来实现，会有诸多问题：如前所述，Cache 命中时，性能反而大幅升高须要的代码批改太多，RocksDB 有寰球顶级的弱小的研发团队，即使是走在谬误的路线上，也能够堆人，堆资源，硬是凭借鼎力出奇观，而咱们显然不能那样干RocksDB 的这个异步机制仍在 Experiment 状态，不光稳定性存疑，而且处在一直的变动演进中，在它这个异步框架内实现，就要带着它这个包袱，它有 Bug，咱们也遭殃，它改了接口，咱们也得跟着改依照我事倍功半的信条：改起码的代码，获最大的收益，这个收益，不仅仅是性能上的收益，还有代码的模块化、可读性、可维护性、可复用性……所以，通过认真思考与衡量，ToplingDB 的 MultiGet 还是得由我本人来亲自实现。（三）实现计划协程分无栈协程和有栈协程，无栈协程实践上性能更好，然而一来须要编译器反对，二来须要批改全链路代码。RocksDB 的 Async IO 实现其实是个有栈协程和无栈协程的混合体。编译器反对还好说，当初支流编译器(gcc,clang,msvc)都反对 C++20 的协程，然而批改全链路代码这是不能忍耐的。所以咱们必须应用有栈协程，依然连续之前 TerarkDB 的抉择：boost fiber（再加上我的改良）。有栈协程实践上性能不如无栈协程，然而凭借低劣的实现，其性能代价（协程切换）曾经低到大抵等同于一个函数调用。但有栈协程最大的劣势其实是几近完满的兼容性：不须要编译器反对，不须要批改现有代码，甚至连现有二进制库都能够齐全复用。io 模型上，三年前应用的是 linux aio，当初天然要应用 io_uring，然而对外的函数接口没变，仍然是：ssize_t fiber_aio_read(int fd, void* buf, size_t len, off_t offset);这个函数原型跟 posix pread 完全相同：ssize_t pread(int fd, void *buf, size_t count, off_t offset);只有下层代码开启多个 fiber 执行 fiber_aio_read，就主动取得了 io 并发的能力，在 MultiGet 中：if (read_options.async_io) { gt_fiber_pool.update_fiber_count(read_options.async_queue_depth); size_t memtab_miss = 0; for (size_t i = 0; i < num_keys; i++) { ...

近日，CloudQuery 数据操作管控平台与阿里云 PolarDB 数据库管理软件，实现产品集成认证测试。也在以下性能上欠缺了用户应用 PolarDB 的体验，使数据库的治理更加平安高效。1.反对在 CloudQuery 中创立连贯，便于进行数据库管控。2.反对编辑连贯、资源纳管、连接池治理以及连贯设置，可设置此连贯下的事务模式、最大连接数、最大等待时间、闲暇连贯超时工夫、连贯管理员等。3.反对开启/敞开测试环境、暗藏模式，设置此连贯的同步复核形式。4.反对受权治理，受权粒度到表级别。5.反对动静脱敏，可针对字段配置脱敏规定。6.反对在 CQ 中执行 SQL 语句对此连贯下的数据进行治理。7.反对后果集导出。8.反对后果集编辑。9.反对执行日志的查看。 不同的功能模块如何操作？权限管控在 CloudQuery 平台中创立 PolarDB 连贯，将 PolarDB 纳入 CloudQuery 平台进行管控。首先，CloudQuery 平台实现了对连贯的管控，包含以下四项。1）连贯概览：查看/编辑连贯信息、监控连贯用户数以及连贯下的 SQL 执行总数、图表视图查看连贯的逻辑库数、schema 数量、表数量。2）资源管理：资源管理可到 schema 层级，可开启连贯下局部 schema，开启后的资源可在 CloudQuery 平台中实现权限管控、数据操作和权限管控。3）连接池治理：查看以后连贯下 SQL 语句、执行打算以及连贯时长等信息。4）连贯设置：设置连贯下的事务模式、最大连接数、最大等待时间、闲暇连贯最大等待时间等。综上，实现了对连贯级的设置和治理，监控并纳管连贯资源。 其次，CloudQuery 平台实现了对资源操作的权限管控，可细粒度到表级别。1）反对对普通用户授予数据库对象操作权限，包含自定义权限等级（DML、DQL、DDL），以及授予右键菜单、后果集操作、导出性能权限，实现真正意义上的权限管控。2）反对批量受权，可依据用户属性判断是否领有某些权限，用户退出某个项目组就领有此项目组的权限。3）反对分级受权治理，可将连贯下的资源分配多个管理员。 数据操作CloudQuery 平台自带 SQL 编辑器（类 似PL/SQL、Navicat），SQL 编辑器反对语法提醒、关键词高亮、SQL 丑化等，不扭转用户的应用习惯。 数据保护CloudQuery 平台反对敏感数据爱护，可设置多种脱敏算法，依据需要抉择动静脱敏/动态脱敏。反对自定义拜访数据库工夫，如工作日拜访，非工作禁止拜访；也反对行过滤，依据用户属性设置属于此用户可见的数据范畴。 审计剖析在 CloudQuery 平台上对 PolarDB 所有的操作都进行了审计，包含 SQL 执行语句：语句内容、语句执行时长、胜利/失败、执行语句的权限起源、哪个用户执行等。并且，能够图像化展现此数据源下不同操作类型的执行次数和均匀执行时长。 对于 CloudQueryCloudQuery 是一款面向企业的云原生一体化数据库管控平台。致力于为开发者、数据资产管理者等技术人员，打造一个一站式平安可控的数据操作平台，CloudQuery 赋予用户仅通过一个 web 浏览器，即可实现数据安全拜访、数据分析治理、数据脱敏等各类简单场景的能力。 CloudQuery 外围能力自研数据库客户端：多种数据库，一个治理和开发工具。反对多类型数据库：笼罩 PolarDB、OceanBase、Oracle、Mysql、PostgreSQL、HIVE、达梦等20多种数据库，并在一直迭代中。用户对立治理：一个组织身份账户，即可拜访所有数据源，简化数据库管理工作。数据透露防护：根据数据安全法要求无效爱护企业数据，防止数据泄露和滥用。高危操作拦挡：操作语句逐条解析，反对多种高危行为辨认与拦挡。终端平安防护：防止传统数据库客户端导致的账号透露、数据透露、版权问题。 对于 PolarDBPolarDB 是阿里云自研的云原生数据库产品家族，采纳存储计算拆散、软硬一体化设计，既领有分布式设计的低成本劣势，又具备集中式的易用性，可满足大规模利用场景需要。2021 年，阿里云把数据库开源作为重要策略方向，正式开源自研外围数据库产品 PolarDB ，助力开发者和客户通过开源版本疾速应用阿里云数据库产品技术，并参加到技术产品的迭代过程中来。 开源云原生数据库 PolarDB 分布式版（PolarDB for Xscale，简称“PolarDB-X”），是阿里云自主研发的高性能云原生分布式数据库产品，其采纳 Shared-nothing 与存储计算拆散架构，反对程度扩大、分布式事务、混合负载等能力，具备企业级、云原生、高可用、高度兼容 MySQL 零碎及生态等特点。开源云原生数据库 PolarDB PostgreSQL 版（PolarDB for PostgreSQL，简称“PolarDB-PG”），是阿里云自主研发的云原生关系型数据库产品，100% 兼容 PostgreSQL；采纳基于 Shared-Storage 的存储计算拆散架构，具备极致弹性、毫秒级提早、HTAP 的能力和高牢靠、高可用、弹性扩大等企业级数据库个性。同时，PolarDB 具备大规模并行计算能力，能够应答 OLTP与OLAP 混合负载。 ...

数据导入吞吐是 OLAP 零碎性能的重要衡量标准之一，高效的数据导入能力可能减速数据实时处理和剖析的效率。随着 Apache Doris 用户规模的不断扩大， 越来越多用户对数据导入提出更高的要求，这也为 Apache Doris 的数据导入能力带来了更大的挑战。 为提供疾速的数据写入反对，Apache Doris 存储引擎采纳了相似 LSM Tree 构造。在进行数据导入时，数据会先写入 Tablet 对应的 MemTable 中，MemTable 采纳 SkipList 的数据结构。当 MemTable 写满之后，会将其中的数据刷写（Flush）到磁盘。数据从 MemTable 刷写到磁盘的过程分为两个阶段，第一阶段是将 MemTable 中的行存构造在内存中转换为列存构造，并为每一列生成对应的索引构造；第二阶段是将转换后的列存构造写入磁盘，生成 Segment 文件。 具体而言，Apache Doris 在导入流程中会把 BE 模块分为上游和上游，其中上游 BE 对数据的解决分为 Scan 和 Sink 两个步骤：首先 Scan 过程对原始数据进行解析，而后 Sink 过程将数据组织并通过 RPC 分发给上游 BE。当上游 BE 接收数据后，首先在内存构造 MemTable 中进行数据攒批，对数据排序、聚合，并最终下刷成数据文件（也称 Segment 文件）到硬盘上来进行长久化存储。 而咱们在理论的数据导入过程中，可能会呈现以下问题： 因上游 BE 跟上游 BE 之间的 RPC 采纳 Ping-Pong 的模式，即上游 BE 一个申请解决实现并回复到上游 BE 后，上游 BE 才会发送下一个申请。如果上游 BE 在 MemTable 的处理过程中耗费了较长的工夫，那么上游 BE 将会期待 RPC 返回的工夫也会变长，这就会影响到数据传输的效率。当对多正本的表导入数据时，须要在每个正本上反复执行 MemTable 的处理过程。然而，这种形式使每个正本所在节点都会耗费肯定的内存和 CPU 资源，不仅如此，简短的解决流程也会影响执行效率。为解决以上问题，咱们在刚刚公布不久 Apache Doris 2.0 版本中（https://github.com/apache/doris/tree/2.0.1-rc04 ），对导入过程中 MemTable 的攒批、排序和落盘等流程进行优化，进步了上下游之间数据传输的效率。此外咱们在新版本中还提供 “单正本导入” 的数据散发模式，当面对多正本数据导入时，无需在多个 BE 上反复进行 MemTable 工作，无效晋升集群计算和内存资源的利用率，进而晋升导入的总吞吐量。 ...

导读蜀海供应链是集销售、研发、洽购、生产、品保、仓储、运输、信息、金融为一体的餐饮供应链服务企业。2021年初，蜀海信息技术核心大数据技术研发团队开始测试用DolphinScheduler作为数据中台和各业务产品我的项目的任务调度零碎工具。本文次要分享了蜀海供应链在海豚晚期旧版本实际过程中的摸索翻新和在跨大版本升级部署过程中的教训，心愿对大家有所启发和帮忙。 作者简介 杜全，蜀海供应链大数据工程师，参加蜀海大数据平台和数据中台建设。 业务背景介绍咱们公司的次要业务如下图所示： 领导驾驶舱：提供给高层领导查看的数据准实时剖析，T+1经营剖析、产品毛利类、市场价格等报表财务：各类日报、月报、年度报表；对账、毛利报表、指标表等客户销售：客户采销类实时报表、日报、月报各个维度的数据分析及查问销售明细数据供应商类：洽购剖析、询价报表、供应商等级、供应商工作台、供应商对账剖析，洽购策略优化等仓储：库存周转、库位、实时库存等各种维度数据指标及报表需要物流运输类：准点率、温控、运输成本，调度等剖析数据分析师：疾速响应各种数据分析需要，及高层领导各种长期数据需要，数据挖掘及各种实时交互式剖析各业务经营/策略/负责人：次要查看各自业务经营的整体状况，查问数据中台的各该业务各种维度实时聚合数据以及一些其余业务的数据报表及剖析需要。 集成降级教训在数据中台建设过程中，好的大数据调度组件往往能达到事倍功半的作用，咱们团队也深知这一点，因而抉择了海豚调度作为蜀海供应链数据中台的调度零碎，并通过从v1.3.6的耦合集成部署革新到v3.1.8解耦集成部署的革新的阶段，在这个过程中也遇到了各种各样的问题并及时提供了解决方案，现就这些做一下分享，心愿能够帮忙到各位小伙伴。 海豚调度旧版本集成之前团队集成的旧版本为v1.3.6，曾经在生产环境稳固运行两年多了，这里次要简略介绍下过后集成到数据中台的细节及随着业务量剧增带来的痛点。 （1）API服务、UI革新对接集成到中台 前端UI革新基于dolphinscheduler-ui我的项目二次开发（改变量大）适配中台款式，集成各海豚调度菜单（首页、项目管理、资源核心、数据源核心、监控核心、平安核心）到中台，对立走中台路由网关。 后端API接口服务革新基于dolphinscheduler-api我的项目二次开发，交融中台用户体系革新。外围革新点如下： ①　革新点1：LoginHandlerInterceptor拦截器类preHandle()办法重构 ②　革新点2：每个Controller管制层类中接口办法减少获取登录用户办法getLoginUser()办法 ③　革新点3：返回数据及分页数据办法革新 （2）告警革新减少钉钉告警 v1.3.6版本告警组组类型仅反对：邮件、短信两种。公司平时是通过钉钉接管告警信息，因而须要集成钉钉告警类型。外围革新点如下： ①　步骤1：定义DingAlertPlugin钉钉告警插件类实现AlertPlugin接口，重写getId()、getName()及process()办法 ②　步骤2：定义DingManager钉钉发送治理类③　步骤3：编写DingUtils钉钉发送音讯工具类④　步骤4：向AlertServer注册钉钉告警插件⑤　步骤5：打包部署并批改dolphinscheduler-daemon.sh 打包部署依据具体批改逻辑，这里批改了dolphinscheduler-alert-1.3.6.jar和dolphinscheduler-dao-1.3.6.jar 因而打包这两个包即可。另外，装置门路下减少alertlib文件夹并在dolphinscheduler-daemon.sh中减少alter-server加载逻辑。 （3）集成成绩展现 数据中台集成菜单与v1.3.6海豚调度保持一致，次要包含：首页、项目管理、资源核心、数据源核心、监控核心、平安核心，这些菜单都是集成到了咱们的数据中台中，前端走平台对立的路由网关。 （4）v1.3.6旧版本业务痛点问题 工作流定义表 process_definition_json字段大JSON 工作和工作流耦合度高，解析json，十分消耗性能，且工作没法重用；否则会导致数据大量冗余，性能差，资源耗费重大降级艰难，1.3.6集成到数据中台零碎中，相当于二次开发了API服务，集成了中台用户体系走对立路由网关，前端UI组件每一次降级，海豚调度就会呈现各种前端款式问题（SUB_PROCESS 子工作流 进入不到该子节点下）、菜单显示不全、日志全屏看不全、我的项目主页高低滑动不了等等一系列UI交互问题工作间自定义参数高低不能依赖传参工作流实例工作穿插没有工作执行策略 ，默认是并行处理的，不保障单例模式，比方调度频率高时 前一个工作流实例还未执行完，后一个又开始，造成数据错乱、不精确自带数据品质从3.0.0开始反对多种告警插件类型和告警组及实例治理（不限于钉钉），从3.0.0开始前端UI大调整、优化鉴于第一版集成的v1.3.6以上的业务痛点，降级并重构集成形式变得尤为重要。 海豚调度新版本升级v1.3.6版本在数据分析师进行业务剖析流转过程中面临的痛点，联合海豚调度新版本更优的个性，降级到更新版本火烧眉毛，以下是对咱们在将海豚调度集成到数据中台以及降级过程的细节做一下介绍，心愿对遇到跨大版本升级的你有所帮忙。 （1）新版本（v3.1.1）集成到中台 海豚调度集成中台我的项目整体架构 次要分为：数据中台-前端、数据中台-后端、海豚调度API服务<UI>及集群。 海豚调度集成中台调用流程 次要流程：数据中台-前端申请关上海豚调度菜单->调用数据中台后端获取海豚调度用户登录信息接口->返回用户名明码->登入海豚调度零碎->数据中台-前端申请退出平台账号->海豚调度接口登出接口->退出零碎 数据模型及设计细节海豚调度集成数据中台我的项目两头用户模型设计 模型设计的目标次要建设数据中台和海豚调度用户的关系，便于在数据中台用户登录后，点击海豚调度菜单时获取到对应的海豚调度用户登录信息胜利登录。 （2）v1.3.6滚动迁徙并降级到v3.1.8+ 这里我以咱们生产环境降级版本v1.3.6为终点，通过v2.0.0->2.0.9>3.0.0>3.1.0->3.18这些版本迭代降级<当然能够跨度步调迈的再小一点，呈现的问题可能就更少了，因为毕竟官网提供的update_schema.sh脚本是实用于小版本的，对于大版本兼容性反对不欠缺。 在降级过程中次要在v2.0.0须要批改局部源码兼容降级，其余版本根本都是须要批改schema对应的ddl脚本兼容降级，次要降级流程总结如下： 下载指标降级安装包（须要滚动降级的源码包和二进制包下载）下载新稳固版本（待降级版本）的所有二进制安装包，并将二进制包放到与以后 DolphinScheduler 旧服务不一样的门路中，降级步骤需在新版本的目录进行。 留神：如果存在跨大版本升级需要，尤其是跨v2.0.0版本，须要下载2.0.0源码包，批改详见（3） Dolphin Scheduler元数据备份（获取生产旧版本SQL脚本）从生产环境转储或用dump命令备份数据库脚本文件，一些非必要的日志表数据能够不要，但须要备份表构造。 批改降级版本的配置文件这里按版本分为≤v2.0.9和≥v3.0.0，在v2.0.9版本之前，目录构造大抵如下： 在v3.0.0版本之后，目录构造大抵如下： 个别批改遵循先配置降级schema，再配置根底部署文件的准则。 对于≤v2.0.9而言，配置降级schema须要批改conf/datasource.properties文件并将数据库驱动包放在lib目录下即可；而配置根底部署文件须要批改conf/common.properties、conf/config/install_config.conf、conf/env/dolphinscheduler_env.sh。 ...

导读：国内某头部理财服务提供商成立于 2019 年，是股份制银行中首批获准筹建、首家获准停业、首家成立的银行理财子公司。自 2004 年推出国内首支人民币理财产品以来，通过投资模式的不断创新和投资治理能力的继续晋升，引领国内银行业理财市场。该企业每天解决的任务量达 1W，外部零碎泛滥，事不宜迟是须要一个对立的调度和监控平台，反对不同理财业务场景下的需要。 2023 年之前，该企业应用开源版本的大数据调度平台 Apache DolphinScheduler 能基本上满足业务需要，但随着业务量增大和个性化需要的增长，在通过周密的调研之后，决定将所有调度工作迁徙到商业版本白鲸调度零碎之上。 采纳白鲸调度零碎让该企业实现了对立调度和监控运维，调度性能大幅提高。本文将详细描述白鲸调度零碎为该企业提供的解决方案和相干利用实际。 业务需要国内某头部理财服务提供商所处的金融行业属于数据密集型行业，随着这个行业的一直倒退和技术的不断进步，金融数据的数据量一直减少，数据起源也越来越多样化，其须要对数据品质进行严格的把控，并须要具备高效的数据处理和剖析能力。此外，金融市场变动疾速，危险管制须要实时响应，这对其数据处理和剖析能力提出了更高的要求。同时，爱护客户的隐衷和机密信息，防备网络攻击和数据泄露等平安问题，都对该企业提出重要的挑战。 具体来说，该企业的产销、投资、危险评估、经营投资等团队都有本人的数据集市（数仓），每个团队都从须要的贴源层获取到本人须要的数据，通过各自团队的ETL 流程，将统计数据输入到各自的集市中，再把本人的集市数据分享给其他人。 因为每个团队都有各自的调度平台，这导致平台的保护老本十分高，运维治理也很不不便，另一方面也不能集中统计和治理所有团队的工作。 因而，对立调度零碎的建设在该企业是事不宜迟。 在建设数据体系过程中，其须要基于信创环境下建设具备高性能、可靠性高、易扩大的调度零碎，以满足该企业在数据体系建设中各类数据处理工作的对立调度和监控需要，实现对立调度和监控运维，反对不同场景下实现各自个性化的需要，保障数据体系的根底建设。 接到商业调度需要时，该企业过后的调度集群由 3 台 40C*256G 的机器组成，由两台 API 、3 个 Master 、3 个 Worker组成，每天解决 1 万量级的工作，未来可能到 3 万+/天。 具体到业务线上，该企业对建设调度零碎有着如下需要： 要反对各部门应用对立的调度零碎，应用权限将各部门的资源进行隔离，保证系统运行的隔离性和安全性。要有丰盛的监控和统计性能，反对对立的数据监控、运维服务的需要；调度零碎要反对多种触发类型，比方事件、自定义日历、依赖调度等形式触发作业，反对用户灵便配置作业及组合工作流，实现在不同场景的调度需要；须要能联合该企业本身需要，反对信创组件、扩展性的工作类型、数据源类型、告警组件及其他扩大需要；反对分布式的架构及资源管制等办法，实现一个高可靠性，高解决性能的调度零碎；反对定制化需要，比方和该企业的本身用户零碎对接用户及权限数据，对接客户的对立登录平台，以及其余数据处理平台和告警平台。基于白鲸调度零碎的一站式解决方案白鲸调度零碎国产信创化调度平台，就是为了反对客户在数据体系建设中不同场景的任务调度需要，针对企业级用户对系统的稳定性、可靠性、合规性、高性能、反对信创环境等要求而开发出的商业化版本，定位于企业级对立调度平台，为企业的批处理工作制订对立的开发标准、运维办法，对各零碎的批量工作进行对立治理、调度和监控。 白鲸调度零碎继承了大数据调度平台 Apache DolphinScheduler弱小的性能与易用性，同时减少了多项企业级性能以满足理论行业用户需要，让企业能够部署一套调度零碎，缩小保护老本，领有弱小的调度能力。 在明确需要后，白鲸开源自信白鲸调度零碎可能满足客户的全副需要，着手分步骤、分阶段进行解决方案的施行部署。通过了一系列测试后，白鲸开源启动了实施方案，并帮忙客户解决了部署前、部署中和部署后的一系列问题，为其交付了残缺的解决方案。 整体技术计划白鲸调度零碎次要应用无核心架构的设计思维，通过注册核心发现服务，服务之间能够互为备份，保障了零碎的可靠性的同时，也能够做到程度扩大服务数量，可能很好地反对企业千万级别的工作数量，齐全满足金融业务场景数据处理量大的需要。 白鲸调度零碎次要服务包含 UI 用户界面、接口层 API 服务，MasterServer、WorkerServer、AlertServer 五个模块，其中工作解决服务 MasterServer 和 WorkerServer 是典型的无核心架构，通过注册核心主动发现服务的启动和敞开，能无效反对工作数量激增和缩小的场景，同时能够保障工作解决的可扩展性和高性能。 零碎所有服务均采纳分布式部署，反对高稳定性、高性能和高容错性，保障提供可继续应用的服务，即便客户的数据中心漫步在全国各地，白鲸调度零碎也能轻松应答来自客户不同部门数据系统的解决需要。 针对客户的需要，白鲸调度零碎提供的解决方案让每个团队都领有了本人的工作执行集群，调度零碎是独自的集群，免密登录各自团队的集群，各团队都在调度上应用 shell 工作 的 ssh remote 'shell command' 来执行各自集群上的工作。 具体解决方案包含（因为窃密需要，只走漏局部信息）： 多日历治理不便多个市场交易日、工作日、天然日治理针对企业设计多种日历，反对调度日历、业务数据日历离开，并反对不同时区、日历导入等性能： 反对多种日历治理：交易日、工作日、天然日等反对日历 Excel 模板导入反对调度日历与业务日历离开反对多时区设置反对日切工夫设置弱小的业务数据日期性能更好满足金融行业需要针对客户调度当中的业务数据日期独自进行设计，更好地满足金融行业需要： 屡次调度应用同一业务数据日期（例，最初一个交易日，如果不翻牌，数据指针进行在这一天，例如 ，9.30 不跑 10.1 七天 10.6日开始跑，仍然跑的是 9.30 日）弱小的业务翻牌工作反对前后自定义翻牌反对自定义脚本间接生成业务日期数值反对定时翻牌和工作完结翻牌配合日历，反对多种简单函数用于数据处理前后 n 日、月（工作日、交易日、天然日）以后牌所在月、年（工作日、交易日、天然日） ...

调研背景：数据库连贯建设是比拟低廉的操作（至多对于 OLTP），不仅要建设 TCP 连贯外还须要进行连贯鉴权操作，所以客户端通常会把数据库连贯保留到连接池中进行复用。连接池保护到弹性数据库（JED）的长连贯，弹性数据库默认不会被动敞开客户端连贯（除非报错），但个别客户端到弹性数据库之间还会有负载平衡代理，它们通常为了节约连贯资源会在连贯闲暇10分钟后被动清理连贯，开释无用的连贯资源。这就导致一些用户的连接池探活参数配置不当，进而拿到是曾经生效的连贯。客户端就会报以下谬误： 基于以上的背景咱们依据Java利用罕用的连接池的罕用版本的连接池探活相干的性能进行了调研，并对每个版本提供了JED配置的模版。目前，罕用的连接池版本如下： HikariCP 3.2.0、 3.4.5、4.0.3 DRUID 1.1.10、1.1.9、1.0.9 DBCP 1.4 、2.2.0、2.1.1 HikariCP咱们第一个章节先来介绍一下HikariCP连接池探活相干的内容： HikariCP连接池会在须要调配连贯对象给应用程序应用时，先查看连贯对象的状态。为了检测连贯是否可用，连接池会调用isConnectionAlive办法。如果连贯对象是可用的，连接池会将连贯对象调配给应用程序应用；如果连贯对象不可用，连接池会创立一个新的连贯对象，并将新的连贯对象调配给应用程序应用。 所以HikariCP连接池的连贯对象生效时，连接池只会在日志中输入正告信息，倡议缩短连贯对象的最大生存工夫(\`maxLifetime\`)。然而，这并不会影响程序的失常执行，因为连接池会主动从新创立新的连贯对象并调配给应用程序应用。因而，应用程序能够持续应用连接池中的连贯对象，而不会受到生效连贯的影响。 尽管应用HikariCP连接池时，如果不配置连贯探活，应用程序在拿到生效的连贯时不会报错，然而当应用程序须要执行SQL时，可能会遇到生效的连贯，导致须要从新建设连贯，减少了额定的性能开销。这样就没有充分发挥连接池的劣势，因为连接池的次要目标是通过重复使用连贯对象来进步应用程序的性能和可伸缩性。 为了最大化施展连接池的价值，咱们就一块来理解一下对于HikariCP探活相干的内容，看看如何利用相干的探活参数更高效地应用连接池。 以下是跟HikariCP探活通用的相干的参数： 参数名称阐明默认值minimumIdle连接池保护的最小闲暇连接数5maximumPoolSize连接池中能包容的最大连接数10maxLifetime此参数用来管制连贯在连接池中最大的生命周期，当建设的连接时间超过这个参数时候在闲暇状态就会被销毁。1800000 (30 minutes)idleTimeout此参数用来管制连贯在连接池中闲暇的工夫，如果设置8分钟，就会每隔8分钟清理一下超过minimumIdle的闲暇连贯。600000 (10 minutes)connectionTestQuery这个参数在低版本中只会在从池中提供连贯之前执行配置的SQL。这个参数实用于不反对JDBC4 Connection.isValid() API，反对JDBC4以上驱动的倡议不要配置。nonekeepaliveTime该属性是避免底层网络基础设施超时断开，定期验证连贯的有效性，如果连贯生效从连接池中剔除。该值必须小于maxLifetime值。4. 0.1以上版本引入的新参数能够联合connectionTestQuery参数来探活。0 (禁用)HikariCP连接池的探活代码如下。能够看到，在探活时，连接池会依据isUseJdbc4Validation属性的值来决定是否走JDBC API进行探活isUseJdbc4Validation属性的值是在初始化数据源时依据connectionTestQuery属性是否为空来赋值的。如果connectionTestQuery属性为空，isUseJdbc4Validation属性的值为true，连接池会走JDBC API进行探活。因而，在JDBC 4.0及以上版本中，不倡议配置connectionTestQuery属性进行探活，因为这样会影响探活的效率。 在HikariCP较低的版本中，无奈对连贯进行保活，只能在每次获取连贯时验证连贯的有效性。而在4.0.1版本中，引入了keepaliveTime参数，能够定时的对连贯进行探活。因而，为防止获取到已敞开的连贯，在低版本中，只能将maxLifetime参数调整到少于10分钟，能力完全避免拿到网关曾经敞开的连贯。在4.0.1及以上版本中，能够应用keepaliveTime参数配合connectionTestQuery参数进行连贯探活，从而在获取连贯之前就进行探活。这样能够进步连贯的可靠性和稳定性，防止应用程序遇到有效连贯的状况。 配置keepaliveTime后咱们能够看到每次到配置的工夫就会打印进去探活日志 因而针对线上应用HikariCP的利用举荐应用4.0.1以上反对keepaliveTime的版本。 JED配置模版：HikariCP3.2.0spring.datasource.hikari.minimumIdle=5spring.datasource.hikari.maximumPoolSize=10spring.datasource.hikari.maxLifetime=540000spring.datasource.hikari.idleTimeout=480000#JDBC4以上的版本不倡议配置connectionTestQueryspring.datasource.hikari.connectionTestQuery=select 1低版本中次要保障maxLifetime低于10分钟可能完全避免拿到网关曾经敞开的连贯，但可能会造成频繁的创立销毁连贯所以倡议应用4.0.1以上反对keepaliveTime的版本。 HikariCP3.4.5同3.2.0版本。 HikariCP4.0.3spring.datasource.hikari.minimumIdle=5spring.datasource.hikari.maximumPoolSize=10spring.datasource.hikari.maxLifetime=1800000spring.datasource.hikari.idleTimeout=600000#JDBC4以上的版本不倡议配置connectionTestQueryspring.datasource.hikari.connectionTestQuery=select 1spring.datasource.hikari.keepaliveTime=3000004.0.1以上的版本中能够把keepaliveTime参数设置小于10分钟对连贯进行探活，就能防止拿到被网关敞开的连贯，maxLifetime的工夫就能够缩短能防止频繁的创立销毁连贯。 参考文档： https://github.com/brettwooldridge/HikariCP#readme 作者：京东批发 王雷鑫 起源：京东云开发者社区 转载请注明起源

Bytebase 和 GitLab 签订技术合作伙伴协定，携手为开发者提供晦涩的数据库合作开发和治理体验。 GitLab 是世界领先的开源 AI 驱动 DevSecOps 平台，旨在帮忙开发者团队更好合作、更高效交付软件。Bytebase 是一款为 DevOps 团队筹备的数据库 CI/CD 工具，专为开发者和 DBA 打造，也是惟一一个同时被 CNCF Landscape 和 Platform Engineering Landscape 收录的数据库工具。 Bytebase：连接 GitLab 代码仓库和数据库变更Bytebase 反对将数据库 Schema 与版本控制系统 (VCS) 集成，实现了「数据库即代码 / Database-as-Code」。用户将数据库 Schema 变更脚本提交到本人的 GitLab 代码仓库，会主动在 Bytebase 触发 SQL 审核和部署 pipeline，实现从代码变更到数据库变更的一体化 CI/CD 流程。 Bytebase 也已将 SQL 审核能力集成到 GitLab CI 流程中。用户能够配置 SQL 审核策略，之后能够在 GitLab 中治理 SQL 脚本并自助实现 SQL 审核工作，防止了在多个工具中切换，还能够通过前置 SQL 审核，在研发流水线的代码提交阶段就能发现问题，而无需等到部署阶段。 提交工单时，如果 MR 中的 SQL 语句违反了审核规定，会在 MR 中呈现对应提醒。 ...

8月31日，KaiwuDB 携手展湾科技、罗克韦尔自动化、新智认知、浪潮信息四家合作伙伴在安徽合肥独特举办“工业互联网联结解决方案”发布会，KaiwuDB 副总经理张勇缺席本次公布流动。 在工业界迈入全新物联网时代的明天，制造业工厂及上下游企业的数智化转型面临从底层基础设施到下层利用全面改革的新挑战，如何在保障平安及零碎性能的前提下，晋升产品品质及生产效率并优化治理，是各大企业关怀的重点问题。 本次 KaiwuDB 联结四方企业携手打造的“1+X”工业互联网联结解决方案，旨在提供一种面向工业互联网场景的全面、可扩大、高可用、平安、智慧的综合业务解决方案。发布会邀请到安徽省、合肥市等重要政府领导，安徽省工业互联网协会出名专家以及泛滥工业企业信息化首领光临现场、独特见证。 “1+X”联结计划依靠 KaiwuDB 多模数据架构、原生 AI 等外围能力及浪潮边缘服务器优异的计算性能为工业互联网利用场景提供松软的数字底座；向上搭建展湾科技工业互联网平台及数智化利用，搭配罗克韦尔自动化控制系统的边缘利用与工业管制，联合新智认知的平安保障能力，为宽广制造业企业提供“采、存、算、管、用”在内的一站式数据链路及 IT 基础设施解决方案。 KaiwuDB 副总经理张勇（两头）与四方领导独特公布“联结计划” 将来，KaiwuDB 将继续踊跃地推动与优质合作伙伴的计划共建，推动计划的实际与规模化落地；也欢送更多生态搭档退出到咱们的口头中，推动更广更深的产品交融，携手实现计划共创、技术共生、生态共赢。 包含工业互联网在内的物联网场景，存在着一大突出特点 —— 数据量宏大且数据模态简单多样化。KaiwuDB 自主翻新的多模架构，是应答海量多模数据的一大利器。 目前大多数工厂采纳的仍然是传统的数据库组合形式，如：装备一套次要的时序数据库，再依据业务需要外加一两套根底的关系型数据库或是图数据库等反对业务。在此状况下给企业数字化降级带来的妨碍不仅限于应用多个数据库的老本问题，还包含不同数据库之间的兼容协同及性能瓶颈。 KaiwuDB 多模架构，可能无效地解决传统工厂“专库专用”“高老本”“运维难”等一系列问题，实现“一库多用“。以一套 KaiwuDB 数据库代替包含时序、OLAP、OLTP 等在内的多套专库，既能保障数据一致性、传输转换等要害性能不受影响，还能大大降低开发、运维及治理老本，助力宽广企业通过多模架构轻松应答工业互联网场景下的业务弊病，“隔靴搔痒”。 KaiwuDB“一库多用” 除此之外，KaiwuDB 基于分布式多模数据库自身，打造了一款数据服务平台—— KDP ，赋能制造业的各大工厂企业进行数据管理与剖析。KDP 基于就地计算、流式计算等核心技术帮忙企业实现多层级、多维度数据下钻，可能对设施产出的海量数据进行实时统计与剖析；同时，基于原生 AI 能力进行历史数据预测剖析，开掘数据价值，撑持科学管理决策，为管理层提供“驾驶舱”，优化企业生产流程，进步企业生产效率，最终实现降本增效。 KDP 数据服务平台 除此之外，KaiwuDB 基于分布式多模数据库自身，打造了一款数据服务平台—— KDP ，赋能制造业的各大工厂企业进行数据管理与剖析。KDP 基于就地计算、流式计算等核心技术帮忙企业实现多层级、多维度数据下钻，可能对设施产出的海量数据进行实时统计与剖析；同时，基于原生 AI 能力进行历史数据预测剖析，开掘数据价值，撑持科学管理决策，为管理层提供“驾驶舱”，优化企业生产流程，进步企业生产效率，最终实现降本增效。

8月31日，第二十五届中国国内软件博览会（以下简称“软博会”）在天津隆重揭幕。KaiwuDB 受邀亮相展会，围绕“塑造软件新生态，赋能倒退新改革”主题，重点展现自研分布式多模数据库及各大行业解决方案，吸引泛滥到场来宾驻足关注。 第二十五届中国国内“软博会” 软博会是我国首个以软件为主题的国家级专业化展会，是我国软件和信息技术服务畛域内规模最大、持续时间最长、最具影响力的业余盛会，也是推动我国软件一直向专业化、品牌化、国际化倒退的重要平台。 以数据库为代表的根底软件是数字经济蓬勃发展的重要底座，是产业高质量倒退的要害撑持。数据库作为信息系统的外围，向下调动系统资源，向上撑持应用软件，承当着大规模数据采集、存储、治理、剖析的重任。 KaiwuDB “软博会”展台现场 数字生产力来源于技术，萌芽于场景，KaiwuDB 紧跟国家策略关注的产业畛域，致力于将数据库技术使用于各大生产环节；继续聚焦产业倒退及客户胜利，“因地制宜”，基于包含就地计算在内的 8 大核心技术，继续打磨产品性能，并陆续推出多个场景化的解决方案，实现了对工业制作、政务大数据、能源、金融等重要畛域的利用撑持。 与此同时，秉承“生态共建&共赢”的凋谢态度，KaiwuDB 近日携手 IoT 畛域多家出名合作伙伴打造更贴近用户场景的联结解决方案，围绕技术攻关、计划共创、产品适配等层面开展深度单干。将来，KaiwuDB 将持续丰盛本身产品及计划，欠缺技术服务水平，力争为宽广企事业用户提供更加平安、稳固、高性能的数据产品及服务；同时也将更加动摇“用户本位”，继续为客户发明新价值。

基于公司丰盛的音乐内容资产，须要将歌曲库、艺人资讯、专辑信息、厂牌信息等大量数据进行对立存储造成音乐内容数据仓库，并通过产品工具为业务人员提供数据分析服务。在内容数仓搭建的过程中，咱们的工作始终围绕降本增效为次要目标进行优化与迭代，心愿在数据服务方面一直晋升产品工具的开发与剖析效率，同时在数仓架构方面可能无效缩小架构老本与资源开销。 在传统数据服务中，咱们为业务分析师提供了多种数据服务，包含 SQL 查问、固定看板、定制化的剖析工具以及人工跑数。然而，在理论利用过程中依然存在肯定痛点： SQL 查问平台 ： 业务分析师依据需要进行 SQL 语句编写，对平台数据进行查问剖析，每位业务人员都须要把握 SQL，导致学习老本高、上手难度大。固定看板（Dashboard） ： 技术人员基于惯例业务开发制作数据看板，尽管可能简化业务分析师查问的过程，然而看板制作老本高且灵便度低，当面对简单的用户问题时，看板无奈及时调整以满足需要变更。定制剖析工具： 基于特定的业务需要，技术人员须要定制化开发产品剖析工具，整体开发成本过高，且繁多的开发工具不具备通用性，随着工具数量减少，操作介面变得散乱，从而升高业务效率。人工跑数： 当以上三个场景都无奈满足业务需要时，业务分析师须要向技术人员提需要进行人工跑数，沟通老本过高、整体解决效率低下。随着行业发展趋势，LLMs 大语言模型（LLMs - Large Language Models，以下对立简称为大模型）呈现无效地解决了这些问题。当平台融入大模型后，平台用户输出的问题会进入大模型进行语义解析，主动转化为 SQL 语句触发 OLAP 引擎开启数据分析与查问。通过平台智能问答交互的形式，业务分析师不再须要依附人工编写 SQL 提供查问剖析后果，技术人员也不须要再制作过于固定或者过于定制化的产品工具。大模型 + OLAP 引擎联合的全新数据服务模式，不仅为平台用户提供了个性化、灵便表白、秒级回复的服务体验，还大幅升高了企业外部技术与业务学习老本，减速数据分析效率，实现多端入口对立、界面对立的平台构建。 本文将具体介绍腾讯音乐如何基于 Apache Doris 构建查问高效、实时写入且对立的 OLAP 剖析引擎，使 OLAP 作为底层基建增强大模型与之连贯转化的效率、后果输入的准确率，最终提供更智能化的问答交互服务，也心愿通过这篇文章为有相干业务需要的公司提供不同视角和思路。 大模型 + OLAP ：开启数据服务平台新模式在大模型 + OLAP 架构计划中，目前经典计划如下图所示，大模型充当中间层将用户输出的自然语言转化为 SQL 执行语句，OLAP 作为底层存储和数据处理的引擎，负责承受和执行从大模型发送过去的 SQL 语句，对数据进行预聚合、多维分析等操作，满足大规模数据集的查问剖析需要。 然而，这种架构在理论落地过程中也面临肯定挑战，例如语义了解的准确性、查问效率的优化、私域常识的了解等方面，具体如下： 简单数据口径不对立： 大模型对于技术方面的词汇，如字段、行列、表等无奈了解，相同对于业务方面的词汇，如公司支出状况、日沉闷用户数量等可能提供无效翻译与转换。因而挑战之一是须要思考如何疏导用户进入指标范畴内发问，挑战之二是当用户存在对多种指标、多类指标查问时，须要思考如何放弃指标维度口径的对立、如何无效生成对应的指标计算公式。模型解决效率较低： 现阶段大模型尽管反对交互能力，但推理速度较慢，须要破费十秒级以上响应，用户每减少一个问题输出，就须要破费更多等待时间，使服务质量升高。同时大模型整体依照 Token 免费，使用量减少时也会导致平台老本升高。私域常识无奈辨认： 尽管大模型曾经发展许多公开数据集的语言转换训练，但面对企业外部的大量专业术语仍无奈很好地了解转化。以音乐内容数据库为例，大模型时常短少对于某些冷门歌曲的认知，在问答过程中无奈正确给出交互反馈，因而咱们须要加强大模型对于私域常识的了解。定制场景无奈满足： 大模型次要根据本身数据集进行答复，会呈现“常识幻觉”（输入不足根据的内容）问题，咱们须要容许第三方插件的接入使大模型得以联网，让用户借助外部插件实现更定制化、更多样的工作。因而如何接入、匹配并触发组件性能是咱们的重点优化指标。面对经典计划中的落地难点，咱们的总体解决思路是将以上四大挑战逐个拆解，通过组件叠加分阶段欠缺大模型 + OLAP 架构构建，最终实现全新的交互问答服务模式，接下来咱们将介绍各阶段挑战对应的解决方案。 01 减少语义层：解决简单数据问题 为了解决简单数据处理问题，咱们在大模型与 OLAP 两头减少 Semantic Layer（以下简称语义层）。 ...

网络拓扑构造是计算机网络中的一项重要技术，它定义了网络中节点之间的物理或逻辑连贯关系。通过正当的网络拓扑结构设计，能够进步网络的性能、可靠性可扩展性和安全性。 一、网络拓扑构造的分类 网络拓扑构造能够分为以下几种类型： 星型拓扑：星型拓扑将所有节点都连贯到一个集线器或交换机上，造成一个星形构造。这种拓扑构造简略、易于实现和治理，然而存在单点故障的危险。总线型拓扑：总线型拓扑将所有节点都连贯到一条总线上，节点之间通过传输介质进行通信。这种拓扑构造具备低成本、易于扩大的长处，然而一旦总线呈现故障整个网络将无奈失常工作。环型拓扑：环型拓扑将所有节点通过网络线缆连接成一个环形构造。这种拓扑构造具备良好的可扩展性和性能，然而也存在环路问题和网络拆分的危险。树型拓扑：树型拓扑将网络节点依照分级构造连接起来，造成一个树状构造。这种拓扑构造具备良好的可扩展性和性能，然而必须有一个根节点同时也存在单点故障的危险。网状拓扑：网状拓扑将网络节点通过多条线缆相互连接，造成一个简单的网状结构。这种拓扑构造具备高度的可靠性和灵活性，然而也存在网络简单、治理艰难的问题。二、网络拓扑构造的抉择准则 在抉择网络拓扑构造的时候，须要思考以下几个准则： 性能：不同的拓扑构造对网络的性能有不同的影响。例如，星型拓扑具备低提早、高带宽的特点，实用于须要低提早和高带宽的利用场景。可靠性：网络拓扑构造的可靠性是指网络在呈现故障时，可能保障数据传输的连续性和稳定性。例如，网状拓扑具备高度的可靠性能够容忍多个节点的故障。 3. 扩展性：网络拓扑构造的扩展性是指网络可能不便地扩大节点数量。例如，总线型拓扑具备良好的扩展性能够灵便地增加或删除节点。安全性：网络拓扑构造的安全性是指网络对于未经受权的拜访和攻打的抵挡能力。例如，树型拓扑具备较好的安全性因为只有根节点才具备拜访权限。 三、网络拓扑构造的利用 网络拓扑构造技术在古代计算机网络中失去广泛应用。不同的利用场景须要抉择不同的拓扑构造。 局域网（LAN）：在局域网中，星型拓扑和总线型拓扑是常见的抉择。星型拓扑实用于小型局域网，而总线型拓扑实用于较大规模的局域网。广域网（WAN）：在广域网中，网状拓扑和树型拓扑是常见的抉择。网状拓扑实用于大规模的广域网，而树型拓扑实用于分级构造较为简单的广域网。数据中心网络：在数据中心网络中，多层树型拓扑和网状拓扑是常见的抉择。多层树型拓扑实用于数据中心外部的通信，而网状拓扑实用于数据中心之间的通信。 总之，网络拓扑构造技术是计算机网络中的重要技术通过正当抉择和设计网络拓扑构造能够进步网络的性能、可靠性可扩展性和安全性。在理论利用中，须要依据具体的需要和场景抉择适合的网络拓扑构造。也能够通过查问ip地址信息，晋升网络安全。

敬爱的社区小伙伴们，咱们很快乐的发表，2023 年 9 月 4 日 咱们正式公布了 Apache Doris 2.0.1 和 Apache Doris 1.2.7 这两个版本，这两个版本由上百名位贡献者共同努力实现的，提供了更多有用的新个性，同时修复了若干已知的问题，进一步晋升了零碎的性能和稳定性，欢送大家下载体验。 本文将介绍这两个版本更新信息，以帮忙大家疾速理解新版本性能个性。同时期待听到大家的反馈和倡议，这将帮忙社区进一步改良和欠缺 Apache Doris。 Apache Doris 2.0.1 版本GitHub下载： https://github.com/apache/doris/tree/2.0.1-rc04 官网下载页： https://doris.apache.org/download/ 01  行为变更将 varchar 默认长度 1 批改为 65533。 #2130202  性能改良对 Array 和 Map 数据类型进行性能优化及稳定性改良。 #22793 #22927 #22738 #22347 #23250 #22300优化了倒排索引的查问性能。 #22836 #23381 #23389 #22570优化了Bitmap、Like、Scan、Agg 等执行性能进行了优化。#23172 #23495 #23476 #23396 #23182 #22216对 CCR 进行了性能优化与稳定性晋升。 #22447 #22559 #22173 #22678加强 Merge-on-Write 主键表的能力。 #22282 #22984 #21933 #22874对表状态和统计信息的性能进行优化。  #22658 #22211 #22775 #22896 #22788 #22882实现 Multi-Catalog 的性能优化及稳定性改良。 #22949 #22923 #22336 #22915 #23056 #23297 #2327903  问题修复修复了 Apache Doris 2.0.0 版本中若干已知问题，进一步提高了零碎的稳定性。您可在 GitHub 残缺 Release Note 中查看所有优化改良及修复问题的列表。 ...

8月24日-27日，第十七届全国常识图谱与语义计算大会（CCKS 2023）在沈阳召开。大会以“常识图谱赋能通用AI”为主题，探讨常识图谱对通用AI技术的撑持能力，摸索常识图谱在跨平台、跨畛域等AI工作中的作用和利用路径。 作为国内常识图谱、语义技术、自然语言了解与常识获取等畛域的外围学术会议，每年的CCKS都会邀请相干技术畛域顶尖专家学者参会，探讨AI前沿技术。今年以来，大语言模型掀起的新一轮AI浪潮席卷寰球。本次大会上，大语言模型也成为泛滥参会专家学者关注的焦点。 在会上，酷克数据首席科学家杨胜文博士发表了题为《用常识加强“小”语言模型》的宗旨演讲，从产业实际的角度分享了在企业数据仓库环境下，利用中小规模语言模型构建面向场景的智能利用的摸索与实际，并对企业数智化转型过程中AI与数据如何更好地协同做了探讨。 大模型VS小模型？ 在过来的几个月中，大语言模型在公众当中的关注度有所弛缓，但学术界和产业界的投入激情并未削弱。国内外各大厂商都在减速技术迭代，泛滥初创公司也在奋起直追，开源社区的倒退也十分迅猛。 杨胜文指出，目前千亿级参数的大语言模型在生成能力方面仍存在一些有余，如生成“幻觉”问题。更为重要的是，企业在理论利用大模型过程中还面临着数据安全、私有化老本高、要害利用场景辨认难和高质量数据不足等诸多挑战。 图1:酷克数据首席科学家杨胜文博士绝对动辄千亿级甚至万亿参数的大语言模型而言，十亿级或百亿级参数的“小”语言模型，曾经具备良好的语言了解和生成能力，并且在落地方面有着显著的老本劣势。小语言模型可能以极低的老本在企业私有化部署，微调、推理所需的硬件老本也较低。通过与企业自有数据紧密结合（包含微调和Prompt加强等），在很多垂直场景都能够获得良好的利用成果。凭借其杰出的性价比和灵活性，小语言模型成为现阶段LLM在企业落地利用的可行代替计划。 同时，日益凋敝的开源生态为小语言模型在企业低成本、规模化的利用发明了条件。在代码和工具层面，曾经呈现了很多优良的开源我的项目和公开数据集，可能满足百亿级参数模型的训练需要。在模型层面，呈现了很多由大型商业公司、钻研机构和初创公司研发的模型，参数规模从数十亿到数百亿参数不等，大部分模型都容许收费商用，这为小语言模型的规模化落地进一步发明了条件。 企业数据仓库与大语言模型的有机联合 大语言模型的训练、微调以及常识加强的利用离不开高质量数据的反对。作为企业数据的存储、加工和剖析的外围场合，企业数据仓库蕴藏着微小的企业数据资产。 杨胜文认为，数据仓库为企业打造垂类模型、搭建面向场景的智能利用提供了人造的数据和计算环境。他同时指出，上一代数仓广泛采纳传统MPP架构，存在数据冗余、时效性差、数据一致性难保障、数据孤岛治理老本低等难题，减少了数据管理和模型开发的复杂度。 酷克数据的旗舰产品HashData云数仓，是国内最早实现存算拆散的云原生剖析型数据库，目前已服务金融、电信、能源等行业泛滥大型企业。HashData数仓零碎由1个元数据集群、若干个计算集群、1个对象存储以及1个治理控制台形成，具备极佳的弹性和可扩展性。 相比传统架构的数据仓库，HashData采纳存算拆散的架构，不仅可能通过SQL计算引擎对传统的数仓业务提供很好的反对，还可能借助ML/DL计算引擎实现对机器学习和深度学习的高效反对，其中包含对大语言模型微调和推理的反对，显著升高了零碎的复杂性，也大幅升高了经营老本。 HashData云数仓还内置了对向量数据的反对，基于分布式并行处理技术，能够反对海量语义向量数据的存储和高效检索。 杨胜文示意，以HashData为代表的古代企业数据仓库，为数据查问、剖析和AI计算提供了对立的软硬件平台，将极大地推动AI技术在企业中的理论利用。 HashML助力企业轻松构建大模型利用 为了进一步升高AI技术的利用门槛，酷克数据基于HashData云数仓自主研发了下一代In-Database高级剖析和数据迷信工具HashML。 杨胜文介绍，HashML首要设计指标就是简略易用，帮忙企业无门槛地应用各种经典和最前沿的AI算法和模型能力，解决理论业务问题。 为了实现这个指标，HashML对编程接口做了高度形象和标准化，容许客户只编写大量代码就能够实现从数据加载到数据处理，再到模型训练、模型部署、推理预测的全流程工作。 图2:HashML次要性能概览就大语言模型而言，借助HashML能够实现高质量数据挖掘、模型微调和Prompt加强，用户只须要大量的代码就能实现智能利用的搭建，包含向量知识库的建库和检索、模型的高效微调、模型部署和在线服务，以及对话式Web利用的疾速开发。另外，HashML针对出名的开源语言模型，例如ChatGLM、Baichuan、Llama2等，提供了额定的性能封装，不便客户更加便捷地应用这些模型。 在会上，杨胜文介绍了基于HashML和小语言模型构建的两个智能利用：检索加强的智能问答（ReQA）和基于自然语言交互的数据分析（ChatData）。 在ReQA中，通过将企业长期积攒的产品手册、技术手册、行业标准、客户服务记录等材料进行向量化，并以向量知识库的模式寄存在HashData，再联合语义向量检索技术和语言模型，就能实现基于本地知识库的精准问答。 图3:基于向量知识库的检索加强的智能问答（ReQA）在ChatData中，用户可能以自然语言的形式与HashData数据库进行交互， 实现数据查问和后果展现，还可能以自然语言的形式对查问后果进行可视化，从而大幅升高数据分析利用的门槛，容许企业更多的员工在职权范围内借助数据分析晋升工作效率和工作品质。为了让模型可能更好的了解用户查问用意并生成正确的SQL语句，酷克数据团队筹备了近十万条的训练语料，对模型进行了微调。 图4:基于自然语言的交互式数据分析（ChatData）展望未来，杨胜文认为，新一代人工智能技术正在减速企业数字化、智能化过程，将对企业的研发、生产、经营带来深远影响。只有让AI计算贴近利用场景、贴近企业数据资产，能力更好地推动AI落地。以HashData为代表的古代企业数据仓库为依靠，联合小语言模型，低成本疾速试错，挖掘高价值利用场景，是现阶段推动大语言模型技术在企业规模化落地的一种可行门路。 本次大会现场，酷克数据云数仓解决方案HashData及下一代数据迷信工具HashML受到泛滥参会者关注。HashML将于近期正式公布，后续咱们会带来更多相干技术分享。敬请关注！

本次 INFINI Labs 产品更新次要公布 Console v1.7.0，重点优化了 Console 告警核心和数据看板 Dashboard 可视化性能。具体介绍如下： 优化告警核心 UI上个版本优化了告警渠道和告诉，本版本次要对告警核心做了重点优化，从新设计了新的 UI 界面。进入告警核心，能够疾速理解整个零碎各集群告警状态，次要包含： 1、告警事件分类统计，反对点击过滤查问对应时间段的具体告警事件，便于管理员重点关注和解决高级别的告警事件； 2、告警事件数热力求，不同的色块示意当天告警数的密集水平，能够帮忙咱们疾速发现告警数据的趋势法则以及不同期间的数据变动状况，进一步可帮忙咱们剖析出集群的总体衰弱状态变化趋势。 3、告警事件列表，通过列表能够理解单个告警事件的信息，如事件级别、事件题目、告警继续时长、事件状态、触发工夫等内容，如果你不想解决某个具体告警事件，能够进行疏忽操作，防止再次收到告警告诉。 告警核心 UI 界面如下所示： 通过告警核心进入告警事件详情，能够查看更多告警信息，包含：告警规定、告警内容（反对 Markdown）、告警规定执行记录、告警告诉发送状况、事件触发统计图等，界面如下所示： 数据看板新增全屏性能为了不便将数据看板 Dashboard 投影展现到电视墙或者 LED 大屏幕，咱们新增了全屏性能，蕴含全屏展现以后 Dashboard，如果配置了多个 Dashboard，也反对全屏时主动滚动 Dashboard，无手动切换。成果如下所示： 全屏模式显示成果如下： 其余更新除了以上次要性能优化，Console 本次更新其余性能清单如下： Features告警规定新增分类和标签属性告警 UI 操作减少批量操作数据看板新增全屏性能数据看板新增日历热力求数据看板组件多分组反对分层显示Bug fix修复数据迁徙工作在大量子工作场景下，统计进度不对的问题修复某些场景下集群反复注册的问题Improvements告警核心页面 UI 优化告警详情页面 UI 优化数据看板组件配置 UI 优化数据看板组件数据源配置优化网关治理-队列治理反对批量删除队列和消费者对于 INFINI ConsoleINFINI Console 是一款十分轻量级的多集群、跨版本的搜寻基础设施对立管控平台。通过对风行的搜索引擎基础设施进行跨版本、多集群的集中纳管， 企业能够疾速不便的对立治理企业外部的不同版本的多套搜寻集群。 Console 在线体验： http://demo.infini.cloud (用户名/明码：readonly/readonly)。 也欢送下载本地装置体验！（附：Easysearch 与 Console 疾速装置演示视频） 期待反馈欢送下载体验应用，如果您在应用过程中遇到如何疑难或者问题，欢送返回 INFINI Labs Github（https://github.com/infinilabs） 中的对应我的项目中提交 Feature Request 或提交 Bug。 ...

什么是防火墙？防火墙是实现网络和信息安全的基础设施，次要是借助硬件和软件的作用，在外部网络和内部网络之间产生爱护屏障，从而实现对不平安网络因素的阻断。在网络中，所谓“防火墙”，是指一种将内部网和公众拜访网（如Internet）离开的办法，它实际上是一种隔离技术。防火墙是在两个网络通讯时执行的一种访问控制尺度，能最大限度阻止网络中的黑客拜访你的网络。是指设置在不同网络（如可信赖的企业内部网和不可信的公共网）或网络安全域之间的一系列部件的组合。它是不同网络或网络安全域之间信息的惟一出入口，能依据企业的平安政策管制（容许、回绝、监测）出入网络的信息流，且自身具备较强的抗攻击能力。它是提供信息安全服务，实现网络和信息安全的基础设施。在逻辑上，防火墙是一个分离器，一个限制器，也是一个分析器，无效地监控了内部网和Internet之间的任何流动，保障了外部网络的平安。

随着挪动办公的迅速遍及，企业正踊跃寻求更具创新性和高效性的形式来应答日常工作挑战。在这一浪潮中，智慧云作为一种引领性的解决方案，为企业带来了卓越的工作效率晋升和老本削减。让咱们深入探讨这种改革形式的劣势。 灵活性与合作 借助智慧云零碎，企业迎来了更为灵便的工作形式。不受工夫和地点限度，员工可能在任何中央、任何工夫拜访所需工作文件和应用程序。这种高度灵活性不仅有利于近程办公、出差等非凡状况，也可能促成团队合作，让各地的员工在共享文档、在线会议和即时消息等方面更加高效地协同工作。 定制化的治理 智慧云的可定制性使得企业可能依据本身需要调整和管理应用程序和工作流程。这使得企业可能更好地适应一直变动的市场环境，进步工作效率和灵活性。 弱小的数据分析和报告性能 智慧云不仅提供高效的工作平台，还装备了弱小的数据分析和报告性能。企业能够实时监控工作进展，进行数据分析，及时做出决策调整，进一步晋升工作效率和品质。 降低成本 智慧云在升高企业老本方面也施展着巨大作用。传统办公模式下，企业须要投入大量资金购买、保护和降级办公设备和软件，以及租赁办公场合。而借助智慧云，企业能够显著缩小这些收入。员工只需一台智能终端设备，即可轻松拜访业务利用和数据。同时，近程办公也缩小了对办公场合的需要，升高了租金和其余相干费用。 将来发展趋势 智慧云助力挪动办公未然成为企业的首选。它不仅晋升了工作效率，也实现了显著的老本削减。通过智慧云，企业可能更加灵便地组织和治理挪动办公，为将来办公形式的倒退奠定了松软的根底。正是智慧云所带来的颠覆性改革，使得企业可能以更高效、更翻新的形式应答日益简单的工作挑战，从而实现可继续的胜利。

一、主从架构为什么咱们要进行读写拆散？集体感觉还是业务倒退到肯定的规模，驱动技术架构的改革，读写拆散能够加重单台服务器的压力，将读申请和写申请分流到不同的服务器，摊派单台服务的负载，进步可用性，进步读申请的性能。 下面这个图是一个根底的Mysql的主从架构，1主1备3从。这种架构是客户端被动做的负载平衡，数据库的连贯信息个别是放到客户端的连贯层，也就是说由客户端来抉择数据库进行读写 上图是一个带proxy的主从架构，客户端只和proxy进行连贯，由proxy依据申请类型和上下文决定申请的散发路由。 两种架构计划各有什么特点： 1.客户端直连架构，因为少了一层proxy转发，所以查问性能会比拟好点儿，架构简略，遇到问题好排查。然而这种架构，因为要理解后端部署细节，呈现主备切换，库迁徙的时候客户端都会感知到，并且须要调整库连贯信息 2.带proxy的架构，对客户端比拟敌对，客户端不须要理解后端部署细节，连贯保护，后端信息保护都由proxy来实现。这样的架构对后端运维团队要求比拟高，而且proxy自身也要求高可用，所以整体架构相对来说比较复杂 然而不管应用哪种架构，因为主从之间存在提早，当一个事务更新实现后马上发动读申请，如果抉择读从库的话，很有可能读到这个事务更新之前的状态，咱们把这种读申请叫做过期读。呈现主从提早的状况有多种，有趣味的同学能够本人理解一下，尽管呈现主从提早咱们同样也有应答策略，然而不能100%防止，这些不是咱们本次探讨的范畴，咱们次要讨论一下如果呈现主从提早，刚好咱们的读走的都是从库，咱们应该怎么应答？ 首先我把应答的策略总结一下： 强制走主库sleep计划判断主从无提早等主库位点等GTID计划接下来基于上述的几种计划，咱们一一讨论一下怎么实现和有什么问题。 二、主从同步在开始介绍主从提早解决方案前先简略的回顾一下主从的同步 上图示意了一个update语句从节点A同步到节点B的残缺过程 备库B和主库A保护了一个长连贯，主库A外部有一个线程，专门用来服务备库B的连贯。一个事务日志同步的残缺流程是： 1.在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、明码，以及要从哪个地位开始申请 binlog，这个地位蕴含文件名和日志偏移量。 2.在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io\_thread 和 sql\_thread。 3.其中 io_thread 负责与主库建设连贯。 4.主库 A 校验完用户名、明码后，开始依照备库 B 传过来的地位，从本地读取 binlog，发给 B。备库 B 拿到 binlog 后，写到本地文件，称为直达日志（relay log）。 5.sql_thread 读取直达日志，解析出日志里的命令，并执行。 上图中红色箭头，如果用色彩深浅示意并发度的话，色彩越深并发度越高，所以主从延迟时间的长短取决于备库同步线程执行直达日志(图中的relay log)的快慢。总结一下可能呈现主从提早的起因： 1.主库并发高，TPS大，备库压力大执行日志慢 2.大事务，一个事务在主库执行5s，那么同样的到备库也得执行5s，比方一次性删除大量的数据，大表DDL等都是大事务 3.从库的并行复制能力，Msyql5.6之前的版本是不反对并行复制的也就是上图的模型。并行复制也比较复杂，就不在这儿赘述了，大家能够自行温习理解一下。 三、主从提早解决方案1.强制走主库这种计划就是要对咱们的申请进行分类，通常能够将申请分成两类： 1.对于必须要拿到最新后果的申请，能够强制走主库 2.对于能够读到旧数据的申请，能够调配到从库 这种计划是最简略的计划，然而这种计划有一个毛病就是，对于所有的申请都不能是过期读的申请，那么所有的压力就又来到了主库，就得放弃读写拆散，放弃扩展性 2.sleep计划sleep计划就是每次查问从库之前都先执行一下：select sleep(1)，相似这样的命令，这种形式有两个问题： 1.如果主从提早大于1s，那么仍然读到的是过期状态 2.如果这个申请可能0.5s就能在从库拿到后果，依然要等1s 这种计划看起来非常的不靠谱，不业余，然而这种计划的确也有应用的场景。 之前在做我的项目的时候，有这样么一种场景，就是咱们先写主库，写完后，发送一个MQ音讯，而后生产方接到音讯后，调用咱们的查问接口查数据，当然咱们也是读写拆散的模式，就呈现了查不到数据的状况，这个时候倡议生产方对音讯进行一个提早生产，比方提早30ms，而后问题就解决了，这种形式相似sleep计划，只不过把sleep放到了调用方 3.判断主从无提早计划命令判断show slave status，这个命令是在从库上执行的，执行的后果外面有个seconds\_behind\_master字段，这个字段示意主从提早多少s,留神单位是秒。所以这种计划就是通过判断以后这个值是否为0，如果为0则间接查问获取后果，如果不为0，则始终期待，直到主从提早变为0 ...

起源：java如何应用tldb MQ tldb是高性能分布式数据库 次要解决分布式服务问题与数据库集群问题基于 tldb，能够用最简洁最快的形式搭建分布式服务零碎java mq客户端tlmq-j开源地址：https://github.com/donnie4w/tlmq-j MQ是构建分布式我的项目的一把利剑，tldb mq是一个高性能，易用，易保护，牢靠的MQ服务 tlmq-j 的 mavan依赖配置： <dependency> <groupId>io.github.donnie4w</groupId> <artifactId>tlmq-j</artifactId> <version>0.0.1</version></dependency>应用阐明：先实例操作对象，SimpleClient第一个参数为服务器连贯，第二个参数是mq的用户名明码，用=连贯 MqClient mc = new SimpleClient("ws://127.0.0.1:5100", "mymq =123");MqClient是对立接口，SimpleClient为tlmq-j实现的繁难实现，实现了tldb mq的协定，反对断线重连，反对wss协定实现接管订阅信息的handler，用于接管服务器推送的信息 mc.pubJsonHandler((mb) -> {logger.info(mb.toString());});调用函数连贯服务器 mc.connect();订阅topic，MQ服务器订阅的topic，推送相应的信息 mc.sub("userinfo")公布信息. 公布信息即播送信息给所有订阅该topic的节点 mc.pubJson("userinfo", "this is java pubJson")其余函数阐明： 指定该连贯接管信息，服务器能够聚合多条信息一起发送，参数示意原传输数据的最大大小，单位M mc.mergeOn((byte) 10); 设定服务器压缩原数据大小下限 10MsubCancel是勾销该节点订阅的topic sc.subCancel("userinfo"); //订阅 topic “userinfo”pullIdSync是拉取指定topic的以后id，也即最大id，tldb mq 每个topic都有惟一id，都会在公布时自增， 用于客户端比拟判断本地是否有信息为接管到或失落数据 long id = mc.pullIdSync("userinfo");pullJsonSync与pullByteSync作用是拉取topic数据，第一个参数是topic，第二个参数是topic的id值 JMqBean jmb = mc.pullJsonSync("userinfo", 1); MqBean mb = mc.pullByteSync("userinfo", 1);tldb mq还有其余的接口请看《如何应用tldb MQ》有具体的接口阐明有任何问题或倡议请Email：donnie4w@gmail.com或 http://tlnet.top/contact 发信给我，谢谢！

禁用 第三方cookie 之后，通过亲测，论断是： 不肯定，百度统计还是有可能晓得你是谁的。但可能失准。 本想钻研一下百度统计是如何统计数据的，发现基本上是利用cookie。大抵状况是这样的： HMACCOUNT 或者是 HMACCOUNT_BFESS 用来标记用户，他们是第三方cookie，domain 属于 .hm.baidu.com，而且属性是 Secure 的，这样本地js是改不掉这个值的，只能通过 https 拜访时，网站返回的值来改。 Hm_lvt 和 Hm_lpvt 都是算工夫的，而且不仅是 cookie ，你的 LocalStorage 和 SessionStorage 也会把这两个值写一遍，避免cookie清空后隐没。 当初实测 禁用第三方cookie 之后，百度统计不会纳入计算，它本可依照新用户来计算，可他不违心这么做，可能有什么起因，咱们并不知道。 当初开发界的态度是越来越不待见第三方cookie，原本是为了跨网站不便用户的，当初被广告商或居心叵测的人利用的有点过分了。所以浏览器不仅仅是提供了 禁用第三方 cookie的选项，最近 Safari 和 Firefox 都默认禁止了 第三方cookie，Chrome 则应用 默认same-site: lax策略。 在第三方cookie人人喊打的当初，统计业的数据可能会越来越不准了。

起源：如何应用tldb MQ tldb是高性能分布式数据库 次要解决分布式服务问题与数据库集群问题基于 tldb，能够用最简洁最快的形式搭建分布式服务零碎tldb MQ是基于tldb分布式数据库根底之上的。它的次要侧重点在数据与性能方面，相对来说性能比拟少，次要就是订阅主题与公布主题信息 tldb MQ的音讯协定格局有两种：一是字节数组，一是字符串json格局 封装在tlmq客户端别离对应的对象是：MqBean{Id,Topic,Msg} 与 JMqBean{"Id":0,"Topic":"","Msg":""} tlmq客户端目前有4个 别离是Java，Python，Golang，JavaScript tlmq的客户端函数别离有：函数名称 作用 用例Connect 连贯服务器 Connect()Sub 订阅主题 Sub("userinfo")SubCancel 勾销订阅 SubCancel("userinfo")MergeOn 数据汇合发送 MergeOn(1)SetZlib 数据压缩 SetZlib(true)RecvAckOn 客户端回执 RecvAckOn(10)PullIdSync 拉取topic的以后Id PullIdSync("userinfo")PullJsonSync 拉取topic信息 PullJsonSync("userinfo",20)PullByteSync 拉取topic信息 PullByteSync("userinfo",20)PullJson 异步拉取topic信息 PullJson("userinfo",20)PullByte 异步拉取topic信息 PullByte("userinfo",20)PubMem 公布topic，不存储信息 PubMem("userinfo",“this is mem info”)PubJson 公布topic PubJson("userinfo",“this is json info”)PubByte 公布topic,字节数组 PubByte("userinfo",[1,0,1,0,1,0,1,0])PullByteHandler 异步解决PullByte拉取的信息 依据须要实现该办法或接口PullJsonHandler 异步解决PullJson拉取的信息 依据须要实现该办法或接口PubByteHandler 解决PubByte公布的信息 依据须要实现该办法或接口PubJsonHandler 解决PubJson公布的信息 依据须要实现该办法或接口PubMemHandler 解决PubMem公布的信息 依据须要实现该办法或接口AckHandler 解决服务器回执 如业务须要确认服务器收到客户端信息，则实现该办法或接口ErrHandler 解决服务器返回的错误码 服务器返回登录信息或客户端协定谬误的错误码Before 链接上服务器时触发该接口 依据须要实现该办法或接口能够应用曾经实现的客户端连贯服务器，也能够依据mq协定本人实现客户端如何应用tlmq-go 客户端： 引入包 import "github.com/donnie4w/tlmq-go/cli" ...

关系型数据库（Relational Database）和非关系型数据库（Non-Relational Database，也称NoSQL数据库）是两种不同类型的数据库管理系统。它们在数据组织形式、应用场景和特点上有所区别。 关系型数据库： 结构化数据：关系型数据库应用表格（表）来组织数据，每个表由行和列组成。表中的数据是以行和列的模式存储，具备固定的模式（schema），对数据的构造和关系进行严格定义。数据一致性：关系型数据库采纳ACID（原子性、一致性、隔离性、持久性）的事务处理机制，保证数据的完整性和一致性。反对简单的查问和关联操作，提供丰盛的查询语言（如SQL）。数据关系：通过主键和外键来建设表与表之间的关联关系，实现数据的强一致性。常见的关系型数据库有MySQL、Oracle、Microsoft SQL Server等。 非关系型数据库：非结构化数据：非关系型数据库以灵便的形式存储数据，通常应用键值对、文档、列族或图形等模式组织数据。数据模型绝对自在，更适宜存储半结构化和非结构化数据。大规模数据和高可用性：非关系型数据库设计用于大规模数据和高并发拜访的场景，具备良好的横向扩展性（可通过减少服务器节点来扩大存储和吞吐量）。提供高可用性、容错机制和主动数据分片。灵活性：非关系型数据库往往没有固定的模式，能够疾速适应变动的数据结构和需要。常见的非关系型数据库有MongoDB、Redis、Cassandra等。

在一起，共迎新时机！8月25-26日，2023华为数据存储用户精英论坛在西宁召开。酷克数据作为国内云原生数据仓库的代表企业，也是华为重要的生态合作伙伴，受邀参加本次论坛，并展现了云数仓畛域最新前沿技术以及联结华为打造的云数仓联结解决方案。 在本次论坛上，华为公布了分布式存储全闪新品OceanStor Pacific 9920。酷克数据外围产品HashData云数仓通过与华为OceanStor Pacific 的适配与优化，造成联结解决方案，为企业数字化转型提供高效 、稳固数据底座。 联手打造高效稳固数据底座HashData和华为的联结解决方案，采纳计算、存储拆散的设计，两者能够独立扩缩容，充分发挥云计算的弹性劣势，秒级扩缩容，反对万级计算机节点，并发拜访任意扩大；对立存储资源池，实现PB级数据随心共享。 图：HashData与华为联结展台基于HashData当先的产品架构和OceanStor Pacific弱小的存储能力，联结解决方案可能解决传统MPP数据库建设老本高、并发规模受限、扩容不灵便等“顽疾”，实现升高建设老本、弹性扩缩容、晋升业务实时性和故障疾速自愈。 通过理论测试，联结解决方案在容量和可靠性上都有极佳的体现： 反对千亿对象单桶存储，大容量下稳固百万TPS不下滑；存算独立建设扩容，TCO降落25%；打消集群间数据冗余，缩小50%有效空间占用；元数据/计算/存储拆散，业务并发无下限；云化资源管理，疾速申请虚拟机；共享存储池，数据无需同步，分钟级扩缩容；节点故障时可靠性不升高，超半数控制器故障时业务不中断；故障疾速接管，性能爬坡工夫缩短至分钟级；数据无需重散布，实现疾速自愈。同时，针对数据量较小的中小企业，HashData和华为独特推出了DataCube Lite一站式轻量大数据解决方案，提供大数据平台+数据治理+高效数仓服务，笼罩数据“采、存、管、算、用”全生命周期，具备轻量灵便、精存快算、软硬联合等个性，助力中小企业更好“上云用数”。 共建国产数据库产业新生态酷克数据与华为的单干渊源已久。早在2020年，HashData云数仓就与华为云鲲鹏云服务实现兼容性认证。尔后，单方基于各自的技术劣势，不断扩大单干畛域，深入单干成绩。           此次HashData联结华为存储打造云数仓解决方案，标记着单方的单干进入更全面、更深刻的新阶段。 酷克数据通过与华为的深度单干，实现了IT基础设施与利用的深度集成，进而实现了业务零碎的疾速发放，帮忙客户更加便捷地应用利用产品，减速解决方案上线效率。 将来，单方将基于华为共享存储不断加强联结计划翻新，打造高效、稳固、便捷的数据库利用解决方案，为客户提供更牢靠、更具性价比的全新抉择，独特推动国产数据库生态体系倒退，助力更多企业用好数据资源，独特创始数字经济美好未来。

起源：tldb 启动脚本示例tldb是高性能分布式数据库 次要解决分布式服务问题与数据库集群问题基于 tldb，能够用最简洁最快的形式搭建分布式服务零碎windows：单机模式脚本示例： win11.001.tldb.exe -mq=":5000" -admin=":4000" -cli=":7000" -dir="D:/tldb_data/_data0" -clus=0 -memlimit=512 -init=1linux单机模式脚本示例： nohup /usr/tldb/linux001_tldb -mq=":5000" -admin=":4000" -dir="/usr/tldb_data/_data0" -cli=":7000" -clus=0 -memlimit=512 &阐明：mq服务端口：5000治理后盾服务端口：4000数据库客户端服务端口：7000数据库文件地址：D:/tldb_data/_data0内存回收下限：512 MB启动初始化账号 -initlinux 集群模式脚本示例：数据库1： nohup /usr/tldb/linux001_tldb -mq=":5001" -admin=":4001" -cs=":6001" -dir="/usr/tldb_data/_data1" -cli=":7001" -memlimit=512 &数据库2： nohup /usr/tldb/linux001_tldb -mq=":5002" -admin=":4002" -cs=":6002" -dir="/usr/tldb_data/_data2" -cli=":7002" -memlimit=512 &数据库3： nohup /usr/tldb/linux001_tldb -mq=":5003" -admin=":4003" -cs=":6003" -dir="/usr/tldb_data/_data3" -cli=":7003" -memlimit=512 &关上其中一个数据库(任一)治理后盾，增加另外两个数据库服务地址即可。3台集群数据库主动实现同步和状态切换 以上实现服务节点增加，期待集群节点实现同步即可，实现同步后，期待集群状态主动由初始化切换到运行，阐明该集群能够进行数据操作了 有任何问题或倡议请Email：donnie4w@gmail.com或 http://tlnet.top/contact  发信给我，谢谢！

起源：tldb数据库的java客户端如何应用tldb是分布式nosql数据库，须要通过客户端接口进行数据操作 通过java有两种形式能够操作tldb， tlcli-j 与tldb接口对接，仅反对字节数组类型的数据，上传服务器数据为字节数组，其余类型须要转换为字节数组tlorm-java 基于tlcli-j实现的orm框架，反对java根底数据类型主动转换，应用十分简洁两种形式都能够间接连贯服务器进行建表，批改表构造，删除表， 增删改查表数据等操作 java 客户端：https://github.com/donnie4w/tlcli-j tlcli-j 的 mavan依赖配置： <dependency> <groupId>io.github.donnie4w</groupId> <artifactId>tlcli-j</artifactId> <version>0.0.2</version></dependency>java orm框架 ： https://github.com/donnie4w/tlorm-java tlorm-java 的 mavan依赖配置： <dependency> <groupId>io.github.donnie4w</groupId> <artifactId>tlorm-java</artifactId> <version>0.0.2</version></dependency>java demo： https://github.com/donnie4w/tldbjavaDemo 在我的项目中应用orm，从建表到数据增删改查，对数据库的操作能够齐全映射在对java类的操作。 如 我的项目tlnettim： https://github.com/donnie4w/tlnetim 该我的项目是go开发的，其长久层的操作用的是 tlorm-go ,tlorm-go与tlorm-java的操作根本一样，有局部中央稍有区别。 我的项目启动后 建表：tlorm-go的操作： //tldb orm 建表orm.Create[ImUser]()orm.Create[ImMessage]()orm.Create[ImLog]()如果是tlorm-java建表首先，创立 ImUser.java ImMessage.java ImLog.java 类必须继承 Orm 并申明泛型的类型 public class ImUser extends Orm{ public long id; public String Name; public String Pwd; public String Icon; public String Label; public String Time;}public class ImLog extends Orm{ public long id; @Index //创立UserId 索引 public long UserId; @Index //创立Room 索引 public String Room; public String Time;}public class ImMessage extends Orm{ public long id; public long UserId; public String Content; @Index public String Room; public String Time;}创立表： ...

作者：李家林 安能物流数据库团队负责人 本文以安能物流作为案例，探讨了在数字化转型中，企业如何利用 TiDB 分布式数据库来应答简单的业务需要和挑战。 安能物流作为中国当先的综合型物流团体，须要应答大规模的业务流程，面临着外围结算零碎所带来的数据库挑战。安能将结算零碎 all in TiDB，克服传统 MySQL 数据库所面临的瓶颈，实现安稳迁徙和性能晋升的同时，打造一栈式物流数据平台，减速数字化降级。 对于安能物流 安能物流（简称：安能）成立于 2010年，是中国当先的综合型物流团体，为企业组织及消费者提供平安、便捷、优质、高效的物流服务。截止到目前安能物流自有员工 20,000 多名，自建 136 个分拨转运核心，乡镇笼罩高达 98%以上，服务范畴遍布全国。安能自 2010 年成立开始，前后经验了七轮国内顶级资本的融资，于 2021 年双 11 在港交所胜利上市，成为“港股快运第一股”。在快运行业，安能领有中国零担快运市场最大的加盟网络，全网有 30,000 多家末端加盟商网点，自营车头和车挂数量高达 9,000多台。在产品服务方面，安能提供多样化的产品和特色业务，以满足不同用户的需要 。 TiDB 在安能结算零碎的利用安能结算零碎作为公司最外围的业务零碎，承载了总部 与末端 加盟商网点所有费用结算业务，包含： 账户治理、充值、开票、交易、调账、对账、代收、代付、税差等全费用结算业务流程解决。 从零碎的逻辑架构图来看，其性能及业务解决流程也是绝对简单的，目前该套零碎承载业务量： 日均 450,000 票，出货量 48,000 吨，反对末端 36,000 家网点实时开单算费扣款和定时批处理调账，日均用户数 3,800，调用量 5,000 万以上。 安能在 2017 年对结算零碎进行了重构，抉择了过后较为通用支流的 MySQL+ 数据库代理中间件分库分表的数据库架构，截止到 2023 年切换到 TiDB 之前，这套 MySQL 伪分布式数据库集群曾经运行了 6 年。在数据量方面：外围业务表 4 张，单表字段 360+，共分了 8 个库；单表数据 3 亿+，2TB 大小。零碎并发状况：30,000 多家网点开单高峰期集中在 16:30 -19:30 三小时内实现，数据库 QPS 均值为每秒 20,000，零碎均匀响应工夫在 80-100ms 内。 ...

公司简介Salla 是一家 2016 年成立，位于沙特麦加的自建站电商平台。 作为中东 Shopify，其最大的特点是反对阿拉伯语建站，并且提供更多适应中东地区特点的本地化服务。截止目前，已有 47,000 家店铺入驻 Salla，商品销售总额达到了 43 亿美元，近三年放弃了靠近 100% 的增速。 单干背景与 Salla CTO Salah Alkhwlani 的首次交换是在 23 年初。咱们诧异的发现，他们对产品的次要性能十分相熟，并且急不可待直奔主题心愿立刻洽购。预先理解到，随着业务的疾速倒退，联合其电商平台的属性，对于数据库的合规管控需要越来越急切。然而市场上的产品要么是独立的 SQL 客户端不足平安管控能力，要么只提供一些 SQL 脚本审核能力，要么只提供命令行的 SQL 公布能力，找不到任何一款产品能够将诸多环节买通构建残缺的数据库开发工作流。如果思考自研，作为一家疾速倒退的科技公司，将研发资源投入到与业务没有间接关联的需要上是一种微小的节约。直到他们发现了 Bytebase 这个产品，通过简略试用后，就立马意识到简直所有性能都像是为他们量身打造的。于是，在首次交换的短短三天后，Salla 就成为了 Bytebase 在中东地区的首个付费用户。 应用场景Salla 有大量的研发人员与经营人员，须要频繁地拜访数据库进行各类操作。作为托管大量用户数据的电商平台，又受到监管方的严格要求。因而，Salla 须要一个业余的软件，对所有绕开利用的间接数据库拜访行为进行管控，具体包含： 所有研发、经营团队对生产零碎数据的间接查问行为所有研发、经营团队对生产零碎数据的导出行为所有研发、经营团队对生产零碎数据的间接批改行为所有研发团队对生产零碎数据库的构造变更行为Salla 基于 Bytebase 构建了一套残缺的数据库拜访权限体系以及审核流程。 对于生产数据库的任何查问与导出行为 实现了细化到每一张表或每一条 SQL 的管控，并且能够将一些关键字段按需遮蔽脱敏。尤为要害的是，所有数据库能够在 Bytebase 中进行对立治理，无需针对每一个数据库设置不同的账号体系。权限能够按需进行被动申请或主动回收，也能够由管理员统一分配，大大简化了治理复杂度。 对于生产数据库的任何 DML & DDL 行为 构建了规范的公布工作流，所有变更申请须要提交工单，基于危险等级主动生成不同的审批流程，审批人基于主动审核工具的辅助高效的实现审核工作，再由专人按需一键公布到数据库。这一过程被对立集成到了 Bytebase 中，相比此前通过项目管理工具提交审核需要，管理员下载脚本人工审核再复制粘贴到数据库客户端公布的模式，新流程不仅大大晋升了合作效率，还极大升高了人为误操作的危险。 深刻单干在满足根本需要后，Salla 打算进行 GitOps 与 Terraform 的集成。通过 GitOps 工作流，能够让研发人员间接通过代码治理平台提交工单，实现与研发工作流的进一步整合。通过 Terraform，能够实现 Bytebase 所有配置的代码化，让管理员更不便的进行人员与数据库拜访权限的批量配置。同时，咱们也惊喜地发现，优质的产品联合服务，让 Salla 违心将咱们举荐给中东地区的同行们，帮忙咱们点亮了一个又一个新的客户，中东市场也意外成为了 Bytebase 的增长点。 ...

IP地址地理位置查问是一种通过IP地址获取设施所在地的技术。它的意义在于帮忙咱们更好地理解网络中的用户，为网络安全、定位用户市场剖析等提供便当。上面咱们来具体探讨一下IP地址地理位置查问的意义。 首先，IP地址地理位置查问对于网络安全至关重要。通过查问IP地址的地理位置，咱们能够判断用户的实在身份和地位。这对于防止网络立功、打击网络欺诈等十分重要。例如，在银行业务中，通过查问用户的IP地址能够精确判断用户的地位从而避免黑客攻击和非法转账。此外，通过地理位置查问能够及时发现并阻止歹意攻打爱护网络的平安稳固。 其次，IP地址地理位置查问能够帮忙定位用户。对于一些波及紧急事件的利用，如紧急呼叫核心、紧急救济等，通过查问IP地址的地理位置能够疾速定位用户的地位提供及时无效的帮忙。同时，在电子商务中，地理位置查问能够帮忙企业理解用户的散布状况和生产习惯从而更好地进行市场剖析和推广。 此外，IP地址地理位置查问还能够用于网络服务的个性化定制。通过查问用户的地理位置，网站能够依据用户所在地区提供相应的语言、货币等个性化设置，进步用户体验。同时，地理位置查问还能够用于内容散发依据用户所在地的网络情况和服务器散布状况将内容疾速传输给用户进步网站的访问速度。 总之，IP地址地理位置查问在网络安全、用户定位市场剖析等方面具备重要的意义。它能够帮忙咱们更好地理解网络用户的实在身份和地位，提供个性化的服务，并在网络安全方面施展重要作用。随着技术的不断进步，IP地址地理位置查问也将越来越准确和智能为咱们的网络应用带来更多的便当和平安保障。

为了帮忙大家及时理解中国数据库行业倒退现状、梳理以后数据库市场环境和产品生态等状况，从2022年4月起，墨天轮社区行业剖析钻研团队出品将继续每月为大家推出最新《中国数据库行业剖析报告》，继续流传数据技术常识、致力促成技术创新与行业生态倒退，目前已更至第十六期，并公布了共计122页的2022年度剖析报告。墨天轮8月《中国数据库行业剖析报告》已正式公布（点击即可跳转，欢送大家下载查阅），本期报盘点了墨天轮“中国数据库风行度排行”、新品公布、投融资等业内资讯，以此展示以后数据库市场倒退前沿动静。 本期报告重点聚焦数据仓库，具体介绍其架构演进、技术原理，并盘点总结五大技术个性与六大发展趋势，首发【寰球数据仓库产业图谱】，最初精选国内外典型的数据仓库产品案例介绍其原理个性，以期率领大家更加全面、深刻地把握数仓技术相干知识点与利用实际。 一、数据库排行榜及前沿动静本章节目录 8月中国数据库风行度排名剖析2023年8月的墨天轮中国数据库风行度排行榜共286个数据库参加排名，本月排行榜前十中，头部变动加剧。其中，OceanBase 间断九个月夺魁，TiDB 排名较上月回升一位至第二名，阿里云 PolarDB 间断两个月排名继续攀升本月已至第四名。   本月排行榜中一批有后劲的产品排名较上月有所回升，在第10-50名这一赛段不少数据库势不可挡冲进赛场。诸如百度自研并开源的 OLAP 数据库 Apache Doris 排名较上月回升一位至第16名；阿里云 Hologres 是8月新增参加排名的数据库，其排名直逼前二十来到第22名；星环科技打造的分布式关系型数据库 KunDB 本月排名回升3位至第28名；北京大学王选所数据管理实验室研发的面向 RDF 常识图谱的开源原生图数据库系统 gStore 本月排名回升至第31名；贝格迈思（Bigmath）自主设计研发采纳C++开发的新型智能数据库 AiSQL 产品 BigInsights ，本月排名较上月迅速攀升63名，现位列第33名等。 数据库行业倒退动静报告整顿了近期业内较受关注的投融资、新品公布等资讯。其中，2023年8月，财政部会同工业和信息化部钻研起草了对于数据库、操作系统、通用服务器、杀毒软件、中间件、便携式计算机、台式计算机、一体式计算机、工作站等政府洽购需要规范，数据库政府洽购需要规范别离包含分布式数据库和集中式数据库两类。此外，星环科技自主研发的企业级交互式数据检索统计分析平台 Transwarp Scope 2.5版本公布，报告对其个性性能进行了解读；数据库初创公司 Neon 取得 4600 万美元融资；Oracle 发表全面推出 MySQL HeatWave Lakehouse，使客户可能像查询数据库内的数据一样疾速地查问对象存储中的数据。此处因篇幅所限仅截取局部图片，具体内容可查阅报告。    二、数据仓库概述及技术演进本章节目录 数据仓库根本概述在没有数据仓库的时代，数据分析人员须要收集、荡涤、整合来自多个数据源的数据，并为每个决策反对环境做局部数据复制，过程耗时长并且准确率低。且因为零碎迭代更新快，数据源通常是曾经下线的旧业务零碎，这为数据分析工作削减了难度。在此倒退背景下，数据仓库（Data Warehouse） 应运而生。 报告第二章具体介绍了数据仓库的起源、分层架构、基本特征以及架构的演变、倒退历程。数据仓库是来自一个或多个不同起源的集成数据的地方存储库，将以后和历史数据存储在一个地位，用于为整个企业的员工创立剖析报告，具备面向主题、集成性、非易失性、时变性等个性。 而从1990年 Inmon 提出数据仓库概念至今，数仓的架构也经验了屡次演进，已由最后的传统数仓架构——离线数仓库——离线大数据架构、Lambda 架构、Kappa 架构以及 Flink 的火寒带出的流批一体架构，一直不便用户能以最天然、最小的老本实现实时计算。 此外，报告还总结了数仓从萌芽摸索到全企业集成时代、企业数据集成时代、凌乱时代–“数据仓库之父”间的论战、实践模型确认时代以及数据仓库产品百家争鸣时代的倒退历程坐标轴，望帮忙读者纵向把握其倒退脉络，具体内容可查阅报告。 数据仓库技术解析报告通过架构图展现了数据仓库的外围组件：地方数据库、ETL（提取、转换、加载）工具、元数据和拜访工具，并具体解析了数据仓库的五大关键技术：查问优化器、MPP架构、向量化、列式存储和数据压缩。 查问优化器的次要指标是抉择最优的执行打算，以最小化查问的执行老本，从而进步查问性能；而MPP架构能够减速对来自多个源的数据进行预处理操作，以便将数据整顿成适宜剖析的模式；向量化能够进步数据分析的效率，故被广泛应用于数据加载、转换、数据分析、简单查问等操作中；列式存储相比行式存储压缩率更高、读写效率更快，且能解决品质更高的数据；在数据仓库中，通常采纳行和列相结合的形式进行压缩，以进步存储效率。此处仅简略列举并截图展现了局部个性，欲了解具体内容查阅报告。    数字化转型浪潮卷起各种概念席卷而来，为帮忙大家梳理辨别，本章最初也介绍了数据湖、湖仓一体、智能湖仓等一些与经常易与数据仓库混同的相干术语的概念，感兴趣的敌人能够下载报告查阅。 三、数据仓库现状及将来趋势本章节目录 报告第三章则从倒退层面对数据仓库的现状、发展趋势进行了剖析。目前中国数据仓库市场依然存在厂商倒退历史较短、市场规模较少、上云过程较美国绝对滞后等问题。但中国企业的数字化场景更加丰盛，数字化的需要也更加迫切。整体来看，中国数据仓库市场的发展潜力非常微小，在将来较长时间内将经验快速增长。IDC预测，到2027年，中国数据仓库软件市场规模将达到27.3亿美元，2022-2027的5年市场年复合增长率（CAGR）为25.7%。 面对新技术的层出不穷，数据仓库将来会朝着实时剖析、云原生Serverless、湖仓一体、HTAP、数智交融以及流式数仓等方向倒退，报告对这六类发展趋势均进行了具体解读，此处因篇幅所限并未作详尽截图展现，大家可下载报告查阅。    最初，报告整顿公布了【寰球数据仓库产业图谱】，以开源与商业、中国与国外两个维度对寰球数仓产品进行辨别，望帮忙大家深刻把握数仓产业倒退，下载报告可查看高清版。 四、数据库产品典型案例剖析报告最初一章选取了国内外较为典型的数据仓库产品作为案例，介绍其外围架构、性能个性与利用实际等。 其中国外产品蕴含弹性数据仓库 Snowflake，具备残缺的SQL反对和半结构化和schema-less数据模式反对，是一种多租户、事务性、平安、高度可扩大的弹性零碎；数据仓库市场的奠基者 Teradata，次要实用于构建大规模数据仓库应用程序，其已于2023年正式发表将逐渐完结在中国的间接经营；谷歌的齐全托管的企业数据仓库 BigQuery 可帮忙用户通过机器学习、天文空间剖析和商业智能等内置性能来治理和剖析数据，利用云数据仓库助力数据驱动型翻新。 国内产品蕴含面向实时剖析的现代化数据仓库 Apache Doris，是一款基于 MPP 架构的高性能、实时的剖析型数据库，不仅能够反对高并发的点查问场景，也能反对高吞吐的简单剖析场景；分布式逻辑数据仓库 GBase 8a，其次要市场是商业剖析和商业智能市场，可利用于政府、党委、平安敏感部门、国防、统计等领有海量业务数据的行业；华为云企业级云分布式数据仓库服务 GaussDB(DWS) 是一种基于云基础架构和平台的在线数据处理数据库，提供即开即用、可扩大且齐全托管的服务；最初介绍了星环研发的助力企业构建一站式实时数仓 ArgoDB 以及阿里云研发的一站式实时数据仓库引擎 Hologres。此处仅展现本章节中局部内容，大家能够下载报告获取更多内容。    本文仅对8月《中国数据库行业剖析报告》的局部内容进行了摘录、整顿，更多残缺、具体内容大家能够下载报告全文理解，也欢送各位数据行业同道交换、探讨、建言献策，咱们一起见证、独特助力中国数据库产业的发展壮大！ 报告全文下载地址：https://www.modb.pro/doc/116039往期报告下载2022年4月-2023年8月中国数据库行业剖析报告合辑2022年中国数据库行业年度剖析报告更多精彩内容尽在墨天轮数据社区，围绕数据人的学习成长提供一站式的全面服务，继续促成数据畛域的常识流传和技术创新。增加社区墨天轮小助手（VX：modb666）可获取更多技术干货。

tldb 启动参数启动设置参数 阐明-dir 数据文件地址-mqtls wss协定 拜访MQ服务-admintls https协定 拜访治理后盾-clitls sslsocket数据库客户端拜访服务器-cs 节点之间集群服务链接地址-mq MQ服务地址-cli 数据库客户端服务器地址.-admin web治理后盾服务地址.-clus 默认零碎主动调配;值为0时,节点单点运行,大概0是为集群运行.-init 启用时，数据库会创立3个账户后盾：admin，MQ：mymq，客户端mycli 明码都为123如：tldb断定单机启动和集群启动的参数是 -clus 默认值为3 单机启动：tldb -clus=0 tldb不加-clus或 -clus的值大于0时，则断定为集群模式 以例子阐明参数作用： *tldb -clus=0 -dir=/home/data -admin=:4000 -cli=:7000 -mq=:5000 -mqtls=1 -init*这个脚本示意 单机启动：-clus=0数据文件地址：/home/data后盾治理拜访地址：http://127.0.0.1:4000客户端拜访地址：ip： 127.0.0.1 port：7000mq拜访地址 ： wss://127.0.0.1:5000 -mqtls=1示意：mq的拜访协定 wss ，否则 为ws-init 启动参数 示意启动时创立初始账户，别离为： 后盾治理账户：adminmq客户端： mymqdb客户端 ： mycli明码对立为： 123其余参数： 启动设置参数 阐明 -dir 数据文件地址-binsize binlog数据文件按每100M进行压缩备份-clitls wss协定 拜访MQ服务-admintls https协定 拜访治理后盾-mqtls sslsocket数据库客户端拜访服务器-clicrt 客户端平安拜访协定的SSL crt证书文件地址-clikey 客户端平安拜访协定的SSL key证书文件地址-mqcrt MQ平安拜访协定的SSL crt证书文件地址-mqkey MQ平安拜访协定的SSL key证书文件地址-admincrt 治理后盾平安拜访协定的SSL crt证书文件地址-adminkey 治理后盾平安拜访协定的SSL key证书文件地址-put 客户端链接增删改并发数,超过则排队期待-get 客户端链接查问并发数,超过则排队期待-ns 集群中节点命名空间必须雷同，否则不能连贯-pwd 集群节点之间链接明码-publickey 默认应用tldb程序中公钥;可另指定公钥地址-privatekey 默认应用tldb程序中私钥;可另指定私钥地址-cs 节点之间集群服务链接地址-mq MQ服务地址-cli 数据库客户端服务器地址.-admin web治理后盾服务地址.-clus 默认零碎主动调配;值为0时,节点单点运行,否则集群运行.-clus_final 默认零碎主动调配大小.值true时,-clus非零参数值失效有任何问题或倡议请Email：donnie4w@gmail.com或 http://tlnet.top/contact 发信给我，谢谢！ ...

行业背景近年来，随着能源行业数字化的一直推动，智能电网、可再生能源发电、分布式发电、微电网等技术蓬勃发展。越来越多的能源企业意识到数据管理与价值开掘对储能及能源利用有着重大意义，并开始摸索一套无效的数据库解决方案以应答分布式储能的需要。如何实现分布式储能在电网中的规模化聚合，晋升电网的运行安全性，同时加强电网对大规模及分布式可再生能源的无效消纳能力，是各大企业关注的重点。 痛点与挑战1. 数据库治理计划有效现有数据服务计划不仅难以实现分布式储能的聚合调控，且对大规模、跨区域多点布局的储能零碎反对难度大。如何对立纳管能源消纳、储能设施、电池模组情况等要害数据，进而进步数据管理效率和准确性显得尤为重要。 2. 能源数据采集和剖析老本昂扬简单能源场景下，测点多且数据量宏大，随之而来的数据实时采集和存储等昂扬老本不可避免；加之，目前市面上构建储能大数据分析能力普遍存在组件繁多、运维艰难以及昂扬的硬件资源投入老本等问题。这些都在很大水平上影响了企业的计划落地与推动。 3. 函数撑持断层分布式储能零碎中的电池、风机、空调等设施监控不足无效的函数反对，导致系统无奈精确预测和判断设施的状态与性能，问题难以及时排除、设施无奈及时培修。这给零碎的稳定性和可靠性带来了不可漠视的危险。 4. 对立可视化监控平台缺失可视化监控平台缺失可能导致设施监测、数据分析和故障排除等工作发展不畅，进而给业务零碎带来重大的管理负担。反之，多维数据看板平台可实现对分布式储能场景的透明化治理，缩小对人力看护的需要，从而降低成本投入。 解决方案 1. 多类型数据管理KaiwuDB 提供“时序引擎+关系引擎”双能力，别离对储能场景中的传感器数据（温度、湿度等）、电力数据（电池等）、器械管制状态值数据（空调等）等时序数据，以及设施信息、业务数据等关系数据进行对立汇聚与纳管。 2. 云边端一体化架构模式边缘端：适配低端工控机，基于 KaiwuDB 实现对数据的采集和短期存储，反对数据实时剖析；云端：通过部署 KaiwuDB 关系引擎、集成 KDP（数据服务平台），实现了数据的充沛利用，反对数据汇聚和全局剖析。计划价值1. 储能柜对电网的综合调节晋升毫秒级的数据实时查问与剖析能力，可升高储能场景的决策时延，晋升储能柜对电网的综合调节能力;并可进一步优化削峰填谷、平滑电荷、调频调峰、缓解配电阻塞等，大幅提高能源应用效率。 2. 设施利用率晋升KaiwuDB 跨模计算与剖析能力可将生产、设施的时序类数据与设施信息、业务的关系数据进行跨模剖析，得出设施的利用率、能效关系等状况，优化设施应用调度，晋升设施利用率，缩短设施服务寿命。 3. 数据的对立汇聚和纳管能力晋升KaiwuDB 云边端及集群的部署计划，灵便适配了储能零碎架构；基于数据订阅公布能力，可实现边缘侧和核心汇聚层同步、全局存储与简单剖析；借助 API 撑持云端利用，实现了数据的对立汇聚和纳管。 4. 数据业务价值晋升通过多类函数，如工夫切分类、数据切分类、窗口切分类等，帮忙用户搭建业务分析模型，排查电池、空调、能耗等问题；通过流式计算性能，满足实时计算和间断查问的储能剖析需要；联合数据公布订阅、API 和 BI 报表性能，实现数据可视化，助力实现全面的业务场景监控。

8月30日，由 NineData 和 SelectDB 独特举办的主题为“实时数据驱动，引领企业智能化数据管理”的线上联结发布会，圆满成功举办！单方聚焦于实时数据仓库技术和数据开发能力，展现如何通过弱小的生态开发兼容性，对接丰盛的大数据生态产品，助力企业疾速发展数据分析业务，独特摸索实时数据驱动的将来企业智能化数据管理解决方案。 本文依据玖章算术技术副总裁陈长城（天羽）在NineData X SelectDB 联结发布会的主题演讲内容整顿。 <p align=center>陈长城（天羽）玖章算术技术副总裁</p> ▶︎ 嘉宾简介 陈长城，曾任阿里云数据库中台负责人和阿里云数据库生态工具部总经理，前阿里云资深技术专家。率领阿里云数据库基础设施实现三次架构改革，从去 IOE 到分布式、异地多活、容器化和存储计算拆散，是历年双 11 大促的数据库外围负责人和容量、架构规划者。主导云原生工具体系架构降级并打造一站式治理能力。发表过多篇技术专利和 VLDB、ICDE 数据库顶会论文。 01 NineData产品介绍 在数据和云的时代企业数字化面临诸多挑战，从Gartner和Percona的报告中，咱们晓得80%以上的企业会抉择多云或混合云，而超过70%的企业会抉择应用多种数据库来满足业务需要。在行业的剖析报告中，咱们发现，如果企业可能无效应用多源基础架构和新的数据架构，它们的创新能力和整体盈利能力将会显著晋升。然而，在数据和云的时代下，企业数据管理的挑战更多，例如数据孤岛、多源异构数据管理复杂度以及开发效率等，都是急需解决的。 基于上述普遍存在的问题和挑战，玖章算术建设了NineData云原生智能数据管理平台。最底层IaaS接口层对立对接各场景的各种数据源，基于此建设NineData数据备份、数据复制、数据比照和SQL开发四大外围功能模块，与企业的数据库、搜寻、音讯队列、数仓等数字零碎严密联动，帮忙企业爱护数据资产，基于多云和混合云灵便构建基础设施，对立平安治理，晋升数据库开发效率。 这里开展介绍一下SQL开发，它是一种让企业内外部所有开发者都遵循对立数据拜访标准并晋升效率的最佳实际产品化，以后企业面对多云和多种数据源，尽管各种数据源有各自的CLI或图形管理工具，但存在这些问题： 权限扩散、审计欠缺，平安管控难度大 ；各个工具建设水平不一，体验个别，开发效率低；无奈造成对立标准，数据库生产稳定性不足保障；多环境、多种数据源无奈对立治理。针对这些问题，NineData设计了企业级数据库安全治理能力，通过对立数据源对接各云厂商和自建的各种数据源，设计工作流和审批流、平安规定配置、权限治理与操作审计、SSO反对等根底组件，将企业的数据（实例、库、表）+  账号角色 + 操作类型 通过规定引擎对立治理，并内置数据库SQL开发的稳定性和平安最佳实际，提供数据库拜访权限治理、变更治理、敏感数据治理、数据导入导出等性能。NineData提供简略GUI的个人版和高效协同的企业版两种服务形式，并联合大模型AIGC的能力，在天然语音查问数据、表结构设计改写、SQL优化倡议方面晋升开发者效率。 企业在数据复制场景下也面临着多数据源、多云数据买通、跨地区长周期复制，以及由此带来的同能和稳定性方面的问题。NineData数据复制致力于提供数据流动的基础设施。打消不同数据库类型、不同厂商、不同环境下的造成的数据流动难点，帮忙企业最大地施展数据价值。目前NineData以及反对13种数据源的单双向链路，强劲的复制性能和欠缺的数据比照性能，具体将在前面开展。 02 数据复制技术架构 先介绍下NineData整体架构，基于多云和多源能力，咱们构建了数据备份、数据复制、数据比照和SQL开发能力。 2.1 多云角度 从多云角度，为了帮忙企业对立治理扩散在多云或混合云的各种数据源，咱们设计了灵便的云原生架构、容器化弹性拉起、网络架构等。 ▶︎  反对专属集群 反对多云的同时，咱们通过专属集群的技术，可能让企业独享自身的资源。包含咱们能够把企业的worker节点搁置在企业本地或VPC外部，实现数据的外部闭环，进步企业数据安全和worker执行效率。 ▶︎  云原生的 SAAS 模式 NineData 作为一个云原生的 SAAS 产品，按需拉起、弹性伸缩是最根本的能力。 ▶︎  网络安全 网络方面，基于平安思考，很多企业客户不心愿裸露数据库的公网端口，因而，咱们设计了一个数据库网关，通过这种设计，用户只需拉起一个NineData数据库网关，就可能连贯咱们的核心治理节点，从而建设反向拜访通道，可能把散落在各地、以及包含外部的数据源的对立治理。此外，咱们的NineData worker也能够放到用户本地，实现数据链路的外部闭环，而治理链路仍然能够通过核心控制台实现对立的链路管理。 2.2 多源方面 在多源方面，咱们次要设计了对立数据源接入层。为了接入泛滥数据源，咱们对数据源的连接池治理、属性配置、连贯检查和平安认证做了对立形象。这样能够将所有的数据源对立接入。咱们的四大次要功能模块都应用雷同的数据源接入层，实现一次接入所有性能都可用。对于用户来说，就实现了真正的对立治理。 在NineData的产品设计中，平安不是繁多的工作或性能，而是从头至尾灌输在产品设计、开发、运维的全过程中，咱们在数据传输加密、运维白屏、操作审计方面做了很多工作，同时NineData通过内部测试和三方审计多方位爱护数据安全。 一个典型的NineData数据复制链路拓扑，当您配置完源和指标之后，NineData 就会让整个链路开始运行。一开始会有一个预查看，查看您的网络连接、账号密码等是否正确。接下来会进行构造复制，抓取和写入全量数据和增量数据。 从产品层面，咱们要反对多云多源，除了下面介绍的弹性架构和网络架构外，咱们在复制模块的多种数据类型兼容和扩展性做了重要的设计，同时多源异构长期运行必然存在少部分不兼容场景，咱们在可观测和可干涉方面也重点做了功能设计。数据传输内核模块的底线是保障数据统一，同时在吞吐和延时上具备当先的劣势，因而咱们在这方面做了很多工作。前面外围个性的分享将围绕这几个点进行开展。 03 数据复制的外围个性 3.1 吞吐能力 以全量性能为例，次要有几个重要的优化项： ▶︎  大表迁徙性能 ...

在当今数字化时代，互联网曾经成为人们生存中不可或缺的一部分。然而，与之同时也带来了一系列安全隐患包含危险用户的存在。为了爱护网络安全和用户隐衷，追踪IP地址地位曾经成为一种常见的伎俩。 首先，什么是IP地址？IP（Internet Protocol）地址是互联网上计算机和设施的惟一标识符。通过追踪IP地址，能够确定用户的大抵地理位置。只管IP地址追踪不能提供准确到具体街道的地位信息，但能够帮忙警方和网络安全专家定位危险用户。 追踪IP地址地位的次要目标是辨认和追捕犯罪分子。网络立功日益猖狂，追踪IP地址成为追捕立功嫌疑人的重要伎俩之一。通过追踪犯罪分子的IP地址，警方能够追踪他们的行踪并采取相应口头。 此外，追踪IP地址地位还能够帮忙防止网络欺诈和偷盗行为。例如，一些诈骗者利用虚伪身份和匿名IP地址进行网络欺诈流动。然而，通过追踪IP地址能够发现并阻止这些欺诈行为爱护用户的利益。 然而，应该留神到追踪IP地址地位也存在一些潜在的问题。首先，IP地址并不是相对精确的地理位置信息。因为网络的复杂性和技术限度，IP地址追踪的定位后果可能有误差。其次，追踪IP地址波及到用户隐衷和个人信息的爱护问题。追踪IP地址可能泄露用户的个人信息，进犯用户的隐私权。 为了均衡网络安全和个人隐私之间的关系，追踪IP地址必须遵循严格的法律和道德准则。国家和地区应该出台相干法律法规，明确规定何时能够追踪IP地址以及追踪的目标。此外，网络服务提供商和网站运营商也应该增强安全措施爱护用户的个人信息和隐衷。 追踪IP地址地位是一种常见的伎俩用于爱护网络安全和追捕犯罪分子。尽管追踪IP地址有肯定的危险和隐衷问题，但在非法的前提下，并遵循相干法律和道德准则，追踪IP地址能够施展重要作用爱护用户的利益和网络安全。

提到数据处理，常常有人把它简称为“ETL”。但认真说来，数据处理经验了ETL、ELT、XX ETL（例如，Reverse ETL、Zero-ETL）到当初风行的EtLT架构几次更迭。目前大家应用大数据Hadoop时代，次要都是ELT形式，也就是加载到Hadoop里进行解决，然而实时数据仓库、数据湖的风行，这个ELT曾经过期了，EtLT才是实时数据加载到数据湖和实时数据仓库的规范架构。 本文次要解说下几个架构呈现的起因和善于的场景及优缺点，以及为什么EtLT逐渐取代了ETL、ELT这些常见架构，成为寰球支流数据处理架构，并给出开源实际办法。 ETL时代（1990-2015）在数据仓库晚期时代，数据仓库提出者Bill Inmmon把数据仓库定义为分主题的存储和查问的数据存储架构，数据在存储时就是按主题分门别类荡涤好的数据。而理论状况也如此，大部分数据源是架构化数据源（例如，mysql、Oracle、SQLServer、ERP、CRM等等），而作为数据集中处理的数据仓库大部分还是以OLTP时代查问和历史存储为主的数据库（DB2、Oracle），因而数据仓库在面对简单ETL解决时并不得心应手。而且这些数据库购买老本都比拟高，解决性能较弱，同时，各种各样的软件数据源越来越多。为了更不便地整合简单的数据源、分担数据计算引擎累赘、大量的ETL软件呈现，大家耳熟能详的Informatica、Talend、Kettle都是那个年代的典型软件产品，很多软件至今还在很多企业的传统架构当中配合数据仓库应用。 长处：技术架构清晰、简单数据源整合顺畅、ETL软件分担靠近50%的数据仓库工作 毛病：所有解决都由数据工程师实现，业务需要满足工夫较长；硬件老本简直投入双份，数据量大时硬件老本过高 在数据仓库晚期和中期，数据源复杂性比拟高的时候，ETL架构简直成为行业标准风行了20多年。 ELT时代（2005-2020）随着数据量越来越大，数据仓库的硬件老本与ETL硬件老本双向增长，而新的MPP技术、分布式技术呈现导致在数据仓库中后期和大数据衰亡时代，ETL的架构逐渐走向ELT架构。例如，当年数据仓库最大厂商Teradata、至今风行的Hadoop Hive架构，都是ELT架构。它们的特点就是，将数据通过各种工具，简直不做join,group等简单转化，只做标准化（Normolization）间接抽取到数据仓库里数据筹备层（Staging Layer），再在数据仓库中通过SQL、H-SQL，从数据筹备层到数据原子层（DWD Layer or SOR Layer）；前期再将原子层数据进入汇总层（DWS Layey or SMA Layer），最终到指标层（ADS Layer or IDX Layer）。尽管Teradata面向的结构化数据，Hadoop面向非结构化数据，但寰球大数据和数据仓库简直用的同一套架构和方法论来实现3-4层数据存储架构。 长处：利用数据仓库高性能计算解决大数据量解决，硬件ROI更高；同时，简单业务逻辑能够通过SQL来用数据分析师和懂业务逻辑的技术人员来解决，而无需懂ETL(如Spark, MapReduce)升高数据处理人员总成本。 毛病：只实用于数据源比较简单、量比拟大的状况，面对简单的数据源显著解决形式有余；同时间接加载，数据筹备层到数据原子层简单度过高，无奈通过SQL解决，往往利用Spark、MapReduce解决，而数据反复存储率较高；无奈反对实时数据仓库等需要。 面对ELT的数据仓库无奈加载简单数据源，实时性比拟差的问题，已经有一个过渡性解决方案被各种公司办法采纳，叫做ODS（Operational Data Store）计划。将简单的数据源通过实时CDC或者实时API或者短时间批量（Micro-Batch）的形式ETL解决到ODS存储当中，而后再从ODS ELT到企业数据仓库当中，目前，还有很多企业采纳此种形式解决。也有局部企业，把ODS搁置在数据仓库当中，通过Spark、MapReduce实现后期的ETL工作，再在数据仓库（Hive、Teredata、Oracle、DB2）当中实现前期的业务数据加工工作。 其实此时，EtLT初期的人群曾经造成，它的特点是人群划分开，简单的数据抽取、CDC、数据结构化、规整化的过程，往往由数据工程师实现，咱们叫做小“t”，它的指标是从源零碎到数据仓库底层数据筹备层或者数据原子层；而简单的带有业务属性的数据原子层到数据汇总层到数据指标层的解决（带有Group by、Join等简单操作）往往是善于应用SQL的业务数据工程师或者数据分析师来解决。而ODS架构的独立我的项目也随着数据量级变大和EtLT架构的呈现逐渐淡出历史舞台。 EtLT （2020-将来）EtLT的架构是由James Densmore 在《Data Pipelines Pocket Reference 2021》中总结提到的一个古代寰球风行的数据处理架构。EtLT也是随着古代数据架构（Modern Data Infrastructure）变动而产生的。 EtLT架构产生的背景古代数据架构架构有如下特点 ，导致EtLT架构呈现： 云、SaaS、本地混合简单数据源数据湖与实时数据仓库新一代大数据联邦(Big Data Federation)AI利用大暴发企业数据社群（Data Community）决裂简单数据源呈现当初寰球企业运行当中，除了传统的软件、数据库之外，云和SaaS的呈现将本曾经很简单的数据源状况更加简单，于是面对SaaS的解决，北美企业提出了新的数据集成（Data Ingestion）的概念，例如 Fivetran，Airbyte，以解决SaaS数据进入数据仓库（例如Snowflake）当中的ELT问题，它是传统ELT架构在SaaS环境下的降级。而云端数据存储（例如，AWS Aruroa，AWS RDS，MongoDB Service等）和传统线下数据库与软件（SAP、Oracle、DB2等）在混合云架构（Hybrid Cloud）也在迅速减少数据源复杂性。传统的ETL和ELT架构就无奈满足如此简单环境的数据源解决。 数据湖与实时数据仓库在古代数据架构环境下，数据湖的呈现交融了传统的ODS和数据仓库的特点，它能够做到贴源的数据变更和实时数据处理（例如 Apache Hudi, Apache Iceberg，Databricks Delta Lake），针对传统的CDC（Change Data Capture）和实时数据流计算都做了数据存储构造变动（Schema Evolution）和计算层面的反对。同时，实时数据仓库理念呈现，很多新型计算引擎（Apache Pinnot、ClickHouse、Apache Doris）都将反对实时ETL提上日程。而传统的CDC ETL软件或者实时计算流计算（Datastream Computing）对于数据湖和实时数据仓库的反对，要么是在新型存储引擎反对要么是在新型数据源连贯方面存在很大问题，不足很好的架构和工具反对。 ...

作者 | 李晨 编辑 | Debra Chen 数据筹备对于推动无效的自助式剖析和数据科学实践至关重要。现在，企业大都晓得基于数据的决策是胜利数字化转型的要害，但要做出无效的决策，只有可信的数据能力提供帮忙，随着数据量和数据源的多样性持续呈指数级增长，要实现这一点更加艰难。 现在，很多公司投入了大量工夫和金钱来整合他们的数据。他们应用数据仓库 或数据湖来发现、拜访和应用数据，并利用AI推动剖析用例。但他们很快意识到，在湖仓中解决大数据依然具备挑战性。数据筹备工具是缺失的组成部分。 什么是数据筹备，挑战是什么数据筹备是清理、标准化和丰盛原始数据的过程。这使数据筹备好利用于高级剖析和数据迷信用例。筹备数据须要执行多项耗时的工作，以便将数据挪动到数据仓库或数据湖，包含： 数据提取数据荡涤数据标准化数据对外服务大规模编排数据同步工作流除了耗时的数据筹备步骤外，数据工程师还须要清理和规范化根底数据，否则，他们将无奈了解要剖析的数据的上下文，因而通常应用小批量的Excel数据来实现此目标。但这些数据工具有其局限性，首先，Excel无奈包容大型数据集，也不容许您操作数据，更无奈为企业流提供牢靠的元数据。筹备数据集的过程可能须要数周到数月能力实现。考察发现，大量企业破费多达80%的工夫筹备数据，用来剖析数据并提取价值的工夫只有区区20%。 翻转 80/20 规定随着非结构化数据的增长，数据工具在删除、清理和组织数据上破费的工夫比以往任何时候都多。数据工程师常常会疏忽要害谬误、数据不统一和处理结果异样，与此同时，业务用户要求失去数据的工夫越来越短，对用于剖析的高质量数据的需要却比以往任何时候都大，目前的数据筹备办法根本无法满足需要。数据工程师和数据分析师往往破费超过80%的工夫查找和筹备所需的数据。这样一来，他们只有 20% 的工夫用于剖析数据并取得业务价值，这种不均衡被称为80/20规定。 那么如何无效扭转80/20规定？对于简单的数据筹备，须要一种麻利、迭代、合作和自助服务的数据管理办法-DataOps，来帮忙企业大幅晋升数据筹备的效率，将80/20的节约转变为公司的劣势。DataOps平台使IT部门可能为其数据资产提供自助服务性能，并使数据分析师可能更无效的发现适合的数据，同时利用数据品质规定和与别人更好地合作，在更短的工夫内交付业务价值。 在正确的工夫为数据分析师提供正确的数据意味着能够筹备简单的数据，能够利用数据品质规定，并能够在更短的工夫内交付业务价值。有了这些企业级数据筹备工具，数据团队和业务团队将会： 缩小在数据发现和筹备上破费的工夫，并减速数据分析和AI我的项目解决存储在数据湖中的大量结构化和非结构化数据集放慢模型开发并推动业务价值通过预测性和迭代式剖析发现简单数据中暗藏的价值白鲸开源如何提供帮忙白鲸开源DataOps平台WhaleStudio提供无代码、麻利的数据筹备和数据合作平台，这样，企业能够更专一于数据科学分析、人工智能（AI）和机器学习（ML）用例。 笼罩全流程的编排调度和OPS能力智能和自动化对于速度、规模、敏捷性至关重要，数据开发的每个步骤都受害于弱小的编排和调度能力，这些性能将进步企业解决数据的速度和规模，还可能跨云平台和解决引擎治理各类数据工作。白鲸开源WhaleStudio中的对立调度零碎——白鲸调度零碎（WhaleScheduler）会帮忙您建设数据采集、加工、运维、服务一站式、体系化、规范化的流水线管理模式，通过对立数据编排调度，为数据生产流水线提供服务，让数据能力服务经营过程更加平安、麻利和智能化。 同时，WhaleStudio基于DataOps最佳实际，为您的环境带来敏捷性、生产力和效率，能够帮忙您通过更频繁、更快、更少谬误地公布来获取即时反馈。WhaleStudio中的IDE和协同平台为您提供开箱即用的 CI/CD 性能，这些使您可能突破开发、经营和平安方面的孤岛，在整个数据开发生命周期中提供统一的体验。图片 引入数据确定解决流程后，须要将数据引入数据湖，通常会先进行数据初始化，将根底数据全量引入湖中，随后从数据源捕捉变更数据 （CDC）进行增量加载，以实现实时的数据捕捉。 借助白鲸开源WhaleStudio中的数据同步工具WhaleTunnel，开发人员能够主动加载文件、数据库和 CDC 记录，云原生解决方案容许您以任何提早（批量、增量、准实时、实时），疾速引入任何数据。它应用简略，是向导驱动的低代码操作，不便任何人员开箱即用。 确保数据可信和可用将数据摄取到数据湖后，须要确保数据洁净、可信且随时可供使用。白鲸开源的数据集成和数据品质解决方案，使开发人员能够在简略的可视化界面中应用拖拽形式来疾速构建、测试和部署数据管道。 构建在白鲸调度零碎（WhaleScheduler）中的数据品质模块，提供全方位的数据品质性能，包含数据分析、清理、反复数据删除和数据验证，帮忙用户防止“垃圾进垃圾出”的问题，确保数据洁净、可信且可用。而白鲸调度零碎（WhaleScheduler）中的元数据模块，提供了血统剖析性能，帮忙企业疾速针对各种数据源和指标的状况进行剖析，放慢开发人员之间的交接和代码审核效率，进一步确保数据的准确性。 创立高性能数据处理管道一旦数据进入数据仓库或者数据湖中，数据使用者可能心愿进一步对数据集进行切片和剖析，则能够持续应用白鲸调度零碎（WhaleScheduler）的可视化设计器来构建DAG逻辑。而构建在WhaleTunnel中的数据集成性能，可能应用无代码接口疾速构建高性能的端到端数据管道，使开发人员能够轻松地在任何云或本地零碎之间挪动和同步数据。批流一体的数据同步形式能够完满兼容离线同步、实时同步、全量同步、增量同步等多种场景，这在极大水平上升高了数据集成工作治理的艰难。 综上所述，白鲸开源WhaleStudio套件能够帮忙企业解决外部多数据源、多数据系统简单的数据集成，继续开发、继续部署、数据捕捉、数据买通等一些列问题，减速数据筹备过程，全面晋升数据分析和大模型构建的能力。 本文由 白鲸开源科技 提供公布反对！