Først og fremmest er du velkommen til at fjerne HDFS- og CKAN-konfigurationsdelene. Du vil undgå unødvendige logfiler relateret til disse komponenter, når du kører Cygnus. Husk selvfølgelig at slette alle referencer til dræn og kanaler; specifikt:
cygnusagent.sources = http-source
cygnusagent.sinks = mysql-sink
cygnusagent.channels = mysql-channel
...
cygnusagent.sources.http-source.channels = mysql-channel
For det andet kan svaret på dit spørgsmål findes i dokumentationen:
Inden for tabeller kan vi finde to muligheder:
- Reparerede rækker med 8 felter som sædvanlig:recvTimeTs, recvTime, entityId, entityType, attrName, attrType, attrValue og attrMd. Disse tabeller (og databaserne) oprettes på udførelsestidspunktet, hvis tabellen ikke eksisterede før rækkeindsættelsen. Med hensyn til attrValue, i sin enkleste form, er denne værdi kun en streng, men siden Orion 0.11.0 kan den være Json-objekt eller Json-array. Med hensyn til attrMd indeholder den en strengserialisering af metadataarrayet for attributten i Json (hvis attributten ikke har metadata, indsættes et tomt array []),
- To kolonner pr. hver enheds attribut (en for værdien og en anden for metadataene), plus en tilføjelseskolonne om modtagelsestiden for dataene (recv_time). Denne slags tabeller (og databaserne) skal klargøres tidligere til udførelse af Cygnus , fordi hver enhed kan have et forskelligt antal attributter, og meddelelserne skal sikre, at en værdi pr. attribut underrettes.
Connectorens adfærd med hensyn til den interne repræsentation af dataene styres af en konfigurationsparameter, attr_persistence, hvis værdier kan være række eller kolonne.
Måske er der et problem med skrivningen, jeg tror, at det sidste afsnit skal enda som "... hele værdier kan være række eller kolonne, og hvis adfærd svarer til de muligheder, der er beskrevet ovenfor, henholdsvis " .
dvs. hvis du bruger kolonnetilstanden, skal databasen og tabellerne være klargjort på forhånd.
Der er en lignende spørgsmål hvor jeg forklarer mere detaljeret sådan en adfærd.
HTH!