1. Hintergrund
Gegenwärtig wird die Prioritätsstufe der von Echtzeit-Data-Warehouses bereitgestellten Echtzeit-Lieferindikatoren immer wichtiger. Insbesondere die von nachgeschalteten Regel-Engines bereitgestellten Data-Warehouse-Daten haben einen direkten Einfluss auf die Werbebereitstellung von Werbevorgängen. Datenverzögerungen oder -anomalien können zu direkten oder indirekten Vermögensverlusten führen. Verlust; Aus dem Verbindungspanorama der Lieferverwaltungsplattform geht hervor, dass die aktuelle Lieferung ein Betriebsprozess mit geschlossenem Regelkreis ist. Das Echtzeit-Data-Warehouse ist ein wichtiger Knotenpunkt in der Datenverbindung . Die Echtzeitdaten unterstützen direkt den automatisierten Betrieb der Regel-Engine und der Zustellung. Manuelle Steuerung der Verwaltungsplattform; Knotenunfälle in Echtzeit können dazu führen, dass die gesamte Zustellungsverbindung nicht normal funktioniert; um eine Stabilität von 99,9 % zu erreichen Beim Lieferlink ist es notwendig, die Stabilität und Priorität der Linkaufgaben zu verbessern.
Der umfassende Bewertungsplan für F&E-Tests fügt dem Live-Link einen Backup-Link hinzu, iteriert die Lieferanforderungen und nimmt iterative Änderungen über den Backup-Link vor. Nach Abschluss der Änderung wird ein Diff der Haupt- und Backup-Links durchgeführt, um sicherzustellen, dass der Diff besteht Die Rate beträgt 99,9 % und dann kann es online gehen.
2. Umsetzungsplan
-
Datenaufbereitung: Die von den aktiven und Backup-Links generierten Daten werden in Echtzeit in ODPS geschrieben.
-
Datenerfassung: Der Testtool-Dienst erfasst gleichzeitig aktive und Backup-Link-Datenabschnitte und behält zwei Kopien der Daten im gleichen Zeitraum bei.
-
Reduzierung und Differenzierung von Datenrauschen: Nachdem das Tool Daten erfasst hat, führt es den ersten Schritt der Verarbeitung zur Rauschreduzierung durch; die Primär- und Backup-Daten beginnen mit dem Vergleich und der zweite Schritt der Verarbeitung zur Rauschreduzierung.
-
Datendifferenzergebnis: Verarbeiten Sie das Ergebnis des Datenvergleichs, bestimmen Sie den Unterschied in jedem Feld und bestimmen Sie schließlich den Unterschied in den Gesamtdaten und geben Sie das Ergebnis an.
3. Richten Sie Primär- und Backup-Links ein
Erläuterung des Echtzeit-Links: Die Quelldaten werden in Kafka geschrieben, Flink verwendet die Kafka-Daten als Datenquelle (Quelle), kombiniert die Attributfelder, um eine Operatorverarbeitung durchzuführen (Transformatin), und die Verarbeitungsergebnisse werden in Kafka geschrieben (Senke). für den nächsten Verarbeitungsschritt. Die Verarbeitung wird über jeden Flink-Aufgabenknoten an die Anwendungsdatenbank gestreamt.
4. Datenvorbereitung – Datenaufteilung
Zeitfensterscheibe
Teilen Sie es entsprechend dem Testzeitpunkt auf und fixieren Sie die Daten von 0 Uhr am Tag bis zum Ausführungszeitraum, um sicherzustellen, dass die Daten nicht mehr aktualisiert werden.
Geschäftsszenario-Slicing
Verschiedene Geschäftsszenarien werden iterativ in Slices unterteilt und der Datenstrom wird bereitgestellt, um eine Vielzahl nachgelagerter Szenariodaten bereitzustellen. Die Slices sind für die iterierten Geschäftsszenariodaten festgelegt. Zum Beispiel: Felder_a='b'
5. Aktive und Standby-Verbindungsdaten-Diff-Differenzierung
Datendriftproblem
Symptom: Der Datenfluss wird ständig aktualisiert. Der Datenfluss derselben Geschäftsdaten wird auf den neuesten Stand gebracht. Der Hauptlink gelangt möglicherweise in die Partition des Tages und der Backup-Link gelangt möglicherweise in die Partition des nächsten Tages.
Rauschunterdrückungsplan: Nehmen Sie das letzte Datenelement aus dem Datenstrom.
Problem mit der Häufigkeit der Datenaktualisierung
Symptom: Während des Aktualisierungsprozesses derselben Geschäftsdaten wird der Hauptlink möglicherweise zehnmal aktualisiert, die Daten werden in den nächsten fünf Malen nicht geändert und der Backup-Link wird nur fünfmal aktualisiert.
Rauschunterdrückungslösung: Nehmen Sie N Datenelemente aus dem Datenstrom für dieselben Geschäftsdaten.
Problem mit der Aktualität der Datenaktualisierung
Problemphänomen: Während desselben Geschäftsdatenaktualisierungsprozesses aktualisiert der Hauptlink drei Daten auf 11.68, 12.9 und 13.05; der Backup-Link aktualisiert drei Daten auf 11.68, 12.9 und 13.1; es ist ersichtlich, dass die Daten im nächsten Schritt aktualisiert wurden Die Zeit ist nicht gleich. Gleich.
Entrauschungslösung: Die Datenströme derselben Geschäftsdaten werden in einer Liste zusammengeführt, und Master und Slave ermitteln gemeinsam, ob die letzten Daten in der von der anderen Partei abgefangenen Datenstromliste vorhanden sind.
Das Problem inkonsistenter Attributfeldwerte
Symptom: Es gibt leere Zeichen, Null, 0 und 0,0. Das Diff-Ergebnis ist fehlgeschlagen, aber die tatsächliche Geschäftsbedeutung ist in Ordnung.
Rauschunterdrückungslösung: Diff nach einheitlicher Konvertierung.
Das Problem der Inkonsistenz in den Nachrichtenfeld-Parsing-Attributfeldern der aktiven und Standby-Links
Symptom: Das Nachrichtenfeld speichert Daten im JSON-Format. Für dieselben Geschäftsdaten sind die Attributfelder, die dem von den primären und sekundären Links analysierten JSON entsprechen, nicht vollständig konsistent, und es gibt Unterschiede zwischen den beiden.
Rauschunterdrückungslösung: Analysieren Sie alle Attributfelder mithilfe des Codes, um einen vollständigen Diff sicherzustellen.
Nachrichtenvorlage:
{"fields_a":"20230628","fields_b":"2023-06-22 19:48:24","fields_c":"2","fields_d":"plan","fields_e":"3******","fields_f":"0.0","fields_g":"2","fields_h":"4*****","fields_i":"ext","fields_j":"binlog+odps","fields_k":"2","fields_l":"STATUS_*****","fields_m":"1********","fields_n":"孙**","fields_o":"2023-06-28T22:19:43.872"}
JSON konvertieren:
{
"fields_a": "20230717",
"fields_d": "plan",
"fields_e": "3******",
"fields_aj": "33761.125",
"fields_p": "37934.0",
"fields_r": "1250.412",
"fields_s": "1250.412",
"fields_t": "33761.125",
"fields_w": "33761.125",
"fields_m": "1*********",
"fields_v": "33761.125",
"fields_y": "33761.125",
"fields_n": "孙**",
"fields_z": "1250.412",
"fields_ai": "27",
"fields_ak": "",
"fields_aa": "33761.125",
"fields_ab": "33761.125",
"fields_ac": "33761.0",
"fields_al": "0.1002",
"fields_i": "***",
"fields_j": "***",
"fields_k": "2",
"fields_ad": "1.0",
"fields_ak": "37934.0",
"fields_x": "1250.412",
"fields_y": "0.0",
"fields_ag": "27",
"fields_af": "27",
"fields_ah": "0.0",
"fields_al": "0.0",
"fields_am": "0.0",
"fields_ao": "37934.0",
"fields_ap": "37934.0",
"fields_an": "33761.125",
"fields_aq": "1*********",
"fields_ae": "27",
"fields_o": "2023-07-17T23:59:00.103",
"fields_ar": "0.1002"
}
Die oben genannten fünf Probleme können durch SQL entrauscht werden. Die gesamte SQL-Entrauschungsvorlage lautet wie folgt:
SET odps.sql.mapper.split.size = 64;
SET odps.stage.joiner.num = 4000;
SET odps.stage.reducer.num = 1999;
CREATE TABLE table_diff AS
SELECT a.fields_as AS fields_as_main
,b.fields_as AS fields_as_branch
,a.fields_at AS fields_at_main
,b.fields_at AS fields_at_branch
,a.fields_d AS fields_d_main
,b.fields_d AS fields_d_branch
,a.fields_i AS fields_i_main
,b.fields_i AS fields_i_branch
,a.fields_j AS fields_j_main
,b.fields_j AS fields_j_branch
,a.fields_aw AS fields_aw_main
,b.fields_aw AS fields_aw_branch
,a.fields_k_json_key AS fields_k_json_key_main
,b.fields_k_json_key AS fields_k_json_key_branch
,a.fields_k_json_key_list AS fields_k_json_key_list_main
,b.fields_k_json_key_list AS fields_k_json_key_list_branch
,CASE WHEN a.fields_k_json_key = b.fields_k_json_key THEN 0
WHEN b.fields_k_json_key_list RLIKE a.fields_k_json_key THEN 0
WHEN a.fields_k_json_key_list RLIKE b.fields_k_json_key THEN 0
ELSE 1
END AS fields_k_json_key_diff_flag
FROM (
SELECT fields_as
,fields_at
,fields_d
,fields_i
,fields_j
,fields_aw
,MAX(CASE WHEN rn = 1 THEN fields_k_json_key END) AS fields_k_json_key
,CONCAT_WS(',',COLLECT_SET(fields_k_json_key)) AS fields_k_json_key_list
FROM (
SELECT *
,CASE WHEN NVL(GET_JSON_OBJECT(message,'$.fields_k'),'') = '' THEN '---'
WHEN GET_JSON_OBJECT(message,'$.fields_k') IN ('0','0.0') THEN '0-0-0'
ELSE GET_JSON_OBJECT(message,'$.fields_k')
END AS fields_k_json_key
,ROW_NUMBER() OVER (PARTITION BY fields_as,fields_at,fields_d,fields_i,fields_j,fields_aw ORDER BY offset DESC ) AS rn
FROM table_main
WHERE pt = 20230628
-- AND fields_i = 'realMetric'
)
WHERE rn < 6
GROUP BY fields_as
,fields_at
,fields_d
,fields_i
,fields_j
,fields_aw
) a
LEFT JOIN (
SELECT fields_as
,fields_at
,fields_d
,fields_i
,fields_j
,fields_aw
,MAX(CASE WHEN rn = 1 THEN fields_k_json_key END) AS fields_k_json_key
,CONCAT_WS(',',COLLECT_SET(fields_k_json_key)) AS fields_k_json_key_list
FROM (
SELECT *
,CASE WHEN NVL(GET_JSON_OBJECT(message,'$.fields_k'),'') = '' THEN '---'
WHEN GET_JSON_OBJECT(message,'$.fields_k') IN ('0','0.0') THEN '0-0-0'
ELSE GET_JSON_OBJECT(message,'$.fields_k')
END AS fields_k_json_key
,ROW_NUMBER() OVER (PARTITION BY fields_as,fields_at,fields_d,fields_i,fields_j,fields_aw ORDER BY offset DESC ) AS rn
FROM table_branch
WHERE pt = 20230628
-- AND fields_i = 'realMetric'
and fields_d !='group'
)
WHERE rn < 6
GROUP BY fields_as
,fields_at
,fields_d
,fields_i
,fields_j
,fields_aw
) b
ON NVL(a.fields_as,'-00') = NVL(b.fields_as,'-00')
AND NVL(a.fields_at,'-00') = NVL(b.fields_at,'-00')
AND NVL(a.fields_d,'-00') = NVL(b.fields_d,'-00')
AND NVL(a.fields_i,'-00') = NVL(b.fields_i,'-00')
AND NVL(a.fields_j,'-00') = NVL(b.fields_j,'-00')
AND NVL(a.fields_aw,'-00') = NVL(b.fields_aw,'-00')
;
Problem mit der Feldrauschunterdrückung
Symptom: Bei einer Änderung der Feldlogik schlägt das Diff-Ergebnis fehl, was sich auf das Diff-Ergebnis auswirkt.
Entrauschungslösung: Es ist notwendig, die logisch geänderten Felder aufzugeben, die logisch geänderten Felder nicht mehr zu beurteilen und sie flexibel über Java zu steuern.
String[] jsonColumnListStrings = jsonColumnList.split(",");
List<String> jsonColumnLists = new ArrayList<String>();
String[] iterationColumnStrings = iterationColumn.split(",");
List<String> iterationColumnLists = Arrays.asList(iterationColumnStrings);
for (String s:jsonColumnListStrings){
if(!iterationColumnLists.contains(s)){//判断字段是否为去噪字段
jsonColumnLists.add(s);
}
}
6. Diff-Ergebnisanalyse
Basierend auf dem vom aktiven und Standby-Diff synthetisierten SQL kann eine Vergleichsergebnistabelle erstellt werden, und die Analyse der Ausführungsergebnisse kann bestimmen, ob die Ausführung erfolgreich war oder nicht.
Analyselogik 1: Bestimmen Sie den Erfolgsanteil jedes Vergleichsfelds
Stellen Sie eine F&E-Analyse bereit, bei der analysierte Felder eine niedrige Erfolgsquote aufweisen.
Analyselogik 2: Bestimmen Sie den Anteil aller Felder, die die Gesamtzahl der Datensätze passieren
Dieser Indikator kann bestimmen, ob der Diff bestanden wurde. Wenn er 99,9 % ausmacht, bedeutet dies, dass er bestanden wurde.
SQL-Beispiel analysieren:
SELECT round(SUM(CASE WHEN fields_k_json_key_diff_flag = 0 THEN 1 ELSE 0 END) / COUNT(1) * 100,4) AS fields_k_ratio
,round(SUM(CASE WHEN fields_m_json_key_diff_flag = 0 THEN 1 ELSE 0 END) / COUNT(1) * 100,4) AS fields_m_ratio
,round(SUM(CASE WHEN fields_e_json_key_diff_flag = 0 THEN 1 ELSE 0 END) / COUNT(1) * 100,4) AS fields_e_ratio
,round(SUM(CASE WHEN fields_a_json_key_diff_flag = 0 THEN 1 ELSE 0 END) / COUNT(1) * 100,4) AS fields_aratio
,round(SUM(CASE WHEN fields_n_json_key_diff_flag = 0 THEN 1 ELSE 0 END) / COUNT(1) * 100,4) AS fields_n_ratio
,round(SUM(CASE WHEN fields_p_json_key_diff_flag = 0 THEN 1 ELSE 0 END) / COUNT(1) * 100,4) AS fields_p_ratio
,round(SUM(CASE WHEN fields_ac_json_key_diff_flag = 0 THEN 1 ELSE 0 END) / COUNT(1) * 100,4) AS fields_ac_ratio
,round(SUM(CASE WHEN fields_ar_json_key_diff_flag = 0 THEN 1 ELSE 0 END) / COUNT(1) * 100,4) AS fields_ar_ratio
,round(SUM(CASE WHEN fields_k_json_key_diff_flag = 0 AND fields_m_json_key_diff_flag = 0 AND fields_e_json_key_diff_flag = 0 AND fields_a_json_key_diff_flag = 0 AND fields_n_json_key_diff_flag = 0 AND fields_p_json_key_diff_flag = 0 AND fields_ac_json_key_diff_flag = 0 AND fields_ar_json_key_diff_flag = 0 THEN 1 ELSE 0 END) / COUNT(1) * 100,4) AS total_ratio
,COUNT(1) AS total_cnt
FROM table_diff
;
7. Werkzeug-Servitisierung
Verarbeitungslogik des Backend-Dienstes
Primärer und sekundärer Vergleich der SQL-Synthese
Implementieren Sie Diffs SQL in den Code, steuern Sie Daten-Slicing, Rauschunterdrückung und andere Szenarien über den Code, um die Test-SQL-Synthese abzuschließen.
for(String s:jsonColumnLists){
selectSql1 = selectSql1 + " case when NVL(GET_JSON_OBJECT(message,'$." + s + "'),'')='' then '---' when get_json_object(message,'$." + s + "') in ('0','0.0') then '0-0-0' else get_json_object(message,'$." + s + "') end AS " + s + "_json_key,";
selectSql2 = selectSql2 + " max(case when rn =1 then " + s + "_json_key end) as " + s + "_json_key,concat_ws(',',collect_set(" + s + "_json_key)) as " + s + "_json_key_list,";
mergeSql = mergeSql + " a." + s + "_json_key as " + s + "_json_key_main,b." + s + "_json_key as " + s + "_json_key_branch,a." + s + "_json_key_list as " + s + "_json_key_list_main,b." + s + "_json_key_list as " + s + "_json_key_list_branch,case when a." + s + "_json_key = b." + s + "_json_key then 0 when b." + s + "_json_key_list rlike a." + s + "_json_key then 0 when a." + s + "_json_key_list rlike b." + s + "_json_key then 0 else 1 end as " + s + "_json_key_diff_flag,";
}
rowNumberSql ="ROW_NUMBER() OVER (PARTITION BY fields_as,fields_at,fields_d,fields_i,fields_j,fields_aw ORDER BY offset DESC ) AS rn ";
selectSql1 = selectSql1 + rowNumberSql;
whereSql1 = whereSql1 + bizdate + " AND fields_i = 'realMetric' ";
String pretreatmentSqlMain = "";
String pretreatmentSqlBranch = "";
pretreatmentSqlBranch = selectSql2.substring(0,selectSql2.length()-1) + " from(" + selectSql1 + " from " + branchLinkTableName + whereSql1 + ")" + whereSql2 + groupSql.substring(0,groupSql.length()-1);
pretreatmentSqlMain = selectSql2.substring(0,selectSql2.length()-1) + " from(" + selectSql1 + " from " + masterLinkTableName + whereSql1 + ")" + whereSql2 + groupSql.substring(0,groupSql.length()-1);
mergeSql = mergeSql.substring(0,mergeSql.length()-1) + " from (" + pretreatmentSqlMain + ")a left join (" + pretreatmentSqlBranch + ")b " + joinSql.substring(0,joinSql.length()-3) + ";";
SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyyMMddHHmmss");
String dateStr = simpleDateFormat.format(new Date());
this.resultDataCreateSql = "set odps.sql.mapper.split.size=64;set odps.stage.joiner.num=4000;set odps.stage.reducer.num=1999; create table du_temp.diff_main_branch_" + dateStr + "_test as " + mergeSql;
log.info(resultDataCreateSql);
this.resultDataTable = "du_temp.diff_main_branch_" + dateStr + "_test";
log.info(resultDataTable);
//合成过滤结果数据的sql
String resultSql = " select ";
String totalResultSql = "round(sum(case when ";
for(String s:jsonColumnLists){
resultSql = resultSql + " round(sum(case when " + s + "_json_key_diff_flag = 0 then 1 else 0 end)/count(1)*100,4) as " + s + "_ratio,";
totalResultSql = totalResultSql + " " + s + "_json_key_diff_flag = 0 and";
}
this.resultDataFiltrate = resultSql + totalResultSql.substring(0,totalResultSql.length()-3) + " then 1 else 0 end)/count(1)*100,4) as total_ratio , count(1) as total_cnt from " + this.resultDataTable + ";";
log.info(resultDataFiltrate);
Analyse des Diff-Ergebnisberichts
...}
else if(testType.equals("主备diff")) {
for (Map.Entry entry:testResultRecord.entrySet()) {
List<String> listValue = (List<String>) entry.getValue();
this.resultData.put(entry.getKey().toString(),listValue.get(0)) ;
if(Double.parseDouble(listValue.get(0))< 99.9 & !entry.getKey().toString().equals("total_cnt")){
this.failDetail.put(entry.getKey().toString(),listValue.get(0)) ;
}
}
if(failDetail.size()>0){
this.testStatus = "失败";
}else {
this.testStatus = "成功";
}
}
Plattformvisualisierung
- Aufgabe erstellen
- Ausführungsliste
- Ergebnisbericht-Plattformanzeige
Wie unten gezeigt: Als Ergebnis eines Ausführungsfehlers beträgt die Erfolgsquote 99,8471, was nicht 99,99 % erreicht .
- Ergebnisbericht-Feishu-Benachrichtigung
Hier ist ein Beispiel:
Name der Ausführungsanforderung: Active-Backup Diff-521 Ausführender: *** Ausführungstyp: Active-Backup Diff Ausführungsnummer: 20230628204636 Name der Ausführungs-Backup-Link-Tabelle: table_main Name der Haupt-Link-Tabelle der Ausführung: table_branch Partition der Ausführungs-Backup-Link-Tabelle: 20230628 Details zum Ausführungsergebnis Tabelle: table_diff Zusammenfassung der Ausführungsergebnisdetails: Fields_am_ratio:99,9958 Fields_z_ratio:99,9826 Fields_af_ratio:99,9856 Fields_ba_ratio:99,9964 Fields_al_ratio:99,9915 Fields_ad_ratio:99,9873 Fields_r_ratio:99,9826 Fields_aa_ratio:99,9 906 Fields_ai_ratio:99,9856 Fields_v_ratio:99,9917 Fields_ak_ratio:99,9909 Fields_m_ratio:99,9969 Fields_ak_ratio:99,9945 Fields_bb_ratio :99.9964 fields_bc_ratio:99.9957 fields_bd_ratio:99.9954 fields_ae_ratio:99.9856 fields_be_ratio:99.9952 fields_bf_ratio:99.9955 fields_t_ratio:99.9917
fields_ag_ratio:99.9856 fields_p_ratio:99.9909 fields_bg_ratio:99.9948 fields_a_ratio:99.9969 fields_d_ratio:99.9969 fields_x_ratio:99.9826 fields_an_ratio:99.9917
fields_ap_ratio:99.9909 fields_ar_ratio:99.9915 fields_y_ratio:99.9917 fields_bh_ratio:99.9955 fields_aj_ratio:99.9916 fields_bi_ratio:99.987 fields_ac_ratio:99.9908 fields_s_ratio:99.9826 fields_ab_ratio:99.9906 fields_i_ratio:99.9969 fields_bj_ratio:99.9951 fields_ah_ratio:99.9959
fields_k_ratio:99.9969
fields_e_ratio:99.9969 fields_bk_ratio:99.9962 fields_bl_ratio:99.8748 fields_al_ratio:99.9958 fields_j_ratio:99.9969
fields_bm_ratio:99.9951 fields_n_ratio: 99,9969 Fields_ao_ratio:99,9909 Fields_w_ratio:99,9906 Fields_bn_ratio:99,9965 Fields_bo_ratio:99,9912 Fields_bcrate_ratio:99,987 Fields_y_ratio:99,9958 Zusammenfassende Daten der aktiven und Standby-Diff-Ausführungsergebnisse: total_ratio:99,8471 total_cnt:71 42
59 Details zum Fehler beim Ausführungsergebnis:
Fields_bl_ratio:99.8748
Total_ratio:99.8471% Ausführungsergebnis Status: fehlgeschlagen
8. Zugriffs- und Freigabeprozess für aktive und Standby-Diff-Tools
Wenn der bereitgestellte Backup-Link schließlich den Test der aktiven und Backup-Diff-Tools besteht, ist er online und entspricht derzeit einer Backup-Produktionslinie.
Wenn die Anforderungen für nachfolgende Versionsiterationen vor der Online-Schaltung vom Diff-Tool überprüft werden, erfüllen sie die Online-Anforderungen.
9. Zusammenfassung
Echtzeit-Computing unterscheidet sich von Offline-Data Warehouses. Die Stabilität und Genauigkeit von Daten sind schwer zu kontrollieren. Komplexe Verbindungen können die Qualität der Gesamtdaten nicht durch einfache Tests garantieren. Die Form von Dual-Link-Diff kann Echtzeitdaten besser garantieren während Iterationen. die Qualität von.
Für die Implementierung von Aktiv- und Standby-Diff: Der größte Nachteil besteht häufig darin, dass das Datenrauschen sehr groß ist. Daher sind technische Mittel zur Reduzierung des Rauschens erforderlich, um die Genauigkeit und Zuverlässigkeit der Datenvergleichsergebnisse sicherzustellen.
* Text/Shiyu
Dieser Artikel stammt ursprünglich von Dewu Technology. Weitere spannende Artikel finden Sie auf der offiziellen Website von Dewu Technology
Ein Nachdruck ohne die Genehmigung von Dewu Technology ist strengstens untersagt, andernfalls wird eine rechtliche Haftung gemäß dem Gesetz verfolgt!
Broadcom kündigte die Beendigung des bestehenden VMware-Partnerprogramms an . Site B stürzte zweimal ab, Tencents „3.29“-Vorfall der Stufe eins … Bestandsaufnahme der zehn häufigsten Ausfallvorfälle im Jahr 2023, Vue 3.4 „Slam Dunk“ veröffentlicht, Yakult bestätigte, dass 95G-Daten durchgesickert sind MySQL 5.7, Moqu, Li Tiaotiao... Bestandsaufnahme der (Open-Source-)Projekte und Websites, die 2023 „gestoppt“ werden „2023 China Open Source Developer Report“ wird offiziell veröffentlicht Rückblick auf die IDE vor 30 Jahren: nur TUI, helle Hintergrundfarbe …… Julia 1.10 offiziell veröffentlicht Rust 1.75.0 veröffentlicht NVIDIA hat GeForce RTX 4090 D speziell für den Verkauf in China auf den Markt gebracht