От: Дейвид Андерсън, водещ софтуер на практика в Confluent Flink SQL е мощен двигател, предназначен за обработка в реално време, стрийминг на данни, използвайки познатия SQL език и неговите основни релационни концепции.Това отдавна е ефективно решение за много домейн приложения, особено ETL тръбопроводи и аналитични работни натоварвания, но досега Flink SQL липсва ключови функции, често необходими за приложения, базирани на събития. С последните разработки, описани тук, релационните API на Apache Flink – а именно Flink SQL и Table API – са узрели до такава степен, че използването на мощните им абстракции и вградените оператори вече не изисква компромис за достъп до ниско ниво обработка на потока на Flink примитиви. Всичко казано тук се отнася еднакво както за Flink SQL, така и за Table API. И двете се намират на върха на едно и също време за изпълнение - концепциите и основните възможности са едни и същи - те са достъпни само от Java или Python, а не от SQL, ако изберете да използвате Table API. Използвайте случаи Тези релационни API са особено подходящи за две широки категории приложения. Agentic AI Съвременните приложения на ИИ често изискват достъп до динамична информация в реално време. Flink SQL улеснява агентическия ИИ, като улеснява комбинирането на потоците от събития в реално време с прозрения от агенти, модели и услуги. Shift left В света на обработката на данни, "преместването на ляво" се отнася до извършване на трансформации и обогатяване на данни възможно най-рано в потока от данни. релационните API на Flink се отличават тук, като позволяват трансформации в реално време и обогатяване с други набори от данни. Познаване съчетано с новост Традиционно, SQL се използва както за оперативни, така и за аналитични случаи на използване. Flink SQL използва добре обмислените концепции и семантика, разработени за онлайн обработка на транзакции (OLTP) и онлайн аналитична обработка (OLAP), и ги разширява, за да отговори на изискванията на приложения за обработка на потока в реално време. The relational algebra remains the same Основните принципи на релационната алгебра, които образуват основата на SQL, са напълно запазени в Flink SQL. Докато традиционните SQL таблици са статични, Flink SQL въвежда концепцията за динамични таблици, които са логически представяния на непрекъснати, неограничени потоци от данни. Tables: Агрегациите (напр. „СЪМ“, „СЪМ“, „AVG“) се прилагат към потоците, осигурявайки обобщения в реално време на данните. Aggregations: Flink SQL поддържа различни операции за обединяване, което позволява да се комбинират данни от различни източници за поток. Те могат да варират от традиционни вътрешни и външни съединения до по-специализирани временни съединения. Joins: Всяко изречение на Flink SQL непрекъснато изчислява резултата от заявка в потоци, което позволява незабавен достъп до често искани данни. Continuous queries (materialized views): New challenges and ideas for stream processing От друга страна, прилагането на тези релационни концепции към динамичния свят на обработката на потока въвежда някои нови съображения: Операциите за обработка на потока често трябва да поддържат "състояние" - информация за минали събития - за да изпълняват изчисленията си. Например, агрегацията трябва да следи частично натрупания резултат, а съединението може да се нуждае от буферни записи от един поток, докато чака съвпадение на записи от друг. Разработчиците, които използват Flink SQL (или таблицата API), трябва внимателно да обмислят управлението на състоянието, тъй като прекомерното състояние може да повлияе на производителността и потреблението на ресурси. Thinking about state: При обработката на потока събитията могат да дойдат извън реда или с закъснения. Водните знаци са ключова концепция в Flink SQL, която помага за справяне с тези нередности, като осигурява понятие за "комплектност" за потоците. Водните знаци определят праг, след който Flink приема, че няма да дойдат повече събития с по-ранна времева марка, което позволява последователни обобщени агрегации и навременни резултати. Watermarks: Flink SQL включва редица специални временни версии на държавни операции, като например агрегации с времеви прозорец и прозоречни съединения, които разчитат на водни знаци, за да знаят кога резултатите им са готови да бъдат излъчени (и кога състоянието, което държат, може да бъде освободено). Последните събития Последните разработки правят тези релационни API-та по-привлекателни от всякога. Flink SQL и Table API са силно разширяеми чрез използването на User-Defined Functions (UDFs). Те позволяват Java или Python да се използват за прилагане на потребителска логика, която не може да бъде изразена директно в SQL. UDFs могат да извършват сложни изчисления, да експлоатират библиотеки на трети страни, да се интегрират с външни системи или да изпълняват специфични за домейна трансформации. За разлика от традиционните UDF, PTF могат да обработват цели таблици (потоци) по усъвършенстван начин, като използват услугите за управление на състоянието и таймера на Flink.Това позволява потребителски дефинирани оператори, като персонализирани функции на прозореца или съединения, които са толкова богати на функции, колкото и вградените оператори. Process Table Functions (PTFs) Изтегляне на съобщения в Flink SQL Операциите за обединяване илюстрират сходствата и ключовите различия в релационните API на Flink в сравнение с традиционните бази данни на SQL. Този раздел използва някои практически примери, за да проучи как представените по-горе понятия могат да се прилагат към реални приложения, които използват обединения. Помислете например за онлайн бизнес обработка на поръчки и плащания, където всяко плащане е свързано с чуждестранен ключ (ordreId) към една поръчка. поръчки и плащания са теми на Apache Kafka и искаме да създадем нова тема Kafka за платени поръчки, която ще се използва за изпълнение на поръчки. Едно просто решение, което изглежда, че трябва да работи е CREATE TABLE PaidOrders AS (
  SELECT
    o.id AS orderId,
    p.id AS paymentId
  FROM
    Orders o INNER JOIN Payments p ON o.id = p.orderId
);
 Разбира се, в реално приложение бихме извадили куп повече информация в изхода, като например идентификационния номер на клиента, адреса за доставка и идентификационните номера на продуктите, които се поръчват. В речта на общността на Flink, присъединяването като това се нарича "редовно присъединяване" (което означава, че не сме направили нищо специално, за да позволим на Flink да го изпълнява по-ефективно).И когато се изпълнява от поточното изпълнение на Flink SQL, редовното присъединяване може да бъде изненадващо скъпо. Всъщност, въз основа на нашите познания за това как тази компания управлява бизнеса си, може да знаем, че всяка поръчка ще има най-много едно съответстващо плащане, така че няма нужда Flink да съхранява поръчка след момента, в който плащането е било обработено. Едно нещо, което можем да направим, за да направим това присъединяване по-евтино, е да приемем, че плащанията винаги ще се случват в рамките на два часа от поръчката (например): CREATE TABLE PaidOrders AS (
  SELECT
    o.id AS orderId,
    p.id AS paymentId
  FROM
    Orders o INNER JOIN Payments p ON o.id = p.orderId
  WHERE
    p.paymentTime BETWEEN o.orderTime AND o.orderTime + INTERVAL '2' HOUR
);
 Това ще ограничи колко време поръчките се съхраняват в състоянието на Flink, но това не е много задоволителен подход.От една страна, ние бихме предпочели да освободим състоянието на поръчката веднага след като се съвпадне с плащане, а от друга страна, някои плащания могат да бъдат забавени за повече от 2 часа. с други думи, това е начин да получите отговор, на който не можем да се доверим, и да похарчите повече, отколкото е необходимо, за да стигнете там. За съжаление, обогатяването на едно към едно съобщение, което идеално бихме искали да направим в този случай, не може да бъде директно изразено с помощта на стандартни SQL концепции. Ето един опростен пример за това как може да изглежда това: // Function that buffers one object from each side
// of the join to produce exactly one result.
public static class OrderPaymentJoin
  extends ProcessTableFunction<JoinResult> {

  public void eval(
    Context ctx,
    @StateHint(name = "result") JoinResult result,
    @ArgumentHint(SET_SEMANTIC_TABLE) Order order,
    @ArgumentHint(SET_SEMANTIC_TABLE) Payment payment
  ) {

    if (order != null) {
      if (result.orderId != null) {
        // Skip duplicates.
        return;
      } else {
        // Save the order and wait 
        // for the matching payment.
        result.orderId = order.id;
      }
    }

    if (payment != null) {
      if (result.paymentId != null) {
        // Skip duplicates.
        return;
      } else {
        // The order will precede the payment, but
        // we cannot guarantee the order will be
        // processed first. Save the payment
        // and wait for the matching order.
        result.paymentId = payment.id;
      }
    }
  
    if (result.orderId != null && 
        result.paymentId != null) {
      // Send out the final join result
      // and clear the state.
      collect(result);
      ctx.clearState("result");
    }
  }
}
 С този PTF на място, нашата заявка за присъединяване става CREATE TABLE PaidOrders AS (
  SELECT
    orderId,
    paymentId
  FROM
    OrderPaymentJoin(
      order => TABLE(Orders) PARTITION BY order_id,
      payment => TABLE(Payments) PARTITION BY order_id 
    )
);
 На практика този опростен пример би могъл да бъде разширен, за да се направи нещо по отношение на възможността за натрупване на все по-голям брой несравними поръчки (за поръчки, които никога не получават плащания). Други вълнуващи събития Native support for ML models FLIP-437 (включен в Flink 2.0) добави поддръжка за модели за машинно обучение като първокласни граждани в Flink SQL. Disaggregated state backend Общността на Flink разработва по-облачен подход към управлението на състоянието, което в крайна сметка ще направи по-практично за приложенията да използват огромни количества състояния. Това никога няма да премахне необходимостта да мислите за изискванията за състоянието на вашите стрийминг приложения, но ще промени значително начина, по който трябва да разгледате компромисите. За повече подробности. Документация Semi-structured types Полуструктурираните данни предлагат по-голяма гъвкавост, като например позволяват добавянето на полета с течение на времето, опционални полета или полета, чийто тип може да варира от ред към ред. В момента потребителите на релационните API на Flink трябва да избират между ROW с строги схеми и статични типове, или да съхраняват данни като JSON струни. добавя тип VARIANT, за да поддържа полуструктурирани данни, които могат да се съхраняват и обработват ефективно. Флип-521 За по-дълбоко разбиране За да научите повече за Flink SQL, Ще започнете с вас. Видео на непрекъснати запитвания на Има няколко отлични примера, ако искате да се потопите по-дълбоко в тази тема. Документация за функциите на таблицата на процеса Шон Фалкънър разкрива защо . Бъдещето на AI агентите е задвижвано от събития Бъдещето на AI агентите е задвижвано от събития

This story contains new, firsthand information uncovered by the writer.

Това аудио е създадено на оригиналния език на историята!

Какво трябва да знаете за най-новите актуализации на Apache Flink SQL и Table API

About Author

КОМЕНТАРИ

ЗАКАЧВАЙТЕ ЕТИКЕТИ

ТАЗИ СТАТИЯ Е ПРЕДСТАВЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps